Hacker News Reader

Comment by msla | Hacker News Reader

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

View on HN

Nobody writes

    MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN.

any more.

I mean, if you squint your eyes a bit, that could be SQL! So even if it's not COBOL, there's people out there writing in a vaguely english business programming language.

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

The exact opposite is true.

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 cursed to write them.

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.

Well, it is in the name. Structured Query Language. And I would argue that it is very often right mind send. You are trying to query data, not process it. Thus actually making it query seems rather reasonable paradigm.

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.

And SQL kinda dates from the same era, I wonder if this type of language was in vogue 50 years ago?

The only notable similarities I see are lack of special characters, all caps by default (most languages from this era are actually case insensitive), and using English words. Those characteristics were in vogue 50 years ago because many computers didn't support lowercase characters, and the set of non-alphanumeric characters supported tended to vary a lot between machines. Here's what the Jargon File had to say about EBCDIC, for example:

> EBCDIC: /eb´s@·dik/, /eb´see`dik/, /eb´k@·dik/, n. [abbreviation, Extended Binary Coded Decimal Interchange Code] An alleged character set used on IBM dinosaurs. It exists in at least six mutually incompatible versions, all featuring such delights as non-contiguous letter sequences and the absence of several ASCII punctuation characters fairly important for modern computer languages (exactly which characters are absent varies according to which version of EBCDIC you're looking at).

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

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.

Man that's almost like Hypercard.

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

You had me at MULTIPLY A BY B

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

Hence "I don't know what the language [...] will look like". Hoare seems to have made that remark around the same time work to redesign Fortran, what eventually became Fortran 90, began. Presumably he was aware of that effort and thought that Fortran would be able to keep reinventing itself as future needs dictated.

More accurate might be "I don't know what the language of 2000 will be called, but I know it will look like Fortran."

This was almost true in 2000. It is not true now. Things change. Slowly.

But are these legacy systems from the 70s, 80s, 90s using modern cobol?

When you hear about people being paid $X vs 10x$X to fix some cobol; is there a correlation between the age of the cobol system?

Probably not; just a matter of how desperate they are.

Which is also a function of how hard it is to find someone who has the required skills to address the problem

Almost certainly yes. The "legacy systems" are likely running on versions of the mainframe with long-term support contracts, whose vendors are committed to providing newer compilers with support for newer versions of the specification as necessary.

Depends what you mean; but not necessarily.

I am managing an ERP system implemented / went live in 2016. It's working on modern P10 hardware, which was released in 2021. The ERP system is continually updated by the vendor and customized by the client.

Even for COBOL running on an actual mainframe, which I think most HNers would think of 1970s dinosaur, most of the actual machines in production would be pretty new. IBM z16 was launched in 2022.

So they are "legacy systems" in the sense they're not written on a javascript framework which was launched last week, running on lambda instances in AWS :). But they are not "OLD" systems, as such.

Yep, the system is old in the same way that we could call x86 "old". The architecture is backwards compatible with instructions going back to the mid 1960s...but that doesn't mean new instructions and updates to the ISA aren't being pushed out on a pretty regular cadence.

The new Telum II processor (and certainly this also implies another big ISA update and new hardware cycle) was announced at Hot Chips just a few weeks ago for example. See:

https://chipsandcheese.com/2024/09/08/telum-ii-at-hot-chips-...

Reply on news.ycombinator.com