The Third Bit

My first programming language was PL/1. (Look it up if you need to, kid.) My second was Pascal, and then in the summer of 1982 I was introduced to two more: C, and the Unix shell. I realized that C was a programming language right away, mostly because that’s what people said it was.  It took me longer to realize that the shell was also a programming language; I still remember the first time the sys admin responsible for our VAX 11/780 wrote a ‘for’ loop on the command line to try my program for each of several input files.

But now I’m programming on the web, which means I’m writing Javascript. OK, that’s the equivalent of C: full of traps for the unwary, but able to do quite a bit once you get your head around it.  What I want to know is, where’s my shell?  Where’s the tool that’s not quite as expressive (try manipulating tree-shaped data in the Bourne shell), and not as fast, but lets me do with two or three commands what would take half an hour to code and debug at the base level?

JQuery isn’t what I’m looking for (though I’m very, very grateful that it exists). JQuery isn’t a watertight layer of abstraction above Javascript: it’s leaky, in the sense that users still have to pay attention to Javascript-y things.  (“Wait, I forgot to say ‘var’…”)  CoffeeScript and other compile-to-JS languages are leaky too, but the shell is as close to being leak-free as any abstraction layer I can think of. In almost 30 years of nearly constant use, I’ve almost never had to think at the C level in order to debug a problem at the shell script level [1].

So what would a shell-like tool for in-browser programming look like? Well, I think it would look something like Microsoft PowerShell. There’d be lots of more-or-less orthogonal tools, each of which did one thing, but instead of communicating via streams of text, they’d send one another streams of objects. Those tools would probably be written in Javascript, and the shell might be as well (just as bash and its ilk are written in C), but users wouldn’t see that.  What they would see is that they could package combinations of tools into scripts that could then be used as tools in their own right. The syntax for simple operations would be much simpler than that of Javascript, at the cost of some expressive power, but that’s OK: 80/20 splits are a good thing.

And hey, it would give us a chance to choose command names that are more mnemonic than ‘ls’ and ‘mv’…

[1] And the times I did were my own fault, because one of the components in my pipe was a program I’d written myself, which didn’t fork properly, and—never mind, it’s not important.

Extensible Programming

The good news is, the Khan Academy has finally added some lectures on programming. The bad news is, the lectures build toward Fibonacci sequences and sorting, rather than things most people will actually want to do.  As Mark Guzdial and others have showed through initiatives like Media Computing, you can introduce all the usual suspects (assignment, iteration, conditionals, etc.) in the context of something like image manipulation, but doing so yields higher retention, particularly among the 85% or so of the population that isn’t turned on by abstract symbol manipulation.

Uncategorized

A good TV drama needs heroes and villains, romance, momentum, crackling dialog, and the occasional chase scene (gunplay optional). Which makes me wonder: why hasn’t anyone ever built a series around the Underground Railroad? There were plenty of heroes, and even more villains; it’s got all the high moral drama you could ever want, and thrills? Just read Bound for Canaan or Beyond the River if you want thrills. If Vince Gilligan is looking for something to do after Breaking Bad, I for one would pre-order the boxed set.

Uncategorized

I have an idea for a game, but no time to implement it, so I’m going to throw it out in the hope that some interwebby young’un with time on her/his hands will build it for me (and everyone else). The starting point is a basic first person shooter with a science-fiction theme (rayguns, jetpacks, etc.). What makes it different is that each player has the ability to wind time backwards, but only a little bit: at any point, they can press a “rewind” button and reverse the flow of time, but doing so uses up the charge in their temporal battery (which is fairly limited). So, if you just got shot, you rewind a few seconds, then go forward again, but this time you don’t stick your head up to look over the parapet. Or suppose you missed a shot: no problem, wind back a second and aim a little lower.

Ah, but wait. If you’re winding time backward because you just missed a shot, I’m going to do something different in th replay as well, right? I’m going to jump instead of crouch, or crouch instead of jump. Except you know that, so instead of aiming low where I was crouching, you’ll aim high because you know I’m going to jump instead. But I know that you know that et cetera, so it becomes one great big head game:

There are lots of ways to mix this up—power-ups that recharge temporal batteries, for example, or being able to spend temporal energy to force play forward, canceling out someone else’s rewind—but the basic mechanic is pretty simple. Implementation will involve more than just recording and undoing events in a standard FPS (if I jump off a cliff, then start running when I land, the game will need to insert an “undo falling” event between the jump and what comes after), but I think that’s a simple matter of coding. Bonus points if the characters look like the robot from Chronotron

Uncategorized

There’s still time to donate.

Uncategorized

Back in the late 1990s, I volunteered for a while with the CNIB helping a young woman finish off her high school diploma. (She was already in college, but they wouldn’t let her graduate until she’d officially completed Grade 12.) The first course I helped her with was Family Studies, and I remember very clearly how I felt when Question 1 on the final exam began with the words, “Examine the graph in Figure 1…” This course was officially rated “Accessible to the Visually Impaired” by the Ministry of Education, but clearly, somebody hadn’t actually tested the materials. As an answer to the question, she had me write, “I can’t—I’m blind,” but it still took four months of phone calls and letters to get someone to mark that exam out of 75 instead of out of 100.

Jump ahead to the fall of 2010. I had (literally) bumped into a computer science instructor at the University of Toronto who happens to be unsighted, and I mentioned the videos I’d been posting on the Software Carpentry site. He was teaching an introductory programming class; maybe the material would be useful to his students? He hemmed and hawed for a moment, then admitted that he’d actually visited the site, but hadn’t been able to follow the lectures. Yes, there were full-text transcripts of what I was saying, but (and here he actually sounded apologetic) he wasn’t deaf: he was blind. Whenever I referred to a diagram or mentioned “the highlighted bit of code”, he lost the thread. Those diagrams and highlights only existed as pixels, not as some kind of markup that a screen reader or other tool could “render” for him.

Now, take a moment and go pretty much any online education site, like the Khan Academy or MIT’s OpenCourseWare. Close your eyes, and see how much of the lecture you can follow. Some aren’t bad—Prof. Wyn Kelley’s American Literature course, for example, works almost as well on an iPod as it does with video. But every time an instructor actually relies on a diagram to explain something, everyone student who’s visually impaired loses a couple of marks, either because they can’t follow at all, or because the extra time it take sthem to figure it out is time their sighted peers are spending mastering the next topic. Things like the in-browser “code and sketch” tool that John Resig is building for the Khan Academy may look very cool, but what happens to people who can’t look? It’s no good saying, “Let us figure out how to teach online, then we’ll worry about special needs,” because experience shows that adding accessibility after the fact works just about as well as adding security after the fact (i.e., it doesn’t).

Ed-tech’s advocates keep saying that they want to make the best teaching accessible to everyone. Respectfully, they’re not doing that, and as schools rush to get students online in order to save money, people who are already disadvantaged will be left even further behind. I don’t have any answers—I don’t think there are any easy ones—but those of us who can see shouldn’t lose sight of the needs of those who can’t.

Equity, Learning

The November/December 2011 issue of IEEE Software has a good article by Markus Völter titled, “From Programming to Modeling—and Back Again“. In it, the author asks, “What’s the difference between programming and modeling? And should there be one?” His answer to the second question is no: instead of today’s sharp divide between describing the problem domain, and telling a computer what to do, we should use extensible environments that support a continuum between the two.  I like his description of what’s wrong with things today: we shouldn’t use concrete syntax as a storage format.  But as with so many other articles on extensible programming, I think he glosses over the biggest practical obstacle such systems face: debugging.  An abstraction’s usefulness is limited by how fixable it is when it breaks; if you give me a way to program in pictures, in natural language, or in some domain-specific notation, but then require me to wade through automatically-generated spaghetti code to figure out why my description of what I want isn’t doing the right thing, you haven’t really helped me very much. I’m still trying to figure out how to reconcile this with the “pile of crap” problem I ranted about in my previous post, though. If my editor/compiler/debugger are all extensible, then everything I try to do will trip over installation and configuration snags…

Extensible Programming

Heather Payne is smart, hard-working, and not afraid to dive into things she doesn’t know. Starting from nothing more than a tweet six months ago, she and her colleagues have built an organization in Toronto called Ladies Learning Code that runs workshops to teach women basic programming skills. A couple of weeks ago, she set herself a goal: she wanted to build a simple little dynamic web site. Yesterday, she blogged this under the heading, “Here’s What I’ve Learned About Programming So Far“:

Respectfully, I disagree. Programming itself isn’t intrinsically hard; what’s hard is all the crap we make people like Heather wade through to get to the programming. I’ve been programming professionally for 29 years, and I’m still baffled, frustrated, and angered by things going wrong when I’m trying to set up a new workspace. Install this—oh, but wait, it depends on that, and the package manager I’m using doesn’t install the right version of that by default, but the error message telling me that only makes sense to five people on the entire planet, so off I go to a Q&A site where someone inevitably says, “It’s easy—you just…” Saints and small mercies, I hate that word—hate it and dread it. “Just” means “I want to make your problem sound trivial.” “Just” means “I refuse to acknowledge that we’ve buried your actual problem in so much accidental complexity that you’ll have to dig for hours to get to it.” Whether it’s a bureaucrat saying, “Why don’t you just fill in this 25-page form,” or a programmer saying, “Why don’t you just switch languages,” its real meaning is, “Your time means nothing to me.”

I’ve been teaching programming off and on for 24 years, and what I’ve learned reflects something psychologists discovered back in the 1970s. Suppose I give you a choice: you can either wait for the bus for 10 minutes every day, or you can wait 1 minute four days a week, and 20 minutes the fifth day, except you won’t know in advance which day each week is going to be the long wait.  If you choose the second option, you’ll wait half as long on average, but almost everyone prefers the first because it’s more predictable. Similarly, if you can choose between a task that will reliably take an hour, or one that will usually take five minutes, but will occasionally take a full day, you’ll choose the former—you pretty much have to if you want to be able to plan anything else.

And that is where we, as programmers, have failed. When Heather and people like her sit down to start programming, they have no way of knowing whether a seemingly-simple task is going to take 5 minutes or 5 hours, because we, the professionals, don’t know either. Oh, we’re probably better at guessing, but we don’t know. And yes, other things aren’t really predictable either—painting a wall can take half a day instead of 30 minutes if you accidentally knock the can over and have to clean it up—but programming has much bigger error bars than anything else I do.

So here’s what I’ve learned so far from almost thirty years of programming and teaching. If we really want it to be something that most people can do, the way most people can do their taxes or change the oil in their car, then we have to make it more predictable. We have to stop excusing ourselves with the J-word; we have to stop saying, “Oh, but of course the debugger won’t work if you’re running a Tkinter application, because the Tk app grabs the event loop,” which is about as fair as saying, “Oh, but of course it rains when you wear red on Tuesdays” (the “…you idiot” at the end of that sentence may be silent, but it’s always there). We don’t need to simplify programming itself: we need to throw away all the crap that’s piled up on top of it. A “simplified for novices” layer on top of the crap won’t work: all abstractions leak, and the interface between the simplification layer and what’s underneath it will be a breeding ground for more incomprehensible bugs.

If we have made programming difficult for someone like Heather, then we should be ashamed of how poorly we have done our jobs. I don’t know what the solution is, or if we can get from here to there, but as far as I’m concerned, it’s the biggest challenge computer literacy projects of all kinds face.

Uncategorized

I unfollowed a former student on Twitter a couple of months ago because he was tossing words like “bitch” and “whore” into his tweets like marshmallows into hot chocolate. Today, I unfollowed a guy named Ted Dziuba because of this post defending—actually, praising—the use of foul language. He probably doesn’t care, but I’m hoping you will, so here goes.

The key sentence in Dziuba’s post was:

People like me, Zed Shaw, and Zach Holman will give you a brutally honest answer if you ask for it.

That’s bullshit, in the strictly technical sense of the word. People who drop the f-bomb (or the c-bomb n-bomb, and for all I know, the q-bomb and λ-bomb) into conversation aren’t telling you the truth any more than Paul Graham and other pundits that Dziuba is so jealous dismissive of. If they’re trying to smother listeners with anodyne non-information, then the foul-mouthed brigade are trying to distract us by throwing burning bags of dog poo onto our porches.

But there’s an important difference. Words like “fuck”, “bitch”, and “nigger” aren’t just meant to shock; they’re also meant to intimidate. Women, ethnic minorities, people with varying sexual orientations, the disabled, and the bullied have all learned the hard way that those words are warning signs of attitudes that start at “you’re not one of us” and rapidly get worse. I don’t know if Dziuba, Shaw, Hansson, and others who excuse themselves by calling it “frank” or “honest” are actually racist, misogynist, or homophobic. What I do know is, they’re sending the same signals as people who are. (And yes, they have defenders and imitators who are people of color, female, and/or LGBT. So what? Some people will do almost anything to fit in…)

Having gone through a phase like this myself in my twenties, I suspect that a large part of what’s driving the potty-mouth brigade is a desperate need to be accepted by the high school cool crowd that cut them cold when they were teenagers. But that kind of ten-cent psychoanalysis isn’t even worth ten cents these days, and anyway, I don’t really care about their reasons. What I do care about is that the makeup of our profession is as skewed as it was thirty year ago when I first started programming—that a lot of people are choosing not to pursue interesting, well-paid, white collar careers because they’re made to feel unwelcome. If you can convince me that saying “shit” over and over again is going to fix that, I’ll apologize for this post. If not, I’ll continue to consider you part of a problem that you, for all your self-proclaimed honesty, aren’t honest enough to face.

Later: the first three responses to this piece were (a) vitriolic and (b) anonymous, so I’m closing off comments for now.

Later: in response to email, no, I’m not expecting this post to change how the people I’m complaining about talk or act. I just want to let the people their words and actions are driving away know that some of us are on their side. To paraphrase Burke, all that is necessary for the triumph of meanness is that people of good will are too afraid of being called prissy to stand up for what’s right.

Uncategorized

Family