Live data from Hacker News

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

wumpus-cave.net

391–400 of 448 posts

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

#391

Earlier quoted context omitted.

> 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…

There was a decent amount of that going on in China in the 90s and early 2000s actually in the banking sector. You probably won't see much "new business" until you see companies in new large markets explode in size. As in you are unlikely to ever see "new business" in the US, because you'd need a new bank or something to somehow explode to the size of one of the big four and suddenly realize they need to get on board with what all the competition is doing in order to compete.

But it has happened at least a little within the past couple of decades, most notably with China but there have probably been other examples in Asia.

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

#392
post #10

Earlier quoted context omitted.

But are these legacy systems from the 70s, 80s, 90s using modern cobol?

Depends what you mean; but not necessarily. I am managing an ERP system implemented / went live in 2016. It's working on modern P10 hardware, which was released in 2021. The ERP system is continually updated by the vendor and customized by the client. Even for COBOL running on an actual mainframe, which I think most HNers would think of 1970s dinosaur, most of the actual machines in production would be pretty new. IB…

Yep, the system is old in the same way that we could call x86 "old". The architecture is backwards compatible with instructions going back to the mid 1960s...but that doesn't mean new instructions and updates to the ISA aren't being pushed out on a pretty regular cadence.

The new Telum II processor (and certainly this also implies another big ISA update and new hardware cycle) was announced at Hot Chips just a few weeks ago for example. See:

https://chipsandcheese.com/2024/09/08/telum-ii-at-hot-chips-...

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

#393

Earlier quoted context omitted.

I agree with you by and large except for this part. > COBOL's promise was ... we wouldn't need programmers anymore..average person doesn't know how to explain & solve a problem COBOL wasn't intended to be used by an "average" person but rather those with deep domain knowledge. They would know the business processes so well that they could transcribe it in COBOL with little or no need to learn how the computers worked…

> In some ways similar to analysts/data folks using SQL to communicate with databases. But SQL has the exact same problem. Except for very trivial scenarios, you can't just be an expert and plop your expertise into a SQL query. You have to learn how to use SQL to use SQL.

> You have to learn how to use SQL to use SQL.

As with any other tool one has to learn it to effectively use it. Some find the learning curve not worth it and stick with Excel which is OK. But the thing is even Excel has to be learned to make full use of its potential.

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

#394

Earlier quoted context omitted.

ActiveState still offers a supported Python 2.7 version across all major platforms for those who need it ( https://www.activestate.com/products/python/python-2-7/ ), so that's 14 years and counting. If enough stuff needs it, people will keep it running. Java 8 will probably be in the same boat eventually if/when Oracle finally drops support.

I am not even sure what support is needed at this point. The interpreter is what it is. You know there are no new libraries to integrate. I guess deploying it on a newer OS which might make it challenging to install unless it is a freshly compiled build?

Patches for security issues, most notably.

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

#395
post #134
post #5

"I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare COBOL is alive in that it keeps changing from era to era, to the point modern COBOL looks rather little like the 1950s COBOL everyone instinctively thinks about when they heard the term. It's as if we were still programming in Algol because Java had been called Algol-94 or something.

> "I don't know what the language of the year 2000 will look like, but I know it will be called Fortran." —Tony Hoare Kemeny and Kurtz described Fortran as "old-fashioned" in 1968! https://dtss.dartmouth.edu/sciencearticle/index.html >

Hence "I don't know what the language [...] will look like". Hoare seems to have made that remark around the same time work to redesign Fortran, what eventually became Fortran 90, began. Presumably he was aware of that effort and thought that Fortran would be able to keep reinventing itself as future needs dictated.

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

#396

Earlier quoted context omitted.

I don't think many people would describe Java as "fresh" these days. In demand, sure, but this is overwhelmingly driven by existing large enterprise codebases. Also, for all the talk about nifty new features, how much stuff is still on v11 even?

I understand from where your reply is coming from, but again, I was reading the same opinions about Java since more than 2 decades ago. > overwhelmingly driven by existing large enterprise codebases That happens with all mainstream languages, but it's a feedback cycle. The more popular a language is (in large enterprise codebases), the more it will get used in new projects, for obvious reasons. People want to get shi…

Two decades ago was 2004; that would be when Java first shipped generics. I remember those times and I don't think the sentiment was similar then. People certainly had many complaints about Java, and more specifically about some elements of the stack such as EJB, but as a whole I don't recall it being predominantly seen as "legacy" back then the way it is now.

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

#397
post #359

Earlier quoted context omitted.

> IMHO, the best way to do it is to be sitting with the expert, and observe exactly what they do. Or you give them a prototype of the program, and see what they complain about?

My experience is that invariably results in "development by veto". Each prototype they say that's not what I want, give me something else (that I'll fail to describe just like the last time) and I'll tell you that is wrong too after you've worked on it for a few weeks. Occasionally, you'll randomly get something they accept - but only for a few weeks until they come across some missing capability for some other thing…

[deleted]

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

#398

Earlier quoted context omitted.

dBase and its numerous descendants and competitors (FoxPro, Clipper etc) were extremely popular for line-of-business desktop applications in the 90s. And, yes, they are indeed traditionally categorized as 4GLs - and, given how nebulous the definition always has been anyway, I think that "traditionally categorized" is the most practical definition that you can use here. But, yes, I agree that aside from the generally…

That class of software also allowed for very efficient data capture against normalised tables. A recall as early as Paradox for DOS (something I haven't thought of for a while) in about 1990 being really simple tools for creating one-to-many database capture 'forms' (with selection boxes, date drop downs, the lot). The richness of form design and tight coupling to the database meant that the language did not need to…

Yep, and C# (or VB.NET) + WinForms sort of carried that torch well into the aughts. You can still see traces of that all over classic .NET - stuff like DataSet and stock widgets designed specifically for those kinds of CRUD apps such as BindingNavigator.

It's interesting that we have largely abandoned this approach to software development despite its amazing productivity in that niche. I guess a large part of it is because custom-made software is much less common in general than it used to be.

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

#399
post #194

Earlier quoted context omitted.

Maybe I'm in a minority, but I genuinely dislike conditions placed afterwards. They feel great to type out when you're in the flow, but coming back and reading them grates on my nerves. Seeing the condition first means I load a logical branch into my mental context. Seeing the condition after means I have to rewrite the context of what I just read to become part of a logical branch, and now the flow of reading is bro…

Try thinking of it as prefix if and infix if? And in any event it’s a very natural language pattern if you know what I mean.

Ostensibly, code is read more than it is written. I'd rather stick to forms that favor staying in a flow.

Natural language patterns are conversational, and / or use pacing to create emphasis and imply meaning.

With code, we aren't reading a natural language. Injecting natural language conventions amongst things like some_string.chars.each { |c| ... } Is entirely unnecessary and unhelpful in my not very humble opinion.

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

#400
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 think Perl today is probably closer to COBOL it was massive for a time, felt like it was everywhere. Nowadays it is increasingly niche. Like COBOL there is still a lot of perl code out in the wild.

When I used to work for ZipRecruiter in 22-23, much of their codebase was Perl. Pretty mind-boggling. There were even people working on it who would construct arguments why it was a perfectly reasonable language for ongoing software development. But some VP put his foot down and said "no more new projects in Perl!" and they started using Go for new projects.
Post reply on HN