That sentiment may be true to some extent, but fails to mention all of the problems of the BASIC language that made people look into alternatives, none of which were snobbiness.
If that were a real reason, Python would have suffered a similar fate.
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.
Not true. When I learned Applesoft BASIC in 1978–79 on an Apple ][+, it had arrays.
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.
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.
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.
What are other methods for slaying this complexity? And what are the languages that use it?
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.
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.
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.
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.
Although Turbo Pascal was also popular for a time, I'm not sure anything truly replaced these beginner-friendly languages until Python came along.
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.)
In any another environment, it really doesn't make sense.
This was before floppy disks… you could load a program from cassette tape.