Thoughts: On Means On (or “Where’s the ‘New’ Command?”)

Some of you may (and the rest of you won’t) remember a time in the history of your computer usage where starting up your machine took almost no time at all and the thing confirmed that it was “READY” to hear what you had to say. It would even give you a coherent response if you typed in a simple arithmetic expression (as long as you typed a “?” first). It was good stuff.

I recently recounted to a co-worker that I had initially had some trouble the first time I seriously tried to use a PC, which must have been around the fourth grade or so, because it didn’t seem to do anything meaningful when I typed anything like LIST, RUN, or ? "HELLO". Apparently the thing was a different beast than the C64 I’d been using. My dad helped by directing me to type win to start Windows 3.1; that would be my crutch until I picked up the rest.

Eventually I learned about QBasic and slowly started to slough off the newly deprecated parts of what I knew about programming—no line numbers, avoid GOTO when possible, and so forth. Eventually my dad finagled me a copy of Visual Basic 3.0 and so I picked that up as well. Later on, I’d use my spelling bee money to upgrade to VB 5 and make things with 32-bit features. Later still I’d learn C and C++, and then everything I know about Perl, PHP, Java, and beyond.

A sad fact about all of this progress is that the typical home computer user has gotten increasingly distant from knowledge about how the machinery works. It might seem justified in that the machinery itself has gotten more complex. In truth, however, as the gears and rotors get more intricate, clever ways to abstract away the tricky parts evolve as well.

For example, consider The Oregon Trail for the Apple II, and the game of the same title released on the social networking scene this past February. It’s a sure thing that if the teams that developed either version met via time machine and shared their code, it’s far more likely that the old team would be able to figure out the new team’s code than vice versa. Even if the old generation’s code were relatively higher in quality than the new (which would be my expectation in fact), it was written for the Apple II, probably with large parts of it in MOS 6502 assembly and the rest, if any, in some other very non-modular language. The cognitive load involved in development for the older platforms was comparatively colossal relative to the newer machinery.

Flash (the newer game’s platform) won’t even let you touch the same guts that the older guys had to know intimately. It doesn’t have memory management routines nor even registers. The newer game was built on primitives of variables, events, and even pre-fab shapes and sounds. The environment was designed so that the most involved parts of development are already done (the computer has sufficient capacity that you can just have all sorts of other people’s code in the same place as yours) and the content creator can dedicate more effort to the product itself.

Still, unfortunately, nothing like that—like Flash or any other development platform—is already there and waiting the moment I turn the machine on (or as is the habit lately, when I move the mouse and unlock the screen).

On a lot of computers, possibly the majority, you have a menu button that leads you to any program installed on the system. This is a “start” (har har), but it doesn’t so much involve creation nor even modification. It merely tells you what you can currently do with your computer. That is, if it’s not in this list, your computer won’t do it (unless you buy/steal/download and install something that implements the feature). This is the way Windows (and much other stuff) treats software.

In contrast, here’s an example of how it treats text files: If I use the start menu to open notepad.exe, I get a blank slate. I can go to the File menu, which leads with the two options “New” and “Open…”, but since “New” is already understood, I can instead just immediately start typing new text.

(By the way, BASIC on the old-school machines worked the same way: You could immediately start entering a program listing at the first prompt. When you decided to clear the existing program and start a new one, the NEW command obliged. And for an existing program, there was usually some variant of LOAD.)

So, how’s that for a model? The start menu is like an “Open…” dialog without a matching “New”, and it defaults to making me run something existing instead of defaulting to a blank slate for something new. I’d like to see that “New” button. The casual user needs to know it’s okay to produce in addition to consuming.

Where should “New” lead, you might ask? I do think that the time for strictly text-based programming languages might be past in terms of beginners. BASIC was pretty simple but it was still a vocabulary with some cognitive load. Not everyone thinks like that. There are certain wordless, flowchart-based languages that allow the user to draw out a flow graphically. Since I like to be able to pronounce what I’m writing, I tend to shy from these as well.

I haven’t used it before, but Scratch seems to be using an interesting compromise of these approaches; commands are assembled as colorful building blocks. The entire gamut of commands is selectable from an easy-to-use palette, meaning that learners don’t need to memorize individual commands and need only have an idea of what sort of command might be useful in a given place. Some commands have fill-in-the-blank parameters. Block conditionals and loops are very easily distinguished; a command inside a block is visually surrounded by the block. This seems to pry so much load off the user’s working memory that even the reluctant or generally computer-illiterate could end up with a useful notion of how to program.

It seems very kid-centric, which is a plus if you’re trying to teach kids. It might not go over so well with the adults who try to act seriously, and I’d like to see a variant of this blocks-and-palette generalized to the sort of thing I still use perl and bash for most of the time, such as batch find-and-replace in documents (including .odt, .doc, and the like), utility programs that are too small to develop a GUI for (but that could really use one), file renaming, media library management… I need not go on. Suffice it to say that a marriage of the development environment from Scratch with something like the engine from AutoHotkey (an automation tool for Windows) would be extremely valuable.

And here, with a screeching halt, ends the thought.