FreeBASIC https://en.wikipedia.org/wiki/FreeBASIC is a modern, GPL'd compiler that implements nearly all of Microsoft QuickBASIC along with a bunch of extensions. Runs on *nix and Windows.
QuickBASIC was a rather nice BASIC dialect for its era, and you can write well-structured and modular procedural code. Along with a bunch of 2450 GOTO 410 lines, if you really want.
That's an interesting post. Minimal BASIC really deserves its name, being quite a bit more limited than even the ZX80s or VIC-20's BASIC variants.
Especially in the educational context, this lead to a lot of languages seemingly forgotten -- BASIC being too little, and the computers not having enough power for Pascal/Algol-W/C. LOGO was quite popular, of course, but anyone remember COMAL? It had line numbers, but mostly for editing interactively. Beyond that, you had full structured programming, a decent enough allowance for variable names and a rather verbose syntax to help you remember where you are. No semicolons required, turtle graphics included in most implementations. Short example:
0100 draw'circle(160,100,100,2)
0110
0120 PROC draw'circle(xc,yc,r,color)
0130 pencolor(color)
0140 circle(xc,yc,r)
0150 paint(xc,yc)
0160 IF r > 10 THEN draw'circle(xc,yc,r-10,color+1)
0170 ENDPROC draw'circle
One of my favorite languages of that era was Elan. Which, like most others, was slightly pascal-ish, too, but introduced refinements, a feature rarely seen since (literate programming preprocessors excepted). Also allowed ample usage of spaces in identifiers.
problem of pascal:
read the maximum;
start with the number 1;
begin with the sum 0;
WHILE number <= max
REP add number to sum;
take the next number;
ENDREP;
show the result.
read the maximum:
INT VAR max;
get(max).
start with the number 1:
INT VAR number:: 1.
start with the sum 0:
INT VAR sum:: 0.
add number to sum:
sum := sum + number.
take the next number:
number := number + 1.
show the result:
line;
put (sum).
We tend to do similar things with (maybe nested) functions and comments, but this puts it all on the language level, which also would make it easy to have the system prompt you for your missing refinements, and of course get by without passing parameters.
Now, replacing all that or more contemporary equivalents (like Scratch or Python) with a didactic approach that's pretty much centered on writing flowcharts beforehand is quite an idea. Which, by the way, is something we shouldn't forget when we compare languages: It's not just about its syntax alone, but how students are taught to construct and revise them. REPLs vs file-based, for example. This would have them draw the general structure and then encode that in GOTOs. I bet Dijkstra would feel torn about this…
It's easier to parse, especially if your language has lots of keywords that might be part of identifiers, like "begin", "end", "for" and "and" or "or". I think with the Algol-like languages it was mostly required to specially treat the keywords, either by quoting them, uppercasing them or writing them in bold (if supported).
But beyond that, I'm not sure that I want that in a "modern" idiom, where I get a whole bunch of compound words on the screen, like classes, objects, methods and variables. Spaces are quite easy to pick out as delimiters -- and I've actually heard that as an argument for CamelCase against snake_case.
Then again, I'm German so I might have a high tolerance for long strings and syntactical pain.
Change frightens me, so I find the idea of spaces in identifies shocking, but I'm curious if once you got used to the idea if there are upsides. Especially now with syntax highlighting, you could visually tell whether it was distinguishing keywords from your identifiers correctly.
The ALGOL family marks reserved words specially. How to mark them is implementation specific. Some require `all `keywords `be `marked `with `a `symbol. Others Require Keywords Be Capitalized. Some use a different font. (Yes, italics or bold can be semantically important in programming, it turns out.)
If all your keywords are specially marked, everything between them can be vacuumed up by the parser as-is. It's actually easier to parse than modern languages with space delimiters. But arguably worse to write.
ELAN was specifically developed to be used in the systematic teaching of programming to students in secondary education. As such it had very much the same goals as BASIC, but given that it was developed a decade later, and with one of the authors of the Algol 68 report leading the development group, it was much richer.
Some information for those interested is still at http://www.cs.ru.nl/elan/ and there's an implementation for the language there as well.
An interesting tidbit is that ELAN was used for the EUMEL system by Jochen Liedtke, who took what he learned to develop the L3 and later L4 microkernels; see also https://6xq.net/eumel/
QuickBasic is from 1990. ECMA-55 is from 1978, and even then it's explictly “Minimal BASIC”, not a remotely comprehensive language in that family even for the time.
This is fantastic. I learned to program back in the 90s using QBasic. It came with DOS and along with it a book very much like this PDF. I read through the whole book, entering every line of code in the examples, changing little pieces of it until I understood how it worked. Such good memories. I'll enjoy reading this. Thank you.
21 comments
[ 3.8 ms ] story [ 50.7 ms ] threadIt isn't a great language but it will go a fair way.
There’s also a GUI toolkit with an interface designer being developed for it: https://www.qb64.org/inform/
You can find the MSDos images you need on archive.org.
QuickBASIC was a rather nice BASIC dialect for its era, and you can write well-structured and modular procedural code. Along with a bunch of 2450 GOTO 410 lines, if you really want.
Personally, I've used:
* GW-BASIC / BASICA
* QBasic / QuickBasic
* Visual Basic 6
* Visual Basic.NET
* UniVerse BASIC / Unidata BASIC - these are quite similar and both descend from Pick BASIC
Each of these is a distinctly different language with very different capabilities, but they all share the BASIC name.
Just like C, C++, Objective-C, C#, C--, C@+ do in regards to C.
Especially in the educational context, this lead to a lot of languages seemingly forgotten -- BASIC being too little, and the computers not having enough power for Pascal/Algol-W/C. LOGO was quite popular, of course, but anyone remember COMAL? It had line numbers, but mostly for editing interactively. Beyond that, you had full structured programming, a decent enough allowance for variable names and a rather verbose syntax to help you remember where you are. No semicolons required, turtle graphics included in most implementations. Short example:
One of my favorite languages of that era was Elan. Which, like most others, was slightly pascal-ish, too, but introduced refinements, a feature rarely seen since (literate programming preprocessors excepted). Also allowed ample usage of spaces in identifiers. We tend to do similar things with (maybe nested) functions and comments, but this puts it all on the language level, which also would make it easy to have the system prompt you for your missing refinements, and of course get by without passing parameters.Now, replacing all that or more contemporary equivalents (like Scratch or Python) with a didactic approach that's pretty much centered on writing flowcharts beforehand is quite an idea. Which, by the way, is something we shouldn't forget when we compare languages: It's not just about its syntax alone, but how students are taught to construct and revise them. REPLs vs file-based, for example. This would have them draw the general structure and then encode that in GOTOs. I bet Dijkstra would feel torn about this…
But beyond that, I'm not sure that I want that in a "modern" idiom, where I get a whole bunch of compound words on the screen, like classes, objects, methods and variables. Spaces are quite easy to pick out as delimiters -- and I've actually heard that as an argument for CamelCase against snake_case.
Then again, I'm German so I might have a high tolerance for long strings and syntactical pain.
You're certainly used to stropping your Nouns. Maybe `all` that `keyword` stropping `in` ALGOL 60 isn't so bad `if` you're used to that. 8-)
If all your keywords are specially marked, everything between them can be vacuumed up by the parser as-is. It's actually easier to parse than modern languages with space delimiters. But arguably worse to write.
Some information for those interested is still at http://www.cs.ru.nl/elan/ and there's an implementation for the language there as well.
An interesting tidbit is that ELAN was used for the EUMEL system by Jochen Liedtke, who took what he learned to develop the L3 and later L4 microkernels; see also https://6xq.net/eumel/
The Linked List example has an unbelievable number of GOTO 120 and GOSUB 380 type of statements. Even QuickBasic didn't have to do that.
QuickBasic is from 1990. ECMA-55 is from 1978, and even then it's explictly “Minimal BASIC”, not a remotely comprehensive language in that family even for the time.
Thanks.