In this post, Mark Guzdial brings up an issue that’s generated a fair amount of interest in recent years. The old-school personal computers — Apple II, Atari, Commodore — all came with a free, and built-in, BASIC interpreter. BASIC even came with PC-DOS/MS-DOS. This onboard BASIC was the first exposure to programming for many (I’m tempted to say most) of today’s programmers.
Now, no one would argue that BASIC is a great language. It was, however, free and ubiquitous – there were problems if you wanted to share your Atari BASIC program with someone who had an Apple II, but often you could make the code work with a little bit of ingenuity.
Where do modern kids get that experience? Are we creating a generation of appliance users who (if they’re exposed to programming at all) get their first experience in a behemoth like Java?
So there’s no confusion here: I like Java (well, I like the JVM anyway 
), and have written more than my share of it. However, it doesn’t exactly lend itself to casual tinkering. Compare:
10 PRINT "Hello, world!"
1 line, 11 characters of overhead, what the code does is obvious at a glance, even to someone who doesn’t know programming (they might wonder about the 10, but that’s about it).
to:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World!");
}
}
6 lines, 112 characters of overhead — plus you have to compile it, maybe set up your CLASSPATH, and perhaps perform other chores that stand in the way of instant gratification. Also, the code is largely opaque to a programming-naive reader. “public class”? “static”? “void”? Say what?
There have been many attempts to fix this. Scratch from MIT, Alice from Carnegie Mellon, indie projects such as Hackety Hack from why the lucky stiff (please come back, _why! We miss you!), special purpose scripting languages such as LSL, and several others.
With the exception of LSL, most of them are excellent (Cory Ondrejka, author of LSL: “[N]ote to self, next time spend more than one night designing language.” ). I’ve had good luck teaching this type of language to an audience of K-12 teachers, most of whom had no background in programming.
Where they come up short is ubiquity. They’re almost all free, which is great, but they have to be installed, which is not so great. Most school computers are locked down extremely tightly (an interesting topic its own right). In fact, one of my students was reprimanded for installing Scratch on her classroom machines.
Even if you are permitted to install the software, the installation step still creates a barrier for sharing your creation with your friends, since they in turn have to install something before they can run your code.
MIT has worked around this to some degree with their Java (and now Flash) web-based Scratch players, but Java and Flash present their own issues (school firewalls or other security software may block Java and Flash, Windows machines, and starting with OS X Lion, Macs, no longer come with Java installed, Flash doesn’t work at all on iPhone/iPad, and doesn’t work very well on Android).
So… what to do?
I would argue that JavaScript is the modern equivalent of BASIC; it’s free, ubiquitous, and has the requisite nasty, nasty syntax. Any kid with a web browser and a text editor can write and run JavaScript without installing anything. HTML 5 opens up the possibility for impressive visual and sound effects that can be shared with anyone else on the planet who has a modern browser.
Even with the ugly syntax, JavaScript is a much better language than old-school BASIC. Closures, anonymous functions, objects — there are a lot of Big Ideas in there.
Besides the syntax, the other drawbacks of JavaScript include performance and the sandbox model (sandboxing is essential when you’re running arbitrary code from random web sites, but extremely inconvenient when you’re running your own trusted code).
There are workarounds. There are new packages that let you use better syntax (e.g., CoffeeScript, which gives you Ruby-like syntax, the experimental ClojureScript, which gives you Lisp, and many others).
With respect to speed, Google has invested major effort in their V8 JavaScript compiler, which gives you near-native code performance. It’s much, much faster than classic JavaScript.
There are also several options for those who chafe at the sandbox.
Node.js lets you access the file system, write servers, and similar stuff.
Packages such as PhoneGap and Appcelerator Titanium let you write JavaScript applications that run on phones and other mobile platforms. In both cases, the code has direct access to phone features such as the camera, microphone, contact list, geolocation, accelerometers, and so on. PhoneGap works by calling native routines from interpreted JavaScript, while Titanium precompiles the JavaScript to native code.
While I have no data, I would wager that the ability to do cool things on their phones, and share those cool things with their friends*, would be an extremely powerful motivator for today’s students.
* The biggest barriers to doing phone stuff are bureaucratic rather than technical — there are some issues involved with distributing your creation. For iOS, the best option right now (on a school level) appears to be Apple’s Enterprise Distribution mechanism, which isn’t particularly transparent, cheap, or low-friction. For individuals (or if you want wider distribution through the App Store) you’ll need to buy a seat in the standard iOS developer program. I’d really like to see Apple set up some kind of low-cost student program — perhaps it could include the standard developer package’s ability to distribute to a limited number of devices on an ad hoc basis, but not include the commercial features (e.g., distribution through the App Store). Android is much more lenient in this respect.
