One of the things we’re often grousing about in the computing education and games education communities is programming literacy (some people call this procedural literacy, but I reserve that phrase for a more general concept of literacy, more on this…

As an undergrad at CMU, I became one of the many TA’s for this course. While it was difficult enough to get a painting major to use Excel, I like to imagine that a few weeks could have been spent introducing programming concepts. However I wonder if Perlis realized just how dreadful of a process that would be for some students, who would probably loathe the thought of describing processes in the abstract. I’ve heard some say they think everyone has the capability to program, and while technically this may be true, in practice it could be that for some, just the concept of abstractly representing processes feels so cold and mechanical, they could never bring themselves to do it, or at least not without kicking and screaming.

If anyone has any links to articles on the topic of “why I hate programming”, please share them, it would be interesting to better understand the obstacles to the ideal of procedural literacy.

Starting just with languages with minimal syntax: Scheme and Lisp. Even something like the quote mark operator can be a huge stumbling block for many students – why does ‘foo behave so strangely, and is different from foo and from “foo”? Explaining this requires breaking abstraction barriers away from the nice high-level process description, and going into macroexpansion and internal object representation and a mess of processes underlying the language itself, which students never get. Or the alternative, to gloss over it, and run the risk of students building completely wrong models of its behavior, and having their programs fail in what appear to be arbitrary and capricious ways. It’s immensely frustrating for everyone.

Things get worse with lower-level languages. C, C++, and Java, are all pretty complex syntactically and semantically – statements have to be in blocks, and sometimes they start new blocks, which are sometimes invisible, all depending on the usage of brackets; sometimes they return values, sometimes they don’t; sometimes you can ignore what they return, sometimes you can’t; sometimes they produce side-effects, sometimes they don’t, etc. These languages present mental pieces that have all sorts of sharp edges, weird angles and, worst of all, tend to break in completely unexpected ways.

So in addition to Andrew’s posting, I’d also like to throw in the problem of language frustration. Learning to program requires learning to deal with an endless stream of arbitrary language minutiae; requires not merely precision, but pedantry, until you get the idea of what goes on underneath. But I don’t know whether an intuitive language be designed at all and still be complex enough to be useful.

I think the revolution has been slowly moving along – more a procedural literacy evolution. More people are able to control their computers in more ways now than they could 43 years ago. And there are certainly scripting environments now (such as scripting in Flash or Director, VB, back in the 80’s Hypercard) that enable more people to engage in some degree of procedural authorship. But all of these special purpose environments come at the price of obscuring the full expressive potential of computation. The next stage of procedural literacy is learning to navigate the huge tower of absraction that exists in any computer system, with each layer definining its own little process universe, and with all layers, including the programming languages themselves, contingent human-authored artifacts, each carrying the meanings, assumptions, biases and affordances of their author.

While it was difficult enough to get a painting major to use Excel, I like to imagine that a few weeks could have been spent introducing programming concepts. However I wonder if Perlis realized just how dreadful of a process that would be for some students, who would probably loathe the thought of describing processes in the abstract. I’ve heard some say they think everyone has the capability to program, and while technically this may be true, in practice it could be that for some, just the concept of abstractly representing processes feels so cold and mechanical, they could never bring themselves to do it, or at least not without kicking and screaming.

While programming does have its abstract aspects, it also has the properties of a concrete craft practice. Programmers build these elaborate Rube Goldberg machines, in a practice that feels like a combination of writing and mechanical tinkering. But you’re right that the mechanical tinkering part demands precision. I think a block for many people is not so much abstraction, but the extreme attention to detail demanded by programming. A “loose idea” is not enough – it must be fully described in great detail before it will run on a machine.

So in addition to Andrew’s posting, I’d also like to throw in the problem of language frustration. Learning to program requires learning to deal with an endless stream of arbitrary language minutiae; requires not merely precision, but pedantry, until you get the idea of what goes on underneath.

The “what goes on underneath” part references the fact that every language encodes a model of computation. Full procedural literacy would involve freedom from any particular model. But this is a high standard for literacy. Many programmers happily spend their lives working in imperative languages truly believing that computation is fundamentally about sequences of instructions, with occasional branching and looping. It most decidely is not, any more than computation is fundamentally an eval-apply cycle (list processing langauges), forward chaining rules with no specification of sequencing (rule languages), backward chaining rules with unification (logic languages), or the many higher-level architectures, all of which can be built on top of the others, none more fundamental than the others.

In the standard Intro to CS it takes people a long time to get to the point where there are things they can play with.

Markup is certainly easier than programming, but nevertheless I think the speed with which so many people learned HTML in the mid-90s may be instructive.

People learned HTML by getting the source of other people’s HTML files and then tinkering. Changing things and seeing what worked, taking elements from one page and trying to insert them into another, and so on. Usually looking at an reference or formal definition came later, as did starting any HTML page from scratch.

I think Intro to CS would seem more like it was a course about processes if students started the class with existing, functional processes that they then started to alter and combine. Most Intro to CS, as Rob points out, starts out teaching about syntax — which seems pretty far from the goal of thinking about process.

I’ve been reading some in the CS education literature recently, and I haven’t found anyone advocating this “start with tinkering” approach. Though I did find a report by the AAUW saying that tinkering/exploration is one of the things women really like about later CS classes (and its absence is part of what they dislike in earlier ones).

Am I missing something here?

(1) Teaching procedurality to young kids who have flexible minds and open futures

(2) Teaching procedurality to adults who have never learned any, and have less flexible minds.

(2) seems a lot harder than (1) to me. But I think the problem has less to do with the mechanics of CS instruction — although syntax vs. procedure is a good issue to discuss — and more to do with the students’ lack of previous, foundational experience with procedural systems of any kind. They need to have played more Go, Chess, and Backgammon, to have learned more natural languages (including, perhaps especially, dead languages), played with more Legos, created more amateur architectural plans, learned to dance, etc…

The challenge is that all of those charges are in the past perfect tense. How can you recuperate that?

I have many thoughts on (1), and I may share them here or on WCG soon. I’ve been trying to turn them into an article.

The “start with tinkering” approach is what I tried to do in Computation as an Expressive Medium, an immersion approach to learning programming as opposed to a “memorize the vocabulary and grammar” approach. Interestingly, I had several students in the class who already had strong programming backgrounds (including a couple of people with CS degrees). We talked about having them place out of the course, but decided they should take it because they had never read some of the historical and theoretical material we were reading in the course and had never written the kinds of programs we were writing. As one of them said, “I never got to write interesting programs as a CS major”, which I think was his way of saying that he never got to tinker and really explore programming as a medium.

(2) Teaching procedurality to adults who have never learned any, and have less flexible minds.

(2) seems a lot harder than (1) to me. But I think the problem has less to do with the mechanics of CS instruction — although syntax vs. procedure is a good issue to discuss — and more to do with the students’ lack of previous, foundational experience with procedural systems of any kind.

I think we are in a transitional phase where adults are entering graduate programs in New Media with no prior experience in procedurality. As programs such as Georgia Tech’s new undergraduate degree in Computational Media, which is half CS courses and half Literature Communication and Culture courses, are created, I think we can expect that future graduate students in New Media will have programming experience. And even for those students who come into graduate New Media programs without an undergraduate background in New Media, in the future we can expect that they learned to program in elementary school. One of the things I like about the phrase “procedural literacy” is that it immediately conjures its opposite, implying that an inability to think procedurally really is a form of illiteracy, with as dire harmful consequences as the inability to read and write.

But, even when we can expect that all students entering graduate New Media programs are procedurally literate, there will still be a need for courses that explore procedurality as a medium, that explore the interrelationship between conceptual and theoretical concerns and code. This goes beyond merely knowing how to program, and is really about being able to conceptually think about code.

[Group 2 does not]

I don’t think group 1 exists. I don’t think it is going to magically appear in twenty years, just because third graders have computers in the classroom.

Okay, yes, there will be a handful of these ideal students who will be procedurally literate as a result of all the right accidents in their education, but I doubt they will ever occur in meaningful numbers. It is, in fact, the goal of education, specifically for higher education (because I don’t see how it would occur any earlier) to provide this literacy. And, to be a pessimist, I don’t see procedural literacy becoming a priority in our lifetimes.

My experience has been that CS majors are taught the mechanics of the tools, and expected to do a lot of this tinkering on their own to complement their education. For example, a good CS graduate picks up most language knowlege on their own, from coding within and outside of class. Like natural language learning via immersion. :)

But even then they’re rarely taught the creative aspects, just the mechanics. Like Michael mentions, it can be quite hard to find projects that guide experimentation with programming as a creative medium – which is why classes like his are really exciting news.

Michael: Full procedural literacy would involve freedom from any particular model. But this is a high standard for literacy.

I’m also wondering what’s required to attain this standard, and what it is, exactly. I mean, in speaking of procedural literacy, we’re going above mere syntax, above data structure considerations; we’re going above algorithm analysis and cost trade-offs; we’re even above particular models of computation, imperative to functional, to inference-based, etc.

But this is where my imagination fails me. What exactly is this procedural literacy that gives one freedom from the messiness of particular models of computation, but could also be taught to beginners? I mean, full literacy in computer science does eventually lead to that kind of a gestalt vision, but that’s not what you have in mind, is it?

I’ll agree with that. But I’d also argue that procedurality is not limited to code, as I hinted above.

Brandon — t is, in fact, the goal of education, specifically for higher education (because I don’t see how it would occur any earlier) to provide this literacy

I think you’re dead wrong on this. This has to start a lot earlier. Think about kids’ receptivity to the conceptual and symbolic at a young age. This has to happen now, not later.

But I think you missed my main point, which is that you should never expect a procedurally literate student to walk into your classroom. You have to teach it. And, to make it more challenging, you shouldn’t need to use a computer to do it.

Clearly, you have no experience with kids or their education. Procedural literacy starts at the earliest of stages, and as I argued can begin with extra-curricular media such as board games, toys, and other media, as I explicitly suggested above. Furthermore, personalities like Seymour Papert and Alan Kay have created means for kids to learn about programming from a very early age, since the mid 1970s. Futhermore, even if one were willing to admit that US curricula were replete with valuable learning (which I am not), your suggestion that such curricula are “chock full” wreaks of a massive misunderstanding of the inherent problems of institutionalized education today. The notion that Michael and my suggestions about procedural literacy correspond or participate with any “accepted” notion of primary public education in the contemporary USA leave me in the most confused of states, given that both of us are arguing for a change in pedagogical approaches.

Your suggestion that the responsibility to teach kids in any kind of topic that exceeds the current educational modalities suggests not only that you chose to ignore my insistence that procedurality must be cultivated at any early age, but also that your understanding of the topic at hand is deeply deluded. Were teachers like Michael and I (yes, we’ve actually taught!) expecting a wealth of procedurally literate students to waltz into our program, do you think we would discuss such topics with such devoted interest and attention? Or perhaps you simply hope to exercise some kind of glib trump card in arguing that computers aren’t useful systems of computation, or that my own entirely non-computer based suggestions of principal tools for procedural learning simply do not qualify for the blindered, broad-based objections you raise.

If ever you choose to consider any of the issues on this or other public forums in a way that wreaks of anything but disdain and anitpathy, I shall consider responding further. Until then, I wish you the best of luck in your antipathetic antimodalism.

Well, first of all I will take Ian’s response as an admission that you are indeed a revolutionary, seeking not simply to push the educational system down a better path, but to overturn it in favor of radical new ideas. (Ideas that aren’t new with respect to Papert and Kay, but would certainly be a new pedagogy at the little red schoolhouse.)

My first response to this was to directly question the feasibility of such an action. My instinct was to look at how this “procedural literacy” could fit in with the real and everyday institutions of education. My mistake! The bomb-lobbing revolutionaries are going to do away with all the old institutions. Papert and Kay were only the first wave, and now it is up to you, my young BFG-toting soldier, to carry on the fight!

Enough with the levity. I am overly glib, that is true. Because I see a solid lack of any critical foundation for all of these radical new ideas, for the fad that is ludology, for the clever slight-of-hand that is trying to replace “computers in the classroom” with “games in the classroom”. Yes, I have big problems with the current state of education as well, but I also think that the “cognitive revolution” that accompanied the rise of the modern computer is deeply flawed. Which makes me a reactionary against the ideas of Papert and Kay.

You are welcome to address my perspective in whatever forum appeals most to you.

Something like a gestalt may be what I have in mind. And no, it’s not something that can be taught to beginners. That’s why I said it’s a high standard for procedural literacy, a level that many programmers with degrees in computer science may not have. What I mean is the ability to think architecturally about computation, to invent new representations and languages as you need them, to mix-and-match different computational concepts, to not be blindered by any one model of computation. But getting there means being exposed in turn to many models of computation, something that won’t happen in one introductory course. Abelson and Suchman’s The Structure and Interpretation of Computer Programs is indeed and intro to CS that, in a first course on programming, has you do things like write interpreters for computer languages. So it tries to accelerate this architecturalist understanding of computation. I don’t know how well it works in this regard. Any comments? And it certainly has the wrong focus as an introductory approach to teaching procedural literacy for new media scholars and practitioners.

A Priori Attention to Eventualities Regardless of Likelihood. The development of a mechanical attitude toward mechanical processing requires that processing of even unlikely cases by provided for. The programming of the solution of a quadratic equation and the analysis of the general second-degree equation in two variables to select conic sections are good examples where many students fail to provide for eventualities. The willingness to program through a tedious collection of tests on special cases must be fostered. (emphasis added)

Because people really did feel free to play with the exercises in the text, tweaking them and making them more amusing and more fun.

It’s been a good number of years since I took the course that used that text, and honestly, I really wouldn’t mind going through it again. A fugue of epiphanies were in that little purple book for me.

What would be great is if a semester class is introduced, like methodology classes for pgrads who come from artistic backgrounds, where programming is taught as a necessary intro for all NM pgrads.

But with its emphasis on solving math and EE problems, it’s horrible for teaching anyone but engineering undergrads. Those frustrate the non-engg people – but to change the emphasis, some work would have to go into building good graphics and media wrappers for Scheme that the students could easily use, and practically rewriting whole sub-chapters of the book… :)

The visual tools can be used to help visualize the procedures themselves – I remember being shown an almost abstract visualization of sort algorithms that did an excellent job in helping train my own visualization (and, for me, and perhaps for many others, it’s the internal visualization, the transformation of the procedures into spatio-visual metaphors in my head – and hopefully, the right metaphors with the right entailments – that compromises much of the real learning.)

One tool, in fact, that could be helpful would be a visual metaphor output to a debugger, that simultaneously output approriate visualizations for conditionals, loops, algorithms, et al while simultaneously bouncing through the code.

William, I agree that teaching programming for artists and humanists shouldn’t be only about the visual. In fact, for the assignments I gave the first time I taught computation as an expressive medium, only one of them was explicitly about producing imagery – the rest were about treating the web as a data structure, creating tools for image manipulation (pushing on the notion that tools themselves are authored, and should be considered as a space for intervention), and text interaction.

One of my concerns about using scheme, however, would be the issue of a community of practice. For a language such as Java, there are many artists already using it, which means that there are many people to talk to, large amounts of code available to build upon and so forth, when doing creative work with Java. Because of the ubiquity of Java VMs in web browsers, the web can easily be used as a mechanism for viewing Java-based work. I think one of the goals of such a class should be to not only increase procedural literacy, but give the students concrete skills in a language that’s already broadly used and that they can start using in their own practice.

In your list of procedural concepts, we did cover recursion, environments, scope and assignment using Java, but not meta-circular evaluation. The last is of course critical for thinking about how to implement interpreters for your own languages. But I think there’s no way I’d teach meta-circular evaluation in a computation as an expressive medium course. Remember that the students in such a class, unlike SICP students, are also reading historical and theoretical texts in new media, and have to connect the readings to the programming material. So they’re doing some extra conceptual work that the SICP students aren’t. A programming course for humanists and artists should not be thought of as dumbed down CS, or CS made friendly, but rather as an alternative CS curriculum. It’s all right for it to be hard, to be “splodey”, but there are many different ways to be “splodey” besides teaching traditional CS material. Incidently, the Java students are also learning about OO design (which is really knowledge representation), a concept that the scheme students don’t get.

One tool, in fact, that could be helpful would be a visual metaphor output to a debugger, that simultaneously output approriate visualizations for conditionals, loops, algorithms, et al while simultaneously bouncing through the code.

Very nice idea! Points towards some of the interesting tool development that should be done to support the teaching of procedural literacy.

Brandon, I don’t quite follow the connection between game studies and teaching procedural literacy. While games are certainly an instance of a procedural medium, the concept of procedural literacy is much broader than games. As far as the cognitive revolution, which in its uncritical formulations treats humans as information processors identical to contemporary computers, the only antidote would seem to be procedural literacy. Only through an understanding of programming and how computers really operate could someone gain a deep understanding of the similarities and differences between human experience and computation.

In our intro to CS class, though, we did do OO work in Scheme. It was spun out of the assignment section of SICP, and including implementing a primitve OO framework using message-passing. It was in those exercises, too, that students were able to be the most creative, designing an OO virtual world of restaurant-objects and food-objects, along with the usual ATM and bank account objects. In defense of Scheme, it makes it easy to teach OO by actually implementing it, rather than receiving it full-formed from the forehead of Zeus, as it were.

Nice strawman there, William. :)

No, just “adding pictures” would be absurd; it ameliorates nothing. On the other hand, things need to be approached differently, because some of the assumptions SICP makes about math and engineering backgrounds of its readers are simply false in our current context.

Take the calculus assignment in ch. 2, where students write a pattern-matching system that takes an equation and performs symbolic differentiation. Or, for that matter, the analog circuit simulator from ch. 3, which is really just an excuse to introduce streams (they’re like wires :), and delayed evaluation. They’re fun assignments, but unnecessarily difficult for those who never took basic engineering courses. There’s no reason to make Calculus I and Intro to Circuits into prerequisites for teaching pattern matching and streams.

I think there is danger in the promotion of procedural literacy for its own sake. Yes, people should study these things in order to contrast experience and computation, but unless you make that the explicit goal — the contrast, the critique — you end up with procedural literacy for its own sake.

So, speaking as a reactionary, I’m not sure that computers should ever be allowed into the classroom, because their presence clouds the issue of what should be taught — an understanding of processes versus skills to make the computer do cool stuff. Only when there are technical goals for a course should you need students to sit at a computer, and that time should not be considered as instructional time.

Which opens up the question: how can procedural literacy be presented without a computer? There are plenty of ways to present mechanical computation without a CRT, but they have become neglected.