BASIC is a language that refuses to die. It just keeps coming back, in ever more varied and powerful forms. There is a list of close to 300 BASIC dialects on Wikipedia. Is this due to some technical superiority of the language? I do not believe so. Then what?
I think BASIC's success is due to its inferiority - and its community.
Before I explain, let me get to my main point: I believe BASIC needs to live up to its name. Certainly not every dialect of BASIC, but at least one flagship well-supported dialect. It should be designed with Beginners in mind. It should be reasonably All-purpose. It should be Instruction Code, that is, procedural. And it should be basic - which I use in a similar sense to "spartan".
This is not an argument for a BASIC whose sole purpose is to teach kids programming. It's an argument for a BASIC which fosters community, collaboration and exploration.
I seldom use any BASIC dialects these days, and when I do it's either QuickBasic or QB64. I also keep an eye on the development of QB64, and have had some experience with Visual Basic. I know what GW-BASIC and BASICA are like and I've had a brush with FreeBasic. My knowledge of other dialects is quite limited which means I cannot be regarded as an authority on the subject, but still I wish to make my opinion known.
I have seen enough FreeBasic code to conclude that it's not BASIC enough for me. QB64 is much better in that regard, and when I say "one flagship well-supported dialect", I believe QB64 could fill that position.
That's not to suggest that FreeBasic has no place - it has a very important place, particularly as an avenue for those who feel the simple procedural style of BASIC is too restrictive. But that's not what I wish to talk about in this article. Henceforth, when I talk about BASIC, I'm talking about my vision of a "basic BASIC" and I'm not trying to criticise other dialects out there. I keep BASIC capitalised to remind you of this.
As I have said, I think one of the reasons for BASIC's success is in fact the inferiority of the language. It enables beginners to learn and gives them confidence. It encourages more advanced users to explore and to question.
Let's take a case study: QB's INPUT. Most people will agree that INPUT isn't very useful. That redo from start nonsense, the inability to set a length limit, the handling of commas and of course the necessity to press Enter mean it's rarely used in more polished programs. More importantly, beginners are motivated to seek a better alternative. They often find INKEY$ and soon realise they can make their own, improved INPUT. They realise that INPUT is made from simpler parts.
It is my belief that such moments are of great importance in encouraging, inspiring, and capturing the curiosity and imagination of novice programmers. They see that things like INPUT aren't magic, and they're not even particularly difficult to understand and recreate.
Another interesting example is sorting. There's no built-in sort procedure in QB. This not only encourages people to learn how sorting is done, it also encourages debates about which sorting algorithms are more efficient. Sorting isn't made to look like arcane magic that mere mortals could never understand.
Imagine if there were very few opportunities like this - if the answer to "How do I sort?" was "Just type array.sort()" and the answer to "Yes but how does array.sort() work?" was "Oh... I'm not sure". This is a reality in many programming languages. People have long used the phrase "pure BASIC" or "pure QB" to describe code. This phrase has meaning precisely because QB didn't offer a vast collection of time-savers. Pure BASIC means "I know how this program works and I want you to know how it works too".
Another point is that BASIC is an inconsistent, inelegant language. There's no delicate symmetry or simplicity or harmony - it's just a programming language that gets the job done. Consequently people dare to think things could be different. Someone who wishes to extend or change the language isn't concerned about disturbing its elegance or consistency. They just do what they think is best and then move on. Hence the hundreds of dialects.
Many people actually enjoyed pushing the limits of QuickBasic. We've seen some amazing things done in QB and some amazing libraries written to extend QB.
I'll return to this subject once I've covered some more fundamental issues.
The single most important thing about BASIC is its community. The needs and wants of the community influence the direction of actively-developed dialects, and generally the community is the source of developers for these dialects. The community helps keep people interested in BASIC and motivates them to make new programs. It provides a target audience for such programs. It helps people exchange knowledge, learn new things, and push boundaries.
Historically, the BASIC community - an eclectic combination of kids, tinkerers and hobbyists, people writing everything from business software to games, but most without much formal training - was a force to be reckoned with and this led to some high quality software (editors, interpreters, compilers) and documentation (help files, manuals, and more) being produced by many including the likes of Microsoft. These days the community mostly serves itself, though the internet has made this much easier.
The measure of a beginner/hobbyist language like BASIC is not how efficient, powerful, advanced, or easy-to-use it is. It is the enjoyment and benefit that people derive from it. This is reflected in the community more than anything else.
In my opinion, BASIC's purpose is to help people develop an interest in programming and learn how to program. If you are reading this, there's a good chance that you disagree and think BASIC needs to cater to hobbyists.
Sure, being a hobby language is an important part of BASIC's heritage. A BASIC interpreter was supplied as a prominent feature of practically all early microcomputers, which were themselves hobbyist devices. This has contributed to an amazing creative culture around the BASIC languages. So I don't dispute the importance of catering to hobbyists. But I think there should be an emphasis on teaching and learning. I will explain my reasons.
First, I think it's no accident that BASIC and hobbyists get on so well! Hobbyists are often self-taught and write programs in their spare time. A language that provokes them to explore and learn while they use it helps to make up for their lack of training.
Also, collecting beginners is a great way to build community. The more accessible the language is to them, the more likely that it will hold their interest, enriching the community with their imagination and talent and questions. For me beginners are one of the few reasons I still maintain any interest in BASIC at all.
So what kind of beginners are we looking to attract? The best kind - those that want to learn, and are willing to contribute to the community.
That seems reasonable, but doesn't bowing down to beginners mean that more experienced programmers are held back? I should say it does - but by how much?
First I must make a distinction between language features and the capabilities of the runtime environment/standard libraries. Language features are tools provided by the language to help make programs easier to read and write, or more efficient. Things like SUBs, FUNCTIONs and type suffixes (%, $ etc.) are language features. So are pointers, polymorphism and function overloading. On the other hand, the ability to draw graphics, play sounds, read from the keyboard or mouse, read files from the disk, and communicate over the network are capabilities provided by the runtime environment or libraries.
The two concepts are somewhat blurred together, especially in BASIC. This isn't really an issue as long as you get the general idea.
I think BASIC should be all-purpose. Many people want a BASIC dialect to be "powerful", but I would prefer it to be all-purpose. A language doesn't need trendy language features to be all-purpose. It's the capabilities that are important.
And capabilities are what beginners want. They don't ask "How do I write elegant, reusable abstractions?" but "How do I get random numbers?", "How do I pause the program for a while?", "How do I play music in the background?". I'm all for "modernising" BASIC by taking away memory limits, improving graphics and sound support, introducing networking support, database support, threading support, and even widget capabilities - provided it is done in a way that preserves the simplicity of the language.
Yes, language features can be a productivity booster. Likewise a built-in sort (for instance) would save experienced programmers a little bit of time. But then programs you write would become more opaque to people with less skill than you. If you can't live without that stuff you can always choose another dialect or a different programming language altogether. But I believe most hobbyists would be quite happy to keep the language simple.
You've probably realised that I'm not keen on the addition of language features to BASIC. No pointers, no short-circuit operators, no macros, no namespaces, no lists or dictionaries, no classes, objects, closures, or lambdas. No polymorphism. No inheritance.
BASIC doesn't need this stuff. My own achievements include a file manager, a GIF decoder, a UTF-8 decoder, a JPEG encoder, and I've seen interpreters, compilers, GUIs, and 3D games - all written in QB. In Issue #1 I discussed the possibility of using QB to write an operating system kernel. I recently wrote a partial (but functioning) web server in QB64, making use of its networking capabilities. This is coming from someone who uses a lot of C and Haskell; I like function pointers and closures and type inference and unsigned numbers and typeclasses and recursive data structures and inline assembly and dynamic memory allocation and embedded languages: but BASIC doesn't need them.
To be clear, I'm fine with SUBs and FUNCTIONs; I can't imagine programming without some kind of procedures and they are so much better than their predecessors (GOSUB and DEF FN).
Now let me justify why I think language features would be a problem for BASIC.
It's not just that fewer language features means less to learn. It's also that the most fundamental features are generally the easiest to understand. (Compare variables, FOR-loops, arrays and SUBs to the stuff I mentioned before.) This means that a beginner can come to roughly understand all the important language features within a fairly short space of time.
What are the effects of people understanding the features of their language? Novices feel more confident - when they look at programs written by other people, they won't feel totally bewildered, because the programs won't be full of syntax they've never seen. People will be more willing to try to understand other people's code, rather than just copy-pasting it. Obviously this is good for learning new things, but it also makes it easier to customise someone else's code. I think these are all big wins.
Fewer language features also makes it easier to decide on the design of a program. It is easier to weigh up the options and reason about performance and the like - because there are fewer options!
How do we "modernise" BASIC without falling into the trap of making the new functionality look like magic? We should try to stay close to the hardware (or OS API) and provide a base on top of which people can write (and share) code that does more advanced things.
QB64 has built-in support for all manner of image and sound files. This concerns me. It has relegated image and sound file formats to the domain of magic.
I would have nothing against programmers sharing image and sound file decoders (written in BASIC) amongst themselves, nor such software being distributed with QB64. I even wouldn't mind them being built-in if they were written in BASIC. The problem is QB64's image and sound file decoders are written in C, and not written by a member of the BASIC community. I find this a little tragic.
So what should we do instead? Provide access to the hardware! In this case, provide high-resolution high-colour screen modes. (QB64 does this already.) And let the programmers read image files using "pure BASIC". (Definitely can be done.) Also, provide access to a low-level sound buffer. I created a tone generator some time ago and felt let down by the lack of such a feature in QB64. Instead I had to have my program continually update a WAV file and get QB64 to play it - an ugly hack. I would really like to see some development here because I think lots of interesting synthesised music stuff could emerge if sound samples could be played directly. And even despite being able to "magically" play MP3s and such, people would become interested in the low-level stuff if they saw (or rather, heard) such programs.
For networking I don't see much benefit to drilling all the way down. UDP and TCP connections make a fine networking abstraction. But built-in HTTP and FTP aren't necessary; it would be easy enough to make functioning clients for them in BASIC.
I think I'll leave it there.
I don't want to force anyone to learn anything. If you want to copy someone's code without reading it, there's nothing wrong with that. I just don't want people to be afraid of learning due to things seeming mysterious or out of reach.
I'm also just stating my opinion, and trying to paint a picture of my ideal world. I wouldn't expect any language to conform to my wishes 100% (not even a language I was in charge of), and I definitely do not wish to divide the community. I just hope to make an impression on my readers.
Can we have a BASIC dialect that's BASIC, but still appealing to beginners and hobbyists? I'm sure of it.