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

#411

Post by DebtDeflation » Wed, Oct 02, 2024, 7:56 PM UTC

chii wrote: post #325

dcminter wrote: post #278

Earlier quoted context omitted.

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

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…

My experience with "business domain experts" is that the majority of them are simply executing a process that someone else defined a long time ago. Their definition of "success" is usually that all steps within the process execute successfully without error and they can move on to the next transaction or activity. Very few of them are capable of taking a step back and considering what the process is actually trying to achieve and whether there might be a better way of accomplishing it. This leads to constant "paving of the cowpath" where archaic processes just get replicated in new technologies every so many years.

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

#412

Post by randomdata » Wed, Oct 02, 2024, 8:18 PM UTC

bad_user wrote: post #279

int_19h wrote: post #267

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…

> The more popular a language is (in large enterprise codebases), the more it will get used in new projects

It seems to me the more popular a language, the more poorly written libraries are found in it, which soon starts to draw people away from what is popular to a new language that has a limited library ecosystem thinking they can fix the mistakes they saw last time and make a name for themselves in the process. Lather, rinse, repeat.

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

#413

Post by User23 » Wed, Oct 02, 2024, 8:34 PM UTC

zdragnar wrote: post #399

User23 wrote: post #194

Earlier quoted context omitted.

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…

I’m not really sure what you mean. Both prefix and infix if are both based on natural language conventions. So, for that matter, is reading code from left to right and any other number of patterns.

The infix if form is as if not more readable than the prefix if in cases where only a single statement is guarded.

I mean we could code without any pesky natural language at all by using some kind of lambda calculus with de Bruijn indices, but I think most people would find that considerably less readable.

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

#414

Post by codr7 » Wed, Oct 02, 2024, 8:44 PM UTC

bigiain wrote: post #235

bigger_cheese wrote: post #182

Earlier quoted context omitted.

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.

Perl footgunned itself with the Perl5/Perl6/Raku and almost 2 decades between major releases debacle. I wrote a _lot_ of Perl, starting with Perl4 cgi scripts in the mid 90s, then Perl5 and FastCGI and Apache ModPerl. I loved it as a language. But by the time I left that gig in 2008, nobody wanted Perl any more. I mostly drifted around PHP, Python, Ruby, and Javascript for a few years until moving away from full time…

I lost interest long before Raku, Parrot was a wild ride :)

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

#415

Post by artificialLimbs » Wed, Oct 02, 2024, 9:17 PM UTC

refneb wrote: post #29

exhilaration wrote: post #22

Earlier quoted context omitted.

IBM offers just such a service under the WatsonX branding, it's an LLM to convert COBOL to Java: https://www.ibm.com/products/watsonx-code-assistant-z I work at a company with a large COBOL codebase and this has been mentioned in a few presentations about our modernization efforts.

How did that go? My employer is going to try snd evaluate watsonx product. Have you had any luck converting large/complex COBOL modules ?

Don’t know about COBOL, but we recently threw some ancient RPG 3 programs into ChatGPT for conversion to both ‘plain English’ and PHP and it got pretty close - maybe 80-90%.

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

#416

Post by dcminter » Wed, Oct 02, 2024, 9:25 PM UTC

chii wrote: post #325

dcminter wrote: post #278

Earlier quoted context omitted.

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

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…

> For example, they know if the submission was from party A, it must be type X.

Ha! As far as I remember it was almost exactly this when we interrogated them (but it's been a while).

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

#417

Post by justincredible » Wed, Oct 02, 2024, 9:28 PM UTC

7thaccount wrote: post #122

hollerith wrote: post #109

Earlier quoted context omitted.

Bizarre comment. No developer who should be allowed anywhere near a computer would ever consider choosing COBOL where Rust is appropriate or vice versa.

I don't think the use cases for Cobol (bank software) typically overlap with those for Rust (operating systems...etc). It's like saying no gardener should be allowed near a garden that would choose a shovel over a pair of shears. Both have a place.

[dead]

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

#418

Post by 9659 » Wed, Oct 02, 2024, 11:05 PM UTC

johnnyjeans wrote: post #356

tombert wrote: post #98

Earlier quoted context omitted.

Fair, I guess the list was “languages that I know were popular at one point but I don’t know anyone really using now”. Ada definitely does seem pretty cool from the little bit I have read about it. I’m not sure why it’s fallen by the wayside in favor of C and its derivatives.

It's easy to get lost in the modern way we look at compilers and toolchains, but it wasn't always like this. Free compilers basically didn't exist 30+ years ago. Certainly none of the free compilers were good . For the longest time, your only options for Ada compilers were priced at government contractor-levels (think $10k per seat... in the 80s). It's also an extremely complicated language, while C isn't. A single,…

if gnat (the gnu ada translator) from NYU had come out 5 years earlier, ada might have caught on with the masses.

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

#419

Post by rafark » Wed, Oct 02, 2024, 11:22 PM UTC

cies wrote: post #403

FrustratedMonky wrote: post #51

Is PERL dead yet?

I asked ChatGPT -- Please estimate the popularity of these languages, relative to the most popular one (that gets 100%). Base your answer on community activity on different platforms (stackoverflow, reddit, hacker news, dev.to, github) and the number of books available and sold: COBOL, Perl, PHP, BASIC, TCL, ColdFusion. Estimated popularity: PHP: 100% (reference) Perl: 30% COBOL: 25% BASIC: 10% TCL: 8% ColdFusion: 5%…

Why php though? Php is as old as java and very popular and constantly updated.

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

#420

Post by hardburn » Wed, Oct 02, 2024, 11:46 PM UTC

greenavocado wrote: post #165

hardburn wrote: post #141

Earlier quoted context omitted.

I actually met a programmer who worked on military jets. According to her, Ada is only used anymore for the older jets that were already programmed in it, and she worked in C++.

Military jets coded in C++. God help us all.

Most aerospace stuff is. The thing is, they have reams of very specific rules about how it's coded, how to verify that code, and how to verify the compiler of that code, and how to verify the code output from that compiler. It's not an easy process to replace, but its proven reliable just by all the commercial planes flying every day without falling out of the sky.

In theory, something like Rust could do the job instead, but they'd still have to verify the entire chain. Rust is for the rest of us to get something half as reliable as that while also being able to write more than two lines of code per day.