BASIC and the Time to Hello World
There is a crisis in software development.
Wait, sorry, there are so many crises in software development that I need to be more specific.
There is a crisis in generating new programmers.
I know this sounds crazy in the face of an industry that employs, seemingly, more programmers than there are people on the face of the planet, but I stand by it nonetheless. This is because there's a certain kind of programmer that's missing: the programmer that's doing it for the love of programming.
There's a huge difference between the programmer who loves programming and the programmer (the so-called “tech-bro-dude”) who loves the dream of money as they churn out Yet Another CRUD Application And Ad Delivery Mechanism. And here's the thing.<1> Programmers who do it for the love are:
- the source of all actual advancement in the field; and,
- made, not genetically predetermined.
The kind of people who become programmers out of love are likely determined at least partially by genetics, but that kind of person could just as easily get fascinated by music, or by mechanical devices, or by any number of other fields of interest. It all depends on the on ramps available to catch (and hold) their attention long enough to plant that little seed of love.
“I's looking behind us now into history back …”
Back when I started programming—back when I fell in love with it—there was really only one game the beginner could play: BASIC. All the computers a beginner had access to had BASIC, whether this was DEC machines like the PDP-11 or personal computers like the Commodore PET. Many of the latter would start up in BASIC, in fact (as did some of the former!). You turned on the machine (or logged into your account) and there, after a (hopefully) brief burst of nonsense words that meant nothing to beginner's eyes (but often made important questions arise) came that lovely, welcoming, reassuring prompt:
Ok
_
This prompt told us what we needed to hear. That the machine was ready. And that everything was OK.
From here we could type commands, slavishly following some book or magazine (remember those?) perched precariously in our laps or to one side:
print 'Hello, world!'
Hello, world!
Ok
_
We could change the commands and see what happened. We could set variables and print them out. We could input values into variables and print them out. Maybe even alter them in the process!
Such power was at our fingertips and we got our results back instantly in a tight feedback loop of joy and dopamine. And then we got to programming.
10 input 'What's your name? ', name$
20 print 'Hello, ', name$, ' ',
30 goto 20
The specifics of syntax will have varied slightly from machine to machine, but the gist was the same. And at our fingertips we had power. Power to command a machine to repeatedly type the same thing over and over and over again for all eternity if we so chose. (We never did. We did, however, quite frequently alter the message to something profane. Because children.)
There are two key metrics that BASIC nailed from the get-go:
- Time to 'Hello, world!'
- Time to altering 'Hello, world!'
Very few languages before it or since had that heady mixture of instant feedback and (seeming) endless power. More nerds got hooked on programming, falling almost immediately in love, because of that feedback loop and, in the process, learned quickly. BASIC was my on ramp to programming and led very quickly to learning 6502 assembler, then Pascal, then another assembler dialect and, before long, a whole bunch of other things in computer science, software engineering, and programming.
I have BASIC to blame for, essentially, over 4 decades of my life. And my story is the story of thousands of people just like me scattered to the four winds in the software industry. It's not an accident that the early to mid 1980s were some of the most creative (if sometimes insane) periods of program design and development. It's what happens when you unleash nerds in love on an industry.
“Time counts and keeps counting …”
Over time, of course, the limitations of BASIC became manifest. Yes, amazing things were made with BASIC. (Like an astonishingly realistic flight simulator on a TSR-80 Model II I typed in from a magazine and then tinkered with.) Yes, BASIC was actually a powerful programming language that lurked, all muscular and jacked, behind the easy-seeming interface.
But it was flawed. So flawed that big names in computing dumped on it. And as much as we nerds who used it as an on ramp loved our first language (you never forget your first!), we knew, too, that it was flawed.
So we spread out. Pascal. Modula-2. That nifty “C” language we'd heard so much about. C++. Java. Python. Ruby. Language after language flowed beneath our fingertips and we accomplished so much more with these languages, with their power and their extensive communities and libraries. In the process we became software engineers and internalized a lot of engineering “best practices”.
But we forgot our roots.
We forgot to keep a good on-ramp for burgeoning programmer nerds. An easy way to do cool things with ever-more-powerful hardware that would attract the attention of our kind before they got swallowed up by video games, by music, by anything else out there that wasn't programming.
People tried to make pedagogical tools for teaching programming, but that was the problem. They were pedagogical tools, not authentic programming languages. In the distant past there was Logo, for example, and it was a powerful tool for teaching programming concepts … but not for programming. It was like those interminable “educational toys” that get foisted on parents as being good for their children; the kind children would tinker with for a while before going back to their toy cars, G.I. Joes, Barbies, and other such toys that were actually fun.
I saw lots of children put in front of Logo. I saw them fascinated by it for a while. Then I saw that interest fade as the limitations of the environment closed in on them. And I've seen the same thing with successor or competitor environments up to today's Kojo or Scratch. These kinds of tools are an onramp that leads to a brick wall. To get past that brick wall we're faced with engineering tools.
And as powerful and as capable as those engineering tools are, they are not fun for newcomers. And the interest drops off since to do “real programming” you have to do all this other confusing, boring, tedious stuff. The result is we get the wrong kind of programmer. We get the kind who hear that “coding is money” and come in to get themselves a slice of that pie. The kind who only want to learn things that look good on a resume so they can get a thicker slice next job.
The kind who have no joy in the art and the science of programming. The kind who think the height of technical achievement is finding ways to blast ads into the eyes and ears of everybody around them.
“… finding the trick of what's been and lost ain't no easy ride, but that's our track.”
We need to find that on ramp again. That thing that requires a minimum amount of effort (like launching an app) to get you programming like turning on a '70s or '80s era personal computer had. Yet that thing you can (and would want to!) do serious programming in here in the 2020s.
This is a tall order, I realize, but I also think it's an essential for our industry. Our industry has not meaningfully progressed in decades, hitching a ride on hardware improvements without really improving our software techniques in any profound way. (No, object-orientation is not a profound improvement. Functional programming might barely qualify. Barely.) And to improve our software techniques, we need to get our nerds back. The people who program because they love programming, not because they love stock options and paycheques. (I mean they'll love stock options and paycheques too, obviously, but that shouldn't be their primary motivation.)
Some people might point to things like FreeBASIC and they may have a point. Others may point to venerable projects like Tcl/Tk and may have a similar point. There's plenty of possible on-ramps, but they tend to fail in practice for reasons that are subtle because they're not being built to be on-ramps. Consider this for FreeBASIC, for example:
FreeBASIC gives you the FreeBASIC compiler program (fbc or fbc.exe), plus the tools and libraries used by it. fbc is a command line program that takes FreeBASIC source code files (*.bas) and compiles them into executables. In the combined standalone packages for windows, the main executable is named fbc32.exe (for 32-bit) and fbc64.exe (for 64-bit)
fbc is typically invoked by Integrated Development Environments (IDEs) or text editors, from a terminal or command prompt, or through build-systems such as makefiles. fbc itself is not a graphical code editor or IDE!
This is not an on-ramp. This is a compiler (an engineering tool!) that requires several non-coding steps to use. There's no feedback loop. There's no instant result from changes made in front. There's no way to test a piece of code you want to try out before formally entering it into your program. FreeBASIC is a very good language and piece of code … but it's not a viable on-ramp.
Tcl/Tk is better as an on-ramp. You get a prompt (although it's not as friendly and reassuring as Ok
was!). You can do things live in that prompt. Hell, like some BASIC environments (chiefly on personal computers like the PET, but also in some PDP-8 and PDP-11 environments I used) you can even access commands of the underlying operating system and, importantly, capture their output and use them in your programs. It's all very powerful.
Pity it's such a pain in the ass to install.
No, really. I'm not joking. I've been working with computers since 1979 in some capacity or another, and I still have troubles figuring out which Tcl/Tk to install and how to get it to run and such. It's a powerful language (far more powerful than people give it credit for!) and it can accomplish amazing things, but it is definitively not a “download this app and run it and it just works” kind of experience. A prospective on-ramper is hit with decision paralysis right from the outset before even typing puts "Hello, world!"
. This is an on-ramper who is now at risk of walking off to pick up a guitar, or a paintbrush, or whatever else catches their fancy and another proper programmer lost to us.
And that's not the end of it all. There's still one more problem with FreeBASIC, Tcl/Tk and other projects in that vein: they're not web-native.
BASIC spoke the native language of computers of the time, as did Tcl/Tk: text and occasional bits of graphics or sound. The native language of computing today, for good or for bad, is the World Wide Web. And none of the viable on-ramps in terms of combining ease of use with power is web-native. Making them work with the web, indeed, is so fraught with difficulty that it's off-putting, not attractive.
“… we knows there'll come a night when they sees the distant light and they'll be coming home.”
So this is where we stand. As an industry we've stagnated. Most of our programmers want to put ads in front of our eyes, and that's the extent of their ambitions (because they're in it for the paycheque, and ads before eyes is what pays). The people who could change the status quo—who could introduce the world to whole new ways of looking at computers—are dying out and not being replaced by enough new blood to move us forward. We're losing the creative, interested, inquiring minds to other fields that still reward this and as a result we're in trouble.
We need an on-ramp. We need a tool that does for modern children what BASIC did for my generation. We need a tool that is:
- web-native, because that's where children live;
- low-friction to enter, so that children can slide on in with ease;
- high-power behind the scenes, so children don't quickly grow into the boundaries and get bored.
We need this so that the people who program out of love can see the distant light and come home.
<1> Yes, I apologize for that. It might not happen again.