It’s not the 1st time a language/tool will be lost to the annals of the job market, eg VB6 or FoxPro. Though previously all such cases used to happen gradually, giving most people enough time to adapt to the changes.
I wonder what’s it going to be like this time now that the machine, w/ the help of humans of course, can accomplish an otherwise multi-month risky corporate project much faster? What happens to all those COBOL developer jobs?
Pray share your thoughts, esp if you’re a COBOL professional and have more context around the implication of this announcement 🙏
Converting ancient code to a more modern language seems like a great use for AI, in all honesty. Not a lot of COBOL devs out there but once it’s Java the amount of coders available to fix/improve whatever ChatGPT spits out jumps exponentially!
The fact that you say that tells me that you don’t know very much about software engineering. This whole thing is a terrible idea, and has the potential to introduce tons of incredibly subtle bugs and security flaws. ML + LLM is not ready to be used for stuff like this at the moment in anything outside of an experimental context. Engineers are generally - and with very good reason - deeply wary of “too much magic” and this stuff falls squarely into that category.
All of that is mentioned in the article. Given how much it cost last time a company tried to convert from COBOL, don’t be surprised when you see more businesses opt for this cheaper path. Even if it only converts half of the codebase, that’s still a huge improvement.
Doing this manually is a tall order…
And doing it manually is probably cheaper in the long run, especially considering that COBOL tends to power some very mission critical tasks, like financial systems.
The process should be:
- set up a way to have part of your codebase in your new language
- write tests for the code you’re about to port
- port the code
- go to 2 until it’s done
If you already have a robust test suite, step 2 becomes much easier.
We’re doing this process on a simpler task of going from Flow (JavaScript with types) to TypeScript, but I did a larger transition from JavaScript to Go and Ruby to Python using the same strategy and I’ve seen lots of success stories with other changes (e.g. C to Rust).
If AI is involved, I would personally use it only for step 2 because writing tests is tedious and usually pretty easy to review. However, I would never use it for both step 2 and 3 because of the risk of introducing subtle bugs. LLMs don’t understand the code, they merely spot patterns and that’s absolutely not what you want.
Even if it only converts half of the codebase, that’s still a huge improvement.
The problem is it’ll convert 100% of the code base but (you hope) 50% of it will actually be correct. Which 50%? That’s left as an exercise to the reader. There’s no human, no plan, no logic necessarily to how it was converted also so it can be very difficult to understand code like that and you can’t ask the person who wrote why stuff is a certain way.
Understanding large, complex codebases one didn’t write is a difficult task even under pretty ideal conditions.
Yeah, I read the article.
They’re MASSIVELY handwaving a lot of detail away. Moreover, they’re taking the “we’ll fix it in post” approach by suggesting “we can just run an armful of security analysis software on the code after the system spits something out”. While that’s a great sentiment, you (and everyone considering this approach) needs to consider that complex systems are pretty much NEVER perfect. There WILL be misses. Add this to the fact that a ton of organizations that still use COBOL are banks - which are generally considered fairly critical to the day-to-day operation of our society, and you can see why I am incredibly skeptical of this whole line of thinking.
I’m sure the IBM engineers who made the thing are extremely good at what they do, but at the same time, I have a lot less faith in the organizations that will actually employ the system. In fact, I wouldn’t be terribly shocked to find that banks would assign an inappropriately junior engineer to the task - perhaps even an intern - because “it’s as simple as invoking a processing pipeline”. This puts a truly hilarious amount of trust into what’s effectively a black box.
Additionally, for a good engineer, learning any given programming language isn’t actually that hard. And if these transition efforts are done in what I would consider to be the right way, you’d also have a team of engineers who know both the input and output languages such that they can go over (at the very, very least) critical and logically complex areas of the code to ensure accuracy. But since this is all about saving money, I’d bet that step simply won’t be done.
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.
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.
I’m more alarmed at the conversation in this thread about migrating these cobol apps to java. Maybe I am the one who is out of touch, but what the actual fuck? Is it just because of the large java hiring pool? If you are effectively starting from scratch why in the ever loving fuck would you pick java?
That’s alot of effort to go from one horrible programming language to another horrible programming language.
What would your language of choice have been? And why is java horrible for this scenario? it sounds like a reasonably good choice to me
JavaScript is actually really nice as a beginner programming language because of how quickly and visually you can see your results, and how easily you can debug with console output. Yeah it’s horribly unoptimized but it’s not for big things. It’s for little things. It’s baby’s first programming language.
I’m thinking Go or Rust would be the logical next step. They probably won’t want an interpreted language so Python is out.
Just curious, what about go or rust makes them the logical next choice and not java? What do go or rust do better that java doesn’t?
Something I found is that LLM struggle with weirder cases, when it comes to code.
I once tried getting ChatGPT (though admittedly only 3.5) to generate code in understand SaHuTOrEPoL, which is one of the more esoteric languages I created, and it really struggled with it.
Why would you expect ChatGPT to know how to write code in a language that you created yourself? According to that repository you created it last year, and ChatGPT was only trained on data up to 2021 so there’s no way it could have been in its training set. Even though AIs have surprised us with their insights in a lot of cases they aren’t magical.
Admittedly, I worded my comment poorly. What I meant is that ChatGPT struggled with understanding the semantics and structure of the language.
As an example, try from this this code block
$S__ do
S__-m__w("Hello world!") do
You can, hopefully guess that S__ is a variable which has a method m__w, accessed by using a hyphen, rather than a dot and statements end using a do keyword. ChatGPT missed on all marks.
Have you tried including the docs in the prompt as well? I wouldn’t have guessed that S__ is a variable in your example, but I would’ve known that after reading the docs. I’d expect ChatGPT to at least do OK if it had access to the docs.
I don’t think the LLM is gonna do that great of a job with it for this reason, but still worth giving a shot. ChatGPT is a well trained coding chimp. You realistically could get a well trained chimp to start off a lot of projects and have people finish it. The fact that it can correct itself after you explain how it’s wrong is very powerful as well.
LLM isn’t gonna be useful for converting a single program from COBOL to Java, it is gonna be useful for converting many programs from COBOL to Java. I bet IBM is trying this on their own shit first before they try to sell it to customers, because language conversion software would be a HUGE but very boom based money.
As I stated on a different comment in this thread, I worded my comment poorly. Why I think this is relevant however that, at least in this case, if an LLM get code which is significantly different from what its trained with, it can make wildly incorrect guesses. While here its because of a language with a… unique syntax, I think this could also be the case for code with a lot of technical debt or weird design decisions.
Yeah, I don’t think this will be as good as we want. The amount of technical debt I’d expect in these big programs would be off the charts. It would take a full team of people just to feed in corrections, and they would need to both know COBOL and be willing to kill all the COBOL jobs to do it. It’s a tough ask
I’m still optimistic though because it’s IBM and converting between languages is a billion dollar question. I don’t think IBM would do a truly irresponsible deployment of such big corporate changes. I’d expect IBM to do a LOT of testing before sending anything out that would actually change the world, such as banking software. But in could be wrong.
Probably because it wasn’t trained on it. That’s not any different from asking the same of a human.
Of all modern languages, why java? Which will likely soon become legacy for backend applications
Sadly, I’ve haven’t been programming for a while, but I did program Java. Why do you consider it legacy and do you see a specific language replacing it?
I was pretty impressed by what I saw from Kotlin. Pragmatic and terse, not as academic as Java. Reminds me of the shift away from EJB to Spring. Have been reading up on Rust and thought that with the LVM and WebAssembly (also for the backend), it is perfectly positioned as an alternative. What do you think?