Why switch to languages that have a long track record of software security issues and nasty bugs?
Productivity, integration, cost, staff availability, better tooling, better user interface.
The two first are nice buzzwords, but the effective benefits using more "modern" languages don't always hold in real projects.
They're really not buzzwords.
Productivity is the ratio of time spent to problems solved. You want to have a library of tools which is adaptable to all problem domains without having to reinvent any wheels if possible. Integration is the ability to interact with disparate other systems. No system is an island now.
I'd like you to show me how much work is involved in a realistic case of financial portfolio valuation without modern languages. The task is basically:
1. Map a list of product providers to portfolio items (around 60,000,000 daily) and retrieve them from a mix of SQL boxes and document stores.
2. Fracture this out into distinct queues per provider.
3. Fire this at about 40 different distinct integrations (ranging from shitty bits of SFTP, SOAP, XML, HTTP, JSON, custom protocols all using different auth methods ranging from OAuth to broken ass custom X509 certificate CAs) using batching.
4. Reliably poll, or be sent responses.
5. Match the responses to portfolios (this actually is a very complex matching engine which is nearly 2 MLOC on its own to give you an idea of the scale).
6. Update database and document stores
7. Dynamically generate 60,000,000 portfolio reports in multiple document formats
8. Print them and stuff them in envelopes and order deliveries across 25 countries...
I'd love to see how someone even approaches that with anything that is older than a few years. We're just onboarding protobufs channels. Do you have an implementation of protobufs for COBOL?
What do you mean by "better user interface"?
Someone who knows windows or a web interface can sit down and use it without having to use some shitty terminal emulator or turd written in some vile GUI toolkit dragged along (mostly whining about HP / ME10 / CoCreate shite there but it exists elsewhere).
Regarding staff - and cost, which is tightly related for software development - things are not necessarily as obvious as it may seem. Of course you can find way more developers for Java, Python or the like. Numbers don't make quality or success though. A couple of very experienced developers (which you are more likely to find among COBOL developers) can be a lot more productive than 10 Java kiddies. So this shortage may actually be a plus rather than a minus.
LOL that's just complete bollocks. Sorry
In COBOL you pay someone to write the libraries then they write the application.
In Java you pay someone to write the application using the libraries off the shelf. You also get a test suite for your money. You get documentation. You get continuous integration and delivery. And importantly you get to choose the target architecture not be constrained by it.
There certainly are very few people able to develop in COBOL these days, but as long as there are enough to get the job done, I don't see the problem. Sure they are highly paid given the shortage (which motivates them even more to do quality work), but does that make projects more expensive in the end? I'm not convinced, and experience in other fields has often taught me otherwise. And given the current situation (you may wish it were different, it won't change reality), I think anyone serious about working as a software developer in the banking/financial domain should still learn COBOL. It's fine not to be interested in these domains whatsoever though.
There's no problem at all. The key problem is the celebration of this as a way of life. The world moved on and the only reason anyone is fanfaring this shit is to hide the legacy problems the business has.
Absolutely no one should be learning COBOL in 2020 entering the banking and financial sector.
Then of course comes the main point: maintaining and evolving legacy systems. Rewriting software from scratch has a long track record of spectacularly failed projects, in all kinds of domains.
That's a fair point. Only idiots rewrite systems from scratch and do a grand switch over. Migration to new tech should be a carefully controlled and phased "evolution". The platform I'm working on now is slowly eating away at legacy and moving over to a much more distributed model behind the existing interfaces. Eventually they will be replaced as well. But at no point is anyone pulling the plug and rewriting from scratch.
Lastly, as I said, COBOL seems to have evolved quite a bit, and I believe it even has object-oriented features these days.
It's really quite fugly though. Also most of our stuff isn't actually OO even though it's written in OO languages.
You can write bugs in COBOL too.
Of course. My point here was, using domain-specific languages, there's a whole range of bugs/security issues that you can avoid compared to using very general-purpose ones.
Yes we build domain specific languages to express complex problems as well. The matching engine above uses a DSL to define rule chains and a formal verification framework to validate them and the system behaviour afterwards (as it compiles them into parallel streaming implementation).
Shit's complicated!
FORTRAN was also another interesting example.
Of course you can write numerical analysis software in C, C++, Java, Pascal, Ada, whatever. (And I have - I'm not specifically advocating FORTRAN, I have never used it outside of uni.) But there's a good chance it'll take the average specialist more time, introduce more bugs, and will make them have to look for third-party libraries that may be costly or utterly buggy, or take months writing their own. So that's really about domain-specific languages and tools.
Most of our stuff is in C#. Including the numerical analysis stuff. Most of the modeling starts in Mathematica or Excel though or is which is how it goes these days.