Hacker News Reader

Comment by ThinkBeat | Hacker News Reader

Cobol is far from dead. It is not sexy and I dont know of any systems starting out today using it. But there are massive legacy systems till out there.

At least a couple years ago Cobol programmers were in high demand.

According to Microfocus [1 (2018)] over 2 million people worldwide are active full-time Cobol programmers, and it is running quite a few mission critical systems.

>Companies involved in keeping COBOL-based systems working say that 95 percent of >ATM transactions pass through COBOL programs, 80 percent of in-person >transactions rely on them, and over 40 percent of banks still use COBOL as the >foundation of their systems.

View on HN

Pascal similarly lives on with Deplhi/Lazarus. I know plenty of currently supported commercial programs running on Delphi and considering a transition to Lazarus.

I've seen an uptick in APL and APL-derived array languages. "Niche" would have been a better term. I would put Smalltalk in the same category.

What about some commercial languages instead which are de-facto dead, such as ColdFusion, ActionScript, Lingo, and so on...

> and I dont know of any systems starting out today using it

I do... In a project I was working on for a major Dutch government organization, they were building stuff in COBOL. This was a project where we were using NLP for automated data extraction. I still find it hilarious that part of it was being built in COBOL.

It's not dead, ok.

Can we say it's mostly dead?

For example, is it more or less dead than perl?

>> Can we say it's mostly dead?

>> For example, is it more or less dead than perl?

== The current state of Perl 5 for Python fans ==

Perl 5: I'm not dead!

TIOBE: 'Ere! 'E says 'e's not dead!

Internet: Yes he is.

Perl 5: I'm not!

TIOBE: 'E isn't?

Internet: Well... he will be soon--he's very ill...

Perl 5: I'm getting better!

Internet: No you're not, you'll be stone dead in a moment.

TIOBE: I can't take 'im off like that! It's against regulations!

Perl 5: I don't want to go off the chart....

Internet: Oh, don't be such a baby.

TIOBE: I can't take 'im off....

Perl 5: I feel fine!

Internet: Well, do us a favor...

TIOBE: I can't!

Internet: Can you hang around a couple of minutes? He won't be long...

TIOBE: No, gotta get to Reddit, they lost nine today.

Internet: Well, when's your next round?

TIOBE: Next year.

Perl 5: I think I'll go for a walk....

Internet: You're not fooling anyone, you know-- (to TIOBE) Look, isn't there something you can do...?

Perl 5: I feel happy! I feel happy!

https://youtu.be/Jdf5EXo6I68?t=50

Monthy Python is just pure genius :D

Less dead than perl by far. I've seen a lot of new COBOL going into production just this year. New versions of the compiler (the IBM one, the only one that really matters for COBOL) are still being released. A while back they went to the trouble of implementing full JSON serialization/deserialization. You would be surprised how many web services are pretty much just COBOL the minute the server needs to do anything with files or databases or whatnot.

As somebody that grew up on C and mostly doesn't work on the applications programming side of things, it was always tough to get my head around why so many people still wanted to write COBOL. Over the years though I've concluded that its simply a better language for certain kinds of tasks than anything created since. And there has been no shortage of support in keeping it relevant and easy to integrate with modern systems.

It would be interesting to see the COBOL record IO and destructuring of files and whatnot be implemented in a more modern language. I don't think anybody particularly cares for COBOL syntax, but the programming paradigm it supports doesn't have any other major players. Nobody has ever really even tried, probably because the types of people that usually create programming languages have no connections to the somewhat closed world of COBOL enthusiasts at large corporations. Certainly an interesting idea for a hobby project though, there are a lot of interesting places you could take a mixed COBOL/functional language type thing.

For instance, a function would take one file and output another, file structures and record structures could be interpreted as data types, archiving files would be treated as a side effect of the system essentially (or potentially if you get real crazy, make that some sort of functional abstraction as well). Just spitballing here because it's a fantastic idea that I would love to see. There is no reason that working with files has to necessarily be treated as entirely external to the program/a side effect, so long as you take care to have some sort of way to deal with acquiring locks/contention issues and whatnot. Not a problem on mainframes, but there would need to be some systems features implementing to make that sort of paradigm effective in a Unix style environment. I'm not sure it could be done entirely in a runtime, a lot of that state would really need to be global.

Microfocus COBOL also matters - there's non-trivial amount of code that is still being worked on, in COBOL, that runs these days mainly on RHEL machines and is compiled with Microfocus.

As for handling destructuring files, how useful it is really shows when you consider how easier many tasks become when you have access to such facility - even if nowadays you might expect it to be handled by extra compilation step that uses protocol buffers or something similar.

Modern programming languages are more than capable of providing an abstraction layer that can offer seamless file->struct and struct->file conversions.

It's basically the equivalent of ORM for relational database.

But nobody does it not because it's hard or because the language doesn't support it. They don't do it because we no longer think of file system the main "database" that stores your application state.

Instead we think of the filesystem as a lower level building block for higher level abstractions (such as relational or whatnot databases)

At least in south America, I saw in almost every financial institution, a lot of cobol being used until today.

Is someone who is no longer having children but is still a major team player at their employer “mostly dead”?

Since we're talking about languages, a better question would be "is a language in which no new works are written but which has a large catalog of past works that are still studied by thousands of people 'mostly dead'?"

Most would say yes.

The many COBOL programmers are not being paid to study a dead language, they are being paid to adapt, evolve, and maintain living systems written in that language.

> in which no new works are written

There's a lot of new code written in most of these languages. It might be existing systems, but the code being written is new.

Perl, in my opinion, will never be dead enough.

As I said above, I have opinions about each of the languages I have learned.

Reply on news.ycombinator.com