Knowing and Doing

I wrote about a recent CS curricular discussion, which started with a blog posting by Mark Guzdial. Reading the comments to Guzdial's post is worth the time, as you'll find a couple of lengthy remarks by Alan Kay. As always, Kay challenges even computer science faculty to think beyond the boundaries of our discipline to the role what our students learn from us plays in a democratic world.

One of Kay's comments caught my attention for connections to a couple of things I've written about in recent years. First, consider this:

I posit that this is still the main issue in America. "Skilled children" is too low a threshold for our system of government: we need "educated adults". ... I think the principle is clear and simple: there are thresholds that have to be achieved before one can enter various conversations and processes. "Air guitar and attitude" won't do.

Science is a pretty good model (and it was used by the framers of the US). It is a two level system. The first level has to admit any and all ideas for consideration (to avoid dogma and becoming just another belief system). But the dues for "free and open" are that science has built the strongest system of critical thinking in human history to make the next level threshold for "worthy ideas" as high as possible. This really works.

This echoes the split mind of a scientist: willing to experiment with the widest set of ideas we can imagine, then setting the highest standard we can imagine for accepting the idea as true. As Kay goes on to say, this approach is embedded in the fabric of the American mentality for free society and government. This is yet another good reason for all students to learn and appreciate modern science; it's not just about science.

Next, consider this passage that follows soon after:

"Air guitar" is a metaphor for choosing too tiny a subset of a process and fooling oneself that it is the whole thing. ... You say "needs" and I agree, but you are using it to mean the same as "wants", and it is simply not the case that education should necessarily adapt to the "wants" of students. This is where the confusion of education and marketing enters. The marketeers are trying to understand "wants" (and even inject more) and cater to them for a price; real educators are interested in "needs" and are trying to fulfill these needs. Marketeers are not trying to change but to achieve fit; educators are trying to change those they work with. Introducing marketing ideas into educational processes is a disaster in the making.

I've written occasionally about ideas from marketing, from the value of telling the right story to the creating of new programs. I believe those things and think that we in academia can learn a lot from marketers with the right ideas. Further, I don't think that any of this is in conflict with what Kay says here. He and I agree that we should not change our curriculum to cater solely to the perceptions and base desires of our clientele, whether students, industry, or even government. My appeal to marketing for inspiration lies in finding better ways to communicate what we do and offer and in making sure that what we do and offer are in alignment with the long-term viability of the culture. The best companies are in business for the long haul and must stay aligned with the changing needs of the world.

Further, as I am certain Kay will agree based on many of the things he has said about Apple of the 1980s, the very best companies create and sell products that their customers didn't even know they wanted. We in academia might learn something from the Apples of our world about how to provide the liberal and professional education that our students need but don't realize they need. The same goes for convincing state legislatures and industry when they view too short a horizon for what we do.

Like Kay, I want to give my students "real computing" and "real education".

I think it is fitting and proper to talk about these issues on Independence Day in the United States. We depend on education to preserve the democratic system in which we live and the values by which we live. But there's more. Education -- including, perhaps especially, science -- creates freedom in the student. The mind becomes free to think greater thoughts and accomplish greater deeds when it has been empowered with our best ideas. Science is one.

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.

In March I talked about a couple of OOPSLA submissions written by our merged ChiliPLoP groups. In May I wrote about the verdict on one but forgot to mention the other. Maybe because the rejection was so much more interesting!

Anyone, our second submission was accepted into the Educators' Symposium. It is not a paper, really, but an extended abstract for an activity we will run: a code review recast as it might happen in a software studio. We hope to give participants a snapshot of what a studio-based course looks, feels, and works like. This is something instructors can try on a small scale in class and, if it works for them, expand throughout their course. Even if code reviews is all the farther they go, we co-authors think that this will be a useful step for many instructors. It draws on experiences in the writers' workshops of PLoP helps students to think about the many design choices they make when writing software, and to make them reflectively rather than subconsciously.

The real trick to this activity will be the homework we give before the symposium:

Before coming to OOPSLA, Educators' Symposium participants will be asked to submit a program, in a language of their choice (though using only standard libraries), which implements the core of a program to generate Tag Clouds from a data set. ...

My experience with many workshops in the past and especially with the Educators' Symposium is that participants never do this kind of homework. Some are well-intentioned but never make time for it, while others figure they can skate by without having written the code. (Sounds as if professors are a lot like their students, huh?) Without code to review, a code review doesn't get very far. We hope that we can find a way to encourage symposium attendees to overcome history and come with some code to workshop.

I received my copy of the student evaluations from my spring course, which was really three courses that felt like one to me and a few common students. One of the open-ended questions on the form my university uses asks the student to complete this blank:

I could have improved my learning in this course by _____.

After teaching for a while now, I can predict what students will say in this section. This semester was a perfect example.

The second most common answer is a variation of ...

reading the textbook

It doesn't what book I assign; how big it is; whether it is mostly exposition or mostly code; or whether it's written in an academic style or in the vernacular. A few students read the book, and a few of those will typically praise it, but most don't read much if any of it.

The most common answer is a variation of (drumroll, please) ...

starting the homework assignments sooner

Sooner, so they had more time to work on them. Sooner, so that they could ask questions when they were stumped. Sooner for all sorts of reason, but always sooner.

Neither of these bits of wisdom are new to them. If nothing else, they have heard me exhort them to start sooner and to read more. I suppose I could do more to encourage these behaviors, such as giving quick quizzes every day over the reading, but most strategies feel wrong. Do either students or I really want to turn the class into a treadmill of points for their grade? Do I want to have to grade all that stuff? Aren't they adults?

For homework assignments, one thing we instructors can do to encourage beginning sooner is to have short iterations with frequent submission. In my spring course, I had small programming exercises due weekly. I could have tried biweekly submissions, or a problem every other day. But that feels like micromanagement to me. Students have other courses and work schedules to consider, and I like to give them at least a few days to navigate through their various duties. And besides, aren't they adults?

I don't think that students want to be micromanaged with quizzes and deadlines, and I do think think they genuinely mean well. Maybe the problem is that they view the comments they make on student evaluations as backward-looking, when instead they should think of them as forward-looking. Perhaps we should phrase the question as

I will improve my learning in future courses by _____.

The student's evaluation of the instructor would then be more like a retrospective that benefits the student as much as the instructor, because it asks both parties to consider how they can improve their results in the "next iteration" -- the next courses they take. These comments about the future, not the past.

(Ooh, it just occurred to me: perhaps I could try a brief something after one of the assignments early in the course that plays the role of retrospective. Maybe if students consciously consider the value of starting sooner and reading the text during the course they can change their behavior soon enough to affect their performance. This would create more frequent futures!)

What did I learn from these evaluations that will help me in the future? In every course, there is a set of common answers to the item "My learning in this course would have improved if the instructor had _____.", but for this item there are also usually an answer or two that stand out as particularly salient or which teach me something new.

From this course, students reminded me of the value in reviewing solutions to homework assignments soon after they submit their solutions. This is always a valuable tactic, and especially in a course where students are learning new languages and styles of programming. The best way to learn is to see different solutions, including ones that demonstrate idiomatic usage. It gives students a way to compare their solutions and to learn from differences. I let the fact that most of students this semester were juniors and seniors with a fair amount of programming experience convince myself that maybe we could get by without this sort of follow-up. But that was probably just a juicy rationalization that allowed me to "squeeze in more material", to the detriment of my student's learning.

I have written about that before in my blog. This entry is now an example of how I am sometimes no better than my students at practicing what I recommend in a retrospective! Let's see if I can do better at this in the fall.

The rest of my evaluation data was pretty good -- a nice ego boost in a week where I needed one. Consider this an open "thank you" to the students who take time to write both suggestions for improvement and positive comments that let me know that, on the whole, they like my courses. Those positive comments help keep us instructors motivated just as much as positive feedback helps students feel better about hanging in there.

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.

I'm preparing for a quick visit to the Google campus tomorrow and Friday. This is my first trip to the Google campus, and I have to admit that I'm looking forward to it. To this wide-eyed Midwestern computer scientist, it feels as if I am visiting Camelot.

The occasion of my trip is a "roadshow summit" co-sponsored by the Computer Science Teachers Association and SIGCSE, and hosted by Google. The CSTA is a unit of the ACM "that supports and promotes the teaching of computer science and other computing disciplines" in K-12 schools. The goal of the workshop is:

... to bring together faculty and students who are currently offering, or planning to develop, outreach "road shows" to local K-12 schools. Our goal is to improve the quality and number of college and university-supported careers and equity outreach programs by helping to develop a community that will share research, expertise, and best practices, and create shared resources.

My selfish goal in wanting to attend the workshop initially was to steal lots of good ideas with more experience and creativity than I. My contribution will be to share what we have done in our department, especially over the last semester. I asked two faculty members to develop curricula for K-12 outreach activities, in lieu of one of their usual course assignments. The curriculum materials should be useful whether we take them on the road to the schools or when we have students on campus for visits. One professor started with robotics in mind but quickly switched to some simple programming activities with the Scratch programming environment. The other worked on high-performance and parallel computing for pre-college students, an education thread he has been working in for much of this decade. I do not have a link to materials he developed specifically for our outreach efforts yet, but I can point you to LittleFe, one of his ongoing projects.

I'm curious to see what other schools have done and still plan to steal as many ideas as I can! And, while I'm looking forward to the workshop and seeing Google's campus, I am not looking forward to the fast turnaround... My flight leaves tomorrow morning; we work Thursday afternoon, Thursday evening, Friday morning, and Friday early afternoon; and then I start the sojourn back home. I'll cover a lot of miles in forty-eight hours, but I hope they prove fruitful.

Someone pointed me toward a video of a talk given at Google by John Medina on his new book Brain Rules. I enjoyed the talk and will have to track down a copy of the book. Early on, he explains that the way he have designed our schools and workplaces produce the worst possible environments in which for us to learn and work. But my favorite passage came near the end, in response to the question, "Do you believe in magic?"

Hopefully I'm a nice guy, but I'm a really grumpy scientist, and in the end, I'm a reductionist. So if you can show me, [I'll believe it]. As a scientist, I have to be grumpy about everything and be able to be willing to believe anything. ... If you care what you believe, you should never be in the investigative fields -- ever. You can't care what you believe; you just have to care what's out there. And when you do that, your bandwidth is as wide as that sounds, and the rigor ... has to be as narrow as as the biggest bigot you've ever seen. Both are resident in a scientist's mind at the same time.

Yes. Unfortunately, public discourse seems to include an unusually high number of scientists are very good at the "being grumpy about everything" part and not so good at the "being able to be willing to believe anything" part. Notice that Medina said "be able to be willing to believe", not "be willing to believe". I think that some people are less able to be willing to believe something they don't already believe, which makes them not especially good candidates to be scientists.

I grew up on the sitcom of the 1970s and 1980s. As kids, we watched almost everything we saw in reruns, whether from the '60s or the '70s, but I enjoyed so many of them. By the time I got to college, I had well-thought ideas on why The Dick Van Dyke Show remains one of the best sitcoms ever, why WKRP in Cincinnati was underrated for its quality, and why All in the Family was _the_ best sitcom ever. I still hold all these biases in my heart. Of course, I didn't limit myself to sitcoms; I also loved light-action dramas, especially The Rockford Files.

Little did I know then that my TV viewing was soaking up a cognitive surplus in a time of social transition, or that it had anything in common with gin pushcarts in the streets of London at the onset of the Industrial Revolution.

Clay Shirky has published a wonderful little essay, Gin, Television, and Social Surplus that taught me these things and put much of what we see on happening on the web into the context of a changing social, cultural, and economic order. Shirky contends that, as our economy and technology evolve, a "cognitive surplus" is created. Energy that used to be spent on activities required in the old way is now freed for other purposes. But society doesn't know what to do with this surplus immediately, and so there is a transition period where the surplus is dissipated in (we hope) harmless ways.

My generation, and perhaps my parents', was part of this transition. We consumed media content produced by others. Some denigrate that era as one of mindless consumption, but I think we should not be so harsh. Shows like All in the Family and, yes, WKRP in Cincinnati often tackled issues on the fault lines of our culture and gave people a different way to be exposed to new ideas. Even more frivolous shows such as The Dick Van Dyke Show and The Rockford Files helped people relax and enjoy, and this was especially useful for those who were unprepared for the expectations of a new world.

We are now seeing the advent of the new order in which people are not relegated to consuming from the media channels of others but are empowered to create and share their own content. Much attention is given by Shirky and many, many others to the traditional media such as audio and video, and these are surely where the new generation has had its first great opportunities to shape its world. As Shirky says:

Here's something four-year-olds know: A screen that ships without a mouse ships broken. Here's something four-year-olds know: Media that's targeted at you but doesn't include you may not be worth sitting still for.

But as I've been writing about here, lets not forget the next step: the power to create and shape the media themselves via programming. When people can write programs, they are not relegated even to using the media they have been given but are empowered to create new media, and thus to express and share ideas that may otherwise have been limited to the abstraction of words. Flickr and YouTube didn't drop from the sky; people with ideas created new channels of dissemination. The same is true of tools like Photoshop and technologies such as wikis: they are ideas turned into reality through code.

Do read Shirky's article, if you haven't already. It has me thinking about the challenge we academics face in reaching this new generation and engaging them in the power that is now available to them. Until we understand this world better, I think that we will do well to offer young people lots of options -- different ways to connect, and different paths to follow into futures that they are creating.

One thing we can learn from the democratized landscape of the web. I think, is that we are not offering one audience many choices; we are offering many audiences the one or two choices each that they need to get on board. We can do this through programming courses aimed at different audiences and through interdisciplinary major and minor programs that embed the power of computing in the context of problems and issues that matter to our students.

Let's keep around the good old CS majors as well, for those students who want to go deep creating the technology that others are using to create media and content -- just as we can use the new technologies and media channels to keep great old sitcoms available for geezers like me.

I still have a couple of entries to make on SIGCSE 2008 happenings. If I don't hurry up, it will be time for reports from PLoP or OOPSLA! But I do have a bit of related good news to post...

I've received an invitation to Peter Denning's "Rebooting Computing" summit, which I first mentioned when covering Denning's talk at SIGCSE. The summit is scheduled for January 2009 and is part of Denning's NSF-funded Resparking Innovation in Computing Education project. This will be a chance to spend a few days with others thinking about this issue to outline concrete steps that we all might take to make change. I've written about this issue frequently here, most recently in the form of studio-based computing, project-based and problem-based learning, and programming for non-CS folks like computing into their own work. (Like scientists and artists. I'm excited about this chance.

I sometimes talk about lecture (say, here) as not being the optimal way for students to learn. That doesn't mean that I don't think it lecture has value at all. I still lecture, though I prefer to punctuate my disquisition with occasional problem breaks, during which students try out some idea. Without those breaks, the active learning they afford, and the feedback they can give students about where they stand, I sometimes wonder how much value being in class with me for seventy-five minutes has.

It turns out that there is probably value even in "just listening". Mark Guzdial recently described work by a psychology grad student that explains the relationship between learning and reading text, hearing narration, and viewing images. Most people learn more efficiently when they hear an explanation while looking at text, code, or diagrams. If they read the same explanation while looking at the text, code, or diagrams, it will take them longer to learn the material to the same depth.

So, coming to class and hearing a good lecture can be a good investment of time. It jump-starts the brain. Of course, the student still needs to read and work through problems at home later, too. Reading and solving problems give the mind an opportunity to rehearse and to process material more deeply. The result of listening to lecture followed by intense study can be a powerful form of learning.

I encourage students to take advantage of all their modalities. Augmenting lecture with opportunities for practice and feedback gives them a strong combination of learning styles in class. Then, as often as I can, I provide students with written notes that contain both my explanations and the in-class exercises we did. This allows them to recall their in-class experience as much as possible. On the occasion when students really must miss class, they can get a flavor of what happened in class, but reading the notes is a poor substitute for experiencing the class live. Then, I assign readings from a text or other sources that supplements the material with cover in class with a different presentation. Finally, I ask students to do a significant amount of project work, which gives them the chance to learn how to do while exercising the knowledge of the material in ways that make connections in their minds. I hope that this multi-faceted approach maximizes student opportunities to learn deeply and come to appreciate what they learn.

I notice a common rhetorical device in many academic arguments. It goes like this. One person makes a claim and offers some evidence. Often, the claim involves doing something new or seeing something in a new way. The next person rebuts the argument with a claim that the old way of doing or seeing things is more "fundamental" -- it is the foundation on which other ways of doing and seeing are built. Oftentimes, the rebuttal comes with no particular supporting evidence, with the claimant relying on many in the discussion to accept the claim prima facie. We might call this The Fundamental Imperative.

This device is standard issue in the CS curriculum discussions about object-oriented programming and structured programming in first-year courses. I recently noticed its use on the SIGCSE mailing list, in a discussion of what mathematics courses should be required as part of a CS major. After several folks observed that calculus was being de-emphasized in some CS majors, in favor of more discrete mathematics, one frequent poster declared:

(In a word, computer science is no longer to be considered a hard science.)

If we know [the applicants'] school well we may decide to treat them as having solid and relevant math backgrounds, but we will no longer automatically make that assumption.

Often, the conversation ends there; folks don't want to argue against what is accepted as basic, fundamental, good, and true. But someone in this thread had the courage to call out the emperor:

If you want good physicists, then hire people who have calculus. If you want good computer scientists, then hire people who have discrete structures, theory of computation, and program verification.

I don't believe that people who are doing computer science are not doing "hard science" just because it is not physics. The world is bigger than that.

...

You say "solid and relevant" when you really should be saying "relevant". The math that CS majors take is solid. It may not be immediately relevant to problems [at your company]. That doesn't mean it is not "solid" or "hard science".

I sent this poster a private "thank you". For some reason, people who drop the The Fundamental Imperative into an argument seem to think that it is true absolutely, regardless of context. Sure, there may be students who would benefit from learning to program using a "back to the basics" approach, and there may be CS students for whom calculus will be an essential skill in their professional toolkits. But that's probably not true of all students, and it may well be that the world has changed enough that most students would benefit from different preparation.

"The Fundamental Imperative" is a nice formal name for this technique, but I tend to think of it as "if it was good enough for me...", because so often it comes down to old fogies like me projecting our experience onto the future. Both parties in such discussions would do well not to fall victim to their own storytelling.

The verdict is in on the paper we wrote at ChiliPLoP and submitted to Onward!: rejected. (We are still waiting to hear back on our Educators' Symposium submission.) The reviews of our Onward! paper were mostly on mark, both on surface features (e.g., our list of references was weak) and on the deeper ideas we offer (e.g., questions about the history of studio approaches, and questions about how the costs will scale). We knew that this submission was risky; our time was simply too short to afford enough iterations and legwork to produce a good enough paper for Onward!.

I found it interesting that the most negative reviewer recommended the paper for acceptance. This reviewer was clearly engaged by the idea of our paper and ended up writing the most thorough, thoughtful review, challenging many of our assumptions along the way. I'd love to have the chance to engage this person in conversation at the conference. For now, I'll have to settle for pointing out some of the more colorful and interesting bits of the review.

In at least one regard, this reviewer holds the traditional view about university education. When it comes to the "significant body of knowledge that is more or less standard and that everyone in the field should acquire at some point in time", "the current lecture plus problem sets approach is a substantially more efficient and thorough way to do this."

Agreed. But isn't it more efficient to give the students a book to read? A full prof or even a TA standing in a big room is an expensive way to demonstrate standard bodies of knowledge. Lecture made more sense when books and other written material were scarce and expensive. Most evidence on learning is that lecture is actually much less effective than we professors (and the students who do well in lecture courses) tend to think.

The reviewer does offer one alternative to lecture: "setting up a competition based on mastery of these skills". Actually, this approach is consistent with the spirit of our paper's studio-based, apprenticeship-based, and project-based. Small teams working to improve their skills in order to win a competition could well inhabit the studio. Our paper tended to overemphasize the softer collaboration of an idyllic large-scale team.

This comment fascinated me:

Another issue is that this approach, in comparison with standard approaches, emphasizes work over thinking. In comparison with doing, for example, graph theory or computational complexity proofs, software development has a much lower ratio of thought to work. An undergraduate education should maximize this ratio.

Because I write a blog called Knowing and Doing, you might imagine that I think highly of the interplay between working and thinking. The reviewer has a point: an education centered on projects in a studio must be certain to engage students with the deep theoretical material of the discipline, because it is that material which provides the foundation for everything we do and which enables us to do and create new things. I am skeptical of the notion that an undergrad education should maximize the ratio of thinking to doing, because thinking unfettered by doing tends to drift off into an ether of unreality. However, I do agree that we must try to achieve an appropriate balance between thinking and doing, and that a project-based approach will tend to list toward doing.

One comment by the reviewer reveals that he or she is a researcher, not a practitioner:

In my undergraduate education I tried to avoid any course that involved significant software development (once I had obtained a basic mastery of programming). I believe this is generally appropriate for undergraduates.

Imagine the product of an English department saying, "In my undergraduate education I tried to avoid any course that involved significant composition (once I had obtained a basic mastery of grammar and syntax). I believe this is generally appropriate for undergraduates." I doubt this person would make much of a writer. He or she might be well prepared, though, to teach lit-crit theory at a university.

Most of my students go into industry, and I encourage them to take as many courses as they can in which they will build serious pieces of software with intellectual content. The mixture of thinking and doing stretches them and keeps them honest.

An education system that produces both practitioners and theoreticians must walk a strange line. One of the goals of our paper was to argue that a studio approach could do a better job of producing both researchers and practitioners than our current system, which often seems to do only a middling job by trying to cater to both audiences.

I agree wholeheartedly, though, with this observation:

A great strength of the American system is that it keeps people's options open until very late, maximizing the ability of society to recognize and obtain the benefits of placing able people in positions where they can be maximally productive. In my view this is worth the lack of focus.

My colleagues and I need to sharpen our focus so that we can communicate more effectively the notion that a system based on apprenticeship and projects in a studio can, in fact, help learners develop as researchers and as practitioners better than a traditional classroom approach.

The reviewer's closing comment expresses rather starkly the challenge we face in advocating a new approach to undergraduate education:

In summary, the paper advocates a return to an archaic system that was abandoned in the sciences for good reason, namely the inefficiency and ineffectiveness of the advocated system in transmitting the required basic foundational information to people entering the field. The write-up itself reflects naive assumptions about the group and individual dynamics that are required to make the approach succeed. I would support some of the proposed activities as part of an undergraduate education, but not as the primary approach.

The fact that so many university educators and graduates believe our current system exists in its current form because it is more efficient and effective than the alternatives -- and that it was designed intentionally for these reasons -- is a substantial cultural obstacle to any reform. Such is the challenge. We owe this reviewer our gratitude for laying out the issues so well.

In closing, I can't resist quoting one last passage from this review, for my friends in the other sciences:

The problem with putting students with no mastery of the basics into an apprenticeship position is that, at least in computer science, they are largely useless. (This is less true in sciences such as biology and chemistry, which involve shallower ideas and more menial activities. But even in these sciences, it is more efficient to teach students the basics outside of an apprenticeship situation.)

The serious truth behind this comment is the one that explains why building an effective computer science research program around undergraduates can be so difficult. The jocular truth behind it is that, well, CS is just plain deeper and harder! (I'll duck now.)

Not from me, but from The Common School Journal, an early-1800s primer on teaching:

Make no effort to simplify language.

Also: Treat all students as equals, with expectation that all participate and learn. Teach where each student lacks.

I think I have a more detailed essay on this topic in me, in terms of how we teach programming and software development. But it will have to wait for another day. In any case, my agedness seems to be growing asymptotically faster than my wisdom.

Brian Marick lamented recently that his daughter's homework probably wasn't affecting her future in the same way that some of his school experiences affected his. I've had that feeling, too, but sometimes wonder whether (1) my memory is good enough to draw such conclusions and (2) my daughters will remember key experiences from their school days anyway. After teaching for all these years I am sometimes surprised by what former students remember from their time in my courses, and how those memories affect them.

Brian's mention of New Math elicited some interesting comments. Kevin Lawrence hit on a point that has been on my mind in two contexts lately:

A big decision point in education is whether you are optimizing for people who will go on to be very good at a subject or for people who find it difficult.

In the context of university CS curricula, I often field complaints from colleagues here and everywhere about how the use of (graphics | games | anything post-1980 | non-scientific applications) in CS courses is dumbing down of our curriculum. These folks claim that we are spending too much time catering to folks who won't succeed in the discipline, or at least excel, and that at the same time we drive away the folks who would be good at CS but dislike the "softness" of the new approach.

In the context of reaching out to pre-university students, to show folks cool and glitzy things that they might do in computer science, I sometimes hear the same sort of thing. Be careful, folks say, not to popularize the science too much. We might mislead students into thinking that CS is not serious, or that it is easy.

I fully agree that we don't want to mislead middle schoolers or CS majors about the content or rigor of our discipline, or to give the impression that we cannot do serious and important work. But physics students and math geeks are not the only folks who can or should use computing. They are most definitely not the only folks who can make vital contributions to the discipline. (We can even learn from people who quote "King Lear".)

By not reaching out to students with different views and interests, we do computer science a disservice. Once they are attracted to the discipline and excited to learn, we can teach them all about rigor and science and math. Some of those folks won't succeed in CS, but then again neither do some of the folks who come in with the more traditional "geeky" interests.

If this topic interests you, follow the trail from Brian's blog to two blog entries by Kevin Lawrence, one old and one new. Both are worth a read. (I always knew there was a really good reason to enable comments on my blog -- Alan Kay might drop by!)

I may not be a web guy, but some of my students are -- and very good ones. Back in December, I wrote about one of my students, Sergei Golitsinski, defending an MA thesis in Communications, which used computing to elucidate a problem in that discipline. For that study, he wrote tools that allowed him to trace the threads of influence in a prominent blog-driven controversy.

Sergei finally defended his MS thesis in computer science yesterday. Its title -- "Specification and Automatic Code Generation of the Data Layer for Data-Intensive Web-Based Applications" -- sounds like the usual thesis title, but as is often the case the idea behind it is really quite accessible. This thesis shows how you can use knowledge about your web application to generate much of the code you need for your site.

I like this work for several reasons. First, it was all about finding patterns in real applications and using them to inform software development. Second, it focused on how to use domain knowledge to get leverage from the patterns. Third, it used standard language-processing ideas to create a modeling language and then use models written in it to generate code. This thesis demonstrates how several areas of computer science -- database, information storage and retrieval, and programming languages among them -- can work together to help us write programs to do work for us. I also like it because Sergei applied his ideas to his own professional work and took a critical look at what the outcome means for his own practice.

Listening to the defense, I had two favorite phrases. The first was recursive weakness. He used this term in reference to weak entities in a database that are themselves parents to weak entities. But it brought to mind so many images for the functional programmer in me. (I'm almost certainly recursively weak myself, but where is the base case?) The second arose arose while discussing alternative approaches to a particular problem. Referring to one, he said trivial approach; non-trivial implementation. It occurred to me that so many ideas fall into this category, and part of understanding your domain well is recognizing them. Sometimes we need to avoid their black holes; other times, we need their challenges. Another big part of becoming a master is knowing which path to choose once you have recognized them.

Sergei is a master, and soon he will have a CS degree that says so. But like all masters, he has much to learn. When I wrote about his previous defense, his plan was up in the air but pointing toward applying CS in the world of communications. Since then, he has accepted admission to a Ph.D. program in communications at the University of Maryland, where he hopes to be in the vanguard of a new discipline he calls computational communications. I look forward to watching his progress.

You can read his CS thesis on-line, and all of the code used in his study will be, too, soon.

I am not a web guy. If I intend to teach languages (PHP) or frameworks (Rails) with the web as their natural home, I need to do a lot more practice myself. It's too easy to know how to do something and still not know it well enough to teach it well. Unexpected results under time pressure create too much trouble.

MySQL, no. PostgreSQL, yes. This, twenty years after cutting my database teeth on Ingres.

Ruby's dynamic features are so, so nice. Still, I occasionally find myself wishing for Smalltalk. First love never dies.

Fifteen hours of instruction -- 5 weeks at 3 hours per week -- is plenty of time to teach most or all of the ideas in a language like bash, PHP, or Ruby. But the instructor still needs to select specific examples and parts of the class library carefully. It's too easy to start down a path of "Now look at this [class, method, primitive]..."

When I succeeded in selecting carefully, I suffered from persistent omitter's resource. "But I wish I could have covered that... Sometimes that is what students wanted to see. But most of the time they can figure that out. What they want is some insight. What insight could I have shared had I covered that instead of this?

If you want to know what students want, ask them. Easy to say, hard to do unless I slow down occasionally to reflect.

Practice, practice, practice. That's where students learn. It's also where students who don't learn don't learn.

Oh, and professor: That "Practice, practice, practice" thing -- it applies to you, too. You'll remember just how much fun programming can be.

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

Of the 20 greatest engineering achievements of the 20th century, two lie within computing: computers (#8) and the Internet (#13). Those are broad categories defined around general-purpose tools that have affected the lives of almost every person and the practice of almost every job.

In 2004, human beings harvested 10 quintillion grains of rice. In 2004, humans beings fabricated 10 quintillion transistors. 10 quintillion is a big number: 10,000,000,000,000,000,000.

Ed Lazowska of the University of Washington opened his Saturday luncheon talk at SIGCSE with these facts, as a way to illustrate the broad effect that our discipline has had on the world and the magnitude of the discipline today. He followed by putting the computational power available today into historical context. The amount of computational power that was available in the mainstream in the 1950s is roughly equivalent to an electronic greeting card today. Jump forward to the Apollo mission to the moon, and that computation power is now available in a Furby. Lazowska didn't give sources for these claims or data to substantiate them, but sound reasonable to me within an order of magnitude.

The title of Lazowska's talk was "Computer Science: Past, Present, and Future", and it was intended to send conference attendees home energized about our discipline. He energized folks with cool facts about computer science's growth and effect. Then he looked to the future, at some of the challenges and some of the steps being taken to address them.

One of the active steps being taken within computing is the Computing Community Consortium a joint venture of the National Science Foundation and the Computing Research Association, whose mission is to "supports the computing research community in creating compelling research visions and the mechanisms to realize these visions". According to Lazowska, the CCC hopes to inspire "audacious and inspiring research" while at the same time articulating visions of the discipline to the rest of the world. Lazowska is one of the leaders of the group. The group's twin goals are both worth the attention of our discipline's biggest thinkers.

As I listened to Lazowska describe the CCC's initiatives, I was reminded of our discipline's revolutionary effect on other disciplines and industries. Lazowska reported that two or two and a half of the 20th century's greatest engineering results were computing, but take a look at the rest of the list. Over the last half century, computers and the Internet have played an increasingly important role in many of these greatest achievements, from embedded computers in automobiles, airplanes, and spacecraft to the software that has opened new horizons in radio and television, telephones, health technologies, and most of the top 20.

Now take a look at the Grand Challenges for Engineering in the 21st Century, which Lazowska pointed us to. Many of these challenges depend crucially upon our discipline. Here are seven:

• secure cyberspace
• enhance virtual reality
• advance personalized learning
• engineer the tools of scientific discovery
• advance health informatics
• reverse-engineer the brain
• engineer better medicines

But imagine doing any of the other seven without involving computing in an intimate way!

I've written a few times about how science has come to be a computational endeavor. Lazowska gave an example that I reported from as part of the next generation of science: databases. A database makes it possible to answer questions that you think of next year, not just the ones you thought of five years ago, when you wrote your proposal to NSF and when you later defined the format of your flat text file. He illustrated his idea with examples of projects at the Ocean Observatories Initiative, and the Quality of Life Technology Center. He also mentioned the idea of prosthetics as the "future of interfaces", which is a natural research and entrepreneurial opportunity for CS students. You may recall having read about this entrepreneurial connection in this blog way back!

For his part, Lazowska suggested advancing personalized learning as an area in which computing could have an immeasurable effect. Adaptive one-on-one tutoring is something that could reach an enormous unserved population and help develop the human capital that could revolutionize the world. This is actually the area into which I was evolving back when I was doing AI research, intelligent tutoring systems. I remain immensely interested in the area and what it could mean for the world. Many folks are uncomfortable with the idea of "computers teaching our children", but I think it's simply a part of the evolution of communication that computer science embodies. The book is a means of educating, communicating, and sharing information, but it is a one-track medium. The computer is a multiple-track medium, a way to deliver interactive and dynamic content to a wide audience. A "dynabook"... I wonder if anyone has been promoting this idea for say, oh, thirty years?

Fear of computers playing a human-like role in human interaction is nothing new. It reminds me of another story Lazowska told, from Time Magazine's article on the computer as the 1982 Machine of the Year. The article mentions CADUCEUS, one of the medical expert systems that was at the forefront of AI's focus on intelligent systems in the '70s and '80s. Here's the best passage:

... while it is possible that a family doctor would recognize 4,000 different symptoms, CADUCEUS is more likely to see patterns in what patients report and can then suggest a diagnosis. The process may sound dehumanized, but in one hospital where the computer specializes in peptic ulcers, a survey of patients showed that they found the machine "more friendly, polite, relaxing and comprehensible" than the average physician.

There are days when I am certain that we can create an adaptive tutoring system that is more relaxing and comprehensible than I am as a teacher, and probably friendlier and politer to boot.

Lazowska closed with an exhortation that computer scientists adopt the stance of the myth buster in trying to educate the general population, whether myths about programming (e.g., "Programming is a solitary activity"), employment ("Computing jobs will all go overseas."), or intrinsic joy ("There are no challenges left.") He certainly gave his audience plenty of raw material for busting one of the myths about the discipline not being interesting: "Computer science lacks opportunities to change the world." Not only do we change the world directly in the form of things like the Internet; these days, when almost anyone changes the world, they do so by using computing!

Lazowska's talk was perhaps too long, trying to pack more information into an hour than we could comfortably digest. But it was a good way to close out SIGCSE, given that one of its explicit themes seemed to engaging the world and that the buzz everywhere I went at the conference was about how we need to reach out more and communicate more effectively.

Recently, both Lance Fortnow and Michael Mitzenmacher wrote entries on how often a prof can miss a class during the semester. This is an issue for any instructor who has a professional life. Between conferences to attend and professional service duties, there will always be a conflict some time.

I have a standing solution for myself, developed through many years of teaching, going to conferences, reviewing for NSF, and serving on program committees. I teach a Tuesday/Thursday schedule in a fifteen-week semester, so a full set of class meetings is thirty. Every semester, I just plan for twenty-eight.

In the fall, I have standing plans to attend OOPSLA and, until a couple of years ago, PLoP. In the spring come SIGCSE, ChiliPLoP, or both. I can usually cover 28 sessions both semesters with a little calendar help. Until the 2007-2008, we always had two days during Thanksgiving week, which gave my courses a 29th meeting day. The spring has Spring Break. When my conference schedule falls just wrong and leaves me a day short, I will ask someone to guest lecture.

My students don't seem to mind. I usually leave them with a good project to work on while I'm gone, sometimes larger than the usual project given that they have more time to spend on it. In the end, what students learn is less about what I do in class than about what they do with the course material, and a good-sized project is usually well worth the time alloted. When I get back, we can debrief the project and, when appropriate, discuss what I learned while I was away. Later, I can fold what I learned into future courses, which makes the two class days missed an investment in the experience I can offer.

This semester I faced an unusual choice. Instead of one 15-week course, I am teaching three 5-week courses. My away time, for SIGCSE, all fell during one of the 5-week sessions. 28 out of 30 seems reasonable, but 8 out of 10 did not. So I arranged to meet my students for a couple of "make-up sessions". We held one the day before I left for Portland. After we had completed sessions 8 and 9 after break, we decided that 9 out of 10 had been enough, and we called it a wrap. I was willing to do a tenth session if students were interested, but they seemed ready to move on, so we did.

The choices we face at primarily undergraduate "teaching university" are probably different from those faced at bigger, research school. First, I suspect that some if not all of Lance's and Michael's teaching is done in graduate classes. Grad students are a different audience, one perhaps better able to use time away from class productively while still learning new material. Second, at the bigger schools, teaching a class for undergrads often means having one or more graduate TAs to help. These folks are often more than capable of pinch-hitting for an extra absence or two during the semester, with no apparent loss in quality to the students. (If you believe some of the stereotypes about research-oriented faculty, then you might think that the students could be better off with a TA filling in. But I think that stereotype is overblown and often just wrong.)

Another option available to us these days is videocasting. One of my colleagues who travels a lot in-semester sometimes records a lecture for his students in a classroom that supports showing the professor and the projected image in the video. This takes time, if only because there is a tendency for an instructor to want not to leave blemishes in a videocast recorded for posterity -- even little glitches that are normal in any in-person presentation. I've not tried this yet, but I might one day soon when the conditions are right. Done well, this could be better than even a well-prepared set of lecture notes and questions.

A while back, I wondered out load how I might be able to improve my "topics in languages" courses over the course of the semester, with them being three 5-week iterations instead of the usual 15-week course. The languages in the three courses have been different -- bash, PHP, and now Ruby -- which influences how and when I teach what, but all of the courses are about scripting, so there is a common mindset. This has made it possible, for example, to reuse several in-class examples and homework exercises, as a way for students participating in more than one of the iterations to compare and contrast how the languages work.

I have noticed one unexpected phenomenon from the vantage point of closer-than-usual iterations: How I teach a language I know is different from how I teach a language I don't know. Or perhaps I should say, how I want to teach a language I know is different from how I want to teach a language I don't know.

Going into the bash section, I knew a fair amount of shell scripting already and felt a desire to delve into the areas that I didn't know as well. But the shell was new enough to most of the students, and different enough from the languages they knew, that I was able comfortably in my mind to organize the course around the basic principles of the Unix Way, especially pipes. Using a good secondary text, Classic Shell Scripting, helped, too.

Then came PHP, about which I knew relatively little. I found myself paying close attention to low-level syntactic issues as I myself learned the language well. "Look at this cool thing I just learned about variables..." was a typical expression in class. Some of the examples I used were rather un-PHP-like as I explored the boundaries of the language.

I am now teaching Ruby, a language I know and like pretty well. I find myself wanting to jump passed the low-level stuff like variables and classes right to the application level, where students can see Ruby in action. This makes sense for me, since I know most of that low-level stuff cold, but perhaps not so much for a student seeing Ruby for the first time. Fortunately, many of the ideas in Ruby are similar enough to the ones they have seen in the previous scripting languages and in other programming languages. Ruby also is pretty easy to read, as was PHP, which makes code approachable. Still, I am pushing on myself to be sure that the applications I show them progress in a reasonable way from simpler language features to more complex, so that students can grow in their understanding smoothly. This week, I evolved a simple diff script from Everyday Scripting with Ruby as our first example and wrote a script for finding popular pages in a server log based on Tim Bray's chapter in Beautiful Code.

I'll have to ask the students who have been all three sections if they noticed differences in how I approached the languages and what, if any, difference it made to them.

Owen is reputed to have said something like "Don't give as a programming assignment something the student could just as easily do by hand." (I am still doing penance, even though Lent ended two weeks ago.) This has been dubbed Astrachan's Law, perhaps by Nick Parlante. In the linked paper, Parlante says that showmanship is the key to the Law, that

A trivial bit of code is fine for the introductory in-lecture example, but such simplicity can take the fun out of an assignment. As jaded old programmers, it's too easy to forget the magical quality that software can have, especially when it's churning out an unimaginable result. Astrachan's Law reminds us to do a little showing off with our computation. A program with impressive output is more fun to work on.

I think of this Astrachan's Law in a particular way. First, I think that it reaches beyond showmanship: Not only do students have less fun working on trivial programs, they don't think that trivial programs are worth doing at all -- which means they may not practice enough or at all. Second, I most often think of Astrachan's Law as talking about data. When we ask students to convert Fahrenheit to Celsius, or to sum ten numbers entered at the keyboard, we waste the value of a program on something that can be done faster with a calculator or -- gasp! -- a pencil and paper. Even if students want to know the answer to our trivial assignment, they won't see a need to master Java syntax to find it. You don't have to go all the way to data-intensive computing, but we really should use data sets that matter.

Yesterday, I encountered what might be a variant or extension of Astrachan's Law.

John Zelle of Wartburg College gave a seminar for our department on how to do virtual reality "on a shoestring" -- for $2000 or less. He demonstrated some of his equipment, some of the software he and his students have written, and some of the programs written by students in his classes. His presentation impressed me immensely. The quality of the experience produced by a couple of standard projects, a couple of polarizing filters, and a dollar pair of paper 3D glasses was remarkable. On top of that, John and his students wrote much of the code driving the VR, including the VR-savvy presentation software.

Toward the end of his talk, John was saying something about the quality of the VR and student motivation. He commented that it was hard to motivate many students when it came to 3D animation and filmmaking these days because (I paraphrase) "they grow up accustomed to Pixar, and nothing we do can approach that quality". In response to another question, he said that a particular something they had done in class had been quite successful, at least in part because it was something students could not have done with off-the-shelf software.

These comments made me think about how, in the typical media computation programming course, students spend a lot of time writing code to imitate what programs such as Photoshop and Audacity do. To me, this seems empowering: the idea that a freshman can write code for a common Photoshop filter in a few lines of Java or Python, at passable quality, tells me how powerful being able to write programs makes us.

But maybe to my students, Photoshop filters have been done, so that problem is solved and not worthy of being done again. Like so much of computing, such programs are so much a part of the background noise of their lives that learning how to make them work is as appealing to them as making a ball-point pen is to people of my age. I'd hope that some CS-leaning students do want to learn such trivialities, on the way to learning more and pushing the boundaries, but there may not be enough folks of that bent any more.

On only one day's thought, this is merely a conjecture in search of supporting evidence. I'd love to here what you think, whether pro, con, or other.

I do have some anecdotal experience that is consistent in part with my conjecture, in the world of 2D graphics. When we first started teaching Java in a third-semester object-oriented programming course, some of the faculty were excited by what we could do graphically in that course. It was so much more interesting than some of our other courses! But many students yawned. Even back in 1997 or 1998, college students came to us having experienced graphics much cooler than what they could do in a first Java course. Over time, fewer and fewer students found the examples knock-out compelling; the graphics became just another example.

If this holds, I suppose that we might view it as a new law, but it seems to me a natural extension of Astrachan's Law, a corollary, if you will, that applies the basic idea into the realm of application, rather than data.

My working title for this conjecture is the Pixar Effect, from the Zelle comment that crystallized it in my mind. However, I am open to someone else dubbing it the Wallingford Conjecture or the Wallingford Corollary. My humility is at battle with my ego.

Is anybody home? After a flurry of writing from SIGCSE, I returned home to family time and plenty of work at the office. The result has been one entry in ten days. I look forward to finishing up my SIGCSE reports, but they appear to lie forward a bit, as the next week or so are busy. I have a few new topics in the hopper waiting for a few minutes to write as well.

One bit of good news is that part of my busy-ness this week and next is launching the third iteration of my language topics course. We've done bash and PHP and are now moving on to Ruby, one of my favorite languages. Shell scripting is great, but its tools are too limited to make writing bigger programs fun. PHP was better than I expected, but in the end it is really about building web sites, not writing more general programs. (And after a few weeks of using the language, PHP's warts started to grate on me.)

Ruby is... sublime. It isn't perfect, of course, but even its idiosyncrasies seem to get out of my way when I am deep in code. I looked up the definition of 'sublime', as I sometimes do when I use a word which is outside my daily working vocabulary or is misused enough in conversation that I worry about misusing it myself. The first set of definitions have a subtlety reminiscent of Ruby. To "vaporize and then condense right back again" sounds just like Ruby getting out of my way, only for me to find that I've just written a substantial program in a few lines. (My favorite, though, is "well-meaning ineptitude that rises to empyreal absurdity"!)

This is my first time to teach Ruby formally in a course. I hope to use this new course beginning as a prompt to write a few entries on Ruby and what teaching it is like.

There are many wonderful resources for learning about and programming in Ruby. I've suggested that my students use the pickaxe book as a primary reference, even if they use the first edition, a complete version of which is available on-line. In today's class, though, I used a simple evolutionary example from Brian Marick's book Everyday Scripting with Ruby. I hesitated to use this book as the student's primary source because it was originally written for tester's without any programming background, and my course is for upper-division CS majors with several languages under their belts. But Brian works through several examples in a way that I find compelling, and I think I can base a few solid sessions on one or two of them.

This book makes me wonder how easy it would be to re-target a book from an audience like non-programming testers to an audience of scripting-savvy programmers who want to learn Ruby's particular yumminess. I know that in the course of writing the book Brian generalized his target audience from testers to the union of three different audiences (testers, business analysts, and programmers). Maybe after I've lived with the book and an audience of student programmers I'll have a better sense of how well the re-targeting worked. If it works for my class, then I'll be inclined to adopt it for the next offering of this course.

Anyway, today we evolved a script for diffing to directories of files for a tester. I liked the flow of development and the simple script that resulted. Now we will move on to explore language features and their use in greater depth. One example I hope to work through soon, perhaps in conjunction with Ruby's regular expressions, is "Finding Things", Tim Bray's chapter in Beautiful Code.

Oh, and I must say that this is the first time that one of my courses has a theme song -- and a fine theme song, indeed. Now, if only someone would create a new programming language called "Angie", I would be in heaven.

An article in the March 2008 issue of Computing Research News describes a relatively new partnership among NSF, Google, and IBM to help the academic computing "explore innovative research and education ideas in data-intensive computing". They define data-intensive computing a new paradigm in which the size of the data dominates all other performance features. Google's database of the web is one example, but so are terabytes and petabytes of scientific data collected from satellites and earth-bound sensors. On the hardware side of the equation, we need to understand better how to assemble clusters of computers to operate on the data and how to network them effectively. Just as important is the need to develop programming abstractions, languages, and tools that are powerful enough so that we mortals can grasp and solve problems at this massive scale. Google's Map-Reduce algorithm (an idea adapted from the functional programming world) is just a start in this direction.

This notion of data-intensive computing came up in two of the plenary addresses at the recent SIGCSE conference. Not surprisingly, one was the talk by Google's Marissa Mayer, who encouraged CS educators to think about how we can help our students prepare to work within this paradigm. The second was the banquet address by Ed Lazowska, the chair of Washington's Computer Science department. Lazowska's focus was more on the need for research into the hardware and software issues that undergird computing on massive data sets. (My notes on Lazowska's talk are still in the works.)

This recurring theme is one of the reasons that our Hot Topic group at ChiliPLoP began its work on the assembly and preparation of large data sets for use in early programming courses. What counts as "large" for a freshman surely differs from what counts as "large" for Google, but we can certainly begin to develop a sense of scale in our students' minds as they write code and see the consequences of their algorithms and implementations. Students already experience large data in their lives, with 160 GB video iPods in their pockets. Having them compute on such large sets should be a natural step.

The Computing Research News also has an announcement of a meeting of the Big-Data Computing Study Group, which is holding a one-day Data-Intensive Computing Symposium today in Sunnyvale. I don't know how much of this symposium will report new research results and how much will share background among the players, in order to forge working relationships. I hope that someone writes up the results of the symposium for the rest of us...

Though our ChiliPLoP group ended up working on a different project this year, I expect that several of us will continue with the idea, and it may even be a theme for us at a future ChiliPLoP. The project that we worked on instead -- designing a radically different undergraduate computer science degree program -- has some currency, though, too. In this same issue of the CRN, CRA board chair Dan Reed talks about the importance of innovation in computing and computing education:

As we debate the possible effects of an economic downturn, it is even more important that we articulate -- clearly and forcefully -- the importance of computing innovation and education as economic engines.

[... T]he CRA has created a new computing education committee ... whose charge is to think broadly about the future of computing education. We cannot continue the infinite addition of layers to the computing curriculum onion that was defined in the 1970s. I believe we need to rethink some of our fundamental assumptions about computing education approaches and content.

Rethink fundamental assumptions and start from a fresh point of view is just what we proposed. We'll have to share our work with Reed and the CRA.

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

The second day of the conference opened with the keynote address by Google's VP of Search Products and User Experience, Marissa Mayer. She was one of the early hires as the company expanded beyond the founders, and from her talk it's clear that she has been involved with a lot of different products in her time there. She is also something the discipline of computer science could use more of, a young woman in a highly-visible technical and leadership and roles. Mayer is a great ambassador for CS as it seeks to expand the number of female high-school and college students.

This talk was called Innovation, Design, and Simplicity at Google and illustrated some of the ways that Google encourages creativity in its employees and gets leverage from their ideas and energy. I'll drop some of her themes into this report, though I imagine that the stories I relate in between may not always sync up. Such is the price of a fast-moving talk and five days of receding memory.

Creativity loves constraint.

I have written on this topic a few times, notably in the context of patterns, and it is a mantra for Google, whose home page remains among the least adorned on the web. Mayer said that she likes to protect its minimalist feel even when others would like to jazz it up. The constraints of a simple page force the company to be more creative in how it presents results. I suspect it also played a role in Google developing its cute practice of customizing the company logo in honor of holidays and other special events. Mayer said that minimalism may be a guide now, but it was not necessarily a reason for simplicity in the beginning. Co-founder Sergey Brin created the first Google home page, and he famously said, "I don't do HTML."

Mayer has a strong background both in CS and in CS education, having worked with the undergrad education folks at Stanford as a TA while an undergrad. (She said that it was Eric Roberts who first recommended Google to her, though at the time he could not remember the company's name!) One of her first acts as an employee was to run a user study on doing search from the Google homepage. She said that when users first sat down and brought up the page, they just sat there. And sat there. They were "waiting for the rest of it"! Already, users of the web were already accustomed to fancy pages and lots of graphics and text. She said Google added its copyright tag line at the bottom of the page to serve as punctutation, to tell the user that that's all there was.

Search is a fixed focus at Google, not a fancy user interface. Having a simple UI helps to harness the company's creativity.

Work on big problems, things users do every day.

Work on things that are easy to explain and understand.

Mayer described in some detail the path that a user's query follows from her browser to Google and back again with search results. Much of that story was as expected, though I was surprised by the fact that there are load balancers to balance the load on the load balancers that hand off queries to processors! Though I might have thought that another level of indirection would slow the process it down, indeed it is necessary in order to ensure that the system doesn't slow down. Even with the web server and the ad server and the mixers, users generally see their results in about 0.2 seconds. How is that for a real-time constraint to encourage technical creativity?

Search is the #2 task performed on the web. E-mail is (still) #1. Though some talking heads have begun to say that search is a mature business in need of consolidation, Google believes that search is just getting started. We know so little about how to do it well, how to meet the user's needs, and how to uncover untapped needs. Mayer mentioned a problem familiar to this old AI guy: determining the meaning of the words used in a query so that they can serve pages that match the user's conceptual intent. She used a nice example that I'll probably borrow the next time I teac