Early on, I used to use T for my FOR loops, simply because it was easier to type NEXT T. Why it wasn’t R, I can’t say (same logic).
I remember my father lamenting that MS-BASIC only recognized 2 characters for variable names. He’d used up A and AA, and wanted to use AAA. (Note, he didn’t exhaust AB-AZ or A1-A9…). AAA is easier.
You can build a full size X-Wing fighter using just normal Lego bricks, but that is not practical for most people. I think of huge systems built in Basic in the same way.
What are separate languages or dialects of the same one is a very subjective issue. Not many people agree with me that Self and Slate are Smalltalk even though the differences are so small compared to the huge changes between Smalltalk-72 and Smalltalk-80.
ZGrass was a very different language than Basic, yet it was defined in such a way that you could type in Basic programs from a magazine and they would work. I used a similar trick in my NeoLogo. If I understood correctly, you have to have a colon after labels (including numeric ones) in Visual Basic which would mean it wouldn’t run classic Basic programs without a bit of editing. To be fair, Fortran which is famous for its “dusty decks” has changed enough from one version to another that old code has to be rewritten.
Is that a heritage opinion or a modern opinion? A large system in vintage BASICs doesn’t look like systems do today. Like I said, I wouldn’t greenfield a BASIC system today. But we’re not talking about today, we’re talking about Retro BASIC. You think those PDP systems with BASIC out of the box just sat idle? Or the other gaggle of mini’s out there programmed by VARs for vertical markets? How many Dental packages are written in BASIC. Heck, how many Dental packages are STILL written in BASIC.
Back in the day, my Doctor (DOCTOR!) wrote his own back office system on a TRS-80 Model II. One guess what he wrote that in.
You seem to think that the folks building those systems made bad choices using BASIC out of the choices presented to them. Perhaps, they were uninformed decisions. Or, perhaps, that they saw the advantages of the language and its runtime over the alternatives, despite its drawbacks. Maybe my doctor should have used dBase instead. Maybe dBase wasn’t out for the Model II. Who knows.
BASIC did not start dramatically morphing until the early 80’s, and the momentum of the language as presented in the 70’s carried it far forward. BASICA and GWBASIC weren’t any great leap in the early PC Days. QuickBASIC was a jump, but it was more BASIC without line numbers than anything like Pascal. Most business BASICs simply stood out with better disk integration of some kind (like the ISAM integration I mentioned). THAT was the important part, that was the hard part in contrast to anything else like creating a entry screen or a report.
Having to make minor edits to the code is different from having to rethink the conceptual model of the runtime as presented by the language. BASIC is not Pascal. BASIC is not C. Put a 70’s BASIC programmer in front of Visual Basic and Pascal, and he’ll feel much more at home in VB than in Pascal. In VB you can write BASIC idioms and succeed, even if Visual Basic developed it’s own idioms.
70’s BASIC in VB is more idiomatic for VB than 70’s BASIC in Pascal. Pascal isn’t even close to BASIC. It takes more than block structure and named subroutines/functions to differentiate something like Pascal from BASIC.
VAX BASIC-PLUS, a very advanced BASIC, is STILL BASIC. A BASIC programmer does not have to use the advance features to use it. A TRS-80 BASIC programmer would be quite comfortable with VAX BASIC out of the box once they get used to the edit/compile cycle. You can probably get pretty far typing one of David Ahl’s gems in to VAX BASIC. Good luck porting Wumpus to Pascal if you’re an enthusiast wanting to play Wumpus vs a BASIC programmer wanted to port it to Pascal.
Early BASIC was a much better language for data processing than Pascal was. It had better facilities for routine data processing. Better I/O, formatting, some BASICs supported BCD arithmetic. I chose VAX BASIC over Pascal for a data processing task because BASIC had a much better interface to VAX RMS than Pascal had. In Pascal, it was a bolt on library. In VAX BASIC it was better integrated in to the language. My BASIC program beat the tar out of the competing Pascal program that was written. (Mostly because of how it was written, and had I done it the same way in Pascal – it still would have beaten the other – it was just a lot easier to do it in BASIC than Pascal).
Large BASIC systems tend to be disparate programs, backed by disk files, united by some ad hoc menu system, potentially CHAINed together. You integrate at the system level, not the subroutine level.
Most data processing is pretty straight forward. You can write sophisticated programs in COBOL, but most programs in COBOL are not sophisticated, because it’s unnecessary. BASIC filled that niche very well. Was cheap, approachable, “fast enough”, and available. My magazines were filled with BASIC programs, not COBOL programs back in the day.
It feels to me that we’ve got two different opinions here, both intelligent and with interesting justifications, and neither party is likely to change their mind. So it might be best to call it a day on the debate,
I don’t think our opinions are different, though my analogy might give that impression.
One of my implementations of my SuperLogo was in TI99;4A Extended Basic. The first implementation of Smalltlak-72 was in Data General Nova Basic. Jerry Pournelle’s accounting and tax system in CBASIC grew to be very large. And so on.
Speaking of Cobol, the equivalent in the micro world was dBase/Summer/Clipper. From the mid 1980s to the mid 1990s quite a bit of computing was done with those languages. For larger computers there was also MUMPS.
Once I was asked to fix a Basic program that was used to test suspension parts at an automobile plant. Though it wasn’t very big, it was messy enough that it was just simpler for me to start over in Turbo Pascal. The main reason for that was to replace the question and answer user interface in the Basic program with something slightly more GUI-like. If this had been a few years later, I could have made something nicer for a fraction of the effort with Visual Basic.
A contrast I like to make is between languages that are “flat” like Basic, Fortran, Pilot, and even Scratch and those that can grow like Forth, Lisp, Smalltalk and many others. A key difference is how much what you add can look like what is built into the language. But a programmer can waste a language’s resources. The first program in Pascal I saw was a chess program in the November and December 1978 issues of Byte magazine and it would have been more readable in Basic. They declared a large number of labels and used goto everywhere.
OK so perhaps one of you is saying it shouldn’t be done and the other is saying it can be done and it sometimes is. These are totally compatible positions!
Please, both of you, continue to post if you sincerely believe you are moving the discussion forward and are acknowledging the other’s points. Every time you post, you bump the thread, and everyone else gets excited that there’s something new and interesting to read. Please make sure they are not disappointed. Remember this is a public conversation.
I’m excited! My first language was (Integer, then Applesoft) BASIC on the Apple II, followed by either qbasic or GW-BASIC on a PC, but I have to confess that I have limited nostalgia for the language. It is very interesting to see different opinions about BASIC through a modern lens from people who clearly were more passionate about it at the time than I could muster.
It’s making me want to get one of the Digital BASIC disk packs for my PDPs working. 
BASIC was the hammer of the age. If you were working in data processing, versus scientific or engineering, and not on an IBM, you were likely using BASIC, especially on the smaller computers.
Even then I know my father worked on several projects using embed micro computers in the early '80s whose control programs were written in BASIC.
BASIC is like that girl in Jurassic Park “This is UNIX. I KNOW this!” She was instantly empowered to solve the problems of the hour. BASIC was that tool for many. Accessible and empowering.
10 PRINT "HELLO WORLD"
RUN
Beats the heck out of K&Rs example any day of the week.
Could my Doctor have created his back office system using FORTRAN IV? Honestly, I doubt it. Folks learned BASIC out of comic books. I never saw David Ahl’s 101 Computer Games for COBOL.
Just when we computerists were rubbing our hands with glee that the industry had finally driven a stake through BASICs heart, MS released VB3, and blew every thing out of the water. VB3 crushed the dBase/Paradox/FoxPro of the day.
And, appreciate, I’m not a fan of the language BASIC as a language. I’m a fan of BASIC for its impact on computing. For its empowering nature. For enabling Doctors to feel they can put their precious time in to something like writing their own system.
MicroSoft did it right putting BASIC in to Office. In Excel, in Access, Word. WORD! A word processor that runs BASIC. As amazing a legacy Lisp has in Emacs – it’s not BASIC. It’s still for geeks and graybeards. (I wrote a word processor in BASIC once…like I said – hammer.)
There were a couple of events in my career that I hold on to. One, working at a large industrial company, my friend and I were walking by one of the people that gets our reports. She was cutting up the green bar, with scissors, re-ordering the lines, and taping them down so she could photocopy them to make the final product to pass upstream.
“Uh, you know we can do that for you, right?” “You CAN!??” And, of course, we did – a really tough 2 minute change.
Another was a company that would run the AR aging report at the end of every day. More often than not, this other lady, an accounting clerk, would be there late in the day waiting for it. It was a long report, took, like a 1/2hr + to run, and then it had to be printed, and it that took it’s sweet time. Watching her one day, I saw here notice the report was done, and walk over to the printer, tear it off and bring it back. She then plopped the thick stack on her desk, opened it up to the last page, tore it off, and tossed the rest of it in to the recycle box.
She was just interested in the open balance at the end the report. The next day, I wrote her a report that gave her that single page, printed, in less than a minute.
Trust me when I say that these two changes really made these ladies day.
Here’s two folks, just doing their work, trying to get through the day. Where the machines that are supposed to make their day better just stand in their way. These things are supposed to empower people.
BASIC was instrumental in harnessing these machines for the greater good. Otherwise, they’re just room heaters.
I wouldn’t use BASIC today. I used it in the past as it was the hammer du jour. So, I may not care for the language, especially with todays alternatives, but I certainly appreciate for what it can do and what it did.
This very thing cropped up recently in a thread on 6502.org: it turns out MS Basic and also EhBasic silently ignore extra characters in long variable names, which can lead to bugs - in this case, a visible distortion in a Mandelbrot image. Which turns out to be unwittingly displayed in the background of a popular video:
(BTW sorry about earlier comments - I think now I might have been over-protective. But let’s please be careful! A discussion is an excellent thing, an argument less so. Be prepared not to have the last word. Be sure not to be talking past one another. Respect differences of opinion and of perspective.)
It is very easy to be misunderstood on the Internet. If you imagine that I don’t approve ofpeople building huge objects out of Lego bricks or people using cardboard to build accessories for their Nintendo Switch then you would naturally think I would be against large systems in Basic. To make matters worse, I often point out arguments against opinions I agree with since I feel it is important to think about all viewpoints.
For a year or so after I learned Basic, it was the only high level language I knew. When I got to use Fortran and Algol I really didn’t see much difference. Only when I got to Lisp, Forth, APL and others did I come to my current opinion. This was 1980/1981.
But in practice, I didn’t have access to any language other than Basic for my personal projects. So I continued to do everything in it for a few more years. And the limitations of using audio tape for storage were so great that the characteristics of the language were not a factor.
When I give talks about the history of free software, I always point out that there were several communities before GNU which shared software (not counting vender specific user groups). The grew around a shared programming language, a common computer and some communication scheme:
For printing listings in magazine pages, Basic was by far the best option. What would take some 10 pages of Pascal or Logo would easily fit into 2 pages of Basic, specially if you used multiple statements to pad most lines to roughly the same length. Some Basic listings did use indentation but that was not very common. The numbers at the start of each line really helped keeping track of where you were on the page.
The only thing that could compare were hex dump listings, but typing those in was just really annoying and you didn’t learn a thing since it was a black box. Though if you did it enough you started to remember opcodes for your processor.
It is fun to see listings once again being included in the magazine for the Raspberry Pi and other maker texts. Though the Scratch listings look very pretty, they take up quite a bit of space. C is more reasonable but still not very dense. Python is the closest to Basic as a magazine-friendly language.
One last aspect of Basic I would like to mention is related to a dimension of computing systems called “discoverability”. How far can you get by poking around in a system?
Obviously that depends a lot on the environment around the system as well as your previous experience. Lisp was very discoverable in the 1960s if you were a student at MIT, but not so much if you were at the University of Utah (see Alan Kay’s experience in 1969 at SAIL). Today we have the Internet with stackoverflow and much more, but what if you were all by yourself at home with a microcomputer in the 1980s and had very limited access to books?
I think that lack of discoverability is what killed Logo. Papert’s group would have a two week course for a bunch of teachers who then would go back to their schools and give weekend courses to other teachers who then would try it with their students. The students didn’t have the books, so they were limited to the trivial subset of Logo their third hand teacher remembered.
Scratch is very discoverable. The screen is divided into specific areas and every possible command is listed in the left pane from where you just drag it to the middle pane. Even Scratch’s older brother, Etoys, which is more open ended and harder to figure out was discovered by children in the original One Laptop Per Child trials who then showed their teachers who had no idea that it was there.
Forth implementations normally have a WORDS command that will list all other commands. That is a great start, but you don’t have a way to find out how to use these commands.
Basic has a limited and fixed vocabulary. Several computers took advantage of that to associate each possible command with a key on the key board.
It is true that these schemes were often created to compensate for how nasty the keyboards were, but the result was that they guided users into typing programs with the correct syntax, which is a huge obstacle for beginners that more experienced programmers don’t appreciate (it is the reason for the snap together block thing in current beginner languages).
On the subject of Logo… the only thing I took from it was Turtle graphics. The rest (list processing, etc.) more or less was left behind. And these days, I do like turtle graphics - to the point that I wrote them into my own BASIC as direct instructions.
But the whole “discoverability” thing (or lack of) was very relevant - even in the late 70’s/early 80’s - living in Scotland, it id seem like being in a void at times - desperately trying to find out what’s new and ordering magazines expensively from the US and waiting weeks for them to arrive…
These days? blink and you miss it…
-Gordon
It also made it easy to write a small, compact BASIC - the tokenisation step was effectively “free” as each button with a keyword on it directly inserted the token into your code. The LIST command was (and often still is) a de-compiler for the tokenised code.
-Gordon
I recently discovered(!) that the BBC Basic version 5, which is found in the RISC OS Pico distribution for the Raspberry Pi, has a HELP command. (Pico is nice because it boots in seconds to a black and white text screen with a > prompt, but has all the power of BBC Basic and some useful OS facilities too.) In the album linked below I use HELP to see Basic help and also *HELP to see the OS help. There’s also a quick benchmark to show how the two versions of Basic have quite different float performance - one version uses 5 byte floats compatible with Acorn’s 8 bit Basics, and the other uses 8 byte floats which are unfortunately soft floats and therefore much slower.
Interesting that it’s using software FP on the Pi - especially when the ARM supports hardware FP, however as far as I’m aware, it’s an ARM architecture/revision where the FP part is optional - this is why in the early days of the Pi, finding a Linux distribution that would use the enabled hardware FP was virtually impossible and why Raspbian was created with the intention of using hardware FP from the start.
-Gordon
AFAICT the situation in RISC OS is a consequence of the long history of this OS with the ARM itself. AIUI the ARM’s floating point facilities used to use an interface called FPA, which was changed to one called VFP, and unfortunately the Basic port seems to be pinned to FPA - which it therefore has to emulate on a modern VFP-equipped ARM. There’s a work-in-progress port of Basic to VFP but I haven’t yet been able to access it from the Pico mini-distribution.
Right. That all makes sense now!
-Gordon
I think, much of the awkwardness of BASIC is owed to the principal idea of a dialog and the edit/run-cycle. E.g., runtime-wise, storing any constants and target line numbers as text and to have them converted to numeric values at each visit is arguably dreadful. However, for a dialog using dumb terminals and most of the time spent in the edit/run-cycle, it totally makes sense, since it provides for a low-cost LIST command and easy re-editing. As do line numbers. For the same reason, blocks and procedures consisting of blocks (as opposed to single-line FN) are probably not a priority as they diverge from the single-line-edit paradigm.
For the time, it was a reasonable decision and it extended the idea of timesharing. And it was egalitarian as it didn’t require the rather arcane compile step. (Given the dialog nature of the language, this was also technically reasonable, since running an expensive compilation on every edit of a line wasn’t really an option.)
I’ve been thinking about a system for incremental compilation for basic-like language, though I’m not sure if it quite counts as it does a second pass once the program’s running.
My plan is, at line entry time, the line is tokenised so you have tokenised source, and there’s the first pass of compilation, which calculates the size of the object code for each line.
When you run the program, the system adds up all the sizes, computing the location of the object code for each line, and puts a stub there. What the stub does is compile each line the first time it’s needed (JIT).
So as each line is run for the first time, the stub calls the line-compiler to replace itself with the fully-compiled line. By this time, the object-code location for all lines are known, so GOTO commands can compile them in.
For the object code, I was thinking forth-style words, so maybe tokens, or pointers to machine code, or pointers to a word structure that refers to machine code.
Variable names are translated to addresses in multiple steps.
At line entry time, variable names are translated into identifier indexes, which could be a one or two byte id. This is how it’s stored in the tokenised source. If it’s a new name, it’s added to an identifier table, otherwise the id for the name is looked up in the table. Note, being in the identifier table doesn’t mean there’s a variable allocated for that identifier.
You have a table of allocated variables and corresponding identifiers (could be included in the identifier table, or could be a separate table)
If you’re compiling a line that’s assigning to a variable that hasn’t been allocated, allocate it right away, then compile in its address into the assignment.
Since you only do the second-pass compilation when you’re about to run a line, if you’re compiling a line that’s looking up the value of a variable name, and the variable hasn’t been allocated for that name, that can be an error. This does mean that something like:
IF 1 > 5 THEN PRINT NOSUCHVAR
will give an error, but it’s simpler than having partially-compiled lines you need to run.
