Hacker News Reader

Comment by Animats | Hacker News Reader

Nobody writes

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

any more.

View on HN

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

Reply on news.ycombinator.com