I agree that dropping into the basic interpreter was amazing on the old 8 bit computers. Things have really changed recently with the popularity of Retro computing as I wrote about the exact same thing around 10-15 years ago (I can't find the post unfortunately) and I was downvoted a lot as almost all the commenters seemed to think that accessing DevTools in Google Chrome and entering Javascript commands was that same thing as the interactive Basic mode of a Commodore 64 in my case. Oh, how times have changed for the better now :)
“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.“
I genuinely feel that Dijkstra’s famous rant about BASIC had a big hand in killing it off. I don’t think it was the intention but it created so much bias against BASIC. If you created something in basic, or even suggested using it, someone would post that quote in the usenet thread. Like Godwin’s Law.
It’s a shame, because it was so accessible, not just because it was right there but also because it does make it very easy for beginners to understand programming in a way that structured programming doesn’t.
If there’s one language guilty of causing brain damage it’s surely JavaScript.
> "I genuinely feel that Dijkstra’s famous rant about BASIC had a big hand in killing it off. I don’t think it was the intention but it created so much bias against BASIC."
Seems doubtful? In the essay where his famous comment on BASIC appeared ("How Do We Tell Truths That Might Hurt?" https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD498.PDF), Dijkstra took a snarky swipe at many of the major languages of the time: PL/I, COBOL, FORTRAN, APL and COBOL and FORTRAN at least are still around. It was just what in modern parlance would be called a shitpost (no, really, read it), albeit more articulate than most.
I’m not sure Dijkstras quote had that much of an effect. Visual Basic was one of the most popular languages until Microsoft killed it.
Basic evolved to have blocks, scopes, procedures, and functions. Visual Basic is probably closer to Algol or Pascal than to the original GOTO-only BASIC which Dijkstra was complainig about. VB.Net has the same semantics as C# which means it is one of the most powerful languages available. But it is not really a good beginner language anymore.
Dijkstra wrote that in 1975 [1]. I don't think it had a major hand in killing off BASIC considering that "peak" BASIC occurred later with the home computer market. The vast majority of home computer users had no clue who Dijkstra was as they happily typed BASIC listings from various magazines and books.
For me the biggest motivation to not dip my toes too much into BASIC on 8-bit computers was the abysmal performance. If I remember right, assembler was about 100x faster, compiled high-level languages like PASCAL about 10x faster, and FORTH somewhere inbetween compiled languages and assembler.
FORTH could've been a very elegant alternative to BASIC on 8-bit class hardware, but one major problem with it was that having to enter absolutely everything as RPN/postfix notation could be very unintuitive at times. E.g. prefix or mixfix notation for some things such as math is only very slightly harder to parse, but then provides a big gain in user friendliness. And floating point math takes up a big chunk of the code in typical BASIC ROMs, so it was clearly regarded as important to duplicate that desk calculator-like UX.
At least on the C64, I use BASIC as largely a scripting language and master scheduler, calling 6502 machine language subroutines with SYS, and reserving BASIC for the very highest level main loop or non-speed-sensitive tasks that would be inconvenient, bulky or unnecessary to write in assembly. It gives me a scaffold to hang things off.
Learning quickbasic which was compiled in DOS as a kid pushed me to learn x86 assembly just to make pixels appear on screen faster. Its slowness was a feature for me in the end.
>impossible to teach good programming to students that have had a prior exposure to BASIC
As someone whose first exposure to computer programming was BASIC on an Apple II in the early 1980s when I was around 8-9 years old and who later went on to learn multiple other programming languages, I always wondered what about BASIC inspired that particular sentiment. Was it the line numbers? The GOTO statement? The use of "GOSUB.....RETURN" rather than explicit functions?
spoilers: There was no GOSUB in the version Dijkstra commented on. There was not even anything else to put in an "THEN" statement than a line number ("THEN 210" is the code). If you wanted to store user's name in your variable, "n" was the name to go with, because "name" was not supported. And so on... :)
Interesting, I wasn't aware how much the language had evolved from the mid 1970s through the early 1980s.
However, this line in your article would seem to indicate that GOSUB was available in the original version:
>The first version of the language was extremely limited, compared to any later popular version of BASIC. The only supported keywords apart from math functions were: LET, PRINT, END, FOR...NEXT, GOTO, GOSUB...RETURN, IF...THEN, DEF, READ, DATA, DIM, and REM.
> If there’s one language guilty of causing brain damage it’s surely JavaScript.
In its detractors, you mean? (This was a perfectly reasonable comment until you got irrational at the end; even people who understand Dijkstra's comment but feel that we lost something should be extremely pleased that the thing that took BASIC's place is a language that supports structured programming and is otherwise as nice as JS.)
> If there’s one language guilty of causing brain damage it’s surely JavaScript
Hahaha. I largely consider JavaScript to be the new BASIC - not because you can learn how to do some fun or useful things with it in an afternoon, but because it is ubiquitous. Web browsers are everywhere, and nearly all of them have JavaScript. A lot of JavaScript's quirkiness and inconvenience seems to derive from its web browser/DOM environment. (It's probably still easier to write GUI apps in Visual BASIC.)
Also: I'm still disappointed that Python 3 removed the print statement, so that
print "hello, world!"
is no longer a program that works both in BASIC and in Python.
related: https://news.ycombinator.com/item?id=38743062 - starts with this quote and checks whether it even applied to the BASIC we talk about here. Points out at least a few of the advantages of the integrated BASIC environment.
It also never killed it off, and it wasn't a big rant - just a single sentence - either. He also ranted over a few other languages in the same list.
PHP, like JS, sees a lot of unstructured code relying on random global variables in the wild as well :)
I grew up typing programs from softdisk magazine, Compute! etc... into TRS-80, Apple II, Atari 800, and C-64. I still think JavaScript in a browser is better.
JavaScript is way more powerful than Basic on any of those 4 platforms. The canvas 2D API is way more capable and easy than what came with those systems. Even getting something like
<input type="text">
Was 50-150 lines of code in BASIC, by which I mean a text input line with a cursor and editing and not just BASIC's "INPUT" command which provided nearly zero editing support.
Libraries like pixi.js or three.js or p5.js etc make it trivial to get fancy graphics on the screen. Making something you can share it with your friends or the entire world with a link, even if they don't own the same type of machine running the same OS. Host them on codepen, jsfiddle, github pages, all free.
I loved my experience with Basic and those old machines but I wouldn't force my kids to learn that way.
It's hard to compare these, it's like comparing a shovel to an excavator.
If a browser had to be implemented in 16 KB of binary, and use at most 48kB of RAM when running, many of the APIs you enjoy having would not be there. And it's not even about features of the language itself.
There was a time when you could have both - the language and the functionalities of a browser - IE supported VBScript in script tags:
<SCRIPT LANGUAGE="VBScript">
<!--
Sub Button1_OnClick
MsgBox "Hello world"
End Sub
-->
</SCRIPT>
Except it's way less discoverable. The BASIC prompt was all you got on some 8 bits computers, so it made playing with it almost mandatory. Also everything was way simpler (less abstractions layers, no network) to grok for a young kid.
I picked BASIC in 3rd grade reading a "stolen" math book. I saw a bunch of 10 line examples in its pages and remembered that weird pc jr. cartridge that said basic. The cartridge seemed useless until that day....
my experience was I would not have learned anything without a manual and examples. There was no autocomplete so there was no discoverabliy and there was no internet so unless you bought a book or happened to have access to a library that had modern basic books you were out of luck.
VS Today wheer there are 1000s of websites that will teach you JavaScript and 1000s of free video classes and hundreds of thousands of free examples. JavaScript is several orders of magnitude more discovable than basic ever was
> accessing DevTools in Google Chrome and entering Javascript commands was that same thing as the interactive Basic mode of a Commodore 64
JavaScript is ubiquitous (which is why I consider it to be BASIC's de facto heir), but it's (much) less accessible than BASIC was.
And as good BBSes, user groups, and print magazines may have been for sharing C64 programs, the internet is pretty great for sharing JavaScript programs with people all over the world.
I feel like BASIC on my C64 was the last time I really, intuitively understood what my computer was doing when I was programming and executing software.
There are so many layers between me and the hardware today that I feel like I float above it, and that I just have to trust it all intrinsically.
I don't, really, and it constantly gives me this feeling of almost falling.
I can totally relate to that, and it is why I really got into WebAssembly. It is such a simple concept that you can understand it fully, easy to write by hand, create an emulator, and more. Feels like stepping back in time :-)
Well, it is amazing you can write something in a decent set of Javascript these days and have it execute mostly the same across Windows, Mac, Linux, iOS, and Android, irrespective of CPU architecture.
It is, but at the same time I know that if I re-run it in two years it will suffer from bitrot and ill have to futz around with it to get to run. I hate that a lot.
Surely by "re-run" you mean "try to re-build". If you write something that runs in the browser today (and you're not doing something dumb like using experimental or otherwise non-standard APIs), chances are extremely high that it will still work in two years. The browser is one of the most consistent, interoperable, stable software platforms that the industry has managed to produce.
Amstrad CPC (Locomotive BASIC) and the BBC Micro both had it. In the CPC implementation, at least, you could choose the starting line number and the increment, e.g. RENUM 100,5
Wow I just tried this out on an Electron emulator. It seems like the second parameter for RENUMBER is limited to a byte (255).
The first parameter is weird, though: if you put in a number that's too large, the system reports a syntax error. 10000,255 works, but 50000,255 doesn't.
Locomotive BASIC was also a very good BASIC implementation. I wrote a multiplayer game with background music in it, without having to resort to any PEEKs or POKEs like you would on a Commodore 64.
Microsoft BASIC for Atari 400 and Atari 800 (which is distinct from the Atari BASIC that shipped with those computers) had a `RENUM` command that would renumber lines. New line numbers would start at 10 and increment by 10. Those defaults could be overridden.
Don't know about other TRS-80 models but the Color Computer did have a RENUM command. It worked well as long as all of your GOTO and GOSUB statements jumped to existing line numbers. I learned quickly to at least stub out a REM line if I was going to add a jump to a sub-routine/code block that I hadn't written yet.
HC-BASIC, the common BASIC implementation on East German 8-bit computers (KC85/1../4, KC87, Z1013) has a RENUMBER command. Without args, it simply starts at the first existing line number and increments by 10. With args it was possible to move an existing range to a new starting line number and interval.
BASIC on the ZX was quite limiting, unless you were already enjoying 128K ZX Basic, or even better on CP/M for the +3A model with integrated floppy drive.
I see. I think I've heard that Microsoft's BASIC was fairly popular, and I recently also downloaded BBC BASIC for CP/M - BBC BASIC is widely popular, but the only downside of its good documentation is that it doesn't say which version each thing is supported in.
BASIC was an IDE even going back to Kemeny and Kurtz in the 60s. The upshot of that was, it was one of the first times nontechnical people would even countenance writing programs for a computer. Instead of having to use a keypunch to author the program and then submit the cardstack to an operator, you could author, run, and debug the program by sitting at the teletype and entering some simple commands along with your program.
Members of the Dartmouth football team wrote a football simulation for Dartmouth BASIC back then; a port of this game for microcomputer BASICs is available in David H. Ahl's BASIC Computer Games as "FTBALL".
I once read about an OS that booted before the floppy had fully spun up, and was inspired, only to discover when I tried it myself that at computer speeds, even with the floppy seek to load a kernel from a FAT image, it's actually rather easy.
(to be fair, I think media corruption was more common back then, so boot-time file system checks and other sanity checks may have been what kept mainstream boots slower?)
Loading speed for cassette tapes and floppy disks was measured in bits per second at the time (usually between a few hundred to a few thousand bps), that was just what the hardware could handle, even without expensive error correction ;)
Makes a lot of sense, too. Why would you even want to load data faster than you can read it on screen, or print it out on paper? That's just a waste for such a minor increase in overall speed.
Everything was in ROM: 16k BASIC, 16k operating system, optional 16k disk operating system. The 464 (“646” is a typo) shipped with a cassette deck, not a floppy disk drive, so there was no possibility of loading the OS from volatile storage.
> so there was no possibility of loading the OS from volatile storage.
There are exceptions to this rule: Sharp was known for their concept of "clean computers" (MZ series and X1), which came only with a simple monitor in ROM, while at the same time featuring just a cassette drive to load a BASIC interpreter (of which there were several flavors) from.
DDI-1. It was a package including the disk interface (with AMSDOS in ROM and CP/M 2.2 partly in ROM) plus the drive itself. The FDD-1 was an optional second drive but you had to have the DDI-1 first.
Wow, I had no idea! There might be a 664 in box in my parent's house somewhere -- although it also might have been discarded some time in the last 20 years (as I imagine happened to many of them).
More like less than a second after power-up to reach full usefulness at the command line.
These type computers did not need to actually boot their OS from a "peripheral" storage device.
They did not "boot" at all, they just ran the built-in OS/BASIC straight from where it was contained on ROM.
This was like the C64 which had its BASIC in internal ROM too.
With the early Atari's the internal ROM was more like a skeletal BIOS which ran whichever ROM cartridge you had in the game slot, whether it was a commercial game or not. And the Atari BASIC command line was only available if you had the BASIC cartridge inserted where a game would otherwise be.
...that's pretty much what "booting" means though. Even on those hardwired machines with operating system and BASIC interpreter in ROM, the hardware still needs to be brought into a defined state (IO, timer, audio and video chips need to be initialized, interrupts need to be setup, the operating system needs to initialize portions of RAM used for keeping variable state, also checking what peripheral devices and hardware modules are connected and initializing those, and so on and on...).
on the Amstrad computers, and that's the context, BASIC was an interpreter on top of AMSDOS, which is a DOS, and an OS (just without any UI) indeed.
It's AMSDOS that provided hardware and disk handling, while BASIC could focus on running BASIC code. I think even the graphics routines (like setting a pixel) may have been implemented in AMSDOS, but not sure - and the line between two is blurry from user perspective. While those are two ROMs by two companies, they were developed in cooperation.
> I think even the graphics routines (like setting a pixel) may have been implemented in AMSDOS
Since I just have the CPC Intern book lying around on my desk :)
The graphics routines were not part of AMSDOS, but of the GRA ROM pack (the CPC OS was modularized into "packs" each coming with a standardized interface jump table: Kernel (KL), Machine Pack (MP), Jump/Restore (JRE), Screen Pack (SCR), Text Screen (TXT), Graphics Screen (GRA), Keyboard Manager (KM), Sound Manager (SOUND), Cassette Manager (CAS), Screen Editor (EDIT).
The book doesn't tell much about the AMSDOS ROM, only that the 16 KByte ROM is split into 8 KByte for the actual AMSDOS, and the other 8 KByte are used for a part of the LOGO interpreter coming with CP/M 2.2
PS: also important to note that not all CPC models came with the AMSDOS ROM or builtin floppy drive, so the actual operating system and BASIC interpreter couldn't be built on top of AMSDOS.
> PS: also important to note that not all CPC models came with the AMSDOS ROM or builtin floppy drive, so the actual operating system and
Right, technically correct! On the other hand, the command to return to BASIC from CP/M was "AMSDOS" - the distinction to be seen by the user was to be AMSDOS vs CP/M as two operating systems.
As it was understood with 1980's microprocessor desktops, booting was a more complex stepwise startup procedure than simply running the fully-functional factory OS or video game instantly from ROM.
Booting required a storage medium other than memory (such as punch cards, paper tape, magnetic tape, disks) to peripherally store the actual OS or shell which had to be loaded into memory in a "bootstrapping" process before it could run. RAM was used for the working OS rather than ROM, so process control was "booted" to RAM right after the ROM code merely establishes a hardware interface and serves as an Initial Program Loader.
Nobody ever talked about "booting" a C64 or Atari400 if all you were going to run was the factory BASIC command line.
Which was the vast majority of non-gaming use. Far fewer users had external storage to begin with and almost all of them used it only for storing & loading their own code or non-ROM game files [0].
Only the uncommonly advanced operators (not me) were actually using their external storage to "boot" to a different OS or programming language, but it was necessary if you were going to use something like Pascal [1]:
"Kyan PASCAL consists of two programs: the editor program (ED) and the compiler/assembler program (PC). When your Apple (ATARI) is booted (to boot the ATARI, push the <OPTION> key during power-up) with a KyanPASCAL disk in the drive the following will be displayed:
KYANPASCAL VERSION 1.0 COPYRIGHT
1985 BY KYANSOFTWARE
1850 UNION STREET, SUITE 183
SAN FRANCISCO, CA 94123
>"
IOW when you didn't push the <OPTION> key during power up (which very few users ever pushed) you weren't booting the Atari, but merely powering up and running the game or command line directly from ROM.
It was not like an x86 PC which used its ROM firmware mainly as an Initial Program Loader, otherwise known as a bootloader, to load your desired OS from storage into RAM, giving you access to a correspronding command line the booting way. If you weren't going to run something like a Disk Operating System why would you want to boot anyway?
It may be obvious but I really did like it with computers that you didn't need to boot.
Sorry if I hurt anyone's feelings.
[0] so BASIC was dabbled in more often and widely as a "game" similar to the regular game cartridges, where they had to start from the beginning each time you turned on the computer, and all progress was lost when you powered down.
One important aspect TFA is not explaining is that you could move the cursor around the screen and edit and re-execute any command or program line. So it wasn’t just a linear REPL. And it didn’t have history nor typically copy & paste.
The screen editor was a feature of specific BASIC interpreters though, for instance the BASIC on Acorn Atoms didn't allow it (AFAIK only later on the BBC Micro). Some BASIC screen editors also had a primitive form of copy/paste.
I remember when I finally figured out the point of GOSUB (I was maybe 13, so 1986), and why it was more powerful than GOTO. Still no stack, and the only calling convention was that RETURN would take you back to the line after where you called GOSUB.
Writing this words now, I don't know that I ever looked into what happened if you called GOSUB from a GOSUB routine, or how deep you could call. That would imply some sort of stack!
Prints a "Memory full in 50" after printing level 84. At first I thought it dedicated about 168 bytes for GOSUB stack, but the "memory full" happens on the level assignment.
You can erase this stack explicitly by calling `CLEAR` (will also close open files and clear ALL variables).
Does the RETURN statement work correctly on Amstrad when there are multiple subroutines in the call stack? I.e., does every RETURN return to the line after the corresponding GOSUB or after the latest one?
Coverting GOSUB X:RETURN to GOTO X was my first tail-call optimization.
> I don't know that I ever looked into what happened if you called GOSUB from a GOSUB routine
I want to say all BASICs had a stack (not sure about Apple Integer BASIC), or used the CPU stack. Expression evaluation also used it, and if you overflowed it you would get a ?FORMULA TOO COMPLEX error.
Applesoft BASIC allowed nested GOSUBs. I think you could get about 10 deep, if memory serves. You could absolutely do recursive calls. You would have to implement subroutine-local variable scope yourself. (I would have use arrays with an index that incremented at the beginning of each call and decremented before the RETURN.)
Applesoft BASIC was by Microsoft so it is pretty much identical to the other 6502 Microsoft BASICs like on the Commodore and OSI systems. Apple and Commodore both customized their Microsoft BASICs somewhat. If you benchmark Applesoft BASIC and Commodore BASIC, on systems with the same clock speed (eg. 1 MHz), they benchmark the same.
Similarly, I’ve heard some people call early Forth systems of the 1980s to be complete operating systems, which I would agree with. Many of them shipped with tiny editors, block management systems, and multitaskers. It was one of the most interesting eras of computing.
Always thought the raspberry pi was missing a trick by not just dropping straight into basic. It is supposed to be a learning tool, Linux is a brick wall of a learning curve (imo!)
Anyway it's been a very long time since I used my raspberry pi, maybe this is now a feature.
BASIC was my door to programming and computers. I experienced it in my 7th grade in the late 80s when I had the fortune of one of my friends owning a Commodore 64. What a thrill it was, so many weekend afternoons vanished into thin air...
I got started on a CPC with Locomotive BASIC before upgrading my system with disk drive, 256KB RAM pack, ROMS, and CP/M 2.2 and then 3.0. Sought out CP/M because of the amount of free software already available. Programmed in BASIC, BCPL, and eventually C (not a great fit for the Z80). It’s hard to express the value of this learning experience to young users today.
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
As I commented in another thread, the idea of being permanently damaged by being taught the Wrong Thing is a misconception about learning. Yet most of us are where we're at by having survived many such things.
I hope Dijkstra was being humorous. I used to wear his quote as a badge of honor.
I've dug deep into that quote and it wasn't even so much about the BASIC we know from the 8-bits. ;-) He also criticized every other major language at the time, except Pascal and (slowly emerging) C.
I know. I think he was just taking the piss and I love it. And yet, there's more than a grain of truth in this quote and in other salty aphorisms from Dijkstra, especially:
"The tools we use have a profound influence on our thinking habits, and, therefore, our thinking ability."
I went from Basic to Pascal to C/C++ to Java to Python which bear more than a passing resemblance to one another. Am I habituated to overlook or discount other programming paradigms, like Lisp, Prolog, and Forth? I can tell you with certainty that I once was. My view was even more limited then than it is now, and yet at that time I thought I knew everything worth knowing.