Knowing and Doing

I enjoyed Reg Braithwaite's talk Ruby.rewrite(Ruby) (slides available on-line). It gives a nice survey of some metaprogramming hacks related to Ruby's syntactic and semantic structure.

To me, one of the most thought-provoking things Reg says is actually a rather small point in the overall message of the talk. Object-oriented programming is, he summarizes, basically a matter a matter of nouns and verbs, objects and their behaviors. What about other parts of speech? He gives a simple example of an adverb:

blitz.not.blank?

In this expression, not is an adverb that modifies the behavior of blank?. At the syntactic level, we are really telling blitz to behave differently in response to the next message, which happens to be blank?, but from the programmer's semantic level not modifies the predicate blank?. It is an adverb!

Reg notes that some purists might flag this code as a violation of the Law of Demeter, because it sends a message to an object received from another message send. But it doesn't! It just looks that way at the syntax level. We aren't chaining two requests together; we are modifying how one of the requests works, how its result is to be interpreted. While this may look like a violation of the Law of Demeter, it isn't. Being able to talk about adverbs, and thus to distinguish among different kinds of message, helps to make this clear.

It also helps us to program better in at least two ways. First, we are able to use our tools without unnecessary guilt at breaking the letter of a law that doesn't really apply. Second, we are freed to think more creatively about how our programs can say what we mean. I love that Ruby allows me to create constructs such as not and weave them seamlessly into my code. Many of my favorite gems and apps use this feature to create domain-specific languages that look and feel like what they are and look and feel like Ruby -- at the same time. Treetop is an example. I'd love to hear about your favorite examples.

So, our OO programs have nouns and verbs and adverbs. What about other parts of speech? I can think of at least two from Java. One is pronouns. In English, this is a demonstrative pronoun. It is in Java, too. I think that super is also demonstrative pronoun, though it's not a word we use similarly in English. As an object, I consist of this part of me and that (super) part of me.

Another is adjectives. When I teach Java to students, I usually make an analogy from access modifiers -- public, private, and protected -- to adjectives. They modify the variables and methods which they accompany. So do synchronized and volatile.

Once we free ourselves to think this way, though, I think there is something more powerful afoot. We can begin to think about creating and using our own pronouns and adjectives in code. Do we need to say something in which another part of speech helps us to communicate better? If so, how can we make it so? We shouldn't be limited to the keywords defined for us five or fifteen or fifty years ago.

Thinking about adverbs in programming languages reminds me of a wonderful Onward! talk I heard at the OOPSLA 2003 conference. Cristina Lopes talked about naturalistic programming. She suggested that this was a natural step in the evolution from aspect-oriented programming, which had delocalized references within programs in a new way, to code that is concise, effective, and understandable. Naturalistic programming would seek to take advantage of elements in natural language that humans have been using to think about and describe complex systems for thousand of years. I don't remember many of the details of the talk, but I recall discussion of how we could use anaphora (repetition for the sake of emphasis) and temporal references in programs. Now that my mind is tuned to this wavelength, I'll go back to read the paper and see what other connections it might trigger. What other parts of speech might we make a natural part of our programs?

(While writing this essay, I have felt a strong sense of deja vu. Have I written a previous blog entry on this before? If so, I haven't found it yet. I'll keep looking.)

One of my colleagues is an old-school C programmer. He can make the machine dance using C. When C++ came along, he tried it for a while, but many of the newly-available features seemed like overkill to him. I think templates fell into that category. Other features disturbed him. I remember him reporting some particularly bad experiences with operator overloading. They made code unreadable! Unmaintainable! You could never be sure what + was doing, let alone operators like () and casts. His verdict: Operator overloading and its ilk are too powerful. They are fine in theory, but real languages should not provide so much freedom.

Some people don't like languages with features that allow them to reconfigure how the language looks and works. I may have been in that group once, long ago, but then I met Lisp and Smalltalk. What wonderful friends they were. They opened themselves completely to me; almost nothing was off limits. In Lisp, most everything was open to inspection, code was data that I could process, and macros let me define my own syntax. In Smalltalk, everything was an object, including the integers and the classes and the methods. Even better, most of Smalltalk was implemented in Smalltalk, right there for me to browse and mimic... and change.

Once I was shown a world bigger than Fortran, PL/I, and Pascal, I came to learn something important, something Giles Bowkett captures in his inimitable, colorful style:

There is no such thing as metaprogramming. It's all just programming.

(Note: "Colorful" is a euphemism for "not safe to read aloud at work, nor to be read by those with tender sensibilities".)

Ruby fits nicely with languages such as Common Lisp, Scheme, and Smalltalk. It doesn't erect too many boundaries around what you can do. The result can be disorienting to someone coming from a more mainstream language such as Java or C, where boundaries between "my program" and "the language" are so much more common. But to Lispers, Schemers, and Smalltalkers, the freedom feels... free. It empowers them to express their ideas in code that is direct, succinct, and powerful.

Actually, when you program in C, you learn the same lesson, only in a different way. It's all just programming. Good C programmers often implement their own little interpreters and their own higher-order procedures as a part of larger programs. To do so, they simply create their own data structures and code to manipulate them. This truth is the raw material out of which Greenspun's Tenth Rule of Programming springs. And that's the point. In languages like C, if you want to use more powerful features, and you will, you have to roll them for yourself. My friends who are "C weenies" -- including the aforementioned colleague -- take great pride in their ability to solve any problem with just a bit more programming, and they love to tell us the stories

Metaprogramming is not magic. It is simply another tool in the prepared programmer's toolbox. It's awfully nice when that tool is also part of the programming language we use. Otherwise, we are limited in what we can say conveniently in our programs by the somewhat arbitrary lines drawn between real and meta.

You know what? Almost everything in programming looks like magic to me. That may seem like an overstatement, but it's not. When I see a program of a few thousand lines or more generate music, play chess, or even do mundane tasks like display text, images, and video in a web browser, I am amazed. When I see one program convert another into the language of a particular machine, I am amazed. When people show me shorter programs that can do these things, I am even more amazed.

The beauty of computer science is that we dig deeper into these programs, learn their ideas, and come to understand how they work. We also learn how to write them ourselves.

It may still feel like magic to me, but in my mind I know better.

Whenever I bump into a new bit of sorcery, a new illusion or a new incantation, I know what I need to do. I need to learn more about how to write programs.

I really enjoyed reading the text of William Cook's banquet speech at ECOOP 2009. When I served as tutorials chair for OOPSLA 2006, Cook was program chair, and that gave me a chance to meet him and learn a bit about his background. He has an interesting career story to tell. In this talk, he tells us this story as a way to compare and contrast computer science in academia and in industry. It's well worth a read.

As a doctoral student, I thought my career path might look similar to Cook's. I applied for research positions in industry, with two of the Big Six accounting firms and with an automobile manufacturer, at the same time I applied for academic positions. In the end, after years of leaning toward industry, I decided to accept a faculty position. As a result, my experience with industrial CS research and development is limited to summer positions and to interactions throughout grad school.

Cook's talk needs no summary; you should read it for yourself. Here are a few points that stood out to me as I read:

Venture capitalists talk about pain killers versus vitamins. A vitamin is a product that might make you healthier over the long run, but it's hard to tell. Pain killers are products where the customer screams "give it to me now" and asks what it costs later. Venture capitalists only want to fund pain killers.

This is true not only of venture capitalists, but of lots of people. As a professor, I recognize this in myself and in my students all of the time. Cook points out that most software development tools are vitamins. So are many of the best development practices. We need to learn tools and practices that will make us most productive and powerful in the long run, but without short-term pain we may not generate the resolve to do so.

We read all the standard references on OO for business applications. It didn't make sense to us. We started investigating model-driven development styles. We created modeling languages for data, user interfaces, security and workflow. These four aspects are the core of any enterprise application. We created interpreters to run the languages, and our interpreters did many powerful optimizations by weaving together the different aspects.

To me, this part of the talk exemplifies best how a computer scientist thinks differently than a non-computer scientist, whether experienced in software development or not. Languages are tools we create to help us solve problems, not merely someone else's solutions we pluck off the shelf. Language processors are tools we create to make our languages come to life in solving instances of actual problems.

The way I see it is that industry generally has more problems than they do solutions, but academia often has more solutions than problems.

Cook makes a great case for a bidirectional flow between industry, with its challenging problems in context, and academia, with its solutions built of theory, abstraction, and design. This transfer can be mutually beneficial, but it is complicated by context:

Industrial problems are often messy and tied to specific technical situations or domains. It is not easy to translate these complex problems into something that can be worked on in academia. This translation involves abstraction and selection.

The challenge is greatest when we then take solutions to problems abstracted from real-world details and selected for interestingness more than business value and try to re-inject them into the wild. Too often, these solutions fail to take hold, not because people in industry are "stupid or timid" but because the solution doesn't solve their problem. It solves an ideal problem, not a real one. The translation process from research to development requires a finishing step that people in the research lab often have little interest in doing and that people in the development studio have little time to implement. The result is a disconnect that can sour the relationship unnecessarily.

Finally, the talk is full of pithy lines that I hope to steal and use to good effect sometime soon. Here is my favorite:

Simplicity is not where things start. ... It is where they end.

Computer scientists seek simplicity, whether in academia or in industry. Cook gives us some clues in this talk about how people in these spheres can understand one another better and, perhaps, work better together toward their common goal.

I didn't write this comment on the blog entry Wa: The key to clear, harmonious design:

I know that you are talking about visual design, but I am struck by how this approach applies to many other domains.

But I could have.

I started university life intending to become an architect, and my interest in visual design has remained strong through the years. I was delighted when I learned of Christopher Alexander's influence on some in the software world, because it gave me more opportunities to read and think about architectural design -- and to think about how its ideas relate to how we design software. I am quite interested in the notion that there are universal truths about design, and even if not what we can learn from designers in other disciplines.

Garr Reynolds identifies seven principles of the Zen aesthetic of harmony. Like the commenter, my thoughts turned quickly from the visual world to another domain. For me, the domain is software. How well do these principles of harmony apply to software? Several are staples of software design. Others require more thought.

(1) Embrace economy of materials and means
(3) Keep things clean and clutter-free

These are no-brainers. Programmers want to keep their code clean, and most prefer an economical style, even when using a language that requires more overhead than they would like.

(6) Think not only of yourself, but of the other (e.g., the viewer).

When we develop software, we have several kinds of others to consider. The most obvious are our users. We have disciplines, such as human-computer interaction, and development styles, such as user-centered design, focused squarely on the people who will use our programs.

We also need to think of other programmers. These are the people who will read our code. Software usually spends much more time in maintenance than in creation, so readability pays off in a huge way over time. We can help our readers by writing good documentation, an essential complement to our programs. However, the best way to help our readers is to write readable code. In this we are more like Reynolds's presenters. We need to focus on the clarity and beauty of our primary product.

Finally, let's not forget our customers and our clients, the people who pay us to write software. To me, one of the most encouraging contributions of XP was its emphasis on delivering tangible value to our customers every day.

(7) Remain humble and modest.

This is not technical advice. It is human advice. And I think it is underrated in too many contexts.

I have worked with programmers who were not humble enough. Sadly, I have been that programmer, too.

A lack of humility almost always hurts the project and the team. Reynolds is right in saying that true confidence follows from humility and modesty. Without humility, a programmer is prone to drift into arrogance, and arrogance is more dangerous than incompetence.

A programmer needs to balance humility against gumption, the hubris that empowers us to tackle problems which seem insurmountable. I have always found that humility is a great asset when I have the gumption to tackle a big problem. Humility keeps me alert to things I don't understand or might not see otherwise, and it encourages me to take care at each step.

... Now come a couple of principles that cause me to thing harder.

(2) Repeat design elements.

Duplication is a bane to software developers. We long ago recognized that repetition of the same code creates so many problems for writing and modifying software that we have coined maxims such as "Don't repeat yourself" and "Say it one once and only once." We even create acronyms such as DRY to get the idea across in three spare letters.

However, at another level, repetition is unavoidable. A stack is a powerful way to organize and manipulate data, so we want to use one whenever it helps. Rather than copy and paste the code, we create an abstract data type or a class and reuse the component by instantiating it.

Software reuse of this sort is how programmers repeat design elements. Indeed, one of the most basic ideas in all of programming is the procedure, an abstraction of a repeated behavioral element. It is fundamental to all programming, and one of the contributions that computer science made as we moved away from our roots in mathematics.

In the last two decades, programmers have begun to embrace repeatable design units at higher levels. Design patterns recur across contexts, and so now we do our best to document them and share them with others. Architectures and protocols and, yes, even our languages are ways to reify recurring patterns in a way that makes using them as convenient as possible.

(4) Avoid symmetry.

Some programmers may look at this principle and say, "Huh? How can this apply? I'm not even sure what it means in the context of software."

When linguistic structures and data structures repeat, they repeat just as they are, bringing a natural symmetry to the algorithms we use and the code we write. But at the level of design patterns and architectures, things are not so simple. Christopher Alexander, the building architect who is the intellectual forefather of the software patterns community, famously said that a pattern appears a million times, but never exactly the same. The pattern is molded to fit the peculiar forces at play in each system. This seems to me a form of breaking symmetry.

But we can take the idea of avoiding symmetry farther. In the mathematical and scientific communities, there has long been a technical definition of symmetry in groups, as well as a corresponding definition of breaking symmetry in patterns. Only a few people in the software community have taken this formal step with design patterns. Chief among them are Jim Coplien and Liping Zhao. Check out their book chapter, Symmetry Breaking in Software Patterns, if you'd like to learn more.

A few years ago I was able to spend some time looking at this paper and at some of the scientific literature on patterns and symmetry breaking. Unfortunately, I have not been able to return to it since. I don't yet fully understand these ideas, but I think I understand enough to see that there is something important here. This glimmer convinces me that avoiding symmetry is perhaps an important principle for us software designers, one worthy of deeper investigation.

... This leaves us with one more principle from the Presentation Zen article:

(5) Avoid the obvious in favor of the subtle

This is the one principle out of the seven that I think does not apply to writing software. All other things being equal, we should prefer the obvious to the subtle. Doing something that isn't obvious is the single best reason to write a comment in our code. When we must do something unexpected by our readers, we must tell them what we have done and why. Subtlety is an impediment to understanding code.

Perhaps this is a way in which we who work in software differ from creative artists. Subtlety can enhance a work of art, by letting -- even requiring -- the mind to sense, explore, and discover something beyond the surface. As much art as there is in good code, code is at its core a functional document. Requiring maintenance programmers to mull over a procedure and to explore its hidden treasures only slows them down and increases the chances that they will make errors while changing it.

I love subtlety in algorithms and designs, and I think I've learned a lot from reading code that engages me in a way I've not experienced before. But there is something dangerous about code in which subtlety becomes more important than what the program does.

Blaine Buxton recently wrote a nice entry on the idea of devilishly clever code:

But, it got me thinking about clever and production code. In my opinion, clever is never good or wanted in production code. It's great to learn and understand clever code, though. It's a great mental workout to keep you sharp.

Maybe I am missing something subtle here; I've been accused of not seeing nuance before. This may be like the principle of avoiding symmetry, but I haven't reached the glimmer of understanding yet. Certainly, many people speak of Apple's great success with subtle design that engages and appeals to users in a way that other design companies do not. Others, though attribute its success to creating products that are intuitive to use. To me, intuitiveness points more to obviousness and clarity than to subtlety. And besides, Apple's user experience is at the level of design Reynolds is talking about, not at the level of code.

I would love to hear examples, pro and con, of subtlety in code. I'd love to learn something new!

A while back -- a year? two? -- the folks at the College Board announced some changes to the way they would offer the AP exams in computer science. I think the plan was to eliminate the B exam (advanced) and redesign the A exam (basic). At the time, there was much discussion among CS educators, at conferences, on the SIGCSE mailing list, and in a few blogs. In 2008 sometime, I read a CACM article by a CS educator on the issue. Her comments were interesting enough that I made some notes in the margins and set the article aside. I also collected a few of my thoughts about the discussions I had read and heard into a text file. I would write a blog article!

But I never did.

I went looking for that text file today. I found it in a folder named recent/, but it is not recent. The last time I touched the file was Tuesday, December 9, 2008.

I guess it wasn't all that urgent after all.

Actually, this isn't all that uncommon for blog article ideas. Many come to mind, but few make it to the screen. Yet this seems different. When the original news was announced, the topic seemed so urgent to many of my close friends and colleagues, and that made it seem urgent to me. The Future of Computer Science in the High Schools was at stake. Yet I could never bring myself to write about the article.

To be honest, it is hard for me to care much about AP. I have been teaching at my university for over seventeen years, and I cannot recall a single student who asked us about AP CS credit. We simply never see it.

Computer programming courses long ago disappeared from most high schools in my state. I am willing to wager that no Iowa schools ever taught computer science qua computer science; if any did, the number was nearly zero. Even back in the early to mid-1990s when dedicated CS courses existed, they were always about learning to program, usually in Basic or Pascal. That made sense, because the best way to help high school students get ready for the first college CS course is to introduce them to programming. Whatever you think about programming as the first course, that is the way most universities work, as well as nearly every college in Iowa. Those programming courses could have been AP courses, but most were not.

Unfortunately, falling budgets, increasing demands in core high school subjects, and a lack of certified CS teachers led many schools to cut their programming courses. If students in my state see a "computer course" in high school these days, it is almost always a course on applications, usually productivity tools or web design.

Maybe I am being self-centered in finding it hard to care about the AP CS exams. We do not see students with AP CS credit or receive inquiries about its availability here. AP CS matters a lot to other people, and they are better equipped to deal with the College Board and the nature and content of the exams.

Then again, maybe I am being short-sighted. Many argue that AP CS is the face of computer science in the high schools, and for better or worse it defines what most people in the K-12 world think CS is. I am less bothered with programming as the focus of that course than many of my friends and colleagues. I'm even sympathetic to Stuart Reges's ardent defense of the current exam structure at his site to preserve it in the penumbra of the University of Washington. But I do think that the course and exam could do a better job of teaching and testing programming than it has over the last decade or so.

Should the course be more than programming, or different altogether? I am open to that, too; CS certainly is more than "just programming". Alas, I am not sure that the academic CS world can design a non-programming high school CS course that satisfies enough of the university CS departments to garner widespread adoption.

But for someone at a university like mine, and in a state like mine, all of the money and mindshare spent on AP Computer Science seems to go for naught. It may benefit the so-called top CS programs, the wealthier school districts, and the students in states where computing already has more of a presence in the high school classroom. In my context? It's a no-op.

Why did I dig a ten-month old text file out for blogging now? There is much ado again about AP CS in light of the Georgia Department of Education announcing that AP Computer Science would no longer count towards high school graduation requirements. This has led to a wide-ranging discussion about whether CS should count as science or math (the TeachScheme! folks have a suggestion for this), the content of the course, and state curriculum standards. Ultimately, the issue comes down to two things: politics, both educational and governmental, and the finite number of hours available in the school day.

So, I will likely return to matters of greater urgency to my university and my state. Perhaps I am being short-sighted, but the simple fact is this. The AP CS curriculum has been around for a long time, and its existence has been of no help in getting my state to require or endorse high school CS courses, certify high school CS teachers, or even acknowledge the existence of computer science as a subject or discipline essential to the high school curriculum. We will continue to work on ways to introduce K-12 students to computer science and to help willing and interested schools to do more and better CS-related material. The AP CS curriculum is likely to have little or no effect on our success or failure.

Artificial. Tyler Cowen writes about a new arena of battle for the Turing Test:

I wonder when the average quality of spam comment will exceed the average quality of a non-spam comment.

This is not the noblest goal for AI, but it may be one for which the economic incentive to succeed drives someone to work hard enough to do so.

Oh So Real. I have written periodically over the last sixteen months about being sick with an unnamed and undiagnosed malady. At times, I was sick enough that I was unable to run for stretches of several weeks. When I tried to run, I was able to run only slowly and only for short distances. What's worse, the symptoms always returned; sometimes they worsened. The inability of my doctors to uncover a cause worried me. The inability to run frustrated and disappointed me.

Yesterday I read an essay by a runner about the need to run through a battle with cancer:

I knew, though, if I was going to survive, I'd have to keep running. I knew it instinctively. It was as though running was as essential as breathing.

Jenny's essay is at turns poetic and clinical, harshly realistic and hopelessly romantic. It puts my own struggles into a much larger context and makes them seem smaller. Yet in my bones I can understand what she means: "... that is why I love running: nothing me feel more alive. I hope I can run forever."

Today brought high contrast to my daily duties.

I spent my morning preparing a talk on computer science, careers, and job prospects for an audience of high school counselors from around the state. Then I gave the talk and lunched with them. Both prep and presentation were a lot of fun! I get to take some element of computer science and use it as a way to communicate how much fun CS and why these counselors should encourage their students to consider CS as a major. Many of the adults in my audience were likely prepared for the worst, to be bored by a hard topic they don't understand. Seeing the looks in their eyes when they saw how an image could be disassembled and reassembled to hide information -- I hope the look in my eyes reflected it.

Early afternoon found me working on next semester's schedule of courses and responding to requests for consultations on curricular changes being made by another department. The former is in most ways paperwork, seemingly for paperwork's sake. The latter requires delicate language and, all too frequently, politics. Every minute seems a grind. This is an experience of getting caught up in stupid details, administration style.

I ended the day by visiting with a local company about a software project that one of our senior project courses might work on. I learned a little about pumps and viscosity and flow, and we discussed the challenges they face in deploying an application that meets all their needs. Working on real problems with real clients is still one of the great things about building software.

Being head of our department has brought me more opportunities like the ones that bookended my day, but it has also thrust me into far too many battles with paperwork and academic process and politics like the ones that filled the in-between time. After four-plus years, I have not come to enjoy that part of the job, even when I appreciate the value it can bring to our department and university when I do it well. I know it's a problem when I have to struggle to maintain my focus on the task at hand just to make progress. Such tasks offer nothing like the flow that comes from preparing and giving a talk, writing code, or working on a hard problem.

A few months ago I read about a tool called Freedom, which "frees you from the distractions of the internet, allowing you time to code, write, or create." (It does this by disabling one's otherwise functional networking for up to eight hours.") I don't use Freedom or any tool like it, but there are moments when I fear I might need one to keep doing my work. Funny, but none of those moments involve preparing and giving a talk, writing code, or working on a hard problem.

Tim Bray said it well:

If you need extra mental discipline or tool support to get the focus you need to do what you have to do, there's nothing wrong with that, I suppose. But if none of your work is pulling you into The Zone, quite possibly you have a job problem not an Internet problem.

Fortunately, some of my work pulls me into The Zone. Days like today remind me how much different it feels. When I am mired in a some tarpit outside of the zone, it's most definitely not an Internet problem.

Yesterday evening, in between volleyball games, I had a chance to do some reading. I marked several one-liners to blog on. I planned a disconnected list of short notes, but after I started writing I realized that they revolve around a common theme: change.

Over the last few months, Kent Beck has been blogging about his experiences creating a new product and trying to promote a new way to think about his design. In his most recent piece, Turning Skills into Money, he talks about how difficult it can be to create change in software service companies, because the economic model under which they operates actually encourages them to have a large cohort of relatively inexperienced and undertrained workers.

The best line on that page, though, is a much-tweeted line from a comment by Niklas Bjørnerstedt:

A good team can learn a new domain much faster than a bad one can learn good practices.

I can't help thinking about the change we would like to create in our students through our software engineering course. Skills and good practices matter. We cannot overemphasize the importance of proficiency, driven by curiosity and a desire to get better.

Then I ran across Jason Fried's The Next Generation Bends Over, a salty and angry lament about the sale of Mint to Intuit. My favorite line, with one symbolic editorial substitution:

Is that the best the next generation can do? Become part of the old generation? How about kicking the $%^& out of the old guys? What ever happened to that?

I experimented with Mint and liked it, though I never convinced myself to go all the way it. I have tried Quicken, too. It seemed at the same time too little and too much for me, so I've been rolling my own. But I love the idea of Mint and hope to see the idea survive. As the industry leader, Intuit has the leverage to accelerate the change in how people manage their finances, compared to the smaller upstart it purchased.

For those of us who use these products and services, the nature of the risk has just changed. The risk with the small guy is that it might fold up before it spreads the change widely enough to take root. The risk with the big power is that it doesn't really get it and wastes an opportunity to create change (and wealth). I suspect that Intuit gets it and so hold out hope.

Still... I love the feistiness that Fried shows. People with big ideas and need not settle. I've been trying to encourage the young people with whom I work, students and recent alumni, to shoot for the moon, whether in business or in grad school.

This story meshed nicely with Paul Graham's Post-Medium Publishing, in which Graham joins in the discussion of what it will be like for creators no longer constrained by the printed page and the firms that have controlled publication in the past. The money line was:

... the really interesting question is not what will happen to existing forms, but what new forms will appear.

Change will happen. It is natural that we all want to think about our esteemed institutions and what the change means for them. But the real excitement lies in what will grow up to replace them. That's where the wealth lies, too. That's true for every discipline that traffics in knowledge and ideas, including our universities.

Finally, Mark Guzdial ruminates on what changes CS education. He concludes:

My first pass analysis suggests that, to make change in CS, invent a language or tool at a well-known institution. Textbooks or curricula rarely make change, and it's really hard to get attention when you're not at a "name" institution.

I think I'll have more to say about this article later, but I certainly know what Mark must be feeling. In addition to his analysis of tools and textbooks and pedagogies, he has his own experience creating a new way to teach computing to non-majors and major alike. He and his team have developed a promising idea, built the infrastructure to support it, and run experiments to show how well it works. Yet... The CS ed world looks much like it always has, as people keep doing what they've always been doing, for as many reasons as you can imagine. And inertia works against even those with the advantages Mark enumerates. Education is a remarkably conservative place, even our universities.

"Only one, but it's always the right one."
-- Jose Raoul Capablanca,
when asked how many moves ahead
he looked while playing chess

When I was in high school, I played a lot of chess. That's also when I first learned about computer programming. I almost immediately was tantalized by the idea of writing a program to play chess. At the time, this was still a novelty. Chess programs were getting better, but they couldn't compete with the best humans yet, and I played just well enough to know how hard it was to play the game really well. Like so many people of that era, I thought that playing chess was a perfect paradigm of intelligence. It looked like such a wonderful challenge to the budding programmer in me.

I never wrote a program that played chess well, yet my programming life often crossed paths with the game. My first program written out of passion was a program to implement a ratings system for our chess club. Later, in college, I wrote a program to perform the Swiss system commonly used to run chess tournaments as a part of my senior project. This was a pretty straightforward program, really, but it taught me a lot about data structures, algorithms, and how to model problems.

Though I never wrote a great chessplaying program, that was the problem that mesmerized me and ultimately drew me to artificial intelligence and a major in computer science.

In a practical sense, chess has been "solved", but not in the way that most of us who loved AI as kids had hoped. Rather than reasoning symbolically about positions and plans, attacks and counterattacks, Deep Blue, Fritz, and all of today's programs win by deep search. This is a strategy that works well for serial digital computers but not so well for the human mind.

To some, the computer's approach seems uncivilized even today, but those of us who love AI ought be neither surprised nor chagrined. We have long claimed that intelligence can arise from any suitable architecture. We should be happy to learn how it arises most naturally for machines with fast processors and large memories. Deep Blue's approach may not help us to understand how we humans manage to play the game well in the face of its complexity and depth, but it turns out that this is another question entirely.

Reading David Mechner's All Systems Go last week brought back a flood of memories. The Eastern game of Go stands alone these days among the great two-person board games, unconquered by the onslaught of raw machine power. The game's complexity is enormous, with a branching factor at each ply so high that search-based programs soon drown in a flood of positions. As such, Go encourages programmers to dream the Big Dream of implementing a deliberative, symbolic reasoner in order to create a programs that plays the game well. The hubris and well-meaning naivete of AI researchers have promised huge advances throughout the years, only to have ambitious predictions go unfulfilled in the face of unexpected complexity. Well-defined problems such as chess turned out to be complex enough that programs reasoning like humans were unable to succeed. Ill-defined problems involving human language and the interconnected network of implicit knowledge that humans seem to navigate so easily -- well, they are even more resistant to our solutions.

Then, when we write programs to play games like chess well, many people -- including some AI researchers -- move the goal line. Schaefer et al. solved checkers with Chinook, but many say that its use of fast search and a big endgame databases is unfair. Chess remains unsolved in the formal sense, but even inexpensive programs available on the mass market play far, far better than all but a handful of humans in the world. The best program play better than the best humans.

Not so with Go. Mechner writes:

Go is too complex, too subtle a game to yield to exhaustive, relatively simpleminded computer searches. To master it, a program has to think more like a person.

And then:

Go sends investigators back to the basics--to the study of learning, of knowledge representation, of pattern recognition and strategic planning. It forces us to find new models for how we think, or at least for how we think we think.

Ah, the dream lives!

Even so, I am nervous when I read Mechner talking about the subtlety of Go, the depth of its strategy, and the impossibility of playing it well in by search and power. The histories of AI and CS have demonstrated repeatedly that what we think difficult often turns out to be straightforward for the right sort of program, and that what we think easy often turns out to be achingly difficult to implement. What Mechner calls 'subtle' about Go may well just be a name for our ignorance, for our lack of understanding today. It might be wise for Go aficionados to remain humble... Man's hubris survives only until the gods see fit to smash it.

We humans draw on the challenge of great problems to inspire us to study, work, and create. Lance Fortnow wrote recently about the mystique of the open problem. He expresses the essence of one of the obstacles we in CS face in trying to excite the current generation of students about our discipline: "It was much more interesting to go to the moon in the 60's than it is today." P versus NP may excite a small group of us, but when kids walk around with iPhones in their pockets and play on-line games more realistic than my real life, it is hard to find the equivalent of the moon mission to excite students with the prospect of computer science. Isn't all of computing like Fermat's last theorem: "Nothing there left to dream there."?

For old fogies like me, there is still a lot of passion and excitement in the challenge of a game like Go. Some days, I get the urge to ditch my serious work -- work that matters to people in the world, return to my roots, and write a program to play Go. Don't tell me it can't be done.

I've been thinking a lot about the Software Engineering course I'm teaching this fall, which commences a week from Tuesday. Along the way, I have been looking at a lot of books and articles with "software engineering" in the title. It's surprising how few of them get any where near code. I know I shouldn't be surprised. I remember taking courses on software engineering, and I've stayed close enough to the area all these years to know what matters. There are issues other than programming that we need to think about while building big systems. And there is plenty of material out there about programming and programming tools and the nuts and bolts of programming.

Still, I think it is important when talking about software engineering to keep in mind what the goal is: a working program, or collection of programs. When we forget that, it's too easy to spin off into a land of un-reality. It's also important to keep in mind that someone has to actually write code, or no software will ever be engineered. I hope that the course I teach can strike a good balance.

In the interest of keeping code in mind, I share with you an assortment of programming news. Good, bad, ugly, or fun? You decide.

Hiding the Rainforest. Mark Guzdial reports that Georgia Tech is eliminating yet another language from its computing curriculum. Sigh. Thought experiments notwithstanding, variety in language and style is good for programmers. On a pragmatic note, someone might want to tell the GT folks that programming for the JVM may soon look more like Lisp and feel more like ML than Java or C++.

Programming meets the Age of Twitter. A Processing programming contest with a twist: all programs must be 200-characters or less. I'll give extra credit for any program that is a legal tweet.

Power to the Programmer! Phil Windley enjoys saving $60 by writing his own QIF->CSV converter. But the real hero is the person who wrote Finance::QIF.

Why Johnny Can't Read Perl. Courtesy of Lambda the Ultimate comes news we all figured had to be true: a formal proof that Perl cannot be parsed. Who said the Halting Theorem wasn't useful? I guess I'll stop working on my refactoring browser for Perl.

Last month, in honor of the Apollo 11 mission's fortieth anniversary, Google Code announced the open-sourcing of code for the mission's command and lunar modules. Very cool indeed. This project creates opportunities for many people. CS historians can add this code to their record of computing and can now study computing at NASA in a new way. Grady Booch will be proud. He has been working for many years on the task of preserving code and other historic artifacts of our discipline that revolve around software.

Software archeologists can study the code to find patterns and architectural decisions that will help us understand the design of software better. What we learn can help us do more, just as the Apollo 11 mission prepared the way for future visitors to the moon, such as Charles Duke of Apollo 16 (pictured here).

This code could help CS educators convince a few students to assembly language programming seriously. This code isn't Java or even C, folks. Surely some young people are still mesmerized enough by space travel that they would want to dig in to this code?

As a person who appreciates assembly-level programming but prefers working at a higher level, I can't help but think that it would be fun to reverse-engineer these programs to code at a more abstract level and then write compilers that could produce equivalent assembly that runs on the simulator. The higher-level programs created in this way would be a great way for us to record the architecture and patterns we find in the raw source.

Reading this code and about the project that surrounds it, I am in awe of the scale of the programming achievement. For a computer scientist, this achievement is beautiful. I'd love to use this code to share the excitement of computing with non-computer scientists, but I don't know how. It's assembly, after all. I'm afraid that most people would look at this code and say, "Um, wow, very impressive" while thinking, "Yet another example of how computer science is beyond me."

If only those people knew that many computer scientists feel the same way. We are in awe. At one level, we feel like this is way over our heads, too. How could these programmers done so much with so little? Wow. But then we take a breath and realize that we have the tools we need to dig in and understand how this stuff works. Having some training and experience, we can step back from our awe and approach the code in a different way. Like a scientist. And anyone can have the outlook of a scientist.

When I wonder how could the programmers of the 1960s could have done so much with so little, I feel another emotion, too: sheepishness. How far have we as a discipline progressed in forty years? Stepping back from the sheepishness, I can see that since that time programmers have created some astoundingly complex systems in environments that are as harsh or harsher than the Apollo programmers faced. It's not fair to glorify the past more than it deserves.

But still... Wow. Revisiting this project forty years later ought to motivate all of us involved with computer science in 2009 -- software professionals, academics, and students -- to dream bigger dreams and tackle more challenging projects.

In my entry about advice on my advice to students interested in web development, I quoted an alum who dared suggest that undergrads study one language in depth for four years. This seems extreme to me, but it is often useful to examine the axioms on which we base our curricula. Wade's idea fits well with the idea that we would like to teach students enough that they can scratch an itch. I think that this approach overvalues what we can learn from a single language, and any language that takes four years to master is probably the wrong language for undergrads. Even if we accept that our goal is to help students scratch their own itches in the service of motivation, can't we do better? I think so.

My goal here is not to add to the seemingly endless cacophony about which first language(s) we should use in CS1. But I was impressed by a comment Terry Chay made on the entry of his to which I linked in my "itch to scratch" post, about textbooks. Although he is a proponent of PHP for web development, he argues that it isn't suitable for people learning their first programming language. One of the reasons is the the best books about PHP assume too much background.

Consider Welling and Thomson's PHP and MySQL Web Development. It is about web programming and so assumes that students are familiar with HTML, starting and restarting Apache, activating PHP, installing and setting up MySQL, and all the editor- and OS-specific details of writing, storing, and running scripts. That's a lot of hidden prerequisites, and it is one of the challenges we face anytime we try to embed CS1 in a context. Context is context, and students have to have it before they move on.

However, Chay claims that, after its first chapter, PHP and MySQL Web Development "offers more 'immersion' gratification (at the least cost) than any other language's textbook." But it's too late. The first chapter is what beginners see first and what they must make sense of before moving on. Unfortunately,

It's that first chapter that does the first timer in.

Many people who don't teach CS1 and who have never tried writing for that audience underestimate just how important this is, and just how difficult an obstacle it is to overcome. I occasionally see really good books about programming written to solve problems in a specific domain or context that might work well for beginners -- but only as a second course, after someone has taught a course that gets them through the introduction.

Right now I have examination copies of three books sitting on my desk or desktop that are relevant to this discussion.

• A Web-Based Introduction to Programming, by Mike O'Kane. I requested this when it was the first text book I'd seen that aimed to use PHP in context to teach a CS1 course. Often, books written specifically for CS1 lose the appeal and flavor of books written for motivated practitioners with an itch to scratch. Can this book be as good as the book Chay recommends?
• Using Google App Engine: Building Web Applications, by Charles Severance. I've see this book criticized for covering too many low-level details, but it aims to be a self-contained introduction to programming. The only way to do that is to cover all the knowledge usually assumed by Chapter 1. The combination of web applications and Google seems like a potential winner.
• Practical Programming: An Introduction to Computer Science Using Python, by Campbell, Gries, Montojo, and Wilson. This book was motivated at least in part by Greg Wilson's efforts to teach programming to scientists. Unlike the previous two, Practical Programming uses several themes to introduce the ideas of CS and the programming tools needed to play with them. Will the same ideas work as well when brought to the CS1 level, outside of a single unifying context?

I'm disappointed that I haven't taken the time to study these in detail. I am familiar with drafts of Practical Programming after having reviewed them in the books early stages and know it to be a well-written book. But that's not enough to say whether it works as well as I hope. Severance's book also promises big things, but I need to dig deeper to see how well it works. O'Kane's looks like the most traditional CS1 book of the bunch, with a twist: if-statements don't arrive until Chapter 7, and loops until Chapter 9.

Gotta make time! But then there is my own decidedly non-freshman course to think about. Fifteen days and counting...

An Addition to My News Aggregator

Thanks to John Cook, I came across the blog of Dan Meyers, a high school math teacher. Cook pointed to an entry with a video of Meyer speaking pecha kucha-style at OSCON. One of the important messages for teachers conveyed in this five minutes is Be less helpful. Learning happens more often when people think and do than when they follow orders in a well-defined script.

While browsing his archive I came across this personal revelation about the value of the time he was spending on his class outside of the business day:

I realize now that the return on that investment of thirty minutes of my personal time isn't the promise of more personal time later. ... Rather it's the promise of easier and more satisfying work time now.

Time saved later is a bonus. If you depend on that return, you will often be disappointed, and that feeds the emotional grind that is teaching. Kinda like running in the middle. I think it also applies more than we first realize to reuse and development speed in software.

Learning and Doing

One of the underlying themes in Meyers's writing seems to be the same idea in this line from Gerd Binnig, which I found at Physics Quote of Day:

Doing physics is much more enjoyable than just learning it. Maybe 'doing it' is the right way of learning ....

Programming can be a lot more fun than learning to program, at least the way we often try to teach it. I'm glad that so many people are working on ways to teach it better. In one sense, the path to better seems clear.

Knowing and Doing

One of the reasons I named by blog "Knowing and Doing" was that I wanted to explore the connection between learning, knowing, and doing. Having committed to that name so many years ago, I decided to stake its claim at Posterous, which I learned about via Jake Good. Given some technical issues with using NanoBlogger, at least an old version of it, I've again been giving some thought to upgrading or changing platforms. Like Jake, I'm always tempted to roll my own, but...

I don't know if I'll do much or anything more with Knowing and Doing at Posterous, but it's there if I decide that it looks promising.

A Poignant Convergence

Finally, a little levity laced with truth. Several people have written to say they liked the name of my recent entry, Sometimes, Students Have an Itch to Scratch. On a whim, I typed it into Translation Party, which alternately translates a phrase from English into Japanese and back until it reaches equilibrium. In only six steps, my catchphrase settles onto:

Sometimes I fear for the students.

Knowing how few students will try to scratch their own itches with their new-found power as a programmer, and how few of them will be given a chance to do so in their courses on the way to learning something valuable, I chuckled. Then I took a few moments to mourn.

Mark Guzdial recently wrote:

It's interesting is how the contextualized approach [to teaching intro CS] impacted future student choice. Did we convince students that computing is interesting? I don't think so. Instead, we convinced students that computing was relevant to the things that they already had value for, that it had utility for them. Thus, we had students who were willing to take "More Media Computation" classes (as long as we kept explaining the utility), but not "More Computer Science" classes.

This came back to mind while I was reading Terry Chay's 5 million, which was recommended to me by alumnus Tony Bibbs in response to my recent request for assistance. While discussing how to recommend what language programmers should learn first, Chay wrote something in the same vein. I have cleaned up what I assume to be a typographical glitch in what he posted:

You know you can learn it in a classroom, but immersion is a much faster way to learn.

The best way to learn to program is to have an itch that needs scratching.

Together, these passages brought to mind advice that Alistair Cockburn once gave for introducing agile software development ideas into an organization. I recall his advise as this: Don't go into an organization talking about your solutions. Ask them about the problems they are having producing software. What causes them pain? Then look for a change they could make that would reduce or eliminate the pain. Often times, an agile practice will be the ticket, and this will serve as an opportunity to help them do something that helps them, not something that merely pulls a play from the playbook you are trying to sell.

I once ran across a quote on a blog at JavaRanch that seems not to exist anymore> which talked about the change in mindset that should accompany adopting Alistair's advice:

Changing other people in ways that I deem appropriate, that's hard. Asking people how they want to change, and how I can help them change, that's easy. Why don't I do more of the latter?

Those of us who teach students to program and who hope to attract creative and interested minds to CS cannot rely just on scratching the itches that students have, but that does seem like a useful prong in a multi-pronged effort. As Mark points out, many students interested in programming within a context are really interested in that context, not in programming or CS more generally. That's okay. Teaching a broad set of people how to do media computation is valuable on its own. But there are students like the ones Terry Chay describes who will immerse themselves in programming to scratch their own itches and then find they want to go deeper or broader than the one context.

Even with all the thinking out loud I do here, I am not sure yet which students will be the ones who go all the way with CS or how we can begin to identify them. Perhaps the best thing we can do is to draw them in with their own interests and see what happens. Teaching a generic, CS-centric intro sequence is not the best way to reach all students, even the ones who come in thinking they want to do CS. Empowering students to solve problems that matter to them seems like a promising way for us to approach the issue.

One reader commented on my CS/basketball fantasy that a CS1 course built around an obsession with sports would be a frivolous waste of time. That is probably true, but I have seen a fair number of students over the years in our CS1 courses and in Basic programming courses who invested significant numbers of hours into writing programs related to football, baseball, and basketball. I'm glad that those students engaged themselves with a programming language and set out to solve problems they cared about. If I could engage such students with my assignments, that would be an excellent use of our time in class, not a frivolous waste. I may not want to build an entire course around a particular student's interest in ranking NFL teams, but I am always looking for ways to incorporate student interests into what we need to do anyway.

Among other things, teachers need to keep in mind that students have itches, too. It never hurts to ask them every once in a while what those itches are.

The economics blog Marginal Revolution has an occasional series of posts called "Markets in Everything", in which the writers report examples of markets at work in various aspects of everyday life. I've considered doing something similar here with computing, as a way to document some concrete examples of computational thinking and -- gasp! -- computer programs playing a role how we live, work, and play. Perhaps this will be a start.

Courtesy of Wicked Teacher of the West, I came across this story about NBA player Shane Battier, who stands out in an unusual way: by not standing out with his stats. A parallel theme of the story is how the NBA's Houston Rockets are using data and computer analysis in an effort to maximize their chances of victory. The connection to Battier is that the traditional statistics we associate with basketball -- points, rebounds, assists, blocked shots, and the like -- do not reflect his value. The Rockets think that Battier contributes far more to their chance of winning than his stat line shows.

The Rockets collect more detailed data about players and game situations, and Battier is able to use it to maximize his value. He has developed great instincts for the game, but he is an empiricist at heart:

The numbers either refute my thinking or support my thinking, and when there's any question, I trust the numbers. The numbers don't lie.

For an Indiana boy like myself, nothing could be more exciting than knowing that the Houston Rockets employ a head of basketball analytics. This sort of data analysis has long been popular among geeks who follow baseball, a game of discrete events in which the work of Bill James and like-minded statistician-fans of the American Pastime finds a natural home. I grew up a huge baseball fan and, like all boys my age, lived and died on the stats of my favorite players. But Indiana is basketball country, and basketball is my first and truest love. Combining hoops with computer science -- could there be a better job? There is at least one guy living the dream, in Houston.

I have written about the importance of solving real problems in CS courses, and many people are working to redefine introductory CS to put the concepts and skills we teach into context. Common themes include bioinformatics, economics, and media computation. Basketball may not be as important as sequencing the human genome, but it is real and it matters to a enough people to support a major entertainment industry. If I were willing to satisfy my own guilty pleasures, I would design a CS 1 course around Hoosier hysteria. Even if I don't, it's comforting to know that some people are beginning to use computer science to understand the game better.

Good Question

Last week, I gave a talk on careers in computing to thirty or so high school kids in a math and science program on campus this summer. Because it's hard to make sense out of computing careers if one doesn't even know what computer science is, I started off with half an hour or so talking about CS. Part of that was distinguishing between discovering things, creating things, and studying things.

At the end, we had time for the usual question-and-answer session. The first question came from a young man who had looked quite disinterested throughout the talk: What is the most important thing you have discovered or invented?

Who says kids don't pay attention?

The Age of Fire

Yesterday, I took my laptop with me to do advising at freshmen orientation. It allows me to grab course enrollment data of the university web site (processed, but raw enough), rather than look at the print-outs the advising folks provide every morning. With that data and little more than grep and sorting on columns, I can find courses for my students much more easily than thumbing back and forth in the print-outs. And the results are certainly of a higher quality than my thumbing would give.

The looks on the other advisors' faces at our table made me think of how a group of prehistoric men must have looked when one of their compatriots struck two rocks together to make fire.

Computer Science's Dirty Little Secret

An alumnus sent me a link to an MSNBC article about Kodu, a framework for building Xbox-like games aimed at nine-year-olds.

I like how Matthew MacLaurin, lead developer, thinks:

MacLaurin ... says he hopes it doesn't just teach programming, but teaches us to appreciate programming as a modern art form.

(Emphasis added.)

The piece talks about "the growing importance of user-generated content in gaming" and how most people assume "that all of the creativity in video games takes place in the graphics and art side of the gaming studios, while the programming gets done by a bunch of math guys toiling over dry code. Author Winda Benedetti writes (emphasis added):

I had asked [McLaurin] if [Kodu] was like putting chocolate on broccoli -- a means of tricking kids into thinking the complex world of programming was actually fun.

But he insists that's not the case at all.

"It's teaching them that it was chocolate the whole time, it just looked like a piece of broccoli," he explains. "We're really saying that programming is the most fun part of creating games because of the way it surprises you. You do something really simple, and you get something really complex and cool coming back at you."

Programming isn't our dirty little secret. It is a shining achievement.

Afterthoughts

I am still amazed when lay people respond to me using a computer to solve daily problems, as if I have brought a computation machine from the future. Shocking! Yes, I actually use it to compute. The fact that people are surprised even when a computer scientist uses it that way should help us keep in mind just how little people understand what computer science is and what we can do with it.

Have an answer to the question, "What is the most important thing you have made?" ready at hand, and suitable for different audiences. When someone asks, that is the moment when you might be able to change a mind.

Quoted by Harry Lewis in Excellence Without a Soul:

A liberal education is what remains after you have forgotten the facts that were first learned while becoming educated.
-- Jorge Dominguez

I think this applies not only to a liberal education broadly construed but also to specialized areas of study -- and even to a "narrow" technical field such as computer science. What is left five or ten years from now will be the education our students have received. Students may not remember the intricacies of writing an equals method in Java. I won't mind one bit. What will they remember? This is the true test of the courses we create and of the curricula we design. Let's set our sights high enough to hit the target we seek.

Lately I've been trying to swear off scare quotes and other writing affectations. I use them above with sincere intention. Computer science is not as narrow as most people think. Students usually think it is, and so do many of their parents. I hope that what we teach and do alleviates this misconception. Sadly, too often those of us who study computer science -- and teach it -- think of the discipline too narrowly. We may not preach it that way, but we often practice it so.

With good courses, a good curriculum, and a little luck, students may even remember some of their CS education. I enjoyed reading how people like Tim O'Reilly have been formed by elements of their classical classical education. How are we forming our students in the spirit of a classical CS education? If any discipline needs to teach enduring truths, it is ours! The details disappear with every new chip, every new OS, every new software trend.

What is most likely to remain from our stints in school are habit. Sure, CS students must take with them some facts and truths: trade-offs matter; in some situations, the constant dominates the polynomial; all useful programming languages have primitives, means for combining them, and means for abstracting away detail. Yes, facts matter, but our nature is tied to its habits. I said last time that publishing the data I collect and use would be a good habit because habits direct how we think. I am a pragmatist in the strong sense that knowledge is habit of thought. Habit of action creates habit of thought. Knowledge is not the only value born in habit. As Aristotle taught us,

Excellence is an art won by training and habituation. We do not act rightly because we have virtue or excellence, but rather we have those because we have acted rightly.

Even an old CS student can remember some of his liberal arts education...

Finally, we will do well to remember that students learn as much or more from the example we set as from what we say in the classroom, or even in our one-on-one mentoring. All the more reason to create habits of action we don't mind having our students imitate.

~~~~

Note. Someone might read Excellence Without a Soul and think that Harry Lewis is a classicist or a humanities scholar. He is a computer scientist, who just happened to spend eight years as Dean of Harvard College. Dominguez, whom Lewis quotes, is a political science professor at Harvard, but he claims to be paraphrasing Alfred North Whitehead -- a logician and mathematician -- in the snippet above. Those narrow technical guys...

My favorite Lewis book is, in fact, a computer science book, Elements of the Theory of Computation, which I mentioned here a while back. I learned theory of computation from that book -- as well as a lot of basic discrete math, because my undergrad CS program didn't require a discrete course. Often, we learn well enough what we need to learn when we need it. Elements remains one of my favorite CS books ever.

As I mentioned last time, this week I am getting back to some regular work after mostly wrapping up a big project, including cleaning off my desk. It is cluttered with a lot of loose paper that the Digital Age had promised to eliminate. Some is my own fault, paper copies of notes and agendas I should probably find a way to not to print. Old habits dies hard.

But I also have a lot paper sent to me as department head. Print-outs; old-style print-outs from a mainframe. The only thing missing from a 1980s flashback is the green bar paper.

Some of these print-outs are actually quite interesting. One set is of grade distribution reports produced by the registrar's office, which show how many students earned As, Bs, and so on in each course we offered this spring and for each instructor who taught a course in our department. This sort of data can be used to understand enrollment figures and maybe even performance in later courses. Some upper administrators have suggested using this data in anonymous form as a subtle form of peer pressure, so that profs who are outliers within a course might self-correct their own distributions. I'm ready to think about going there yet, but the raw data seems useful, and interesting in its own right.

I might want to do more with the data. This is the first time I recall receiving this, but in the fall it would be interesting to cross-reference the grade distributions by course and instructor. Do the students who start intro CS in the fall tend to earn different grades than those who start in the spring? Are there trends we can see over falls, springs, or whole years? My colleagues and I have sometimes wondered aloud about such things, but having a concrete example of the data in hand has opened new possibilities in my mind. (A typical user am I...)

As a programmer, I have the ability to do such analyses with relatively straightforward scripts, but I can't. The data is closed. I don't receive actual data from the registrar's office; I receive a print-out of one view of the data, determined by people in that office. Sadly, this data is mostly closed even to them, because they are working with an ancient mainframe database system for which there is no support and a diminishing amount of corporate memory here on campus. The university is in the process of implementing a new student information system, which should help solve some of these problems. I don't imagine that people across campus will have much access to this data, though. That's not the usual M.O. for universities.

Course enrollment and grade data aren't the only ones we could benefit from opening up a bit. As a part of the big project I just wrapped up, the task force I was on collected a massive amount of data about expenditures on campus. This data is accessible to many administrators on campus, but only through a web interface that constrains interaction pretty tightly. Now that we have collected the data, processed almost all of it by hand (the roughness of the data made automated processing an unattractive alternative), and tabulated it for analysis, we are starting to receive requests for our spreadsheets from others on campus. These folks all have access to the data, just not in the cleaned-up, organized format into which we massaged it. I expressed frustration with our financial system in a mini-rant a few years ago, and other users feel similar limitations.

For me, having enrollment and grade data would be so cool. We could convert data into information that we could then us to inform scheduling, teaching assignments, and the like. Universities are inherently an information-based institutions, but we don't always put our own understanding of the world into practice very well. Constrained resources and intellectual inertia slow us down or stop us all together.

Hence my wistful hope while reading Tim Bray's "Hello-World" for Open Data. Vancouver has a great idea:

• Publish the data in a usable form.
• License it in a way that turns people loose to do whatever they want, but doesn't create unreasonable liability risk for the city.
• See what happens. ...

Would anyone on campus take advantage? Maybe, maybe not. I can imagine some interesting mash-ups using only university data, let alone linking to external data. But this isn't likely to happen. GPA data and instructor data are closely guarded by departments and instructors, and throwing light on it would upset enough people that any benefits would probably be shouted down. But perhaps some subset of the data the university maintains, suitably anonymized, could be opened up. If nothing else, transparency sometimes helps to promote trust.

I should probably do this myself, at the department level, with data related to schedule, budget, and so on. I occasionally share the spreadsheets I build with the faculty, so they can see the information I use to make decisions. This spring, we even discussed opening up the historic formula used in the department to allocate our version of merit pay.

(What a system that is -- so complicated that that I've feared making more than small editorial changes to it in my time as head. I keep hoping to find the time and energy to build something meaningful from scratch, but that never happens. And it turns out that most faculty are happy with what we have now, perhaps for "the devil you know" reasons.)

I doubt even the CS faculty in my department would care to have open data of this form. We are a small crew, and they are busy with the business of teaching and research. It is my job to serve them by taking as much of this thinking out of our way. Then again, who knows for sure until we try? If the cost of sharing can be made low enough, I'll have no reason not to share. But whether anyone uses the data that might not even be the real point. Habits change when we change them, when we take the time to create new ones to replace the old ones. This would a good habit for me to have.

Where did the title of my previous entry come from? Two more quick hits tell a story.

Factoid of the Day

On a walk the other night, my daughter asked why we called variables x. She is reviewing some math this summer in preparation to study algebra this fall. All I could say was, "I don't know."

Before I had a chance to look into the reason, one explanation fell into my lap. I was reading an article called The Shakespeare of Iran, which I ran across in a tweet somewhere. And there was an answer: the great Omar Khayyam.

Omar was the first Persian mathematician to call the unknown factor of an equation (i.e., the x) shiy (meaning thing or something in Arabic). This word was transliterated to Spanish during the Middle Ages as xay, and, from there, it became popular among European mathematicians to call the unknown factor either xay, or more usually by its abbreviated form, x, which is the reason that unknown factors are usually represented by an x.

However, I can't confirm that Khayyam was first. Both Wikipedia and another source also report the Arabic language connection, and the latter mentions Khayyam, but not specifically as the source. That author also notes that "xenos" is the Greek word for "unknown" and so could be the root. However, I also haven't found a reference for this use of x that predates Khayyam, either. So may be.

My daughter and I ended up with as much of a history lesson as a mathematical terminology lesson. I like that.

Quote of the Day

Yesterday afternoon, the same daughter was listening in on a conversation between me and a colleague about doing math and science, teaching math and science, and how poorly we do it. After we mentioned K-12 education and how students learn to think of science and math as "hard" and "for the brains", she joined the conversation with:

Don't ask teachers, 'Why?' They don't know, and they act like it's not important.

I was floored.

She is right, of course. Even our elementary school children notice this phenomenon, drawing on their own experiences with teachers who diminish or dismiss the very questions we want our children to ask. Why? is the question that makes science and math what they are.

Maybe the teacher knows the answer and doesn't want to take the time to answer it. Maybe she knows the answer but doesn't know how to answer it in a way that a 4th- or 6th- or 8th-grader can understand. Maybe he really doesn't know the answer -- a condition I fear happens all too often. No matter; the damage is done when the the teacher doesn't answer, and the child figures the teacher doesn't know. Science and math are so hard that the teacher doesn't get it either! Better move on to something else. Sigh.

This problem doesn't occur only in elementary school or high school. How often do college professors send the same signal? And how often do college professors not know why?

Sometimes, truth hits me in the face when I least expect it. My daughters keep on teaching me.

While reading about the fate of newspapers prior to writing my recent entry on whether universities are next, I ran across a blog entry by Dave Winer called If you don't like the news.... Winer had attended a panel discussion at the UC-Berkeley school of journalism. After hearing what he considered the standard "blanket condemnation of the web" by the journalists there, he was thinking about all the blogs he would love to have shown them -- examples of experts and citizens alike writing about economics, politics, and the world; examples of a new sort of journalism, made possible by the web, which give him hope for the future of ideas on the internet.

Here is the money quote for me:

I would also say to the assembled educators -- you owe it to the next generations, who you serve, to prepare them for the world they will live in as adults, not the world we grew up in. Teach all of them the basics of journalism, no matter what they came to Cal to study. Everyone is now a journalist. You'll see an explosion in your craft, but it will cease to be a profession.

Replace "journalism" with "computer science", and "journalist" with "programmer", and this statement fits perfectly with the theme of much of this blog for the past couple of years. I would be happy to say this to my fellow computer science educators: Everyone should now be a programmer. We'll see an explosion in our craft.

Will programming cease to be a profession? I don't think so, because there is still a kind and level of programming that goes beyond what most people will want to do. Some of us will remain the implementors of certain tools for others to use, but more and more we will empower others to make the tools they need to think, do, and maybe even play.

Are academic computer scientists ready to make this shift in mindset? No more so than academic journalists, I suspect. Are practicing programmers? No more so than practicing journalists, I suspect.

Purely by happenstance, I ran across another quote from Winer this week, one that expresses something about programming from the heart of a programmer:

i wasn't born a programmer.
i became one because i was impatient.
-- @davewiner

I suspect that a lot of you know just what he means. How do we cultivate the right sort of impatience in our students?

I have regarded it as the highest goal
of programming language design to enable
good ideas to be elegantly expressed.
-- Tony Hoare, The Emperor's Old Clothes

One of computing's pioneers has passed. Word came this morning from Queen Mary, University of London, that Peter Landin died yesterday. Landin is perhaps not as well known on this side of the pond as he should be. His university web page lists his research interests as "logic and foundations of programming; theoretical computations; programming foundations; computer languages", but it doesn't say much about his seminal contributions in those areas. Nor does it mention his role helping to establish computer science as a discipline in the UK.

In the world of programming languages, though, Landin is well-known. He was one of the early researchers influenced by McCarthy's Lisp, and he helped to develop the connection between the lambda calculus and the idea of a programming language. In turn, He influenced Tony Hoare and Hoare's creation of Quicksort. This followed his involvement in the design of Algol 60, which introduced recursion to a wider world of computer scientists and programmers. Algol 60 was in many ways the alpha of modern programming languages.

I am probably like many computer scientists in having read only one of Landin's papers, The Next 700 Programming Languages. I remember first running across this paper while studying functional languages a decade or so ago. Its title intrigued me, and its publication date -- July 1965 -- made me wonder just what he could mean by it. I was blown away. He distinguished among four different levels of features that denote a language: physical, logical, abstract, and "applicative expressions". The last of these abstracted even more grammatical detail away from what many of us tend to think of as the abstract tree of a program. He also wrote about the role of where clauses in specifying local bindings natural just as mathematicians long have.

Before reading this paper, I had never seen a discussion of the physical appearance of programs written in a language. Re-reading the paper now, I had forgotten that Landin used an analogy to soccer, the off-side rule, to define a class of physical appearances in which indentation mattered. After we as a discipline left the punch card behind, for many years it was unstylish at best, and heresy at worst, for whitespace to matter in programming language design. These days, languages such as Python and Haskell have sidestepped this tradition and put whitespace to good use.

On a lighter note, Landin also coined the term syntactic sugar, a fact I learned only while reading about Landin after his passing. What whimsy! A good name is sometimes worth as much as a good idea. I join Hoare in praising Landin for showing him the elegance of recursion, but also reserve a little laud for giving us such a wonderful term to use when talking about the elegance of small languages.

This isn't quite an END DO moment for me. I heard about John Backus throughout my undergrad and graduate careers, and his influence on the realization of the compiler has affected me deeply for as long as I've been a student of computer science. I came to Landin later, through his theoretical contributions. Yet it's interesting that they shared a deep appreciation for functional languages. For much of the discipline's history, functional programming has remained within the province of the academic, looked upon disdainfully by practitioners as impractical, abstract, and a distraction from the real business of programming. Now the whole programming world is atwitter with new languages, and new features for old languages, that draw on the abstraction, power, and beauty of functional programming. The world eventually catch up with ideas of visionaries.

An e-mail message from Edmund Robinson shared the sad news of Landin's passing with many people. In it, Robinson wrote:

The ideas in his papers were truly original and beautiful, but Peter never had a simplistic approach to scientific progress, and would scoff at the idea of individual personal contribution.

Whatever Landin's thoughts about "the idea of individual personal contribution", the computing world owes him a debt for what he gave us. Read "The Next 700 Programming Languages" in his honor. I am reading it again and plan next to look into his other major papers, to see what more he has to teach me.

For the programming languages geek who has everything, try the Lambda Chair. The company took the time to name it right, then sadly took the promotional photo from the wrong side. Still, an attractive complement to any office -- and only $2,000. Perfect for my university budget!

I found out about this chair on the PLT mailing list today. The initial frivolity led to an interesting excursion into history when someone asked:

Does anyone know if Church had anything in mind for lambda to stand for, or was it just an arbitrary choice?

In response, Matthias Felleisen shared a story that is similar to one I'd heard in the languages community before. At the beginning of the last century, mathematicians used ^ to indicate class abstractions, such as î : i is prime. Church used ^`, the primed version of the hat, to indicate function abstraction, because a function is a special kind of set. Church's secretary read this notation as », and Church let it stand.

Later in the thread, Dave Herman offered pointers to a couple of technical references that shed further light on the origin of lambda. On Page 7 of History of Lambda-Calculus and Combinatory Logic, Cardone and Hindley cite Church himself:

(By the way, why did Church choose the notation "»"? In [Church, 1964, §2] he stated clearly that it came from the notation "î" used for class-abstraction by Whitehead and Russell, by first modifying "î" to "'i" to distinguish function-abstraction from class-abstraction, and then changing "'" to "»" for ease of printing. This origin was also reported in [Rosser, 1984, p.338]. On the other hand, in his later years Church told two enquirers that the choice was more accidental: a symbol was needed and "»" just happened to be chosen.)

The two internal references are to an unpublished letter from Church to Harald Dickson, dated July 7, 1964, and to J. B. Rosser's 1984 paper Highlights of the History of the Lambda Calculus from the Annals of the History of Computing.

Herman also pointed to Page 182 of The Impact of the Lambda Calculus in Logic and Computer Science:

We end this introduction by telling what seems to be the story how the letter '»' was chosen to denote function abstraction. In [100] Principia Mathematica the notation for the function f with f(i) = 2i + 1 is 2 î + 1. Church originally intended to use the notation î.2i + 1. The typesetter could not position the hat on top of the i and placed it in front of it, resulting in 'i.2i + 1. Then another typesetter changed it into »i.2i + 1.

(I changed the variable x to an i in the preceding paragraph, because, much like the alleged trendsetting typesetter, I don't know how to position the circumflex on top of an x in HTML!)

Even in technical disciplines, history can be an imprecise endeavor. Still, it's fun when we go from anecdote to a more reliable source. I don't know that I'll ever need to tell the story of the lambda, but I like knowing it anyway.

Yesterday, a student told me about the Ruby gem Treetop, a DSL for writing language grammars. This language uses parsing expression grammar, which turns our usual idea of grammar inside out. Most compiler theory is built atop the context-free and regular grammars of Chomsky. These grammars are generative: they describe rules that allow us to create strings which are part of the language. Parsing expression grammars describe rules that allow us to recognize strings which are part of the language.

This new kind of grammar offers a lot of advantages for working with programming languages, such as unifying lexical and syntactic descriptions and supporting the construction of linear-time parsers. I remember seeing Bryan Ford talk about packrat parsing at ICFP 2002, but at that point I wasn't thinking as much about language grammars and so didn't pay close attention the type of grammar that underlay his parsing ideas.

While generative grammars are a fundamental part of computing theory, they don't map directly onto the primary task for which many software people use them: building scanners and parsers for programming languages. Our programs recognize strings, not generate them. So we have developed mechanisms for building and even generating scanners and parsers, given grammars that we have written under specific constraints and then massaged to fit our programming mechanisms. Sometimes the modified grammars aren't as straightforward as we might like. This can be a problem for anyone who comes to the grammar later, as well as a problem for the creators of the grammar when they want to change it in response to changes requested by users.

A recognition-based grammar matches our goals as compiler writers more closely, which could be a nice advantage. Parsing expression grammars make explicit the specification of the code we write against them.

For those of us who teach compiler courses, something like a parsing expression grammar raises another question. Oftentimes, we hope that the compiler course can do double duty: teach students how to build a compiler, and help them to understand the theory, history, and big issues of language processors. I think of this as a battle between two forces, "learning to" versus "learning about", a manifestation of epistemology's distinction between "knowing that" and "knowing how".

Using recognition-based grammars as the foundation for a compiler course introduces a trade-off: students may be empowered more quickly to create language grammars and parsers but perhaps not learn as much about the standard terminology and techniques of the discipline. These standard ways are, of course, our historical ways of doing things. There is much value in learning history, but at what point do we take the step forward to techniques that are more practical than reminiscent?

This is a choice that we have to make all the time in a compiler course: top-down versus bottom-up parsing, table-driven parsers versus recursive-descent parsers, writing parsers by hand versus using parser generators... As I've discussed here before, I still ask students to write their parser by hand because I think the experience of writing this code teaches them more than just about compilers.

Now that I have been re-introduced to this notion of recognition-based grammars, I'm wondering whether they might help me to balance some of the forces at play more satisfactorily. Students would have the experience of writing a non-trivial parser by hand, but against a grammar that is more transparent and easier to work with. I will play with parsing expression grammars a bit in the next year or so and consider making a change the next time I teach the course. (If you have taught a compiler course using this approach, or know someone who has, please let me know.)

Going this way would not commit me to having students write their parsers by hand. The link that started this thread of thought points to a tool for automating the manipulation of parsing expression grammars. Whatever I do, I'll add that tool to the list of tools I share with students.

Oh, and a little Ruby Love to close. Take a look at TreeTop. Its syntax is beautiful. A Treetop grammar reads cleanly, crisply -- and is executable Ruby code. This is the sort of beauty that Ruby allows, even encourages, and is one of the reasons I remain enamored of the language.

While waiting for a school convocation to start last night, I was digging through my bag looking for something to read. I came across a print-out of Personal Dynamic Media, which I cited in my entry about Adele Goldberg. I gladly re-re-read it. This extended passage a good explanation of the idea that the digital computer is more than a tool, that it is a medium, and a more powerful medium than any other we humans have created and used:

"Devices" which variously store, retrieve, or manipulate information in the form of messages embedded in a medium have been in existence for thousands of years. People use them to communicate ideas and feelings both to others and back to themselves. Although thinking goes on in one's head, external media serve to materialize thoughts and, through feedback, to augment the actual paths the thinking follows. Methods discovered in one medium provide metaphors which contribute new ways to think about notions in other media.

For most of recorded history, the interactions of humans with their media have been primarily nonconversational and passive in the sense that marks on paper, paint on walls, even "motion" pictures and television, do not change in response to the viewer's wishes. A mathematical formulation -- which may symbolize the essence of an entire universe -- once put down on paper, remains static and requires the reader to expand its possibilities.

Every message is, in one sense or another, a simulation of some idea. It may be representational or abstract. The essence of a medium is very much dependent on the way messages are embedded, changed, and viewed. Although digital computers were originally designed to do arithmetic computation, the ability to simulate the details of any descriptive model means that the computer, viewed as a medium itself, can be all other media if the embedding and viewing methods are sufficiently well provided. Moreover, this new "metamedium" is active -- it can respond to queries and experiments -- so that the messages may involve the learner in a two-way conversation. This property has never been available before except through the medium of an individual teacher. We think the implications are vast and compelling.

I agree. But after reading this paper again all I can think is: No wonder Kay is so disappointed by what we are doing in the world of computing in 2009. Looking at what he, Goldberg, and their team were doing back in the 1970s, with technology that looks so very primitive to us these days -- not only the interactivity of the medium they were creating, but the creations of the people working in the medium, even elementary school students. Even if I think only in terms of how they viewed and created language... We have not done a good job living up to the promise of that work.

If you are eager to embrace this promise, perhaps you will be inspired by this passage from the Education in the Digital Age interview I mentioned in Making Language:

Music is in the person.
An instrument amplifies it.
The computer is like that.

How are you using the computer to amplify the music inside of you? What can you do to help the computer amplify what is inside others?

I've been catching up on some reading while not making progress on other work. I enjoyed this interview with Barbara Liskov, which discusses some of the work that earned her the 2008 Turing Award. I liked this passage:

I then developed a programming language that included this idea [of how to abstract away from the details of data representation in programs]. I did that for two reasons: one was to make sure that I had defined everything precisely because a programming language eventually turns into code that runs on a machine so it has to be very well-defined; and then additionally because programmers write programs in programming languages and so I thought it would be a good vehicle for communicating the idea so they would really understand it.

Liskov had two needs, and she designed a language to meet them. First, she needed to know that her idea for how to organize programs were sound. She wanted to hold herself accountable. A program is an effective way to implement an idea and show that it works as described. In her case, her idea was about _writing_ programs, so she created a new language that embodied the idea and wrote a processor for programs written in that language.

Second, she needed to share her idea with others. She wanted to teach programmers to use her idea effectively. To do that, she created a language. It embodied her ideas about encapsulation and abstraction in language primitives that programmers could use directly. This made it possible for them to learn how to think in their terms and thus produce a new kind of program.

This is a great example of what language can do, and why having the power to create new languages makes computer science different. A program is an idea and a language is a vehicle for expressing ideas. We are only beginning to understand what this means for how we can learn and communicate. In the video Education in the Digital Age, Alan Kay talks about how creating a new language changes how we learn:

The computer allows us to put what we are thinking into a dynamic language and probe it in a way we never could before.

We need to find a way to help CS students see this early on so that they become comfortable with the idea of creating languages to help themselves learn. Mark Guzdial recently said much the same thing: we must help students see that languages are things you build, not just use. Can we introduce students to this idea in their introductory courses? Certainly, under the right conditions. One of my colleagues loves to use small BASIC-like interpreters in his intro course or his assembly language courses. This used to be a common idea, but as curricula and introductory programming languages have changed over time, it seems to have fallen out of favor. Some folks persist, perhaps with simple a simple command language. But we need to reinforce the idea throughout the curriculum. This is less a matter of course content than the mindset of the instructor.

After reading so much recently about Liskov, I am eager to spend some time studying CLU. I heard of CLU as an undergraduate but never had a chance for in-depth study. Even with so many new languages to dive into, I still have an affinity for older languages and and for original literature on many CS topics. (If I were in the humanities, I would probably be a classicist, not a scholar of modern lit or pop culture...)

Thanks to several of you who have pointed out that Scheme behaves exactly Python on the Python example in my previous post:

    > (define (f x) (if (> x 0) (f (- x 1)) 0))
    > (define g f)
    > (define (f x) x)
    > (g 5)
    > 4

Sigh. Indeed, it does. That is what I get for writing code for a blog and not test-driving it first. As an instructor, I learned long ago about the dangers of making claims about code that I have not executed and explored a bit -- even seemingly simple code. Now I can re-learn that lesson here.

The reason this code behaves as it does in both Scheme and Python is that the bindings of function f don't involve a closure at all. They refer to a free variable that must be looked up at in the top-level environment when they are executed.

While writing that entry, I was thinking of a Scheme example more like this:

    (define f
      (lambda (x)
        (letrec ((f (lambda (x)
                      (if (> x 0)
                          (f (- x 1))
                          0))))
          (f x))))

... in which the recursive call (f (- x 1)) takes place in the context of a local binding. It is also a much more complex piece of code. I do not know whether there is an idiomatic Python program similar to this or to my earlier Scheme example:

    (define f
      (let ((i 100))
        (lambda (x)
           (+ x i))))
    (define i 1)
    (f 1)

If there is, I suspect that real Python programmers would say that they simply don't program in this way very often. As van Rossum's The History of Python blog points out, Python was never intended as a functional language, even when it included features that made functional-style programming possible. So one ought not be too surprised when a purely functional idiom doesn't work out as expected. Whether that is better or worse for students who are learning to program in Python, I'll leave up to the people responsible for Python.

One can find all kinds of discussion on the web about whether Python closures are indeed "broken" or not, such as here (the comments are as interesting as the article). Until I have a little more time to dig deeper into the design and implementation of Python, though, I will have to accept that this is just one of those areas where I am not keeping up as well as I might like. But I will get to the bottom of this.

Back to the original thought beyond my previous post: It seems that Python is not the language to use as an example dynamic scope. Until I find something else, I'll stick with Common Lisp and maybe sneak in a little Perl for variety.

When I teach programming languages, we discuss the concepts of static and dynamic scoping. Scheme, like most languages these days, is statically scoped. This means that a variable refers to the binding that existed when the variable was created. For example,

> (define f
    (let ((i 100))
      (lambda (x)
        (+ x i))))
> (define i 1)
> (f 1)
101

This displays 101, not 2, because the reference to i in the body of function f is to the local variable i that exists when the function was created, not to the i that exists when the function is called. If the interpreter looked to the calling context to find its binding for i, that would be an example of dynamic scope, and the interpreter would display 2 instead.

Most languages use static typic these days for a variety of reasons, not the least of which is that it is easier for programmers to reason about code that is statically scoped. It is also easier to decompose programs and create modules that programmers can understand easily and use reliably.

In my course, when looking for an example of a dynamically-scoped language, I usually refer to Common Lisp. Many old Lisps were scoped dynamically, and Common Lisp gives the programmer the ability to define individual variables as dynamically-scoped. Lisp does not mean much to students these days, though. If I were more of a Perl programmer, I would have known that Perl offers the same ability to choose dynamic scope for a particular variable. But I'm not, so I didn't know about this feature of the language until writing this entry. Besides, Perl itself is beginning to fade from the forefront of students' attention these days, too. I could use an example closer to my students' experience.

A recent post on why Python does not optimize tail calls brought this topic to mind. I've often heard it said that in Python closures are "broken", which is to say that they are not closures at all. Consider this example drawn from the linked article:

IDLE 1.2.1      
>>> def f(x):
    if x > 0:
       return f(x-1)
    return 0;



>>> g = f
>>> def f(x):
    return x



>>> g(5)
4

g is a function defined in terms of f. By the time we call g, f refers to a different function at the top level. The result is something that looks a lot like dynamic scope.

I don't know enough about the history of Python to know whether such dynamic scoping is the result of a conscious decision of the language designer or not. Reading over the Python history blog, I get the impression that it was less a conscious choice and more a side effect of having adopted specific semantics for other parts of the language. Opting for simplicity and transparency as an overarching sometimes means accepting their effects downstream. As my programming languages students learn, it's actually easier to implement dynamic scope in an interpreter, because you get it "for free". To implement static scope, the interpreter must go to the effort of storing the data environment that exists at the time a block, function, or other closure is created. This leads to a trade-off: a simpler interpreter supports programs that can be harder to understand, and a more complex interpreter supports programs that are easier to understand.

So for now I will say that dynamic scope is a feature of Python, not a bug, though it may not have been one of the intended features at the time of the language's design.

If any of your current favorite languages use or allow dynamic scope, I'd love to hear about it -- and especially whether and how you ever put that feature to use.

I occasionally sneak a peek at the Learning Curves blog when I should be working. Yesterday I saw this entry, with a sad bullet point for us CS profs:

Keep getting caught up in stupid details on the computer science homework. String handling. Formatting times. That sort of thing. The problem no longer interests me now that I grasp the big idea.

This is an issue I see a lot in students, usually the better ones. In some cases, the problem is that the students feel they have a right not to be bothered with any details, stupid or otherwise. But a lot of programming involves stupid details. So do most other activities, like playing the piano, playing a sport, reading a book, closing a company's financial books, or running a chemistry experiment.

Life isn't a matter only of big ideas that never come into contact with the world. Our fingers have to strike the keys and play the right notes, in the correct order at the proper tempo. I can understand the big ideas of shooting a ball through a hoop, but players succeed because they shoot thousands of shots, over and over, paying careful attention to details such as their point of release, the rotation of the ball, and the bending of their knees.

There may be an element of this in Hirta's lament, but I do not imagine that this is her whole of her problem. Some details really are stupid. For the most part, basketball players need not worry about the lettering on the ball, and piano players need not think about whether their sheet music was printed on 80% or 90% post-consumer recycled paper. Yet too often people who write programs have to attend to details just as silly, irrelevant, and disruptive.

This problem is even worse for people learning to write programs. "Don't worry what public static void main( String[] args ) means; just type it in before you start." Huh? Java is not alone here. C++ throws all sorts of silly details into the faces of novice programmers, and even languages touted for their novice-friendliness, such as Ada, push all manner of syntax and convention into the minds of beginners. Let's face it: learning to program is hard enough. We don't need to distract learners with details that don't contribute to learning the big idea, and maybe even get in the way.

If we hope to excite people with the power of programming, we will do it with big ideas, not the placement of periods, spaces, keywords, and braces. We need to find ways so that students can solve problems and write programs by understanding the ideas behind them, using tools that get in the way as little as possible. No junk allowed. That may be through simpler languages, better libraries, or something else that I haven't learned about yet.

(And please don't post a link to this entry on Reddit with a comment saying that that silly Eugene fella thinks we should dumb down programming and programming languages by trying to eliminate all the details, and that this is impossible, and that Eugene's thinking it is possible is a sign that he is almost certainly ruining a bunch of poor students in the heartland. Re-read the first part of the entry first...)

Oh, and for my agile developer friends: Read a little farther down the Learning Curves post to find this:

Email from TA alleges that debugging will be faster if one writes all the test cases ahead of time because one won't have to keep typing things while testing by hand.

Hirta dismisses the idea, saying that debugging will still require diagnosis and judgment, and thus be particular to the program and to the bug in question. But I think her TA has re-discovered test-first programming. Standing ovation!

The last few days I have run across several pointers to Scala and Clojure, two dynamic languages that support functional programming style on the JVM. Whenever I run into a new programming language, I start thinking about how much time I should put into learning and using it. If it is a functional language, I think a bit harder, and naturally wonder whether I should consider migrating my Programming Languages course from the venerable but now 30-plus-years-old Scheme to the new language.

My time is finite and in scarce supply, so I have to choose wisely. If I try to chase every language thread that pops up everywhere, I'll end up completely lost and making no progress on anything important. Choosing which threads to follow requires good professional judgment and, frankly, a lot of luck. In the worst case, I'd like to learn something new for the time I invest.

Scala and Clojure have been on my radar for a while and, like books that receive multiple recommendations, are nearing critical mass for a deeper look. With summer around the corner and my usual itch to learn something new, chances go up even more.

Could one of these languages, or another, ever displace Scheme from my course? That's yet another major issue. A few years ago I entertained the notion of using Haskell in lieu of Scheme for a short while, but Scheme's simplicity and dynamic typing won out. Our students need to see something as different as possible from what they are used to, whatever burden that places on me and the course. My own experience with Lisp and Scheme surely had some effect on my decision. For every beautiful idea I could demonstrate in Haskell, I knew of a similar idea or three in Scheme.

My circumstance reminds me of a comment by Patrick Lam to a blog entry at Learning Curves:

I've noticed that computer science faculty technology usage often seems to be frozen to when they start their first tenure-track job. Unclear yet if I'll get stuck to 2008 technology.

Lam is wise to think consciously of this now. I know I did not. Then again, I think my track record learning new technologies, languages, and tools through the 1990s, in my first decade as a tenure-track professor, holds up pretty well. I picked up several new programming languages, played with wikis, adopted and used various tools from the agile community, taught courses in several new courses that required more than passing familiarity with the tools of those subdisciplines, and did a lot of work in the software patterns world.

My pace learning new technologies may have slowed a bit in the 2000s, but I've continued to learn new things. Haskell, Ruby, Subversion, blogs, RSS, Twitter, ... All of have become part of my research, teaching, or daily practice in the last decade. And not just as curiosities next to my real languages and tools; Ruby has become one of my favorite programming languages, alongside old-timers Smalltalk and Scheme.

 

A language that doesn't affect the way you think about programming, is not worth knowing. -- Alan Perlis, Epigrams on Programming

At some point, though, there is something of a "not again..." feeling that accompanies the appearance of new tools on the scene. CVS led to Subversion, which led to ... Darcs, Mercurial, Git, and more. Which new tool is most worth the effort and time? I've always had a fondness for classics, for ideas that will last, so learning yet another tool of the same kind looks increasingly less exciting as time passes. Alan Perlis was right. We need to spend our time and energy learning things that matter.

This approach carries one small risk for university professors, though. Sticking with the classics can leave one's course materials, examples, and assignments looking stale and out of touch. Any CS 1 students care to write a Fahrenheit-to-Celsius converter?

In the 1990s, when I was learning a lot of new stuff in my first few years on the faculty, I managed to publish a few papers and stay active. However, I am not a "research professor" at a "research school", which is Lam's situation. Hence the rest of his comment:

Also unclear if getting stuck is actually necessary for being successful faculty.

As silly as this may sound, it is a legitimate question. If you spend all of your time chasing the next technology, especially for teaching your courses, then you won't have time to do your research, publish papers, and get grants. You have to strike a careful balance. There is more to this question than simply the availability of time; there is also a matter of mindset:

Getting to the bottom of things -- questioning assumptions, investigating causes, making connections -- requires a different state of mind than staying on top of things.

This comes from John Cook's Getting to the Bottom of Things. In that piece, Cook concerns himself mostly with multitasking, focus, and context switching, but there is more. The mindset of the scientist -- who is trying to understand the world at a deep level -- is different than the mindset of the practitioner or tool builder. Time and energy devoted to the latter almost certainly cannibalizes the time and energy available for the former.

As I think in these terms, it seems clearer to me one advantage that some so-called teaching faculty have over research faculty in the classroom. I've always had great respect for the depth of curiosity and understanding that active researchers bring to the classroom. If they are also interested in teaching well, they have something special to share with their students. But teaching faculty have a complementary advantage. Their ability to stay on top of things means that their courses can be on the cutting edge in a way that many research faculty's courses cannot. Trade-offs and balance yet again.

For what it's worth, I really am intrigued by the possibilities offered by Scala and Clojure for my Programming Languages course. If we can have all of the beauty of other functional languages at the same time as a connection to what is happening out in the world, all the better. Practical connections can be wonderfully motivating to students -- or seem seem cloyingly trendy. Running on top of the JVM creates a lot of neat possibilities not only for the languages course but also for the compilers course and for courses in systems and enterprise software development. The JVM has become something of a standard architecture that students should know something about -- but we don't want to give our students too narrow an experience. Busy, busy, busy.

Well, Carefree. But it plays the Western theme to the hilt.

This was a shorter conference visit than usual. Due to bad weather on the way here, I arrived on the last flight in on Sunday. Due to work constraints of my workshop colleagues, I am heading out before the Wednesday morning session. Yet it was a productive trip -- like last year, but this time on our own work, as originally planned. We produced

• the beginnings of a catalog of data-driven real-world problems used in CS1 courses across the country, and
• half of a grant proposal to NSF's CPATH program, to fund some of our more ambitious ideas about programming for everyone, including CS majors.

A good trip.

Yesterday over our late afternoon break, we joined with the other workshop group and had an animated discussion started by a guy who has been involved with the agile community. He claimed that XP and other agile approaches tell us that "thinking is not allowed", that no design is allowed. A straw man can be fun and useful for exploring the boundaries of a metaphor. But believing it for real? Sigh.

A passing thought: Will professionals in other disciplines really benefit from knowing how to program? Why can't they "just" use a spreadsheet or a modeling tool like Shazam? This question didn't come to mind as a doubt, but as a realization that I need a variety of compelling stories to tell when I talk about this with people who don't already believe my claim.

While speaking of spreadsheets... My co-conspirator Robert Duvall was poking around Swivel, a web site that collects and shares open data sets, and read about the founders' inspiration. They cited something Dan Bricklin said about his own inspiration for inventing the spreadsheet:

I wanted to create a word processor for data.

Very nice. Notice that Bricklin's word processor for data exposes a powerful form of end-user programming.

When I go to conferences, I usually feel as if the friends and colleagues I meet are doing more, and more interesting, things than I -- in research, in class, in life. It turns out that a lot of my friends and colleagues seem to think the same thing about their friends and colleagues, including me. Huh.

I write this in the air. I was booked on a 100% full 6:50 AM PHX-MSP flight. We arrive at the airport a few minutes later than planned. Rats, I have been assigned a window seat by the airline. Okay, so I get on the plane and take my seat. A family of three gets on and asks me hopefully whether there is any chance I'd like an aisle seat. Sure, I can help. (!) I trade out to the aisle seat across the aisle so that they can sit together. Then the guy booked into the middle seat next to me doesn't show. Surprise: room for my Macbook Pro and my elbows. Some days, the smile on me in small and unexpected ways.

In real life there is no such thing as algebra.

-- Fran Lebowitz

At this time next week, I will be on my way to ChiliPLoP for a working session. Readers here know how much I enjoy my annual sojourn to this working conference, but this year I look forward to it with special fervor.

First, my day job the last few months -- the last year, really -- has been heavier than usual with administrative activities: IT task force, program review, budget concerns. These are all important tasks, with large potential effects on my university, my department, and our curriculum and faculty. But they are not computer science, and I need to do some computer science.

Second, I am still in a state of hopeful optimism that my year-long Running Winter is coming to an end. I put in five runs this week and reached 20 miles for the first time since October. The week culminated this morning in a chilly, hilly 8 miles on a fresh dusting of snow and under a crystal clear blue sky. ChiliPLoP is my favorite place to run away from home. I never leave Carefree without being inspired, unless I am sick and unable to run. Even if I manage only two short runs around town, which is what I figure is in store, I think that the location will do a little more magic for me.

Our hot topic group will be working at the intersection of computer science and other disciplines, stepping a bit farther from mainstream CS than it has in recent years. We all see the need to seek something more transformative than incremental, and I'd like to put into practice some of the mindset I've been exploring in my blog the last year or so.

The other group will again be led by Dave West and Dick Gabriel, and they, too, are thinking about how we might re-imagine computer science and software development around Peter Naur's notion of programming as theory building. Ironically, I mentioned that work recently in a context that crosses into my hot topic's focus. This could lead to some interesting dinner conversation.

Both hot topics' work will have implications for how we present programming, software development, and computer science to others, whether CS students are professionals in other disciplines. Michael Berman (who recently launched his new blog) sent a comment on my Sweating the Small Stuff that we need to keep in mind whenever we want people to learn how to do something:

I think that's an essential observation, and one that needs to be designed into the curriculum. Most people don't learn something until they need it. So trying to get students to learn syntax by teaching them syntax and having them solve toy problems doesn't teach them syntax. It's a mistake to think that there's something wrong with the students or the intro class -- the problem is in the curriculum design.

I learned algebra when I took trig, and trig when I took calculus, and I learned calculus in my physics class and later in queueing theory and probability. (I never really learned queueing theory.)

One of the great hopes of teaching computation to physicists, economists, sociologists, and anyone else is that they have real problems to solve and so might learn the tool they need to solve them. Might -- because we need to tell them a story that compels them to want to solve them with computation. Putting programming into the context of building theories in an applied discipline is a first step.

(Then we need to figure out the context and curriculum that helps CS students learn to program without getting angry...)

When I was first asked to consider writing a blog piece for the Ada Lovelace Day challenge, I wasn't sure I wanted to. I don't usually blog with any particular agenda; I just write whatever is in my mind at the time, itching to get out. This was surely a topic I have thought and written about before, and it's one that I have worked on with people at my university and across the state. I think it is in the best interest of computer science to be sure that we are not missing out on great minds who might be self-selecting away from the discipline for the wrong reasons. So I said yes.

Soon afterwards, ACM announced Barbara Liskov as the winner of the Turing Award. I had written about Fran Allen when she won the Turing Award, and here was another female researcher in programming languages whose work I have long admired. I think the Liskov Substitution Principle is one of the great ideas in software development, a crucial feature of object-oriented programming, of any kind of programming, really. I make a variant of the LSP the centerpiece of my undergraduate courses on OOP. But Liskov has done more -- CLU and encapsulation, Thor and object-oriented databases, the idea of Byzantine fault tolerance in distributed computing, ... It was a perfect fit for the challenge.

But my first thought, Adele Goldberg, would not leave me. That thought grew out of my long love affair with Smalltalk, to which she contributed, and out of a memory I have from my second OOPSLA Educators' Symposium, where she gave a talk on learning environments, programming, and language. Goldberg isn't a typical academic Ph.D.; she is versatile, having worked in technical research, applications, and business. She has made technical contributions and contributions to teaching and learning. She helped found companies. In the end, that's the piece I wanted to write.

So, if my entry on Goldberg sounds stilted or awkward, please cut me a little slack. I don't write on assigned topics much any more, at least not in my blog. I should probably have set aside more time to write that entry, but I wrote it much as I might write any other entry. If nothing else, I hope you can find value in the link to her Personal Dynamic Media article, which I was so happy to find on-line.

At this point, one other person has written about Goldberg for the Lovelace Day challenge. That entry has links to a couple of videos, including one of Adele demonstrating a WIMP interface using an early implementation of Smalltalk. A nice piece of history. Mark Guzial mentions Adele in his Lovelace Day essay, but he wrote about three women closer to home. One of his subjects is Janet Kolodner, who did groundbreaking research on case-based reasoning that was essential to my own graduate work. I'm a fan!

My slogan is:
computing is too important to be left to men.

-- Karen Sparck-Jones, 1935-2007

We talk a lot about the state of women in computing. Girls have deserted computer science as an academic major in recent years, and female undergrad enrollment is at a historic low relative to boys. Some people say, "Girls don't like to program," but I don't think that explains all of the problem. At least a few women agree with me... During a session of the Rebooting Computing Summit in January, one of the men asserted that girls don't like to program, and one of the women -- Fran Allen, I think -- asked, "Says who?" From the back of the room, a woman's voice called out, "Men!"

A lot of people outside of computer science do not know how much pioneering work in our discipline was done by women. Allen won a Turing Award for her work on languages and compilers, and the most recent Turing Award was given to Barbara Liskov, also for work in programming languages. Karen Sparck-Jones, quoted above, discovered the idea of inverse document frequency, laying the foundation for a generation of advances in information retrieval. And these are just the ones ready at hand; there many more.

When people assert that women don't like (just) to program, they usually mean that women prefer to do computer science in context, where they can see and influence more directly the effects that their creations will have in the world. One of my heroes in computing, Adele Goldberg, has demonstrated that women can like -- and excel -- on both sides of the great divide.

(Note: I am not speaking of this Adele Goldberg, who is, I'm sure, a fine computer scientist in her own right!)

Goldberg is perhaps best known as co-author of several books on Smalltalk. Many of us fortunate enough to come into contact with Smalltalk back in the 1980s cut our teeth on the fabulous "blue book", Smalltalk-80: The Language and Its Implementation. You can check out a portion of the blue book on-line. This book taught many a programmer how to implement a language like Smalltalk. It is still one of the great books about a language implementation, and it still has a lot to teach us a lot about object-oriented languages.

But Goldberg didn't just write about Smalltalk; she was in the lab doing the work that created it. During the 1970s, she was one of the principal researchers at Xerox PARC. The team at PARC not only developed Smalltalk but also created and experimented with graphical user interfaces and other features of the personal computing experience that we all now take for granted.

Goldberg's legacy extends beyond the technical side of Smalltalk. She worked with Alan Kay to develop an idea of computing as a medium for everyone and a new way for young people to learn, using the computer as a dynamic medium. They described their vision in Personal Dynamic Media, a paper that appeared in the March 1977 issue of IEEE Computer. This was a vision that most people did not really grasp until the 1990s, and it inspired many people to consider a world far beyond what existed at the time. But this paper did not just talk about vision; it also showed their ideas implemented in hardware and software, tools that children were already using to create ideas. When I look back at this paper, it reminds me of one reason I admire Goldberg's work: it addresses both the technical and the social, the abstract and the concrete, idea and implementation. She and Kay were thinking Big Thoughts and also then testing them in the world.

(A PDF of this paper is currently available on-line as part of the New Media Reader. Read it!)

After leaving PARC, Goldberg helped found ParcPlace, a company that produced a very nice Smalltalk product suitable for corporate applications and CS research alike. The Intelligent Systems Lab I worked in as a grad student at Michigan State was one of ParcPlace's first clients, and we built all of our lab's software infrastructure on top of its ObjectWorks platform. I still have ObjectWorks on 3.5" floppies, as well as some of the original documentation. (I may want to use it again some day...)

Some academics view founding a business as antithetical to the academic enterprise, or at least as not very interesting, but Goldberg sees it as a natural extension of what computer science is:

The theoretical and practical knowledge embodied in CS is interesting as standalone study. But the real opportunity lies in equipping oneself to partner with scientists or business experts, to learn what they know and, together, to change how research or business is conducted.

(I found this quote as a sidebar in Women in Computing -- Take 2, an article in a recent issue of Communications of the ACM.)

I suppose that the women-don't-like-to-program crowd might point to Goldberg's career in industry as evidence that she prefers computing in its applied context to the hard-core technical work of computer science, but I don't think that is true. Her work on Smalltalk and real tools at PARC was hard-core technical, and her work at ParcPlace on Smalltalk environments was hard-core technical, too. And she has the mentality of a researcher:

Don't ask whether you can do something, but how to do it.

When no one knows the answer, you figure it out for yourself. That's what Goldberg has done throughout her career. And once she knows how, she does it -- both to test the idea and make it better, and to get the idea out into the world where people can benefit from it. She seems to like working on both sides of the divide. No, she would probably tell us that the divide is an artificial barrier of our own making, and that more of us should be doing both kinds of work.

When we are looking for examples of women who have helped invent computer science, we find researchers and practitioners. We find women working in academia and in industry, working in technical laboratories and in social settings where applications dominate theory. We don't have to limit our vision of what women can do in computing to any one kind of work or work place. We can encourage young women who want to be programmers and researchers, working on the most technical of advances. We can encourage young women who want to work out in the world, changing how people do what they do via the dynamic power of software. If you are ever looking for one person to serve as an example of all these possibilities, Adele Goldberg may be the person you seek.

Tim Bray talks about how photography is too easy to learn:

Quoting from About Photography (1949) by American photographer Will Connell (hat tip Brendan MacRae): "Every medium suffers from its own particular handicap. Photography's greatest handicap is the ease with which the medium as such can be learned. As a result, too many budding neophytes learn to speak the language too long before they have anything to say."

Programming doesn't seem to suffer from this problem! Comments to Bray's entry about books like "C for Dummies" notwithstanding, there are not many people walking around who think programming is too easy. Mark Guzdial has described the reaction of students taking a non-majors course with a computational economics theme when they found out they would have to do a little scripting in Python. Most people who do not already have an interest in CS express disdain for programming's complexity, or fear of it. No one likes to feel stupid. Perhaps worst of all, even students who do want to major in CS don't want to program.

We in the business seem almost to have gone out of our way to make programming hard. I am not saying that programming is or can be "easy", but we should stop erecting artificial barriers that make it harder than it needs to be -- or that create an impression that only really smart people can write code. People who have ideas can write. We need to extend that idea to the realm of code. We cannot make professional programmers out of everyone, any more than piano and violin lessons can make professional musicians out of everyone. But we ought to be able to do what music teachers can do: help anyone become a competent, if limited, practitioner -- and come to appreciate the art of programming along the way.

The good news is that we can solve this "problem", such as it is. As Guzdial wrote in another fine piece:

An amazing thing about computing is that there are virtually no ground rules. If we don't like what the activity of programming is like, we can change it.

We need to create tools that expose powerful constructs to novices and hide the details until later, if they ever need to be exposed. Scratch and Alice are currently popular platforms in this vein, but we need more. We also need to connect the ability to program with people's desires and interests. Scripting Facebook seems like the opportunity du jour that is begging to be grasped.

I'm happy to run across good news about programming, even if it is only the backhanded notion that programming is not too easy. Now we need to keep on with the business of making certain that programming is not too hard.

Confluence... The Education column in the February 2009 issue of Communications of the ACM, Human Computing Skills: Rethinking the K-12 Experience, champions computational thinking in lieu of programming:

Through the years, despite our best efforts to articulate that CS is more than "just programming," the misconception that the two are equivalent remains. This equation continues to project a narrow and misleading image of our discipline -- and directly impacts the character and number of students we attract.

I remain sympathetic to this concern. Many people, including lost potential majors, think that CS == programming. I don't know any computer scientists who think that is true. I'd like for people to understand what CS is and for potential majors who end up not wanting to program for a living to know that there is room for them in our discipline. But pitching programming to the aside altogether is the wrong way to do that, and will do more harm than good -- even for non-computer scientists.

It seems to me that the authors of this column conflate CS with programming at some level, because they equate writing a program with "scholarly work" in computer science:

While being educated implies proficiency in basic language and quantitative skills, it does not imply knowledge of or the ability to carry out scholarly English and mathematics. Indeed, for those students interested in pursuing higher-level English and mathematics, there exist milestone courses to help make the critical intellectual leaps necessary to shift from the development of useful skills to the academic study of these subjects. Analogously, we believe the same dichotomy exists between CT, as a skill, and computer science as an academic subject. Our thesis is this: Programming is to CS what proof construction is to mathematics and what literary analysis is to English.

In my mind, it is a big -- and invalid -- step from saying "CT and CS are different" to saying that programming is fundamentally the domain of CS scholars. I doubt that many professional software developers will agree with a claim that they are academic computer scientists!

I am familiar with Peter Naur's Programming as Theory Building, which Alistair Cockburn brought to the attention of the software development world in his book, Agile Software Development. I'm a big fan of this article and am receptive to the analogy; I think it gives us an interesting way to look at professional software development.

But I think there is more to it than what Naur has to say. Programming is writing.

Back to the ACM column. It's certainly true that, at least for many areas of CS, "The shift to the study of CS as an academic subject cannot .. be achieved without intense immersion in crafting programs." In that sense, Naur's thesis is a good fit. But consider the analogy to English. We all write in a less formal, less intense way long before we enter linguistic analysis or even intense immersion in composition courses. We do so as a means of communicating our ideas, and most of us succeed quite well doing so without advanced formal training in composition.

How do we reach that level? We start young and build our skills slowly through our K-12 education. We write every year in school, starting with sentences and growing into larger and larger works as we go.

I recall that in my junior year English class we focused on the paragraph, a small unit of writing. We had written our first term papers the year before, in our sophomore English course. At the time, this seemed to me like a huge step backward, but I now recognize this as part of the Spiral pattern. The previous year, we had written larger works, and now we stepped back to develop further our skills in the small after seeing how important they were in the large.

This is part of what we miss in computing: the K-8 or K-12 preparation (and practice) that we all get as writers, done in the small and across many other learning contexts.

Likewise, I disagree that proof is solely the province of mathematics scholars:

Just as math students come to proofs after 12 or more years of experience with basic math, ...

In my education, we wrote our first proofs in geometry -- as sophomores, the same year we wrote our first term papers.

I do think one idea from the article and from the CT movement merits more thought:

... programming should begin for all students only after they have had substantial practice acting and thinking as computational agents.

Practice is good! Over the years, I have learned from CS colleagues encountered many effective ways to introduce students, whether at the university or earlier, to ideas such as sorting algorithms, parallelism, and object-oriented programming by role play and other active techniques -- through the learner acting as a computational agent. This is an area in which the Computational Thinking community can contribute real value. Projects such as CS Unplugged have already developed some wonderful ways to introduce CT to young people.

Just as we grow into more mature writers and mathematical problem solvers throughout our school years, we should grow into more mature computational thinkers as we develop. I just don't want us to hold programming out of the mix artificially. Instead, let's look for ways to introduce programming naturally where it helps students understand ideas better. Let's create languages and build tools to make this work for students.

As I write this, I am struck by the different nouns phrases we are using in this conversation. We speak of "writers", not "linguistic thinkers". People learn to speak and write, to communicate their ideas. What is it that we are learning to do when we become "computational thinkers"? Astrachan's plea for "computational doing" takes on an even more XXXXX tone.

Alan Kay's dream for Smalltalk has always been the children could learn to program and grow smoothly into great ideas, just as children learn to read and write English and grow smoothly into the language and great ideas of, say, Shakespeare. This is a critical need in computer science. The How to Design Programs crowd have shown us some of the things we might do to accomplish this: language levels, tool support, thinking support, and pedagogical methods.

Deep knowledge of programming is not essential to understand all basic computer science, some knowledge of programming adds so very much even to our basic ideas.

I've heard from a few of you about my previous post. People have strong feelings in both directions. If you haven't seen it already, check out Mark Guzdial's commentary on this topic. Mark explores a bit further what it means to understand algorithms and data structures without executing programs, and perhaps without writing them. I'm glad that he is willing to stake out a strong position on this issue.

Those of you who receive inroads, SIGCSE's periodical, should watch for a short article by Owen Astrachan in the next issue, called "Cogito Ergo Hack". Owen hits the target spot-on: without what he calls "computational doing", we miss a fantastic opportunity to help people understand computational ideas at a deeper level by seeing them embodied in something they themselves create. Computational doing might involve a lot of different activities, but programming is one of the essential activities.

We need as many people as possible, and especially clear thinkers and writers like Mark and Owen, to ask the questions and encourage others to think about what being a computational thinker means. Besides, catchy phrases like "computational doing" and "Cogito Ergo Hack" are likely to capture the attention of more people than my pedestrian prose!

Tweet of the Day

Haskell is a human-readable program compression format.
-- Michael Feathers

Maybe we should write a generator that produces Haskell.

Non-Tech Blog of the Day

Earlier in my career I worked hard to attract attention. ... The problem with this approach is that eventually it all burns down to ashes and no one knows a thing more about software development than they did before.
-- Kent Beck

Seek truth. You will learn to focus your life outside your own identity, and it makes finding out you're wrong not only acceptable, but desirable.

Last week, I read a paper on changes how statistics is taught. In the last few decades, more schools have begun to teach stats conceptually, so that the general university graduate might be able to reason effectively about events, variation, and conditions. This contrasts with the older style in which it was taught as a course for mathematicians, with the focus on formulas and mastery of underlying theorems. The authors said that the new style emphasized statistical thinking, rather than traditional statistics.

For some reason, this brought to mind the buzz around "computational thinking" in the CS world. I have to be honest: I don't know exactly what people mean when they talk about computational thinking. I think the idea is similar to what the stats guys are talking about: using the ideas and methods discovered in computer science to reason about processes in the real world. I certainly agree that most every college graduate could benefit from this, and that popularizing these notions might do wonders for helping students to understand why CS is important and worth considering as a major and career.

But when I look at the work that passes under the CT banner, I have a hard time distinguishing computational thinking from what I would call a publicly-accessible view of computer science. Maybe that's all it is: an attempt to offer a coherent view of CS for the general public, in a way that all could begin to think computationally.

The one thing that stands out in all the papers and presentations about CT I've seen is this: no programming. Perhaps the motivation for leaving programming out of the picture is that people find it scary and hard, so omitting it makes for a more palatable public view. Perhaps some people think that programming isn't an essential part of computational thinking. If it's the former, I'm willing to cut them some slack. If it's the latter, I disagree. But that's not surprising to readers here.

While thinking on this, I came across this analogy: computational thinking with no programming is like statistical thinking without any mathematics. That seems wrong. We may well want stats courses aimed at the general populace to emphasize application and judgment, but I don't think we want students to see statistics devoid of any calculation. When we reason about means and variance, we should probably have some idea how these terms are grounded in arithmetic that people understand and can do.

When I tried my analogy out on a colleague, he balked. We don't need much math to reason effectively in a "statistical" way, he said; that was precisely the problem we had before. Is he overreacting? How well can people understand the ideas of mean and standard deviation without knowing how to compute them? How little math can they know and still reason effectively? He offered as an example the idea of a square root. We can understand what a square root and what it means without knowing how to calculate one by hand. Nearly every calculator has a button for the square root, and most students' calculators these days have buttons for the mean -- and maybe the variance; I'll have to look at my high school daughter's low-end model to see.

For the most part, my colleague feels similarly about programming for everyone. His concern with CT is not eliminating programming but what would be taught in lieu of programming. Many of the articles we have seen on CT seem to want to replace programming with definitions and abstractions that are used by professional computer scientists. The effect is to replace teaching a programming language with teaching a relatively formal "computational thinking" language. In his mind, we should replace programming with computational skills and ideas that are useful for people involved in everyday tasks. He fears that, if we teach CT as if the audience is a group of budding computer scientists, we will make the same mistake that mathematics often has: teaching for the specialists and finding out that "everyone else is rotten at it".

The stats teaching paper I read last week says all the right things. I should look at one of the newer textbooks to see how well they carry it out, and how much of the old math skills they still teach and require.

I'm still left thinking about how well people can think computationally without learning at least a little programming. To the extent that we can eliminate programming, how much of what is left is unique to computer science? How far can we take the distinction between formula and algorithm without seeing some code? And what is lost when we do? There is something awfully powerful about watching a program in action, and being able to talk about and see the difference between dynamic behavior and static description.

I've been following the idea of open notebook science for a while, both for its meaning to science and for the technological need it creates. Yesterday I read Cameron Neylon's piece on a web-native lab notebook. It was an interesting read, though it did contain a single paragraph that ran for two pages... After he describes how to use a blog to organize an integrated record of lab activities, he says:

What we're left with is the procedures which after all is the core of the record, right? Well no. Procedures are also just documents. Maybe they are text documents, but perhaps they are better expressed as spreadsheets or workflows (or rather the record of running a workflow). Again these may well be better handled by external services, be they word processors, spreadsheets, or specialist services. They just need to be somewhere where we can point at them.

Procedures are, well, procedures. It would be very cool if we could help scientists record their procedures as code. Programs require more precision than free-form text, which would make sharing scientific procedures more reliable, and they support naturally the distinction between static and dynamic presentation. Neylon sees this opportunity when he talks about recording a procedure as a workflow or as a record of running one.

Just another wild-hair idea at the boundary where CS meets people doing their work.

I commented a couple of times in my review of the Rebooting Computing summit, about the process we used, and the reaction it created among the participants. We used an implementation of Appreciative Inquiry that emphasized collectively exploring our individual experiences and visions before springing into action.

Some people were skeptical from the outset, as some people will be about anything that so "touchy-feely". Perhaps some assumed that we all know what the problem is and that enough of us know what the solution should be and so wanted to get down to business. That seems unlikely to me. Were this problem easily understood or solved, we wouldn't have needed a summit to form action groups.

The process began to unravel on the second day, and many people were losing patience. After lunch -- more than halfway through the summit -- the entire group worked together to construct an overlaid set of societal, technical, and personal timelines of computing. For me, time began to drag during this exercise, though I enjoyed hearing the stories and seeing what so many people thought stood out in our technical history.

The 'construct a timeline of computing' was the final straw for some, especially some of the bigger names. While constructing the timeline, we found that many people in the room didn't know the right dates for the events they were adding. One of my colleagues finally couldn't stop himself and moved a couple of items to their right spots. It must have been especially frustrating for the people in the room who were there when these events were happening -- or who were the principal players! This is an example of how collaboration for collaboration's sake often doesn't work.

Later, Alan Kay referred to the summit's process as "participation without progress". Our process emphasized the former but in many ways impeded (or prevented) the latter. Kay said that this approach assumes all people's ideas are equally valid or useful. He called for something more like a representative democracy than what we had, which I would liken to a town hall form of government.

Kay may well be right, though a representative democracy-like approach risks losing buy-in and enthusiasm from the wider audience. Our representatives would need to be able either to solve the problems themselves or to energize "we, the people" to do the work. I'm not sure whether what ails computing can be solved by only a few, so I think bringing a large community on board at some point is necessary.

The next question is, who has the ideas that we should be acting on? I think the summit was a least partly successful in giving people with good ideas a chance to express them to a large group and in particular to let some of the more influential people in the room know about the people and the ideas. Unfortunately, the process throttled some other ideas with lack of interest. One that stands out to me now is the issue of outsourcing and intellectual property, which has been a dominant topic of discussion on the listserv since we left San Jose. Fortunately, people are talking about it now.

(I have to admit that I do not yet fully understand the problem. I either need more time to read or a bigger brain -- maybe both.)

In the end when we broke identified and joined action groups, some people asked, "How different is this set of action groups than if we had started the summit with this exercise?" Many people thought we would have ended up with the same groups. I think they might be right, though I'm not sure this means there was no value in the work that led to them.

Perhaps one problem was that this process does not scale well to 200+ people. If it does, then perhaps it just didn't scale well to these 200+ people. The room was full of Type A personalities. The industry people were the kind with strong opinions and a drive to solve problems. The faculty were... Well, most faculty are control freaks, and this group was representative.

Personally, I found the process to be worth at least some of the time we spent. I enjoyed looking back at my life in computing, reflecting on my own history, reliving a few stories, and thinking about what has influenced. I realized that my interest in computer science wasn't driven by math or CS teachers in high school or my undergraduate years.. I had a natural affinity for computing and what it means. The teachers who most affected me were ones who encouraged me to think abstractly and to take ideas seriously, who gave me reason to think I could do those things. The key was to find my passion and run.

I first saw that sort of passion in William Magrath my honors humanities prof, as a freshmen in college. As much as I loved humanities and political science and all the rest, I had a sense that CS was where my passion lay. The one undergrad CS prof who comes to mind as an influence, William Brown, was not a researcher. He was a serious systems guy who had come from IBM. In retrospect, I credit him with showing me that CS had serious ideas and was worth deep thought. He encouraged me subtly to go to grad school and answered a lot of questions from a naive student whose background made grad school seem as far away as the moon.

I can't give a definitive review of the Rebooting Computing workshop process because, sadly, I had to return home to do my other day job so missed the third day. From what I last, hear, the last day seemed to have clicked better for more people. I will say this. We have to realize that the goal of "rebooting" computing is a big task, and not everyone who needs to be involved shares the same context, history, motivation, or goals. It was worth trying to figure out some of that background before trying to make plans. Even if the process moved slower than some of us thought it should, it did get us all talking. That is a start, and the agile developer in me knows the value in that.

In addition to my more general comments on the Rebooting Computing summit, I made a lot of notes about the image of the discipline, which was, I think, one of the primary motivations for many summit participants. The bad image that most kids and parents have of careers in computing these days came up frequently. How can we make computing as attractive as medicine or law or business?

One of my table mates told us a story of seeing brochures for two bioinformatics programs at the same university. One was housed in the CS department, and the other was housed with the life sciences. The photos used in the two brochures painted strikingly different images in terms of how people were dressed and what the surroundings looked like. One looked like a serious discipline, while the other was "scruffy". Which one do you think ambitious students will choose? Which one will appeal to the parents of prospective students? Which one do you think was housed in CS?

Sometimes, the messages we send about our discipline are subtle, and sometimes not.

Too often, what K-12 students see in school these days under the guise of "computing" is applications. It is boring, full of black boxes with no mystery. It is about tools to use, not ideas for making things. After listening to several people relate their dissatisfaction with this view of computing, it occurred to me that one thing we might do to immediately improve the discipline's image is to get what currently passes for computing out of our schools. It tells the wrong stories!

The more commonly proposed solution is to require CS in K-12 schools and do it right. Cutting computing would be easier... Adding a new requirement to the crowded K-12 curriculum is a tall task fraught with political and economic roadblocks. And, to be honest, our success in presenting a good image of computing through introductory university courses doesn't fill me with confidence that we are ready to teach required CS in K-12 everywhere.

Don't take any of these thoughts too seriously. I'm still thinking out loud, in the spirit of the workshop. But I don't think there are any easy or obvious answers to the problems we face. One thing I liked about the summit was spending a few days with many different kinds of people who care about the problems and who all seem to be trying something to make things better.

The problems facing computing are not just about image. Some think to think so, but they aren't. Yet image is part of the problem. And the stories we tell -- explicitly and implicitly -- matter.

[This is the first of several pieces on my thoughts at the Rebooting Computing summit, held January 12-14 in San Jose, California. Later articles talk about image of CS, thoughts on approach, thoughts on personal stories and, as always, a little of this and that.]

This was unusual: a workshop with no laptops out. Some participants broke the rule almost immediately, including some big names, but I decided to follow my leaders. That meant no live note-taking, except on paper, nor any interleaved blogging. I decided to expand this opportunity and take advantage of an Internet-free trip, even back in the hotel!

The workshop brought together 225 people or so from all parts of computer science: industry, universities, K-12 education, and government. We had a higher percentage of women than the discipline as a whole, which made sense given our goals, and a large international contingent. Three Turing Award winners joined in: Alan Kay, Vinton Cerf, and Fran Allen, who was an intellectual connection to the compiler course I put on hold for a few days in order to participate myself. There were also a number of other major contributors to computing, people such as Grady Booch, Richard Gabriel, Dan Ingalls, and the most famous of three Eugenes in the room, Gene Spafford.

Most came without knowing what in particular we would do for these three days, or how. The draw was the vision: a desire to reinvigorate computing everywhere.

The location was a perfect backdrop, the Computer History Museum. The large printout of a chess program on old green and white computer paper hanging from the rafters near our upper-floor meeting room served as a constant reminder of a day when everything about computers and programming seemed new and exciting, when everything was a challenge to tackle. The working replica of Charles Babbage's Difference Engine on the main floor reminded us that big dreams are good -- and may go unfulfilled in one's lifetime.

The Introduction

Peter Denning opened with a few remarks on what led him to organize the workshop. He expressed his long-standing dissatisfaction with the idea that computer science == programming. Dijkstra famously proclaimed that he was a programmer, and proud of it, but Denning always knew there was something bigger. What is missing if we think only of programming? Using his personal experience as an example, he claimed that the outliers in the general population who make enter CS have invested many hours in several kinds of activity: math, science, and engineering.

Throughout much of the history of computer science, people made magic because they didn't know what they were doing was impossible. This gave rise to the metaphor driving the workshop and his current effort -- to reboot computing, to clean out the cruft. We have non-volatile memory, though, so we can start fresh with wisdom accumulated over the first 60-70 years of the discipline. (Later the next day, Alan Kay pointed out that rebooting leaves same operating system and architecture in place, and that what we need to do is redesign them from the bottom up, too!)

A spark ignited inside each of us once that turned us onto computing. What was it? Why did it catch? How? One of the goals of the summit was to find out how we can create the same conditions for others.

The Approach

The goal of the workshop was to change the world -- to change how people think about computing. The planning process destroyed the stereotypes that the non-CS facilitators held about CS people.

The workshop was organized around Appreciative Inquiry (AI, but not the CS one -- or the one from the ag school!), a process I first heard about in a paper by Kent Beck. It uses a an exploration of positive experiences to help understand a situation and choose action. For the summit, this meant developing a shared positive context about computing before moving on to the choosing of specific goals and plans.

Our facilitators used an implementation they characterized as Discovery-Dream-Design-Destiny. The idea was to start by examining the past, then envision the future, and finally to return to the present and make plans. Understanding the past helps us put our dreams into context, and building a shared vision of the future helps us to convert knowledge into actions.

One of our facilitators, Frank Barrett, is a former prof jazz musician, said an old saying from his past career is "Great performances create great listeners." He believes, though, that the converse is true: "Great listeners create great performances." He encouraged us to listen to one another's stories carefully and look for common understanding that we could convert into action.

Frank also said that the goal of the workshop is really to change how people talk, not just think, about computing. Whenever you propose that kind of change, people will see you as a revolutionary -- or as a lunatic.

An unusual complement to this humanistic approach to the workshop was a graphic artist who was recording the workshop live before our eyes, in image and word. Even when the record was mostly catchphrases that could have become part of a slide presentation, the colors and shapes added a nice touch to the experience.

The Spark

What excited most of us about computing was solving a problem -- having some something that that was important to us, sometimes bigger than we could do easily by hand, and doing it with a computer. Sometimes we enjoyed the making of things that could serve our needs. Sometimes we were enlivened by making something we found beautiful.

Still, a lot of people in the room "stumbled" or "drifted" into CS from other places. Those words carry quite different images of peoples' experiences. However subtle the move, they all seemed to have been working on real problems.

One of the beauties of computer science is that it is in and about everything. For many, computing is a lens through which to study problems and create solutions. Like mathematics, but more.

One particular comment made the first morning stood out in my mind. The gap between what people want to make with a computer and what they can reasonably make has widened considerably in the last thirty years. What they want to make is influenced by what they see and use every day. Back in 1980 I wanted to write a program to compute chess ratings, and a bit of BASIC was all I needed. Kids these days walk around with computational monsters in their pockets, sometimes a couple, and their desires have grown to match. Show them Java or Python, let alone BASIC, and they may well feel deflated before considering just what they could do.

Computing creates a new world. It builds new structures on top of old, day by day. Computing is different today than it was thirty years ago -- and so is the world. What excited us may well not excite today's youth.

What about what excited us might?

(Like any good computer scientist, I have gone meta.)

Educators cannot create learning. Students do that. What can educators provide? A sense of quality. What is good? What is worth doing? Why?

History

A lot of great history was made and known by the people in this room. The rest of us have lived through some of it. Just hearing some of these lessons reignited the old spark inside of me.

Consider Alan Turing's seminal 1935 paper on the Halting Problem. Part of the paper is Turing "thumbing his nose" at his skeptical mathematician colleagues, saying "The very question is computation. You can't escape it."

One time, Charles Babbage was working with his friend, the astronomer Herschel. They were using a set of astronomy tables to solve a problem, and Babbage became frustrated by errors in the tables. He threw the book at a wall and said, "I wish these calculations had been executed by steam!" Steam.

Ada Lovelace referred to Babbage's Difference Engine as a machine that "weaves patterns of ideas".

Alan Kay reminded us of the ultimate importance of what Turing taught us: If you don't like the machine you have, you can make the machine you want.

AI -- the computing kind, which was the source of many of my own initial sparks -- has had two positive effects on the wider discipline. First, it has always offered a big vision of what computing can be. Second, even when it struggles to reach that vision, it spins off new technologies it creates along the way.

At some point in the two days, Alan Kay chastised us. Know your history! Google has puts all seventy-five or so of Douglas Engelbart's papers at your fingertips. Do you even type the keywords into the search box, let alone read them?

About Computing

A common thread throughout the workshop was, what are the key ideas and features of computing that we should not lose as we move forward? There were some common answers. People want to solve real problems for real people. They want to find ideas in experience and applications. Another was the virtue of persistence, which one person characterized as "embracing failure" -- a twisted but valuable perspective. Yet another was the idea of "no more black boxes", whether hardware or software. Look inside, and figure out what makes it tick. None of these are unique to CS, but they are in some essential to it.

Problem solving came up a lot, too. I think that people in most disciplines "solve problems" and so would claim problem solving as an essential feature of the discipline. Is computer science different? I think so. CS is about the process of solving problems. We seek to understand the nature of algorithms and how they manipulate information. Whichever real problem we have just solved, we ask, "How?" and "Why?" We try to generalize and understand the data and the algorithm.

Another common feature that many thought essential to computing is that it is interdisciplinary. CS reaches into everything. This has certainly been one of the things that has attracted me to computing all these years. I am interested in many things, and I love to learn about ideas that transcend disciplines -- or that seem to but don't. What is similar and dissimilar between two problems or solutions? Much of AI comes down to knowing what is similar and what is not, and that idea held my close attention for more than a decade.

While talking with one of my table mates at the summit, I realized that this was one of the biggest influences my Ph.D. advisor, Jon Sticklen, had on me. He approached AI from all directions, from the perspectives of people solving problems in all disciplines. He created an environment that sought and respected ideas from everywhere, and he encouraged that mindset in all who studied in his lab.

Programming

While I respect Denning's dissatisfaction with the idea that computer science == programming, I don't think we should lose the idea of programming whatever we do to reinvigorate computing. Whatever else computing is, in the end, it all comes down to a program running somewhere.

When it was my turn to describe part of my vision for the future of computing, I said something like this:

When they have questions, children will routinely walk to the computer and write a program to find the answers, just as they now use Google, Wikipedia, or IMDB to look up answers.

I expected to have my table mates look at me funny, but my vision went over remarkably well. People embraced the idea -- as long as we put it in the context of "solving a problem". When I ventured further to using a program "to communicate an idea", I met resistance. Something unusual happened, though. As the discussion continued, every once in a while someone would say, "I'm still thinking about communicating an idea with a program...". It didn't quite fit, but they were intrigued. I consider that progress.

Closing

At the end of the second day, we formed action groups around a dozen or so ideas that had a lot of traction across the whole group. I joined a group interested in using problem-based learning to change how we introduce computing to students.

That seemed like a moment when we would really get down to business, but unfortunately I had to miss the last day of the summit. This was the first week of winter semester classes at my university, and I could not afford to miss both sessions of my course. I'm waiting to hear from other members of my group, to see what they discussed on Wednesday and what we are going to do next.

As I was traveling back home the next day, I thought about whether the workshop had been worth missing most of the first week of my semester. I'll talk more about the process and our use of time in a later entry. But whatever else, the summit put a lot of different people from different parts of the discipline into one room and got us talking about why computing matters and how we can help to change how the world thinks -- and talks -- about it. That was good.

Before I left for California, I told a colleague that this summit held the promise of being something special, and that it also bore the the risk of being the same old thing, with visionaries, practitioners, and career educators chasing their tails in a vain effort to tame this discipline of ours. In the end, I think it was -- as so many things turn out to be -- a little of both.

This is the busy end to a busier-than-usual semester. As a result, my only opportunity and drive to blog come from echoes. Sometimes that's okay.

Running

... or not. After six weeks or so of 26-28 miles a week -- not much by standards, but a slow and steady stream -- November hit me hard. Since 11/03 I've managed only 6-8 miles a week and not felt well the days after. My doctors are running out of possible diagnoses, which is good in one way but bad in another. In addition to the blog echo, I have an actual echo running through my head, from John Mellencamp's "Junior": Sometimes I feel better / But I never do feel well.

Building Tools

As we wrap up the semester's study of programming languages, my students took their final quiz today. I used the free time before the quiz to show them how we could imperative features -- an assignment operator and sequences of statements -- to a simple functional interpreter that they have been building over the course of the last few homework assignments. After writing a simple cell data type (10 lines of code) to support mutable data, we added 25 or so lines of code to their interpreter and modified 5 or so more. That's all it took.

I'm always amazed by what we can do in a few lines of code. Those few lines also managed to illustrate several of the ideas students encountered this semester: map, currying, and even a higher-order type predicate. Today's mini-demonstration has me psyched to add more features to the language, to make it more useful both as a language and as an example of how language works. If only we had more time...

After class, I was talking with a student about this and that related to class, internships, and programming. He commented that he now groks what The Pragmatic Programmer says about writing your own tools and writing programs to generate code for you. I smiled and thought, yep, that's what programmers do.

40th Anniversaries

Today was one of the 40th anniversaries I mentioned six weeks ago: Douglas Engelbart's demonstration of a mouse-controlled, real time-interactive, networked computer. SFGate heralds this as the premiere of the PC, but this event has always seemed more about interaction than personal computing. Surely, the kind of interactivity that Engelbart showed off was a necessary precursor to the PC, but this demonstration was so much more -- it showed that people can interact with digital media and, yes, programs in a way that connects with human needs and wants. Engelbart's ideas will out-live what we know as the personal computer.

No matter, though. The demonstration inspired a generation. A friend of mine sent a note to all his friends today, asking us to "drink a toast to Douglas Engelbart" and reminiscing on what personal computing means to many of us:

Think how much this has changed our lives... The communication capabilities allow us to communicate extremely quickly, throughout the globe. The PC, and Internet, allow me to have friends in Australia, Belfast, Brazil, China, Holland, India, Japan, London, Switzerland, and many other places. ... Can you even picture a world without PC's? I've seen and used them in remote places like Nosy Be, Madagascar, and Siem Reap, Cambodia.

The world is a different place, and many of us -- my friend included -- contribute to that. That humbles and awes me.

Programming Matters

Don't need programmers, only smart people? Or people with good "people skills"? Today on the Rebooting Computing mailing list, Peter Norvig wrote:

At Google, a typical team might be 1 software architect, 5 software designers who are also responsible for development, testing, and production, and one product manager. All 7 would have CS BS degrees, and maybe 2 MS and 2 PhDs. Programming is a significant part of the job for everyone but the product manager, although s/he typically has programming experience in the past (school or job). Overall, programming is a very large part of the job for the majority of the engineering team.

Sure, Google is different. But at the end of the day, it's not that different. The financial services companies that hire many of my university's graduates are producing business value through information technology. Maximizing value through computing is even more important in this climate of economic uncertainty. Engineering and scientific firms hire our students, too, where they work with other CS grads and with scientists and engineers of all sorts. Programming matters there, and many of the programmers are scientists. The code that scientists produce is so important to these organizations that people such as Greg Wilson would like to see us focus more on helping scientists build better software than on high-performance computing.

Those who can turn ideas into code are the masters of this new world. Such mastery can begin with meager steps, such as adding a few lines of code to an interpreter make imperative programming come alive. It continues when a programmer looks at the result and says, "I wonder what would happen if..."

Today, I was asked the best question ever by a high-school student.

During the fall, we host weekly campus visits by prospective students who are interested in majoring in CS. Most are accompanied by their parents, and most of the dialogue in the sessions is driven by the parents. Today's visitors were buddies from school who attended sans parents. As a part of our talking about careers open to CS grads, I mentioned that some grads like to move into positions where they don't deal much with code. I told them that two of the things I don't like about my current position is that I only get to teach one course each semester and that I don't have much time to cut code. Off-handedly, I said, "I'm a programmer."

Without missing a beat, one the students asked me, "What hobby projects are you working on?"

Score! I talked about a couple of things I work on whenever I can, little utilities I'm growing for myself in Ruby and Scheme, and some refactoring support for myself in Scheme. But the question was much more important than the answer.

Some people like to program. Sometimes we discover the passion in unexpected ways, as we saw in the article I referred to in my recent entry:

[Leah] Culver started out as an art major at the University of Minnesota, but found her calling in a required programming class. "Before that I didn't even know what programming was," she admits. ... She built Pownce from scratch using a programming language called Python.

Programmers find a way to program, just as runners find a way to run. I must admit, though, that I am in awe of the numbers Steve Yegge uses when talking about all the code he has written when you take into account his professional and personal projects:

I've now written at least 30,000 lines of serious code in both Emacs Lisp and JavaScript, which pales next to the 750,000 or so lines of Java I've [spit] out, and doesn't even compare to the amount of C, Python, assembly language or other stuff I've written.

Wow. I'll have to do a back-of-the-envelope estimate of my total output sometime... In any case, I am willing to stipulate to his claim that:

... 30,000 lines is a pretty good hunk of code for getting to know a language. Especially if you're writing an interpreter for one language in another language: you wind up knowing both better than you ever wanted to know them.

The students in our compiler course will get a small taste of this next semester, though even I -- with the reputation of a slave driver -- can't expect them to produce 30 KLOC in a single project! I can assure them that they will make a non-trivial dent in the 10,000 hours of practice they need to master their discipline. And most will be glad for it.

Courtesy of Brian Marick and his Agile Development Practices keynote:

Humans plus running code are smarter than humans plus time.

We can sit around all day thinking, and we may come up with something good. But if we turn our thoughts into code and execute it, we will probably get there faster. Running a piece of code gives us information, and we can use that feedback to work smarter. Besides, the act of writing the code itself tends to make us smarter, because writing code forces us to be honest with ourselves in places where abstract thought can get away with being sloppy.

Brian offers this assertion as an assumption that underlies the agile software value of working software, and specifically as assumption that underlies a guideline he learned from Kent Beck:

No design discussion should last more than 15 minutes without someone turning to a computer to do an experiment.

An experiment gives us facts, and facts have a way of shutting down the paths to fruitless (and often strenuous) argument we all love to follow whenever we don't have facts.

I love Kent Beck. He has a way of capturing great ideas in simple aphorisms that focus my mind. Don't make the mistake that some people make, trying to turn one of his aphorisms into more than it is. This isn't a hard and fast rule, and it probably does not apply in every context. But it does capture an idea that many of us in software development share: execucting a real program usually gives us answers faster and more reliably than a bunch of software developers sitting around pontificating about a theoretical program.

As Brian says:

Rather than spending too much time predicting the future, you take a stab at it and react to what you learn from writing and running code...

This makes for a nice play on Alan Kay's most famous bon mot, "The best way to predict the future is to invent it." The best way to predict the future of a program is to invent it: to write the program, and to see how it works. Agile software development depends on the fact that software is -- or should be -- soft, malleable, workable in our hands. Invent the future of your program, knowing full well that you will get some things wrong, and use what you learn from writing and running the program to make it better. Pretty soon, you will know what the program should look like, because you will have it in hand.

To me, this is one of the best lessons from Brian's keynote, and well worth an Agile Thought.

A recent article at Fast Company highlights some of the Most Influential Women in Web 2.0. This list "wasn't chosen by star power, nor by career altitude" but for the biggest innovations in the nebulous sphere of Web 2.0. This list is also not a random sample, which makes drawing conclusions from it dicey. Yet I could not help noticing how few of them have CS background:

• Sinha: cognitive neuroscience
• Kaplan: economics, government, philosophy, and history
• Page/Des Jardins/Stone: theatre/English lit/political science
• Huffington: economics
• Banister: HS drop-out
• Bianchini: political science, then MBA
• Fake: English
• Trott: English
• Hamlin: political economy and human rights
• Mayer: systems science (after starting in biology and chemistry), then M.S. in CS
• Culver: computer science (after starting in art)

Perhaps this is a non-representative sample of women in computing or Web 2.0. Or perhaps the range of backgrounds we see here, especially its tilt toward the humanities, says more about the social and interactive nature of Web 2.0 than about computer science. Perhaps it says something about women and what they want out of their academic majors.

Somehow, though, I think this list is a great example of why we need to broaden the public's conception of computing, in hopes that more might choose to major in CS. I also think it is also a great example of why we as a discipline need to engage students all across the campus. We need to expose more (all?) students to expose them to the power of the ideas of computing and give them some of the skills they will need to apply it to whatever they decide to do.

I'm glad these innovators and women found computing along the way to turning their ideas into reality, but I'd like for us to eliminate some of the barriers that we erect between computer science and tomorrow's innovators.

Just before I left for the SECANT workshop, I wrote an entry on programming based on a conversation with a colleague in the math department. Then I went off to SECANT, which gave me a chance to think about the intersection of CS and science, which took my mind off of the role CS plays in mathematics. But the gods are reminding us: Computer science is changing how some mathematicians work, and not just via programming.

The December 2008 issue of the Notices of the American Mathematical Society features four papers on the use of computers in mathematical proof, both to create new results and to ask and explore "new mathematical questions about the nature and technique of such proofs". This idea is known as formal proof. All four papers of the special issue are available as PDF files on the web site. (This is an excellent feature of Notices: the current issue is openly available to the community!).

The lead article of the issue, by Thomas Hales, lays out the problem for which Formal Proof is the solution. In a nutshell: mathematicians verify their results by a social process, which means those results are fallible.

Traditional mathematical proofs are written in a way to make them easily understood by mathematicians. Routine logical steps are omitted. An enormous amount of context is assumed on the part of the reader.

Many of you probably already know that this is true, from your own negative experience. I know that I often felt as if I was missing a lot of context when I was reading proofs in the abstract algebra book we used in grad school!

How are these proofs validated? By other mathematicians reading them and accepting them as valid. The best known and most important proofs have been read and understood by many mathematicians, so we can trust that they are probably correct. If there were something wrong with the result, someone would have found out by now -- either by by finding an error in the proof or by discovering that something else breaks when we rely on it. Programmers know that this is how most programs are "proven" correct: by using them reliably for a long time under many different conditions.

One problem with this process is that some proofs are so long and so complicated that the number of people who can read and understand them is quite small. For the results that break the most new ground, even the best mathematicians have to learn a lot to understand the proof. These "proof assistants" may not have the time, energy, or attention span to validate a result well enough that we "know" it is correct.

A formal proof is an attempt to bypass the social process of mathematicians reading a result, providing the necessary context, filling in the details, and approving the result by automating those steps:

A formal proof is a proof in which every logical inference has been checked all the way back to the fundamental axioms of mathematics. All the intermediate logical steps are supplied, without exception. No appeal is made to intuition, even if the translation from intuition to logic is routine.

A formal proof will be less intuitive to most human readers, especially the advanced ones, but it should be less susceptible to errors by relying on formal specification of the context and of all the intermediate steps. "Show your work!"

Specifying all of the extra detail completely is something humans are not so good at. Many great mathematicians -- and programmers -- are great in some part because they are able to take improbable intuitive leaps onto new ground. But computers thrive on such tedious detail, so work on formal proof comes naturally to rest in the realm of programs that aid the process.

Computerized "proof assistants" are nothing new. Hales cites examples going back to 1954 and the Johniac computer. I can't go that far back (my parents were still in grade school!), but I remember working with programs of this sort back in the mid- to late-1980s as a grad student in AI. Prof. Rich Hall, a philosophy professor specializing in epistemology and philosophy of mind, was a treasured member of my Ph.D. committee. For the philosophy component of my comprehensive, Hall asked me to study two such programs, Tarski's World and Computer Assisted Logic Lessons (CALL), intended as logic tutors and proof assistants for beginners. (Tarski's World is discussed here. CALL was a program home-brewed at Michigan State. I found one reference to it via Google, in an MSU prof's syllabus from 1998.) My task was to identify the fundamental distinctions between the two programs, especially with regard to their respective assumptions, and to evaluate their instructional utility. Remarkably, I still have the paper I wrote for my exam -- formatted in nroff!

Formal proof sounds perfect: Let a program do the grunt work to validate even our most complex proofs. But formal proof offers up to problems... The first is that the human has to specify some of the initial detail for the program in some logical language. One thing that many years in AI taught me is that logic languages are just like programming languages, and writing proofs in them encounters all the same perils as writing a program. Writing proofs is the cross borne by mathematicians, though, and this problem is exactly the one formal proof seeks to solve (a recursive problem!): making sure that our proofs contain all the necessary detail, written and used correctly.

The second problem is that now we have to consider whether the computer program itself is correct. To use the program to validate a proof, we need first to validate the program. This is a different recursion. Fortunately, we have some things on our side. One is scale, both relative to large programs and to the proofs we hope to construct. As Hales points out:

The computer code that implements the axioms and rules of inference is referred to as the kernel of the system. It takes fewer than 500 lines of computer code to implement the kernel of HOL Light [a particular computer proof assistant]. (By contrast, a Linux distribution contains approximately 283 million lines of computer code.)

The "kernel" of the system is small enough to be amenable to validation in several ways. One is the social process used for other programs: make the code open source and let everyone and his brother study it and use it. I love the way Hales embraces this approach:

I wish to see a poster of the lines of the kernel, to be taught in undergraduate courses, and published throughout the world, as the bedrock of mathematics. It is math commenced afresh as executable code.

(The emphasis is mine. More on that later.)

This replaces the social process for validating proofs, up one level. Even if we validate the proof assistant only informally, it will be used repeatedly to validate proofs, and every use is an opportunity to find errors in the program. We can even use the program to validate proofs we already understand well just for the purpose of validating the program. (The world of mathematics is full of test data!) We use a social process to build a tool which then serves us over and over. Building tools is an essence of computer science.

Given the small size of the program, we could also use formal methods to prove its correctness or at least offer evidence that it is correct. John Harrison used HOL Light to something akin to a formal proof of its own soundness. This is the first time in a long while that I have read about Gödel's incompleteness theorem coming into play with a real program... This approach made me think of the compiler-writing technique known as bootstrapping, though that's not quite what Harrison did.

Finally, we might try to validate the program using another proof assistant. Hales calls this "exporting" a proof. The idea is this. Translate a proof written for one assistant into the language of another.

If a proof in one system is incorrect because of an underlying flaw in the theorem-proving program itself, then the export to a different system fails, and the underlying flaw is exposed.

For some reason, this reminded of cross-compilation, where we use a compiler on one platform to generate code for another platform. The purpose of cross compiling is to propagate programs onto systems where they do not exist yet. The purpose of exporting is different, to increase our confidence in one or both proof assistants. When we combine the confidence we have in the program via social acceptance with the confidence we gain from validating exported proofs, we have even more reason to trust the program, and thus the proofs it validates. Our confidence grows.

This process reminds us all that math, while not a natural science, is imbued with the spirit of science:

With a computer -- indeed with any physical artifact, whether a codex, transistor, or a flash drive made of proteins from salt-marsh bacteria -- it is never a matter of achieving philosophical certainty. It is a scientific knowledge of the regularity of nature and human technology, akin to the scientific evidence that Planck's constant lies reliably within its experimental range. Technology can push the probability of a false certification ever closer to zero: 10^-6, 10^-9, 10^-12, ....

We never know our proofs are correct. We only have good reason to believe so. The same is true of programs. That's another reason for a computer scientist like me to be fascinated by this direction in mathematics.

The connection to the topic of the SECANT workshop is strong. Computing is helping to revolutionize how mathematicians work, just as it is revolutionizing how scientists work. Part of the math revolution will resemble the one in science, because some math research is itself inherently computational. The changes we talk about with formal proofs are a bit different, in that they are about how we validate results, not how we create them.

Both traditional mathematics and computational mathematics depend ultimately on validation. Formal proof is aimed at addressing the former, but what of the latter? Certainly some scientists have recognized the problem and embarked on efforts to solve it. I wrote about one such effort early this year, a simulation-and-documentation system that interleaves programs, their execution, and the papers written to publish the results. Not surprisingly, such thinking and the systems that implement it require a change in mindset, one that will likely come only after a long... social process.

Hales recognizes what the use of computing to generate and check proofs means for his discipline: It is math commenced afresh as executable code. I think many disciplines will find themselves redefined in just this way.

[A transcript of the SECANT 2008 workshop: Table of Contents]

The last session of an eventful workshop consisted of two people. One was a last minute sub for a science speaker who had to pull out. The sub, from Microsoft Research, didn't add much science content, but did say something I wish undergrads would pick up on. What do all companies look for these days? Short ramp-up time, self-starters. These boil down to curiosity and initiative.

The second speaker gave the sort of industry report I so enjoyed last year. David Spellmeyer, a Purdue computer science and chemistry grad, is CTO and CIO at Nodality. He titled his talk, "Computational Thinking as a Competitive Advantage in Industry". I love that title! because I love the ways computing confers a competitive advantage over companies that don't get it yet. The downside of Spellmeyer talking about his own company's competitive advantage: he can't post his slides.

Spellmeyer did tell us a bit about his company's science at various points in his story. Nodality works on patient-specific classification of disease and response to therapies. At least part of that involves evaluating phosphoprotein-signaling networks. (I hope that doesn't give too much away.)

He looks for computational thinking skills in all of the scientists Nodality hires. His CT wish list included items familiar and surprising:

• familiarity with the complexity of computing
• exposure to programming languages
• analytical methods for experimental studies
• familiarity with the technology and inner workings of the computer, especially database

These skills give competitive advantage to his company -- and also to the individual! The company is able to do more better and faster. The individual has better judgment across a wider range of problems. These advantages intersect at a point where computational thinking demystifies the computer, computer systems, and programming. Understanding even a little about computers and programs helps to dispel myth of the perfect computer and the perfect computer system. Those myths create frustrations that grow into more. (Spellmeyer used another image to drive this point home: Hitchcock's North by Northwest.)

How does computational thinking help the company do more better and faster? By...

• ... letting scientists spend more time doing what they love.
• ... eliminating low-value-add transactional activities in the business process.
• ... boosting the speed and scalability of their systems.

Notice that these advantages range from the scientific to business process to the technical. It's not only about techies sitting in front of monitors.

On the scientific side of the equation, Nodality has a data problem. A robust assay produces a flood of data:

10⁶ cells/patient X 50 patients/experiment 20 challenges X 20 markers
’ 10¹⁰ data points per experiment

Thereafter followed a lot of detail that I couldn't follow in real time, which is probably just as well. There is a reason that Spellmeyer can't post his slides...

How do they eliminate low-value-added transactional activities?

• Talk to customers.
• Find patterns of practice.
• Propose computational tools to improve practice.
• Use an agile approach to gather requirements, design a system, field, get feedback, and iterate in short cycles.

Computational thinking enables scientists and techies to think of their experiments, and how to set them up, in different ways. For example, they might conceive of a way to set up a cytometer differently. They also think differently about experiment analysis and inventory management.

As Spellmeyer wrapped up, he he included a few snippets to motivate his ideas and the scale of the problems that he and his company face. He quoted Margaret Wheatley as saying that all science is a metaphor, a description of a reality we can never fully know. As a pragmatist, this is something I believe almost from the outset. He also said that in business, learning occurs naturally through normal interactions in work practices. Not in classes. "Context, community, and content" are the triumvirate that drives all they do. For this reason, his company puts a lot of effort into its community software tools.

The problem ultimately comes down to an issue at the intersection of combinatorics, pragmatics, and even ethics. We can make billions of unique molecules. Which ones should we make? We need to consider molecules similar enough to ones we understand but dissimilar enough to offer hope of a new result. This leads to a question of similarity and dissimilarity, one of those AI-complete tasks. There is room for a lot of great algorithm exploration here.

Finally, Spellmeyer weighed in on a hot topic from the previous session: Excel is a basic tool in his company. The business guys have developed an extremely complex business model, and all of their work is in Excel. But it's not just a work horse on the business side; scientists use Excel to transform data. He is happy to find scientists and techies alike who know how to use Excel at full strength.

[A transcript of the SECANT 2008 workshop: Table of Contents]

This session was labeled "birds-of-a-feather", likely a track for short talks that didn't fit very well elsewhere. The most common feather was curriculum, efforts to develop it and determine its effect.

First up was Ruth Chabay, on looking in detail at students' computational thinking skills. She is involved in a pilot study that aims to answer the question, "Do students think differently about physics after programming?" This is the sort of outcomes assessment that people who develop curriculum rarely do. Even CS faculty -- despite the fact that we would never think of writing programs and not checking to see whether they ran correctly. This study is mostly question and method at this point, with only hints at answers.

The research methodology is a talk-aloud protocol with videotaping of the participants' behavior. Chabay showed an illustrative video of a student reasoning through a very simple program, talking about the problem. I'd love to be able to observe students from some of my courses in this way. It would be hard to gather useful quantitative data, but the qualitative results would surely give some insight into what some students are thinking when they are going their own way.

Next up was Rubin Landau, who developed a Computational Physics program at Oregon State. He started with a survey from the American Physical Society which reported what do physics grads do 5 years after they leave school. A large percentage are involved in developing software, but alumni said that the number one skill they use is "scientific problem solving". Even for those working in scientific positions, the principles of physics are far from the most important skill. Landau stressed that this does not mean that physics isn't important; it's just that students don't graduate to repeat what they learned as an undergrad. In Landau's opinion, much of physics education is driven by the needs of researchers and for graduate students. Undergraduate curriculum is often designed as a compromise between those forces and the demands of the university and its undergraduates.

Landau described the Computational Physics curriculum they created at Oregon State with the needs of undergrad education as the driving force. I don't know enough physics to follow his description in real-time, but I noticed a few futures. Students should learn two "compiled languages"; it doesn't really matter which, though he still likes it if one is Fortran. The intro courses introduce many numerical analysis concepts involving computation (underflow, rounding). This course is now so well settled that they offer it on-line with candid video mini-lectures. Upper-division courses include content that students may well work with in industry but which have disappeared from other schools' curricula, such as fluid dynamics..

Landau is fun to listen to, because he has an arsenal of one-liners at the ready. He reported one of his favorite computational physics student comments:

Now I know what's "dynamic" in thermodynamics!

Bruce Sherwood reported a physics student comment of his own: "I don't like computers." Sherwood responded, "That's okay. You're a physicist. I don't like them either." But physics students and professors need to realize that saying they don't like computers is like saying, "I don't like voltmeters." If you can't work with a voltmeter or a computer, you are in the wrong business. That's just the way the world is.

My favorite line of Landau's is one that applies as well to computer science as to physics:

We need a curriculum for doers, not monks.

The next two speakers were computer scientists. James Early described a project in which students are developing learner-centered content for their introductory computer science course. This project was motivated by last year's SECANT workshop. Most of the students in their intro course are not CS majors. The goal of the project is to excite these students about computation, so they'll take it back to their majors and put it to good use. I immediately thought, "I'd like to have CS majors get excited about computation and take it back to their major, too!" Too few CS students take full advantage of their programming skills to improve their own academic lives...

Resource link to explore: the Solomon-Felder Index of Learning Styles, which has gained some market share in engineering world. Besides, it's on-line and free!

Mark Urban-Lurain closed the session by describing the CPATH project at Michigan State, my old graduate school stomping grounds. This project is aimed at creating a process for redesigning engineering curriculum. But much of the interesting discussion revolved the fact that most engineering firms request that students have computational skills in... Excel! Several of the CS faculty in the room nodded their heads, because they have pointed this out to their colleagues and run into a stonewall. CS departments balk at such "tools". Now, Excel is not my tool of choice, but macros really are a form of programming. I've been following with interest some work in the Haskell community on programming in spreadsheets (see some of the papers here. We in CS have more powerful tools to use and teach, but we also need to meet users of computation where the live. And in many domains, that is the spreadsheet.

I ended the workshop by chatting with Urban-Lurain, with whom I came into contact as a teaching assistant. His colleague on this CPATH project is my doctoral advisor. It is a small world.

[A transcript of the SECANT 2008 workshop: Table of Contents]

The first day of the workshop ended with two panels of two computer scientists each. The first described two current projects on introductory CS courses, and the second presented two CPATH projects related to the goals of SECANT. I either knew about these projects already or was familiar with their lessons from my department's experiences, so I didn't take quite as detailed notes. Then again, maybe I was just tiring after a long day of good stuff.

On intro CS, Deepak Kumar talked about Learning Computing with Robots, which has developed a course that serves primarily non-majors, with a goal of broadening interest in computing, even as a general education course. This course teaches computing, not robotics. Kumar mentioned that the cost of materials is no longer the issue it once was. They have built the course around a robot kit that costs in the neighborhood o $110 -- about the same price as a textbook these days!

Next, Tom Cortina talked about Teaching Key Principles of Computer Science Without Programming. In many ways, Cortina was swimming against the tide of this workshop, as he argued that non-majors could (should?) learn CS minus the programming. There certainly is a lot of cool stuff that students can learn using canned tools, talking about history, and doing some light math and logic. Cortina's course in particular covers a lot of neat material about algorithms. But still I think students miss out on something useful -- even central to computing -- when they bypass programming altogether. However, if the choice is between this course and a majors-style course that leaves non-majors confused, frustrated, or hating CS, well, then, I'll take this!

The second "panel" presented two related CPATH projects. Valerie Barr of Union College described efforts creating a course in computational science across the curriculum at Union and Lafayette College. The key experience she reported was on how to build an initial audience for the course, so that later word of mouth can spread. Barr's experience sound familiar: blanket e-mail to faculty tends not to work well, but one-on-one conversations with faculty do -- especially ongoing contact and continued conversation. This sort of human contact is time-intensive, which makes it hard to scale as you move to schools much larger than Union or Lafayette. Barr said that they had had good luck dealing with people in their Career Center, who could tell students how useful computational skills are across all the majors on campus. At my school, we have had similar good results working with people in Academic Advising and Career Services. They seem to get the value of computational skills as well as or better than faculty across campus, and they have different channels than we do for reaching students over the long term.

Finally, Lenny Pitt described the iCUBED project at the University of Illinois. The one content fact I remember from Pitt's talk is that they are working to develop applied CS programs and "CS + <X>" programs within other departments. The most memorable part of his talk for me, though, was how he had reconfigured the project's acronym (which they inherited from enabling policy or legislation) based on the workshop's theme and 2008 mantra: "Infiltration: Computing Used By Every Discipline." Creative!

[A transcript of the SECANT 2008 workshop: Table of Contents]

As always, at this workshop I have heard lots of one-liners and one-off comments that will stick with me after the event ends. This entry is a place for me to think about them by writing, and to share them in case they click with you, too.

The buzzword of this year's workshop: infiltration. Frontal curricular assaults often fail, so people here are looking for ways to sneak new ideas into courses and programs. An incremental approach creates problems of its own, but agile software proponents understand its value.

College profs like to roll their own, but high-school teachers are great adapters. (And adopters.)

Chris Hoffman, while describing his background: "When you reach my age, the question becomes, 'What haven't you done?' Or maybe, 'What have you done well?'"

Lenny Pitt: "With Python, we couldn't get very far. Well, we could get as far as we wanted, but students couldn't get very far." Beautiful. Imagine how far students will get with Java or Ada or C++.

Rubin Landau: "multidisciplinary != interdisciplinary". Yes! Ideas that transform a space do more than bring several disciplines into the same room. The discipline is new.

It's important to keep in mind the relationship between modeling and computing. We can do model without computing. But analytical models aren't feasible for all problems, and increasingly the problems we are interested in fall into this set.

Finally let me re-run an old rant by linking to the original episode. People, when you are second or third or sixth, you look really foolish.

[A transcript of the SECANT 2008 workshop: Table of Contents]

As much as computation is now changing biology, it has already changed physics. Last year's workshop had a full complement of physicists and astronomers. In their minds, it is already clear that physicists must program -- even students learning intro physics. The question is, what problems do they face in bringing more computation to physics education? This panel session shared some physicists' experience in the trenches. Bruce Sherwood, the panel chair, set the stage: We used to be able to describe physics as theory, experiment, and the interplay between the two. This is no longer true, and it hasn't been for a while. Physics is now theory, experiment, simulation, and the interplay among the three! Yet this truth is not reflected in the undergraduate physics curriculum -- even at so-called "respectable schools".

Rubin Landau described a systemic approach, a Computational Physics major he designed and implemented at Oregon State. He was motivated by what he saw as a turning inward of physics, efforts to cover all of the history of physics in the undergrad curriculum, with a focus on mathematics from the 19th century, and not looking outward to how physics is done today. (This CS educator felt immediate empathy for Landau's plight.) He noted his own embarrassment: computational physicists at major physics conferences who refuse to discuss their algorithms or the verification of their programs. This is simply not part of the culture of physics.

Students learn by doing, so projects are key to this Computational Physics curriculum. Students use a "compiled language", which is Landau's way to distinguish programming in a CS-style language from Mathematica and Maple. For him, the key is to separate the program from engine; students need to see the program as an idea. Two languages is better, as that gives students a chance to generalize the issues at play in using computation for modeling.

The OSU experience is that the political issues in changing the curriculum are much tougher to solve than the academic issues: the need for budget, the resistance of senior faculty, the reluctance of junior faculty to risk tenure, and so on.

Landau closed by saying that, for physics-minded students, using computation in physics and then taking a CS course seems to work best. He likened this to the use of Feynman diagrams in grad school: students learn to calculate with them, and then learn the field theory behind them the next year. His undergrads have several "A-ha!" moments throughout CS1. I suspect that this approach would work for a lot of CS students, too, if we can get them to use computation. Media computation is one avenue I've seen work with some.

Next up was Robert Swendsen, from Carnegie-Mellon. In the old days, physicists wrote programs because they did not know how to solve a problem analytically. Now, they compute to solve problems that no one knows how to solve analytically. (Mental note: It also lets them ask new questions.) The common problem many of us face: we tend to teach the course we took -- something of a recursion problem. (Mental note: Where is the base case? Aristotle, I suppose.)

Swendsen identified a few other challenges. Students are used to looking at equations, though if they don't get as much from them as we do, but they have no experience looking at and reasoning about data. They struggle even with low-level issues such as accuracy in terms of the number of significant digits. Further, many students do not think that computational physics is "real" physics. To them, physics == equations.

This is a cultural expectation across the sciences, a product of the few centuries of practice. Nor is it limited to students; people out in the world think of science as equations. Perhaps they pick this notion up in their high-school courses, or even in their college courses. I think that faculty in and out of the sciences share this misperception as well. The one exception is probably biology, which may account for part of its popularity as a major -- no math! no equations! I couldn't help but think of Bernard Chazelle's efforts to popularize the notion that the algorithm is the idiom of modern science.

Listening to Swendsen, I also had an overriding sense of deja vu, back to when CS faculty across the country were trying to introduce OO thinking into the first-year CS curriculum. Curriculum change must share some essential commonalities due to human nature.

Physicist Mark Haugan focused on a particular problem he sees: a lack of continuity across courses in the physics curriculum with respect to computation. Students may use computation in one course and then see no follow-through in their next courses. In his mind, students need to learn that computation is a medium for expressing ideas -- a theme regular readers of this blog will recognize. Mathematical equations are one medium, and programs are another. I think the key is that we need to discuss and work with problems where computation matters -- think Astrachan's Law -- problems for which the lack of computation would limit our ability to understand and solve the problem. This, too, echoes the OO experience in computer science education. We still face the issue that other courses and other professors will do things in a more traditional way. This is another theme common to both SECANT workshops: we need to help students feel so empowered by computation that they use it unbidden in their future courses.

The Q-n-A session contained a wonderful thread on the idea of physics as a liberal art. One person reported a comment made by a student who had taken a computational physics course and then read a newspaper article on climate modeling:

Wow. Now I know what that means.

I can think of no higher "student learning outcome" we in computer science can have for our general education and introductory programming courses: Wow. Now I know what that means.

There are many educated people who don't what "computer model" means. They don't understand what is reported in the news. There are many educated people reporting the news who don't understand the news they are reporting.

That's not right.

[A transcript of the SECANT 2008 workshop: Table of Contents]

The next session of the workshop was a panel of university faculty working in the health sciences, talking about how they use computation in their disciplines and what the key issues are. Panel chair, Raj Acharya, from Penn State's Computer Science and Engineering department, opened with the bon mot "all science is computer science", a reference to a 2001 New York Times piece that I have been using for the last few years when speaking to prospective students, their parents, and other faculty. By itself, this statement sounds flip, but it is true in many ways. The telescope astronomers use today is as much a computational instrument as a mechanical one. Many of the most interesting advances in biology these days are really bioinformatics.

The dawn of big data is changing what we do in CS, but it's having an even bigger effect in some other sciences by creating a new way to do science. Modeling is a nascent research method based in computation: propose model, test it against the data, and iterate. Data mining is an essential step in this new process: all of the data goes into a box, and the box has to make the sense of the data. This swaps two steps in the traditional scientific method... Instead of forming a hypothesis and then testing it by collecting data, a scientist can mine a large collection of data to find candidate hypotheses, and then confirm with more traditional bench science and by checking models against other and larger data sets.

Tony Hazbun, who works in the School of Pharmacy at Purdue, talked about work in systems biology. He identified four key ideas that biologists need to learn from computer science, which echoed a talk from last year's workshop:

• data visualization
• database management (relational, not flat)
• data classification (cluster analysis)
• modeling

Hazbun made one provocative claim that I think hits the heart of why this sort of science is important. We mine data sets to see patterns that we probably would not have seen otherwise. This is approach is more objective than traditional science, in which the hypotheses we test are the ones we create out of our own experience. This is a much more personal approach -- and thus more subjective. Data mining helps us to step outside our own experience.

Next up was Daisuke Kihara, a Purdue bioinformatician who was educated in Japan. He talked about the difficulties he has had building a research group of graduate students. The main problem is that biology students have few or no skills in mathematics and programming, and CS students know little or no biology. In the US, he said, education is often too discipline-specific, with not enough breadth, which limits the kind of cross-fertilization needed by researchers in bioinformatics. My university created an undergraduate major in Bioinformatics three years ago in an effort to bridge this gap, in part because biotechnology is an industry targeted for economic development in our state.

(My mind wandered a bit as I thought about Kihara's claim about US education. If he is right, then perhaps the US grew strong technically and academically during a time when the major advances came within specific disciplines. Now that the most important advances are coming in multidisciplinary areas, we may well need to change our approach, or lose our lead. I've been concerned about this for a year or so, because I have seen the problem of specializing too soon creeping down into our high schools. But then I wondered, is Kihara's claim true? Computer science has a history grounded in applications that motivate our advances; I think it's a relatively recent phenomenon that we spend most of our time looking inward.)

In addition to technical skills and domain knowledge, scientists of the future need the elusive "problem-solving skills" we all talk about and hope to develop in our courses. Haixu Tang, from the Informatics program at Indiana contrasted the mentality of what he called information technology and scientific computing:

• technique-driven versus problem-driven
• general models versus specific, even novel, models
• robust, scalable, and modular software versus accurate, efficient programs

These distinctions reflect a cultural divide that makes integrating CS into science disciplines tough. In Tang's experience, domain knowledge is not the primary hurdle, but he has found it easier to teach computer scientists biology than to teach biologists computer science.

Tang also described the shift in scientific method that computing enables. In traditional biology, scientists work from hypothesis to data to knowledge, with a cycle from data back to hypothesis. In genome science, science can proceed from data to hypothesis to knowledge, with a cycle from hypothesis back to data. The shift is from hypothesis-driven science to data-driven science. Simulation has joined theory and statistics in the methodological toolbox.

In the Q-n-A session that followed the panel, someone expressed concern with data-driven research. Too many people don't go back to do the experiments needed to confirm hypotheses found via data mining or to verify their data by independent means. The result is bad science. Olga Vitek, a statistical bioinformatician, replied that the key is developing skill in experimental design. Some researchers in this new world are learning the hard way.

The last speaker was Peter Waddell, a comparative biologist who is working to reconstruct the tree of life based on genome sequences. One example he offered was that the genome record shows primates' closest relatives to be... tree lemurs and shrews! This process is going slowly but gaining speed. He told a great story about shotgun sequencing, BLAST, and the challenges in aligning and matching sequences. I couldn't follow it, because I am a computer scientist who needs to learn more biology.

When Waddell began to talk about some of the computing challenges he and his colleagues face, I could follow the details much better. They are working with a sparse matrix that will have between 10² and 10³ rows and between 10² and 10⁹ (!!) columns. The row and column sums will differ, but he needs to generate random matrices having the same row and column sums as the original matrix. In his estimation, students almost need to have a triple major in CS, math, and stats, with lots of biology and maybe a little chemistry thrown in, in order to contribute to this kind of research. The next best thing is cross-fertilization. His favorite places to work have been where all of the faculty lunch together, where they are able to share ideas and learn to speak each other's languages.

This remark led to another question, because it "raised the hobgoblin of multidisciplinary research": an undergraduate needs seven years of study in order to prepare for a research career -- and that is only for the best students. Average undergrads will need more, and even that might not be enough. What can we do? One idea: redesign the whole curriculum to be interdisciplinary, with problems, mathematics, computational thinking, and research methods taught and reinforced everywhere. Graduating students will not be as well-versed in any one area, but perhaps they will be better at solving problems across the boundaries of any single discipline.

This isn't just a problem for multidisciplinary science preparation. We face the same problem in computer science itself, where the software development side of our discipline requires a variety of skills that are often best learned in context. The integrated curriculum suggestion made here makes me think of the integrated apprenticeship-style curriculum that ChiliPLoP produced this year.

[A transcript of the SECANT 2008 workshop: Table of Contents]

To open the workshop, the SECANT faculty at Purdue described an experimental course they taught last spring, Introduction to Computational Thinking. It was designed by a multi-disciplinary team from physics, chemistry, biology, and computer science for students from across the sciences.

The first thing that jumped out to me from this talk was that the faculty first designed the projects that they wanted students to do, and then figured out what students would need to know in order to do the projects. This is not a new idea (few ideas are), but while many people talk about doing this, I don't see as many actually doing it. It's always interesting to see how the idea works in practice. Owen Astrachan would be proud.

The second was the focus on visualization of results as essential to science and as a powerful attractor for students. It is not yet lunch time on Day 1, but I have heard enough already to say that visualization will be a key theme of the workshop. That's not too surprising, because visualization was also a recurring theme in last year's workshop. Again, though, I am glad to be reminded of just how important this issue is outside the walls of the Computer Science building. It should affect how we prepare students for careers applying CS in the world.

The four projects in the Purdue course's first offering were:

• manipulating digital audio -- Data representation is a jump for many students.
• percolation in grids -- Recursion is very hard, even for very bright students. Immediate feedback, including visualization, is helpful.
• Monte Carlo simulation of a physical system
• protein-protein interaction -- Graph abstractions are also challenging for many students.

This looks like a broad set of problems, the sort of interdisciplinary science that the core natural sciences share and which we computer scientists often miss out on. For CS students to take this course, they will need to know a little about the several sciences. That would be good for them, too.

Teaching CS principles to non-CS students required the CS faculty to take an approach unlike what they are used to. They took advantage of Python's strengths as a high-level, dynamic scripting language to use powerful primitives, plentiful libraries, and existing tools for visualizing results. (They also had to deal with its weaknesses, not the least of which for them was the delayed feedback about program correctness that students encounter in a dynamically-typed language.) They delayed teaching the sort of software engineering principles that we CS guys love to teach early. Instead, they tried to introduce abstractions only on a need-to-know basis.

Each project raised particular issues that allowed the students to engage with principles of computing. Audio manipulation exposed the idea of binary representation, and percolation introduced recursion, which exposed the notion of the call stack. Other times, the mechanics of writing and running programs exposed underlying computing issues. For example, when a program ran slower than students expected on the basis of previous programs, they got to learn about the difference in performance between primitive operations and user-defined functions.

The panelists reported lessons from their first experience that will inform their offering next spring:

• The problem-driven format was a big win.
• Having students write meaningful programs early was a big win.
• Having students see the results of their programs early via visualization was a big win.
• Python worked well in these regards.
• The science students' interest in computing is bimodal. Computing either has a strong appeal to them almost immediately, or the student exhibits strong resistance to computing as a tool.
• On the political front, interaction with science faculty is essential to succeeding. They have to buy in to this sort of course, as do administrators who direct resources.

One of the open questions they are considering is, do they need or want to offer different sections of this course for different majors? This is a question many of us are facing. Having a more homogeneous student base would allow the use of different kinds of problem and more disciplinary depth. But narrowing the problem set would lose the insight available across disciplines. At a school like mine, we also risk spreading the student base so thin that we are unable to offer the courses at all.

Somewhere in this talk, speaker Susanne Hambrusch, the workshop organizer and leader, said something that made me think about what in my mind is the key to bringing computation to the other disciplines most naturally: We need to leave students thinking, "This helps me answer questions in my discipline -- better, or faster, or ...". This echoed something that Ruth Chabay said at the end of last year's workshop. Students who see the value of computation and can use computation effectively will use computation to solve their own problems. That should be one of the primary goals of any course in computing we teach for students outside of CS.

This set of entries records my experiences at the 2008 SECANT 2008 workshop October 30-31, hosted by the Department of Computer Science at Purdue University.

Primary entries:

• Workshop 1: A Course in Computational Thinking
  -- SECANT a year later
• Workshop 2: Computational Thinking in the Health Sciences
  -- big data is changing the research method of science
• Workshop 3: Computational Thinking in Physics
  -- bringing computation to the undergrad physics curriculum
• Workshop 4: Computer Scientists on CS Education Issues
  -- bringing science awareness to computer science departments
• Workshop 5: Curriculum Development
  -- some miscellaneous projects in the trenches
• Workshop 6: The Next Generation of Scientists in the Workforce
  -- computational thinking as competitive advantage

Ancillary entries:

• This and That
  -- the inevitable miscellaneous thoughts
• No One Programs Any More
  -- a timely conversation the week before the workshop

On my drive to Purdue today, I listened to the first 3/4 of Caleb Carr's novel, "Killing Time". This is not a genre I read or listen to often, so it's hard for me to gauge the book's quality. If you are inclined, you can read reviews on-line. At this point, I would say that it is not a very good book, but it delivered fine escapism for a car ride on a day when I needed a break more than deep thought. But it did get me to thinking about... computer science. The vignette that sets up the novel's plot is based on a typical use case for Photoshop, or a homework assignment in a media computation CS1 course.

Carr describes a world controlled by "information barons", a term intended to raise the specter of the 19th century's rail barons and their control of wealth and commerce. The central feature of his world in 2023 is deception -- the manipulation of information, whether digital or physical, to control what people think and feel. The novel's opening involves the role a doctored video plays in a presidential assassination, and later episodes include doctored photos, characters manufactured via the data planted on the internet, the encryption of data on disk, and real-time surveillance of encrypted communication.

If students are at all interested in this kind of story, whether for the science fiction, the intrigue, or the social implications of digital media and their malleability, then we have a great way to engage them in computing that matters. It's CSI for the computer age.

Carr seems to have an agenda on the social issues, and as is often the case, such an agenda interferes with the development of the story. His characters are largely cut-outs in service of the message. Carr paints a dystopian view striking for its unremitting focus on the negatives of digital media and the science's increasing understanding of the world at a molecular level. The book seems unaware that biology and chemistry are helping us to understand diseases, create new drugs, and design new therapies, or that computation and digital information create new possibilities in every discipline and part of life. Perhaps it is more accurate to say that Carr starts with these promises as his backdrop and chooses to paint a world in which everything that could go wrong has. That makes for an interesting story but ultimately an unsatisfying thought experiment. For escapism, that may be okay.

After my previous entry, I couldn't help but wonder whether I would have the patience to read this book. I have to think not. How many pages? 274 pages -- almost slender compared to Perec's book. Still, I'm glad I'm listening and not reading.

There are two big 40th anniversary events coming up for those of us in computer science. On November 5, the Computer History Museum is hosting the 40th Anniversary of the Dynabook, with Alan Kay, Charles Thacker, and Mary Lou Jepsen. Then on December 9, Stanford is hosting Engelbart and the Dawn of Interactive Computing: SRI's Revolutionary 1968 Demo. Much of the last 40 years of technology has been an evolution toward the ideas embodied in Kay's FLEX machine and Engelbart's mouse-controlled, real time-interactive, networked computer. These ideas showed us what was possible. In addition to technological vision, Kay and Engelbart also shared a greater goal: "to use computing to augment society's collective intellect and ability to solve the complex issues of our time".

I expect that 40 is going to be a common number in computer science celebrations in the next few years.

I don't know if "reddited" is a word like "slashdotted" yet, but I can say that yesterday's post, No One Programs Any More, has reached #1 on Reddit's programming channel. This topic seems to strike a chord with a lot of people, both in the software business and in other technology pursuits. Here are my favorite comments so far:

I can't think of a single skill I've learned that has had more of an impact on my life than a semi-advanced grasp of programming.

This person received some grief for ranking learning how to program ahead of, say, learning how to eat, but I know just what the commenter means. Learning to program changes one's mind in the same way that learning to read and write. Another commenter agreed:

It's amazing how after a year of programming at university, I began to perceive the world around me differently. The way I saw things and thought about them changed significantly. It was almost as if I could feel the change.

Even at my advanced age, I love when that feeling strikes. Beginning to understand call/cc felt like that (though I don't think I fully grok it yet).

My favorite comment is a bit of advice I recommend for you all:

I will not argue with a man named Eugene.

Reddit readers really are smart!

One of my colleagues in the Math department sent me some e-mail today:

I am a constant advocate for our (math) majors receiving some sort of 'computer-programming experience' before they graduate.

Of course not all of my colleagues are as enthusiastic about this... In fact, at a recent meeting, someone stated: "No one programs anyone." This is was the basis of their argument against requiring a programming course... and it turns out that several people believe this statement.

He asked for my reaction to their stance.

This request comes as I prepare to attend the second SECANT workshop at Purdue next week. Last fall I wrote several articles about the inaugural workshop for this NSF-funded project. The NSF must think that programming and, more generally, computer science are important beyond the walls of the CS building, because it has funded projects like SECANT, the goal of which is to:

... bring together computer scientists and natural scientists who recognize that computing has become indispensable to scientific inquiry and is set to permeate science in a transformative manner.

Most of the attendees last year, and many on the roster for this year, are scientists: physicists, biologists, chemists, and astronomers. They all program in some form, because CS has redefined how they do science. Some of them are developing curriculum in their disciplines that are programming-based so that future grads are better prepared for their careers.

In the time since I joined the faculty here, many departments have dropped the computer programming requirement from their majors. Part of the reason is probably that the intro programming courses were not meeting their students' needs, and our department needs to take responsibility for that. But a big part of the reason is that many faculty across campus believe as the Math faculty do, that their students don't need to learn computer programming anymore. Not too surprisingly, I disagree.

We have started to see some movement in the other direction. The Physics department now requires an introductory programming course because so many physicists need to know how to write and modify simulation programs that serve as their experiments. One result has been a steady stream of students in our intro C course, which focuses on scientific applications. Another is an ongoing research relationship among a member of the Physics faculty, a member of the CS faculty, and undergraduates from both departments that has produced several papers (with undergrad co-authors) and occasional award recognition. None of this research is possible without physics students being able to program complex molecular system simulations.

Scientists are not the only non-CS people who need to program -- or want to. People working in finance and other areas of business program, even if only in the form of complex spreadsheets, which are constraint propagation programs. Even further afield, artists are beginning to use computational media to create art and to explore concepts of form and color in a new way.

Saying all this, I can understand how mathematicians who work at a distance from computational applications might think that programming is passe. They have little experience with code themselves, and then they read vague articles in the newspapers about off-shoring and the demise of programming. Even among computer scientists who work with scientists know "surprisingly little about how scientists develop and use software in their research", which is why some of them are conducting sponsored research to to survey scientists on how they use computers.

But surely mathematicians are aware computational work on number theory that requires a nearly global network of computers to perform massive calculations, for instance, to find large prime numbers. One might dismiss such work as "merely" applications, not real math, but these applications are testing mathematical theorems about numbers in ways we could only have dreamed of in past times.

Math profs at mid-sized universities are not the only ones with the impression that programming is disappearing or less important than it used to be. Mark Guzdial recently wrote that some think programming isn't essential even for computer scientists:

I was at a meeting a couple weeks ago where an anecdote was related that speaks to this concern. A high-ranking NSF official made the argument that programming is not a critical skill for computer scientists. "Google doesn't want smart programmers! They want smart people!" A Google executive was in the audience and responded, "No, we want people who program."

I'm glad that Google knows better what Google needs than this particular high-ranking NSF official, and I realize that said official may only have meant that the smart people Google hires can become good programmers. But I do think that this story indicates the breadth of the misunderstanding people have about the role programming plays in the world today.

Perhaps the math profs here who said that "no one programs any more" were speaking only of math graduates from this university. But even that very limited claim is false. I suggested to my friend that they should probably survey their own alumni. I know several of them who program for a living. And some of them came back after graduation to learn how.

Last time I mentioned a Supreme Court justice's thoughts on how universal access to legal case data changes the research task associated with the practice of the law. Justice Roberts's comments brought to mind two thoughts, one related to the law and one not.

As a graduate student, I worked on the representation and manipulation of legal arguments. This required me to spend some time reading legal journals for two different purposes. First, I needed to review the literature on applying computers to legal tasks, ad in particular how to represent knowledge of statute and cases. Second, I needed to find, read, and code cases for the knowledge base of my program. I'm not that old, but I'm old enough that my research preceded the Internet Age's access to legal cases. I went to the campus library to check out thick volumes of the Harvard Law Review and other legal collections and journals. These books became my companions for several months, as I lay on the floor of my study and pored over them.

When I could not find a resource I needed on campus, I rode my bike to the Michigan State Law Library in downtown Lansing to use law reviews in its collection. I was not allowed to take these home, so I worked through them one at a time in carols there. I was quite an anomalous sight there, in T-shirt and shorts with a bike helmet at my side!

I loved that time, reading and learning. I never considered studying the law as a profession, but this work was a wonderful education in a fascinating domain where computing can be applied. My enjoyment of the reading almost certainly extending my research time in grad school by a couple of months.

The second thought was of the changes in chess brought about by the application of simple database technology. I've written about chess before, but not about computing applications to it. Of course, the remarkable advances in chess-playing computers that came to a head in Hitech and Deep Thought have now reached the desktop in the form of cheap and amazingly strong programs. This has affected chess in so many ways, from eliminating the possibility of adjournments in most tournaments to providing super-strong partners for every player who wants to play, day or night. The Internet does the same, though now we are never sure if we are playing against a person or a person sitting next to a PC running Fritz.

But my thoughts turned to the same effect Justice Roberts talked about, the changes created by opening databases on how players learn, study, and stay abreast of opening theory. If you have never played tournament chess, you may not be aware of how much knowledge of chess openings has been recorded. Go to a big-box bookstore like Amazon or Barnes and Noble or Borders and browse the library of chess titles. (You can do that on-line now, of course!) You will see encyclopedias of openings like, well, the Encyclopedia of Chess Openings; books on classes of openings, such as systems for defending against king pawn openings; and books upon books about individual openings, from the most popular Ruy Lopez and Sicilian Defense to niche openings like my favorites, Petroff's Defense and the Center Game.

In the olden days of the 1980s, players bought books on their objects of study and pored over them with the same vigor as legal theorists studying law review articles. We hunted down games featuring our openings so that we could play through them to see if there was a novelty worth learning or if someone had finally solved an open problem in a popular variation. I still have a binder full of games with Petroff's Defense, cataloged using my own system, variation by variation with notes by famous players and my own humble notes from unusual games. My goal was to know this opening so well that I could always get a comfortable game out of the opening, against even stronger players, and to occasionally get a winning position early against a player not as well versed in the Petroff as I.

Talk about a misspent youth.

Chessplayers these days have the same dream, but they rarely spend hours with their heads buried inside opening books. These days, it is possible to subscribe to a database service that puts at our fingertips, via a computer keyboard, every game played with any opening -- anywhere in the recorded chess world, as recently as the latest update a week ago. What is the study of chess openings like now? I don't know, having grown up in the older era and not having kept up with chess study in many years. Perhaps Justice Roberts feels a little like this these days. Clerks do a lot of his research, and when he needs to do his own sleuthing, those old law reviews feel warm and inviting.

I do know this. Opening databases have so changed chess practice, from grandmasters down to patzers like me, that the latest issue of Chess Life, the magazine of U.S. Chess, includes a review of the most recent revision of Modern Chess Openings -- the opening bible on which most players in the West once relied as the foundation of broad study -- whose primary premise is this: What role does MCO play in a world where computer database is king? What is the use of this venerable text?

From our gamerooms to our courtrooms, applications of even the most straightforward computing technology have changed the world. And we haven't even begun to talk about programs.

The Chief Justice of the U.S. Supreme Court, John Roberts, spoke last week at Drake University, which merited an article in our local paper. Robert spoke on the history of technology in the law, and in particular on how the internet is changing in fundamental ways how the law is practiced. He likened the change to that created by the printing press, an analogy I use whenever I speak with parents and prospective CS majors.

The detective work that was important and rewarding when I was starting out is now almost ... irrelevant.

I wonder if this will have an effect on the kind of students who undertake study of the law, or the kind of lawyers who succeed in the profession. I don't imagine that it will affect the attractiveness of the law for a while, because I doubt that a desire to spend countless hours poring through legal journals is the primary motivator for most law students. Prestige and money are certainly more prominent, as is a desire to "make a difference". But who performs best way well change, as the circumstances under which lawyers work change. This sort of transformation is almost unavoidable when a new medium redefines even part of a discipline.

Roberts is perhaps concerned about this part of the change himself. Technology makes information more accessible, which means skill in finding it is no longer as valuable. How about skill at manipulating it? Being able to find information more readily can liberate practitioners, but only if they know what to do with it.

There's a lot of value in thinking outside the box. But the key word is "thinking". ... You cannot think effectively outside the box if you don't know where the box is.

I love that sentence! It's a nice complement to a phrase of Twyla Tharp's that I wrote about over three years ago: Before you can think out of the box, you have to start with a box. Tharp and Roberts are speaking of different boxes, and both are so right about both boxes.

I received an interesting request in e-mail today. I was asked to identify a few...

software innovators--people who have challenged, disrupted, and redefined disciplines through radical code.

The request is specifically for programmers, thinkers, and writers who revolutionized my field, computer science. The first people who come to mind, of course, are John McCarthy and Alan Kay. McCarthy may not himself have written code for the first Lisp interpreter back in 1958, but this page certainly revolutionized computing. I know that Kay didn't write all of Smalltalk, even at the beginning (Dan Ingalls is responsible for most or all of the VM), but the ideas in Smalltalk certainly changed how I and many other people think about programming. So they are at the top of my list.

Why limit my response to the products of my timy brain? I am interested in hearing whom you think changed computing with "radical code". Don't limit yourself to CS, either. I'd love to hear about people who changed other disciplines with their code. Drop me a message with your ideas!

Another entry generated from a thread on a mailing list...

A recent thread on the SIGCSE list began as a discussion of how programming language constructs are abstractions of the underlying hardware, and what that means for how students understand the code they write. For example, this snippet of Java:

    int x = 1;
    while (x > 0)
        x++;

does not result in an infinite, because Java ints are not integers.

This is one of many examples that remind us how important it is to study computer organization and architecture, and more generally to learn that abstractions are never 100% faithful to the details they hide. If they were, they would not be abstractions! A few good abstractions make all the difference in how we work, but -- much like metaphor -- we have to pay attention to what happens at their edges.

Eventually, the thread devolved toward a standard old discussion on this list, "What is Computer Science?" I conjecture that every mailing list, news group, and bulletin board has a topic that is its "fixed point", the topic toward which every conversation ultimately leads if left to proceed long enough, unfettered by an external force. Just about every Usenet newsgroup in which I participated during the late 1980s and early 1990s had one, and the SIGCSE list does, too. It is, "What is Computer Science?"

This question matters deeply to many people, who believe that graduates of CS programs have a particular role to play in the world. Some think that the primary job of undergraduate CS programs is to produce software engineers. If CS is really engineering (or at least should be thought of that way for practical reasons), then the courses we teach and the curricula we design should have specific outcomes, teach specific content, and imbue in students the mindset and methodology of an engineer. If CS is some sort of liberal art, then our courses and curricula will look quite different.

Much of this new thread was unremarkable if only because it all sounded so familiar to me. One group of people argued that CS is engineering, and another argued that it was more than engineering, perhaps even a science. I must have been in an ornery mood, because one poster's assertion provoked me to jump into the fray with a few remarks. He claimed that CS was not a science, because it is not a "natural science", and that it is not a natural science because the object of its study is not a natural phenomenon:

I don't believe that I have ever seen a general purpose, stored-program computing device that occurs in nature... unless we want to claim that humans are examples of such devices.

This seems like such a misguided view of computer science, but many people hold it. I'm not surprised that non-computer scientists believe this, but I am still surprised to learn that someone in our discipline does, too. Different people have different backgrounds and experiences, and I guess those differences can lead people to widely diverging viewpoints.

Computer science does not study the digital computer. Dijkstra told us so a long time ago, and if we didn't believe him then, we should now, with the advent of ideas such as quantum computing and biological computing.

Computer science is about processes that transform information. I see many naturally-occurring processes in the world. It appears now that life is the result of an information process, implement in the form of DNA. Chemical processes involve information as well as matter. And some physicists now believe that the universe as we experience it is a projection of two-dimensional information embodied in the interaction of matter and energy.

When we speak of these disciplines, we are saying more than that computer scientists use their tool -- a general-purpose computation machine -- to help biologists, chemists, and physicists do science in their areas. We are talking about a more general view of processes and information, how they behave in theory and under resource constraints. Certainly, computer scientists use their tools to help practitioners of other disciplines do their jobs differently. But perhaps more important, computer scientists seek to unify our understanding of processes and information across the many disciplines in which they occur, in a way that sheds light on how information processing works in each discipline. We are still at the advent of the cycle feeding back what we learn from computing into the other disciplines, but many believe that this is where the greatest value of computer science ultimately lies. This means that computer science is wonderful not only because we help others by giving them tools but also because we are studying something important in its own right.

If we broaden our definition of "naturally occurring" to include social phenomena in large. complex systems that were not designed by anyone in particular, then the social sciences give rise to a whole new class of information processes. Economic markets, political systems, and influence networks all manifest processes that manipulate and communicate information. How do these processes work? Are they bound by the same laws as physical information processing? These are insanely interesting questions, whose answers will help us to understand the world we live in so much better than we do now. Again, study of these processes from the perspective of computer science is only just beginning, but we have to start somewhere. Fortunately, some scientists are taking the first steps.

I believe everything I've said here today, but that doesn't mean that I believe that CS is only science. Much of what we do in CS is engineering: of hardware systems, of software systems, of larger systems in which the manipulation of information is but one component. Much of what we do is mathematics: finding patterns, constructing abstractions, and following the implications of our constructions within a formal system. That doesn't mean computer science is not also science. Some people think we use the scientific method only as a tool to study engineered artifacts, but I think that they are missing the big picture of what CS is.

The fact that people within our discipline still grapple with this sense of uncertainty about its fundamental nature does not disconcert me. We are a young discipline and unlike any of the disciplines that came before (which are themselves human constructs in trying to classify knowledge of the world). We do not need to hide from this unique character, but should embrace it. As Peter Denning has written over the years Is computer science science? Engineering? Mathematics? The answer need not be one of the above. From different perspectives, it can be all three.

Of course, we are left with the question of what it is like for a discipline to comprise all three. Denning's Rebooting Computing summit will bring together people who have been thinking about this conundrum in an effort to make progress, or chart a course. On the CS education front, we need to think deeply about the implications of CS's split personality for the design of our curricula. Owen Astrachan is working on innovating the image of CS in the university by turning our view outward again to the role of computer science in understanding a world bigger than the insides of our computers or compilers. Both of these projects are funded by the NSF, which seems to appreciate the possibilities.

I can't think about the relationship between computer science and natural science with thinking of Herb Simon's seminal Sciences of the Artificial. I don't know whether reading it would change enough minds, but it affected deeply how I think about complex systems, intentionality, and science.

My semester has started with a busy bang, complicated beyond usual by a colleague's family emergency, which has me teaching an extra course until he returns. The good news is that my own course is programming languages, so I am getting to think about fun stuff at least a couple of days a week.

Teaching Scheme to a typical mix of eager, indifferent, and skeptical students brought to mind a blog entry I read recently on Fluent Builders in Java. This really is a neat little design pattern for Java or C++ -- a way to make those code written in these languages look and feel so much better to the reader. But looking at the simple example:

Car car = Car.builder()
   .year(2007)
   .make("Toyota")
   .model("Camry")
   .color("blue")
   .build();

... can't help me think about the old snark that we are reinventing Smalltalk and Lisp one feature at a time. A language extension here, a design pattern there, and pretty soon you have the language people want to use. Once again, I am turning into an old curmudgeon before my time.

As the author points out in a comment, Ruby gives us an more convenient way to fake named parameters: passing a hash of name/value pairs to the constructor. This is a much cleaner hack for programmers, because we don't have to do anything special; hashes are primitives. From the perspective of teaching Programming Languages this semester, what like most about the Ruby example is that it implements the named parameters in data, not code. The duality of data and program is one of those Big Ideas that all CS students should grok before they leave us, and now I have a way to talk about the trade-off using Java, Scheme, and an idiomatic construction in Ruby, a language gaining steam in industry.

Of course, we know that Scheme programmers don't need patterns... This topic came up in a recent thread on the PLT Scheme mailing list. Actually, the Scheme guys gave a reasonably balanced answer, in the context of a question that implied an unnecessary insertion of pattern-talk into Scheme programming. How would a Scheme programmer solve the problem that gives rise to fluent builders? Likely, write a macro: extend the language with new syntax that permits named parameters. This is the "pattern as language construct" mentality that extensible syntax allows. (But this leaves other questions unanswered, including: When is it worth the effort to use named parameters in this way? What trade-offs do we face among various ways to implement the macro?)

Finally, thinking ahead to next semester's compilers class, I can't help but think of ways to use this example to illustrate ideas we'll discuss there. A compiler can look for opportunities to optimize the cascaded message send shown above into a single function call. A code generator could produce a fluent builder for any given class. The latter would allow a programmer to use a fluent builder without the tedium of writing boilerplate code, and the former would produce efficient run-time code while allowing the programmer to write code in a clear and convenient way. See a problem; fix it. Sometimes that means creating a new tool.

Sometimes I wonder whether it is worth blogging ideas as simple as these. What's the value? I have a new piece of evidence in favor. Back in May 2007, I wrote several entries about a paper on the psychology of security. It was so salient to me for a while that I ended up suggesting to a colleague that he might use the paper in his capstone course. Sixteen months later, it is the very same colleague's capstone course that I find myself covering temporarily, and it just so happens that this week the students are discussing... Schneier's paper. Re-reading my own blog entries has proven invaluable in reconnecting with the ideas that were fresh back then. (But did I re-read Schneier's paper?)

The Parade magazine insert to my Sunday paper contained an interview with legendary bluesman B.B. King that included this snippet:

There's never a day goes by that I don't miss having graduated and gone to college. If I went now, I would major in computers and minor in music. I have a laptop with me all the time, so it's my tutor and my buddy.

CS and music are, of course, a great combination. Over the years, I've had a number of strong and interesting students whose backgrounds included heavy doses of music, from alt rock to marching band to classical. But B.B. King is from a different universe. Maybe I can get this quote plastered on the walls of all the local haunts for musicians.

I wonder what B.B. calls his laptop?

I'm not a physicist and don't keep up on the latest -- or even much of the not-so-latest -- in string theory. But recently a colleague pointed me toward Leonard Susskind's 2008 book, The Black Hole War. Before tracking down the book, I read a review from the Los Angeles Times. The review introduced me to Susskind's "holographic principle", which holds that

... our universe is a three-dimensional projection of information stored in two dimensions at the boundary of space ...

Suddenly, data and algorithm visualizations seem so much more important than just ways to make pretty graphs. When we tell the world that computation is everywhere, we may be more right than I ever realized. Add in the principle of the conservation of information that lies at the center of the dispute between Susskind's work and Hawking's, and "computing for everyone" takes on a whole new meaning.

Note to self: read this book.

I taught my first session of Programming Languages today, so the semester is officially underway. Right now, my mind is a swirl of Scheme, closures, continuations, MapReduce, and lazy evaluation. I've been teaching this course for a dozen years based on functional programming (a style new to our students at this point) and writing interpreters in Scheme. This makes me very comfortable with the material. Over the years I have watched ideas work their way from the niche of PL courses into mainstream languages. The resurgence of scripting languages has been both a result of this change and a trigger. The discussion of true closures in languages such as Ruby and Java is one example.

This evolution is fun to watch, even if it moves haltingly and perhaps slower than I'd prefer. In order to keep my course current, I need to incorporate some of these changes into my course. This time around, I find myself thinking about what ideas beyond the "edge" of practical languages I should highlight in my course. I'd like for my students to learn about some of the coolest ideas that will be appearing in their professional practice in the near future. For some reason, lazy evaluation seems ripe for deeper consideration. Working it into my class more significantly will be a project for me this semester.

Delving headlong into a new semester's teaching makes Jorge Cham's recent cartoon seem all the more true:

For faculty at a "teaching university", the numbers are often skewed even further. Of course, I am an administrator now, so I teach but one course a semester, not three. Yet the feeling is the same, and the desire to spend more time on real CS -- teaching and research -- is just as strong. Maybe I can add a few hours to each day?

Today I'm listening to the August 21 episode of The Bob and Tom Show, a syndicated morning radio show. One of the guests on this episode is comedian Dwayne Perkins. There I was working on my previous entry when I hear Perkins say "I was a computer science student in college...". Surprise! Of course, the reference was part of a skit on his dating life and ended up mentioning a preponderance of Asian-American males in his classes, but still.

I don't know if CS plays any role in his comedy more generally, but he at least is tech-savvy enough to have a blog with both discursive entries and short videos.

I'm guessing that it's a good thing to have a performer say "computer science" every so often as part of his work. Whatever he says about CS, people aren't likely to remember much of the content, but they might remember hearing the words "computer science". Something that puts our discipline in the mainstream may well help demythologize it.

Coincidentally, I heard this episode on a day when we did final registration for fall courses, and every introductory programming course we offer is full. This includes our intro course for majors, which is a good 50% larger than last year, and non-majors courses in VB and C++. Perhaps the tide has turned. Or perhaps some of the efforts we have mad in the last three years are beginning to pay off.

Recently, someone sent me a link to Clifford Stoll's TED talk from February 2006, and yesterday I finally watched. Actually, I listened more than I watched, for two reasons. First, because I was multitasking in several other windows, as I always am at the machine. Second, because Stoll's manic style jumping around the stage isn't much to my liking.

As a university professor and a parent, I enjoyed the talk for its message about science and education. It's worth listening to simply for the epigram he gives in the first minute or so, about science, engineering, and technology, and for the quote he recites to close the talk. (Academic buildings have some of the coolest quotes engraved right on their walls.) But the real meat of the talk, which doesn't start until midway through, is the point.

Prodded by schoolteachers to whom he was talking about science in the schools, Stoll decided that he should put his money where his mouth is: he became a science teacher. Not just giving a guest lecture at a high school, but teaching a real junior-high science class four days a week. He doesn't do the "turn to Chapter 7 and do all the odd problems" kind of teaching either, but real physics. For example, his students measure the speed of light. They may be off by 25%, but they measured the speed of light, using experiments they helped design and real tools. This isn't the baking soda volcano, folks. Good stuff. And I'll bet that junior-high kids love his style; he's much better suited for that audience than I!

One remark irked me, even if he didn't mean it the way I heard it. At about 1:38, he makes a short little riff on his belief that computers don't belong in schools. "No! Keep them out of schools", he says.

In one sense, he is right. Educators, school administrators, and school boards have made "integrating technology" so big a deal that computers are put into classrooms for their own sake. They become devices for delivering lame games and ineffective simulations. We teach Apple Keynote, and students think they have learned "computers" -- and so do most teachers and parents. When we consider what "computers in schools" means to most people, we probably should keep kids away from them, or at least cut back their use.

At first, I thought I was irked at Stoll for saying this, but now I realize that I should be irked at my profession for not having done a better job both educating everyone about what computers really mean for education and producing the tools that capitalize on this opportunity.

Once again I am shamed by Alan Kay's vision. The teachers working with Alan also have their students do real experiments, too, such as measuring the speed of gravity. Then they use computers to build executable models that help students to formalize the mathematics for describing the phenomenon. Programming is one of their tools.

Imagine saying that we should keep pencils and paper out of our schools, returning to the days of chalk slates. People would laugh, scoff, and revolt. Saying we should keep computers out of schools should elicit the same kind of response. And not because kids wouldn't have access to e-mail, the web, and GarageBand.

I've written here a lot in the last year or so about ideas in the vein of "programming for everyone", so I feel I should point you toward Calculemus!, Brian Hayes's latest column in The American Scientist. This short paper is something of a hodgepodge in celebration of the 25th anniversary of Hayes writing monthly articles on the joys of computation.

First, he talks about the history of his columns, which explore the realm of inquisitive computing -- writing programs as a way to explore ideas that interest him and his readers. This isn't software development, with "requirements" and "process" and "lifecycle management". This is asking a cool question (say, "Is there any pattern in the sequence of numbers that are perfect medians?) and writing some code in search of answers, and more questions. This is exactly the way in which I conceive of programming as an essential intellectual skill of the future to be. I don't imagine that most people will ask themselves such mathematical questions (though they might), but they might be inquisitive at work or at home in their own areas of interest.

They may be sitting on a plane talking with a fellow passenger and have a question about football overtimes. I lived that story once many years ago, talking about sudden-death overtime in the NFL. My seatmate was a pilot who liked to follow football, and after we discussed some of the days scores he asked out loud, "I wonder how frequently the team that wins the coin toss wins the game?" He figured that was the end of the question, because how could we answer it? I whipped out my laptop, fired up Dr. Scheme, and built a little model. We experimented with several parameters, including a percentage we had read for how often the first team scores on its opening drive, until we had a good sense of how much of an advantage winning the coin toss is. He was amazed that we could do what we did. I could only say, it would be great if more people knew this was possible, and learned the little bit of programming they need to do it. I'm not sure he believed that.

Hayes then gives three examples of the kinds of problem he likes to explore and how programs can help. I'm tempted to elaborate on his examples, but that would make this post as long as the paper. Just read it. I can say that all three were fun for me to play with, and two of them admit almost trivial implementations for getting started in the search for answers. (I was surprised to learn that what he calls abc-hits has implications for number theory.)

Finally, Hayes closes with a discussion of what sort of programming environments and languages we need to support inquisitive programming by the masses. He laments the passing of Dartmouth BASIC into the bowels of structured programming, object-oriented programming, and, dare I add, VB.NET -- from a language for everyone to a language for a small group of professionals writing serious programs in a serious setting. (He also laments that "GUI-coddled computer users have forgotten how to install an executable in usr/local/bin and add it to their $PATH", so he's not completely consistent in aiming at the computing non-professional!)

He hopes to be language-agnostic, though he confesses to being a Lisp weenie and suggests that Python may be the language best positioned to fill the needs of inquisitive programmers, with its avid user community in the sciences. He is probably right, as I have noted Python's ascendancy in CS ed and the physics community before. Most encounters I have with Python leave me thinking "Boy, I like Ruby", so I would love to see the Ruby grow into this area, too. For that to happen, we need more books like this one to introduce real people to Ruby in their own contexts. I'm looking forward to seeing an exam copy of this title to see whether it or one like it can be useful among students and professionals working in the life sciences.

I've long enjoyed Hayes's column and still follow it on-line after having dropped my subscription to The American Scientist a few years ago. (It's a fine publication, but I have only so many hours in my day to read!) You can find many of his articles on-line now at bit-player. If you can make time to explore a bit, I encourage you to look there...

[A transcript of the SIGCSE 2008 conference: Table of Contents]

(Okay, so I am over four months behind posting my last couple of entries from SIGCSE. Two things I've read in the last week or so jolted my memory about one of these items. I'll risk that they are longer of much interest and try to finish off my SIGCSE reports before classes start.)

A Discipline, Not Just a Job

During his talk, I think, Owen Astrachan said:

Don't talk about where the jobs are. We do not need to kowtow to the market. CS is ideas, a discipline.

We do, of course, need to keep in mind that the first motivation for many of our students is to get a job. But Owen is right. To the extent that we "sell" anything, let's sell that CS is a beautiful and powerful set of ideas. We can broaden the minds of our job-seeking students -- and also attract thinking students who are looking for powerful ideas.

When Good Students Are Too Good

Rich Pattis tossed out an apparently old saw I had never heard: Don't give your spec to the best programmer in the room. She will make it work, even if the spec isn't what you want and doesn't make sense. Give it to a mediocre programmer. If the spec is bad, he will fail and come back with questions.

This applies to homework assignments, too. Good students can make anything work, and most will. That good students solved your problem is not evidence of a well-written spec.

Context Complicates

I've talked a lot here about giving students problems in context, whether in the context of large projects or in the context of "real" problems. As I was listening to Marissa Mayer's talk and lunchtable conversation, I was reminded that context complicates matters, for both teacher and students. We have to be careful when designing instruction to be sure that students are able to attend to what we want them to learn, and not be constantly distracted by details in the backstory. Otherwise, a task being in context hurts more than it helps.

The solution: Start with problems in context, then simplify to a model that captures the essence of the context and eliminates unnecessary complexity and distraction. Joe Bergin has probably already written a pedagogical pattern for this, but I don't see it after a quick glance at some of his papers. I've heard teachers like Owen, Nick Parlante, and Julie Zelensky talk about this problem in a variety of settings, and they have some neat approaches to solving it.

Overshooting Your Mark in the Classroom

It is easy for teachers to dream bigger than they can deliver when they lose touch with the reality of teaching a course. I see this all the time when people talk about first-year CS courses -- including myself. In my piece on the Nifty Assignments session, I expressed disappointment that one of the assignments had a write-up of four pages and suggested that I might be able to get away with giving students only the motivating story and a five-line assignment statement. Right. It is more likely that the assignment's creator knows what he is doing from the experience of actually using the assignment in class. From the easy chairs of the Oregon Convention Center, everything looks easier. (I call this the Jeopardy! Effect.)

The risk of overshooting is even bigger when the instructor has not been in the trenches, ever or even for a long while. Mark Guzdial recently told the story of Richard Feynman's freshman physics course, which is a classic example of this phenomenon. Feynman wrote a great set of lectures, but they don't really work as a freshman text, except perhaps with the most elite students.

I recently ran across a link to a new CS1 textbook for C++ straight from Bjarne Stroustrup himself. Stroustrup has moved from industry to academia and has had the opportunity to develop a new course for freshmen. "We need to improve the education of our software developers," he says. When one of my more acerbic colleagues saw this, he response was sharp and fast: "Gee, that quick! Seems those of us in 'academia' don't catch on as well as the newbies."

For all I know, Stroustrup's text will be just what every school that wants to teach C++ in CS1 needs, but I am also skeptical. A lot of smart guys with extensive teaching experience -- several of them my friends -- have been working on this problem for a long time, and it's hard. I look forward to seeing a copy of the book and to hearing how it works for the early adopters.

Joe, is there a pedagogical pattern called "In the Trenches"? If not, there should be. Let's write it.

Yesterday, I wrote a bit about scripting languages. It seems odd to have to talk about the value of scripting languages in 2008, as Ronald Loui does in his recent IEEE Computer article, but despite their omnipresence in industry, the academic world largely continues to prefer traditional systems languages. Some of us would like to see this change. First, let's consider the case of novice programmers.

Most scripting languages lack some of the features of systems languages that are considered important for learners, such as static typing. Yet these "safer" languages also get in the way of learning, as Loui writes, by imposing "enterprise-sized correctness" on the beginner.

Early programmers must learn to be creative and inventive, and they need programming tools that support exploration rather than production.

This kind of claim has been made for years by advocates of languages such as Scheme for CS1, but those languages were always dismissed by "practical" academics as toy languages or niche languages. Those people can't dismiss scripting languages so easily. You can call Python and Perl toy languages, but they are used widely in industry for significant tasks. The new ploy of these skeptics is to speak of the "scripting language du jour" and to dismiss them as fads that will disappear while real languages (read: C) remain.

What scripting language would be the best vehicle for CS1? Python has had the buzz in the CS ed community for a while. After having taught a little PHP las semester, I would deem it too haphazard for CS1. Sure, students should be able to do powerful things, but the pocket-protected academic in me prefers a language that at least pretends to embody good design principles, and the pragmatist in me prefers a language that offers a smoother transition into languages beyond scripting. JavaScript is an idea I've seen proposed more frequently of late, and it is a choice with some surprising positives. I don't have enough experience with it to say much, but I am a little concerned about the model that programming in a browser creates for beginning students.

Python and Ruby do seem like the best choices among the scripting languages with the widest and deepest reach. As Loui notes, few people dislike either, and most people respect both, to some level. Both have been designed carefully enough to be learned by beginners and and support a reasonable transition as students move to the next level of the curriculum. Having used both, I prefer Ruby, not only for its OO-ness but also for how free I feel when coding in it. But I certainly respect the attraction many people have to Python, especially for its better developed graphics support.

Some faculty ask whether scripting languages scale to enterprise-level software. My first reaction is: For teaching CS1, why should we care? Really? Students don't write enterprise-level software in CS1; they learn to program. Enabling creativity and supporting exploration are more important than the speed of the interpreter. If students are motivated, they will write code -- a lot of it. Practice makes perfect, not optimized loop unrolling and type hygiene.

My second reaction is that these languages scale quite nicely to real problems in industry. That is why they have been adopted so widely. If you need to process a large web access log, you really don't want to use Java, C, or Ada. You want Perl, Python, or Ruby. This level of scale gives us access to real problems in CS1, and for these tasks scripting languages do more than well enough. Add to that their simplicity and the ability to do a lot with a little code, and student learning is enhanced.

Loui writes, "Indeed, scripting languages are not the answer for long-lasting, CPU-intensive nested loops." But then, Java and C++ and Ada aren't the answer for all the code we write, either. Many of the daily tasks that programmers perform lie in the space better covered by scripting languages. After learning a simpler language that is useful for these daily tasks, students can move on to larger-scale problems and learn the role of a larger-scale language in solving them. That seems more natural to me than going in the other direction.

Now let's consider the case of academic programming languages research. A lot of interesting work is being done in industry on the design and implementation of scripting language, but Loui laments that academic PL research still focus on syntactic and semantic issues of more traditional languages.

Actually, I see a lot of academic work on DSLs -- domain-specific languages -- that is of value. One problem is this research is so theoretical that it is beyond the interest of programmers in the trenches. Then again, it's beyond the mathematical ability and interest of many CS academics, too. (I recently had to comfort a tech entrepreneur friend of mine who was distraught that he couldn't understand even the titles of some PL theory papers on the resume of a programmer he was thinking of hiring. I told him that the lambda calculus does that to people!)

Loui suggest that PL language research might profitably move in a direction taken by linguistics and consider pragmatics rather than syntax and semantics. Instead of proving something more about type systems, perhaps a languages researcher might consider "the disruptive influence that Ruby on Rails might have on web programming". Studying how well "convention over configuration" works in practice might be of as much use as incrementally extending a compiler optimization technique. The effect of pragmatics research would further blur the line between programming languages and software engineering, a line we have seen crossed by some academics from the PLT Scheme community. This has turned out to be practical for PL academics who are interested in tools that support the programming process.

Loui's discussion of programming pragmatics reminds me of my time in studying knowledge-based systems. Our work was pragmatic, in the sense that we sought to model the algorithms and data organization that expert problem solvers used, which we found to be tailored to specific problem types. Other researchers working on such task-specific architectures arrived at models consistent with ours. One particular group went beyond modeling cognitive structures to the sociology of problem solving, John McDermott's lab at Carnegie Mellon. I was impressed by McDermott's focus on understanding problem solvers in an almost anthropological way, but at the time I was hopelessly in love with the algorithm and language side of things to incorporate this kind of observation into my own work. Now, I recognize it as the pragmatics side of knowledge-based systems.

(McDermott was well known in the expert systems community for his work on the pioneering programs R1 and XCON. I googled him to find out what he was up to these days but didn't find much, but through some publications, I infer that he must now be with the Center for High Assurance Computer Systems at the Naval Research Laboratory. I guess that accounts for the sparse web presence.)

Reading Loui's article was an enjoyable repast, though even he admits that much of the piece reflects old arguments from proponents of dynamic languages. It did have, I think, at least one fact off track. He asserts that Java displaced Scheme as the primary language used in CS1. If that is true, it is so only for a slender subset of more elite schools, or perhaps that Scheme made inroads during a brief interregnum between Java and ... Pascal, a traditional procedural language that was small and simple enough to mostly stay out of the way of programmers and learners.

As with so many current papers, one of the best results of reading it is a reminder of a piece of classic literature, in this case Ousterhout's 1998 essay. I usually read this paper again each time I teach programming languages, and with my next offering of that course to begin in three weeks, the timing is perfect to read it again.

Colleague and reader Michael Berman pointed me to the July 2008 issue of IEEE Computer, which includes an article on the virtues of scripting languages, Ronald Loui's In Praise of Scripting: Real Programming Pragmatism. Loui's inspiration is an even more important article in praise of scripting, John Ousterhout's classic Scripting: Higher Level Programming for the 21st Century. Both papers tell us that scripting deserves more respect in the hierarchy of programming and that scripting languages deserve more consideration in the programming language and CS education communities.

New programming languages come from many sources, but most are created to fill some niche. Sometimes the niche is theoretical, but more often the creators want to be able to do something more easily than they can with existing languages. Scripting languages in particular tend to originate in practice, to fill a niche in the trenches, and grow from there. Sometimes, they come to be used just like a so-called general-purpose programming language.

When programmers have a problem that they need solve repeatedly, they want a language that gives them tools that are "ready at hand". For these programming tasks, power comes from the level of abstraction provided by built-in tools. Usually these tools are chosen to fill the needs of a specific niche, but they almost always include the ability to process text conveniently, quickly, and succinctly.

Succinctness is a special virtue of scripting languages. Loui mentions the virtue of short source code, and I'm surprised that more people don't talk about the value of small programs. Loui suggests one advantage that I rarely see discussed: languages that allow and even encourage short programs enable programmers to get done with a task before losing motivation or concentration. I don't know how important this advantage is for professional programmers; perhaps some of my readers who work in the real world can tell me what they think. I can say, though, that, when working with university students, and especially novice programmers, motivation or concentration are huge factors. I sometimes hear colleagues say that students who can't stay motivated and concentrate long enough to solve an assignment in C++, Ada, or Java probably should not be CS majors. This seems to ignore reality, both of human psychology and of past experience with students. Not to mention the fact that teach non-majors, too.

Another advantage of succinctness Loui proposes relates to programmer error. System-level languages include features intended to help programmers make fewer errors, such as static typing, naming schemes, and verbosity. But they also require programmers to spend more time writing code and to write more code, and in that time programmers find other ways to err. This is, too, is an interesting claim if applied to professional software development. One standard answer is that software development is not "just" programming and that such errors would disappear if we simply spent more time up-front in analysis, modeling, and design. Of course, these activities add even more time and more product to the lifecycle, and create more space for error. They also put farther in the future the developers' opportunity to get feedback from customers and users, which in many domains is the best way to eliminate the most important errors that can arise when making software.

Again, my experience is that students, especially CS1 students, find ways to make mistakes, regardless of how safe their language is.

One way to minimize errors and their effects is to shrink the universe of possible errors. Smaller programs -- less code -- is one way to do that. It's harder to make as many or even the same kind of errors in a small piece of code. It's also easier to find and fix errors in a small piece of code. There are exceptions to both of these assertions, but I think that they hold in most circumstances.

Students also have to be able to understand the problem they are trying to solve and the tools they are using to solve it. This places an upper bound on the abstraction level we can allow in the languages we give our novice students and the techniques we teach them. (This has long been an argument made by people who think we should not teach OO techniques in the first year, that they are too abstract for the minds of our typical first-year students.) All other things equal, concrete is good for beginning programmers -- and for learners of all kinds. The fact that scripting languages were designed for concrete tasks means that we are often able to make the connection for students between the languages abstractions and tasks they can appreciate, such as manipulating images, sound, and text.

My biases resonate with this claim in favor of scripting languages:

Students should learn to love their own possibilities before they learn to loathe other people's restrictions.

I've always applied this sentiment to languages such as Smalltalk and Scheme which, while not generally considered scripting languages, share many of the features that make scripting languages attractive.

In this regard, Java and Ada are the poster children in my department's early courses. Students in the C++ track don't suffer from this particular failing as much because they tend not to learn C++ anyway, but a more hygienic C. These students are more likely to lose motivation and concentration while drowning in an ocean of machine details.

When we consider the problem of teaching programming to beginners, this statement by Loui stands out as well:

Students who learn to script early are empowered throughout their college years, especially in the crucial Unix and Web environments.

Non-majors who want to learn a little programming to become more productive in their disciplines of choice don't get much value at all from one semester learning Java, Ada, or C++. (The one exception might be the physics majors, who do use C/C++ later.) But even majors benefit from learning a language that they might use sooner, say, in a summer job. A language like PHP, JavaScript, or even Perl is probably the most valuable in this regard. Java is the one "enterprise" language that many of our students can use in the summer jobs they tend to find, but unfortunately one or two semesters are not enough for most of them to master enough of the language to be able to contribute much in a professional environment.

Over the years, I have come to think that even more important than usefulness for summer jobs is the usefulness a language brings to students in their daily lives, and the mindset it fosters. I want CS students to customize their environments. I want them to automate the tasks they do every day when compiling programs and managing their files. I want them to automate their software testing.

When students learns a big, verbose, picky language, they come to think of writing a program as a major production, one that may well cause more pain in the short term than it relieves in the long term. Even if that is not true, the student looks at the near-term pain and may think, "No, thanks." When students learn a scripting language, they can see that writing a program should be as easy as having a good idea -- "I don't need to keep typing these same three commands over and over", or "A program can reorganize this data file for me." -- and writing it down. A program is an idea, made manifest in an executable form. They can make our lives better. Of all people, computer scientists should be able to harness their power -- even CS students.

This post has grown to cover much more than I had originally planned, and taken more time to write. I'll stop here for now and pick up this thread of thought in my next entry.

The recent rescue of hostages in Colombia relied on a strategy familiar to people interested in computer network security: a man-in-the-middle attack.

... for months, in an operation one army officer likened to a "broken telephone," military intelligence had been able to convince Ms. Betancourt's captor, Gerardo Aguilar, a guerrilla known as "Cesar," that he was communicating with his top bosses in the guerrillas' seven-man secretariat. Army intelligence convinced top guerrilla leaders that they were talking to Cesar. In reality, both were talking to army intelligence.

As Bruce Schneier reports in Wired magazine, this strategy is well-known on the internet, both to would-be system crackers and to security experts. The risk of man-in-the-middle attacks is heightened on-line because the primary safeguard against them -- shared social context -- is so often lacking. Schneier describes some of the technical methods available for reducing the risk of such attacks, but his tone is subdued... Even when people have a protection mechanism available, as they do in SSL, they usually don't take advantage of it. Why? Using the mechanism requires work, and most of us are just too lazy.

Then again, the probability of being victimized by a man-in-the-middle attack may be small enough that many of us can rationalize that the cost is greater than the benefit. That is a convenient thought, until we are victimized!

The problem feature that makes man-in-the-middle attacks possible is unjustified trust. This is not a feature of particular technical systems, but of any social system that relies on mediated communication. One of the neat things about the Colombian hostage story it that shows that some of the problems we study in computer science are relevant in a wider context, and that some of our technical solutions can be relevant, too. A little computer science can amplify the problem solving of almost anyone who deals with "systems", whatever their components.

This story shows a potential influence from computing on the wider world. Just so that you know the relationship runs both ways, I point you to Joshua Kerievsky's announcement of "Programming with the Stars", one of the events on the Developer Jam stage at the upcoming Agile 2008 conference. Programming with the Stars adapts the successful formula of Dancing with the Stars, a hit television show, to the world of programming. On the TV show, non-dancers of renown from other popular disciplines pair with professional dancers for a weekly dance competitions. Programming with the Stars will work similarly, only with (pair) programming plugged in for dancing. Rather than competitions involving samba or tango, the competitions will be in categories such as test-driven development of new code and refactoring a code base.

As in the show, each pair will include an expert and a non-expert, and there will be a panel of three judges:

• Rachel Davies
• Uncle Bob Martin
• Crazy Mike Hill

I've already mentioned Uncle Bob in this blog, even in a humorous vein, and I envision him playing the role of Simon Cowell from "American Idol". How Davies and Hill compare to Paula Abdul and Randy Jackson, I don't know. But I expect plenty of sarcasm, gushing praise, and hip lingo from the panel, dog.

Computer scientists and software developers can draw inspiration from pop culture and have a little fun along the way. Just don't forget that the ideas we play with are real and serious. Ask those rescued hostages.

I've been trying to take a break from the office and spend some time at home and with my family. Still, I enjoy finding time to read an occasional technical article and be inspired. While waiting for my daughter's play rehearsal to end last night, I read A Conversation with Christos Papadimitriou, a short interview in the August 2008 of Dr. Dobb's Journal. I first learned of Papadimitriou from a textbook of his that we used in one of my earliest graduate course, Elements of the Theory of Computation. Since that time, he has done groundbreaking work in computational complexity and algorithms, with applications in game theory, economics, networks, and most recently bioinformatics. It seems that many of the best theoreticians have a knack for grounding their research in problems that matter.

The article includes several tidbits that might interest computer scientists and professional programmers of various sorts. Some are pretty far afield from my work. For instance, Papadimitriou and two of his students recently produced an important result related to the Nash Equilibrium in game theory (have you seen A Beautiful Mind?) Nash's theorem tells us that an equilibrium exists in every game, but it does not tell us how to find the equilibrium. Is it possible to produce a tractable algorithm for finding it? Papadimitriou and his students showed that Nash's theorem depends intrinsically on the theorem which is the basis of Nash's proof, which means that, in practice, we cannot produce such an algorithm; finding the Nash equilibrium for any given problem is intractable.

The interview spent considerable time discussing Papadimitriou's recent work related to the Internet and the Web, which are ideas I will likely read more about. Papadimitriou sees the net as an unusual opportunity for computer scientists: a chance to study a computational artifact we didn't design. Unlike our hardware and software systems, it "emerged from an interaction of millions of entities on the basis of deliberately simple protocols". The result is a "mystery" that our designed artifacts can't offer. For a theoretical CS guy, the net and web serve as a research lab of unprecedented size.

It also offers a platform for research at the intersection of computing and other disciplines, such as communication, where my CS grad student Sergei Golitsinski is taking his research. The interviewer quoted net pioneer John Gilmore in the same arena: "The Net interprets censorship as damage and routes around it." This leads to open questions about how rumors spread, an area that Papadimitriou calls "information epidemiology". One of my former grad students, Nate Labelle, worked in this area for a particular part of the designed world, open-source software packages, and I'd love to have a student delve into the epidemiology of more generalized information.

I would also like to read Papadimitriou's novel, Turing. I recall when it came out and just haven't gotten around to asking my library to pick it up or borrow it. In the interview, Papadimitriou said,

I discovered this [novel] was inside me and had to come out, so I took time to write it. I couldn't resist it. ... If I had not done it, I would be a less happy man.

Powerful testimony, and the chance to read CS-themed fiction doesn't come along every day.

After reading Lockhart, I read Matthias Felleisen's response to Lockhart, and from there I read Matthias's design for a second course to follow How to Design Programs. From an unlinked reference there, I finally found A Critique of Abelson and Sussman, also known as "Why Calculating Is Better Than Scheming" (and also available from the ACM Digital Library). I'm not sure why I'd never run into this old paper before; it appeared in a 1987 issue of the SIGPLAN Notices. In any case, I am glad I did now, because it offers some neat insights on teaching introductory programming. Some of you may recall its author, Philip Wadler, from his appearance in this blog as Lambda Man a couple of OOPSLAs ago.

In this paper, Wadler argues that Structure and Interpretation of Computer Programs, which I have lauded as one of the great CS books, could be improved as a vehicle for teaching introductory programming by using a language other than Scheme. In particular, he thinks that four particular language features are helpful, if not essential:

• pattern matching
• a more mathematics-like syntax
• types, both static and user-defined
• lazy evaluation

Read the paper for an excellent discussion of each, but I will summarize. Pattern matching pulls syntax of many decisions out of a single function and creates separate expressions for each. This is similar to writing separate functions for each case, and in some ways resembles function overloading in languages such as Java and C++. A syntax more like traditional math notation is handy when teaching students to derive expressions and to reason about values and correctness. Static typing requires code to state clearly the kinds of objects it manipulates, which eliminates a source of confusion for students. Finally, lazy evaluation allows programs to express meaningful ideas in a natural way without having the language enforce conclusions that are not strictly necessary. This can be also be useful when doing derivation and proof, but it also opens the door to some cool applications, such as infinite streams.

We teach functional programming and use some of these concepts in a junior-/senior-level programming languages course, where many of Wadler's concerns are less of an issue. (They do come into play with a few students, hough; Wadler might say we wouldn't have these problems if we taught our intro course differently!) But for freshmen, the smallest possibilities of confusion become major confusions. Wadler offers a convincing argument for his points, so much so that Felleisen, a Scheme guy throughout, has applied many of these suggestions in the TeachScheme! project. Rather than switching to a different language, the TeachScheme! team chose to simplify Scheme through a series of "teaching languages" that expose concepts and syntax just-in-time.

If you want evidence that Wadler is describing a very different way to teach introductory programming, consider this from the end of Section 4.1:

I would argue that the value of lazy evaluation outweighs the value of being able to teach assignment in the first course. Indeed, I believe there is great value in delaying the introduction of assignment until after the first course.

The assignment statement is like mom and apple pie in most university CS1 courses! The typical CS faculty could hardly conceive of an intro course without assignment. Abelson and Sussman recognized that assignment need not be introduced so early by waiting until the middle of SICP to use set. But for most computer scientists and CS faculty, postponing assignment would require a Kuhn-like paradigm shift.

Advocates of OOP in CS1 encountered this problem when they tried to do real OOP in the first course. Consider the excellent Object-Oriented Programming in Pascal: A Graphical Approach, which waiting until the middle of the first course to introduce if-statements. From the reaction of most faculty I know, you would have thought that Conner, Niguidula, and van Dam were asking people to throw away The Ten Commandments. Few universities adopted the text despite its being a wonderful and clear introduction to programming in an object-oriented style. As my last post noted, OOP causes us to think differently, and if the faculty can't make the jump in CS1 then students won't -- even if the students could.

(There is an interesting connection between the Conner, Niguidula, and van Dam approach and Wadler's ideas. The former postpones explicit decision structures in code by distributing them across objects with different behavior. The latter postpones explicit decision structures by distributing them across separate cases in the code, which look like overloaded function definitions. I wonder if CS faculty would be more open to waiting on if-statements through pattern matching than they were through the dynamic polymorphism of OOP?)

Wadler indicates early on that his suggestions do not presuppose functional programming except perhaps for lazy evaluation. Yet his suggestions are not likely to have a wide effect on CS1 in the United States any time soon, because even if they were implemented in a course using an imperative language, most schools simply don't teach CS1 in a way compatible with these ideas. Still, we would be wise to take them to heart, as Felleisen did, and use them where possible to help us make our courses better.

Most papers presented at SIGCSE and the OOPSLA Educators' Symposium are about teaching methods, not computational methods. When the papers do contain new technical content, it's usually content that isn't really new, just new to the audience or to mainstream use in the classroom. The most prominent example of the latter that comes to mind immediately is the series of papers by Zung Nguyen and Stephen Wong at SIGCSE on design patterns for data structures. Those papers were valuable in principle because they showed that how one conceives of containers changes when one is working with objects. In practice, they sometimes missed their mark because they were so complex that many teachers in the audience said, "Cool! But I can't do that in class."

However, the OOPSLA Educators' Symposium this year received a submission with a cool object-oriented implementation of a common introductory programming topic. Unfortunately, it may not have made the cut for inclusion based on some technical concerns of the committee. Even so, I was so happy to see this paper and to play with the implementation a little on the side! It reminded me of one of the first efforts I saw in a mainstream CS book to show how we think differently about a problem we all know and love when working with objects. That was Tim Budd's implementation of the venerable eight queens problem in An Introduction to Object-Oriented Programming.

Rather than implement the typical procedural algorithm in an object-oriented language, Budd created a solution that allowed each queen to solve the problem for herself by doing some local computation and communicating with the queen to her right. I remember first studying his code to understand how it worked and then showing it to colleagues. Most of them just said, "Huh?" Changing how we think is hard, especially when we already have a perfectly satisfactory solution for the problem in mind. You have to want to get it, and then work until you do.

You can still find Budd's code from the "download area" link on the textbook's page, though you might find a more palatable version in the download area for the book's second edition. I just spent a few minutes creating a Ruby version, which you are welcome to. It is slightly Ruby-ized but mostly follows Budd's solution for now. (Note to self: have fun this weekend refactoring that code!)

Another thing I liked about "An Introduction to Object-Oriented Programming" was its linguistic ecumenism. All examples were given in four languages: Object Pascal, C++, Objective C, and Smalltalk. The reader could learn OOP without tying it to a single language, and Budd could point out subtle differences in how the languages worked. I was already a Smalltalk programmer and used this book as a way to learn some Objective C, a skill which has been useful again this decade.

(Budd's second edition was a step forward in one respect, by adding Java to the roster of languages. But it was also the beginning of the end. Java soon became so popular that the next version of his book used Java only. It was still a good book for its time, but it lost some of its value when it became monolingual.)

Last week I wrote about an essay by Paul Lockhart from a few years ago that has been making the rounds this year. Lockhart lamented that math is so poorly misrepresented in our schools that students grow up missing out on its beauty, and even still not being able to perform the skills in whose name we have killed scholastic math. I've long claimed that we would produce more skilled students if we allowed them to approach these skills from the angle of engaging problems. For Lockhart, such problems come form the minds of students themselves and may have no connection to the "real world".

In computer science, I think letting students create their own problems is also quite valuable. It's one of the reasons that open-ended project courses and independent undergraduate research so often lead to an amazing level of learning. When a group of students wants to train a checkers-playing program to learn from scratch, they'll figure out ways to do it. Along the way, they learn a ton -- some of it material I would have selected for them, some beyond what I would have guessed.

The problems CS students create for themselves often do come straight out of their real world, and that's okay, too. Many of us CS love abstract problems such as the why of Y, but for most of us -- even the academics who make a living in the abstractions -- came to computing from concrete problems. I think I was this way, starting when I learned Basic in high school and wanted to make things, like crosstables for chess tournaments and ratings for the players in our club. From there, it wasn't that far a journey into Gödel, Escher, Bach and grad school! Along the way, I had professors and friends who introduced me to a world much larger than the one in which I wrote programs to print pages on which to record chess games.

This is one reason that I tout Owen Astrachan's problem-based learning project for CS. Owen is interested in problems that come from the real world, outside the minds of the crazy but harmless computer scientists he and I know, love, and are. These are the problems that matter to other people, which is good for the long-term prospects of our discipline and great for hooking the minds of kids on the beauty and power of computing. For computer science students, I am a proponent of courses built around projects, because they are big enough to matter to CS students and big enough to teach them lessons they can't learn working on smaller pieces of code.

With an orientation toward the ground, discussions of functional programming versus object-oriented programming seem almost not to matter. Students can solve any problem in either style, right? So who cares? Well, those of us who teach CS care, and our students should, too, but it's important to remember that this is an inward-looking discussion that won't mean much to people outside of CS. It also won't matter much to our students as they first begin to study computer science, so we can't turn our first-year courses into battlegrounds of ideology. We need to be sure that, whatever style we choose to teach first, we teach it in a way that helps students solve problems -- and create the problems that interest them. They style needs to feel right for the kind of problems we expose them to, so that the students can begin to think naturally about computational solutions.

In my department we have for more than a decade introduced functional programming as a style in our programming languages course, after students have seen OOP and procedural programming. I see a lot of benefit in teaching FP sooner, but that's would not fit our faculty all that well. (The students would probably be fine!) Functional programming has a natural home in our languages course, where we teach it as an especially handy way of thinking about how programming languages work. This is a set of topics we want students to learn anyway, so we are able to introduce and practice a new style in the context of essential content, such as how local variables work and how to write a parser. If a few students pick up on some of the beautiful ideas and go do something crazy, like fire up a Haskell interpreter and try to grok monads, well, that's just fine.

So no, I'm not complaining about the presence
of facts and formulas in our mathematics classes,
I'm complaining about the lack of mathematics
in our mathematics classes.
-- Paul Lockhart

A week or so ago I mentioned reading a paper called A Mathematician's Lament by Paul Lockhart and said I'd write more on it later. Yesterday's post, which touched on the topic of teaching what is useful reminded me of Lockhart, a mathematician who stakes out a position that is at once diametrically opposed to the notion of teaching what is useful about math and yet grounded in a way that our K-12 math curriculum is not. This topic is especially salient for me right now because our state is these days devoting some effort to the reform of math and science education, and my university and college are playing a leading role in the initiative.

Lockhart's lament is not that we teach mathematics poorly in our K-12 schools, but rather that we don't teach mathematics at all. We teach definitions, rules, and formal systems that have been distilled away from any interesting context, in the name of teaching students skills that will be useful later. What students do in school is not what mathematicians do, and that's a shame, because mathematicians is fun, creative, beautiful -- art.

As Lockhart described his nightmare of music students not being allowed to create or even play music, having to copy and transpose sheet music, I cringed, because I recognized how much of our introductory CS courses work. As he talked about how elementary and HS students never get to "hear the music" in mathematics, I thought of Brian Greene's Put a Little Science in Your Life, which laments the same problem in science education. How have we managed to kill all that is beautiful in these wonderful ideas -- these powerful and even useful ideas -- in the name of teaching useful skills? So sad.

Lockhart sets out an extreme stance. Make math optional. Don't worry about any particular content, or the order of topics, or any particular skills.

Mathematics is the music of reason. To do mathematics is to engage in an act of discovery and conjecture, intuition and inspiration; to be in a state of confusion--not because it makes no sense to you, but because you gave it sense and you still don't understand what your creation is up to; to have a breakthrough idea; to be frustrated as an artist; to be awed and overwhelmed by an almost painful beauty; to be alive, damn it.

I teach computer science, and this poetic sense resonates with me. I feel these emotions about programs all the time!

In the end, Lockhart admits that his position is extreme, that the pendulum has swung so far to the "useful skills" side of the continuum he feels a need to shout out for the "math is beautiful" side. Throughout the paper he tries to address objections, most of which involve our students not learning what they need to know to be citizens or scientists. (Hint: Does anyone really think that most students learn that now? How much worse off could we be to treat math as art? Maybe then at least a few more students would appreciate math and be willing to learn more.)

This paper is long-ish -- 25 pages -- but it is a fun read. His screed on high school geometry is unrestrained. He calls geometry class "Instrument of the Devil" because it so thoroughly and ruthlessly kills the beauty of proof:

Other math courses may hide the beautiful bird, or put it in a cage, but in geometry class it is openly and cruelly tortured.

His discussion of proof as a natural product of a student's curiosity and desire to explain an idea is as well written as any I've read. It extends another idea from earlier in the paper that fits quite nicely with something I have written about computer science: Mathematics is the art of explanation.

By concentrating on what, and leaving out why, mathematics is reduced to an empty shell. The art is not in the "truth" but in the explanation, the argument. It is the argument itself which gives the truth its context, and determines what is really being said and meant. Mathematics is the art of explanation. If you deny students the opportunity to engage in this activity--to pose their own problems, make their own conjectures and discoveries, to be wrong, to be creatively frustrated, to have an inspiration, and to cobble together their own explanations and proofs--you deny them mathematics itself.

I am also quite sympathetic to one of the other themes that runs deeply in this paper:

Mathematics is about problems, and problems must be made the focus of a student's mathematical life.

(Ditto for computer science.)

... you don't start with definitions, you start with problems. Nobody ever had an idea of a number being "irrational" until Pythagoras attempted to measure the diagonal of a square and discovered that it could not be represented as a fraction.

Problems can motivate students, especially when students create their own problems. That is one of the beautiful things about math: almost anything you see in the world can become a problem to work on. It's also true of computer science. Students who want to write a program to do something -- play a game, predict a sports score, track their workouts -- will go out of their way to learn what they need to know. I'm guessing anyone who has taught computer science for any amount of time has experienced this first hand.

As I've mentioned here a few times, my colleague Owen Astrachan is working on a big project to explore the idea of problem-based learning in CS. (I'm wearing the project's official T-shirt as I type this!) This idea is also right in line with Alan Kay's proposal for an "exploratorium" of problems for students who want to learn to commmunicate via computation, which I describe in this entry.

I love this passage from one of Lockhart's little dialogues:

SALVIATI:     ... people learn better when the product comes out of the process. A real appreciation for poetry does not come from memorizing a bunch of poems, it comes from writing your own.

SIMPLICIO:     Yes, but before you can write your own poems you need to learn the alphabet. The process has to begin somewhere. You have to walk before you can run.

SALVIATI:     ... No, you have to have something you want to run toward.

You just have to have something you want to run toward. For teenaged boys, that something is often a girl, and suddenly the desire to write a poem becomes a powerful motivator. We should let students find goals to run toward in math and science and computer science, and then teach them how.

It's interesting that I end with a running metaphor, and not just because I run. My daughter is a sprinter and now hurdler on her school track team. She sprints because she likes to run short distances and hates to run anything long (where, I think, "long" is defined as anything longer than her race distance!). The local runners' club leads a summer running program for high school students, and some people thought my daughter would benefit. One benefit of the program is camaraderie; one drawback that it involves serious workouts. Each week the group does a longer run, a day of interval training, and a day of hill work.

I suggested that she might be benefit more from simply running more -- not doing workouts that kill her, just building up a base of mileage and getting stronger while enjoying some longer runs. My experience is that it's possible to get over the hump and go from disliking longs runs to enjoying them. Then you can move on to workouts that make you faster. So she and I are going to run together a couple of times a week this summer, taking it easy, enjoying the scenery, chatting and otherwise not stressing about "long runs".

There is an element of beauty versus duty in learning most things. When the task is all duty, you may do it, but you may never like it. Indeed, you may come to hate it and stop altogether when the external forces that keep you on task (your teammates, your sense of belonging) disappear. When you enjoy the beauty of what you are doing, everything else changes. So it is with math, I think, and computer science, too.

A couple of weeks ago I linked to Shriram Krishnamurthi, who mentioned a recent SIGPLAN-sponsored workshop that has proposed a change to ACM's curriculum guidelines. The change is quite simple, shifting ten hours of instruction in programming languages from small topics into a single ten-hour category called "functional programming". Among the small topics that would be affected, coverage of recursion and event-driven programming would be halved, and coverage of virtual machines and language translation would no longer be mandated separately, nor would an "overview" of programming languages.

In practice, the proposal to eliminate coverage of some areas has less effect than you might think. Recursion is a natural topic in functional programming, and event-driven programming is a natural topic on object-oriented programming. The current recommendation of three hours total to cover virtual machines and language translation hardly does them justice anyway; students can't possibly learn any of the valuable ideas in depth in that amount of time. If schools adopt this change, they would be spending the time spent more productively helping students to understand functional programming well. Many schools will probably continue to teach those topics as part of their principles of programming languages course anyway.

I didn't comment on the proposal in detail earlier because it seemed more like the shuffling of deck chairs than a major change in stance. I do approve of the message the proposal sends, namely that functional programming is important enough to be a core topic in computer science. Readers of this blog already know where I stand on that.

Earlier this week, though, Mark Guzdial blogged Prediction and Invention: Object-oriented vs. functional, which has created some discussion in several circles. He starts with "The goal of any curriculum is to prepare the students for their future." Here is my take.

Mark seems to be saying that functional programming is not sufficiently useful to our students to make it a core programming topic. Mandating that schools teach ten hours each of functional and object-oriented programming, he thinks, tells our students that we faculty believe functional programming is -- or will be -- as important as object-oriented programming to their professional careers. Our students get jobs in companies that primarily use OO languages and frameworks, and our curricula should reflect that.

This piece has a vocational tone that I find surprising coming from Mark, and that is perhaps what most people are reacting to when they read it. When he speaks of making sure the curriculum teaches what is "real" to students, or how entry-level programmers often find themselves modifying existing code with an OO framework, it's easy to draw a vocational theme from his article. A lot of academics, especially computer scientists, are sensitive to such positions, because the needs of industry and the perceptions of our students already exert enough pressure on CS curriculum. In practical terms, we have to find the right balance between practical skills for students and the ideas that underlie those skills and the rest of computing practice. We already know that, and "esoteric" topics such as functional programming and computing theory are already part of that conversation.

Whether Mark is willing to stand behind the vocational argument or not, I think there is another theme in his piece that also requires a balance he doesn't promote. It comes back to the role of curriculum guidelines in shaping what schools teach and expressing what we think students should learn. Early on, he says,

I completely disagree that we should try to mandate that much functional programming through manipulation of the curriculum standards.

And later:

Then, when teaching more functional programming becomes a recognized best practice, it will be obvious that it should be part of the curriculum standards.

The question is whether curriculum standards should be prescriptive or descriptive. Mark views the current SIGPLAN proposal as prescribing an approach that contradicts both current best practice and the needs of industry, rather describing best practice in schools around the country. And he thinks curriculum standards should be descriptive.

I am sensitive to this sort of claim myself, because -- like Mark! -- I have been contending for many years with faculty who think OOP is a fad and has no place in a CS curriculum, or at least in our first-year courses. These faculty, both at my university and throughout the country, argue that our courses should be about what students "really do" in the world, not about esoteric design patterns and programming techniques. In the end, these people end up claiming that people like me are trying to prescribe a paradigm for how our students should think.

The ironic thing, of course, is that over the last fifteen years OOP and Java have gone from being something new to the predominant tools in industry. It's a good things that some schools started teaching more OOP, even in the first year, and developing the texts and teaching materials that other schools could use to join in later.

(The people arguing against OOP in the first year have not given up the case; they've now shifted to claiming that we should teach even Java "fundamentals first", going "back to basics" before diving into all that complicated stuff about data and procedures bearing some relation to one another. I've written about that debate before and have tremendous respect for many of the people on the front line of "basics" argument. I still disagree.)

As in the case of vocational versus theoretical content, I think we need to find the right balance between prescriptive and descriptive curriculum standards. These two dimensions are not wholly independent of each other, but they are different and so call for different balances. I agree with Mark that at least part of our curriculum standard should be descriptive of current practice, both in universities and in industry. Standard curricular practice is important in helping to create some consistency across universities and helping to keep schools who are out of the know on a solid and steady path. And the simple fact is that our students do graduate into professional careers and need to be prepared to participate in an economy that increasingly depends on information technology. For those of us at state-supported universities, this is a reasonable expectation of the people who pay our bills.

However, I think that we also need some prescriptive elements to our curricula. As Alan Kay says in a comment on Mark's blog, universities have a responsibility not only to produce graduates capable in participating in the economy but also to help students become competent, informed citizens in a democracy. This is perhaps even more important at state-supported universities, which serve the citizenry of the state. This may sound too far from the ground when talking about computer science curriculum, but it's not. The same ideas apply -- to growing informed citizens, and to growing informed technical professionals.

The notion that curriculum standards are partly prescriptive is not all that strange, because it's not that different from how curriculum standards have worked in the past, really. Personally, I like having experts in areas such as programming languages and operating systems helping us keep our curricular standards up to date. I certainly value their input for what they know to be current in the field. I also value their input because they know what is coming, what is likely to have an effect on practice in the near future, and what might help students understand better the more standard content we teach.

At first I had a hard time figuring out Mark's position, because I know him to grok functional programming. Why was he taking this position? What were his goals? His first paragraph seems to lay out his goal for the CS curriculum:

The goal of any curriculum is to prepare the students for their future. In just a handful of years, teachers aim to give the students the background to be successful for several decades.

He then recognizes that "the challenge of creating a curriculum is the challenge of predicting the future."

These concerns seem to sync quite nicely with the notion of encouraging that all students learn a modicum about functional programming! I don't have studies to cite, but I've often heard and long believed that the more different programming styles and languages a person learns, the better a programmer she will be. Mark points to studies show little direct transfer from skills learned in one language to skills learned in another, and I do not doubt their truth. But I'm not even talking about direct transfer of knowledge from functional programming to OOP; I'm thinking of the sort of expansion of the mind that happens when we learn different ways to think about problems and implement solutions. A lot of the common OO design patterns borrow ideas from other domains, including functional programming. How can we borrow interesting ideas if we don't know about them?

It is right and good that our curriculum standards push a little beyond current technical and curricular practice, because then we are able to teach ideas that can help computing evolve. This evolution is just as important in the trenches of a web services group at an insurance company as it is to researchers doing basic science. In the particular case of functional programming, students learn not only beautiful ideas but also powerful ideas, ideas that are germinating now in the development of programming languages in practice, from Ruby and Python to .NET. Our students need those ideas for their careers.

As I mentioned, Alan Kay chimed in with a few ideas. I think he disagrees that we can't predict the future by inventing it through curriculum. His idealism on these issues seems to frustrate some people, but I find it refreshing. We can set our sights higher and work to make something better. When I used the allusion to "shuffling the deck chairs" above, I was thinking of Kay, who is on record as saying that how we teach CS is broken. He has also talked to CS educators and exhorted us to set our sights higher. Kay supports the idea of prescriptive curricula for a number of reasons, the most relevant of which to this conversation is that we don't want to hard-code accidental or misguided practice, even if it's the "best" we have right now. Guzdial rightly points out that we don't want to prescribe new accidental or misguided practices, either. That's where the idea of striking a balance comes in for me. We have to do our best to describe what is good now and prescribe at least a little of what is good for the future.

I see no reason that we can't invent good futures by judiciously defined curriculum, any more than inventing futures in other arenas. Sure, we face social, societal, and political pressures, but how many arenas don't?

So, what about the particular curriculum proposal under discussion? Unlike Guzdial, I like the message it sends, that functional programming is an important topic for all CS grads to learn about. But in end I don't think it will cause any dramatic changes in how CS departments work. I used the word "encourage" above rather than Guzdial's more ominous "mandate", because even ACM's curriculum standards have no force of law. Under the proposed plan, maybe a few schools might try to present a coherent treatment of functional programming where now they don't, at the expense of covering a few good ideas at a shallow level. There will continue to be plenty of diversity, one of the values that guides Guzdial's vision. On this, he and I agree strongly. Diversity in curricula is good, both for the vocational reasons he asserts but also because we learn even better how to teach CS well from the labors and explorations of others.

I'm not yet thinking about my Programming Languages course this fall, but I wish I were. The first temptation came via my newsreader and Martin Fowler's recent piece ParserFear. Martin is writing a book on domain-specific languages and blogging occasionally on his ideas. This article is about just what the title says, programmers' often irrational fears of rolling a parser, which deter them from implementing their own DSLs. He speculates:

So why is there an unreasonable fear of writing parsers for DSLs? I think it boils down to two main reasons.

• You didn't do the compiler class at university and therefore think parsers are scary.
• You did do the compiler class at university and are therefore convinced that parsers are scary.

The first is easy to understand, people are naturally nervous of things they don't know about. The second reason is the one that's interesting. What this boils down to is how people come across parsing in universities.

CS students tend to learn about parsing for the first time in a compiler class, working on a large language with a full range of constructs. Parsing such languages is hard. In a few compiler courses, including my own, students still learn to build a parser by hand and so don't even have the chance to use parser generators as a labor- and pain-saving device. That's okay in a compiler course, which students take in large part to learn how their tools really work.

Martin doesn't suggest that we change the compiler course, and I don't either (though I'm open to possibilities). He does seem to think it's a shame that students are turned off to parsing and language design by first, and perhaps only, seeing them at their most complex. I agree and think that we should do more to introduce these ideas to students earlier.

I introduce students to the idea of parsing in my Programming Languages course, and ask students to write a few very small parsers to handle simple languages. I've been thinking for a while that I should do more in this area, and reading Martin's article has me itching to redesign the latter part of my course to allow more work with parsing and parsers. Another possibility is to use parsing as the content of some of our early programming exercises, when students are nominally learning to program in a functional style. Students can certainly apply the programming techniques they are learning to translate simple data formats into more abstract forms. This might help them to begin to see that parsing is an idea broader than just general-purpose programming languages. It might ease their transition a couple of weeks later to the idea of syntax-as-data structure and allow us to do some simple work with DSLs.

I have tried the idea of parsing at its simplest with relative novices as early as CS 1. When I taught a media computation CS1, one of the last programming assignments was to write a program to read a file of simple graphics commands and produce the desired graphical image. The idea was to bypass Java's verbose syntax for doing simple AWT/Swing graphics and allow non-programmers (artists) to make images. I asked students to implement a couple of simple commands, such as "draw line", and create at least one command of their own. I expected all of their graphics languages to be "straight-line", with no control or data structures, but that didn't mean that the resulting DSLs were not useful. They were just simple. A couple of students did really interesting work, creating very high-level commands for swirls and splashes. These students wrote methods to interpret those command using control and data structures that their "programmers" didn't have to know about.

Any change to my Programming Languages needs to be "footprint-neutral", to use Shriram Krishnamurthi's phrase. Anything I add has to fit in my fifteen-week course and either displace existing material or work in parallel. Shriram used this phrase in the broader context of rejiggering the teaching of teaching of programming languages within the core ACM curriculum, which a recent SIGPLAN-sponsored workshop tried to do. After having just read Martin's article on parsing, I was eager to refresh my memory on where parsing fits into the core curriculum proposal. Parsing falls under knowledge unit PL3, Language Translation, which has two hours allotted to it in the core. (An optional knowledge unit on Language Translation Systems includes more.) Interestingly, the working group Shriram reports on recommends cutting those two hours to zero, on the grounds that the current coverage is too superficial, and using those hours to build up a 10-hour unit on Functional Programming. That's a worthy goal, though I haven't hard a chance to think deeply about the proposal yet.

Working with constrained resources sometimes requires making tough choices. I know that Shriram and the people with whom he worked think that parsing is a worthwhile topic for CS students to know, so perhaps they have in mind something like what I suggested above: piggybacking some coverage of parsing on top of the coverage of functional programming. In any case, I think I'll work on finding more ways for my Programming Languages students to engage parsing and domain-specific languages.

The second half of the workshop opened with one of the best sessions of the event, the presentation "What Research Tells Us About Best Practices for Recruiting Girls into Computing" by Lecia Barker, a senior research scientist at the National Center for Women and IT. This was great stuff, empirical data on what girls and boys think and prefer. I'll be spending some time looking into Barker's summary and citations later. Some of the items she suggested confirm commonsense, such as not implying that you need to be a genius to succeed in computing; you only need to be capable, like anything else. I wonder if we realize how often our actions and examples implicitly say "CS is difficult" to interested young people. We can also use implicit cues to connect with the interests of our audience, such as applications that involve animals or the health sciences, or images of women performing in positions of leadership.

Other suggestions were newer to me. For example, evidence shows that Latina girls differ more from white and African-American girls than white and African-American girls differ from each other. This is good to know for my school, which is in the Iowa metro area with the highest percentage of African-Americans and a burgeoning Latina population. She also suggested that middle-school girls and high-school girls have different interests and preferences, so outreach activities should be tailored to the audience. We need to appeal to girls now, not to who they will be in three years. We want them to be making choices now that lead to a career path.

A second Five-Minute Madness session had less new information for me. I thought most about funding for outreach activities, such as ongoing support for an undergraduate outreach assistant whom we have hired for next year using a one-time grant form the university's co-op office. I had never considered applying for a special projects grant from the ACM for outreach, and the idea of applying to Avon was even more shocking!

The last two sessions were aimed at helping people get a start on designing an outreach project. First, the whole group brainstormed ideas for target audiences and goals, and then the newbies in the room designed a few slides for an outreach presentation with guidance from the more experienced people. Second, the two groups split, with the newbies working more on design and the experienced folks discussing the biggest challenges they face and ways to overcome them.

These sessions again made clear that I need to "think bigger". One, Outreach need not aim only at schools; we can engage kids through libraries, 4-H (which has broadened its mission to include technology teams), the FFA, Boys and Girls Clubs, and the YMCA and YWCA. Some schools report interesting results from working with minority girls through mother/daughter groups at community centers. Sometimes, the daughters end up encouraging the moms to think bigger themselves and seek education for more challenging and interesting careers. Two, we have a lot more support from upper administration and from CS faculty at my school than most outreach groups have at their schools. This means that we could be more aggressive in our efforts. I think we will next year.

The workshop ended with a presentation by Gabe Cohen, the project manager for Google Apps. This was the only sales pitch we received from Google in the time we were here (other than being treated and fed well), and it lasted only fifteen minutes. Cohen showed a couple of new-ish features of the free Apps suite, including spreadsheets with built-in support for web-based form input. He closed hurriedly with a spin through the new AppEngine, which debuted to the public on Wednesday. It looks cool, but do I have time?

The workshop was well-done and worth the trip. The main point I take away is to be more aggressive on several fronts, especially in seeking funding opportunities. Several companies we work with have funded outreach activities at other schools, and our state legislative and executive branches have begun to take this issue seriously from the standpoint of economic development. I also need to find ways to leverage faculty interest in doing outreach and interest from our administration in both STEM education initiatives and community service and outreach.

The workshop has ended. Google was a great host, from beginning to end. They began offering food and drinks almost immediately, and we never hungered or thirsted for long. That part of the trip made Google feel like the young person's haven it is. Wherever we went, the meeting tables included recessed power and ethernet cables for every kind of laptop imaginable, including my new Mac. (Macbook Pros were everywhere we went at Google.) But we also learned right away that visitors also must stay within bounds. No wandering around was allowed; we had to remain within sight of a Googler. And we were told not to take any photos on the grounds or in the buildings.

The workshop was presented live from within Google Docs, which allowed the leaders and presenters to display from a common tool and to add content as we went along. The participants didn't have access to the doc, but we were it as a PDF file -- on the smallest flash drive I've ever owned. It's a 1GB stick with the dimensions of the delete key on my laptop (including height).

The introduction to the workshop consisted of a linked-list game in which each person introduced the person to his left, followed by remarks from Maggie Johnson, the Learning and Development Director at Google Engineering, and Chris Stephenson, the executive director of ACM's Computer Science Teachers Association. The game ran a bit long, but it let everyone see how many different kinds of people were in the room, including a lot of non-CS faculty who lead outreach activities for some of the bigger CS departments. Chris expressed happiness that K-12, community colleges, and universities were beginning to work together on the CS pipeline. Outreach is necessary, but it can also be joyful. (This brought to mind her panel statement at SIGCSE, in a session I still haven't written up...)

Next up was Liz Adams reporting on her survey of people and places who are doing road shows or thinking about it. She has amassed a lot of raw data, which is probably most useful as a source of ideas. During her talk, someone asked, does anyone know if what they are doing is working? This led to a good discussion of assessment and just what you can learn. The goals of these road shows are many. When we meet with students, are we recruiting for our own school? Or are we trying to recruit for discipline, getting more kids to consider CS as a possible major? Are we working to reach more girls and underrepresented groups, or do we seek a rising tide? Perhaps we are doing service for the economy of our community, region, or state? The general answer is 'yes' to all of these things, which makes measuring success all the more difficult. While it's comforting to shoot wide, this may not be the most effective strategy for achieving any goal at all!

One idea I took away from this session was