[heisgone]

Indeed. Financial companies are in a difficult position. COBOL was invented for them 60 years ago. Then, they were the primary users of computers. Now, they are just one users among many and no language is going to be invented for them specifically. Instead, you have thousand of enterprise software companies that are trying to market them all sort of complex solutions and keep the gravy trains coming. Financial companies would need to take the matter in their own hands and invent their own modern language but their culture doesn't allow it. Financial companies have extremely long term needs but are unable to put together the kind of long term project that would allow a cohesive language to emerge. Instead, they buy into ridiculous short term thinking like Agile. If maintaining COBOL code from 30 years ago is costly, imagine what today's business software 30 years from now. I have seen critical information only a few years old being lost among insurance companies. Consequential bugs that lead to people losing money. It's scary to think that those systems are guardian of our finances.

[petejodo]

I'm curious what features this hypothetical modern language would have that would be particular suited for financial institutions. This thought has piqued my interest

[heisgone]

The language need a fairly limited set of functions to support actuary calculations. You don't want things to get out of hand, with side effects, complex libraries, and so forth. Things need to be robust. Language like PL/SQL and SAS were fine but the systems are a pain to deal with and require technical knowledge that actuaries don't always have. Python is no emerging in the field by default because it allow quick prototyping but I would have concerns of the long term stability and maintainability of anything built out of it.

[8eye]

maybe put a framework on top of COBOL call COBOL-x, there use that as your starting point.

kind of joking/not joking, marketing has gotta play a huge role in that transition.