Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

COBOL has been “dead” for so long, my grandpa wrote about it

wumpus-cave.net

Post reply on HN
Print view View original

151–160 of 448 posts

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#151

Post by mcv »

norir wrote: post #38

I think of scala in this context. I think that scala is basically dead at this point in the way that COBOL was framed in the article. Yes, there are still many businesses/services that have critical components written in scala but current mindshare has cratered for new projects. I only single out scala because I have spent a lot of time with it and have seen it go through the hype cycle (in 2012-14 it seemed like I w…

Scala can never be dead like COBOL because it has never been alive like Google. I love it too, but Scala has always been fringe. COBOL was everywhere.

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#152

Post by guessmyname »

norir wrote: post #38

I think of scala in this context. I think that scala is basically dead at this point in the way that COBOL was framed in the article. Yes, there are still many businesses/services that have critical components written in scala but current mindshare has cratered for new projects. I only single out scala because I have spent a lot of time with it and have seen it go through the hype cycle (in 2012-14 it seemed like I w…

I know a couple of engineering teams at Apple that are working on new projects in Scala, while also maintaining some legacy systems. Some of these projects are quite critical to the company’s ecosystem, e.g. test systems. I’ve spoken with several engineers who helped create these systems years ago; they’re all now in senior management positions. Some still stand by the technology choices made back then, while others are more open when given a chance to reflect. The general consensus is that if Kotlin had been available at the time, or if Swift had been a viable option for back-end services, they definitely wouldn’t have chosen Scala for those projects.

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#153

Post by bear8642 »

tombert wrote: post #30

You know, one of these days I really need to sit down and play with some of these "legacy" languages, like Fortran or COBOL or Ada or APL; languages that have certainly fallen out of popularity but are still used in some critical places. It does make me wonder about millions and millions of lines of Java out there; Java has more or less eaten the enterprise space (for better or worse), but is there any reason to thin…

Tryapl.org exists if want to play with APL - John Scholes' Game of Life and other excellent videos (https://www.youtube.com/watch?v=a9xAKttWgP4) might spark your interest

Other newer array languages exist too - https://aplwiki.com/wiki/Running_APL if want to explore the current space.

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#154

Post by facorreia »

I worked for a company in the late 1980s that started developing with a 4GL product (Dataflex) instead of COBOL. The article is right that COBOL has outlasted most (all?) of those 4GL solutions.

Looking back, COBOL would have been a better technical choice back then. Dataflex's metadata-based dynamic UI and report generation saved some simple, repetitive work, but much more effort was wasted working around its limitations.

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#155

Post by AdieuToLogic »

_yb2s wrote: post #69
flatpepsi17 wrote: post #62

Article starts mentioning 4GL's - a term I have not heard in a long, long time. COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code. The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. When you get down to breaking down that problem... you b…

> we wouldn't need programmers anymore This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages. But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper, and have it work - something few people can or need to do nowadays

> This blows my mind, since it seems like a fairly low level/terse language compared to more modern domain specific languages.

I have heard others and myself describe COBOL in many ways, most involving creative expletive phraseology which would make a sailor blush, but "low level/terse language" is a new one to me.

> But in some sense they were dead right... since (I assume) that what "programming" meant at the time was being able to write raw machine code by hand on paper ...

LISP and Fortran predate COBOL IIRC.

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#156

Post by gerdesj »

Muromec wrote: post #135
crackez wrote: post #125

Earlier quoted context omitted.

Negativo friendo. The mainframe is turning into a middleware layer running on Enterprise Linux. We've containerized the mainframe at this point, and I mean that directly - eg. Running jcl, multiple CICS regions, all in COBOL that originated on z/OS is now running in k8s on amd64.

There is a major drawback to this approach -- you need to have somebody who knows what they are doing. Total deal breaker in most of the places that have this problem in the first place.

"you need to have somebody who knows what they are doing"

That applies everywhere.

Your parent comment has managed to stuff a mainframe in a container and suddenly, hardware is no longer an issue. COBOL is well documented too so all good and so too will be the OS they are emulating. I used to look after a System 36 and I remember a creaking book shelf.

The code base may have some issues but it will be well battle tested due to age. Its COBOL so it is legible and understandable, even by the cool kids.

If you lack the skills to engage with something then, yes, there will be snags. If you are prepared to read specs, manuals and have some reasonable programing aptitude and so on then you will be golden. No need for geniuses, just conscientious hard workers.

It's not rocket science.

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#157

Post by AdieuToLogic »

flatpepsi17 wrote: post #62

Article starts mentioning 4GL's - a term I have not heard in a long, long time. COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code. The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. When you get down to breaking down that problem... you b…

> COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code.

The more things change, the more they are the same.

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#158

Post by palisade »

erik_seaberg wrote: post #147
palisade wrote: post #70

Note: I'm getting some hate from others who think I would pick or prefer COBOL over a modern language. I wouldn't. I was making an outside-the-box "devil's advocate" objective observation. I just wanted to preface that here. Okay, the rest of my original comment remains below: The irony is that we already had a memory safe and stable language in Cobol that was easier to read and understand than Rust. But, no one want…

Sorry, https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex... seems to be demonstrating a language that is not memory-safe (maybe it used to be, but how?) COMPUTE SIZE-NEEDED = LENGTH OF OBJ + LENGTH OF VARTAB * NUM-ELEMENTS ALLOCATE SIZE-NEEDED CHARACTERS INITIALIZED RETURNING VPTR SET ADDRESS OF VARGRP TO VPTR MOVE NUM-ELEMENTS TO OBJ MOVE BUFFER(1:SIZE-NEEDED) TO VARGRP SET VPTR TO ADDRESS OF BUFFER FREE…

The compiler would have rejected that, if I remember correctly. I'm not in the field of cobol myself, I learned it briefly in college ages ago.

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#159

Post by snovymgodym »

DaiPlusPlus wrote: post #99
snovymgodym wrote: post #40

As always, these discussions will depend on your definition of "dead" and "alive". If we can call a technology dead once no new business is built on it, then I think we can safely call COBOL dead (and the IBM 390x aka Z/OS platform along with it, for which "COBOL" is usually a proxy). But if we say that anything still being used in production is not dead, then of course COBOL is alive and significantly more alive tha…

> we can call a technology dead once no new business is built on it You don’t suppose any bank - or other large financial institution - might have standardised on Cobol for their core business flows/processes? In which case a new business-unit or “internal startup” team (e.g. a new category of insurance product) might very-well have some part written in Cobol so it integrates with the rest of the bank - or at very-le…

Sure, I know for a fact that what you're describing exists. That's not really what I mean by new business being built on it. That's a case of a very large and old business already being so locked into the mainframe ecosystem for their core systems that anything new they try to do ends up needing some kind of integration system with the legacy system.

What I mean is that nobody starts a business today and says "Ok, we need an IBM mainframe running DB2 and we'll have a bunch of COBOL, ReXX, and PL/I programs for handling our business logic".

Re: COBOL has been “dead” for so long, my grandpa wrote about it

#160

Post by strken »

Suppafly wrote: post #43
tombert wrote: post #30

You know, one of these days I really need to sit down and play with some of these "legacy" languages, like Fortran or COBOL or Ada or APL; languages that have certainly fallen out of popularity but are still used in some critical places. It does make me wonder about millions and millions of lines of Java out there; Java has more or less eaten the enterprise space (for better or worse), but is there any reason to thin…

>but is there any reason to think that in 30-40 years the only people writing Java will be retirees maintaining old banking systems? It feels like we're getting into that space already.

I think Android makes a difference here. Sure, a lot of people are on Kotlin, but a lot aren't.
Post reply on HN