This is possibly one of the more cursed single sentences I've ever seen in a job posting

Cassandra Granade 🏳️‍⚧️

@aud It's a 3SAT reduction... The fact that you can have non-overlapping ranges of versions allowed gives you a lot of expressive power.

Asta [AMP]

@[email protected] The more I learn about computing, the more I understand why @[email protected] has so many strong feelings about packaging.

Asta [AMP]

@[email protected] @[email protected] "COPILOT" but it's just a guy deeply into COBOL programming and aviation and he lives in a forested area and he hates programming but will happily call your code shit if you pay him enough to review it.

Asta [AMP]

@[email protected] @[email protected] "COPILOT, please write a for loop in java with proper documentation"
"dipshit money boy, I made love to your mother who was a vastly superior programmer to you. We bonded over what a fucking disappointment you are."

Flatbush Gardener 🌈

@xgranade @aud
It needs to remain maintainable. Otherwise, COBOL *is* your source code now.

Cassandra Granade 🏳️‍⚧️

@xris @aud I guess, but I wouldn't expect the result of COBOL → Java to be maintainable? Normally how I've seen that kind of move away from legacy done is use the legacy language (here, COBOL) as the source of truth, then gradually replace it one module at a time rather than trying to maintain the output of transpilation.

Cassandra Granade 🏳️‍⚧️

@xris @aud I guess that gets back to @ireneista's point about COBOL being line-oriented, though... that would absolutely make it much harder to replace module-by-module.

Asta [AMP]

@[email protected] @[email protected] Perhaps that's why they think this will "totally work": why, LLMs are so "natural" and human like! Unlike that awful machine transpilation (which, you know, is auditable and not stochastic and actually works). So they, perhaps foolishly, think of this output as being maintainable?*

* they probably don't think any of this, but I wonder if that's somewhere in their brains as re: how this all works.

Asta [AMP]

@[email protected] @[email protected] @[email protected] oh, well. There's that too. I dunno much about COBOL so I don't have that level of insight into the problem.

Irenes (many)

@aud @xris @xgranade there's that for sure. the idea that functions and code blocks should always have well-defined boundaries, not porous edges, had to be invented. any attempt to translate to a modern language needs to grapple with that tension. in our other thread we wrote about our experience writing a mechanical translator for a language called DB/C...........

Irenes (many)

@aud @xris @xgranade but like the other big problem is that the contexts where code in line-oriented languages are still in use are things like banking and aviation

where the risk of making ANY change is just enormous, let alone replacing the whole thing

Irenes (many)

@aud @xris @xgranade the translation isn't even the hardest part of a migration effort there, it's the testing strategy. how do you gain confidence your new code won't kill people and/or cause you to go bankrupt in microseconds?

SpookJ 👻

@aud @xgranade it scans as a reasonable choice to me. It has a few desirable properties:

1) It's not COBOL (read as: you can find literally anybody to maintain it)

2) It has a *lot* of operational experience in "this absolutely must not fall over" contexts. See (1), not only can you find a lot of people to work on it, you can find a lot of people whose entire careers are organized around critical support for keeping applications in it afloat.

3) It's perfectly adequate. Not sexy, but fine.

Cassandra Granade 🏳️‍⚧️

@SnoopJ @aud Agreed, but the problem is that Java works by being legible to the most common denominator amongst developers; that goes out the window if you have highly non-idiomatic code written by a transpiler.

Cassandra Granade 🏳️‍⚧️

@ireneista @aud @xris Makes a lot of sense. You could pretty easily prove and test your transpiler, but if you make a single change to the emitted code then that all goes out the window.

Asta [AMP]

@[email protected] @[email protected] @[email protected]

where the risk of making ANY change is just enormous

yeah, that kind of gets into why I poked fun of this in the first place: I do not, at all, trust the people posting this to take this risk seriously.

Even if the stochastic element is small, you really just shouldn't go around and introduce a stochastic element in a scenario where determinism is critical. It's just... wrong from the start.

SpookJ 👻

@xgranade @aud oh, yea, vote of no confidence in the particular choice to transpile it.

It's a billion-dollar industry if such a tool existed, but… well, it doesn't exist yet for a reason…

And the LLM thing just signals "we are absolutely not serious about this". One can only assume they don't understand how that scans to the target market.

Irenes (many)

@aud @xris @xgranade absolutely agreed. it is fundamentally not possible for LLMs in their current form to do anything about reliability or testing their output against reality, and none of the lines of research we're aware of that are getting venture capital or institutional investment would change that, even if successful

Asta [AMP]

@[email protected] @[email protected] @[email protected] Right? And, well, actually, even the testing is probably difficult without introducing the idea of "reasonable error"... and considering the "reasonable error" for these types of systems is "0. precisely 0. it's a fucking airplane."

welp

Glyph

@SnoopJ @xgranade @aud +1000 to "we are absolutely not serious about this". I would bet on this company's success if they quietly swapped out the LLM for the guts of an extant COBOL compiler