I was inspired to use Processing as the basis for a course in introductory programming in large part because it reminded me of a type of computing that I think we’ve lost sight of over the years: the idea of the computer as a blank canvas, always available for you to try out the next interesting idea that crosses your mind.  The Commodore 64 or TRS-80 Color Computer (just to pick a couple of examples) may not have been powerful computers, but they inspired a lot of creative work simply because a instant after you turned them on, they had a mostly blank screen and flashing cursor and were ready and waiting for you to start writing your own program.  Nowadays, it takes a fairly advanced knowledge of most programming languages to get to the point where you can understand how to draw a line on the screen.  That’s not to disparage GUI libraries and frameworks and development environments out of hand — they make modern application development livable — but they do effectively bar the vast majority of people from writing small programs for their own computers.  We seem to have decided that there’s no such thing as a small program any more.

We often classify languages as being for either beginners or advanced programmers, a nasty habit that became particularly pronounced during the heyday of small home computers in the 80s, when there was a cultural divide between people who “only” knew BASIC and not assembly language (like the real programmers used).  Now, there’s no denying that an Apple II can do things in machine code that it cannot possibly accomplish in BASIC, but that’s always been obvious enough without shaming people into abandoning programming altogether.  Now we’ve got computers that are faster than we ever dreamed possible, but there are still a surfeit of programmers happy to look down their nose at anyone using a language they consider insufficiently elite.  Processing would very likely be unacceptable to many of these folks: after all, it’s a front end for a language that’s compiled into byte code for a virtual machine.  Real programmers use…

(Insert scratching record sound.)

Real programmers use whatever tools suffice to allow them to accomplish the results they seek.  If you write programs that are useful to you and you find satisfaction in doing that, you’re a real programmer.  Moreover, I guarantee that doing so on a regular basis will make you a better programmer over time.  You may eventually branch off into other languages or decide to program closer to the metal because you like the challenge, or you may stick with a simple language that you enjoy because it does what you want it to do.  You might not be qualified to be a professional programmer, but if I’ve got one point to make here, it’s that programming isn’t just for professional programmers, any more than writing is just for professional authors or basketball is just for professional athletes.  It’s your computer, and you ought to be able to make it do what you want: that’s programming.

So when I say that Processing is a great language for getting into programming, I don’t mean that in the snide way we computer geeks often use to suggest that sure, maybe it’s okay for a newbie, but honestly, if you want to do something real…  No, I mean that it’s a great language for getting into programming, as in really enjoying what you’re doing and being able to write some powerful programs with not so many lines of code.  It’s a language that can give you a taste of why we geeks enjoy these cantankerous computer-things so darn much — and if you decide to bite the bullet and try some of this programming thing I keep going on about, and one of your friend scoffs at your choice of language, you’ve got my blessing to tell him or her that you know of at least one person with a CS doctorate who likes prototyping things in this baby language, thank you very much, and check out this awesome new program you just wrote.

And for those with warts this little thing will do the trick, best way to get rid of warts.

Existence for this past week has often involved sitting about and waiting for the phone to ring, which has given me a chance to play around with the HTML5 Canvas element and the super-speedy V8 Javascript engine embedded in Google Chrome.  The Canvas element is particularly exciting to me, since it finally allows you to play around with pixel-level drawing on the Web without resorting to skeevy CSS tricks (such as, for instance, a grid of tiny <span> elements with a background color and absolute positioning).  Yes, there’s a lot of Web design the Canvas is completely inappropriate for, but I think the nay-sayers are underestimating the value of the Web as a universal programming platform.  The HTML5 Canvas is a lot like Processing: it gives beginning programmers a way to draw pictures on the screen without having to learn a dozen other technologies, APIs, and libraries to get something done — and Javascript has become a good language for starting out, thanks to better development tools and debuggers.

I don’t mean to imply that the Canvas + Javascript combination is just for beginners — quite the contrary, in fact.  I think that we’re going to be seeing a lot of really cool data visualizations and games developed using Canvas, especially with the advent of highly optimized Javascript engines.  Don’t believe that’s possible?  Check out Ben Firschman’s Javascript NES emulator, which uses Canvas for display.  If you can emulate a 6502-based system with graphics and sound co-processors in a scripting language, it’s time to take that scripting language a little more seriously.

I’ve thrown together a couple of demonstrations of the technology: one is a simple implementation of Reversi, and the other is a Chip-8 emulator.  Rather than just throw them out there as a “hey, look what I did,” I’m opting to take a tutorial approach that’s more along the lines of “hey, look what you can do!”  For each of these projects, I’ll be writing a series of posts that take the program from its inception all the way to the finished product.  You’ll be able to see the design decisions and choices that go into making a working program and hopefully be inspired to build something of your own in the process.

All of the code for these projects will be released under Creative Commons licenses that allow you to adapt it for your own projects, and I’ll try not to assume anything about your existing programming experience.  Feel free to ask any questions you have about the material (even if you’re coming across this blog many moons after this post has first appeared), and I’ll do my best to clarify.  If you’re curious at all about game programming on the Web, this is a great time to start!

(For the curious, other upcoming Canvas projects I’m sketching out include a Rogue-like RPG and a TRS-80 Color Computer emulator.  If only there were more spare hours in the day!)

I think all of the bugs are worked out now, and every CHIP-8 and SChip feature should be implemented (including annoying sound effects, if your browser supports OGG Vorbis sound files).  Everything should work okay (in theory) with Chrome, Firefox, Safari, and possibly Opera.  Versions of Internet Explorer prior to IE9 aren’t supported and won’t ever be, simply because they lack support for Canvas… sorry about that if you’re stuck with IE on Windows XP!

As I mentioned last night, I’ll be writing an extended series of tutorial posts that guide you through the process of writing an emulator like this, and you’re welcome to use the code under a Creative Commons license (non-commercial share-alike).

If there are any browser incompatibilities or compatibilities, I’d love to hear about them.

It’s not a bad way to build code, but the syntax of Javascript isn’t well-suited for it, since it maintains the artificial distinction between expressions and statements common to most languages with C-like syntax.  Instead of function () { 5 } we’re forced to write function () { return 5; }, and it gets much worse when you’re writing functions that return functions.  You often wind up with a tangle of braces, parentheses, and semicolons at the end of the line, and without a decent syntax highlighter, it’s a mess.

In the process of writing this code and making it more aesthetically palatable to myself, I’ve come up with a few things that might help if you’re in a similar situation.

The first has to do with whether the Javascript engine forms closures in such a way that the free variables are retrieved just as efficiently regardless of whether they’re bound to parameters of an enclosing function or locally defined variables.  To offer an example, here are two bits of code that bind the variable f to a function with two free variables. The two versions are computationally identical but could differ in execution speed depending on the engine:

  f = (function (a, b) {
        return function () {
          return a + b;
        };
      })(5, 6);

and

  var a = 5;
  var b = 6;
  f = function () { return a + b; }

The second version does create new local variables outside the assignment, but it’s obviously much easier to read than the first version. Moreover, testing shows that in Chrome’s V8 Javascript engine, the resulting procedures are virtually identical (if not exactly the same) in terms of execution speed.

That’s great news! On the other hand, the second method can become much less attractive when you’re building an entire array of functions for later execution, because Javascript has some scoping rules that, in my opinion, fall in the “sick and wrong” category. Consider the following code:

  a = Array(4);
  for (var i = 0; i < 4; ++i) {
    var j = i * 2;
    a[i] = function () { return j; };
  }

  for (var i = 0; i < 4; ++i)
    debug("a[" + i + "]() = " + a[i]());

In a civilized world, each iteration of the loop would construct a brand-new local variable j to be captured by the reference in the newly-created function, so you’d get this output:

  a[0]() = 0
  a[1]() = 2
  a[2]() = 4
  a[3]() = 6

Instead, you wind up closing over the same variable reference in every procedure and get this output:

  a[0]() = 6
  a[1]() = 6
  a[2]() = 6
  a[3]() = 6

This would tend to send you right back to the first (more ugly) technique above, which handles the problem by wrapping the new function in another function that accepts the free variables as parameters, then passing in those parameters immediately. However, I’ve come up with a technique for making this sort of code less unsightly. Here are the functions that make it possible:

  function closure(map, body) {
    var varList = keys(map).join(", ");
    var valList = vals(map);
    var f = eval("(function (" + varList + ") { return function () { " + body + " }; })");
    return f.apply(null, valList);
  }

  function keys(map) {
    var ls = [];
    for (var key in map)
      ls.push(key);
    return ls;
  }

  function vals(map) {
    var ls = [];
    for (var key in map)
      ls.push(map[key]);
    return ls;
  }

The closure function takes two arguments: the first is an associative array mapping the free variables to their values, and the second is a string containing code that refers to those free variables. What you get back is a function of no arguments in which those free variables have been fixed. For instance, the array example from earlier can now be written like this:

  a = Array(4);
  for (var i = 0; i < 4; ++i)
    a[i] = closure({"j":i*2}, "return j;");

Although the closure function calls eval(), you don’t actually pay any runtime penalty for this later on — the return value is a completely cooked function that will run efficiently when called. (As another Javascript oddity, note the extra parentheses wrapped around the code that’s passed to eval() — they don’t seem as if they ought to be necessary, and yet they are.)

You may never need to write this sort of code-writing code, but if you’re accustomed to taking a functional programming approach to problems, it’s a natural style to adopt. Feel free to use any of this in your own programs and contribute any additional observations or suggestions!