No it is not, plus vscode is something entirely different. Really i am specifically talking about the Visual Studio debugger compared to FOSS debuggers.
No it is not, plus vscode is something entirely different. Really i am specifically talking about the Visual Studio debugger compared to FOSS debuggers.
Honestly? Visual Studio. Like I am an Emacs user through and through. When properly setup with LSP, ccls, etc. it offers a better editing experience, and when it works its similar to, if not better than VS–even on huge codebases. But I would rather go live in a dumpster than have to use GDB over the VS debugger again. Its so slow, its a nightmare to use with multithreaded code, it just isnt capable of handling a large, GUI driven application.
Maybe there is some GDB config guidebook that I’m missing, but it better be something more than ‘lmao just write a python script to pretty-print std::vector’.
Oh FFS there is nothing magical about COBOL like its some kind of sword in the stone which only a chosen few can draw. COBOL is simple(-ish), COBOL is verbose. That’s why there is so much of it.
The reason you don’t see new developers flocking to these mythical high-paying COBOL jobs is its not about the language, but rather about maintaining these gianourmous, mission-critical applications that are basically black boxes due to the loss of institutional knowledge. Very high risk with almost no tangible, immediate reward–so don’t touch it. Not something you can just throw a new developer at and hope for the best, the only person who knew this stuff was some guy named “John”, and he retired 15 years ago! Etc, etc.
Also this is IBM were talking about, so purely buzzword-driven development. IBM isn’t exactly known for pushing the envelope recently. Plus transpilers have existed as a concept since… Forever basically? Doubt anything more will come from this other than upselling existing IBM contracts who are already replacing COBOL.