In defence of BASIC

[rowan]

Sorry, it's more of a Bleatings post. But.



Sometimes I feel BASIC gets a bit of a bad rap. Maybe it doesn't, I don't know.
It was my first exposure to a programming language, on the speccy when I was really young.
It introduced a lot of useful fundamentals; this is a variable, that's a calculation statement, here's a FOR loop, this is a GOTO, that's a GOSUB.

I've used many other languages since, imperative & declarative.
BASIC's not a language I've been near, nor wanted to for the majority of my life but it still holds a fond memory as the first.
I've seen a number of impressive things done with it over the years. It's useful.

For all the haters, at the very least it gives real, implemented demonstrations of how you may not want to do things, so you can avoid them.
I'd say that has to be useful & hence creditable to them too.

So I sort of like you, BASIC, some ways.

[zip accident]

I sort of agree, but there were a lot of different varieties of BASIC, Some were good, some were probably terrible, but most were in between those extremes.

The first BASIC I saw was on the psychology labs 6800 based micros, first I programmed on was DEC System 10 BASIC, it didn't have PEEK or POKE. I found the BASIC on the NewBrain accessible, but the BASICs for the ST were too much, they had far to many keywords, they were trying to be c++ before it was invented.

[Whiteball]

BASIC on early home micros helped kick-start so many peoples interest in computers I don't think it can ever be overstated enough. Despite all the varieties and flavours (some good, some so not) doesn't really come into it.

Without BASIC home micros may have struggled to take hold as quick as they did and some peoples careers may never have got going in computers at all.

BASIC was and is a good thing. Accessibility was key and BASIC deliverd that to the masses.

[Dio]

I'm a little unsure about how true that is. Maybe yes for the first two generations of home micros? But once the 1982 machines came along, I'm not sure how many people ever used BASIC at all beyond maybe the first few pages of the manual and losing interest. It's not insignificant, but at the same time I think the idea that millions learned BASIC on these machines is rather overstated. Most people bought computers to run software, whether games or something else (observe how the 16-bit machines abandoned default programming languages altogether and nobody cared); the ZX81 is the one clear and obvious exception because it didn't really have any useful software, but I've always had a sneaking suspicion many ZX81s were impulse buys that never really got used much.

But if we're talking BASIC... BASIC's an interesting conundrum. If you're working on a machine with a few KB of RAM - even the 64KB of RAM on some of those machines, you get straight into two key constraints whatever language choice you might use:
- You're not going to be able to write much in the way of comments.
- You're not going to have long identifiers.

Those two mean any code you write is inherently going to be impenetrable and to some extent restricts you to toy languages on such machines, although the problem is mitigated by the fact that programs are so small you can kind of hold the whole thing in your head; if you've got a 1KB machine, who needs multiple letter variables anyway? In that context, BASIC's not that awful. But...

... fundamentally, early 80s BASIC is a terrible, terrible thing. The primary key deficiencies are:
- line numbers. These are really primarily a concession to the inline editor; to use them for flow control as well is truly awful design, not leas because it's slow (most BASICs do a linear search through the program to find the destination, so GOSUB/GOTO slow down depending on where in the program they are). Which also then creates...
- flow control by line number is such a bad idea. You have to look at the destination code to understand what's being done. Even two character labels would have allowed at least some expression of intent and fitted in the same space. And then you also get...
- All variables are globals, including any parameters you pass to functions.
- With no concept of data structures it's very hard to do any interesting data manipulation. Fundamentally you're kind of restricted to it being a smart calculator.

The core lesson to be learned from BASIC is "This is awful. How do I get access to something better?" Even at 11 years old, it was quickly clear that the most interesting thing in the Spectrum manual was the table of Z80 opcodes. I think a less obvious deficiency is that it teaches people that the things above aren't important, which I think put in a layer of snobbery that at first held me back significantly when I was started on real high level languages like Pascal and C (I only finally managed to get the point of C when I worked out how it was a thin layer over assembly with added data structures).

Anyway, at least thankfully it wasn't FORTH that won out. Write-only code is never useful.

As part of my continual attempt to build a better 1982 computer - for the Pointless Retro (TM) concept I'm working on, the goal is basically a Spectrum that could have won the BBC contract and beaten the C64 in every respect at roughly the same price - I've been toying with better languages that were practically implementable on small computers. You can get something much more readable and easier to use on there (you can do something somewhat like Python, or add strong types and make it a bit more C-ish). The key trick (beyond adding data structures, named procedures and local variables) is to turn identifiers into indexes into tables with the entries assigned at the declarator which allows you to have at least marginally interesting identifier names while still keeping the cost at each site down to a couple of bytes. If you do it right, you can actually write a decent part of the ROM in this thing as well (once the basic calculator stack works, you might as well use the language to do all the trasncendentals). Hard to think it would work well on 1KB machines, mind.

Haven't got it working yet, though - the data structures are tricky to manage in assembly language, mind, and it creates a few slightly non-obvious things in the editor (e.g. changing the name of the declarator changes the name of all the references to it).

[KlaxonCow]

My defence of BASIC would be that it was properly immediate - interpreted and dynamic.

You type in a command, hit return and it runs then and there.

Because that was really how it was mostly used by the majority of people, to function as the operating system of these early machines.

LOAD "*",8
RUN

And while languages like C, C++, Python, RUST, etc. are all so much faster and more powerful, and I like them, I feel that what's missing is that immediacy.

Note that I am differentiating between "interpreted" and "immediate" here a little. There are still plenty of dynamic interpreted languages. But the immediate "command line" type of language is missing and I've often thought it's needed.

This is what BASIC (imperfectly) provided back in the day, and I don't feel there has been a successor to it in terms of that immediacy.

If I had the time, I've always wanted to create such a language, where that "immediacy" is its central pillar.

My thoughts were to borrow the "word" concept from FORTH. Though the rest of it - with the operand stack, writing things "backwards" all the time - would be gone, replaced by something C-like instead.

But keeping that idea from FORTH, where you define a "word" and build up a dictionary of these words, and then could call them immediately by just typing their name (and words can call other words too).

Code: Select all

:example
   print("Hello, World");

> example
Hello, world!

Yes, "words" here are just functions, really. But there's the notion that you build up a "vocabulary" of words - the system would come with a whole bunch of them pre-defined.

And it's designed for immediate use. Functioning, as BASIC used to do, as a command line operating system. So one of the pre-defined words could be, say, "wordCount", another "grep" and so forth, so you could do UNIX-like chaining and piping.

E.g. "wordCount(cat(grep("/folder/*.pdf", "fish")))".

Grep files in a folder that contain the word fish, pass that array of files to "cat" to print them out and "wordCount" tells you their word count.

(Yes, I said array. It'd have basic data structures like that, and data typing.)

Stuff like that. Because I do think what's been lost is that immediacy. You write code in a IDE or text editor, then pass it to the compiler or interpreter. And that one level of indirection breaks the immediacy.

But the idea here is that it's all designed to be immediate. You're at a command line and you type a word, and it runs immediately. Even when defining new words, you're doing it at the command line. Open the definition, type in your code, close the word. Then it's immediately in the vocabulary for use.

Yes, this is a bit like typing in line numbers with BASIC. But it's fixed. Line numbers are crap, as are GOTO and GOSUB. Instead, you define a "word" by a colon and giving it a name. You call it by just typing the name and hitting return. You can redefine it by just defining it again. You can "LIST" the words in the vocabulary, or "LIST wordCount" to list the code for the "wordCount" subroutine. Use arrow keys to edit it and then hitting return redefines it.

(And, like, when you enter that definition, it could be compiled there and then, rather than interpreted, if you want maximum performance. Like QuickBASIC used to do, which is what made it "quick".)

Like, that old immediate BASIC way of doing things. But I'm just fixing the shit bits - no line numbers, but named subroutines. Words can have parameters in parentheses. Subroutines can return values that you can then plug into another subroutine, like C.

I reckon it'd be cool. A command prompt and then you build up a "vocabulary" of commands to get shit done. With the emphasis on that immediacy, all running from a command line. No text editors, but just edited there in the command line.

[Dio]

Yeah. Although initially I pushed back at the idea of merging shell and programming language, most advanced shells contain a programming language, and the idea of being able to define parts of the OS and shell (that aren't performance critical) in the contained programming language also gets more appealing as you add proper data structure management to the language, especially when the language becomes powerful enough to make that denser code than the equivalent asm and if you have good ROM banking techniques for disk expansion.

(And, indeed, Python in interactive mode works much the same way.)

[NorthWay]

Any interpreted language could probably have worked as the combined CLI/programming environment, at least as long as all the industry had agreed on the same one.

What I find fascinating about BASIC was that it was actually possible to use for making commercial releases, as long as you picked your genre with care. And in this case I'm thinking of text adventures which is one I care for very much.
I think a good number of early adventure games were done in BASIC(it feels like I'm screaming here, can you write it in lowercase?); I have one of the early Scott Adams games that I think was written for the VIC-20 and then just loaded into the C= 64 as the screen formatting is a bit funky.

[Dio]

Maybe in 1981? I can't think of many commercial ones on the Spectrum. A couple of things from the very early days but they tended to be graphical hybrids like Crystal Orb rather than parser adventures.

You can write text adventures in BASIC but it's inefficient. String handling and comparison is horrible and without much in the way of data structures you have to manage a lot of "data" with control flow. The adventure database systems like Quill and later STAC were far superior.

[KlaxonCow]

BASIC (it feels like I'm screaming here, can you write it in lowercase?)

Seeing as "Beginner's All-purpose Symbolic Instruction Code" is really a nonsense "backronym" and doesn't really stand for anything, in truth, other than conferring the idea that it's simple and basic, then I don't see why not. Call it "Basic", if you prefer.

After all, FORTH was never an acronym nor claimed to be at any point, but it's also an ALL CAPS kind of language.

Honestly, it's more to do with early computers not being able to do lowercase. Either at all, or at least not mixed with upper case at the same time. Then it's just tradition, really, to keep it going.

Why do I use the ALL CAPS names myself? Because names are proper nouns. They're like quotations - you're not supposed to edit them, or Anglicise them or anything. They should be rendered "as is".

And, as programmers, we're case sensitive people who see "wordcount", "wordCount" and "WordCount" as being different variables. Case matters - so if the case of BASIC, as we've always seen it, is BASIC then that's its name and "Basic" is something different.

One of the side reasons why I like C. It gave no shits about its name and was just "C" because it was derived from "B". No more to it than that. Mind you, that's still always a capital "C" but that works, as it's a single letter and would be capitalised as a proper noun by the rules of grammar anyway.

FORTRAN and ALGOL was always all caps too.

PASCAL / Pascal is interesting, because I've seen it rendered both ways - but I think the ALL CAPS version is because everyone was so used to ALL CAPS with every other programming language, they just followed suit but it was never officially thus. I think it was, with its "English-like" attitude, officially "Pascal" because that's how you write normal words (and the name of the person after which it was named). Yeah, Wikipedia renders it as "Pascal" throughout, though it renders ALGOL as ALGOL throughout as well, suggesting that Pascal does not require the ALL CAPS treatment.

I'm now tempted to create a programming language, simply so I can name it something that starts with a lowercase letter and has an uppercase randomly in the middle, to see if people will dutifully follow that convention. How about calling it "mCode" or, better, "zZz#" to include a symbol as well?

[skab]

BASIC was a great beginner's language, it's easy, immediate, and it uses a lot of GOTOs. How the hell that would be a great thing, you ask? It prepares you well for programming in Assembler, which is what you inevitably end up with. I never understood all the fuss about GOTO considered harmful and all that jazz...

Oh BASIC uses line numbers, how terrible. At the same time FORTRAN used line numbers for ages and that is still idolized as the scientist's language.

I would have loved to see a BASIC without line numbers, better flow control, and a proper full-screen editor back then, but as BASIC interpreters at the time were basically the first Microsoft monopoly, there was no real progress back then and everything stayed the same for a decade.

Upper-caps thing: Pascal is clearly a person's name, so it's lower caps. The rest is usually some sort of acronym. Forth might be an outlier, since early computers only knew upper-caps and all other languages were upper-caps, so they just went with it. Should be lower-caps.

[Dio]

I never understood all the fuss about GOTO considered harmful and all that jazz...

Dijkstra's essay is in good part smugly-written BS, but there is a more easily expressible point hidden away in it: unstructured control flow is harder to understand than structured control flow. To make sense of the control flow of a program you need to understand every possible source and destination of control flow change, and goto - especially line-number based goto - allows so much freedom in source and destination that the resulting code easily becomes very difficult to work with. There are idioms in which goto can be safely used and can be superior to the alternatives (error handling is the typical example) but goto is generally horrible.

If you want an example of this, think about how much people went on about flowcharts in the 70s and 80s and almost nobody ever does now. They were a way of trying to understand and design the flow control structure of programs written in a language that was both unusually reliant on flow control (in good part due to the lack of data structures) and also extraordinarily reluctant to have structure imposed upon it. Once BASIC went away, mostly so did flowcharts. Line number based goto and gosub are largely responsible for that, in my opinion.

[zip accident]

Forth might be an outlier, since early computers only knew upper-caps and all other languages were upper-caps, so they just went with it.

I remember reading a rumour that Forth would have beeb Fourth, but the micro it was written on only allowed 5 letters.

[KlaxonCow]

I would have loved to see a BASIC without line numbers, better flow control, and a proper full-screen editor back then

Once Microsoft did eventually progress in the MS-DOS era, that's exactly what we got with Microsoft QuickBASIC.



It had its own text-based IDE - a glorified DOS "edit.com" text editor, tailored specifically for QuickBASIC. You could even compile your BASIC code into an EXE.

I quite liked using QuickBASIC back in the day. It struck the balance between immediacy and a better structured BASIC quite well, through the IDE. Because of the IDE, there were no line numbers and it featured more structured control flow like WHILE and REPEAT / UNTIL loops. Note the "SELECT / CASE" in the screenshot above. It also had proper procedures (functions), which were named, not just "GOSUB [line number]". It was also possible to split code out over multiple files and, thus, the rudiments of "modules" were there.

Note also the "immediate" box at the bottom of the screen, so you could type stuff into that box to be executed immediately, like it was a command prompt.

Besides the more modern Blitz Max, it's probably the most fun I've had in BASIC and it was more powerful and structured than "GORILLAS.BAS" - the example game that came with it that everyone played at school, where you take turns to throw bananas at each other by typing in the angle and strength (like an educational version of "Worms") - would have you believe.



It also ran fast enough on PC hardware to do some interesting stuff. For a college project, I remember writing code - in Mode 13h, poking bytes at the screen memory at A000h - to draw a texture on a sphere, to make a planet and then have it spin. Nominally an "astronomy" thing, to show the planets of the Solar System with different coloured textures. It wasn't perfect, but it was actually a decent enough frame rate to get away with it. Doing sine stuff to work out which pixels to write from a texture.

As I say, it was fun and surprising how much you could actually make it do. It's still BASIC, so remained pathetic compared to assembly, but on 386 / 486 hardware, it was plenty fast enough for lots of interesting little "graphic demos" I liked to make at college.

I know it's terrible in all sorts of ways, but I have a soft spot for BASIC. And I really do miss having more "immediate" programming languages like that.

[venusian]

On my list of stupid projects I'll never do is a 16K ROM IDE for a language for the Amstrad CPC. It'd be fun to see what could have been done with enough time.

The Enterprise 64/128 is an interesting case though. BASIC came on a separate 64KB cartridge. Programs were edited using an in-ROM editor/word processor which was shared with other languages (so, it's not in the 16KB of BASIC). It had proper control flow structures, functions, exceptions etc. And 8 separate programs in memory at once. And channels for IO handling. It sounds pretty wild for a Z80 machine in1985.

[Barney]

I love BASIC, particularly Sinclair BASIC because that's the first I picked up. I got my current job because I wrote an interpreter for it for Windows PCs.

It's great fun: https://www.youtube.com/@ZXDunny/videos

Though it's little more than a toy, really.