Live data from Hacker News

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

wumpus-cave.net

131–140 of 448 posts

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

#131
post #44

Earlier quoted context omitted.

The nice thing about a vaguely English like language is that your average LLM is going to do a better job of making sense of it. Because it can leverage its learnings from the entire training set, not just the code-specific portion of it.

Not for generating it, because the more it looks like prose the more the LLM's output will be influenced by all the prose it's ingested.

I've used o365 copilot to analyze a COBOL app I had source code to, and it was great at explaining how the code worked. Made writing an interface to it a breeze with some sample code and I swear I am not a COBOL person, I'm just the Linux guy trying to help a buddy out...

It also does a reasonable job of generating working COBOL. I had to fix up just a few errors in the data definitions as the llm generated badly sized data members, but it was pretty smooth. Much smoother than my experiences with llm's and Python. What a crap shoot Python is with llm's...

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

#132
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 assume it became less popular when Java became more bearable.

Kotlin made Java bearable.

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

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

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

#135

Earlier quoted context omitted.

This is what people miss about COBOL. It's not like people are compiling COBOL and running it on Linux on an x86 box. They are running it on legacy operating systems (and hardware) which provide a different set of underlying services. It's a whole different planet.

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.

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

#136
post #57
post #49

Earlier quoted context omitted.

I program an Android app for a Fortune 100 company. Last commit where someone edited a Java file was last week. Most of the new code from the past few years has been in Kotlin though.

This. Nobody wants to have the COBOL problem again, so the developer hiring money follows the programming language popularity market (with a certain regulatory approved laf ofc)

“laf” or “lag”?

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

#137

Earlier quoted context omitted.

So you spotted that? I have no proof or links to share, but I've always thought SQL was inspired by, or at least made to not look out of place next to COBOL. I recall COBOL coding card layout interpreted a flag on punch cards at the char column where top-level picture clauses needed to start specifically for designating a line as SQL for static embedded SQL preprocessing.

I think it’s more that computers at the time didn’t all have lowercase characters. Consider that even C and C++ supported trigraph/digraph compatibility chars until something like last year (and IBM still complained…):

C is much older than Unicode, so it's not that surprising that some systems are still using https://en.wikipedia.org/wiki/ISO/IEC_646 and replacing some reserved punctuation (e.g., curly braces) with their country's accented letters.

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

#139
post #27
post #14

Earlier quoted context omitted.

Nobody writes MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN. any more.

> print food if tasty? Ruby is nice.

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 broken.

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

#140

As long as there are tactical nukes that depend on COBOL, COBOL ain't dead. We might all die, but COBOL will sit happy in its steel reinforce nuclear bunker

Still doesn't beat Assembly, which will continue running on Voyager 1 even after the inevitable demise of our planet. Would survive the end of our solar system too.
Post reply on HN