BASIC was not just a programming language | Hacker News Reader

BASIC was not just a programming language

gcher.com

139 pointsguillaumec116 comments

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 :)

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.

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.

And all of your BASIC was in the manual, taught to you as soon as you bought the computer.

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

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>

“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.

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.

Perhaps forth for newbies wouldn't be too friendly... but you can totally write an infix parser in forth, and toggle in and out of that parser.

Look up the Jupiter Ace from 1982. A lot like a Timex-Sinclair, but with Forth as the built in language.

https://en.wikipedia.org/wiki/Jupiter_Ace

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.

So, basically how people use python now?

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.

> If there’s one language guilty of causing brain damage it’s surely JavaScript.

Why JS and not PHP?

they are both guilty

both, depending on adhesive tape usage

PHP stops you from being clever with it by making you angry at times. It's very predictable too, on its hardly avoidable, disgusting pitfalls.

But things may still change for the worse with that process of Scala-ification they are doing to PHP 8.x.

>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?

It was probably the lack of structure like blocks and scopes. Everything is flat and global and GOTO means control can enter and exit at any point.

I tried to answer it in the article that someone recently posted to HN as well - https://news.ycombinator.com/item?id=38743062

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... :)

Oh, and the line numbers were a necessity.

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.

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.

"Teamonkey's law" sounds good to me. Whenever BASIC is mentioned, someone will invoke Dijkstra's rant.

>If there’s one language guilty of causing brain damage it’s surely JavaScript.

I'm not sure about that. The only language that I felt led to bad things from developers was perl, mainly because it was so difficult to read later.

> mainly because it was so difficult to read later

But it wasn't, it was just so easy to write badly early.

> "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 joke that Real Programmers™ get their shitposts immortalized in ACM publications: https://dl.acm.org/doi/10.1145/947923.947924 )

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 :)

> 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.)

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.

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/E... - 18th June 1975

> 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.

> accessing DevTools in Google Chrome and entering Javascript commands was that same thing as the interactive Basic mode of a Commodore 64

It's not the same, it's better.

Author of parent comment here: As a funny side note, my current project for ten years has been JavaScript based :)

> 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.

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.

Yes, that's what I mean, thanks.

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 :-)

> If you ran out of numbers, the renum command would recompute all the line numbers for you.

This is the first time I heard of such a BASIC command, even though I grew up learning to program on a Sinclair ZX Spectrum.

Which of the home computers of the time had this command? Would it renumber in multiples of 10?

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

IIRC BBC BASIC let you choose the renumber increment, but the ZX Spectrum didn't.

For approved choices :)

> AUTO10,1000

Silly

> _

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.

Isn't it because the line number is 16-bit unsigned int?

Great clue. Thanks!

RENUMBER takes maximum parameters of 32767 and 255.

But line numbers wrap! So if you do RENUMBER 32767,1 then your line numbers will go:

This is even more interesting, 32767 is the max signed 16-bit int. And it wouldn't wrap to 0 after that for sure.

Btw does it allow 0? Amstrad's BASIC does not (oficially).

I no longer have an Acorn Electron, but using ElkJS (https://elkjs.azurewebsites.net/) I did:

  >0 REM
  >10 REM
  >RENUMBER 32767,1
  >LIST
  32767 REM
  0 REM
  >0 REM
  >LIST
      0 REM
  32767 REM
      0 REM

I asked a friend to test this on a real Acorn Electron. It behaved the same.

He also found some more info from the web and by trying stuff out:

  Hey, I confirmed this is the same on the actual machine so yep it looks like this was part of the ROM. I found a small amount of info, including that the maximum actual line number is 65279 (BBC BASIC V file format — Matt Godbolt’s blog (xania.org). It looks like the BASIC editor only properly dealt with lines up to 32767 (0x7FFF), including ANDing them with that when using LIST!

Weird things happen if you have a program with line numbers beyond 32767. LIST shows the wrong line numbers, RENUMBER doesn't renumber GOTOs properly.

MSX supported that as well

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.

Don't know which ones did. TRS-80, C-64, VIC-20, Atari 800, Apple II, did NOT

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.

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.

which BASIC for CP/M did you use? (there's a few, and there was no standard, so feature parity is not guaranteed)

CP/M already had compilers for BASIC, but I don't recall the name, I only owned a Timex 2068, the 128K were owned by other folks in our group.

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.

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.

https://archive.org/details/a8b_Atari_800_Basic_v1.0_1981_Mi...

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.

Commodore Plus/4, C16/116 and C128 had it (BASIC V3.5 and up). COMAL on the C64 also had it.

TI-99/4A had it, but not sure if it was included in TI BASIC or only on TI EXTENDED BASIC.

Can confirm - it worked in both.

RENUM was in GW-BASIC. So, any IBM "Compatible" had this for sure. It was also in Microsoft BASIC-80 so it would be in older machines as well.

The optional second argument would change the step size. The default was 10.

To add to the multitude of existing comments: the C64 did not have it, but the C128 did.

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".

> The Amstrad CPC 646 would literally take less than a second to boot

Wow.

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.

And Amstrad PCW had boot code in the printer controller, to save on ROM prices :D, and booted from a floppy only (by default to a CP/M as well)

You could attach an external floppy drive (I believe it was called FDD-1) to CPC464 and run CP/M 2.2 on it. https://www.cpcwiki.eu/index.php/CP/M_2.2

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.

They could have typoed '664', which was the 464 with a floppy disk drive. However there basic was still in the ROM.

Indeed. I still have my 664 in the loft somewhere!

They're worth quite a bit these days as they were rapidly replaced on the market by the 6128 (which is in my loft).

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).

It was a typo for 464 - you can tell by the video it links to.

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.

>literally take less than a second to boot

Literally, completely wrong.

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.

RAM and storage were almost all yours.

Define boot.

Booting doesn't require loading an os.

And if we include dos as an os, I'm not even sure of the conceptual difference between booting basic and booting dos.

The only major thing is device discovery and setup etc.

But even the 8 bits had to start up the screen output routines, so I would still classify that as 'booting'

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.

Btw. which book describes these internals? ;>>>

There was a popular book series in Germany called 'xxx Intern' where xxx would be a computer model. For instance for the CPC:

https://archive.org/details/cpc-464-intern-bruckmann-english...

(I have a physical copy of the followup book "CPC 664/6128 Intern", archive.org doesn't seem to have that one though)

Awesome, thank you! Appreciated :)

(Amstrad community is the main reason I am thinking of learning German and Spanish :D)

>Define boot.

Good idea. Legitimate request.

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.

[1] http://www.atarimania.com/8bit/files/Kyan_Pascal_Manual.pdf

> ...reach full usefulness at the command line

...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...).

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!

[edited to correct a typo]

Understanding the point of DATA was also a big breakthrough for me, but that happened earlier.

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.

On an Amstrad,

    10 level=1
    20 GOSUB 40
    30 END
    40 PRINT"Current level: ",level
    50 level=level+1
    60 GOSUB 40

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?

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.

IIRC the standard full install still includes Python with an IDE and some PyGame examples, right in the start menu.

RISC OS on the Pi includes BBC BASIC:

https://www.riscosopen.org/content/downloads/raspberry-pi

They used to offer a BBC BASIC-only image called RISC OS Pico, which you can still find on the Internet Archive and should still work on older Pis:

https://web.archive.org/web/20181109020203/https://www.risco...

https://web.archive.org/web/20181109020203/http://packages.r...

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.

Why doesn't somebody make a nice new BASIC computer where you can bit bang the hardware? Give BASIC some new keywords for Internet use, boom.

The Amstrad CPC 464 plus is what I grew up with. In the footnote sure it was fast to jump into BASIC but of course loading from cassettes took ages :)

So many memories with the family's beloved Sony MSX as a kid in the 80s.

Kind of sounds like Smalltalk?

RENUM? What!?!!?

"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."

--Edsger Dijkstra (1975)

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.

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

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.

And yet, I learned first on GW Basic and turned out to be a halfway decent programmer.

Compared to Dijkstra I'm quite certain that I'm a miserable programmer.

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 believe he was being humorous. Either way, I don't take it too seriously. After all, I also started programming with Basic.

Reply on news.ycombinator.com