That a language might overcome the "any hunk of code bigger than a screenfull is too complex to manage", other than by chopping the code into functions and classes or whatever, is news to me.

What are other methods for slaying this complexity? And what are the languages that use it?

I think it's all of the languages people complain are "too complex": to be able to deal with more of program's complexity, you take on more language complexity.

e.g.:

• Encapsulation. Keeping implementation details private is pointless when you deal with a small program (the implementation is right there on your screen), but it becomes valuable when otherwise it'd be too hard to check which details you can change and which you can't.

• Strong type systems. All the types are obvious when the program fits in your head, and seem like unnecessary boilerplate. However, when the program is large, it off-loads a bunch of sanity checks from your head to the compiler.

Same goes for design patterns. Writing an `AbstractWidget` and `WidgetFactory` when you have two widgets to deal with is overcomplicating. But when you have 50 widgets, you need something to avoid drowning in copypaste and spaghetti if/elses.

Ideally, the features needed for writing bigger codes should be optional. For instance, a beginner can write a Python script within a single screen that does something like graph some data. Encapsulation can be treated as an add-on, as can be the type system.

That's assuming you want scalability. If a language is absolutely never going to be used for scripting by beginners, it doesn't need to be used that way.

> Ideally, the features needed for writing bigger codes should be optional.

Newer languages like Rust, Swift and arguably Carbon don't make programming-in-the-large features "optional"; they make them as lean as possible, so that users can more easily apply them at the outset compared to older languages like Java/C#. That way even a screenful-length trivial script can potentially grow into a larger system without becoming unmaintainable in the process.

Oh, you shouldn’t really be comparing unreadability of BASIC to even Unix shell scripts. Python is the pinnacle of readability and structure in comparison.

Let’s see…

Numbered lines as labels, GOTO everywhere. You got GOSUB if you were lucky.

All state propagated mostly via global variables. Subroutine parameters were present in dialects few and far between.

Now, variables. Maximum length of an identifier was what, 1? Or 2?

Inconsistent delimiters and syntax in general. Take GW-BASIC and its hot mess of graphical commands. Here you can’t have parentheses, but there you must. Semicolons here, commas there.

All the stuff that makes programs readable — consistent syntax, named procedures, reasonably long variable names, named labels if you must — all appeared very late, in QBASIC I think. But the rest of the BASIC world still had to cater to the lowest common denominator if your program was to be even mildly portable.

For starters, you didn't "get GOSUB if you were lucky". It dates back to the very first version of Dartmouth BASIC.

That aside, most of the limitations that you describe are applicable to BASIC as it was in 1970s (and some, like numeric-only labels and single-letter identifiers, are straight from the 60s). For example, GW-BASIC that you mention already had 40 significant characters in identifiers, WHILE loops, and single-expression user-defined functions.

I also don't recall anyone writing any serious amount of BASIC code while catering to the lowest common denominator for the sake of portability, simply because the dialects were different enough that it wasn't really feasible. Even on a single platform like DOS, going from e.g. Turbo BASIC to QBASIC required substantial changes.