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

271–280 of 448 posts

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

#271

Post by int_19h »

jl6 wrote: post #73
Suppafly wrote: post #48

Earlier quoted context omitted.

seriously sometimes writing SQL feels more like composing a google query than programming.

A great thing about being a programmer is getting to complain about the crappy requirements you have to work with. SQL, on the other hand, is not a program - it’s a precise specification of the result you want, in a format that lets the database engine write the “program” for you. Thus, writing SQL helps you appreciate the struggle to achieve good requirements, and there is a chance you will develop empathy for those…

That can be said of any program written in a pure declarative language, but even so not all of them look like SQL. And, yes, they are still programs.

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

#272

Post by devjab »

froh wrote: post #244
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…

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

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 doubt there will be a great need for generalist programmers though. The one area that may survive is the people who’re capable of transforming business needs and rules into code. Which requires a social and analytical skillset for cooperating with non tech people. You’ll also see a demand for skilled programmers at scale and for embedded programming, but the giant work force of generalist developers (and probably web developers once Figma and similar lets designers generate better code) is likely going to become much smaller in the coming decades.

Then is basically what the entire office workforce is facing. AI believers have been saying AI would do to the office what robots did to the assembly line for years, but now it actually seems like they’re going to be correct.

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

#273

Post by jll29 »

andsoitis wrote: post #250
AdieuToLogic wrote: post #155

Earlier quoted context omitted.

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

> LISP and Fortran predate COBOL IIRC. Correct. Fortran, LISP, and COBOL were invented in ‘57, ‘58, and ‘59, respectively.

> Yes, but the ideas behind COBOL were older still. Flowmatic, COBOL’s predecessor, dates back to 1955, so it really just depends how you count.

Yes. but the ideas behind LISP were older still: Church's typed lambda calulus was conceived in 1936.

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

#274

Post by swiftcoder »

worthless-trash wrote: post #213
emmelaich wrote: post #181

Earlier quoted context omitted.

Surprised they don't use Swift. Or is that too unstable? Or is there a on-JVM requirement?

My money is that they started these projects before swift was available on linux. I have no evidence to say that apple use Linux, but businesses gotta business so isnt a big bet to make.

Even if the servers run MacOS, swift wasn't really being aimed at backend usecases for the first few years of its existence....

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

#275

Post by int_19h »

gavindean90 wrote: post #215
remlov wrote: post #61

Earlier quoted context omitted.

Several years ago I briefly worked at a major telecommunications provider with services across the southern United States that ran Python 2.4 on their production provisioning servers. Worked just fine.

The difference being that the COBOL is still supported after a decade.

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.

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

#276

Post by int_19h »

yawnxyz wrote: post #145

huh so are any languages actually dead? ChatGPT mentions FORTRAN, ALGOL, or Pascal... which I don't think are dead at all. Ada I've never heard of, so maybe that one's dead? If they're able to write WebAssembly compilers for all these languages, then they'll probably live forever! The only reason punchcards are "dead" is bc the machines are gone or mostly unavailable...

It depends on how you define "dead". ALGOL proper has been dead for many decades, but pretty much all mainstream general purpose PLs today are its direct descendants, and sometimes this ancestry is plain to see (e.g. every time you write "struct" or "void" in a C-like language, that's straight from ALGOL 68). I once wrote a comment on HN summarizing all the various bits and pieces I know of that are still around: https://news.ycombinator.com/item?id=18691821

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

#278

Post by dcminter »

moomin wrote: post #268
vishnugupta wrote: post #249

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 my experience, often it’s hard to find that person with deep domain knowledge, and even when they do, it’s unstructured, they take things for granted they shouldn’t* and the have no appreciation of the demands of formalism. Getting anything you can use to construct a work plan, never mind a detailed feature list, out of clients can be a dark art. *To the point I have repeatedly experienced a point close to the end…

I recall a spec doc from a domain expert that said something like:

"The transaction consists of a credit stub and a debit stub. If the debit stub is missing and is of type X then we do A and if it is of type Y then we do B."

How to know what flavour the missing item was? Absolutely no mention of that...

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

#279

Post by bad_user »

int_19h wrote: post #267
bad_user wrote: post #243

Earlier quoted context omitted.

IMO, there's rarely such a thing as maintenance mode. Projects constantly evolve, and in turn this drives more investment in tooling and the ecosystem needed to keep those projects up. And this investment is what eventually drives more new projects and fresh blood, keeping the language fresh and in demand. Again, look at Java. Ofc, there's always the question of what happens with a market that isn't constantly growin…

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 shit done and to have good ROI and maintenance costs. Therefore, the availability of documentation, tooling, libraries, and developers helps, in large and small projects alike.

And yes, Java is quite fresh, IMO.

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

#280

Post by sofixa »

kukkeliskuu wrote: post #211

Cloud is the new mainframe, except worse. It has all the downsides, but does not have the biggest upside. The grandpa could create (using CICS), a very reliable and performant service that would call other services inside the same transaction. The platform would handle all the complicated stuff, such as maintaining data integrity. Try to write AWS Lambdas that call each other within the same transaction.

> It has all the downsides

Vendor lock-in from a single vendor? Wildly expensive capex and opex? Impossibility for people to know any of the tech involved without you sending them on a course to learn about it or them already having experience with it?

> Try to write AWS Lambdas that call each other within the same transaction.

Why is that your comparison? Was deploying to the mainframe as simple as throwing a .zip with your code at an API that you could give access to developers?

Post reply on HN