Hacker News Reader

Comment by matsemann | Hacker News Reader

Before, only the senior cobol programmers at the company understood and knew the codebase.

Now, no one does.

I can see the allure of moving away from a legacy cobol system. But an AI rewrite doesn't actually solve any of the issues with having a legacy cobol codebase. You just have a new system no one knows or understands.

View on HN

> Now, no one does.

I got a chuckle over this, but in my experience working on legacy systems, this is the case already. Using AI to translate/explain the code brings extra understanding.

Whilst true, it's not without its gotchas, and I saw a video the other day that elegantly highlights this: https://www.youtube.com/watch?v=t6MAZW-joCo. A false sense of confidence is bad; one that is offloaded onto somebody else is another.

Can it really explain the code if the information is not there anymore ? It was in a binder that got shredded 40 years ago by accident.

More like it will hallucinate some explanation & cause even more confusion.

If what you want is the "Why", you're right it probably won't get it right. It'll just give you baseless speculation. But if what you want is the "What" or the "How", I think it can be useful.

The code is the information. If you need binders of info then it wasn’t codified

Yes, it would take a long time for humans to remake a documentation from the codebase itself, but AI could do that much quicker and with close to perfect accuracy, Code is superior to documentation as it's the direct intended behavior (including bugs), in a sense, we won't even need documentation in the future, except maybe to lower AI costs.

It seems to me that some companies are looking to move off COBOL and mainframes to say Linux and Java, because that is what someone was employed to do, not because it's necessarily a good idea.

I think COBOL systems would be plenty maintainable if the owners of the systems invested in maintaining them. If companies just let people retire, attempt to hire replacements with unremarkable salaries, then maintenance is a problem.

If they paid salaries that reflected how critical this work is, I don't think it would be that big a problem to find and keep good developers.

We have critical economic infrastructure being treated as annoyance and a cost centre.

I firmly believe that any thoughtful rewrite is good. Most companies just don't have resources for that. At least, it serves as a security review, but also refreshes team knowledge of the system. They usually also improve documentation if it was wrong.

Wasn't COBOL invented to read like business prose and be easily understood by programmers and non-programmers alike? If developers are able to write COBOL code no one understands than it failed its main objective.

IMHO every large software system should be developed on the basis of clear and concise functional specifications so everyone can understand what the software does and how it does so at a higher functional level.

Cobol code isn't esoteric, but it is designed in a way that is unambiguous and clear about its control flow, but very verbose and tedious to read/write. Translating from Cobol to a modern programming language is trivial for LLMs for that reason because the lack of any hidden state functionalities like generics for example.

Modern Cobol has most of the goodies, it is much more feature rich than Go.

Your last paragraph is getting at the core problem: COBOL _is_ easy to understand and write at the language level but what keeps people on these systems is decades of accumulated business rules, and it’s almost certain that there’s no accurate spec for the whole system. You might have some overall documentation but I’d expect to find cases where someone added a special case back in 1987 to handle an edge case and everyone who works in shipping knows there’s something special to do if this usually numeric field starts with a $ sign etc. but it’s not described in some kind of spec.

Java should have significantly better tools for trying to understand a program than cobol.

It has had for plenty of years now, however many think vi and emacs is enough.

"Now, no one does."

well, we just need to learn the rewrite then ???

Yeah, "We are looking for a developer specialized in critical Java code following idiomatic COBOL which hasn't been tested in production yet and which nobody is sure about whether the exact behavior matches what's been running in production. You will enjoy meaningful work in an environment which has been considering engaging in environmental concerns for decades and which caries the well-being and social condition of fellow human beings as a core values, directly addressing your middle age existential crisis. Extra bonus points if you like using LLMs. The pay is good, but remember you are a Java developer, not a COBOL developer, and also remember we are already paying for tokens to do your job. Those are also possibly getting more and more expensive so we'll see about the raises. Job starts as soon as possible."

The problem isn't as much understanding what the code does (that's hard but not impossible), but understanding why that duplicate INSERT into the database is needed.

The guy who no longer works at the company knew it was because of a bug in the DB that wasn't fixed by the vendor after the company cancelled the maintenance contract due to financial difficulties during the great recession.

AI doesn't and can't know that. So AI proposes to "fix the bug as we port it" and remove the double INSERT. The CTO sends an email saying that the new AI fixed 174 bugs during the porting process and now the company has a much better and resilient system.

BREAKING NEWS: thousands of travelers can't get go back home after thanksgiving due to a computer glitch that accidentally cancelled their return tickets. Stay tuned to our live coverage!

nah you just make it hyperbole

If you can migrate using a strangle pattern, I can see it working pretty well and fast.

> Now, no one does.

Not true, AI does. It's AI job security...

Having worked in COBOL extensivly in the 80s and 90s, as well as working for a software house that did migrations (Craziest was Plan assembler to Dec Vax C).

I do wonder how an ambitious AI would handle the maths. COBOL is renowed for its fixed no rounding maths, utterly rigid and defined in the code, Java on the other hand is not (e.g., 0.1 + 0.2 becomes 0.30000000000000004), unless they are extensivly using BigDecimal, then its already a broken migration.

I've seen projects proclaim in the past to migrate COBOL systems to Java, and fail expicly when the solution was a dtaawarehouse system and a seperate Java system using the legacy backend to do all the fancy marketing reports or whatever other department was pushing for changes they wanted without a grasp of what it truly entailed and blinded by some sales pitch.

It's not just the code that needs migrating, its the data as well, then you want solid robust infrastrucure, which is why IBM still sell those mainframes to run all that well battle tested COBOL code.

Is it impossible to migrate to Java or any othger language - no, anything can be done, but the level of devil in the details and not just software, the data and a robust system to run it upon. It is very easy for even the best to overlook a gotcha.

We have all used an AI where it has gone down one path and you then point out something and it corrects itself, without the knowledge and a load of old grey beads(or a team) to act as devil advocate and try to pull the output apart, YOU can end up with something that works for everyones satisfaction, but is hiding a few gotchas down the line. AI coding needs a full debate team with one puishing it and one countering it almost I'd say.

If it works, why change it is always a good approach and why we mostly have in certain systems a COBOL backend with APIs or datawarehousing to expose for fancy java or other language added value/functionality.

I can only image generations of directors pushing cutting edge to replace legacy systems, and learning that cutting edge can cut you. My sympathy for the IT departments who have to deal with that as it has always been a bain of IT departments who are then forced to justify why it's fooling in a constructive way and explain it to non IT people in upper managment why the case.

As for migrating COBOL to anything, I'd not do it myself, id suggest a rewrite/redesign of a new system from scratch and then run both in parallel for a long time and make sure they actually do the same job and results. Even hand migrating back in the day, would produce a lot of messy code that refactoring would make sence and yet, not what the client would pay for as that would be a rewrite.

You can't use BigDecimal either. There are libraries whose whole purpose is just to exactly reproduce COBOL arithmetic, eg. the IBM Decimal Arithmetic Library.

Wow, their Java code example [0] makes COBOL look elegant and terse by comparison.

[0] https://community.ibm.com/community/user/blogs/gregory-cerne...

I know it's not the only problem (but it is IMO the main one), but this is why I'm a proponent of allowing operator overloading in languages.

Yes, you can't tell at a glance if `+` really still does what it should, but I find that problem no different from a library mis-naming a function and/or said function having strange side-effects.

`+` should do addition, period. No, not even concatenation if possible (I do find the lack of a separate concatenation operator to be a language flaw --- that said, I understand the use of `+` for concat in libraries targeting languages that offer no alternative).

I think the abuse (especially in C++ ... seriously, allowing overloading of the comma operator? --- and <iostream> working via bit-shifting streams by ${some_string} bits) gave everyone a bad taste and they kind of threw out the baby with the bathwater.

php has a separate `.` operator that concatenate and you get an error if you try to do it with a `+`. That's indeed better but most of the time you concatenate with `sprintf` anyway

Yes, and it's a surprising good part about PHP (a language that otherwise has an enormous collection of warts, to put it mildly).

I feel like the more dynamic and/or weakly-typed the language is, the more important it is to have a separate concat operator.

The worst ones being weakly-typed and dynamic. Consider `'5' + '10'` in JavaScript vs `'5' - '10'`. I also very much dislike Python's `+` for concat, but at least it's more strongly typed.

PHP, Lua, and Erlang are three examples of dynamically-typed languages with separate concat operators (`.`, `..`, `++`; respectively), and they all are better for it.

That said, even statically-typed languages benefit greatly from it. Maybe if C++ had a concat operator, it'd never end up abusing `<<` for writing to a stream (yes, there's no opposite for reading, but maybe they wouldn't end up doing that in this case).

For example, D uses `~` in infix for concat. Even UnrealScript, a 1990s game-engine-specific language (which tend to be a mess in general) did this right (it uses `$` or `@` --- with `a @ b` being equivalent to `a $ " " $ b`, IIRC).

It seems like Java is thinking about it now that Valhalla is landing and they’re expecting more user defined mathematical types.

Aehm we were writing proper math code in Java 15 years ago already.

Your 0.1 + 0.2 example wasn't an issue than and is not an issue today.

Start extracting specs from the codebase.

Prompt the core architecutre well suited for it.

Let it write tests.

Let it vibe migrate from left to write.

Now you at least have a chance of a team being able to work on that code base and actually clean it up and make it good.

Cobold is hard, hard legacy with bad tooling.

Reply on news.ycombinator.com