6502.org

It was indeed a major contributor to the democratization of computing. Hats off, sir, may you rest in peace.

It's only unstructured BASIC that's unstructured. Structured BASIC isn't unstructured. REPEAT:PROChelp(sys1%):sys1%=FNtest(in%,flag%):UNTIL sys1%>endstate%

Yeah, but pretty much any high-level language on microcomputers would have done that. It happened to be BASIC, but didn't have to be.
Yes, your analysis of that is correct, I believe. Forth is certainly higher level language than assembly language, but it's nowhere near as high level as BASIC. It's not so much just the stack use, but the particular style of stack use (including the lack of an easy and clear way of nesting things) that causes problems in the realm of expressions. You'll note that Lisp, which is a similar notation but prefix instead of postfix, doesn't have this issue.

But it goes further, as you mention: one thing that even the microcomputer BASICs had was automatic memory management which, as we all know to this day (at least those of us who have programmed in C and C++) is a big boon.
Sure, but that's what people learned on, and in the end when someone decided to strip down "mainframe" BASIC and functions went out the window, that's at least in part on the language designers. That couldn't have happened with Lisp.

It's worth noting that a huge factor in BASIC being a win over, e.g., FORTRAN (which provided the general idea of the language), was its focus on interactive development. Which of course was taken from (or rather, given by, given that McCarthy suggested it to Kurtz) Lisp.

Yes, but that rather completely misses the whole point of structured code. We don't write structured code because it's inherently better; we write it because it's a much clearer expression of our intent, thus making it easier for other people to read, find bugs in, modify, etc.

Would you say that the code above is the clearest possible way, and easiest to read way, to express what you're trying to say? Is it quick and easy to identify the loop structure at a glance?

At first glance, that doesn't even look like BASIC to me. But I grew up with Microsoft BASIC variants, so it's not as easy for me to mentally shift gears.

JGH's example would be more convincing, I think, if laid out differently. It's standard BBC Basic.
It's clear (to me) that REPEAT..UNTIL is a nice addition, much more structured than FOR, IF, or GOTO, and also relatively easy to implement (it doesn't need any lookahead or complex parsing)

BigEd is right; it's not the syntax of the instruction but the semantics of the way it's laid out.

It's why my tiny basic doesn't allow multiple statements on a line; it's too easy to miss some small but critical part of an instruction within a loop when it's all stuffed on a line. (I implement REPEAT/UNTIL as do/while which is effectively identical beyond the names, and the sign of the final test).

Programming is a question of algorithms and data structures; tricksy programming helps nobody and deliberately obfuscated code - irrespective of the language that's being obfuscated - is an offence to any other programmer... there is absolutely no point in writing code that no-one else (including, probably, future you!) can read.

Neil

BigEd, that clarified things massively.

Interestingly, writing that out in a more functional way to get rid of the extra complexity of the REPEAT loop makes more clear one of the issues with the code: when you rewrite it to be a function with a tail call you discover you need to add a sys parameter, at which point it becomes obvious you need to set sys in two different places: once outside the loop and once inside it:
This points out one of the issues with BASIC's hard focus on an imperative style, rather than encouraging the use of functions for everything.

I'm probably in the minority here, but I'm actually fond of tricksy programming, especially on older CPUs that can significantly benefit from its utilization, with smaller and/or faster being the implied goal. This is where proper and informative comments in the source can make all the difference. Obfuscation can have a place too, but a much smaller one, IMO. I'm not really a "programmer" though ... I'm a hobbyist/hacker who likes to program with an intense fetish for optimization, so that is a contributing factor.

Ah, but you don't have to work with decade-old code written by a cow-worker with a penchant for, um, dense programming matched only by his distaste for white space and comments... "All my code is self-commenting!"

Though I can appreciate the intellectual challenge of creating the smallest fastest code - you need only look at my neobasic, though I haven't 'optimised' it yet, for an example - I can't help feeling it doesn't have anyone in a professional environment.

Neil