Technology
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
view the rest of the comments
This is what in thinking. Even the few people I know IRL that know COBOL from their starting days say it's a giant pain in the ass as a language. It's not like it's really gonna cost all that much time to do compared to paying labor to rewrite it from the base, even if they don't end up using it. Sure, correcting bad code can take a lot of time to do manually. But important code being in COBOL is a ticking time bomb, they gotta do something.
Counterpoint: if it ain’t broke, don’t fix it.
Counter counterpoint: The longer you let it sit the more obsolete the language becomes and the harder it becomes to fix it when something does break.
This is essentially preventative maintenance.
Counter^3 point: a system that was thoroughly engineered and tested a long time ago, and that still fulfills all the technical requirements that the system must meet will simply not spontaneously break.
Analogously: this would be like using an ML + LLM to rewrite the entire Linux kernel in Rust. While an (arguably) admirable goal, doing that in one fell swoop would be categorically rejected by the Linux community, to the extent that if some group of people somehow unilaterally just merged that work, the rest of the Linux kernel dev community would almost certainly trigger a fork of the entire kernel, with the vast majority of the community using the forked version as the new source of truth.
This is not preventative maintenance. This is fixing something that’s not broken, that has moreover worked reliably, performantly (enough), and correctly for literal decades. You do not let a black box rewrite your whole codebase in another language and then expect everything to magically work.