The original Bourne shell was written in a *very* strange style of C, which shows that even in 1979, some of the original Unix greats disdained C's famed terseness & wanted _keywords_ instead of punctuation marks.

TIL it has a name: it's known as "Bournegol".

https://oldhome.schmorp.de/marc/bournegol.html

Marc Lehmann's "Bournegol Page"

Bournegol

@lproven so, C but it reads like SQL
@ZanaGB @lproven SELECT curse FROM antiquity
@f4grx @lproven WHERE `legibility` IS NOT NULL
ORDER BY `keyword_length`;

@ZanaGB @f4grx

So does that imply

IF LEN(keyword) = 1 THEN legibility = 0

...?

Because personally that's always how I've found the curly-braces languages. SPELL IT OUT you lazy b@st@rds. What's the matter with you, can't you smegging well type?

@lproven i suppose it depends, what kind of model of program structure do you want your syntactic-assembly-instructions (the { and endif and so on) to imply?

keywords imply to me

while_start(); // push evaluator state
while_cond(expr);
// ... work
while_end(); // jump or pop

where keywords indicate a state-modifying instruction

braces imply to me

fnwhile(^{ return expr; }
, ^ {
// ... work
});

where control structures are syntax-time operators that accept blocks as their operands

both models have their place
personally i have come around strongly to the second because it seems more composable and abstractable (i.e. you can define "higher order" controls that take the control operator and apply blocks to it)
which is useful specifically because that's what i like to do, maybe not what others want to do

@ZanaGB @f4grx

@erisceleste @lproven @f4grx

We personally love a very verbose way of laying down instructions. But then again a lot of our work is basically functional with little to no objects in place. So perhaps not as abstracted as some people. so having your BEGIN FOR, END WHILE, IF, CASE, DO, etc etc, and other, almost SQL-isms are neat.

Your first example is easy to figure out what it might be doing. your last example is pretty much just soup to our eyes (also is that a return type declaration or the variable to return at the end of the function? etc etc).

A lot of people do rave about natural language programming but honestly, just having actual readable words for what you're doing even if you're doing verbose assembly would be good. ( but, again, it is not the same to stuff some values into some registers to have a little bunny move across a 32 tile playfield than it is, temperature monitoring for blood samples or what have you)