Live data from Hacker News

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

wumpus-cave.net

301–310 of 448 posts

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

#301

Earlier quoted context omitted.

4GL were supposed to be even more of that, with more "human-language-like" constructs added to the language to deal with things besides general logic, simple data structures and arithmetic. The author mentions "4GLs" were all the rage in the early 1990s, but I doubt that that was true outside of the mainframe world. The 4GL movement, as a conscious movement, seems to have always been highly mainframe oriented (the Wi…

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…

Gosh it's a long time since I heard 'Clipper' mentioned. I used to do 'PC' apps for Banks in the early 90s. Turbo Pascal and Clipper were popular with us. (We used PL/1 rather than COBOL for batch processing)

Then VB 4.0 started to get popular around 1996 and ruled the roost...

So many technologies... does anyone remember 'SUPRA' from that era! (think it was supposed to be a 4GL language/interface for mainframe databases)

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

#302
post #244

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…

> The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. I intuit this also is an intrinsic limit to LLM based approaches to "you don't need them expensive programmers no more" with LLMs magically "generating the solution" you move the responsibility for concise expression of the problem up the ladder. and then you "program" in prompts, rev…

There is a disconnect somewhere. When I read online, I hear about how GenAI/LLMs replace programmers and office workers. When I go to work, I mostly hear the question of how we can apply GenAI/LLMs, apart from discussion of the general buzz.

Maybe this is a reflection of local conditions, I'm not sure, but it doesn't seem like the truly revolutionary changes require the solution to find a problem. It was immediately clear what you could do with assembly line automation, or the motor car, or the printing press.

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

#303

Earlier quoted context omitted.

I assume it became less popular when Java became more bearable.

And kotlin came around with great IDE support, and with good features without the complexity of scals

It's hard to understate how much better the Kotlin IDE support is vs Scala. In terms of reliability the Scala IntelliJ plugin really seemed to go downhill for me with Scala 3, which was a real shame.

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

#304

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…

This is often the exact reason I give to people when they don't understand why Amy and I don't think "everyone should be a 'coder!'" should be pushed in schools, heh.

When you're graduating students from high school who go into college as engineering hopefuls who can't solve X - 2 = 0 for X, what hopes does the average individual have for solving programming problems?

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

#305

Earlier quoted context omitted.

Worse. It’s a DSL without a formal specification. You are writing prompts blindly in hopes they trigger the desired behaviour from the LLM. A bit like writing enchantments to force demons to do your bidding.

>A bit like writing enchantments to force demons to do your bidding. But without the cool chanting and poetic language; just like cyberpunk was realized without the vivid imagery and neon lights :(

> just like cyberpunk was realized without the vivid imagery and neon lights :(

The 21st century never ceases to disappoint. It’s a cheap, low budget and dystopian version of what we imagined.

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

#307
post #244

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…

> The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. I intuit this also is an intrinsic limit to LLM based approaches to "you don't need them expensive programmers no more" with LLMs magically "generating the solution" you move the responsibility for concise expression of the problem up the ladder. and then you "program" in prompts, rev…

In fact we've been using programming LLMs for a long time, which we call compilers.

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

#308
COBOL is not dead, but it's difficult to get access to, because there is almost no open-source tooling around it for Linux. We (OCamlPro) have created a project, called SuperBOL, to create an open-source environment around the GnuCOBOL open-source compiler (that is now very mature and used by companies). We have already released the VScode extension with an LSP for COBOL to get a modern IDE, and we are working on other tools, mostly depending on our customers.

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

#309

COBOL is not dead, but it's difficult to get access to, because there is almost no open-source tooling around it for Linux. We (OCamlPro) have created a project, called SuperBOL, to create an open-source environment around the GnuCOBOL open-source compiler (that is now very mature and used by companies). We have already released the VScode extension with an LSP for COBOL to get a modern IDE, and we are working on oth…

The problem is not so much access to tooling, but access to mainframes. I can learn COBOL in a day or two, and I would love to work on a "boring" COBOL job, but I have no experience with mainframes.

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

#310
post #272

Earlier quoted context omitted.

This is only true to an extend. We have a lot of digitally inclined workers who’re developing programs or scripts to handle a lot of things for them. It’s imperfect and often wildly insecure and inefficient, but unlike any previous no-code or “standard” solution it actually works. Often in conjunction with “standard” solutions. On one hand you’re correct in that there will always be a need for programmers. I really d…

Another parallel is type foundries and printing presses. At one point people operated these linotype machines which used molten lead. Of course this transitioned to photo typesetting which, to the dismay of everyone had poor results. Along came Donald Knuth and TeX to fix those deficiencies. NOTE: mechanical printing has a profoundly better result no matter what. It is the ink and the impression in paper that makes i…

TeX was predated by a family of macro-based document languages that began with RUNOFF and continued through roff, nroff, troff, ditroff, and groff. Plus tbl, eqn, and mm*. Some manual pages still use that stuff. Most Linux systems still install it by default. TeX has roughly the same concept, a macro-based layout language, but a better design with far less cruft.
Post reply on HN