COBOL has been “dead” for so long, my grandpa wrote about it • Hacker News Board

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

#371

Post by discretion22 » Wed, Oct 02, 2024, 3:56 PM UTC

eru wrote: post #359

chii wrote: post #325

Earlier quoted context omitted.

It's interesting that domain experts all exhibit the same cognitive issue - their assumptions are just so ingrained that they cannot articulate it at all. The fact that they "know" a missing stub would have a type is because they actually have some more information than they let on, and this information is only known by the expert. For example, they know if the submission was from party A, it must be type X. But that…

> 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 they never told you about.

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

#372

Post by Seylox » Wed, Oct 02, 2024, 3:58 PM UTC

eru wrote: post #359

chii wrote: post #325

Earlier quoted context omitted.

It's interesting that domain experts all exhibit the same cognitive issue - their assumptions are just so ingrained that they cannot articulate it at all. The fact that they "know" a missing stub would have a type is because they actually have some more information than they let on, and this information is only known by the expert. For example, they know if the submission was from party A, it must be type X. But that…

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

Oh, you're onto something. May I slap a sticker on it and call it "agile"?

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

#373

Post by jerf » Wed, Oct 02, 2024, 4:12 PM UTC

mmcdermott wrote: post #302

froh wrote: post #244

Earlier quoted context omitted.

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

I think it's a lot of little things. There's a lot of people very motivated to keep presenting not just AI in general, but the AI we have in hand right now as the next big thing. We've got literally trillions of dollars of wealth tied up in that being maintained right now. It's a great news article to get eyeballs in an attention economy. The prospect of the monetary savings has the asset-owning class salivating.

But I think a more subtle, harder-to-see aspect, that may well be bigger than all those forces, is a general underestimation of how often the problem is knowing what to do rather than how. "How" factors in, certainly, in various complicated ways. But "what" is the complicated thing.

And I suspect that's what will actually gas out this current AI binge. It isn't just that they don't know "what"... it's that they can in many cases make it harder to learn "what" because the user is so busy with "how". That classic movie quote "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should" may take on a new dimension of meaning in an AI era. You were so concerned with how to do the task and letting the computer do all the thinking you didn't consider whether that's what you should be doing at all.

Also, I'm sure a lot of people will read this as me claiming AI can't learn what to do. Actually, no, I don't claim that. I'm talking about the humans here. Even if AI can get better at "what", if humans get too used to not thinking about it and don't even use the AI tool properly, AI is a long way from being able to fill in that deficit.

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

#374

Post by _yb2s » Wed, Oct 02, 2024, 4:16 PM UTC

AdieuToLogic wrote: post #155

_yb2s wrote: post #69

Earlier quoted context omitted.

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

> LISP and Fortran predate COBOL IIRC

I didn't mean to imply COBOL was anything close to the first programming language, only that I was speculating what 'programming' generally meant within computer culture at the time. I was not around at that time- but I strongly suspect that directly writing machine code and/or assembly was still common practice throughout the entire 1950s, whereas it is far less common nowadays.

I wonder what year Fortran overtook assembly and became the most popular programming language during that era? I suspect it was well after COBOL came out. Surely there is a lag time for any new programming language to become commonplace.

I couldn't find any data on that, but I was able to find that C was released in 1972, but took until 1982 to overtake Fortran, and until 1985 to overtake Pascal. I often forget how slow new things propagated through the culture in pre-internet times.

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

#375

Post by normie3000 » Wed, Oct 02, 2024, 4:17 PM UTC

Seylox wrote: post #372

eru wrote: 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?

Oh, you're onto something. May I slap a sticker on it and call it "agile"?

How about "extreme programming"?

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

#376

Post by 0cf8612b2e1e » Wed, Oct 02, 2024, 4:18 PM UTC

int_19h wrote: post #275

gavindean90 wrote: post #215

Earlier quoted context omitted.

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.

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?

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

#377

Post by jtotheh » Wed, Oct 02, 2024, 4:26 PM UTC

I worked for a while as a contractor for the US Dept. of Education Student Loan system. It was z/OS with DB2 and most new business logic was done in this weird language "Gen" https://www.broadcom.com/products/mainframe/application-deve... . Gen can supposedly "generate" java and other stuff but they used it to generate COBOL for the mainframe. You could debug the Gen code on the 3270 emulator, rather than trying to deal with the generated COBOL. There were a small number of people (like 6) who were handling that code. The data and I guess some of the code went back to like 1980 at least. There was so much legacy code, I doubt they've changed platforms. I was supposed to be more a Java guy but I did a little Gen. Mainframe is very alien to me. The people that knew it well could really crank on it, though. I joined when they were converting an MS ASP front end to a Java one. So we wrote Java that users interacted with via the web and that made calls to Gen (really, to cobol). In retrospect there was a lot wrong with that operation... One interesting problem that came up once was that the mainframe didn't sort things the same as Java. It turned to be caused by EBCDIC vs UTF.

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

#378

Post by sigmonsays » Wed, Oct 02, 2024, 4:39 PM UTC

jtotheh wrote: post #377

I worked for a while as a contractor for the US Dept. of Education Student Loan system. It was z/OS with DB2 and most new business logic was done in this weird language "Gen" https://www.broadcom.com/products/mainframe/application-deve... . Gen can supposedly "generate" java and other stuff but they used it to generate COBOL for the mainframe. You could debug the Gen code on the 3270 emulator, rather than trying to d…

thanks for sharing that, it's super entertaining to consider what crazy things people might be doing in the future. Debugging EBCDIC was a surprise and got me laughing.

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

#379

Post by krackout » Wed, Oct 02, 2024, 4:42 PM UTC

COBOL is dead? Not at all. Are new projects created in COBOL? Yes they do. If not in older COBOL form, definitely in SAP ABAP.

For those who haven't heard about it, ABAP (Advanced Business Application Programming) is the name of SAP’s proprietary, fourth-generation programming language :) It's SAP's main language. It's a direct descendant of COBOL, I'd describe it as a COBOL with OOP extensions.

Since SAP's ecosystem is sneaking everywhere, COBOL in its modern, very close incarnation (ABAP), gains new space!

If in any doubts, check some ABAP code. It's not simply influenced by COBOL, it's COBOL.

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

#380

Post by zifpanachr23 » Wed, Oct 02, 2024, 4:43 PM UTC

kjellsbells wrote: post #161

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.

I hope you're right, but many comments here on HN suggest their experience with mainframes is very different. z/OS and its predecessors provided so many services completely transparently to the application that a mainframe to modernity migration is doomed to fail unless it can completely emulate (or design around) the capabilities provided by the OS and other subsystems. Even ignoring the needs of the super high end…

I work on them full time (not doing application programming and so I can't really speak to COBOL) but this is mostly accurate as it relates to the environment.

A lot of these services are completely transparent to the application, but that doesn't mean they are totally transparent to the entire programming staff. The system configuration and programming is probably more complicated (and lower level usually, certainly YAML hasn't really caught on in the Mainframe world outside of the Unix environment) all things considered than something like k8s.

So that's where a lot of the complications come in to play. Every application migration is going to necessarily involve recreating in Kubernetes or some other distributed system a lot of those same automations and customizations that decades worth of mainframe systems programmers have built up (many of whom will no longer be around). And however bad the COBOL labor shortage really is, the shortage of mainframe assembly programmers and personel familiar with the ins and ours of the hardware and system configuration is 10x worse.

It should also be noted that not everywhere that has a mainframe has this issue. There is a wide disparity between the most unwieldy shops and the shops that have done occasional migrations to new LPARs and cleaned up tech debt and adopted new defaults as the operating system environments became more standardized over time. In the second case where a shop has been following the more modern best practices and defaults and has fewer custom systems lying around, ... the amount of effort for a migration (but also in a lot of ways, the motivation to take on a migration project) is lessened.

The case where some company is just absolutely desperate to "get off the mainframe" tend to be cases where the tech debt has become unmanageable, the catch 22 being that these are also the cases where migrations are going to be the most likely to fail due to all of the reasons mentioned above.