BASIC illustrates the "one-screen problem," where a program becomes unreadable when it exceeds one screen, or perhaps one printed page. The one-screen problem is how I explain to beginners the value of things like subroutines with named arguments, local variables, and the like. Languages that survive, have to work for the size of programs that people want or need to write.

1980s BASIC was maybe the only language I ever tried and disliked. Maybe it was because I'd never tried programming in assembly, I don't know. But it felt just all wrong to me. It abstracted over all the stuff I didn't want abstracted, and it didn't make it easy for me to manage complexity. I always had the feeling that to use BASIC, you ironically had to be really smart. To this day I have no idea how people wrote large programs in that language. Especially on platforms like TI calculators.

> BASIC illustrates the "one-screen problem," where a program becomes unreadable when it exceeds one screen, or perhaps one printed page.

Python has the same problem though, as do "scripting" languages in general. The limit may be some low amount of "screens" as opposed to a literal screenful of text, but either way it's quite impossible to program "in the large" with it. Even Go is hampered in this domain by its limited abstractions.

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.

BASIC was very practical for 8 bit machines. You didn't even need an editor, because you could just retype a line. It was also very straightforward for a complete novice (as most people were with those machines).

In any another environment, it really doesn't make sense.

True. One feature that was missed about BASIC on those early computers: you’d turn on the Apple ][ and you were greeted by the BASIC prompt and you could just start typing your program.

This was before floppy disks… you could load a program from cassette tape.

In Atari BASIC and Commodore BASIC, you didn't even need to retype a line. You could cursor up and edit it right on the screen. This saved a ton of typing.

QBasic (actually QuickBASIC; QBasic being the IDE) fixed some of the more glaring deficiencies of the original BASIC and I think was pretty popular for quite some time. I tried it and didn't like it--as I recall, I found things like error handling awkward. But it was from Microsoft and stayed around for quite some time.

Although Turbo Pascal was also popular for a time, I'm not sure anything truly replaced these beginner-friendly languages until Python came along.

> QBasic (actually QuickBASIC; QBasic being the IDE)

QuickBasic and QBasic both included IDEs; QBasic was the later revision (1991, vs. QuickBasic in 1985).

(Weirdly, perhaps, Microsoft released Visual Basic the same year as QuickBasic.)

Visual Basic was very successful, until Microsoft turned it into a mere alternative syntax for C# [0]. There is a parallel universe in which classic Visual Basic would have continued to thrive as a win32 glue language. (It still does to a minor extent in the form of VBA.)

[0] http://catb.org/jargon/html/V/Visual-Fred.html

I agree. VB6 was actively executed by Microsoft. VB6 didn't have to die.

I'm still surprised to this day that nobody stepped into that vacuum and created a VB6 clone. There should have been a ton of money for doing so--I wonder what prevented it.

I still have clients who are struggling to upgrade millions of lines of VB6 code base into something more modern (generally Python). GUI construction sucks in every single language since VB6.

The nice part is that they are unanimous in not choosing a Microsoft language ever again.

I've done some porting of VB6 into C# with WinForms. It's actually a pretty direct mapping. I wrote a converter, and then spend a few minutes cleaning up the converted code per form. Took me a couple weeks to convert a 500KB program, which mostly involved going through and converting VB6-isms that failed to auto-convert into C#. I can't imagine trying to translate something like that into such a different language and UI environment as Python. Unfortunate that they'd reject such a thing just because C# came from Microsoft.

> The BASIC cause of death is written that it was seen as a lesser, kids language.

Nah, its more that:

(1) The standardized, broadly compatible subset was a mostly unstructured, imperative language with very limited features, only global variable scope, named custom functions limited to a single expression (and a syntax that sharply limits what can be in a single expression), variables limited to numbers and strings, that was very tightly adapted to systems without modern capability (“line numbers” seem baroque now, but it really was a great way to have a simple, line-oriented text environment that worked as both REPL and simple dev environment.)

(2) While there were plenty of nonstandard versions with more modern features, they were mostly proprietary, often tied to very specific other pieces of software, and not particularly interoperable between them.

(3) Plenty of more modern, just as easy to use for simple cases, languages became available that had broad cross-platform compatibility (sometimes, not always, with formal standardization) without the limitations of BASIC’s broadly-compatible subset.

(4) Almost no computers came with “power on BASIC” anymore, so the unique role the ubiquitous use of BASIC in this way in the 8-bit home PC era gave it and which provided a support for its overall popularity went away.

> variables limited to numbers and strings

Not true. When I learned Applesoft BASIC in 1978–79 on an Apple ][+, it had arrays.

Correct, numbers, strings, and arrays of each of those would have been more accurate.

defined via 'dim'