[velcrovan]

For years I maintained an ERP system written in BASIC. It was legitimately terrible. The lack of lexical scoping and decent flow control made it nearly impossible to reason about for even simple changes. There’s nothing brilliant about line numbers and all-global variables, it’s literally one of the laziest, sloppiest design decisions you could make in a programming language.

Granted, if your only experience of BASIC is fond memories of the TRS-80 at your grade school, yeah any contempt for it will seem simplistic and poorly motivated. Maybe try having to depend on it for literally anything in a professional setting and you’ll have a more informed perspective.

[lproven]

1. I helped maintain a payroll system written in GW-BASIC for a year or two. It was designed cleanly and well, with each module of code a separate file chain-loaded in from disk as a de facto overlay system. The variables that each module inherited were thoroughly documented in code comments at the top of each module, so it was clear what it would inherit in RAM and which you needed not to touch.

Just as one can write spaghetti code in any language, one can equally write good clean code in any language.

2. Remember what the _B_ in BASIC stands for. Despite that it was used professionally, yes, but there is in any and all fields a need for easy tools for beginners to learn with.

https://www.fortressofdoors.com/take-the-pedals-off-the-bike...

As discussed here:

https://news.ycombinator.com/item?id=42697467

[velcrovan]

The overlay system is an even worse paradigm than global variables within a program. And one I too am very familiar with.

What happened here was that this payroll system of yours was written by people who saw clearly the danger of BASIC's many footguns and mitigated it the best way they could, by supplementing their code with vast quantities of english prose. This is not an argument in favor of BASIC.

> Just as one can write spaghetti code in any language, one can equally write good clean code in any language.

This is only half the truth. It's like saying it's equally possible to drive well or poorly in a 1990 Yugo as it is in a 2025 Accord. The car actually does matter in a lot of cases. I despise Python's tooling, but if one were to do a thoughtful rewrite of your old payroll system in Python, all those code comments would be completely unnecessary (it would be impossible to commit the kind of error that the comments were needed to warn against), and the code itself would be far easier to read and maintain.

[lproven]

> the code itself would be far easier to read and maintain.

As it happens, my boss, who wrote the app, quit, started his own company, and did rewrite it, from memory. He did it in QuickBASIC 4: it became a compiled binary app, in structured code. That made it more readable, sure: the point here being, it wasn't necessary to rewrite it in another unrelated language to get that win.

But QB was a cut-down version of the MS BASIC Professional Development System. It was intended as a pro tool, not as a thing for learners.

In other words:

• Don't mix up simple BASICs intended for beginners with pro-level ones.

• Don't assume that a more "serious" language means more readable code, because it doesn't.

• The flipside: don't assume that more readable code needs a more serious language. It doesn't.

None of your criticisms address what I'm trying to say, which is that BASIC was in its time a good tool for beginners, and the evangelists of, say, Python have failed to understand _why_ it was good at what it did. Python is _not_ a globally better thing.

Tools that are good for pros may be bad for beginners, just as tools for beginners can be bad for pros. This is surely not a stretch or a controversial statement.