While debugging some broken code for a website once, I had a terminal window open. Just white text on a dark background filling almost my entire screen. A non-technical colleague walked by and expressed both disbelief and amazement that this turns into a website.
Unless you know enough programming to see the gap between code on a screen and the end result as suitably insignificant — to know enough of the stepping stones to cross the gap — it is amazing. At the time, the disbelief seemed like a defeatist “I could never do that.”
Bret Victor gave a talk entitled The Future of Programming. It’s “set” in the 1970s and comes complete with an overhead projector and lots of black and white monochrome. If you’re unfamiliar with Bret’s work, you should definitely watch his Inventing on Principle, which is really inspiring and a good representation of his manifesto — in his own words “to invent the medium and representations in which the scientists, engineers, and artists of the next century will understand and create systems.”
Both presentations are beyond good, but The Future of Programming left me with a sense of dissatisfaction with the state of things.
It would be kind of a shame if, in 40 years, we’re still coding, in procedures, in text files, in a sequential programming model. I think that would suggest we didn’t learn anything from this really fertile period in computer science. So that would kind of be a tragedy.
But even more of a tragedy than these ideas not being used would be if these ideas were forgotten. If anybody were ever to be shown this stuff and actually be surprised by it. But even that’s not the biggest tragedy. That’s not the real tragedy.
The real tragedy would be if people forgot that you could have new ideas about programming models in the first place.
— Bret Victor, The Future of Programming
It’s no coincidence that it was presented not too long after Bret gave a few words on Doug Engelbart, who recently passed away and no doubt gave some impetus for The Future of Programming:
Say you bring up his 1968 demo on YouTube and watch a bit. At one point, the face of a remote collaborator, Bill Paxton, appears on screen, and Engelbart and Paxton have a conversation.
“Ah!”, you say. “That’s like Skype!”
Then, Engelbart and Paxton start simultaneously working with the document on the screen.
“Ah!”, you say. “That’s like screen sharing!”
No. It is not like screen sharing at all.
If you truly want to understand NLS, you have to forget today. Forget everything you think you know about computers. Forget that you think you know what a computer is. Go back to 1962. And then read his intent.
The whole presentation, overhead projector and all, is an excellent demonstration of essentially how much we’ve failed to make progress. Not just in making programmers’ lives easier, or lowering the barrier to execution, but in all sorts of setting-the-bar-higher ways.
If you’re in programming, there’s a good chance you know the details of this story already.
In 2009, _why, a programmer committed “information suicide.” Without warning, almost every mark of his presence was taken off the Internet. Intentionally. No explanation was given. As if mid-sentence, he just stopped.
Then, 3 years later, his website started serving files again. Although they weren’t your standard documents. Not web pages, not plain text files, but instead Printer Command Language instructions. To read whatever he was saying, you had to feed the documents to a standard computer printer, which would then print pages. Essentially _why hit Print and sent his work to the open Internet for anyone to pick up and physically print out. Steve Klabnik compiled everything produced for posterity, calling the whole thing CLOSURE, which you can read. After that, there was again nothing from _why.
Now, I never really knew _why until he was just about to remove all of his online work, but it’s not too important here. The key points are that he was (and still is, really) a prominent figure and left without warning or explanation. Then came back with a short piece of work giving vague insight into his reasons for leaving.
Tucked into a bunch of quirky allegorical storytelling (which others have analysed more broadly) are two sets of pages that are more direct than the others. One about reading the works of Franz Kafka, an author who asked his friend to destroy his works when he died. The other story is about riding the bus.
After finishing reading the works of Kafka:
And when I was finished, I felt done. It went quick. I finished early. I was done. I was decimated. To program any more was pointless.
My programs would never live as long as The Trial. A computer will never live as long as The Trial. Hadn’t he told Max Brod to destroy all of those books? He had to said to burn them, my friend, to burn these books. But look, here was Amerika, thoroughly reconstructed and yet completely unfinished, in my hands.
What if Amerika was only written for 32-bit PowerPC? Can an unfinished program be reconstructed?? Can I write a program and go, “Ah, well, you get the gist of it.”
If The Trial was written for 32-bit PowerPC, Max Brod wouldn’t have to burn them! He would just be like, “How do I even get this thing off the hard drive?” But no. It wasn’t written for 32-bit PowerPC. It was written for eyes.
About no longer programming and riding the bus:
I was aimless, but it felt fine. (This is not what I wanted to feel though. I wanted to feel a great absence, a longing, a distance that would finally inspire.)
I felt happy to no longer be loading Windows Vista and testing.
To no longer be loading Ubuntu 10.04 and testing.
To be loading OS X Leopard and testing.
To not be scanning hundreds of pages listing out Cocoa delegates.
To not be looking at MSDN’s giant list of error codes, separated into groups of 500, each with tiny, repetitive and opaque one-line descriptions.
To not be fighting NULL.
To not be downloading Code Project sample projects which illustrated custom WndProc-style callbacks, but not in the way I was looking for.
To not be studying source files in an old CVS directory tree for their use Pango API calls, only to discover that the code was completely broken and that I had just perpetrated these lies into my own source tree for someone else to do the same, an unintentional virus that would infect three or four of us for several days.
To not be using SDL only to find out the antialiasing looks wrong to me on OS X.
To not be using OpenGL only to find out that I wasn’t using the more portable OpenGL ES.
And to not be using ES only to find out that there is an ES 2 around the corner.
To not be using HTML5 only to find that the canvas API or the event API or the appearance of “floats” just doesn’t fly for 70% of the human race.
Nothing could be more pleasant than to write to you here, in a language which hasn’t budged for hundreds of years and which was used to write “Tristram Shandy” and which I think you will understand.
Longer form versions (and then some) of some of his final tweets, really:
kafka would be a lot harder to get into if the trial only ran on a power pc.
programming is rather thankless. you see your works become replaced by superior works in a year. unable to run at all in a few more.
if you program and want any longevity to your work, make a game. all else recycles, but people rewrite architectures to keep games alive.
The choice to use a technology invented in 1984 to distribute a book is a little bit off the wall. It gets attention. He didn’t just upload a PDF somewhere, or use Dropbox, or even write out a plain text file and serve that on his site. Like an overhead projector used for a monochrome presentation set in the year 1973, the choice has purpose. Distribute plain English as close to printed work as possible. Use an old technology as basic as printer instructions that survived 30 years. Stick to just eyes. Force the pages out of a computer.
We celebrate the modern touch-screen UIs with glorious graphics but build them using tools with hideous UIs born in the 1960s.
— Rob Pike (@rob_pike) August 6, 2013
Watching Bret’s talk, and then, later, staring at a ton of XML (of all things) for the visual description of an Android app, reminded me of what _why said a few months earlier, about the difficulty of just trying to get things done. All those lines of code, built up as an endless layer of barriers, separate from the final creation, ultimately rotting away.