making things that make things

{ A THESIS JOURNAL BY SAM WANDER }

We Ride Tricycles.

Alan Kay: I characterize what we have today as a wonderful bike with training wheels on that nobody knows they are on so nobody is trying to take them off. I just feel like we're way way behind where we could have been if it weren't for the way commercialization turned out.

Doug Engelbart: Well, strangely enough, I feel the same. It's part of the thing of the easy to learn and natural to use thing that became sort of a god to follow and the marketplace is driving it and its successful and you could market on that basis, but some of the diagrams pictures that I didn't quite get to the other day was how do you ever migrate from a tricycle to a bicycle because a bicycle is very unnatural and very hard to learn compared to a tricycle, and yet in society it has superseded all the tricycles for people over five years old. So the whole idea of high-performance knowledge work is yet to come up and be in the domain. Its still the orientation of automating what you used to do instead of moving to a whole new domain in which you are going to obviously going to learn quite a few new skills.

MIT/Brown Vannevar Bush Symposium, 1995

Grace.

"I've driven a large number of people at least partially nuts. After all insisiting on talking to computers in plain English was a stupid idea and you couldn't do that. Except it worked.

There were a large number of people in the country who did not like talking in symbols. They were not mathematicians and they hated symbols. So let them write their programs in English. It was common sense."

Grace Hopper, creator of COBOL.

Mind Tools.

Just started George Dyson's Darwin Among the Machines.

We are brothers and sisters of our machines. Minds and tools have been sharpened against each other ever since a scavenger's stone fractured cleanly and the first cutting edge was held in a hunter's hand. The obsidian flake and silicon chip are struck by the light of the same campfire that has passed from hand to hand since the human mind began.

I like the symbiotic nature implied by minds and tools 'sharpening' each other.

I also came across this recent interview with superstar App Maker Loren Brichter where he underlines the idea of computers as 'mind tools' and invokes ol' Doug Engelbart in his use of the word 'augment'.

When you’re trying to make things “less terrible,” do you have any greater goals in mind that guide your decisions? Why do you do all this?

Oh yeah, but it’s so abstract that people will think I’m nuts. So for a goal, I’ll just say “build tools to make us more enlightened.” I mean “enlightened” in a Carl Sagan sense, where we are the universe trying to understand itself. And we’ve long hit the limit of what we can think with our naked brain, so we need to augment it in some way with mind tools. But the tools right now are so complicated that it takes all your mental energy just to try and “hold” them, so you have nothing left to actually do something interesting. Or at least they’re too complicated for me. I’m not that smart.

Personally, I’m tired of the trivial app stuff, and the App Store isn’t conducive to anything more interesting. I think the next big thing in software will happen outside of it.

From 0 to C.

Wish there was more online about this education concept from Amsterdam from a few years ago, but all info seems to have been removed.

Through the use of tangible, hand-made objects, we try to establish a clear understanding of how a computer works and what a programming language actually is: nothing but an abstraction of what we can do as humans.

Procedural Literacy.

I recently came across the 2007 paper Procedural Literacy: Educating the New Media Practitioner by programmer and educator Michael Matteas who runs the Center for Games and Playable Media at UC Santa Cruz.

Matteas argues that rather than get caught up in teaching specific programming languages to new media students, the important thing is to get them to think procedurally in the manner encouraged by the explicit logic of code. Furthermore, a grasp of such ways of thinking is important for the 'wider populace' to be more literate in the technology surrounding them. I wholeheartedly agree with so much of this, I wanted to extract some key passages here for commentary and easy future reference.

_

Firstly, Matteas describes a 1961 discussion between Alan Perlis, Peter Elias and our friend J. C. R. Licklider. Perlis wants all students of the time to learn to think programmatically – not a specific language or machine but 'how analysis of some intuitively performed human tasks leads to mechanical algorithms accomplishable by a machine'.

In response Elias imagines that in the near future both computer programs and users will have become advanced enough that only a fraction need ever worry about programming itself. The rest may simply ride their wave.

Elias desires the development of frictionless tools that, like the computers on Star Trek, allow us to make the computer do our bidding with little work (e.g. “Computer, gather data on the anomaly, correlate it with all known space phenomena, and suggest a course of action.” Computer: “Done”). The problem with this vision is that programming is really about describing processes, describing complex flows of cause and effect, and given that it takes work to describe processes, programming will always involve work, never achieving this frictionless ideal. Any tools that reduce the friction for a certain class of programs, will dramatically increase the friction for other classes of programs. Thus, programming tools for artists, such as Flash, make a certain style of in- teractive animation easy to produce, while making other classes of programs difficult to impossible to produce. Every tool carries with it a specific world- view, opening one space of possibilities while closing off others. A procedurally literate practitioner will still make use of specific tools for specific projects, but will be aware of the constraints of specific tools, will be capable of considering a space of computational possibility larger than any specific tool.

Licklider's response is perfect:

“Pete [Elias], I think the first apes who tried to talk with one another decided that learning language was a dreadful bore. They hoped that a few apes would work the thing out so the rest could avoid the bother. But some people write poetry in the language we speak. Perhaps better poetry will be written in the language of digital computers of the future than has ever been written in English.”

From this vantage point Matteas outlines some of his ideas for giving his students a firm grounding in procedural literacy.

Procedural literacy is not just the craft skill of programming, but includes knowing how to read and analyze computational artifacts.

The sense of reading and analyzing computational artifacts is critical. It's this that I think extends beyond any particular study field or domain – this understanding is necessary for everyone if they are to participate in a culture of pervasive technology.

Without a deep understanding of the relationship between what lies on and beneath the screen, scholars are unable to deeply read new media work, while practitioners, living in the prison-house of “art friendly” tools, are unable to tap the true representational power of computation as a medium. The ideal of procedural literacy as necessary, not just for new media practitioners, but as requirement and right of an educated populace, has been with us for over 40 years. Yet the two culture divide persists, with artists and humanists often believing that programming is a narrow technical specialty removed from culture, and computer scientists and engineers often happy to pursue just such an unexamined and narrow focus.

Hinging the issue on the 'Two Cultures' problem is a powerful point. While people may have argued about the division since C. P. Snow's lecture in 1959 (two years before the discussion above) the way technology and code has pervaded culture makes it more critical then ever.

In the same way that people engage language throughout their entire educational trajectory, so to should students engage procedurality. Only then will computation truly become an expression of culture on par with language, image, sound, and physical objects, adding process-based representation to the human conversation.

It's a bold and ambitious view that speaks to me deeply. A really useful anchor for my explorations from here on.