BASIC co-creator Thomas Kurtz hits END at 96 Professor Thomas Eugene Kurtz, co-inventor of the BASIC programming language, has died aged 96. Along with his colleague, John Kemeny, Kurtz's work revolutionized computing, operating systems, and programming language design. Kurtz was born in Illinois in 1928, and died last week in a hospice in New Hampshire, the home of …
Same here - my first programming was in BASIC on an RM-380Z back in around 1980, followed by a ZX-81 (bought with earnings from a holiday job).
The knowledge gained was useful when I was presented with some FORTRAN programming tasks in my first IT role, once I managed to get used to the rigid syntax!
RIP Prof Kurtz.
Me, too. Slightly earlier using HP Time-Shared BASIC. It used to be possible simply to wander into the Computer Lab at Newcastle University and sit yourself down in front of a KSR33 teletype (or an ASR33 if you wanted to save your program on paper tape) and use the system without any account or authorisation. There was even a built-in language tutorial. As a schoolboy, I wouldn't otherwise even have thought of a career in IT. So I'm grateful to everyone who contributed to that possibility.
Times have changed in so many ways.
Introduction to computers loses something without the venerable Model 33. Waiting for your program to print out gave you time to consider what to do next. And the sensory inputs were just as important...the vibration, the sounds, the smell of hot oil.
I repaired them as a job when I was an undergraduate. Had my own personal one in my dorm room.
Yes, the sounds, vibrations, and smells were a wonderful part of the computing environment, but I found the Teletype Model 33's keyboard action hurt my finger bones (I typed on those things a lot. A successor to the Model 33, the Teletype Model 43, was easier on the fingers, but was like needles on one's eardrums with its piercing screech.
I picked up a used Model 33ASR for £5 at a church rummage sale, and interfaced it with a simple circuit, as an output-only device, to my Commodore VIC-20.
My first experience of programming was in Fortran IV on Glasgow College of Technology's IBM360, submitting packs of punch cards for overnight batch runs. Very frustrating when you make a typo on one of the cards & find out when picking up the results the following day!
I quickly discovered the Time Shared BASIC running on the Data General Nova that they also had, and the joys of interactive programming.
That led me to Sinclair BASIC on ZX Spectrum at home, then Z80 assembly followed by C at work.
I'm not a programmer, I'm an electronics engineer but, what I learned from BASIC programming stood me in great stead in my career.
So, thank you indeed, Professor Kurtz, for all that you unknowingly did for me, I will not forget you.
I cut my teeth in BASIC.
Did a lot of things in it. Point of Sales programs, budget management, art, music, even crude information retrieval systems (anyone here remember DataQuest? In those days there were so many BASIC dialects that programs written for one computer will NEVER run on another, either partially or at all. To my dismay DataQuest was never available for IBM BASIC, which is a shame since the PC had a nice 80 column, 16-color text mode display. It was also the most common type of computer in Malaysia. So I took it upon myself to write a PC equivalent). I even had a crude CLI shell going at one point. Lots of good memories.
Sure, the jump to Pascal was a shellshock (no GOTO damn it!), but it made me what I am today.
RIP sir. Thank you for the music.
I do love how the LGP-30 brochure describes it as Small, and Mobile (presumably because it was on castors)!
Like a lot of people out there of a certain age, BASIC was where we cut our programming teeth as the first high level language we used, mostly because it was on pretty much every home micro by default.(Unless you were one of those people who had a Jupiter Ace!)
All made possible by Kurtz and Kemeny's decision to make the language public domain rather than controlling it.
I didn't have a Jupiter Ace either but I read about it and Forth at the time it came out and something stuck with me. Several decades later I wrote a little stack based expression evaluator (RPN basically) and it just seemed incredibly obvious to implement the stack manipulation words like SWAP, DUP, ROT as well. The rest of the team thought I'd lost my mind with this extreme weirdness. It worked exceedingly well however and became the core of our test verification predicates...
Yeah. There's various paradigms and Engineering dictates that for a given tasks there's optimal paradigmatic choices...
It's most likely that a Forth like stack based programming environment was an optimal design for your problematic. At least, as valid and optimal as the other possible optimal solutions.
Engineers may be as prone as anyone to stubbornness. You were right to follow your own genius . :-)
Also multiply/divide time is about 60x add/subtract time.
This was before the days of RAM - memory wasn't necessarily random access but read off a magnetic drum as here or stored in delay lines as in the Pilot Ace. This meant that the programmer had to optimise where values were stored to avoid waiting for the drum to come round for next access (worst case almost a whole rotation). The ALU would effectively be 1-bit but clever use of hardware enabled some operations to be parallelised.
For the amount of hardware (113 tubes ~= 250 transistors), very productive.
Multiply and Divide were implemented very simplistically, and reliably, and with as few logic gates a possible. In essence each tended to operate exactly as long multiplication and long division worked as we were taught in schools at the time (shifting and adding). This process while reliable was rather time consuming and add in the need to reduce the number of logic gates used to a minimum wound up as a repeated sequence of the same (micro) operations all controlled by the algorithm of the original operation. With the capacity to add more logic gates it became possible to optimise these operations and a lot of very smart thought went into how to do this so more of it could performed in parallel rather than in sequence.
A multiply or divide took one revolution of the drum. The LGP-30 was a bit serial machine. By properly positioning the instructions and operands one could get the speed up to about 200 instructions per second. Otherwise it ran about 60 instructions per second. It had a drum memory of 4096 31-bit words. The accumulator, instruction register, and program counter were also recirculating registers on the drum. A fun machine to work with.
I wouldn't say "other", Mel Kaye has always been inextricably linked to the LGP-30.
Many of the weirdos reading here (self included!) might be interested in knowing that SIMH has a very, very good sim of the -30 (and the later LGP-21). Fun way to while away a rainy afternoon or three, especially if you're feeling nostalgic. Last time I checked, it ran Mel's blackjack program quite nicely.
I am utterly charmed by the LGP-30 brochure. I love the idea of wheeling this thing "smaller than a desk" to the engineer concerned. And those diagrams of the potential uses are a masterpiece of sparse but insightful illustration. It gives just a glimpse of how revolutionary such machines must have been.
RIP, Prof Kurtz.
> Stored program operation means greater flexibility as all programs may be internally self-modifying.
Self-modifying code *can* be very space-efficient, with small op-code sets like this, I suppose, but all I can say is that I tried it once (6502 assembler) and it almost scrambled my brain.
Alright, which one of you at the back said "Almost?!?"
My COSMIC ELF(?) with an RCA1802 processor had one instruction that if set up right, would load itself into the next program location to the end of memory.
Mine had 4 K of ram and I wrote assembler on paper, but I then wrote in the HEX code for the instructions so I could enter it. I bought a BASIC interpreter for it, but I only had the HEX keypad for input. But it had a "graphics" chip so I could do B/W bitmap on a TV.
This post has been deleted by its author
Yep, I wrote an ARM emulator for the Acorn Archimedes as I wanted to be able to watch what the code did, and do things like setting breakpoints in ROM.
It worked by copying the next instruction into the emulator code (after checking it wasn't a jump etc.) then executed it and analysed what registers etc. changed and what the new values were.
<hand raised>
I wrote a program for the above mentioned DG Nova system that used 8KB of core storage which caused a bit of a problem as multiple people started to use it since the Nova only had 10KB of core & the disk/core swapping caused it grind to a halt when user number exceeded 3
Unsurprisingly, the system technician asked me to make it smaller but I didn't know how to chain programs as subroutines so I devised a scheme where subroutines in text files were loaded as program modules that overlaid each other (literally overlays).
For this to work, every overlay module had to have *exactly* the same line numbers....
"Self-modifying code *can* be very space-efficient, with small op-code sets like this, I suppose, but all I can say is that I tried it once (6502 assembler) and it almost scrambled my brain."
Some early processors only had constant addresses for jumps, so to return from a procedure call, the caller would modify a jump instruction at the end of the procedure to jump to the correct place.
I, also, tried self-modifying code on a 6502 when making a sprite routine for my BBC Micro. To allow the sprite to overwrite, XOR, OR, or AND with the screen contents, I modified an instruction in the code for this operation. The alternative would have been either several almost-identical copies of the code or slower operation, but both memory and clock cycles were limited.
Yes - I programmed DOPE on the LGP-30 in 1962. Tom Kurtz just threw an LGP-30 manual at me and said, "go to it." My first program played NIM and then in the Spring term I wrote DOPE and then discovered that Kemeny had a freshman class use it to verify that amateurs could use a computer. Tom was always smiling and enjoyed life. The actual time sharing system was programmed by undergraduates John McGeachie and Mike Bush and went online in 1964. Tom Kurtz was an excellent statistician and mathematician. He was always ready to talk with anyone. I knew him for many years. He will be missed.
BASIC on a ZX81, then Commodore 64, (then 6502 assembly), then BASIC again on a commodore PET, then on the first IBM PCs. Then BasicA, GWBasic, Husky Basic, Visual Basic multiple versions, VB.Net, DEC Basic, all interspersed with other languages, Fortran 66, 77, COBOL, Clipper, C, C++, C#. Happy days.
Pretty much identical for me.
My maths teacher and I bonded at school (I hated him!) when he read the Z80 machine code snippets I had been writing in the back of my maths book to do screen scrolling and the like! We began swapping tips and tricks. Next thing I knew I had unlimited access to the school's computer room - BBC model B's, PETs, C64's, and a couple of Speccy's and ZX81s!
My love for computing crystalized because of BASIC programming. Being able to give the computer instructions and watch it execute and obey them was the greatest feeling.
I had been into electronics and had been following the various electronics magazines (Practical Electronics, ETI, Elektor etc.) when they had started exploring microprocessors in the early 1970s before going on to develop their own systems. By the time I had my first hands-on experience with a computer (Commodore PET 2001-8) I could already understand BASIC programming. The first program I received payment for was a payroll system written for a PET with disk drives written for the PCB company I was working for.
After BASIC came 6502 assembler, some 6800 assembler, Pascal (when I moved on to programming Burroughs B20/25 systems), C, TurboBASIC, Modula-2 (for a later university degree), C++, Java (which I learned in order to move to a better job), Visual C++, HTML, JavaScript, Perl, PHP and countless others dabbled with. For a while, I had two broken Jupiter Ace machines from which I built a single working one. Forth was "interesting"!
Fun days!
On starting work in summer of 1978, first assignment after induction was to go on a course on "Instructing the instructor". Couple of weeks later off to Bristol to run a customer course on BASIC (XEROX Sigma variant of BASIC, whoch I'd not run across before starting this job) - having attended my graduation ceremony in between!
Best bit of that course was the run on the Great Western mainline to Bristol on a then almost brand-new IC125 (High Speed Train) in First Class - no 1st class trips on a student railcard before that!
It was me also, learning BASIC still at school with line numbers and all that.
I got my first job on the basis of that tiny knowledge. So ignorant I was that in my first job I sat down at a DEC VT100 terminal (disconnected) and with ECHO on, I tried to type in BASIC code, because I imagined that was how all these things worked.
The worst part is coming back to something you did ages ago and try to figure out what you did - although it's not as bas as APL !
And just like BASIC, it's still going https://www.forth.com
I remember attempting to write a FORTH interpreter in 8086 assembler for fun ... with only 4k available - those were the days.
[Author here]
> And just like BASIC, it's still going
More than that. There is successor language, which uniquely uses colour for syntax.
https://colorforth.github.io/cf.htm
It can, alternatively, use type styles for colour-blind users.
And creator Chuck Moore has massively-manycore chips, programmed, of course, in Forth.
https://www.greenarraychips.com/
Especially given the number of blue-blood frat/sorority nobs at Dartmouth. I've been through there a number of times and the feel is palpable just walking down the main shopping street near campus. Pleasant, but you can smell all the money underneath it.
Well played, Drs K & K!
I never found FORTRAN a difficult language to learn, nor did the instructors in QUB. It had been decided that all the lab staff (included me as research assistant but not SWMBO as a research student) would go on a 1 week (i.e. 5 days) course in this mysterious computing stuff.
Compulsory courses did not go down well with me and that may have been how the timing of the previous week's field trip to Scotland for SWMBO somehow ended up with missing the Monday of the course. I never found out what they did on that day because all the programming was fitted in on the Tuesday to Friday and I had no sense of having missed anything. And it was easy.
Having said it was easy we were using coding sheets and punched cards with professional keypunch operators to join the two together. It wasn't something that would have been quite so easy dealing with the rigid line formatting at a terminal although I did, much later, use Microsoft's CP/M version. It also helped that FORTRAN was at its best with what I wanted to do with it - doing some calculations and producing nicely laid out tables of results to plot by hand. Nevertheless, a four day course surely makes it an easy language to learn.
Agree, Fortran IV was my second language (circa 1976), for someone who understood basic mathematical/logical thinking and flow charting, Fortran especially combined with the coding sheets was straight-forward.(*)
I think the process of filling out the coding sheets led to better code first time, than when we all got terminals and were able to directly key stuff in.
(*) COBOL is another language which seemed to make more sense when combined with the coding sheets.
"I've no idea why I kept them..."
Same reason I still have a box full of recordings of John Peel's Radio1 shows from the mid '70s through the early '80s ... on cassette.
Totally useless spools of slowly randomizing rust on Mylar, but I can't quite bring myself to chuck 'em.
Don't panic ... they were all digitized decades ago.
This post has been deleted by its author
I started with Algol, briefly, then moved to FORTRAN. My early BASIC experience was with the "street BASIC" on early micros, and it was so primitive it never really seemed useful. Eventually I found VAX BASIC, which was full compiled ANSI BASIC and was a real revelation. Fast, complete, really useful for string handling, it made me realise that it wasn't just a toy language for toy computers. RIP guys.
(the details)
It would have been in the very late 60s, and our (private) school got a connection (dial-up, ASR-33) to a shared PDP-8 at a nearby public (state) school which was a node in a scheme was called "Project LOCAL" and it was a (federally-funded, I assume) way to introduce high school students to computers. This was in Eastern Massachusetts, so the computers were naturally the low-cost DEC machines. I suspect DEC made them available at cost, as they later did with the PDP-11 for universities...the "get 'em early" approach to training future customers. Anyway, one school got a computer, and several others got a Teletype and a timesharing connection.
To an extent, it's a bit sad that every computer (or at least OS) doesn't come with an "original" BASIC, or something approaching it. Most languages, even those intended for teaching beginners, tend to be overly complex in my view. If you can't read the manaul in one sitting and remember most of it, then it's probably more complex than it needs to be. Adding support for GUI toolkits was the start of the rot :-)
I wonder if something like Bash could be considered the current equivalent of BASIC? :-)
Bash exactly exposes the punctuation craze, even worse than C.
Just because it comes preinstalled on most Unix like machines means little.
From a pedagogic point of view, Pascal, Ada, Java, C# or VB.Net are probably the best beginner's languages. Pupils should be shown the light before you take them down into the dungeons of C and C++. And of course there should be proper algorithms+data structures education, otherwise "learning a programming language" is rather pointless.
Pupils should know what variables and mathematic functions are. Which means that bothering 10 year old children with Scratch is not a good idea.
Scratch has variables and mathematic functions, all you needed to do was look at some of the things it can do in the right hands before posting (3D Pen Sketcher, Circles Raytracer, Fibonacci Sphere, Optics, Ragdoll Physics...).
was not BASIC, but close. It was (in 1976) COMAL, a BASIC-inspired language that had structured control statements and procedures/functions with parameters -- similar to the later BBC BASIC. COMAL ran on my high school's RC7000 computer (a rebadged Data General Nova), with ferrite memory and no screen -- we used a paper teletype terminal and punched tape.
I have programmed in many different BASIC variants over the years: Commodore BASIC (first on the PET 2001 and later on VIC 20 and C64), Sinclair BASIC, BBC BASIC, ABC-80 BASIC, BASIC for TI-81, and a few more. Of these, BBC BASIC was my clear favourite.
Without BASIC, the home computer revolution would have been very different. Few other languages could be implemented in a few KB of ROM. Forth was and alternative and used for Jupiter Ace, but it didn't get a huge following since Forth was too difficult for beginners. LISP might have been another alternative, but while a simple LISP interpreter can easily be implemented in 1KB or less, programs tend to use more memory than BASIC. LOGO was available for some 8-bit computers, but requires graphics or an external "turtle" to be interesting. LOGO also uses more memory than BASIC. Of these alternatives, BASIC is by far the easiest to learn, and it was sufficient for home computer programs that don't need other data structures than arrays.
From another site:
When asked about his work with Einstein, Kemeny wrote: "People would ask - did you know enough physics to help Einstein? My standard line was: Einstein did not need help in physics. But contrary to popular belief, Einstein did need help in mathematics. By which I do not mean that he wasn't good at mathematics. He was very good at it, but he was not an up-to-date, research-level mathematician. So he needed an assistant for that, and, frankly, I was more up-to-date in mathematics than he was."
and from an acquaintance:
"Yes, it's very sad. He was a brilliant man but he also was a warm human being. I wrote to him several times with questions about TrueBASIC (a language he and John Kemeny wrote to bring BASIC up to modern Dartmouth standards) and he always answered me with the correct answer and more than that, he gave me real world problems to solve and challenged me to solve them in BASIC and send him the resulting program. After I did, he'd write back and we would discuss alternate ways of solving the problem. He seemed to revel in our discussions. Even though I never had a class with him, I learned more about programming from him than I did in five years of college."
Being a kid of the 80s, I love BASIC. It was wonderful that pretty much whatever home micro you got for your birthday/Xmas in that glorious decade, you’d switch it on, and you’d be plonked straight into a BASIC interpreter. A quick look at the manual for the BASIC commands, and off you’d go! For us 80s kids, it was the perfect, gentle introduction to programming.
The early PCs generally came with a BASIC interpreter too (which was usually easy to find), so it does annoy me that modern PCs ditched including a BASIC with the OS years ago. Considering all the pointless cruft that’s stuffed into Windows these days (don’t get me started on Co-Pillock), would it really hurt Microsoft to re-introduce a minimal BASIC interpreter with Windows?
Even though I’m in my fifties now, I’m still happily playing with BASIC – for me, as a long-time Acorn user, BBC BASIC is my dialect of choice. Although during my work life I have also sampled the delights of compiled versions such as Microsoft QuickBasic and PowerBasic; discovering ‘compiled’ BASIC was quite a revelation at the time, I can tell you!
The screenshot was from the book Illustrating BASIC written in 1977 by my late father Donald Alcock. Back in the day, one of the key problems that computers were used for was engineering, specifically finite state analysis of columns, beams and slabs. The key tools programmers used to attack this were vectors (or array), the matrix and its cousin the tensor, and these concepts were therefore implemented in the languages of this era, Fortran and BASIC. The MAT READ statement you see is for reading a matrix data structure into memory. DATA was used for populating an array.
I remember, as I grew up, we discussed the compatibility issues of the multiple versions of BASIC and what he decided to include in the book - it was a very difficult decision. Anyway, this is what he wrote in the Preface:
"There is soon to be a standard for "Minimal BASIC" by the American National Standards Institute (ANSI X3J2), and "Specification for Standard BASIC" by Bull, Freeman & Garland has been published by the National Computing Centre, UK (1973). These have not yet had time to encourage everyone to fall into line, so the BASIC that you meet will probably not be standard. I have accepted this as a fact of life, and, in writing this book, kept at my side ELEVEN manuals - each defining a different BASIC. Four of these versions are available on big computers operated by international "time-sharing" services; the other seven on computers ranging from big to "desk-top". From these eleven manuals I have tried to discover and point out where BASICs commonly differ from one another and recommend ways of avoiding dependence on any one particular version. I have used the word "portable" to describe a BASIC program written with independence in mind - and treat the need for portability as an axiom".
At the time, as a civil engineer, he was writing an engineering-oriented OS that ran on a Ferranti (later ICL) minicomputer and so had access to a more fully implemented version of BASIC that implemented matrices.
Regarding compatibility and standards: Argh! it's amazing how little has changed over the years - I'm looking at you SQL.
This post has been deleted by its author
I had a BASIC program published in an Amstrad PCW hobby magazine. The program allowed you to write structured BASIC with not one GOTO or line number in sight, it would 'compile' your structured program with it's named subroutines into a BASIC program that the PCW would execute. But my first and fond memory of learning and using BASIC in earnest was the BBC Micro, which if memory serves, did manage structured BASIC.
Mid 70's we were taught some coding in school.
There were the cards that we had to use with special pencils- then send the stack off to Manchester University where they ran the code, and sent the cards back with the errors ( or deliberate attempts to smuggle in nasty loops that would sabotage the uni's computers). I have no idea what the language we used was called.
Also IBM supplied us with a training computer they were trying out. It was red and looked like the supermarket tills they made.- Probably because they were similar inside too. This was programmed with lots of numbers. There were the numbers that had to be laboriously entered by hand to create what I assume was the OS. And then the numbers that told the machine what operation to perform with the contents of what memory location, and where to place the result, which was the programme
I then did an IBM test, where they told me I had the aptitude to work with computers, but not be a programmer. I subsequently found from friends who did go into it, that they had practised before, whereas I literally wandered in off the street.
So I went for my other career choice ( teaching kids with reading difficulties), but also taught myself BBC basic, 6502 assembly and some other bits. And for several decades I did educational IT support and training alongside my day job. Literally, at one point, being the only person training school heads and deputies how to use the new shiny RM PCs that had arrived in their offices.
The first thing I ever programmed (in 1969 at university ) was an olivetti programma 101 https://en.wikipedia.org/wiki/Programma_101 which was a programmable desktop calculator (desktop in the same way a laserjet II printer was thought of as a desktop printer) followed very shortly afterwards by BASIC on a PDP-8 (complete with a fast tape reader!). Shortly after that it was FORTRAN on an ICL 1900 I think - 50 years is a long time to remember. I then never got anywhere near a computer for 10 years until I trained in COBOL in 1981 and got a job as a trainee programmer.
When IBM PCs were introduced it was back to BASIC on them including designing and writing programs interfacing with an IRMA card (3270 emulation) to interact with the mainframe programs written in COBOL and taking the output back onto the PC. The PC running BASIC was networked with other PCs running programs in C and interfacing with a NetWare server via token ring networks using IPX. A sort of early bespoke middleware I suppose between LANs and SNA networks.
Sounds clunky but it worked well for many years. I like to think of it as proper programming but it would probably make anyone used to modern design methods wince.
... these are pages from "Illustrating BASIC (A simple programming language)" by Donald Alcock, published 1977, a book that introduced a lot of people to BASIC, especially in the United Kingdom. (https://www.amazon.co.uk/Illustrating-Basic-Simple-Programming-Language/dp/0521217040)
The entire book was written and drawn by hand, and so could illustrate defective code with little bugs crawling over the mistake, or highlight important concepts.
This book introduced me to BASIC on the ZX81, Dragon 32 then Sinclair QL as a pimply preteen just getting started on my life's passion. If there was anything I didn't quite understand I would go and trouble the author for additional explanation. But then again, he was my father.
RIP Thomas.
For me, Sinclair BASIC on the ZX81 and Spectrum. Both came with superb manuals that took you right through BASIC programming. For younger readers, a manual is a printed book of instructions that came free with stuff.
How many of us owe our interest, passion or career in tech in great part to those two, for creating BASIC and for placing it into the public domain.
In the 80s it was a universal constant in computing. Almost everything had the ability to run BASIC.
RIP.
I think it was the right language at the right time (alright, released about 10 years before home computers, but still...). No other language would have been as accessible to the beginner and an interpreter could be fit into as little as 4K, although the original Dartmouth BASIC was compiled.
This post has been deleted by its author
I learned it around 1970. Took to it immediately and used it to try and predict how high my model rocket would fly. I read about it's inferiority and using GO TOs, etc but had little idea about why. In the 80s, I managed to use it at on a simple project to handle a data file at work. The sales department demanded they have it, which I kind of smirked at because it was pretty crude.
I really didn't learn much past that and thought my skills were pretty mediocre. I tried other languages, but never really advanced much.
Then I happened to look up Intuit yesterday and learned that the first version of Quicken was originally written in BASIC. Maybe there was more to it than I gave it credit.
I wrote a Unix clone in Locomotive BASIC (written on a CPC6128). One of the cornerstones was that Locomotive BASIC supported loading programs by line number range. Thus it was easy to write utilities - you just ensured that you stuck to a specific range of line numbers so that when they were loaded they didn't overwrite the OS' lines.
It had a version of NRoff which modified screen font definitions to emulate underlining, bold and italics when writing to the screen.
It had a compiler that faked procedure/function calls. Or maybe it should be a called preprocessor? I don't remember how I did that but I do remember using it to write some of the utilities and a couple of games using it. The end result was a normal Locomotive BASIC program that used GOTO and GOSUB I think.
I wrote an interpreter as well (unless that's what I'm thinking of above). One annoyance was that unlike Sinclair BASIC whose VAL$ function could evaluate entire expressions Locomotive's could only evaluate numbers so I had to develop an expression parser. That was fun and educational though.
it had a (very slow and limited) assembler and debugger using a fake CPU that I designed.
It was capable of multi-tasking using Locomotive BASIC's event handling and timers (though sadly when it was waiting at a keyboard input prompt they were queued up until the input was entered).
It supported slash terminated file paths by mapping them to the user areas on the disks.
I called it Centrox. To be fair it was slow in a lot of things it did but I enjoyed it and learnt a lot.
Every command or instruction in any computer language is just another program.
Even “machine language,” in which the instructions are programs that had been encoded with logic circuitry.
https://www.dartmouth.edu/basicfifty/commands.html
Basic has 15 main commands, 5 arithmetic expressions, and 10 numeric functions. Basic also has variables; arrays; string variables (just a special kind of array, with a handful of string-specific functions); plus user-defined functions.
All told, basic is a collection of probably not even 100 core sub-programs (none of which are all that complicated).
One thing that ticked me off, you could never do something cool like A=10:GO TO A, instead you could only do something like ON A GO TO 10,20,30 etc.
MSX Basic had ON A GO(SUB|TO) 100,200,300
Only gotcha of course was that the values of A were always 0,1,2 (could have been 1,2,3 - can't remember) for the example above. To get something like drawing program tool bar to work you needed to divide cursor coordinates so that values would fit. Cascading if to check if coordinates were within first button do this elseif coordinates were within second button etc was too slow.
Of course, it was Microsoft there, what did you expect ? Flood fill was especially slow and entertaining to watch. Especially when you left 1 pixel gap somewhere.
This post has been deleted by its author
This post has been deleted by its author
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
