[jbandela1]

Especially when teaching children, limiting abstractions is helpful.

A 5 year old can tell you what:

    10 PRINT “HELLO”
    20 GOTO 10

Does. You can basically look at each line In isolation and figure out what is going on. There is no nesting or scopes.

In addition other than the quotes there are minimal additional symbols. Even parentheses in a function call can be confusing.

[SoftTalker]

And those old computers (TRS-80, TI/99, Commodore 64, etc) that booted straight to a BASIC prompt were so simple to use. You turn them on, they booted in a few seconds and you were ready to start entering code. The programming environment was also the REPL and the OS shell. You were not distracted by those things being conceptually different. The need to use GOTO/GOSUB and line numbers was limiting but also made the flow of control very clear to a new programmer.

[sitkack]

Imagine if you had that repl experience but you also had searchable documentation and tutorials right there with the ability to either view side by side or hit a function key to bring up documentation about the current symbol?

Imagine a world where ram remained constrained but GBs of flash was basically free (like now), how different computing would look.

[analog31]

When I learned BASIC in ca. 1981, my high school had these machines that looked like a keypunch but recorded your "cards" on a floppy disk. You handed the disk to the computer operator and got your printout back later. Terminals were installed a year later.

It meant that you got maybe a couple debug cycles per class hour at most. The lectures, and most programming and debugging, were conducted by tracing through programs on paper or the chalkboard. The simplicity of "thinking like the machine" in BASIC was valuable for this process.

Maybe not any more, now that computers are widely accessible. But I have a hunch that thinking through algorithms is still an important stepping stone towards becoming a programmer.