Live data from Hacker News

COBOL – Still standing the test of time

blog.microfocus.com

61–70 of 104 posts

Re: COBOL – Still standing the test of time

#61
post #45

> Cobol remains the language of choice Sigh , those single liner that both illustrate the ignorance and the status of the author. I’m an enterprise architect in banking , 6 month ago I was hired for IT Transformation. My mission was very simple « move the bank the out of mainframe » In 2 weeks or so I presented a Kafka based runtime based with JVM contracts that would enable the bank to perform in a near real-time ma…

devs refused to go into that because much like the authors they are 30 years in the banks and don’t want to learn something else

The way to fix that is to use the method IBM used to introduce the IBM-PC back in 1981. They set up a completely independent project group that had no connection with the main-frame boys, and so weren't 'brainwashed' into the IBM 'way of life'. The rest is history.

Incidentally, while I no longer program in COBOL, I still like it. It was always easy to do maintenance on a program that I might not have looked at for decades because of its wordiness. I normally program in C these days, but it's not as 'maintenance-friendly' as COBOL unless there are lots of comments.

Re: COBOL – Still standing the test of time

#62
post #45

> Cobol remains the language of choice Sigh , those single liner that both illustrate the ignorance and the status of the author. I’m an enterprise architect in banking , 6 month ago I was hired for IT Transformation. My mission was very simple « move the bank the out of mainframe » In 2 weeks or so I presented a Kafka based runtime based with JVM contracts that would enable the bank to perform in a near real-time ma…

(humor)

> COBOL- still standing the test of time

.. like the plague.

https://en.wikipedia.org/wiki/Bubonic_plague#History

Re: COBOL – Still standing the test of time

#63
post #12

Has anyone ever actually met a COBOL programmer? It seems like the teachers tale of someone cracking their head open while swinging on their chair - presumably they exist but there can't be that many of them?

Not in many years, but I did COBOL professionally for a few years.

Re: COBOL – Still standing the test of time

#64
post #12

Has anyone ever actually met a COBOL programmer? It seems like the teachers tale of someone cracking their head open while swinging on their chair - presumably they exist but there can't be that many of them?

Yes.

Almost all of them were older than 50 though.

Probably most governments still have them. Social security and health payments from governments probably go through Cobol code.

Re: COBOL – Still standing the test of time

#65

I've always thought that the reason COBOL is still "popular" is that it became an entrenched technology many years ago, and the cost of replacement is high enough (and it works fine doing what it's doing) that no one wants to invest the time and money to replace it's usage. This quote made me pause though, "COBOL remains the preferred choice for systems where application quality and operating cost remain important co…

The sentiment ITT seems to be overly dismissive of the value of a system that can reliably run for decades. How many of the new Kafka systems being stood up today would you realistically expect to still be running in 2061? How reliably do you expect those systems to perform over that 40 year period?

The trade offs are quite apparent, but the value these systems provide is perfectly obvious too.

I’m not sure I buy the extensibility argument either. In my experience the COBOL typically runs on the core processing system, the bit of the bank that runs the central ledger. This is usually a small portion of the banks technology footprint, and the rest of their integrating systems can run anything they like. I’ve worked in quite a few banks, and in my experience .NET is a lot more ubiquitous than COBOL is.

Re: COBOL – Still standing the test of time

#66
post #12

Has anyone ever actually met a COBOL programmer? It seems like the teachers tale of someone cracking their head open while swinging on their chair - presumably they exist but there can't be that many of them?

Not really - I used to work with a guy that had touched some COBOL at a previous job (not a bank) but that was it. I haven't worked a bank so I guess that's why I haven't crossed paths with one.

Re: COBOL – Still standing the test of time

#67
I like the commenter on that page disagree with the stats but I would assert that COBOL is still the best business DSL ever written. the whole language is about doing typical business things. Mostevery other language I have used, looked at, is at the primitives level upon which one has to build the functions to make it equivalent to COBOL for writing a simple accounting program. Add to this it's IO is basically just the 2 fundamentals of record based read write and queues(yes COBOL had queues in 70s). if you have written large business systems with multiple data storage backend, and its distributed, and it needs to manage it's own load balancing, then COBOL was brilliant. Still is.

world (and a lot of HN readers) needs to change mindset away from this lang versus that lang towards a this DSL and its problem space versus others DSL and its problem space. For me if I had to write a payroll engine I would prefer use COBOL than javascript but would likely turn to java just because of easier to get reference material.

I learned fortran, Pascal, cobol. then worked in COBOL and assembler. then RPG and awk. nowadays mostly python, javascript, some c for projects.

FWIW I aspire to learn and use Ada.

Re: COBOL – Still standing the test of time

#68
post #12

Has anyone ever actually met a COBOL programmer? It seems like the teachers tale of someone cracking their head open while swinging on their chair - presumably they exist but there can't be that many of them?

I've worked with at least 10 of them maintaining systems for a big insurance company

Re: COBOL – Still standing the test of time

#69
post #44

Earlier quoted context omitted.

I wonder why those big companies don't hire someone new and train them. I'm sure not everyone is interested in new techs. I for one is very interested in these "boring" techs but it's pretty difficult to train myself on these stuffs.

They are. The largest bank here in Sweden for example offers a 6 month free COBOL Academy to newly graduated students, that ends in basically a guaranteed job. I guess there just aren't enough takers.

That would be difficult to pull off in the US because full-time COBOL gigs just don't pay as much as modern software engineering jobs do.

A lot of these big companies with legacy COBOL systems got way too comfy with offshore contractors and now big contracting firms aren't guaranteeing theirlabor pools like they used to because they can make a lot more money placing contractors in Java/Python/AWS/etc roles instead of COBOL.

Training programs like this would have to pay incredibly well to keep people (which is not a bad thing for the workforce generally), but it's clear that some of these companies are used to paying far lower salaries and now they're running out of options while maintaining critical IT infrastructure in some cases.

Re: COBOL – Still standing the test of time

#70
post #45

> Cobol remains the language of choice Sigh , those single liner that both illustrate the ignorance and the status of the author. I’m an enterprise architect in banking , 6 month ago I was hired for IT Transformation. My mission was very simple « move the bank the out of mainframe » In 2 weeks or so I presented a Kafka based runtime based with JVM contracts that would enable the bank to perform in a near real-time ma…

The thing is, you solved a very narrow problem to which there is already a solution (and has been) on the mainframe for 30+ years (MQ). The real problem is that in that COBOL code is 50 years of business rules smeared across millions of lines of code, adjusted for all the changes in law (sometimes applied retroactively) which impact how money is handled. It isn't that mainframes don't have message queues or can't interoperate with web services (they can), even if not all customers take advantage of those features. The problem is replacing that code requires extracting all that knowledge out of the code. Then, on top of that, if there's any downtime, it can be existential risk for the bank.
Post reply on HN