Whilst BASIC encourages all kinds of spaghetti, I'm still convinced it is a better language than Python to start on. Control flow is so obvious to non-programmers when it has line numbers.
However there were user defined functions and procedures as I recall.
GFA did away with them entirely.
The BBC had an odd editor, it was partly line and partly screen based, allowing you to move a secondary cursor across the screen with the arrow keys, and then a ´copy´ key to copy whatever character was under the second cursor to the input cursor as though that key had been pressed. It sounds terrible but it was actually quite quick in actual use.
Personally I think it’s a bit of a stretch to say line numbers were mainly there for editing. Even if you ignore GOTOs the most common method of running pseudo-functions on the BBC Micro was GOSUB.
I remember trying it out at a British Council library which had one such machine available for members to use. Although I had done a little 6502 assembly language programming earlier (using both the PEEK and POKE approach as well as using an assembler), just for fun, on other home computers, I never got to do a lot of it, since by then, I moved on from BASIC and assembly to languages like Pascal and then C. Good times.
I’ve also got a few Amstrads CPCs - another range of British 8bit micros. They ran Locomotive BASIC which was largely inspired by BBC BASIC so there is a hell of a lot in common between those two dialects.
Interesting, didn't know that.
>I’ve also got a few Amstrads CPCs - another range of British 8bit micros.
Cool. Had read about them in computer mags.
I don't even recall a single time when I used that, the usual control structure for that was
Ditto 'proper' functions using DEF FN with parameters and a return value using the '=' sign.
So I think while the FN / FUNC approach was arguably better, I’d be surprised if it was more commonly used than GOTO or GOSUB. But who knows, maybe your circle of friends did things differently?
and the BBC manuals were pretty good. So was Newman and Sproull as well as David Levy's computer gamesmanship. And now that we are talking about this I do remember when I used the line numbers. I came to the BBC from the TRS80 Color Computer/Dragon 32, and that one had the good old Microsoft ROM basic, which did not have such luxuries.
It really clicked for me when writing a musical score editing program, that I tried to put together using the 'old' way and then tried it again using the 'structured' way. The second time around the program made it to completion and it was lots easier to understand so I never really looked back after that. So to me that became the 'normal' way of doing things but I totally see how it could be that this experience was not typical.
You are also right that they were not cheap, my fully decked out 'beeb' (double drives, 256K ram expansion) cost me more than a years worth of savings. But looking back it was most probably the best investment I ever made. It gave me a career.
I never used a Dragon in the 80s but do have a Dragon 64 packed away, waiting for me to hook up and play. I keep meaning to get it out but between work, family, and the other retro hardware, it sadly never gets a look. I’ve heard Dragons were nice machines though.
Yes, I think I paid £400 for mine.
Aside: Just looked up Kemeny in Google.
Interesting snippet from his Wikipedia page:
[ Kemeny's family settled in New York City where he attended George Washington High School. He graduated with the best results in his class three years later. In 1943 Kemeny entered Princeton University where he studied mathematics and philosophy, but he took a year off during his studies to work on the Manhattan Project in Los Alamos National Laboratory. His boss there was Richard Feynman. He also worked there with John von Neumann. Returning to Princeton, Kemeny graduated with his BA in 1947, then worked for his Doctorate under Alonzo Church, also at Princeton. He worked as Albert Einstein's mathematical assistant during graduate school. ]
And the company and BASIC dialect he created later were both called True BASIC:
That was a lot of other eminent people he was associated with :)
Static types and Object Oriented Programming are better ways, I think most of us will agree?
I want to give noobs a taste of the magic of programming immediately
10 Print "hello"
20 GOTO 10
Even the relatively simple
I'm with you on static typing but disagree with OO. I know other developers I strongly respect with every permutation.
Personally, I probably wouldn't object to OO so much if Java weren't such a commonly taught first language, which gets right back to the discussion at hand.
But bad Scratch vs good Scratch or bad Java vs good Java would be a fair comparison and in those cases I would advocate for teaching the right thing from the start.
I'm pretty sure you won't find near universal agreement on either.
10 PRINT "STEVE IS AWESOME!"
20 GOTO 10
But failing that my domain is steve.fi, and my email address is steve@.
Plus, mandatory line numbers is what enables having a REPL that's also a program editor, which is a big win.
Letting people crawl is a great way to teach them the advantages of walking.
What made it hard is you had to enter both an angle and speed and hope you calculated the right combination to hit the other player.
Eventually I wrote my own version of the game in flash/actionscript....but it’s long gone.
Another fun one was called Labyrinth (I think it was spelled LABRNTH.BAS or something). I liked it so much that years later I started making two remakes (one in HTML canvas/JS, one in DCPU-16).
QBasic was a great introductory language for a kid wanting to learn programming IMO.
You can show that the things a regex can compute are the same things that this kind of state machine can compute. I believe that most regex under the hood use such a state machine, so it's very natural to use regex to tokenize.
I know it isn't going to be the most performant approach, but if you're comfortable with regular expressions it's really simple, and performant enough for most cases.
The trick was first a parser, then use C++ objects for each construct and instantiate one for each parsed element. The objects had a 'list' and a 'run' method. They were linked in programmatic order. So run the first one, which returns the next one to run (since it may vary with IF, GOTO etc)
Here it is!
My personal take is here (over 7 year old code, beware):
And I wrote that just to make this functional:
(Try the "help" command.)
$ echo 'PRINT 3+4∗5' > test.bas
$ go run main.go test.bas
$ echo 'PRINT (3+4*5)' > test.bas
$ go run main.go test.bas
$ echo 'PRINT (3+4)*5' > test.bas
$ go run main.go test.bas
10 LET a = 3+4*5
20 PRINT a, "\n"
LET a = 1/0 SHOULD produce a division by error, so I think that's correct. But 1%0 shouldn't panic. I'll fix that.
Regardless, I really like this project. :)
go run main.go /dev/tty
I enjoyed Atari 800 BASIC, so it was modeled after that, tokenized during line entry so that it would not allow you to enter lines with bad syntax.
VAX assembly had instructions for spanning over characters given in a set or scanning to a character in a set, so string processing was very nice.
You should use floating point for the line numbers so that you can always insert more statements between existing lines :-)
This is super inspiring. Nice work.