Serious question: COBOL's just a language. How come no one has put together some kind of runtime interpreter, for COBOL, or thought to produce an emulator facade that keeps the business logic of legacy code, but ports it to another platform, architecture, infrastructure? I look at some of the perfectly cromulent stuff people do with Emscripten [0], and it just blows my mind the things that a browser will run these da…
Defusing COBOL Bombs with Smart Automation
11–20 of 20 posts
Re: Defusing COBOL Bombs with Smart Automation
#12Rewriting COBOL software in Java also looks like repeating the same mistake. Java as a language is already becoming obsolete for many things, including JVM itself, so languages like Kotlin, Scala taking off. On the other part, the same languages also work very hard on being native [1] [2]. So for the long-term strategy, it makes more sense to use the platforms that already made this leap - OCaml, F#, Haskell. Those l…
Java isn't going anywhere anytime soon. It's a safe choice for projects that are expected to have lifespans in the decades.
Re: Defusing COBOL Bombs with Smart Automation
#13Serious question: COBOL's just a language. How come no one has put together some kind of runtime interpreter, for COBOL, or thought to produce an emulator facade that keeps the business logic of legacy code, but ports it to another platform, architecture, infrastructure? I look at some of the perfectly cromulent stuff people do with Emscripten [0], and it just blows my mind the things that a browser will run these da…
There was a link to another article [1] about how COBOL may be better suited to certain mathematical calculations. The article in question presented this iterative function:
x[0] = 4
x[1] = 4.25
x[i] = 108 - ((815 - 1500 / x[i-1] ) / x[i-2])
[1] https://medium.com/@bellmar/is-cobol-holding-you-hostage-wit...
Re: Defusing COBOL Bombs with Smart Automation
#14Serious question: COBOL's just a language. How come no one has put together some kind of runtime interpreter, for COBOL, or thought to produce an emulator facade that keeps the business logic of legacy code, but ports it to another platform, architecture, infrastructure? I look at some of the perfectly cromulent stuff people do with Emscripten [0], and it just blows my mind the things that a browser will run these da…
> for COBOL, or thought to produce an emulator facade that keeps the business logic of legacy code, but ports it to another platform, architecture, infrastructure
There are some, but the answer is: because COBOL is opinionated.
In terms of verbosity it makes Java look like a Haiku, and it's a weird mix of lower level and higher level constructs.
Classes? What are those? Code reuse?
It also talks (in weird ways) to things like green screen interfaces and saves data in "records" or builds "reports" (just try to create XML natively in Cobol)
Re: Defusing COBOL Bombs with Smart Automation
#15Serious question: COBOL's just a language. How come no one has put together some kind of runtime interpreter, for COBOL, or thought to produce an emulator facade that keeps the business logic of legacy code, but ports it to another platform, architecture, infrastructure? I look at some of the perfectly cromulent stuff people do with Emscripten [0], and it just blows my mind the things that a browser will run these da…
There was a link to another article [1] about how COBOL may be better suited to certain mathematical calculations. The article in question presented this iterative function: x[0] = 4 x[1] = 4.25 x[i] = 108 - ((815 - 1500 / x[i-1] ) / x[i-2]) It blew up on iteration 14 using floating point, but COBOL could be programmed to go further (by using more decimal places past the decimal point). [1] https://medium.com/@bellma…
> may be better suited to certain mathematical calculations
No, it isn't. If that's the best excuse they can find for keeping COBOL alive then throw it in the trash already (though I read the article and it's more subtle than that)
There are arbitrary precision libraries for multiple languages, both binary and decimal.
Re: Defusing COBOL Bombs with Smart Automation
#16Serious question: COBOL's just a language. How come no one has put together some kind of runtime interpreter, for COBOL, or thought to produce an emulator facade that keeps the business logic of legacy code, but ports it to another platform, architecture, infrastructure? I look at some of the perfectly cromulent stuff people do with Emscripten [0], and it just blows my mind the things that a browser will run these da…
COBOL work doesn't actually pay well compared to other languages, and it isn't that bigger market. Why? If your business logic and requirements haven't changed, why change a running system? Even if you could transpile with 100% accuracy, then you'd lose speed. Maybe you've gained an operational advantage, but there are other ways to do that. On the other extreme, you need to modernize badly, and so a rewrite is actually feasible because you can take advantage of new technologies, especially web and mobile. Between those use-cases, middleware exists which does allow you to bolt on even more awfulness. Finally, businesses die or get acquired. Sometimes good stuff is lost, but equally bad or old stuff is purged.
Maybe ironically, that Emscripten URL won't load for me.
Re: Defusing COBOL Bombs with Smart Automation
#17Most banks suck at doing software and are being outcompeted by startups that have made building good software their core business.
E.g. N26 in Germany is rapidly growing marketshare in Europe (and soon the US apparently) with products that are modern, user friendly, and 100% guaranteed cobol free. There are a few similar examples of bank startups that invest primarily in R&D and UX to grab market share from old banks that are simply not competitive. Their marketshare is melting away rapidly.
N26 bootstrapped with way less funding than most of these dinosaurs spend on keeping their old crap on life support. Per year.
I had a fun incident at Commerzbank here in Germany a few years ago where a request for some older statements that I needed for our compmany taxes was first impossible and then turned into a "we have to send get somebody into an archive to make a copy of the microfilm; this may take a few weeks". This was this century. This decade even. No joke. A major German bank is storing customer records on microfilm. Incompetent banks like this deserve to go bankrupt. They are sitting ducks for any kind of competition willing to simply show up. We took our business elsewhere after that incident. I will never do business again with that bank.
The real problem is that zombie banks like this have no in-house competence left to do anything productive when it comes to R&D. They are running on automatic pilot run by incompetent idiots. They outsourced all their core competence to consultants that happily come in and pile on more crap as long as they get payed enough. Mostly they evolve simply by copying what other banks do via expensive consultancy projects.
They tend to not have CTOs or anything resembling a technical strategy. Kind of odd if you realize that modern banking is essentially a software driven industry.
Re: Defusing COBOL Bombs with Smart Automation
#18Rewriting COBOL software in Java also looks like repeating the same mistake. Java as a language is already becoming obsolete for many things, including JVM itself, so languages like Kotlin, Scala taking off. On the other part, the same languages also work very hard on being native [1] [2]. So for the long-term strategy, it makes more sense to use the platforms that already made this leap - OCaml, F#, Haskell. Those l…
Java isn't going anywhere anytime soon. It's a safe choice for projects that are expected to have lifespans in the decades.
Absolutely. I've heard it referred as 21th century COBOL :) ... it'll have the same problems in 30 years :)
Re: Defusing COBOL Bombs with Smart Automation
#19Most banks suck at doing software and are being outcompeted by startups that have made building good software their core business. E.g. N26 in Germany is rapidly growing marketshare in Europe (and soon the US apparently) with products that are modern, user friendly, and 100% guaranteed cobol free. There are a few similar examples of bank startups that invest primarily in R&D and UX to grab market share from old banks…
I really hope banks get disrupted from the bottom (as you're mentioning with N26), and yes, I've worked for a Fortune 500 financial group that was a huge mess (they had entire buildings of software developers, but their software was god awful).
But your statement "they're simply not competitive" is extremely misleading. Most of the big banks don't have users as customers, maybe something to be tolerated. They're not competing on user experience.
Industry and Corporate is where it's at, and I guarantee they're getting very good support, personalized attention, etc... (even if the financials are cobbled together in Excel for a multimillion dollar loan). You're probably small fish for them.
Re: Defusing COBOL Bombs with Smart Automation
#20Serious question: COBOL's just a language. How come no one has put together some kind of runtime interpreter, for COBOL, or thought to produce an emulator facade that keeps the business logic of legacy code, but ports it to another platform, architecture, infrastructure? I look at some of the perfectly cromulent stuff people do with Emscripten [0], and it just blows my mind the things that a browser will run these da…
COBOL work doesn't actually pay well compared to other languages, and it isn't that bigger market. Why? If your business logic and requirements haven't changed, why change a running system? Even if you could transpile with 100% accuracy, then you'd lose speed. Maybe you've gained an operational advantage, but there are other ways to do that. On the other extreme, you need to modernize badly, and so a rewrite is actua…
Oh, lol! It just redirects to a github page, and I guess they don't listen on port 443.
So much for https everywhere.