Knowing and Doing

... an author never does more damage to his readers
than when he hides a difficulty.
-- Évariste Galois

Like many of the aphorisms we quote for guidance, this one is true, but not quite true if taken with the wrong sense of its words or at the wrong scale.

First, there are different senses of the word "difficulty". Some difficulties are incidental, and some are essential. An author should indeed hide incidental difficulties; they only get in the way. However, the author must not hide essential difficulty. Part of the author's job is to help the readers overcome the difficulty.

Second, we need to consider the scale of revelation and hiding. Authors who expose difficulties too soon only confuse their readers. Part of the author's job is to prepare the reader, to explain, inspire, and lead readers from their initial state into a state where they are ready to face the difficulty. At that moment, the author is ready to bring the difficulty out into the open. The readers are ready.

What if the reader has already uncovered the difficulty before meeting the author? In that time, the author must not try to hide it, to fool his readers. He must attack it head on -- perhaps with the same deliberation in explaining, inspiring, and leading, but without artifice. It is this sense in which Galois has nailed a universal truth.

If we replace "author" with "teacher" in this discussion we still have truths. The teacher's job is to eliminate incidental difficulties while exposing essential ones. Yet the teacher must be deliberate, too, and prepare the reader, the student, to overcome the difficulty. Indeed, a large part of the teacher's craft is the judicious use of simplification and unfolding, leading students to a deeper understanding.

Sometimes, we teachers can use difficulty to our advantage. As I discussed recently, the brain often learns best when it it encounters its own limitations. Some say that is the only way we learn, but I don't think I believe the notion when taken to this extreme. But I think that difficulty is often the teacher's best source of leverage. Confront students with difficulty, and then help them to find resolution.

Ben Blum-Smith expresses a similar viewpoint in his recent nugget on teaching students to do proofs in mathematics. He launches his essay with remarks by Paul Lockhart, whose essay I discussed last summer. Blum-Smith's teaching nugget is this:

The impulse toward rigorous proof comes about when your intuition fails you. If your intuition is never given a chance to fail you, it's hard to see the point of proof.

This is just as true for us as we learn to create programs as it is when we learn to create proofs. If our intuition and our current toolbox never fail us, it's hard to see the point of learning a new tool -- especially one that is difficult to learn.

Blum-Smith then quotes Lockhart:

Rigorous formal proof only becomes important when there is a crisis -- when you discover that your imaginary objects behave in a counterintuitive way; when there is a paradox of some kind.

This quote doesn't inspire cool thoughts in me the way so many other passages in Lockhart's paper do, but one word stands way out on this reading: crisis. It inspires Blum-Smith as well:

... what happens is that when kids reach a point in their mathematical education where they are asked to prove things, they find

• that they have no idea how to accomplish what is being asked of them, and
• that they don't really get why they're being asked to do it in the first place.

The way out of this is to give them a crisis. We need to give them problems where the obvious pattern is not the real pattern. What you see is not the whole story! Then, there is a reason to prove something.

We need to give our programming students problems in which the obvious solution, the solution that flows naturally from their fingers onto the keyboards, doesn't feel right, or maybe even doesn't work at all. There is more to the story; there is reason to learn something new.

Teachers who know a lot and can present useful knowledge to students can be quite successful, and every teacher really needs to be able to play this role sometime. But that is not enough, especially in a world where increasingly knowledge is a plentiful commodity. Great teachers have to know how to create in the minds of their students a crisis: a circumstance in which they doubt what they know just enough to spur the hard work needed to learn.

A good writer can do this in print, but I think that this is a competitive advantage available to classroom teachers: they operate in a more visceral environment, in which one can create safe and reliably effective crises in their students minds. If face-to-face university courses with domain experts are to thrive in the new, connected world, it will be because they are able to exploit this advantage.

~~~~

Postscript: Galois, the mathematician quoted at the top of this article, was born on October 25. That was the date of one of my latest confrontations with difficulty. Let me assure you: You can run, but you cannot hide!

A couple of weeks back, Brian Foote tweeted:

Ward Cunningham: Pure Knowledge arbitrageurs will no longer gain by hoarding as knowledge increasingly becomes a plentiful commodity #oopsla

This reminds me of a "quought" of the day that I read a couple of years ago. Paraphrased, it asked marketers: What will you do when all of your competitors know all of the same things you do? Ward's message broadens the implication from marketers to any playing field on which knowledge drives success. If everyone has access to the same knowledge, how do you distinguish yourself? Your product? The future looks a bit more imposing when no one starts with any particular advantage in knowledge.

Ward's own contributions to the world -- the wiki and extreme programming among them -- give us a hint as to what this new future might look like. Hoarding is not the answer. Sharing and building together might be.

The history of the internet and the web tells us at the result of collaboration and open knowledge may well be a net win for all of us over a world in which knowledge is hoarded and exploited for gain in controlled bursts.

Part of the ideal of the academy has always been the creation and sharing of knowledge. But increasingly its business model has been exposed as depending on the sort of knowledge arbitrage that Ward warns against. Universities now compete in a world of knowledge more plentiful and open than ever before. What can they do when all of their customers have access to much of the same knowledge that they hope to disseminate? Taking a cue from Ward, universities probably need to be thinking hard about how they share knowledge, how they help students, professors, and industry build knowledge together, and how they add value in their unique way through academic inquiry.

Yesterday I introduced refactoring in my software engineering course. Near the beginning of my code demo, I got sidetracked a bit when I mentioned that I would be using JUnit to run some automated tests. We have not talked about testing yet, automated or otherwise, and I thought that refactoring might be a good way to show its value.

One student wondered why he should go to the trouble; why not just write a few lines of code to do his own testing? My initial response turned too quickly to the idea of automation, which seemed natural given the context of refactoring. Automating tests is essential when we are working in a tight cycle of code-test-refactor-test. This wasn't all that persuasive to the student, who had not seen us refactor yet. Fortunately, another student, who has used testing frameworks at work, jumped in to point out the real flaw in what the first student had proposed: interspersing test code and production code. I think that was more persuasive to the class, and we moved on.

That got me to thinking about a different way to introduce both testing frameworks and refactoring next time. The key pedagogical idea is to focus on students' current experience and why they need something new. Necessity gives birth not only to invention but also to the desire to learn.

Somedays, I think the web is magic. This popped into newsfeed when I refreshed this morning:

whenever possible, introduce new skills and new knowledge as the solution to the limitations of old skills and old knowledge

Meyer, who teaches HS math, has a couple of images contrasting the typical approach to lesson planning (introduce concept, pay "brief homage to workers who use it", work sample problems) to an approach based on the limitations of old skills:

1. summarize briefly relevant prior skills
2. show a "sample problem that renders those skills pretty well useless"
3. describe the new skill

I like to teach design patterns using a more active version of this approach:

1. give the students a problem to solve, preferably one that looks like a good fit for their current skill set
2. as a group, explore the weaknesses in their solutions or the difficulties they had creating them
3. introduce a pattern that balances the forces in this problem, and the discuss the more general context in which it applies

I need to remember to use this strategy with more of the new skills and techniques. It's hard to do this in the small for all techniques, but when I can tie the new idea to an error students make or a difficulty they have, I usually have better success. (My favorite success story with this approach was helping students to learn selection patterns -- ways to use if statements -- in CS1 back in the mid-1990s.)

I know all about the idea of "writing to learn". It is one of the most valuable aspects of this blog for me. When I first got into academia, though, I was surprised to find how many books in the software world are written by people who are far from experts on the topic. Over the years, I have met several serial authors who pick a topic in conjunction with their publishers and go. Some of these folks write books that are successful and useful to people. Still the idea has always seemed odd.

In the last few months, I've seen several articles in which authors talk about how they set out to write a book on a topic they didn't know well or even much at all. Last summer, Alex Payne wrote this about writing the tapir book:

I took on the book in part to develop a mastery of Scala, and I've looked forward to learning something new every time I sit down to write, week after week. Though I understand more of the language than I did when I started, I still don't feel that I'm on the level of folks like David Pollak, Jorge Ortiz, Daniel Spiewak, and the rest of the Scala gurus who dove into the language well before Dean or I. Still, it's been an incredible learning experience ...

Then today I ran across Noel Rappin's essay about PragProWriMo:

I'm also completely confident in this statement -- if you are willing to learn new things, and learn them quickly, you don't need to be the lead maintainer and overlord to write a good technical book on a topic. (Though it does help tremendously to have a trusted super-expert as a technical reference.)

Pick something that you are genuinely curious about and that you want to understand really, really well. It's painful to write even a chapter about something that doesn't interest you.

This kind of writing to learn is still not a part of my mentality. I've certainly chosen to teach courses in order to learn -- to have to learn -- something I want to know, or know better. For example, I didn't know any PHP to speak of, so I gladly took on a 5-week course introducing PHP as a scripting language. But I have a respect for books, perhaps even a reverence, that makes the idea of publishing one on a subject I am not expert in unpalatable. I have to much respect for the people who might read it to waste their time.

I'm coming to learn that this probably places an unnecessary limit on myself. Articles like Payne's and Rappin's remind me that I can study something and become expert enough to write a book that is useful to others. Maybe it's time to set out on that path.

Getting people to take this step is one good reason to heed the call of Pragmatic Programmers Writing Month (PragProWriMo), which is patterned after the more generic NaNoWriMo (NaNoWriMo). Writing is like anything else: we can develop a habit that helps us to produce material regularly, which is a first and necessary step to ever producing good material regularly. And if research results on forming habits is right, we probably need a couple of months of daily repetitions to form a habit we can rely on.

So, whether it's a book or blog you have in mind, get to writing.

(Oh, and you really should click through the link in Rappin's essay to Merlin Mann's Making the Clackity Noise for a provocative -- if salty -- essay on why you should write. From there, follow the link to Buffering, where you will find a video of drummer Sonny Payne playing an extended solo for Count Basie's orchestra. It is simply remarkable.)

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

But I never did.

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

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

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

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

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

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

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

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

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

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

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

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

After my long run yesterday, I was both sorer and more tired ('tireder'?) than after last Sunday's big week and fast long run. Why? I cut my mileage last week from 48 miles to 38, and my long run from 22 miles to 14. I pushed hard only during Wednesday's track workout. Shouldn't last week have felt easy, and shouldn't I be feeling relatively rested after an easy long run yesterday?

No, I shouldn't. The expectation I should is a mental illusion that running long ago taught me was an impostor. It's hard to predict how I will feel on any day, especially during training, but the best predictor isn't what I did this week, but last; not today, but yesterday.

Intellectually, this should not surprise us. The whole reason we train today is to be better -- faster, strong, more durable -- tomorrow. My reading of the running literature says that it takes seven to ten days for the body to integrate the effects of a specific workout. It makes sense that the workout can be affecting our body in all sorts of ways during that period.

This is good example of how running teaches us a lesson that is true in all parts of life:

We are what and who are we are today because of what we did yesterday.

This is true of athletic training. It is true of learning and practice more generally. What we practice is what we become.

More remarkable than that this true in my running is that I can know and write about habit of mind as an intellectual idea without making an immediate connection to my running. I often find in writing this blog that I come back around on the same ideas, sometimes in a slightly different form and sometimes in much the same form as before. My mind seems to need that repetition before it can internalize these truths as universal.

When I say that I am living with yesterday, I am not saying that I can live anywhere but in this moment. That is all I have, really. But it is wise to be mindful that tomorrow will find me a product of what I do today.

Alfred Thompson says that we should beware boring the smart kids in our classes, as part of a wider discussion about losing potential CS majors because of what they experience in CS1. I agree with many people that we need to work hard to bore neither our brightest students nor our average students. And it is hard work, indeed. It's hard enough sometimes even when we have only one of these groups of students in class, say, when we teach an honors section.

However, what struck me most as I read through several blog entries and comments in this conversation was this:

It is sad that we have created an educational system in which it's possible to think that this is a legitimate choice: risk losing great students OR risk losing average students.

We have created a system of schools and universities that are organized more for administrative convenience and high throughput than for learning. Actually, our system dates to a time when schools and classes were smaller, and it just doesn't scale very well as either grows.

Our regimented curricula and university systems are the real problem, not the teachers or the students.

While prepping for my software engineering course last summer, I was re-reading some old articles by Philip Greenspun on teaching, especially an SE course focused on building on-line communities. One of the talks he gives is called Online Communities. This talk builds on the notion that "online communities are at the heart" of most successful applications of the Internet". Writing in 2006, he cites amazon.com, AOL, and eBay as examples, and the three years since have only strengthened his case. MySpace seems to have passed its peak yet remains an active community. I sit hear connected with friends from grade school who have been flocking to Facebook in droves, and Twitter is now one of my primary sources for links to valuable professional articles and commentary.

As a university professor, the next two bullets in his outline evoke both sadness and hope:

• the mournful history of applying technology to education: amplifying existing teachers
• the beauty of online communities: expanding the number of teachers

Perhaps we existing faculty are limited by our background, education, or circumstances. Perhaps we simply choose the more comfortable path of doing what has been done in the past. Even those of us invested in doing things differently sometimes feel like strangers in a strange land.

The great hope of the internet and the web is that it lets many people teach who otherwise wouldn't have a convenient way to reach a mass audience except by textbooks. This is a threat to existing institutions but also perhaps an open door on a better world for all of us.

... AKA Test-Driven X: Teaching

Writing a test before writing code provides a wonderful level of accountability to self and world. The test helps me know what code to write and when we are done. I am often weak and like being able to keep myself honest. Tests also enable me to tell my colleagues and my boss.

These days, I usually think in test-first terms whenever I am creating something. More and more finding myself wondering whether a test-driven approach might work even better. In a recent blog entry, Ron Jeffries asked for analogues of test-driven development outside the software world. My first thought was, what can't be done test-first or even test-driven? Jeffries is, in many ways, better grounded than I am, so rather than talk about accountability, he writes about clarity and concreteness as virtues of TDD. Clarity, concreteness, and accountability seem like good features to build into most processes that create useful artifacts.

I once wrote about student outcomes assessment as a source of accountability and continuous feedback in the university. I quoted Ward Cunningham at the top of that entry, " It's all talk until the tests run.", to suggest to myself a connection to test-first and test-driven development.

Tests are often used to measure student outcomes from courses that we teach at all levels of education. Many people worry about placing too much emphasis on a specific test as a way to evaluate student learning. Among other things, they worry about "teaching to the test". The implication is that we will focus all of our instruction and learning efforts on that test and miss out on genuine learning. Done poorly, teaching to the test limits learning in the way people worry it will. But we can make a similar mistake when using tests to drive our programming, by never generalizing our code beyond a specific set of input values. We don't want to do that in TDD, and we don't want to do that when teaching. The point of the test is to hold us accountable: Can our students actually do what we claim to teach them?

Before the student learning outcomes craze, the common syllabus was the closest thing most departments had to a set of tests for a course. The department could enumerate a set of topics and maybe even a set of skills expected of the course. Faculty new to the course could learn a lot about what to teach by studying the syllabus. Many departments create common final exams for courses with many students spread across many sections and many instructors. The common final isn't exactly like our software tests, though. An instructor may well have done a great job teaching the course, but students have to invest time and energy to pass the test. Conversely, students may well work hard to make sense of what they are taught in class, but the instructor may have done a poor or incomplete job of covering the assigned topics.

I thought a lot about TDD as I was designing what is for me a new course this semester, Software Engineering. My department does not have common syllabi for courses (yet), so I worked from a big binder of material given to me by the person who has taught the course for the last few years. The material was quite useful, but it stopped short of enumerating the specific outcomes of the course as it has been taught. Besides, I wanted to put my stamp on the course, too... I thought about what the outcomes should be and how I might help students reach them. I didn't get much farther than identifying a set of skills for students to begin learning and a set of tools with which they should be familiar, if not facile.

Greg Wilson has done a very nice job of designing his Software Carpentry course in the open and using user stories and other target outcomes to drive his course design. In modern parlance, my efforts in this regard can be tagged #fail. I'm not too surprised, though. For me, teaching a course the first time is more akin to an architectural spike than a first iteration. I have to scope out the neighborhood before I know how to build.

Ideally, perhaps I should have done the spike prior to this semester, but neither the world nor I are ideal. Doing the course this way doesn't work all that badly for the students, and usually no worse than taking a course that has been designed up front by someone who hasn't benefitted from the feedback of teaching the course. In the latter case, the expected outcomes and tests to know they have been met will be imperfect. I tend to be like other faculty in expecting too much from a course the first few times I teach it. If I design the new course all the way to the bottom, either the course is painful for students in expecting too much too fast, or the it is painful for me as I un-design and re-design huge portions of the course.

Ultimately, writing and running tests come back to accountability. Accountability is in short supply in many circles, university curricula included, and tests help us to have it. We owe it to our users, and we owe it to ourselves.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Today one of my students tweeted that he had started doing something new: setting aside time each to sit and think. This admirable discipline led to a Twitter exchange among students that ended with the sentiment that schools don't teach us how to think.

I'm not sure what I think about this. At one level, I know what they mean. Universities offer a lot of courses in which we expect students to be able to think already, but it's rare when courses aim specifically to teach students how to think. Similarly, we don't often teach students how to read, and in software engineering, we don't often teach students how to do analysis. We demonstrate it and hope they catch on. (Welcome to calculus!)

Some courses take aim at how to think, or at least do on paper, but they tend to be gen ed courses or courses in philosophy that most students don't take, or don't take seriously. Majors courses are the best hope for many, because there is some hope that students will care enough about their majors to want to learn to think like experts in the discipline. In CS, our freshman-level discrete structures course is a place where we purport to help students reason the way computer scientists do. In Software Engineering, I've decided the only way we can possibly learn how to build software is to do it and then analyze what happens. Again, I am not teaching students so much how to think, so much as hoping to put them in a position where they can learn.

This is one part of my attempt to start where students are. But where do we go, or try to go, from there?

That said, lots of people in education and academia spend a lot of their time thinking about how to help students learn to think. Last month, I saved a link to a post at Dangerously Irrelevant on Education and Learning to Think. That post assumes that one goal of education is "higher-order thinking" -- thinking about thinking so that we can learn to do it better. It lists a number of features of higher-order thinking, goals for our students and thus for our courses. The list looks awfully attractive to me right now, because my current teaching assignment aims to prepare prospective software developers to work as professionals, and these are precisely the sorts of skills we would like for them to have before they graduate. Systems analysis and requirements gathering are all about imposing meaning, finding structure in apparent disorder. Building software involves uncertainty. Not everything that bears on the task at hand is known. Judgment and self-regulation are essential skills of the professional, but much of our students' previous fourteen or fifteen years of education have taught them not to self-regulate, if only by giving them so few opportunities to do so. When faced with it for the first time, they tend to balk. Should we be surprised?

There are other possible thinking outcomes we might aim for. A while back, I wrote about a particular HS teacher's experience as a summer CS student in Teaching Is Hard. Mark Guzdial also wrote about that teacher's blog entries, and Alan Kay left a comment on Mark's blog. Alan suggested that one of the key traits that we must help students develop is skepticism. This is one of the defining traits of the scientist, who must question what she sees and hears, run experiments to test ideas, and gather evidence to support claims. One of the great lessons of the Enlightenment is that we all can and should think and act like scientists, even when we aren't "doing science". The methods of science are the most reliable way for us to understand the world in which we live. Skepticism and experiment are the best ways to improve how we think and act.

There is more. People such as Richard Gabriel and Paul Graham tell us that education should help us develop taste. This is one of the defining traits of the maker. Just as all people should be able to think and act like scientists, so should all people be able to think and act creators. This is how we shape the world in which we live. Alan Kay talks about taste, too, in other writings and would surely find much to agree with in Gabriel's and Graham's work.

All this adds up to a pretty tall order for our schools and universities, for our apprenticeships and our workplaces. I don't think it's too much of a cop-out to say that one of the best ways to learn all of these higher-order skills is to do -- act like scientists, act like creators -- and then reflect on what happens.

If this were not enough, the post at Dangerously Irrelevant linked to above closes a quote that sets up one last hurdle for students and teachers alike:

It is a new challenge to develop educational programs that assume that all individuals, not just an elite, can become competent thinkers.

100% may be beyond our reach, but in general I start from this assumption. Like I said, teaching is hard. So is learning to think.

Greg Wilson wrote a nice piece recently on the big picture for his Software Carpentry course. His first paragraph captures an idea that is key to the notion of "programming for all" that I and others have been talking about lately:

One of the lessons we learned ... is that most scientists don't actually want to learn how to program--they want solve scientific problems. To many, programming is a tax they have to pay in order to do their research. To the rest, it's something they really would find interesting, but they have a grant deadline coming up and a paper to finish.

Most people don't care about programming. If they do care, they don't like it, or think they don't. They want to do something. Programming has to be a compelling tool, something that makes their lives better as they do the thing they like to do. If it changes how they think about problems and solutions, all the better. When we teach programming to people who are non-CS types, we should present it as such: a compelling tool that makes their lives better. If we teach programming qua programming, we will lose them before we have a chance to make a difference for them.

It turns out that all this is true of CS students, too. Most of them want to do something. And several of the lessons Wilson describes for working with scientists learning to program apply to CS students, such as:

• When students have never experienced the pain of working with big or long-lived programs that benefit from good abstractions, effective interfaces, and tools such as version control systems, "no amount of handwaving is going to get the idea across".
• The best way to reach students is to give them programming skills that will pay off for them in the short term. This motivates better than deferred benefit and encourages them to dig in deeper on their own. That's where the best learning happens anyway.
• Students are often surprised when a course is able to "convey the fundamental ideas needed to make sensible decisions about software without explicitly appearing to do so".

This issue is close to the surface for me as I work on my work on my software engineering course. Undergraduate courses don't usually expose students to the kind of software development projects that are likely to give the right context for learning many of the "big picture" ideas. An in-course project can help, but contemporaneous experience often runs out of sync with the software engineering content of the course. Next semester, they will take a project course in which they can apply what they learn in this course, but little good that does us now!

(Idea for later: Why not teach the project course first and follow with course that teaches techniques that depend on the experience?)

Fortunately, most students trust their professors and give them some leeway when learning skills that are beyond their experience to really grok -- especially when the skills and ideas are a known part of the milieu in which they will work.

Software Engineering this semester offers another complication. There is a wide spread in the level of software and programming experience between the most and least experienced students in the course. What appeals to students at one end of the spectrum often won't appeal students on the other. More fun for the professor...

In closing, I note that many of specific ideas from Wilson's course and Udell's conception of computational thinking apply to a good Software Engineering course for majors. (Several of Wilson's extensions to the body of CT apply less well, in part because they are part of other courses in the CS curriculum and in part because they go beyond the CT that every person probably needs.) I should not be surprised that these basic ideas apply. Wilson is teaching a form of software engineering aimed at a specific audience of developers, and computational thinking is really just a distillation of what all CS students should be learning throughout their undergraduate careers!

A few days ago, I tweeted:

Everything looks worse in black and white.
Including course designs.

It is easy to have fantasies about a new course in the bloom of summer. There are no constraints. I am perfect. My students are perfect. Campus life is perfect. The course is... perfect.

It's important to stop dreaming. But I have never been good at mapping out a new course in its entirety. Beforehand, I'm still learning what I want to say and how to say it. I still need to learn if how I want to say what I think I need to say will work. The best way for me to go is to start teaching.

Before the course starts, I run my own version of the Planning Game. This helps me to develop a high-level picture of the topics I think are essential to cover and the activities I think are essential for students to do. The result is something akin to a System Metaphor and a set of user stories. I prioritize the topics and select the topics that should come at the beginning of the course. This is akin to Release Planning and prepares me for my first release, which is a one-or two-session unit.

Then I implement. Teaching the first week grounds all that thinking I've been doing in reality. The act of meeting the first session, seeing the students, and interacting with them helps me to commit to certain courses of action and gives me a basis for making other decisions as we go along. Initial feedback to a simple survey helps me to prioritize topics.

With a new prep, especially a course outside my usual teaching range, agile course development is even more important for me. Feedback and adaptation are about the only way I can feel confident that the course has a chance to succeed.

While at Agile 2009, I think, Brian Marick tweeted:

1/2: Agile often requires greybeards to admit how much snotty-nosed 20-year-olds have to teach them.

This is true of the agile community, and so it is true for me to the extent that I engage in agile. It is also true of teaching at a university, so it is true for me on another dimension, too. Finding the boundary between where the professor needs to lead where the students need to lead is the key.

One bit of good news from my first week in class. I have reason to believe that this group of students is willing to participate in the daily business of class and, I suspect, in leading when they can and should. That almost always leads to a better course for them, and a better course -- and experience -- for me.

Thinking about teaching software engineering is going to be interesting. I love to make software, and I love to think about it. Now that is more a part of my day job. There is an extra trade-off to make: spending time explicitly preparing for class versus spending time blogging about what I'm thinking along the way!

In my previous entry, I talked about how hard teaching is. When you consider everything -- from the human psychology to human communication, from differences in student background to differences in student temperament, from home life to campus life, oh yeah, and course content -- students and teachers face a big challenge. That's why I liked the pair of Lost in Syntax articles so much. They remind teachers about all of the other things students face. Even people who teach face these challenges when they become students.

Mark Guzdial also blogged after reading "Lost in Syntax". He focused on the source of a particular disconnect that students and teachers may experience in the classroom: what the course content means. Some students want to build things, and for them meaning comes down to a set of practical skills and a set of engineering practices. Some students want to explore, and for them meaning comes down to a different set of practical skills and a way of thinking about questions and experiments. When the instructor of a course adopts one of these stances and uses its language, she connects well with one group of students and often leaves the other group confused and disoriented.

Some people, even a certain kind of university prof, think all this talk of meaning is falderol. You take a course, you learn the content, and you move on. That attitude ignores reality. Even when all the things Wicked Teacher talks about go right, people learn best when they are motivated. And people are most motivated when they know why they are learning what they are learning, and when that "why?" fits the meaning they seek.

The best teachers start (or try to) with what a course means for students and build the learning experience from there. They also start with what the students already know, or think they know, about the course material. By using the students as the baseline for the course, instructors are more able to motivate students and more likely to engage them in a way that creates real learning. When we use the abstractions of our discipline or our own interests as the baseline, we may well teach a course that excites us, but it will often fail to teach students much of anything.

Good teachers start with what a course means for students, but they don't stop there. The teacher's job is to lead students forward, to help students see bigger ideas than they can initially conceive. Even at the level of practical skills and tools, we need to draw students forward to skills and tools they don't yet appreciate when they first enter the class. Starting with what students know and care about is the way that we build the foundation -- and the trust -- they need to learn beyond their imagination. That's what education is.

This is a tall order for any teacher and why I called my previous entry "Teaching is Hard". It is a whole lot easier to build a course atop the discipline's abstractions or one's own interests than to try to understand the students' minds. Even even when we try to start with the students, it is not an easy task.

Some people say that starting anywhere but the intellectual foundation for the discipline is pandering to the students. But starting with student interests and motivations is not pandering at all -- unless we stop there.

Earlier this summer, Wicked Teacher of the West attended a week-long professional development workshop and wrote a two-part reflection on her experience, called "Lost in syntax" [ part 1 | part 2 ]. I have written occasionally here about how useful it is for me as a teacher to be in the learner's shoes every so often in such areas as piano, running, and starting over. Those experiences are analogs, but they require a mapping onto learning computer science. I found Wicked Teacher's reflections especially helpful because she was in the classroom learning CS. I recognize a lot of the symptoms she describes from my students' behaviors in the past. She even captures her bad feelings in a series of object lessons for us teachers.

Great. All I need to do design my course so that it does the right things (such as explaining the big picture) and avoids the obvious pitfalls (such as giving compliments that can be interpreted as indicators of inability), and then watch for signs of problems that are outside my control (such as trouble at home or an unwillingness to ask questions). Simple enough, right?

Right. Much of this is easy in the abstract, but when you get into the rush of the semester, with other courses and other duties tugging at you, a room full of students all in different places, and lots of material to cover in too little time -- well, it suddenly feels a lot harder. Last year, I found myself in the middle of a tough semester and didn't recognize quickly enough that students were not asking questions when they didn't understand. When I am slow to recognize a situation, I am slow to respond. When I am slow to respond, I sometimes miss opportunities to address the issue. Sometimes, I run out of time.

It's a wonder that most teachers don't have the same persistent sense of dread that is expressed in these articles' subtitles: "OMG I'm going to cry in front of all these people".

Still, reflecting in this way -- and reading other peoples' reflections from similar experiences -- is immensely valuable. Simply keeping these lessons in mind over the course of a semester, especially when particular troubles arise, is a good first step toward addressing them in a meaningful way. A little empathy and a little conscious course design can go a long way. The rest is largely a matter of staying alert. I cannot fix every problem or even recognize them all, but paying attention and getting feedback frequently can help me do as well as I can.

I think it is valuable for students to read essays such as Wicked Teacher's. Ultimately, learning is in their hands, and if they can recognize the things that they do which interfere with their own learning, they will be better off. If I can give only one piece of advice from these two reflections, it would be: Ask questions. Ask plenty of questions. Ask them now. Your instructor almost surely wants you to ask. Both of you will be better off if you do.

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

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

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

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

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

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

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

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

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

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

An Addition to My News Aggregator

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

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

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

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

Learning and Doing

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

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

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

Knowing and Doing

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

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

A Poignant Convergence

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

Sometimes I fear for the students.

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

In my previous entry, I reported on some of the many helpful suggestions I received for advice to prospective students interested in web development. The original entry started with a teaser:

His indecision about careers and school is worthy of its own post; I've seen it in so many other 20- and 30-somethings who are unhappy with their first careers and not sure of where to go next.

Many advisees, traditional and non-traditional students alike, seem to want me -- or anyone, for that matter -- to tell them what to do. Which major should I choose? Which classes should I take? This can be a healthy sort of questioning. One of the roles played by university professors is that of academic advisor, in which we help students explore and develop their interests, refine their goals, and choose a path that will help them. Most of us really like this part of our jobs, and it tends to be underutilized by students.

These same questions can also indicate an unhealthy need for answers. Some students seem to want to surrender the power of choice, and the responsibility that comes with wrong choices. We do the world a huge disservice if our schools or culture create a significant number of young people so unable to control their own destiny, unwilling even to try.

In retrospect, I probably should not write a whole post on this topic. I have no expertise or special insight. Maybe what I report here is not a significant problem, merely the result of a sampling bias or a memory bias. But it feels like a pattern, and sometimes it concerns me.

The real reason I decided not to write much more on this was a response sent to me by a computer science alumnus of ours, David Schmüdde. David is not a professional computer scientist; he is a filmmaker, composer, and teacher, not to mention a blogger worth following. (I mentioned his senior project in a long-ago blog entry.) His e-mail message did not deal with the technical details of my request for advice. It was a personal essay on his experiences learning to program at my university, on studying with me, and on now teaching college students. He reminded me that interest and aptitude are not enough. Students also need confidence that they can succeed and the will to commit to the present moment. All the aptitude in the world can be diluted to nothingness by a lack of confidence or a lack of commitment.

What role does the professor play in this? They can inspire trust. As David wrote, it is really hard for people to hand over two or four years of their lives to a university, even to a program of study. They need to be able trust that what they are doing is worthwhile and has a reasonable chance of leading to happiness or some other form of success.

As much as we like to build up our departments and universities in the eyes of the world, we must remember that people do not trust schools. Not really. They trust people. Sometimes the people they trust are parents or friends or teachers from their high schools. But when committing to a course of study in college, often the people they need to trust are the faculty. The advisors they see at summer orientation. The professors they meet when they seek out more advice. The instructors they see in the classroom.

David hoped that his message would not come across as if he were lecturing me, because surely much of what he was saying must have occurred to me before. Sure, but as I write here on occasion, I often need to be reminded. In this case, I needed to be reminded that what we professors do is not just technical. Perhaps it's not even mostly technical. It's about helping people to grow. Every once in a while, it is good for me to have someone tell me to step back and look at what matters. Thanks to David for taking the time to write me a letter doing just that.

So perhaps the best thing I can do for students who seeks so much direction is to recognize their lack of confidence as natural to the human condition, work to build their trust, and then try to assure them that their efforts will bear fruit -- maybe not the fruit they expect when they start, but fruit worthy of the effort. The key is to commit to a course of action and invest one's mind in it.

What a good time to be having this conversation, with a new academic year on its way!

Thanks to everyone who responded to my call for advice on what advice I should give to a student interested in studying at the university with a goal of becoming a web developer. People interpreted the article in lots of different ways and so were able to offer suggestions in many different ways.

In general, most confirmed the gist of my advice. Learn a broad set of technical skills from the spectrum of computer science, because that prepares one to contribute to the biggest part of the web space, or study design, because that's they part the techies tend to do poorly. A couple of readers filled me in on the many different kinds of web development programs being offered by community colleges and technical institutes. We at the university could never compete in this market, at least not as a university.

Mike Holmes wrote a bit about the confusion people have about computer science, with a tip of the hat to Douglas Adams. This confusion does play a role in prospective students' indecision about pursuing CS in college. People go through phases where they think of the computer as replacing an existing technology or medium: calculator, typewriter and printing press, sketchpad, stereo, television. Most of us in computer science seem to do one of two things: latch onto the current craze, or stand aloof from the latest trend and stick with theory. The former underestimates what computing can be and do, while the latter is so general that we appear not to care about what people want or need. It is tough to balance these forces.

In some twittering around my request, Wade Arnold tweeted about the technical side of the issue:

@wallingf Learn Java for 4 years to really know one language well. Then they will pick up php, ruby, or python for domain specific speed

The claim is that by learning a single language really well, a person really learns how to program. After that, she can learn other languages and fill in the gaps, both language-wise and domain-wise. This advice runs counter to what many, many people say, myself included: students should learn lots of different languages and programming styles in order to really learn how to program. I think Wade agrees with that over the long term of a programmer's career. What's unusual in his advice is the idea that a student could or should spend all four years of undergrad study mastering one language before branching out.

A lot of CS profs will dismiss this idea out of hand; indeed, one of the constant complaints one hears in certain CS ed circles is that too many schools have "gone Java" to the exclusion of all other languages and to the lasting detriment of their students. My department's curriculum has, since before I arrived, required students to study a single language for their entire first year, in an effort to help students learn one language well enough that they learn how to program before moving on to new languages and styles. When that language was, say, Pascal, students could pretty well learn the whole language and get a lot of practice using it. C is simple enough for that purpose, I suppose, but C++, Ada, and Java aren't. If we want students to master those languages at a comparable level, we might well need four years. I think that says more about the languages we use than about students learning enough programming in a year to be ready to generalize and fill in gaps with new languages and styles.

This entry has gotten longer than I expected, yet I have more to say. I'll write more in the days to come.

Mark Guzdial recently wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I often find myself at meetings with administrator types, where I am the only person who has spent much time in a classroom teaching university students, at least recently. When talk turns to teaching, I sometimes feel like a pregnant woman at an ob-gyn convention. They may be part of a university and may even have taught a workshop or specialty course, but they don't usually know what it's like to design and teach several courses at a time, over many semesters in a row. That doesn't always stop them from having deeply-held and strong opinions about how to teach. Having been a student once isn't enough to know what it's like to teach.

I have had similar experiences as a university professor among professional software developers. All have been students and have learned something about teaching and learning from their time in school. But their lessons are usually biased by their own experiences. I was a student once, too, but that prepared me only a bit for being a teacher... There are so many different kinds of people in a classroom, so many different kinds of student. Not very many are just like me. (Thank goodness!)

Some software developers have taught. Many give half- or full-day tutorials at conferences. Others teach week-long courses on specific topics. A few have even taught a university course. Even still, I often don't feel like we are talking about the same animal when we talk about teaching. Teaching a training course for professional developers is not the same as teaching a university course to freshmen or even seniors. Teaching an upper-division or graduate seminar bears little resemblance to an elective course for juniors, let alone a class of non-majors. Even teaching such a course as an adjunct can't deliver quite the same experience as teaching a full load of courses across the spectrum of our discipline, day in and day out for a few years in a row. The principle of sustainable pace pops up in a new context.

As with administrators, lack of direct experience doesn't always stop developers from having deeply-held and strong opinions about what we instructors should be doing in the classroom. It creates an interesting dialectic.

That said, I try to learn whatever I can from the developers with whom I'm able to discuss teaching, courses, content, and curricula. One of the reasons I so enjoy PLoP, ChiliPLoP, and OOPSLA is having an opportunity to meet reflective individuals who have thought deeply about their own experiences as students and who are willing to offer advice on how I can do better. But I do try to step back from their advice and put it into the context of what it's like to teach in a real university, not one we've invented. Some ideas sound marvelous in the abstract but die a grisly death on the banks of daily university life. Revolution is easy when the battlefield is in our heads.

When it comes to working with software developers, I am more concerned that they will feel like the pregnant woman when they discuss their area of expertise with me and my university colleagues. One of my goals is not to be "that guy" when talking about software development with developers. I hope and prefer to speak out of personal and professional experience, rather than a theory I read in a book or a blog, or something another professor told me.

What we teach needs to have some connection to what developers do and what our students will need to do when they graduate. There is a lot more to a CS degree than just cutting code, but when we do talk about building software, we should be as accurate and as useful as we can be. This makes teaching a course like software engineering a bigger challenge for most CS profs than the more theoretical or foundational material such as algorithms or even programming languages.

One prescription is the same as above: I listen and try to learn whatever I can from developers when we talk about building software. Conferences like PLoP, ChiliPLoP, and OOPSLA give me opportunities I would not have otherwise, and I listen to alumni tell me about what they do -- and how -- whenever I can. I still have to sift what I learn into the context of the university, but it makes for great raw material.

Another prescription is to write code and use the tools and practices the people in industry use. Staying on top of that fast-moving game gets harder all the time. The world software is alive and changing. We professors have to keep at it. Mostly, it's a matter of us staying alive, too.

Seth Godin says:

People will not pay for by-the-book rewrites of news that belongs to all of us. People will not pay for yesterday's news, driven to our house, delivered a day late, static, without connection or comments or relevance. Why should we?

Universities may not be subject to the same threats as newspapers, due in some measure to

• their ability to aggregate intellectual capital and research capacity,
• their privileged status in so many disciplines as the granters of required credentials, and
• frankly, the lack of maturity, initiative, and discipline of their primary clientele.

But Godin's quote ought to cause a few university professors considerable uneasiness. In the many years since I began attending college as an undergrad, I have seen courses at every level and at every stop that fall under the terms of this rebuke.

In trying to understand the role patterns and pattern languages play both in developing software and in learning to develop software, I often look for different angles from which to look at patterns. I've written the idea of patterns as descriptive grammar and the idea of patterns as a source of freedom in design. Both still seem useful to me as perspectives on patterns, and the latter is among the most-read articles on my blog. The notion of patterns-as-grammar also relates closely to one of the most commonly-cited roles that patterns play for the developer or learner, that of vocabulary for describing the meaningful components of a program.

This weekend, I read Brian Hayes's instructive article on compressive sensing, The Best Bits. Hayes talks about how it is becoming possible to imagine that digital cameras and audio recorders could record compressed streams -- say, a 10-megapixel camera storing a 3MB photo directly rather than recording 30MB and then compressing it after the fact. The technique he calls compressive sensing is a beautiful application of some straightforward mathematics and a touch of algorithmic thinking. I highly recommend it.

While reading this article, though, the idea of patterns as vocabulary came to mind in a new way, triggered initially by this passage:

... every kind of signal that people find meaningful has a sparse representation in some domain. This is really just another way of saying that a meaningful signal must have some structure or regularity; it's not a mere jumble of random bits.

Programs are meaningful signals and have structure and regularity beyond the jumble of seemingly random characters at the level of the programming level. The chasm between random language stuff and high-level structure is most obvious when working with beginners. They have to learn that structure can exist and that there are tools for creating it. But I think developers face this chasm all the time, too, whenever they dive into a new language, a new library, or a new framework. Where is the structure? Knowing it is there and seeing it are too different matters.

The idea of a sparse representation is fundamental to compression. We have to find the domain in which a signal, whether image or sound, can be represented in as few bits as possible while losing little or even none of the signal's information. A pattern language of programs does the same thing for a family of programs. It operates at a level (in Hayes' terms, in a domain) at which the signal of the program can be represented sparsely. By describing Java's I/O stream library as a set of decorators on a set of concrete streams, we convey a huge amount of information in very few words. That's compression. If we say nothing else, we have a lossy compression, in that we won't be able to reconstruct the library accurately from the sparse representation. But if we use more patterns to describe the library (such as Abstract Class and "Throw, Don't Catch"), we get a representation that pretty accurately captures the structure of the library, if not the bit-by-bit code that implements it.

This struck me as a useful way to think about what patterns do for us. If you've seen other descriptions of patterns as a means for compression, I'd love to hear from you.

I recently ran across a link to a Dan Bricklin article from a few years ago, Why Johnny can't program. (I love the web!) Bricklin discusses some of the practical reasons why more people don't program. As he points out, it's not so much that people can't program as that they won't or choose not to program. Why? Because the task of writing code in a textual language isn't fun for everyone. What Bricklin calls "typed statement" programming fails all of Don Norman's principles of good design: visibility, good conceptual model, good mappings, and full and continuous feedback. Other programming models do better on these counts -- spreadsheets, rule-based expert system shells, WYSIWYG editors in which users generate HTML through direct manipulation -- and reach a wider audience. Martin Fowler recently talked about this style, calling it illustrative programming.

I had an agile moment as I read this paragraph from Bricklin about why debugging is hard:

One of the problems with "typed-statement" systems is that even though each statement has an effect, you only see the final result. It is often unclear which statement (or interaction of statements) caused a particular problem. With a "Forms" or direct manipulation system, the granularity is often such that each input change has a corresponding result change.

When we write unit tests for our code at about the same time we write the code, we improve our programming experience by creating intermediate results that help us to debug. But there's more. Writing tests helps us to construct a conceptual model of the program we are writing. They make visible the intended state of the program, and help us to map objects and functions in the code onto the behavior of the program at run-time. When we take small steps and run our tests frequently, they give us full and continuous feedback about the state of our program. Best of all, this understanding is recorded in the tests, which are themselves code!

In some ways, test-driven programming may improve on styles where we don't type statements. By writing tests, we participate actively in creating the model of our program. We are not simply passive users of someone else's constraint engine or inference engine. We construct our understanding as we construct our program.

Then again, some people don't need or want to write the reasoning component, so we need to provide access to tools they can use to be productive. Spreadsheets did that for regular folks. Scripting languages do it for programmers. Some people complain about scripting languages because they lack type safety, hide details, and are too slow. But the fact is that programmers are people, too, and they want tools that put them into a flow. They want languages that hit them in their sweet spot.

Bricklin concludes:

From all this you can see that the way a system requires an author to enter instructions into the computer affects the likelihood of acceptance by regular people. The more constrained the instructions the better. The more the instructions are clearly tied to various results the better. The more obvious and quickly the results may be examined the better.

TDD does all this, and more. It makes professional programmers more productive by providing better cognitive support for mental tasks we have to perform anyway. If we use TDD properly as we teach people to program, perhaps it can help us hit the sweet spot for more people, even in a "typed statement" environment.

Good Question

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

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

Who says kids don't pay attention?

The Age of Fire

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

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

Computer Science's Dirty Little Secret

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

I like how Matthew MacLaurin, lead developer, thinks:

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

(Emphasis added.)

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

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

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

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

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

Afterthoughts

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

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

Quoted by Harry Lewis in Excellence Without a Soul:

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

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

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

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

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

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

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

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

~~~~

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

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

I've been buried in a big project on campus for the last few months. Yesterday, we delivered our report to the president. Ah, time to breathe, heading into a holiday weekend! Of course, next week I'll get back to my regular work. Department stuff. Cleaning my desk. And thinking about teaching software engineering this fall.

A bit of side reading found via my Twitter friends has me thinking about testing, and the role it will play in the course. In the old-style software engineering course, testing is a "stage" in the "process", which betrays a waterfall view of the world even when the instructor and textbook say that they encourage iterative development. But testing usually doesn't get much attention in such courses, maybe one chapter that describes the theory of testing and a few of the kinds of testing we need to do.

It seems to me that testing can take a bigger place in the course, if only because it exemplifies the sort of empiricism that we should all engage in as software developers. When we test, we run experiments to gather evidence that our program works as specified. We should adopt a similar mindset about how we build our programs. How do we know that our design is a good one? Or that our team is functioning well? Or that we are investing enough time and energy in writing tests and refactoring our code?

That's one reason I like Joakim Karlsson's post about the principle of locality in code changes. There may be ways that he can improve his analysis, but the most important thing about this post is that he analyzed code at all. He had a question about how code edits work, so he wrote a program to ask subversion repositories for the answer. That's so much better than assuming that his own hypothesis was correct, or that conventional wisdom was.

In regard to the testing process itself, Michael Feathers wrote a piece on "canalizing" design that points out a flaw in how we usually test our code. We write tests that are independent of one another in principle but that our test engines always run in the same order. This inadvertent weakness of sequential code creates an opportunity for programmers to write code that takes advantage of the implicit relationship between tests. But it's not really an advantage at all, because we then have dependencies in our code that we may not be aware of and which should not exist at all. Feathers suggests putting the tests in a set data structure and executing them them from there. At least then the code makes explicit that there is no implied order to the tests, which reminds the programmers who modify the code later that they should not depend on the order of test execution.

(I also like this idea for its suggestion that programs can and other should be dynamic structures, not dead sequences of text. Using a set of tests also moves us a step closer to making our code work well in a parallel environment. Explicit and implicit sequencing in programs makes it hard to employ the full power of multicore systems, and we need to re-think how we structure our programs if we want to break away from purely sequential machines. The languages guy in me sees some interesting applications of this idea in how write our compilers.)

Finally, I enjoyed reading Gojko Adzic's description of Keith Braithwaite's "TDD as if you mean it" exercise. Like the programming challenges I have described, it asks developers to take an idea to its extreme to break out of habits and to learn just how the idea feels and what it can give. Using tests to drive how the writing of code is more different from what most of us do than we usually realize. This exercise can help you to see just how different -- if you have an exercise leader like Keith to keep you honest.

However, I disagree with something Keith said in response to a comment about the relationship between TDD and functional programming:

I'm firmly convinced that sincere TDD leads one towards a functional style.

TDD will drive you to the style whose language you think.

There will be functional components to your solution to support the tests, and some good OOP has a functional feel. But in my experience you can end up with very nice objects in an object-oriented program as a result of faithfully-executed TDD.

Another of Braithwaite's comments saved the day, though. He credits Allan Watts for this line that captures his intent in designing exercises like this:

I came not as a salesman but as an entertainer. I want you to enjoy these ideas because I enjoy them.

Love this! He has a scholar's heart.

There is a lot more to testing that unit tests or regression testing. Finding ways to introduce students to the full set of ideas while also giving them a visceral sense of testing in the trenches is a challenge. I have to teach enough to prepare a general audience and also prepare students who will go on to take our follow-up course, Software Testing. That's a course that undergraduates at most schools don't have the opportunity to take, a strong point of our program. But that course can't be an excuse not to do testing well in the software engineering course. It's not a backstop; it's new ballgame.

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

Factoid of the Day

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

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

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

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

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

Quote of the Day

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

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

I was floored.

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

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

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

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

Quick hits, for different values of x, of course, but also different values of "the day" I encountered them. I'm slow, and busier than I'd like.

Tweet of the Day

Courtesy of Glenn Vanderburg:

Poor programmers will move heaven and earth to do the wrong thing. Weak tools can't limit the damage they'll do.

Vanderburg is likely talking about professional programmers. I have experienced this truth when working with students. At first, it surprised me when students learning OOP would contort their code into the strangest configurations not to use the OO techniques they were learning. Why use a class? A fifty- or hundred-line method will do nicely.

Then, students learning functional programming would seek out arcane language features and workarounds found on the Internet to avoid trying out the functional patterns they had used in class. What could have been ten lines of transparent Scheme code in two mutually recursive functions became fifteen or more of the most painfully tortured C code wrapped in a thin veil of Scheme.

I've seen this phenomenon in other contexts, too, like when students take an elective course called Agile Software Development and go out of their way to do "the wrong thing". Why bother with those unit tests? We don't really need to try pair programming, so we? Refactor -- what's that?

This feature of programmers and learners has made me think harder trying to help them see the value in just trying the techniques they are supposed to learn. I don't succeed as often as I'd like.

Comic of the Day

Hammock dwellers, unite!

If only. If only. When does summer break start?

I like to solve the Celebrity Cipher in my daily paper. Each puzzle is a mixed alphabet substitution cipher on a quote by someone -- a "celebrity", loosely considered -- followed by the speaker's name, sometimes prefixed with a title or short description. Lately I've been challenging myself to solve the puzzle in my head, without writing any letters down, even once I'm sure of them. Crazy, I know, but this makes the easier puzzles more challenging now that I have gotten pretty good at solving them with pen in hand.

(Spoiler alert... If you like to do this puzzle, too, and have not yet solved the June 22 cipher, turn away now. I am about to give the the answer away!)

Yesterday I was working on a puzzle, and this was the speaker phrase:

IWHNN TOXFZRXNYHO NXKJHSSA YXOYXEBUHO

I had looked at the quote itself for a couple of minutes and so was operating on an initial hypothesis that YWH was the word the. I stared at the speaker for a while... IWHNN would be IheNN. Double letters to end the third word, which is probably the first name. N could be s, or maybe l. s... That would be the first letter of the first name.

And then I saw it, in whole cloth:

Chess grandmaster Savielly Tartakower

Please don't think less of me. I'm not a freak. Really.

How very strange. I have no special mental powers. I do have some experience solving these puzzles, of course, but this phrase is unusual both in the prefix phrase and in the obscurity of the speaker. Yes, I once played a lot of chess and did know of Tartakower, a French-Polish player of the early 20th century. But how did I see this answer?

The human brain amazes me almost every day with its ability to find, recognize, and impose patterns on the world. Practice and exposure to lots and lots of data is one of the ways it learns these patterns. That is part of how I am able to solve these ciphers most days -- experience makes patterns appear to me, unbidden by conscious thought. There may be other paths to mastery, but I know of no other reliable substitute for practice.

What about the rest of the puzzle? From the letter pairs in the speaker phrase, I was able to reconstruct the quote itself with little effort:

Victory goes to the player who makes the next-to-last mistake.

Ah, an old familiar line. If we follow this quote to its logical conclusion, it offers good advice for much of life. You never know which mistake will be the next-to-last, or the last. Keep playing to win. If you learn from your mistakes, you'll start to make fewer, which increases the probability that your opponent will make the last mistake of the game.

Even when in non-adversarial situations, or situations in which there is no obvious single adversary, this is a good mindset to have. People who embrace failure persist. They get better, but perhaps more importantly they simply survive. You have to be in the game when your opportunity comes -- or when your opponent makes the ultimate mistake.

Like so many great lines, Tartakower's is not 100% accurate in all cases. As an accomplished chessplayer, he certainly knew that the best players can lose without ever making an obvious mistake. Some of my favorite games of all time are analyzed in My Sixty Memorable Games, by Bobby Fischer himself. It includes games in which the conquered player never made the move that lost. Instead, the loser accreted small disadvantages, or drifted off theme, and suddenly the position was unfavorable. But looking back, Fischer could find no obvious improvement. Growing up, this fascinated me -- the loser had to make a mistake, right? The winner had make a killer move... Perhaps not.

Even still, the spirit of Tartakower's advice holds. Play in this moment. You never know which mistake will be the next-to-last, or the last. Keep playing.

At this time of year, when I look back over the past twelve months of performing tasks that do not come naturally to me, and looking ahead to next year's vision and duties, this advice gives me comfort.

(Warning: This is longer than my usual entry.)

In recent weeks I have found myself reading with a perverse fascination some of the abundant articles about the future of newspapers and journalism. Clay Shirky's Newspapers and Thinking the Unthinkable has received a deserving number of mentions in most. His essay reminds us, among other things, that revolutions change the rules that define our world. This means that living through a revolution is uncomfortable for most people -- and dangerous to the people most invested in the old order. The ultimate source of the peril is lack of imagination; we are so defined by the rules that we forget they are not universal laws but human constructs.

I'm not usually the sort of person attracted to train wrecks, but that's how I feel about the quandary facing the newspaper industry. Many people in and out of the industry like to blame the internet and web for the problem, but it is more complicated than that. Yes, the explosion of information technology has played a role in creating difficulties for traditional media, but as much as it causes the problems, I think it exposes problems that were already there. Newspapers battle forces from all sides, not the least of which is the decline -- or death? -- of advertising, which may soon be known as a phenomenon most peculiar to the 20th century. The web has helped expose this problem, with metrics that show just how little web ads affect reader behavior. It has also simply given people alternatives to media that were already fading. Newspapers aren't alone.

This afternoon, I read Xark's The Newspaper Suicide Pact and was finally struck by another perverse thought, a fear because it hits closer to my home. What if universities are next? Are we already in a decline that will become apparent only later to those of us who are on the inside?

Indications of the danger are all around. As in the newspaper industry, money is at the root of many problems. The cost of tuition has been rising much faster than inflation for a quarter of a century. At my university, it has more than doubled in the 2000s. Our costs, many self-imposed, rise at the same time that state funding for its universities falls. For many years, students offset the gap by borrowing the difference. This solution is bumping into a new reality now, with the pool of money available for student loans shrinking and the precipitous decline in housing equity for many eroding borrowing ability. Some may see this as a good thing, as our students have seen a rapid growth in indebtedness at graduation, outpacing salaries in even the best-paying fields. Last week, many people around here were agog at a report that my state's university grads incur more student loan debt than any other state's. (We're #1!)

Like newspapers, universities now operate in a world where plentiful information is available on-line. Sometimes it is free, and other times its is much less expensive than the cost of taking a course on the subject. Literate, disciplined people can create a decent education for themselves on-line. Perhaps universities serve primarily the middle and lower tier of students, who haven't the initiative or discipline to do it on their own?

I have no numbers to support these rash thoughts, though journalists and others in the newspaper industry do have ample evidence for fear. University enrollments depend mostly on the demographics of their main audience: population growth, economics, and culture. Students also come for a social purpose. But I think the main driver for many students to matriculate is industry's de facto use of the college degree as the entry credential to the workplace. In times of alternatives and tight money, universities benefit from industry's having outsourced the credentialing function to them.

The university's situation resembles the newspaper's in other ways, too. We offer a similar defense of why the world needs us: in addition to creating knowledge, we sort it, we package it for presentation, and we validate its authenticity and authority. If students start educating themselves using resources freely or cheaply available outside the university, how will we know that they are learning the right stuff? Don't get most academics started on the topic of for-profits like Kaplan University and the University of Phoenix; they are the university's whipping boy. The news industry has one, too: bloggers.

Newspaper publishers talk a lot these days about requiring readers to pay for content. In a certain sense, that is what students do: pay universities for content. Now, though, the web gives everyone access to on-line lectures, open-source lecture notes, the full text of books, technical articles, and ... the list goes on. Why should they pay?

Too many publishers argue that their content is better, more professional, and so stand behind "the reasonable idea that people should have to pay for the professionally produced content they consume". Shirky calls this a "post-rational demand", one that asks readers to behave in a way "intended to restore media companies to the profitability ordained to them by God Almighty" -- despite living in a world where such behaviors are as foreign as living in log cabins and riding horses for transportation. Is the university's self-justification as irrational? Is it becoming more irrational every year?

Some newspapers decide to charge for content as a way to prop up their traditional revenue stream, print subscriptions. Evidence suggest that this not only doesn't work (people inclined to drop their print subscriptions won't be deterred by pay walls) but that it is counter-productive: the loss of on-line visitors causes a decline in web advertising revenue that is much greater than the on-line reader revenue earned. Again, this is pure speculation, but I suspect that if universities try to charge for their on-line content they will see similar results.

The right reason to charge for on-line content is to create a new revenue stream, one that couldn't exist in the realm of print. This is where creative thinking will help to build an economically viable "new media". This is likely the right path for universities, too. My oldest but often most creative-thinking colleague has been suggesting this as a path for my school to consider for a few years. My department is working on one niche offering now: on-line courses aimed at a specific audience that might well take them elsewhere if we don't offer them, and who then have a smoother transition into full university admission later. We have other possibilities in mind, in particular as part of a graduate program that already attracts a large number of people who work full time in other cities.

But then again, there are schools like Harvard, MIT, and Stanford with open course initiatives, placing material on-line for free. How can a mid-sized, non-research public university compete with that content, in that market? How will such schools even maintain their traditional revenue streams if costs continue to rise and high quality on-line material is readily available?

In a middle of a revolution, no one knows the right answers, and there is great value in trying different ideas. Most any school can start with the obvious: lectures on-line, increased use of collaboration tools such as wikis and chats and blogs -- and Twitter and Facebook, and whatever comes next. These tools help us to connect with students, to make knowledge real, to participate in the learning. Some of the obvious paths may be part of the solution. Perhaps all of them are wrong. But as Shirky and others tell us, we need to try all sorts of experiments until we find the right solution. We are not likely to find it by looking at what we have always done. The rules are changing. The reactions of many in the academy tell a sad story. They are dismissive, or simply disinterested. That sounds a lot like the newspapers, too. Maybe people are simply scared and so hole up in the bunker constructed out of comfortable experience.

Like newspapers, some institutions of higher education are positioned to survive a revolution. Small, focused liberal arts colleges and technical universities cater to specific audiences with specific curricula. Of course, the "unique nationals" (schools such as Harvard, MIT, and Stanford) and public research universities with national brands (schools such as Cal-Berkeley and Michigan) sit well. Other research schools do, too, because their mission goes beyond the teaching of undergraduates. Then again, many of those schools are built on an economic model that some academics think is untenable in the long run. (I wrote about that article last month, in another context.)

The schools most in danger are the middle tier of so-called teaching universities and low-grade research schools. How will they compete with the surviving traditional powers or the wealth of information and knowledge available on-line? This is one reason I embrace our president's goal of going from good to great -- focusing our major efforts on a few things that we do really well, perhaps better than anyone, nurturing those areas with resources and attention, and then building our institution's mission and strategy around this powerful core. There is no guarantee that this approach will succeed, but it is perhaps the only path that offers a reasonable chance to schools like ours. We do have one competitive advantage over many of our competitors: enough research and size to offer students a rich learning environment and a wide range of courses of study, but small enough to offer a personal touch otherwise available only at much smaller schools. This is the same major asset that schools like us have always had. When we find ourselves competing in a new arena and under different conditions, this asset must manifest itself in new forms -- but it must remain the core around which we build..

One of the collateral industries built around universities, textbook publishing, has been facing this problem in much the same way as newspapers for a while now. The web created a marketplace with less friction, which has made it harder for them to make the return on investment to which they had grown accustomed. As textbook prices rise, students look for alternatives. Of course, students always have: using old editions, using library copies, sharing. Those are the old strategies -- I used them in school. But today's students have more options. They can buy from overseas dealers. They can make low-cost copies much more readily. Many of my students have begun to bypass the the assigned texts altogether and rely on free sources available on-line. Compassionate faculty look for ways to help students, too. They support old editions. They post lecture notes and course materials on-line. They even write their own textbooks and post them on-line. Here the textbook publishers cross paths with the newspapers. The web reduces entry costs to the point that almost anyone can enter and compete. And publishers shouldn't kid themselves; some of these on-line texts are really good books.

When I think about the case of computer science in particular, I really wonder. I see the wealth of wonderful information available on line. Free textbooks. Whole courses taught or recorded. Yes, blogs. Open-source software communities. User communities built around specific technologies. Academics and practitioners writing marvelous material and giving it away. I wonder, as many do about journalists, whether academics will be able to continue in this way if the university structure on which they build their careers changes or disappears? What experiments will find the successful models of tomorrow's schools?

Were I graduating from high school today, would I need a university education to prepare for a career in the software industry? Sure, most self-educated students would have gaps in their learning, but don't today's university graduates? And are the gaps in the self-educated's preparation as costly as 4+ years paying tuition and taking out loans? What if I worked the same 12, 14, or 16 hours a day (or more) reading, studying, writing, contributing to an open-source project, interacting on-line? Would I be able to marshall the initiative or discipline necessary to do this?

In my time teaching, I have encountered a few students capable of doing this, if they had wanted or needed to. A couple have gone to school and mostly gotten by that way anyway, working on the side, developing careers or their own start-up companies. Their real focus was on their own education, not on the details of any course we set before them.

Don't get me wrong. I believe in the mission of my school and of universities more generally. I believe that there is value in an on-campus experience, an immersion in a community constructed for the primary purpose of exploring ideas, learning and doing together. When else will students have an opportunity to focus full-time on learning across the spectrum of human knowledge, growing as a person and as a future professional? This is probably the best of what we offer: a learning community, focused on ideas broad and deep. We have research labs, teams competing in a cyberdefense and programming contests. The whole is greater than the sum of parts, both in the major and in liberal education.

But for how many students is this the college experience now, even when they live on campus? For many the focus is not on learning but on drinking, social life, video games... That's long been the case to some extent, but the economic model is changing. Is it cost-effective for today's students, who sometimes find themselves working 30 or more hours a week to pay for tuition and lifestyle, trying to take a full load of classes at the same time? How do we make the great value of a university education attractive in a new world? How do we make it a value?

And how long will universities be uniquely positioned to offer this value? Newspapers used to be uniquely positioned to offer a value no one else could. That has changed, and most in the industry didn't see it coming (or did, and averted their eyes rather than face the brutal facts).

I'd like also to say that expertise distinguishes the university from its on-line competition. That has been true in the past and remains true today, for the most part. But in a discipline like computer science, with a large professional component attracts most of its students, where grads will enter software development or networking... there is an awesome amount of expertise out in the world. More and more of those talented people are now sharing what they know on-line.

There is good news. Some people still believe in the value of a university education. Many students, and especially their parents, still believe. During the summer we do freshman orientation twice a week, with an occasional transfer student orientation thrown into the mix. People come to us eagerly, willing to spend out of their want or to take on massive debts to buy what we sell. Some come for jobs, but most still have at least a little of the idealism of education. When I think about their act in light of all that is going on in the world, I am humbled. We owe them something as valuable as what they surrender. We owe them an experience befitting the ideal. This humbles me, but it also Invigorates and scares me, too.

This article is probably more dark fantasy than reality. Still, I wonder how much of what I believe I really should believe, because it's right, and how much is merely a product of my lack of imagination. I am certain that I'm living in the middle of a revolution. I don't know how well I see or understand it. I am also certain of this: I don't want someone to be writing this speech about universities in a few years with me in its clueless intended audience.

Brian Marick tweeted about his mini-blog post Pay me until you're done, which got me to thinking. The idea is something like this: Many agile consultants work in an agile way, attacking the highest-value issue they can in a given situation. If the value of the issues to work on decreases with time, there will come a point at which the consultant's weekly stipend exceeds the value of the work he is doing. Maybe the client should stop buying services at that point.

My first thought was, "Yes, but." (I am far too prone to that!)

First, the "yes": In the general case of consulting, as opposed to contract work, the consultant's run will end as his marginal effect on the company approaches 0. Marick is being honest about his value. At some point, the value of his marginal contribution will fall below the price he is charging that week. Why not have the client end the arrangement at that point, or at least have the option to? This is a nice twist on our usual thinking.

Now for the "but". As I tweeted back this feels a bit like Zeno's Paradox. Marick the consultant covers not half the distance from start to finish each week, but the most valuable piece of ground remaining. With each week, he covers increasingly less valuable distance. So our consultant, cast in the role of Achilles, concedes the race and says, okay, so stop paying me.

This sounds noble, but remember: Achilles would win the race. We unwind Zeno's Paradox when we realize that the sum of an infinite series can be a finite number -- and that number may be just small enough for Achilles to catch the tortoise. This works only for infinite series that behave in a particular way.

Crazy, I know, but this is how the qualification of the "yes" arose in my mind. Maybe, the consultant helps to create a change in his client that changes the nature of the series of tasks he is working on. New ideas might create new or qualitatively different tasks to do. The change created may change the value of an existing task, or reorder the priorities of the remaining tasks. If the nature of the series changes, it may cause the value of the series to change, too. If so, then the client may well want to keep the consultant around, but doing something different than the original set of issues would have called for.

Another thought: Assume that the conditions that Marick described do hold. Should the compensation model be revised? He seems to be assuming that the consultant charges the same amount for each week of work, with the value of the tasks performed early being greater than that amount and the value of the tasks performed later being less than that amount. If that is true,then early on the consultant is bringing in substantially more value than he costs. If the client pulls the plug as soon as the value proposition turns in its favor, then the consultant ends up receiving less than the original contract called for yet providing more than average value for the time period. If the consultant thinks that is fair, great. What if not? Perhaps the consultant should charge more in the early weeks, when he is providing more value, than in later week? Or maybe the client could pay a fee to "buy out" the rest of the contract? (I'm not a professional consultant, so take that into account when evaluating my ideas about consultant compensation...)

And another thought: Does this apply to what happens when a professor teaches a class? In a way, I think it does. When I introduce a new area to students, it may well be the case that the biggest return on the time we spend (and the biggest bang for the students' tuition dollars) happens in the first weeks. If the course is successful, then most students will become increasingly self-sufficient in the area as the semester goes on. This is more likely the case for upper-division courses than for freshmen. What would it be like for a student to decide to opt out of the course at the point where she feels like she has stopped receiving fair value for the time being spent? Learning isn't the same as a business transaction, but this does have an appealing feel to it.

The university model for courses doesn't support Marick's opt-out well. The best students in a course often reach a point where they are self-sufficient or nearly so, and they are "stuck". The "but" in our teaching model is that we teach an audience larger than one, and the students can be at quite different levels in background and understanding. Only the best students reach a point where opting out would make sense; the rest need more (and a few need a lot more -- more than one semester can offer!).

The good news is that the unevenness imposed by our course model doesn't hurt most of those best students. They are usually the ones who are able to make value out of their time in the class and with the professor regardless of what is happening in the classroom. They not only survive the latency, but thrive by veering off in their own direction, asking good questions and doing their own programming, reading, thinking outside of class. This way of thinking about the learning "transaction" of a course may help to explain another class of students. We all know students who are quite bright but end up struggling through academic courses and programs. Perhaps these students, despite their intelligence and aptitude for the discipline, don't have the skills or aptitude to make value out of the latency between the point they stop receiving net value and the end of the course. This inability creates a problem for them (among them, boredom and low grades). Some instructors are better able to recognize this situation and address it through one-on-one engagement. Some would like to help but are in a context that limits them. It's hard to find time for a lot of one-on-one instruction when you teach three large sections and are trying to do research and are expected to meet all of the other expectations of a university prof.

Sorry for the digression from Marick's thought experiment, which is intriguing in its own setting. But I have learned a lot from applying agile development ideas to my running. I have found places where the new twist helps me and others where the analogy fails. I'm can't shake the urge to do the same on occasion with how we teach.

One of the challenges every beginner faces is learning the subtle judgments they must make. How much time will it take for us to implement this story? Should I create a new kind of object here? Estimation and other judgments are a challenge because the beginner lacks the "instinct" for making them, and the environment often does provide enough data to make a clear-cut decision.

I've been living with such a beginner's mind this week on my morning runs. Tuesday morning I started with a feeling of torpor and was sure I'd end with a slow time. When I finished, I was surprised to have run an average time. On Wednesday morning, I felt good yet came in with one of my slowest times for the distance ever. This morning, my legs were stiff, making steps seem a chore. I finished in one of my better times at this distance since working my mileage back up.

My inaccurate judgments flow out of bad instincts. Sometimes, legs feel slow and steps a challenge because I am pushing. Sometimes, I run with ease because I'm not running very hard at all!

At this stage in my running, bad instincts are not a major problem. I'm mostly just trying to run enough miles to build my aerobic base. Guessing my pace wrong has little tangible effect. It's mostly just frustrating not to know. Occasionally, though, the result is as bad as the judgment. Last week, I ran too fast on Wednesday after running faster than planned on Tuesday. I ended up sick for the rest of the week and missed out on 8-10 miles I need to build my base. Other times, the result goes the other way, as when I turned in a best-case scenario half-marathon in Indianapolis. Who knew? Certainly not me.

So, inaccurate instincts can give good or bad results. The common factor is unpredictability. That may be okay when running, or not; in any case, it can be a part of the continuous change I seek. But unpredictability in process is not so okay when I am developing software. Continuous learning is still good, but being wrong can wreak havoc on a timeline, and it can cause problems for your customer.

Bad instincts when estimating my pace wasn't a problem two years, though it has been in my deeper past. When I started running, I often felt like an outsider. Runners knew things that I didn't, which made me feel like a pretender. They had instincts about training, eating, racing, and resting that I lacked. But over time I began to feel like I knew more, and soon -- imperceptibly I began to feel like a runner after all. A lot -- all? -- of what we call "instinct" is developed, not inborn. Practice, repetition, time -- they added up to my instincts as a runner.

Time can also erode instinct. A lack of practice, a lack of repetition, and now I am back to where I was several years ago, instinct-wise. This is, I think, a big part of what makes learning to run again uncomfortable, much as beginners are uncomfortable learning the first time.

One of the things I like about agile approaches to software development is their emphasis on the conscious attention to practice. They encourage us to reflect about our practice and look for ways to improve that are supported by experience. The practices we focus on help us to develop good instincts: how much time it will take for us to implement a story, when to write -- and not write -- tests, how far to refactor a system to prepare for the next story. Developing accurate and effective instinct is one way we get better, and that is more important than being agile.

The traditional software engineering community thinks about this challenge, too. Watts Humphrey created the Personal Software Process to help developers get a better sense of how they use their time and to use this sense to get better. But, typically, the result feels so heavy, so onerous on the developers it aims to help, that few people are likely to stick with it when they get into the trenches with their code.

An aside: This reminds me of conversations I had with students in my AI courses back in the day. I asked them to read Alan Turing's classic Computing Machinery and Intelligence, and in class we discussed the Turing Test and the many objections Turing rebuts. Many students clung to the notion that a computer program could never exhibit human-like intelligence because humans lacked "gut instinct" -- instinct. Many students played right into Turing's rebuttal yet remained firm; they felt deeply that to be human was different. Now, I am not at ease with scientific materialism's claim that humans are purely deterministic beings, but the scientist in me tells me to strive for natural explanations of as much of every phenomenon as possible. Why couldn't a program develop a "gut feeling"? To the extent that at least some of our instincts are learned responses, developed through repetition and time, why couldn't a program learn the same instincts? I had fun playing devil's advocate, as I always do, even when I was certain that I was making little progress in opening some students' minds.

In your work and in your play, be aware of the role that practice, repetition, and time play in developing your instincts. Do not despair that you don't have good instincts. Work to develop them. The word missing from your thought is "yet". A little attention to your work, and a lot of practice, will go a long way. Once you have good instincts, cherish them. They give us comfort and confidence. They make us feel powerful. But don't settle. The same attention and practice will help you get better, to grow as a developer or runner or whatever your task.

As for my running, I am certainly glad to be getting stronger and to be able to run faster than I expect. Still, I look forward to the feeling of control I have when my instincts are more reliable. Unpredictable effort leads to unpredictable days.

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

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

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

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

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

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

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

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

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

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

Sometimes it pays to keep reading. Last time, I commented on breaking rules and mentioned a thread on the XP mailing list. I figured that I had seen all I needed there and was on the verge of skipping the rest. Then I saw a message from Laurent Bossavit and decided to read. I'm not surprised to learn something from Laurent; I have learned from him before.

Laurent's note introduced me to the legal term bright line. In the law, a bright-line rule is...

... a clearly defined rule or standard, composed of objective factors, which leaves little or no room for varying interpretation. The purpose of a bright-line rule is to produce predictable and consistent results in its application.

As Laurent says, Bright lines are important in situations where temptations are strong and the slope particularly steep, a well-known example is alcoholics' high vulnerability to even small exceptions. Test-driven development, or even writing tests soon after code and thus maintaining a complete suite of automated tests, requires a bright line for many developers. It's too easy to slide back into old habits, which for most developers are much older and stronger. Staying on the right side of the line may be the only practical way to Live Right.

This provides a useful name for what teachers often do in class: create bright lines for students. When students are first learning a new concept, they need to develop a new habit. A bright-line rule -- "Thou shalt always write a test first." or "Thou shalt write no line of code outside of a pair." -- removes from the students' minds the need to make a judgment that they are almost always not prepared to make yet: "Is this case an exception?" While learning, it's often better to play Three Bears and overdo it. This gives your mind a chance to develop good judgment through experience.

(For some reason, I am reminded of one way that I used to learn to play a new chess opening. I'd play a bazillion games of speed chess using it. This didn't train my mind to think deeply about the positions the opening created, but it gave me a bazillion repetitions. I soon learned a lot of patterns that allowed me to dismiss many bad alternatives and focus my attention on the more interesting positions.)

I often ask students to start with a bright line, and only later take on the challenge of a balancing test. It's better to evolve toward such complexity, not try to start there.

The psychological benefits of a bright-line test are not limited to beginners. Just as alcoholics have to hold a hard line and consider every choice consciously every day, some of us need a good "Thou shalt.." or "Thou shalt not..." in certain cases. As much as I like to run, I sometimes have to force myself out of bed at 5:00 AM or earlier to do my morning work-out. Why not just skip one? I am a creature of habit, and skipping even one day makes it even harder to get up the next, and the difficulty grows until I have a new habit.

(This has been one of the most challenging parts of trying to get back up to my old mileage after several extended breaks last year. I am proud finally to have done all five of my morning runs last week -- no days off, no PM make-ups. A new habit is in formation.)

If you know you have a particular weakness, draw a bright line for yourself. There is no shame in that; indeed, I'd say that it shows professional maturity to recognize the need and address it. If you need a bright line for everything, that may be a problem...

Sometimes, I adopt a bright line for myself because I want everyone on the team to follow a practice. I may feel comfortable exercising judgment in the gray area but not feel the rest of the team is ready. So we all play by the rules rather than discuss every possible judgment call. As the team develops, we can begin having those discussions. This is similar to how I teach many practices.

This may sound too controlling to you, and occasionally a student will say as much. But nearly everyone in class benefits from taking the more patient road to expertise. Again, from Laurent:

Rules which are more ambiguous and subtle leave more room for various fudge factors, and that of course can turn into an encouragement to fudge, the top of a slippery slope.

Once learners have formed their judgment, they are ready to balance forces. Until then, most are more likely to backslide out of habit than to make an appropriate choice to break the rule. And time spent arguing every case before they are ready is time not spent learning.

Shh.

I have a secret.

When I am writing a program, I will on occasion add a new piece of functionality without writing a test.

I am whispering because I have seen the reaction on the XP mailing list and on a number of blogs that Kent Beck received to his recent article, To Test or Not to Test? That's a Good Question. In this short piece, Kent describes his current thinking that, like golf, software development may have "long game" and "short game", which call for different tools and especially mentalities. One of the differences might be whether one is willing to trade automated testing for some other value, such as delivering a piece of software sooner.

Note that Kent did not say that in the long game he chooses not to test his code; he simply tested manually. He also didn't say that he plans never to write the automated tests he needs later; he said he would write them later, either when he has more time or, perhaps, when he has learned enough to turn 8 hours of writing a test into something much shorter.

Many peoples' public reactions to Kent's admission have been along these lines: "We test you to make this decision, Kent, but we don't trust everyone else. And by saying this is okay, you will contribute to the delinquency of many programmers." Now you know why I need to whisper... I am certainly not in the handful of programmers so good that these folks would be willing to excuse my apostasy. Kent himself is taking a lot of abuse for it.

I have to admit that Kent's argument doesn't seem that big a deal to me. I may not agree with everything he says in his article, but at its core he is claiming only that there is a particular context in which programmers might choose to use their judgment and not write tests before or immediately after writing some code. Shocking: A programmer should use his or her judgment in the course of acting professionally. Where is the surprise?

One of the things I like about Kent's piece is that he helps us to think about when it might be useful to break a particular rule. I know that I'll be breaking rules occasionally, but I often worry that I am surrendering to laziness or sloppiness. Kent is describing a candidate pattern: In this context, with these goals, you are justified in breaking this rule consciously. We are balancing forces, as we do all the time when building anything. We might disagree with the pattern he proposes, but I don't understand why developers would attack the very notion of making a trade-off that results in breaking a rule.

In practice, I often play a little loose with the rules of XP. There are a variety of reasons that lead me to do so. Sometimes I pay for not writing a test, and when I do I reflect on what about the situation made the omission so dangerous. If the only answer I can offer is "You must write the test, always.", then I worry that I have moved from behaving like a professional to behaving like a zealot. I suspect that a lot of developers make similar trade-offs.

I do appreciate the difficulty this raises for those of us who teach XP, whether at universities or in industry. If we teach a set of principles as valuable, what happens to our students' confidence in the principles when we admit that we don't follow the rules slavishly? Well, I hope that my students are learning to think, and that they realize any principle or rule is subject to our professional judgment in any given circumstance.

Of course, in the context of a course, I often ask students to follow the rules "slavishly", especially when the principles in question require a substantial change in how they think and behave. TDD is an example, as is pair programming. More broadly, this idea applies when we teach OOP or functional programming or any other new practice. (No assignment statements or sequences until Week 10 of Programming Languages!) Often, the best way to learn a new practice is to live it for a while. You understand it better then than you can from any description, especially how it can transform the way you think. You can use this understanding later when it comes to apply your judgment about potential trade-offs.

Even still, I know that, no matter how much an instructor encourages a new practice and strives to get students to live inside it for a while, some students simply won't do it. Some want to but struggle changing their habits. I feel for them. Others willfully choose not to try the something new and deny themselves the opportunity to grow. I feel for them, too, but in a different way.

Once students have had a chance to learn a set of principles and to practice them for a while, I love to talk with them about choices, judgment, and trade-offs. They are capable of having a meaningful discussion then.

It's important to remember that Kent is not teaching novices. His primary audience is professional programmers, with whom he ought to be able to have a coherent conversation about choices, judgment, and trade-offs. Fortunately, a few folks on the P list have entertained the "long game versus short game" claim and related their own experiences making these kind of decisions on a daily basis.

If we in the agile world rely on unthinking adherence to rules, then we are guilty of proselytizing, not educating. Lots of folks who don't buy the agile approaches love when they see examples of this rigidity. It gives them evidence to support their tenuous position about the whole community. From all of my full-time years in the classroom, I have learned that perhaps the most valuable asset I can possess is my students' trust in my goals and attitudes. Without that, little I do is likely to have any positive effect on them.

Kent's article has brought to the surfaced another choice agilistas face most every day: the choice between dogma and judgment. We tend to lose people when we opt for unthinking adherence to a rule or a practice. Besides, dogmatic adherence is rarely the best path to getting better every day at what we do, which is, I think one of the principles that motivate the agile methods.

Though final grades are not all yet submitted, the semester is over. We made adjustments to the specification in my compilers course, and the students were able to produce a compiler that produced compilable, executable Java code for a variety of source programs. For the most part, the issues we discussed most at their finals week demo dealt with quality control. We found some programs that confounded their parser or code generator, which were evidence of bits of complexity they had not yet mastered. There is a lesson to be learned: theory and testing often take a back seat to team dynamics and practices. Given the complexity of their source language, I was not too disappointed with their software, though I think this team fell short of its promise. I have been part of teams that have fallen similarly short and so can empathize.

So, what is the verdict on a couple of new ideas we tried this semester: letting the team design its own source language and working in a large team, of six? After their demo, we debriefed the project as a group, and then I asked them to evaluate the project and course in writing. So I have some student data on which to draw as well as my own thoughts.

On designing their own language: yes, but. Most everyone enjoyed that part of the project, and for some it was their favorite activity. But the students found themselves still churning on syntax and semantics relatively late into the project, which affected the quality and stability of their parser. We left open the possibility of small changes to the grammar as they learned more about the language by implementing it, but this element of reality complicated their jobs. I did not lock down the language soon enough and left them making decisions too late in the process.

One thing I can do the next time we try this is to put a firmer deadline on language design. One thing thing that the students and I both found helpful was writing programs in the proposed language and discussing syntactic and semantic language issues grounded in real code. I think I'll build a session or two of this into the course early, before the drop-dead date for the grammar, so that we can all learn as much as we can about the language before we proceed on to implementing it.

We also discussed the idea of developing the compiler in a more agile way, implementing beginning-to-end programs for increasing subsets of the language features until we are done. This may well help us get better feedback about language design earlier, but I'm not sure that it addresses the big risks inherent in letting the students design their own language. I'll have to think more on this.

On working is a team of size six: no. The team members and I were unanimous that a team of size six created more problems than it solved. My original thinking was that a larger team would be better equipped to do the extra work introduced by designing their own language, which almost necessarily delayed the start of the compiler implementation. But I think we were bitten by a preemptive variation of Brooks's Law -- more manpower slowed them down. Communication overhead goes up pretty quickly when you move from a team of three to a team of six, and it was much harder for the team to handle all of its members' ideas effectively. This might well be true for a team of experienced developers, but for a team of undergrads working on their first collaborative project of this scale, it was an occasional show-stopper. I'll know better next time.

As an aside, one feature the students included in the language they designed was first-class functions. This clearly complicated their syntax and their implementation. I was pleased that they took the shot. Even after the project was over and they realized just how much extra work first-class functions turned out to be, the team was nearly unanimous in saying that, if they could start over, they would retain that feature. I admire their spunk and their understanding of the programming power this feature gave to their language.

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

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

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

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

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

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

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

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

Last week, every administrator at my university seemed to be talking about Mark Taylor's End the University as We Know It. Like many other universities, we have been examining pretty much everything we do in light of significant changes in the economy (including, for public universities, drastic reductions in state funding) and demographics. Taylor, a department chair in a humanities department at Columbia University, starts with a critique of graduate programs, which he contends produce a product few need because they also provide an essential commodity for the modern university: cheap teaching labor that frees faculty to do research. From here, he asserts that American higher education should undergo a radical transformation and proposes six steps in the direction he thinks best.

The second proposal caught my attention:

Abolish permanent departments, even for undergraduate education, and create problem-focused programs.

In recent years I have developed a strong belief in the value of project-based education, especially in CS courses. I also have a fondness for the idea of problem-based learning which Owen Astrachan has been touting for some time now. I think of these as having at least one valuable attribute in common: students do something real in context where they have to make real decisions.

Taylor proposes that we build the university of today not around permanent discipline-specific departments but evolving programs centered on "zones of inquiry", Big Problems that matter across disciplines. When I discussed this idea with my provost, I told him that I was fortunate: my discipline, Computer Science, will have a role to play in most every problem-focused program for the foreseeable future. Talk about job security!

This idea may sound wonderful, but there are risks. As Michael Mitzenmacher points out, you still need discipline-specific expertise. Taylor's offers as an example a program built around pressing issues related to water, which would ...

... bring together people in the humanities, arts, social and natural sciences with representatives from professional schools like medicine, law, business, engineering, social work, theology and architecture.

To do that, you need people with expertise in the humanities, arts, social and natural sciences, medicine, law, business, engineering, social work, theology and architecture. Where will these experts come from? Taylor doesn't say as much, but there is a hint in his article, and in others like it, that collaborative work on big problems is all that we need. But I wonder how such a university would prepare students who would become the next generation of experts in the arts, sciences, and professions, let alone the next generation of researchers who will discover the ideas and create the tools we need to solve the big problems. I don't suppose there is any reason in principle that a university in such way could not prepare experts, and my Inner Devil's Advocate is already working on ways that it might succeed swimmingly. But I get a little worried whenever I hear people talking about making radical changes to complex systems without having considered explicitly all of the story.

This particular risk is at the front of my mind because we face the same risk, at a different scale, when we create problem- and project-focused curricula. There is a natural tension between depth in the discipline and working in the context of a specific application or other domain. If I build an intro programming course around, say, media computation or biology, will students learn all of the CS they should learn in that course? Some time will be spent on images and sounds, or on DNA and amino acid base pairs, and that is time not spent on procedures, arrays, pointers, and big-O analysis. I am well aware that adding more content to a course does not mean that everyone will get it all. But some do, and maybe those are the people who will be the experts of the future?

We have used media computation as a theme in a few sections of our intro course over the last four years, and we observe this tension in the results. Some students get just what we want them to get out of the theme: motivation to dig deep, experiment, and discuss important ideas. Others don't connect with the theme, and they just end up knowing less CS-specific content. The prof who has taught this course most often is beginning to see ways in which he can trade back some of the context for opportunities to program in other contexts, which may hit a broader variety of students than a pure media comp course.

When I think about how this trade-off would scale to the level of an entire university in programs that bring together eight, twelve, or twenty disciplines, I realize that we would need to think carefully before proceeding too far. Perhaps Taylor hopes that his article will cause faculty and administration to begin the process of thinking carefully. Some people have been thinking about these issues for a while and even put some of those thoughts into writing (PDF).

The law of unintended consequences lurks in the darkness behind many suggestions of radical changes to complex systems. For example, Taylor suggests that universities abolish tenure. Many would agree. After being a department head for many years, I appreciate many of the advantages of this idea. But consider what might happen in disciplines whose faculty are in great demand in industry. Hmm, such as computer science. Without tenure and its concomitant security, I suspect that a fair number of CS faculty would find their way into industry. Right now, the allure of bigger paydays in industry are balanced against all sorts of risk. Universities offer a level of security in exchange for much lower salaries. Without that security, I might be better off out there in the real world writing programs, hoping that one turns out to be the next Twitter or the IDE that revolutionizes how we program in dynamic languages.

I am not suggesting that we not think radical thoughts or consider how we might do things differently. In fact, I spend a large part of my administrative and academic lives doing just that. I do suggest that we not rush headlong into ideas before thinking them through, even when they seem tantalizingly right at first blush.

As with so many articles of this sort, Taylor may hope simply to cause people to consider new ideas, not adopt the specific prescriptions he offers. Certainly, many schools are already experimenting with ideas such as greater collaboration across disciplines and institutions. As in the case of courses that are focused on problems or projects, the rub is in balancing the forces at play so that we achieve our goal of better helping students to learn.

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

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

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

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

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

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

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

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

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

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

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

We have fallen behind in my compilers course. You may recall that before the semester I contemplated some changes in the course, including letting letting the students design their own language. My group of six chose that route, and as a part of that choice decided to work as a team of six, rather than in pairs or threes. This was the first time for me to have either of these situations in class, and I was curious to see how it would turn out.

Designing a language is tough, and even having lots of examples to work from, both languages and documents describing languages, is not enough to make it easy. We took a little longer than I expected. Actually, the team met its design deadline (with no time to spare, but...), but then followed a period of thinking more about the language. We both needed to come to a better understanding of the implications of some of their design decisions. Over time they changed their definition, sometimes refining and sometimes simply making the language different. This slowed the process of starting to implement the language and caused a few false starts in the scanner and parser.

Such bumps are a natural part of taking on the tougher problem of creating the language, so I don't mind that we are behind. I have learned a few things to do differently the next time a compiler class chooses this route. Working as a team of six increases the communication overhead they face, so I need to do a better job preparing them for the management component of such a large development project. It's hard for a team to manage itself, either through specific roles that include a nominal team leader or through town-hall style democracy. As the instructor, I need to watch for moments when the team needs me to take the rudder and guide things a bit more closely. Still, I think that this has been a valuable experience for the students. When they get out into industry, they will see successes and failures of the sort they've created for themselves this semester.

Still, things have gone reasonably well. It's almost inevitable that occasional disagreements about technical detail or team management will arise. People are people, and we are all hard to work with sometimes. But I've been happy with the attitude that all have brought to the project. I think all have shown a reasonable degree of commitment to the project, too, though they may not realize yet just what sort of commitment getting a big project like this done can require.

I have resisted the urge to tell (or re-tell?) the story of my senior team project: a self-selected team of good programmers and students who nonetheless found ways to fall way behind their development schedule. We had no way to change the scope of the system, struggled mightily in the last weeks of the two-term project, and watched our system crash on the day of the acceptance test. The average number of hours I spent on this project during its second term? 62 hours. And that was while taking another CS course, two accounting courses, and a numerical analysis course -- the final exam for which I have literally no recollection of at all, because by that time I was functioning on nearly zero sleep for days on end. This story probably makes me sound crazy -- not committed, but in need of being committed. Sometimes, that's what a project takes.

On the technical side, I will do more next time to accelerate our understanding of the new language and our fixing of the definition. One approach I'm considering is early homework assignments writing programs in the new language, even before we have a scanner or parser. This causes us all to get concrete sooner. Maybe I will offer extra-credit points to students who catch errors in the spec or in others students' programs. I'll definitely give extra-credit for catching errors in my programs. That's always fun, and I make a perfect foil for the class. I am sure both to make mistakes and to find holes in their design or their understanding of it.

But what about this semester? We are behind, with three weeks to D-Day. What is the best solution?

The first thing to recognize is that sometimes this sort of thing happens. I do not have the authority to implement a death march, short of becoming an ineffective martinet. While I could try telling students that they will receive incompletes until the project is finished, I don't really have the authority to push the deadline of the project beyond the end of our semester.

The better option is one not made available to my project team in school, but which we in the software world now recognize as an essential option: reduce the scope of the project. The team and I discussed this early in the week. We can't do much to make the language smaller, because it is already rather sparse in data types, primitive operators, and control structure. The one thing we could drop is higher-order procedures, but I was so please when they included this feature that I would feel bad watching it drop out now. But that would not really solve our problem. I am not sure they could complete a compiler for the rest of the language in time anyway.

We decided instead to change the target language from JVM bytecodes to Java itself. This simplifies what remains for them quite a bit, but not so much that it makes the job easy. The big things we lose are designing and implementing a low-level run-time system and emitting machine-level code. The flip side is that we decided to retain the language's support for higher-order procedures, which is not trivial to implement in generated Java code. They'll still get to think about and implement closures, perhaps using anonymous inner classes to implement function arguments and results.

This results in a different challenge, and a change in the experience the students will have. The object lesson is a good one. We have made a trade-off, and that is the nature of life for programmers. Change happens, and things don't always proceed according to plan. So we adapt and do the best we can. We might even spend 60 hours one week working on our project!

For me, the biggest effect of the change is on our last two and a half weeks of lecture. Given where we are and what they will be doing, what do they most need to learn? What ideas and techniques should they see even if they won't use them in their compilers? I get to have some fun right up to the end, too.

... for a definition of "the day" that includes when I read them, not when the authors posted them.

Tweet of the Day

Marick's Law: In software, anything of the form "X's Law" is better understood by replacing the word "Law" with "Fervent Desire".
-- Brian Marick

I love definitions that apply to themselves. They are the next best thing to recursion. I will have plenty of opportunities to put Brian's fervent desire into practice while preparing to teach software engineering this fall.

Non-Tech Blog of the Day

I don't usually quote former graffiti vandals or tattoo artists here. But I am an open-minded guy, and this says something that many people prefer not to hear. Courtesy of Michael Berman:

"Am I gifted or especially talented?" Cartoon said. "No. I got all this through hard work. Through respecting my old man. From taking direction from people. From painting when everyone else was asleep. I just found something I really love and practiced at it my whole life."
-- Mister Cartoon

Okay, so I am tickled to have quoted a guy named Mister Cartoon. His work isn't my style, but his attitude is. Work. Respect. Deference. Practice. Most days of the week, I would be well-served by setting aside my hubris and following Mister Cartoon's example.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I wanted to create a word processor for data.

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

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

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

Gus Mueller, creator of one of my favorite tools, VoodooPad, recently wrote a short note on debugging his designs and programs:

I learned a long time ago that the two best debugging tools I own are a nice piece of paper, and a good pencil.

Writing something down is a great way to "think out loud". My Ghostbusters-loving colleague, Mark Jacobson, calls this biction. He doesn't define the term on his web page, though he does have this poetic sequence:

Bic pen, ink flowing, snow falling, writing, thinking, playing, dancing

That sounds fanciful, but biction is a nuts-and-bolts idea. The friction of that Bic pen on the paper is when ideas that are floating fuzzily through the mind confront reality.

Mark and I taught a data structures course together back in the 1990s, and we had a rule: if students wanted to ask one of us a question, they had to show us a picture they had drawn that illustrated their problem: the data structure, pointers, a bit of code, ... If nothing else, this picture helped us to understand their problem better. But it usually offered more. In the process of showing us the problem using their picture, students often figured out the problem in front of our eyes. Other students commented that, while drawing a picture in preparing to ask a question, they saw the answer for themselves. Biction.

Of course, one can also "think out loud" out loud. In response to my post on teaching software engineering, a former student suggested that I should expose my students to pair programming, which he found "hugely beneficial" in another course's major project, or at least to rubber duck debugging. That's biction with your tongue.

It may be that the most important activity happens inside our heads. We just need to create some friction for our thoughts.

We offer a lot of our upper-division courses on a three-semester rotation. For the last few years, I have been teaching Programming Languages and our compilers course as a part of our rotation. Before I became department head, I taught Algorithms -- a course I love -- in the third slot. I passed the course on to someone else my first semester as head, and I've never gotten it back. The person who teaches it now is really good, and this leaves me to be a utility infielder, covering whatever most needs to be covered that semester. I've taught our intro course in this slot, as well as a set of 1-credit courses on individual programming languages.

This fall, I will teach a course I have never taught before: software engineering. This is a traditional introduction to the discipline for juniors and seniors:

Study of software life cycle models and their phases -- planning, requirements, specifications, design, implementation, testing, and maintenance. Emphasis on tools, documentation, and applications.

I have taught non- traditional software engineering before, in the form of two offerings of a course on agile software development. In fact, I taught that course during my first full semester after starting this blog, and it -- along with and sometimes in tandem with training for my second marathon -- provided a wealth of inspiration for my writing.

Long-term readers of this blog know that I have expressed skepticism about the software engineering metaphor, both in general and in some of the specifics, such as gathering requirements. Still, I respect the goals of the discipline and the effort and earnestness of its proponents. I also am able to put aside philosophical concerns in the interest of department concerns. We all agree that developing software, especially in the large, is a challenging endeavor that requires knowledge and skill. That is the goal of our course, and it will be the goal of my offering this fall.

The course I teach needs to stay pretty close to the traditional notion of software engineering, because that's what our curriculum calls for. By most accounts, employers who hire our students are pretty happy with what we teach in the course, in particular the breadth of exposure we give them. This is one of the constraints I face as I plan.

That said, I will certainly teach my own course. I will make sure that students are exposed to the agile approaches. Many of our alumni have told me that their employers are introducing elements of XP or Scrum into their software development processes, and that they wish they had learned a bit about them during their undergraduate studies. This is the right place for them to encounter agile principles and practices, as a different perspective on the phases of the software lifecycle.

I also tend more toward the working-code end of the spectrum, whereas this course has historically tended toward the modeling-and-abstraction end. I'd like to find a way to ensure that students see and experience both. Models are nothing more than pictures on a whiteboard or in a CASE tool until we can implement them in code. Besides, our students seem to graduate with an alarming lack of exposure to modern tools for version control, build management, and testing. I'd like to find a way for them to learn not only what the stages of software development are but also tools and practices for effectively evolving programs through those stages.

I'm looking for papers and ideas that can help me design a good course that balances several of these forces. Karen Reid's and Greg Wilson's Learning by doing is a great exemplar; it talks about how to introduce version control by using a tool like CVS or SVN to deliver, manage, and collect student assignments.

In the end, I want this course to serve well students wherever they end up after graduation, whether at a big-process company such as Rockwell Collins or a mostly-agile shop consisting of a few developers. Most of our graduates will end up working in several different development environments within a few years, regardless of where they land, so broad principles and understanding trump mastery of any particular skill set. But I also know that mastery plays a big role in how they will come to understand the principles.

Whatever I do, I want the course to be real, not merely an academic exercise.

My daily bleg: please send me any thoughts you have on this course, ways to organize it, or tools to use. As always, I value your suggestions and will gladly share the credit!

While running yesterday, I was thinking back to my entry on starting again. I say in that entry that having reach a certain level of accomplishment, however meager, makes starting over tough. It's not the same as a newcomer starting from scratch; in some objective sense the newcomer faces a bigger challenge. But starting over creates a new sort of psychological hurdle that adds to the physical challenge. When you've run 60-mile weeks and 10x800m speed workouts, trying to string together 3-mile runs on consecutive days can be, well, demoralizing.

My mind then wandered of to a message from a reader who is former student. He sent me a note in response to Small Surprises While Grading that went far beyond the specific surprises I mentioned -- great stuff on what had been in his mind while taking the course. I thought of this specific comment:

I'm not sure why [there were so many 0s in the course gradebook], but every assignment left me in a bad mood. My mood after each assignment was worse than the previous one. The second to last assignment I did well on, but left me angrier than I have been in a long time.

I wonder if part of this student's bad mood and anger comes from the same thing I'm feeling while running? He is a successful programmer, nearing the end of his undergraduate work. Then this course comes along and changes the rules: functional programming, Scheme, recursion, language grammars. Maybe he felt like he was starting over. Knowing what it felt like to master a programming language, to whip out programs, and to feel good after an assignment, perhaps this experience felt all the more painful, all the more insurmountable.

Though I have thought back to his message several times in the last couple of months, I didn't know to ask him this question until now. I'll ask. But regardless of his answer, I think the feeling I have occasionally while running these days gives me insight to what some students might be feeling.

I also now realize consciously one advantage that I have as a runner who "has reached the mountaintop" over a brand new runner: I know what it feels like to break through the barrier.

One of the more remarkable experiences on a race course is the dramatic deliverance from the depths of discomfort to the rebirth of spirit, endurance, and performance. There's nothing like breaking through the pain barrier, and finding a better and stronger runner on the other side.

-- from a Running Times article on endurance runner Lisa Smith-Batchen

Knowing that feeling is how I put the feeling of re-climbing the mountain in perspective, why any sense of despair seems to evaporate as quickly as it condenses in my mind. I will get back to long runs and faster times. The newbie may not be so confident.

Oh, and as for learning CS: If many students feel what my correspondent says he felt, or if a few students feel that way often, then that is probably sign of a failure in the design of our curriculum, or of my course. I don't mind that students feel uncomfortable for a while as they learn; that is both natural and necessary. Anger and despair are another matter.

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

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

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

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

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

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

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

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

David Patterson wrote a Viewpoint column for the March 2009 issue of Communications on advising graduate students, paired with a column by Jeffrey Ullman. One piece of Patterson's advice applies to more than advising grad students: "You're a role model; act like one.":

I am struck from parenting two now-grown sons that it's not what you say but what you do that has lasting impact. I bet this lesson applies to your academic progeny. Hence, I am conscious that students are always watching what I do, and try to act in ways that I'd like them to emulate later.

For example, my joy of being a professor is obvious to everyone I interact with, whereas I hear that some colleagues at competing universities complain to their students how hectic their lives are.

I often worry about the message I send students in this regard. My life is more hectic and less fun with computer science since I became department head, and I imagine that most of the negative vibe I may give off is more about administration than academia. One time that I am especially careful about the image I project is when I meet with high school students who are prospective CS majors and their parents. Most of those encounters are scheduled in advance, and I can treat them almost like performances. But my interactions with current students on a daily basis? I'm probably hit-and-miss.

The idea that people will infer more from your deeds than your words is not new and does apply widely, to advisors, teachers, decision makers -- everyone, really. Anyone who has been a parent knows what Patterson means about having raised his sons. Long ago I marked this passage from Matthew Kelly's Building Better Families:

If you ask parents if they want their children to grow up to live passionate and purposeful lives they will say, "Absolutely!" But how many parents are living passionate and purposeful lives? Not so many.

Our example can set a negative tone or a positive tone. The best way to give children a zest for life is to live with zest and share your zest with them.

This applies to our students in class and in the research lab, too. My favorite passage in this regard comes not from Patterson's viewpoint but from The Wednesday Wars, which I quoted once before:

It's got to be hard to be a teacher all the time and not jump into a pool of clear water and come up laughing and snorting with water up your nose.

Through all my years in school, my best teachers jumped into the pool all the time and came up laughing and snorting with water up their noses. They wrote prose and code. They read about new ideas and wanted to try them out in the lab. Their excitement was palpable. Fun was part of the life, and that's what I wanted.

I hope I can embody a little of that excitement and fun as a faculty member to our students, as a father to my daughters. But some days, that is more of a challenge than others.

On Learning Curves, I read a lament about calculus students having a hard time putting their skills into practice on some basic word problems. This line stood out:

They can do the calculus. The algebra slays them.

Of late, our CS faculty have been discussing a programming corollary. Students have passed their intro programming course and a data structures course. They get to an intermediate programming course, or a programming languages course, or an AI course, where they learn some more advanced design idea or algorithm. They answer conceptual courses about the material on exams and do well. Then they try to write code... and hit a wall.

Sometimes a new programming language gets in the way, but sometimes not -- students are using a language they used for a year in the intro sequence. And whether it's a new language or an old one, the problems seem ticky-tack: semicolons, declarations, function calls.

They can talk about the advanced concepts, but simple programming tasks to implement the ideas slays them. The programming part looks like attention to detail to me, or effort spent to internalize basic grammar and vocabulary. One prof half-jokingly says his students have gone out of their way to forget what they already knew.

You don't really know programming unless you can write a program from a real problem, and not just a tightly-specified exercise designed by the instructor. And I'm not sure you can really know a concept -- not in the way that a computer scientist needs to know it -- unless you can write a program using it for a real problem. If syntax is in the way, you simply need to buckle down and learn the syntax.

I don't have any answers on this but thought it was interesting that a calculus prof is running into the same kind of problem.

My compiler students are getting to the point where they should be deep in writing a parser for their language. Walking back from lunch, I was thinking about some very simple things they could do to make their lives -- and project -- better.

1.   Start.

Yes, start. If you read the literature of the agile software development world or even of the life hacker world, people talk about the great power that comes just from taking the first step. I've always loved the old Goethe quote about the power of committing to a course of action. But isn't this all cliché?

It is so easy to put off tracing your language grammar, or building those FIRST and FOLLOW sets, or attacking what you know will be a massive parsing table. It is so easy to be afraid of writing the first line of code because you aren't sure what the whole app will look like.

Take the first step, however small and however scary. I'm always amazed how much more motivated I feel once I break the seal on a big task and have some real feedback from my client or my compiler.

2.   Always have live code.

Live code is always better than ideas in your head. Brian Marick tells us so. One of the Gmail guys tells us so:

We did a lot of things wrong during the 2.5 years of pre-launch Gmail development, but one thing we did very right was to always have live code. ...

Of course none of the code from my prototype ever made it near the real product (thankfully), but that code did something that fancy arguments couldn't do (at least not my fancy arguments), it showed that the idea and product had real potential.

Your code can tell which ideas are good ones and which are bad ones. It can teach you about the app you are building. It can help you learn what your user wants.

I hear this all the time from students: "We have a pretty good handle on this, but no code yet." Sounds good, but... Live code can convince your professor that you really have done something. It can also help you ask questions and be submitted on the due date. Don't underestimate the value in that.

As Buchheit says from the Gmail experience, spend less time talking and more time prototyping. You may not be Google, but you can realize the same benefits as those guys. And with version control you don't have to worry about taking the wrong step; you can always back up.

3.   Don't forget what you know.

Okay, I have to admit that this did not occur to me on my walk home form lunch. This afternoon, a former student and local entrepreneur gave a department seminar on web app security. He twice mentioned that many of the people he hires have learned many useful skills in object-oriented design and software engineering, using system languages such as Java and Ada. When they get to his shop, they are programming in a scripting language such as PHP. "And they throw away all they know!" They stop using the OOP principles and patterns they have learned. They stop documenting code and testing. It's as if scripting occurs in a different universe.

As he pointed out after the talk, all of those skills and techniques and practices matter just as much -- no, more -- when using a language with many power tools, few boundaries, and access to all of his and his clients' data and filesystem.

When building a compiler in class, or any other large-scale team project in a capstone course, all of those skills and techniques and practices matter, too, and sometimes for the first time in student's career. This is likely the largest and most sophisticated program they have ever written. It is the first time they have ever had to depend on one or two or five other students to get done, to understand and work with others' code, to turn their own code other for the understanding and use of their teammates.

There is a reason that you are learning all this stuff. It's for the project you are working on right now.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A student reader sent me a message to say that he didn't click with my talk of 'embracing' failure. He prefers to think in terms of pushing through failure to reach success. So I found it interesting when I ran across a blog entry with a similar them (via The Third Bit) on the same day:

I'm writing this in order to talk about failure and coping.... I've got the failure down. So what about coping? ... failure is really information. You don't fail and therefore become a failure. You fail and in so doing you learn and gain more understanding.

... I've come to understand that if I'm not making mistakes it means I'm not trying hard enough, and I'm not pushing myself far enough.

In this article, David Humphrey recounts the details of a vexing experience trying to fix a bug. Humphrey uses the bug -- unresolved by the end of the article -- to explain how he feels about failing repeatedly. He isn't broken; he is empowered by the information he has captured. Whether we call that embracing failure, both the inevitability of failing and the knowledge we gain by failing, or coping, or gathering information, it seems to be an important trait of people who enjoy computing.

If you'd like to read more on Humphrey's ideas after he fixed his bug, check out his follow-up article.

A while back, I clipped this quote from a university publication, figuring it would decorate a blog entry some day:

The thing about a liberal arts education ... is it prepares you to fail successfully and learn from that failure. ... You will all fail. That's OK.

-- Jim Linahon

Linahon is an alumnus of our school who works in the music industry. He gave a talk on campus for students aspiring to careers in the industry, the theme of which was, "Learn to fail. It happens"

More recently, I ran across this as the solution to a word puzzle in our local paper:

You've got to jump off cliffs all the time and build your wings on the way down.

-- Ray Bradbury

Bradbury was one of my favorite authors when I was growing up (The Martian Chronicles mesmerized me!) This quote goes farther than Linahon's: what other people call failure is learning to fly. Do not fear.

A comment made at the Rebooting Computing summit about "embracing failure" brought these quotes back to mind, along with an e-mail message Rich Pattis wrote sometime last year. Rich talked about how hard our discipline must feel to beginners, because it is a discipline learned almost wholly by failure. Learning to program can seem like nothing more than an uninterrupted sequence failures: syntax errors, logic errors, boundary cases, ugly interface, .... I'm not a novice any more, but I still feel the constant drip of failure whenever I work on a piece of code I don't already understand well.

The thing is, I kinda like that feeling -- the challenge of scaling a mountain of code. My friends who program can at least say that they don't mind it, and the best among them seem to thrive in such an environment. I think that's part of what separates programmers from less disturbed people.

Then again, repeated failure is a part of learning many things. Learning to play a musical instrument or a sport require repeated failure for most people. Hitting a serve in tennis, or a free throw on the hardcourt, or a curve ball in baseball -- the only way to learn is by doing it over and over, failing over and over, until the mind and body come together in a memory that make success a repeatable process. This seems to be an accepted part of athletics, even among the duffers who only play for fun. How many people in America are on a golf course this day, playing the game poorly but hoping -- and working -- to get better?

Why don't we feel the same way about academics, and about computer programming in particular? Some small number seem to, maybe the 2% that Knuth said are capable of getting it.

I have heard some people say that in sports we have created mechanisms for "meaningful failure", though I'm not sure exactly what that means, but I suspect that if we could build tools for students and set problems before them that give them a sense of meaningful failure, we'd probably not scare off so many people from our early courses. I suspect that this is part of what some people mean when they say we should make our courses more fun, though thinking in terms of meaningful failures might give us a better start on the issue than simply mantras about games and robots.

I don't think just equating programming to sports is enough. Mitch Wand sent a message to the PLT Scheme mailing list this weekend on a metaphor he has been using to help students want to stick to the design recipes of How to Design Programs:

In martial arts, the first thing you learn is to do simple motions very precisely. Ditto for ballet, where the first thing you learn is the five positions.

Once those are committed to muscle memory, you can go on to combinations and variations.

Same deal for programming via HtDP: first practice using the templates until you can do it without thinking. Then you can go on to combinations and variations.

I like the analogy and have used a similar idea with students in the past. But my experience is that this only works for students who want to learn to programming -- or martial arts or ballet, for that matter. If you start with people who want to go through the process of learning, then lots of things can work. The teacher just needs to motivate the student every once in a while to stick with the dream. But it's already their dream.

Maybe the problem is that people want to play golf and the martial arts -- for whatever social, business, or masochistic reasons -- but that most people don't want to learn to program? Then our problem comes back to a constant theme on this blog: putting a feeling of power in peoples' hands when we show them programming, so they want to endure the pain.

One last quote, in case you ever are looking for a literary way to motivate students to take on tough challenges rather than little ones that acquiesce easily and making us feel good sooner:

What we choose to fight is so tiny!
What fights us is so great!
...
When we win it's with small things,
and the triumph itself makes us small.
...
Winning does not tempt that man.
This is how he grows: by being defeated, decisively,
by constantly greater beings.

This comes from Rainer Maria Rilke's The Man Watching. What a marvelous image, growing strong by being beaten -- decisively, less -- by ever greater opponents. I'm sure you professional programmers who have been tackling functional programming, continuations, Scheme, Haskell, and Erlang these last few years know just the feeling Rilke describes, deep in the marrow of your bones.

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

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

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

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

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

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

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

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

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

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

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

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

The Introduction

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

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

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

The Approach

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

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

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

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

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

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

The Spark

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

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

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

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

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

What about what excited us might?

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

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

History

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

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

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

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

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

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

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

About Computing

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

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

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

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

Programming

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

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

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

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

Closing

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

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

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

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

The latest edition of inroads, the quarterly publication of SIGCSE, arrived in my mailbox yesterday. The invited editorial was timely for me, as I finally begin to think about teaching this spring. Alfred Aho, co-author of the dragon book and creator of several influential languages and programming tools, wrote about Teaching the Compilers Course. He didn't write a theoretical article or a solely historical one, either; he's been teaching compilers every semester for the last many years at Columbia.

As always, I enjoyed reading what an observant mind has to say about his own work. It's comforting to know that he and his students face many of the same challenges with this course as my students and I do, from the proliferation of powerful, practical tools to the broad range of languages and target machines available. (He also faces a challenge I do not -- teaching his course to 50-100 students every term. Let's just say that my section this spring offers ample opportunity for familiarity and one-on-one interaction!)

Two of Aho's ideas are now germinating in my mind as I settle on my course. The first is something that has long been a feature of my senior project courses other than compilers: an explicit focus on the software engineering side of the project. Back when I taught our Knowledge-Based Systems course (now called Intelligent Systems) every year, we paid a lot of attention to the process of writing a large program as a team, from gathering requirements and modeling knowledge to testing and deploying the final system. We often used a supplementary text on managing the process of building KBS. Students produced documents as well as code and evaluated team members on their contributions and efforts.

When I moved to compilers five or six years ago after a year on sabbatical, I de-emphasized the software engineering process. First of all, I had smaller classes and so no teams of three, four, or five. Instead, I had pairs or even individuals flying solo. Managing team interactions became less important, especially when compared to the more intellectually daunting content of the compiler course. Second, the compiler students tended to skew a little higher academically, and they seemed to be able to handle more effectively the challenge of writing a big program. Third, maybe I got a little lazy and threw myself into the fun content of the course, where my own natural inclinations lie.

Aho has his students work in teams of five and, in addition to writing a compiler and demoing at the end of the semester:

• write a white paper on their source language,
• write a tutorial on using it, and
• close with a substantial project report written by every member of the team.

This short article has reawakened my interest in having my students -- many of whom will graduate into professional careers developing software and managing its development -- attend more to process. I'll keep it light, but these three documents (white paper, tutorial, and project report) will provide structure to tasks the students already have to do, such as to understand their source language well and to explore the nooks and crannies of its use.

The second idea from Aho's article is to have students design their own language to compile. This is something I have never done. It is also a feature that brings more value to the writing of a white paper and a tutorial for the language. I've always given students a language loosely of my own design, adapted from the many source languages I've encountered in colleagues' courses and professional experience. When I design the language, I have to write specs and clarifications; I have to code sample programs to demonstrate the semantics of the language and to test the students' compilers at the end of the semester.

I like the potential benefits of having students design their own language. They will encounter some of the issues that the designers of the languages they use, such as Java, C++, and Ada faced. They can focus their language in a domain or a technology niche of interest to them, such as music and gaming or targeting a multi-core machine. They may even care more about their project if they are implementing an engine that makes their own creation come to life.

If I adopt these course features, they will shift the burden between instructor and student in some unusual ways. Students will have to exert more energy into the languages of the course and write more documentation. I will have to learn about their languages and follow their projects much more intimately as the semester proceeds in order to be able to provide the right kind of guidance at the right moments. But this shift, while demanding different kinds of work on both our parts, should benefit both of us. When I design more of the course upfront, I have greater control over how the projects proceed. This gives me a sense of comfort but deprives the students of experiences with language design and evolution that will serve them well in their careers. The sense of comfort also deprives me of something: the opportunity to step into the unknown in real-time and learn. Besides, my students often surprise me with what they have to teach me.

As I said, I'm just now starting to think about my course in earnest after letting Christmas break be a break. And I'm starting none to soon -- classes begin Monday. Our first session will not be until Thursday, however, as I'll begin the week at the Rebooting Computing summit. This is not the best timing for a workshop, but it does offer me the prospect of a couple of travel days away from the office to think more about my course!

A student wrote to tell me that I had been Reddited again, this time for my entry reflecting on this semester's final exam. I had fun reading the comments. Occasionally, I found myself thinking about how a poster had misread my entry. Even a couple of other posters commented as much. But I stopped myself and remembered what I had learned from writers' workshops at PLoP: they had read my words, which must stand on their own. Reading over a thread that discusses something I've written feels a little bit like a writers' workshop. As an author, I never know how others might interpret what I have written until I hear or read their interpretation in their own words. Interposing clarifying words is a tempting but dangerous trap.

Blog comments, whether on the author's site or on a community site such as Reddit, do tend to drift far afield from the original article. That is different from a PLoP workshop, in which the focus should remain on the work being discussed. In the case of my exam entry, the drift was quite interesting, as people discussed accumulator variables (yes, I was commenting on how students tend to overuse them; they are a wonderful technique when used appropriately) and recursion (yes, it is hard for imperative thinkers to learn, but there are techniques to help...). Well worth the read. But I could also see that sometimes a subthread comes to resemble an exchange in the children's game Telephone. Unless every commenter has read the original article -- in this case, mine -- the discussion tends to drift monotonically away from the content of the original as it loses touch with each successive post. Frankly, that's all right, too. I just hope that I am not held accountable for what someone at the end of the chain says I wrote...

My daughters received a new game from their mom for Christmas. It's called Apples to Apples. Each round, one of the players draws a card with an adjective on it. The rest of the players choose noun cards from their hands that match the adjective. The judge chooses one of the nouns as the best match, and the player who played it wins that round. The objective of the game is to win the most rounds.

I could tell you many things more about the game and how it's played in my family, but there is really only one thing to say:

I stink at this game.

If I am in a three-person game, I finish third. Four players? Fourth. You name the number of players, and I can tell you where I'll finish. Last.

It doesn't seem to matter with whom I play. Recently, I've been playing with my wife and daughters. Last night, my wife's brother joined us. My wife and I have played this game before, with friends from my office. The result is always the same.

My weakness may be heightened by the lobbying that can be part of the game. Players are allowed to try to sell their answers to the judge. I'm not a good salesman and besides don't really like to sell. But that doesn't account for my losing. If we play in silence, I lose.

It's not that I'm bad at all word games. I like many word games and generally do well playing them. If nothing else, I get better after I play a game for a while, by figuring out something about the strategy of the game and the players with whom I play. But in this game, the harder I try to play well, the worse I seem to do.

This must be how students feel in class sometimes. There is some consolation -- that I might become more empathetic as a result of feeling this way -- but, to be honest, it's just a bad feeling.

Early last week, I spent the last couple of days before Christmas wrapping up the grades on my Programming Languages course for fall semester. While grading the final exam, I seemed surprised by something on almost every problem. Here are a few that stand out:

cons and list

... are not the same. We spent some time early in the semester looking at how cons allocates a single new cell, and list allocates one cell per argument. Then we used them in a variety of ways throughout the rest of the course. After fifteen weeks programming in Scheme, how can so many people confuse them?

Overuse of accumulator variables

... is endemic to undergraduate students learning to program functionally. Two of the exam problems asked for straightforward procedures following the structural recursion pattern. These problems were about as simple examples of structural recursion as you can find: The largest value in a binary tree is the larger of

• the largest value in the left subtree, and
• the largest value in the right subtree.

The zip of two lists is a list with a list of their cars consed into the zip of their cdrs. Many students used an accumulator variable to solve both problems. Some succeeded, with unnecessarily complex code, and some solutions buckled under the weight of the complexity.

Habits are hard to break. I have colleagues who tell me that OOP is easy. I look at their code and say, "yes, but...." The code isn't really OO; it just bears the trappings of classes and methods. Sequential, imperative programming habits run deep. An accumulator variable is often a crutch used by a sequential programmer to avoid writing a functional solution. I see that in my own code occasionally -- the accumulator is as often a code smell as a solution.

At a time when the world is looking to parallel computing in a multicore world, we need to find a way to change the habits programmers form, either by teaching functional programming better or by teaching functional programming sooner so that students form different habits.

Scheme procedure names

... are different than primitive procedure names in most other languages. They are bound to their values just like every other symbol. They can be re-bound, either locally or globally, using the same mechanisms used to bind values to any other names. This means that in this code:

    (lambda (f g)
      (lambda (x)
        (+ (f x) (g x))))

the + symbol is a free variable, bound at the top level to the primitive addition operator. After we talked about this idea several times through the semester, I threw the students a bone on the final with a question that asked students to recognize + symbol as a free variable in a piece of code just like this one. The bone sailed past most of them.

Bound and free variables

... remain a tough topic for students to grasp, at least from my teaching. We spent several days in class talking about the idea of bound and free variables, and then writing code that could check a piece of code for bound and free variables. One of those sessions made a point of pointing out that occurs bound does not equal does not occur free, and that occurs free does not equal does not occur bound. For one thing, a variable could occur both bound and free in the same piece of code. For another, it might not occur at all! Yet when a final exam problem asked students to define an occurs-bound? procedure, several of them wrote the one-liner (not (occurs-free? x exp)). If only they knew how close they were... But they wrote that one-liner without understanding.

Syntactic abstraction

... is an idea that befuddles many of my students even after half a semester in which we work with the idea. Our Quiz 3 is tough for many of the students; it is often their lowest quiz grade of the course. In past semesters, though, students seemed to go home after being disappointed with their Quiz 3 score, hit the books, and come away with some understanding. This semester, several students came to the final exam with the same hole in their knowledge -- including students with two of the top three scores for the course. This makes me sad and disappoints me.

I can't do much to ensure that students will care enough to hit the books to overcome their disappointments, but I can change what I do. The next time I teach this course, I will probably have them start by working with for and while constructs in their own favorite languages. Maybe by stripping away the functional programming wrapping and the Scheme code we use to encounter these ideas, they will feel comfortable in a more familiar context and see the idea of syntactic abstraction to be really quite simple.

Postlude

Am I romanticizing the good old days, when men were men and all students went home and learned it all? Maybe a little, but I had a way to ground my nostalgia. I went back and checked the grades students earned in recent offerings of this course, which had very much the same content and structure. The highest score this semester was higher than the top score in the two most recent offerings, by 2-4%. Overall, through, grades lower. In fact, after the top score, the entire group had shifter down a whole letter grade. I don't think the students of the recent past were that much smarter or better prepared than this group, but I do think they had different attitudes and expectations.

One piece of evidence for this conclusion was that this semester there were far more 0s in the final grid of grades. I even had a couple of 0s on quizzes, where students simply failed to show up. This is, of course, much worse than simply scoring lower, because one things students can control is whether they do their work and submit assignments. As I wrote recently, each person must control what he or she can control. I am not sure how best to get juniors and seniors in college to to adopt this mindset, but maybe I'll need to bring Twyla Tharp -- or Bobby Knight -- into my classroom.

As I type, my students are taking the final exam in my programming languages course. A couple might prefer to be reading my blog than taking an exam, but perhaps not. I always enjoyed final exams as a student. They marked the end of something and offered a challenge.

My students can also rest comfortable tonight in the notion that their duties for the course are behind them, yet I still face grading the behemoth I am foisting on them right now. Even still, I am already beginning to put this course behind me, thinking back to what we've learned and ahead to what comes next for a few us, the course on programming language translation.

In my mind, I keep coming back to a punch line I heard on TV the other night:

All I'm saying is, if you keep living and dying on whether or not a person changes, well... you're not gonna make it as a doctor, that's all.

This is Dr. Cox, the "sarcastic, bitter mentor" of the protagonist on the show Scrubs. I don't watch the show a lot, but I have seen this episode a few times, and it ends with a scene in which this line is the lone heartfelt moment among Cox's typical schtick. His protege is having a hard time accepting that one of his patients, who had sidestepped a cancer scare, lights up a cigarette as he leaves the hospital, fully intent on resuming a habit that may kill him. Cox wants the newbie to see that a doctor simply cannot take personally the behaviors of all his patients; all he can do is treat them and, as best he can, try to teach them how to be healthy. The rest is up to them.

Students are a lot like patients. They come to us for help -- not treatment, but presumably education. My role as "doctor" is, as best I can, to teach them how to think and act like a computer scientist or programmer. But not all students have the same commitment, or motivation, or resources as the rest. It's easy to get caught up our own desire to teach, excite, and communicate and forget that not every student will leave the room inspired or changed. If a teacher lives and dies in his own mind on whether or not every student in a class "gets it" or leaves the room changed, well, he is going to have a long and painful life in the classroom. Every course will seem a failure.

The news is not all that bleak, though. Some students leave the room inspired. That energy can carry me a long way. And most students leave a course changed, if only a little bit. For some, that may be all the farther it goes. But for others, that little change is a seed waiting for the right conditions to come along some time in the future. At that moment, it will bloom into something no one can predict.

I guess this week I'm feeling a bit like Uncle Bob, who has been writing a lot of code lately -- hurray! -- but is disappointed in his performance. Programmers think about what it is like to program in an ideal world, just as teachers idealize what will happen in the classroom. When they get into the trenches, though, they encounter their own weaknesses and frailty. I run into that as a programmer sometimes, and as a teacher, too. Like Uncle Bob, I can recite a litany of how badly I do what I do: continually fighting the demons that say, take it easy and just lecture; they'll get it; the constant allure of not grading an assignment thus not being able to give the prompt feedback I know that some students need; do what is expedient, not what's best; it will all work out in the end. But does it?

Uncle Bob closes with:

There is much I have yet to learn about writing software well. So, although after 56 years of life, and 43 years of programming, I have achieved a modicum of success, and even some glory, Chef Baglio is right. It is from that point that you really start to learn.

You start learning _here_, at this point, for whatever the current value of "this" is.

As I was thinking about my final exam last week, I started to wonder what terms and concepts would be most on my students' minds as they studied. So I created a wordle:

This makes for an odd summary of the semester, a flashlight onto my vocabulary, and an unusual piece of art.

Last month my wife and I had the good fortune to see a Broadway touring company perform the Tony Award-winning Movin' Out, a musical created by Twyla Tharp from the music of Billy Joel. I've already mentioned that I am a big fan of Billy Joel, so the chance to listen to his songs for two hours was an easy sell. Some of you may recall that I also wrote an entry way back called Start with a Box that was inspired by a wonderful chapter from Twyla Tharp's The Creative Habit. So even if I knew nothing else about Tharp, Movin' Out would have piqued my interest.

This post isn't about the show, but my quick review is: Wow. The musicians were very good -- not imitating Joel, but performing his music in a way that felt authentic and alive. (Yes, I sang along, silently to myself. My wife said she saw my lips moving!) Tharp managed somehow to tell a compelling story by stitching together a set of unrelated songs written over the long course of Joel's career. I know all of these songs quite well, and occasionally found myself thinking, "But that's not what this song means...". Yet I didn't mind; I was hearing from within the story. And I loved the dance itself -- it was classical even when modern, not abstract like Merce Cunningham's Patterns in Space and Sound. My wife knows dance well, and she was impressed that the male dancers in this show were actually doing classical ballet. (In many performances, the men are more props than dancers, doing lifts and otherwise giving the female leads a foil for their moves.)

Now I see that Merlin Mann is gushing over Tharp and The Creative Habit. Whatever else I can say, Mann is a great source of links... He points us to a YouTube video of Tharp talking about "failing well", as well as the first chapter of her book available on line. Now you can read a bit to see if you want to bother with the whole book. I echo Mann's caveat: we both liked the first chapter, but we liked the rest of the book more.

Since my post three years ago on The Creative Habit, I've been meaning to return to some of the other cool ideas that Tharp writes about in this book. Seeing Movin' Out caused me to dig out my notes from that summer, and seeing Mann's posts has awakened my desire to write some of the posts I have in mind. The ideas I learned in this book relate well to how I write software, teach, and learn.

Here is a teaser that may connect with agile software developers and comfort students preparing for final exams:

The routine is as much a part of the creative process as the lightning bolt of inspiration, maybe more. And this routine is available to everyone.

Oddly, this quote brings to mind an analogy to sports. Basketball coaches often tell players not to rely on having a great shooting night in order to contribute to the team. Shooting is like inspiration; it comes and it goes, a gift of capricious gods. Defense, on the other hand, is always within the control of the player. It is grunt work, made up of effort, attention, and hustle. Every player can contribute on defense every night of the week.

For me, that's one of the key points in this message from Tharp: control what you can control. Build habits within which you work. Regular routine -- weekly, daily, even hourly -- are the scaffolding that keep you focused on making something. What's better, everyone can create and follow a routine.

While I sit and wait for the lightning bolt of inspiration to strike, I am not producing code, inspired or otherwise. Works of inspiration happen while I am working. Working as a matter of routine increases the chances that I will be producing something when the gods smile on me with inspiration. And if they don't... I will still be producing something.

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

Running

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

Building Tools

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

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

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

40th Anniversaries

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

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

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

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

Programming Matters

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

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

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

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

While reading on-line this summer, I ran across a description of how keyless remote entry systems work. I can't find that page just now, but here is a nice description. I never knew how those things worked. Very cool indeed! As I was reading, the programmer in me soon was thinking, "I'd like to write that code". The teacher in me almost as quickly thought, "What a great example for for my programming languages course...": programs with state and shared data. A homework problem was waiting to be written!

This week we got to the point in the course at which this is a perfect homework problem. I started thinking about it, but the week was busy... Finally, the night before I was to post the assignment, I sat down to write my solution. Within an hour I have less than a page of code that implements:

• a random number generator, based on a C program from my grad school operating systems course, which itself was based on an article by Park and Miller in the Communications of the ACM, and


• a pair of functions that implement the remote entry idea for a single behavior (say, unlock) and up through the receiver re-syncing with a skipped-ahead transmitter.

While thinking before programming -- even agile programmers are allowed to do that -- I realized that "re-programming" a desynchronized transmitter/receiver pair would be beyond scope of my homework assignment and that multiple behaviors (say, unlock and lock, turning on an alarm, etc.) added complexity to the code but no interesting ideas. I also realized that there was no shared data in this problem, but two pieces of state held in common: identical random number generators and a key code.

As I programmed, it slowly dawned on me that this problem, in its full form, was surely beyond the scope of my homework assignment. I had a couple of other tasks for them to do, and the keyless entry problem would require both a whole assignment to itself and fairly detailed guidance for the students on how to implement a solution. The interaction between the transmitter and the receiver means that the solution code has to be developed and tested in parallel, and there turned out more to be more layers of indirection in the solution than I had expected: a lambda wrapping a letrec wrapping a let wrapping a letrec wrapping a lambda wrapping one final lambda!

That's more complexity than I care for my students to encounter in the context of this assignment. With more time and more of the assignment "real estate", I could perhaps leave design a solution to students and then guide them during the process. But this is a programming languages course, and I'm trying to keep the focus of the course on features of languages, not on the application of functional programming or Scheme.

(I do love to have students see functional programming and Scheme applied to "real problems", because so often they view the programming language applications as, well, not real. This problem is especially cool for that purpose, because the ability to create a simple closure over two simple functions is so useful here.)

Sigh. The opportunist in me, though, thought, "No problem. Perhaps can will demo the solving of this problem in class."

And now I had a new problem: The only code I have is the final version of my program.

I can still build a demo, designing a session around how I grew this program, but I will have to re-grow it in my mind and in my lecture notes. Unfortunately, the second time through a solution is never quite like the first for me, and in a way that effects the quality of result. The second implementation usually feels and looks a little too pat, a little too straightforward, too obvious. Most people don't learn much about how to build something by looking only at the final product, and when the final product looks inevitable at every turn, all hope is lost. The process of writing the code, and the decisions made along the way matter -- the insights and the false starts; the intermediate steps.

All I have is my final version. If only I had developed this program under version control! At least then I'd have a sequence of intermediate solutions that could help me recover the sequence of decisions and insights and false starts.

I know some people use version control for more than developing software; Martin Fowler has even wrote about putting his whole file system under Subversion. I may not want to go that far, but what about the particular case of developing code for a new demo, lecture, or presentation?

This seems like one of those ideas someone has already had and profited from. I'm just now getting it. Do you ever do this for purposes of teaching or exposition?

Oh, well. I had a lot of fun implementing this code, and that is always a welcome joy. I may yet show it off in class, if only as a finished product. We programmers are often like artists and other creators, and even like parents: we are so proud of our children that we simply must show everyone and brag on them! But turning this solution into a powerful class session about using state and mutually-referential functions must wait until I have more time. Maybe next time I'll try building my new idea code under version control and be able to move more quickly.

Now that keyless remote entry is off the table as a homework problem, I am back to the drawing board for a couple of new problems to round out this assignment. Well, the random number generator is a nice stateful problem in its own right. And if I can just simplify the idea of the transmitter/receiver pair, maybe I can create a problem in the spirit of keyless entry systems -- only with security circa 1970 -- that salvages some of my initial excitement for this problem. Hmm....

~~~~

Postscript.    I wrote the first draft of this entry last night, right after whipping up my solution and despairing. Current students of mine know that I did salvage the idea, because I have already set the homework problems in question before them! The simplification was easier to make than I had feared. The transmitter and receiver use a fixed code and can never be synched. That made all the difference in the complexity of the solution. I left the other parts for extra-credit...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We need a curriculum for doers, not monks.

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

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

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

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

Who am I being when I am not seeing
a connection in the eyes of others?
-- Benjamin Zander

I was all set to write an entry about "students these days", but I see that Mark Guzdial beat me to the punch. Two earlier entries chronicled my experience in class this semester. This is a course I have taught every third semester in recent years, and before that I taught it every year or even every semester for a few years stretching back to the mid-1990s. This has given me a longitudinal view of our student population as it has performed on common content, with common materials and a common approach in the classroom. Certainly the course has evolved a bit in that time, as I try to keep the course forward-looking as well as grounded in basic content. But with all those changes, I don't think the course's fundamental character has changed. If anything, I'd be inclined to say that I do a better job now than way back when, because I've learned how to do a better job. (That may be wishful thinking, of course.)

Yet this semester has felt more challenging than I remember. If I look back at this course over the years, though, can see that there have been signs of change. The last time we offered this course, I noted that students seemed less obviously engaged in the material than in recent times. That group turned out to be well-prepared and thoughtful, but with a quiet personality and a need to see how the course fit into their goals before they made an observable commitment. Maybe in the three years since the last offering before that we have begun to see a different kind of student in CS.

Guzdial describes one of the changes that may be responsible: the broadening of the population that attends college and, indeed, is expected to. With the widening of the pool, we are likely to see more students with varying commitments to the academic enterprise. We might also see students who are less well-prepared. A common hypothesis among faculty I know is that the CS student body we have built up since the dot.com bust has been different from the group we encountered before.

Maybe that's just another example of old fogies wishing for the good old days, but I don't think so. I think we have seen a much wider range of ability, preparation, and motivation in the newer student body than we had back in the "good old days" of the 1990s. With a larger, more diverse set of students attending college now than then, this is a natural outcome.

I don't think today's students learn differently, or have diminished capacity to learn, from exposure to the internet, iPods, and Wiis. And these students are, for the most part, as well-prepared as students before, at least when we account for the increased diversity of the pool. I do think that students have different motivations and different levels of motivation than previous classes.

One of our undergrads tells a story consistent with my observation. He runs free tutoring sessions as a public service to students in our intro programming courses. He wrote recently that he doesn't get as much traffic from CS majors (his primary audience) as he had hoped. On a particular night:

Interestingly enough, all three students were non-CS majors. I'm not entirely sure what that means overall. They are taking a class they don't need -AND- they are seeking help outside of class hours. That alone is unusual. We also discussed all the concepts on paper and each student hand wrote their own notes, which was surprising to me as well.

This tutor is one of our most talented and self-motivated students, so I'm not surprised that he would notice an apparent lack of motivation among his peers. Asking for help is an odd one. In my class, I have several strong students who are scoring lower than they do in other courses, yet only a very few have asked any questions. A couple have, but not until after a quiz that deflates their spirits. I've asked them why they haven't asked questions about the puzzling material earlier. The answers are a mix of optimism ("I just assume that I'll be able to figure this out"), pride ("I don't want to give up and ask for help"), and poor time management ("well, I didn't start the assignment until...").

I was a pretty good student, but I have vivid memories of getting up early one day my sophomore year, picking up a box of punch cards, and heading over to see my Assembler II prof promptly at the start of his 8 AM office hour because I was struggling with a now-forgotten JCL issue. (8 AM?! Many of my students say that 10 AM office hours are too early!) I'm optimistic and proud, but I was also motivated to succeed -- grade-wise, if nothing else. But I suspect that I probably wanted to learn more than I wanted to save face.

As Guzdial says, it may be that today's students are motivated by different things.

... the case for why something is worth learning is increasingly borne by the teacher, ... and the sense of value for what's to be learned is increased based in vocational terms.

This has always been an issue for me when teaching functional programming and Scheme, where the language, style, and ideas are foreign to what students tend to experience in the intro course language du jour and current professional practice. But I would think it'd be easier to motivate many functional programming concepts in a day when Python, Ruby, and even serious languages like C# and Java are bringing to the masses. (Maybe that says something about my skills as a motivator...)

In any case, rather than leave the burden for what's different now at the feet of our students, we CS instructors face the challenge of figuring out how to teach differently. Add this to changes in the discipline and the need for more non-CS students to incorporate computing into their professions and lives, and the challenge becomes even more "interesting".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Wow. Now I know what that means.

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

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

That's not right.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Primary entries:

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

Ancillary entries:

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

One of my most senior colleagues has recently become enamored of Facebook. One of his college buddies started using it to share pictures, so my colleague created an account. Within minutes, he had a friend request -- from a student in one of his classes. And they kept coming... He now has dozen of friends, mostly undergrads at our school but also a few former students and current colleagues.

Earlier this week, he stopped me in the hall to report that during his class the previous hour, a student in the class had posted a message on his own Facebook page saying something to the effect, "I can't keep my eyes open. I have to go to sleep!" How does the prof know? Because they are Facebook friends, of course.

Did the student think twice about posting such a message during class? I doubt it. Was he so blinded by fatigue or boredom that he forgot the prof is his friend and so would see the message? I doubt it. Is he at all concerned in retrospect, or even just a little sheepish? I doubt it. This is standard operating procedure for a college set that opens the blinds on it life, day by day and moment by moment.

We live in a new world. Our students live much more public lives than most of us did, and today's network technology knocks down the well that separates Them from Us.

This can be a good thing. My colleague keeps his Facebook page open in the evenings, where his students can engage him in chat about course material and assignments. He figures that his office hours are now limited only by the time he spends in front of a monitor. Immediate interaction can make a huge difference to a student who is struggling with a database problem or a C syntax error. The prof does not mind this as an encroachment on his time or freedom; he can close the browser window and draw the blinds on office hours anytime he wants, and besides, he's hacking or reading on-line most of the time anyway!

I'm uncertain what the potential downsides of this new openness might be. There's always a risk that students can become too close to their professors, so a prof needs to take care to maintain some semblance of a professional connection. But the demystification of professors is probably a good thing, done right, because it enables connections and creates an environment more conducive to learning. I suppose one downside might be that students develop a sense of entitlement to Anytime, Anywhere access, and professors who can't or don't provide could be viewed negatively. This could poison the learning environment on both sides of the window. But it's also not a new potential problem. Just ask students about the instructors who are never in their offices for face-to-face meetings or who never answer e-mail.

I've not had experience with this transformation due to Facebook. I do have a page, created originally for much the same reason as my colleague's. I do have a small number of friends, including undergrads, former students, current colleagues, a grade-school buddy, and even my 60+ aunt. But I use Facebook sparingly, usually for a specific task, and rarely have my page open. I don't track the comments on my "wall", and I don't generally post on others'. It has been useful in one particular case, though, reconnecting me with a former student whose work I have mentioned here. That has been a real pleasure. (FYI, the link to his old site seems to be broken now.)

However, I do have limited experience with the newly transparent wall between me and my students, through blogs. It started when a few students -- not many -- found my blog and began to read it. Then I found the blogs of a few recent students and, increasingly, current students. I don't have a lot of time to read any blogs these days, but when I do read, I read some of theirs. Blogs are not quite as immediate as the Twitter-like chatter to be found in Facebook, but they are a surprisingly candid look into my students' lives and minds. Struggles they have with a particular class or instructor; personal trials at home; illness and financial woes -- all are common topics in the student blogs I read. So, too, are there joys and excitement and breakthroughs. Their posts enlighten me and humble me. Sometimes I feel as if I am privy to far too much, but mostly I think that the personal connection enriches my relationship both with individual students and with the collective student body. What I read certainly can keep me on a better path as I play the role of instructor or guide.

And, yes, I realize that there is a chance that the system can be gamed. Am I being played by a devious student? It's possible, but honestly, I don't think it's a big issue. The same students who will post in full view of their instructor that they want to sleep through class without shame or compunction are the ones who are blogging. There is a cultural ethic at play, a code by which these students live. I feel confident in assuming that their posts are authentic, absent evidence to the contrary for any given blogger.

(That said, I appreciate when students write entries that praise a course or a professor. Most students current students are circumspect enough not to name names, but there is always the possibility that they refer to my course. That hope can psyche me up some days.)

To be fair, we have to admit that the same possibility for gaming the system arises when professors blog. I suppose that I can say anything here in an effort to manipulate my students' perceptions or feelings. I might also post something like this, which reflects my take on a group of students, and risk affecting my relationship with those students. One of my close friends sent me e-mail soon after that post to raise just that concern.

For the same reasons I give the benefit of the doubt to student bloggers, I give myself the benefit of the doubt, and the same to the students who read this blog. To be honest, writing even the few entries I manage to write these days takes a lot of time and psychic energy. I have too little of either resource to spend them disingenuously. There is a certain ethic to blogging, and most of us who write do so for more important purposes than trying to manipulate a few students' perceptions. Likewise, I trust the students who read this blog to approach it with a mindset of understanding something about computer science and just maybe to get a little sense of what their Dear Old Professor tick.

I know that is the main reason I write -- to figure out how I tick, and maybe learn a few useful nuggets of wisdom along the way. Knowing that I do so in a world much more transparent than the one I inhabited as a CS student years ago is part of the attraction.

Some days, things go well, beyond expectation. Enjoy them! Today was one for me.

I've been thinking a lot about how students learn a new style of programming or a language that is quite different from their experience. Every class has its own personality, which includes interaction style, interest in Big Ideas, and curiosity. Last night it occurred to me that another important part of that personality is trust.

I was grading a quiz and suddenly felt a powerful personal connection to Gunnery Sergeant Foley from one of my favorite movies, An Officer and a Gentleman. There is a scene halfway through the film when he catches the protagonist, Zack Mayo, running an illegal contraband operation out of his barracks. The soldiers are in their room one afternoon when Foley walks in and declaims, "In every class, there's always one guy who thinks he's smarter than me. In this class, that's you, Mayo." He then dislodges a ceiling tile to reveal Mayo's stash of contraband and lets everyone know the jig is up.

Beyond the occasional irrational desire I have to be Lou Gossett breaking the spirits of cocky kids and building them back up from scratch, while grading solutions to a particular exam problem I couldn't help but think, "In every class, there's always one guy who thinks he's smarter than me..." Some of the students seemed to be going out of their ways not to use the technique we had learned in class, which resulted in them writing complex, often incorrect code. More practically for them, they ended up writing more code than they needed, which spent extra time they didn't have the luxury of spending. I felt bad for them grade-wise, but also a little sad that they seemed to have missed out on the beautiful idea beyond the programming pattern they were not using.

(Don't worry, class. This irrational desire of mine is fleeting. I don't want your DOR. Quite the contrary; I am looking for ways help you succeed!)

Sometimes, I wonder if the problem is that students don't really trust me. Why should they? Sure, I'm the teacher, but they feel pretty good about their programming skills, and the patterns I show them may be different and complex enough that they'd rather trust their own skills than my claim that, say, mutual recursion makes life better. They'll learn that with enough experience, and then they may realize that they can trust me after all.

In many ways, though, a bigger part of the problem may be a failure of storytelling. On my side are the stories I tell to engage students in an idea and its use. To paraphrase Merlin Mann paraphrasing Cliff Atkinson, I need to tell a story that makes the students feel like an character with a problem they care about and then show how our new way of solving their problem -- their problem -- makes them winners in the end. I think I do a better job of this now than I did ten years ago in this course, but I always wonder how I can do better.

On their side is, perhaps, a failure of their own storytelling -- not just about bugs, as Guzdial writes, but about the problem domain itself, the data types at play, and the kind of problem they are solving. I suspect writing code over nested symbolic lists that represent programs is so different from the students' experience that many of them have a hard time getting a real sense of what is going on. As long as the domain and task remain completely abstract in the mind, the problems look almost like random markings on the page. Where to start? That disorientation may account for not starting in what seems to me to be the obvious location.

As a teacher, failures in their storytelling become failures in my storytelling. I need to reconsider how I communicate the "big picture" behind my course. Asking students to create their own examples is one micro-step in this direction. But I also need to think about the macro-level -- something like XP's notion of metaphor. That practice has proved to be a stumbling block for XP, and I expect that it will remain a challenge for me.

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

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

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

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

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

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

I had one of those agile moments on Wednesday. A colleague stopped by my office to share his good feeling. He had just come from a CS 2 lab. "I love it whenever I design a lab in which students work in pairs. There is such life in the lab!" He went on to explain the interactions within pairs but also across pairs; one group would hear what another was thinking or doing, and would ask about it. So much learning was in the air.

This reminded me of the old joke... Patient: "Doctor, it hurts when I do this." (Demonstrates.) "Can you help me?" Doctor: "Sure. Don't do that."

Of course, it reminded of the negative space around the joke. Patient: "Doctor, life is great when I do this." (Demonstrates.) "Can you help me?" Doctor: "Sure. Do more of that."

"But..." But. We faculty are creatures of habit, both in knowing and in doing. We just know we can't teach all of our material with students working in pairs, so we don't. I think we can, even when I don't follow my own advice. (Doctor, heal thyself!) We design the labs, so if we want students to work in pairs, we can have them work in pairs.

I've had one or two successful experiences with all pair programming all the time in closed labs. Back when we taught CS1 and CS2 in C++, in the mid-1990s, and I was doing our first-year courses a lot, I designed all of my labs for students working in pairs. I wish I could say I had bee visionary, but my motivation was extrinsic: I had 25-30 students in class and 15 computers in the lab. Students worked with different students every week, in pseudo-random assignments of my device.

My C++-based courses probably weren't very good -- I was relatively new to teaching, and we were using C++ after all -- and the paired programming in our lab sessions may have been one of the saving graces: students shared their perplexity and helped each other learn. When they worked on outside programming assignments for the course, they could call on a sturdy network of friends they had built in lab sessions. Without the pairs, I fear that our course would have worked well for very few students.

If something works well, let's try to understand the context in which it works, and then do it more often in those contexts. That's an agile sentiment, whether we apply it to pair programming or not. Whether we apply it at the university or in industry. Whether we apply it to software development or any other practice in which we find ourselves engaged.

A couple of weeks ago, I mentioned that I might have my students create their own examples for a homework assignment. Among the possible benefits of this were:

• helping the programmers to write down their understanding of the problem in a concrete way early in the process
• giving the programmers a way of to ask concrete questions early in the process -- and reason to ask the questions
• helping the programmers know how much code to write and when to stop

I tried this and, as usual, learned as much or more than my students.

Getting students to think concretely about their tasks is tough, but asking them to write examples seemed to help. Most of them made a pretty good effort and so fleshed out what the one- or two-line text description I gave them meant. I saw lots of the normal cases for each task but also examples at the boundaries of the spec (What if the list is empty?) and on the types of arguments (What if the user passes an integer when the procedure asks for a list? What if the user passes -1 when the procedure expects a non-negative integer?) In class, before the assignment was due, we were able to discuss how much type checking we want our procedures to do, if any, in a language like Scheme without manifest types. Similarly, should we write examples with the wrong number of arguments, which result in an error?

I noticed that most students' examples contrasted cases with different inputs to a procedure, but that few thought about different kinds of output from the procedure. Can filter return an empty list? Well, sure; can you show me an example? I'll know next time to talk to students about this and have them think more broadly about their specs.

Requiring examples part-way through the assignment did motivate questions earlier than usual. On previous assignments, if I received any questions at all, they tended to arrive in my mailbox the night before the programs were due. That was still the case, but now the deadline was halfway through the assignment period, before they had written any code. And most of the class seemed happy to comply with my request that they write their examples before they wrote their code. (They are rarely in a hurry to write their code!)

Did having their own examples in hand help the students know how much code to write and when to stop? Would examples provided by me have helped as much? I don't know, but I guess 'yes' to both. Hmm. I didn't ask students about this! Next time...

Seeing their examples early helped me as much writing their examples early helped them. They got valuable feedback, yes, but so did I. I learned a bit of what they were thinking about the specific problems at hand, but I also learned a bit of what they think about more generally when faced with a programming task.

My first attempt at this also gave me some insight about how to describe the idea of writing examples better, and why it's worth the effort. The examples should clarify the textual description of the problem. They aren't about testing. They may be useful as tests later, but they probably aren't sufficient. (They approximate are a form of black box testing, but not white box testing.) As clarifiers, one might take an extreme position: If the textual description of the problem were missing, would the examples be enough for us to know what procedure to write? At this extreme, examples with the wrong number and type of arguments might be essential; in the more conventional role of clarifying the spec, those examples are unnecessary.

One thing that intrigued me after I made this assignment is that students might use their examples as the source material for test-driven development. (There's that word again.) I doubt many students consider this on their own; a few have an inclination to write and test code in close temporal proximity, but TDD isn't a natural outgrowth of that for most of them. In any case, we are currently learning a pattern-driven style of programming, so they have a pretty good idea of what their simplest piece of code will look like. There is a nice connection, though. Structural recursion relies on mimicking the structure of the input data, and that data definition also gives the programmer an idea about the kinds of input for which she should have examples. That s-list is either an empty list or a pair...

I'm probably reinventing a lot of wheels that the crew behind How to Design Programs smoothed out long ago. But I feel like I'm learning something useful along the way.

On the way out of class today, I ran into the colleague who teaches in the room after me. I apologized for being slow to get out of the room and told him that I had talked more than usual today. From the looks on the faces of my students, I gathered that they needed a bit more. What they really needed was more time with same material. Most of all, they needed me to slow down -- rather than cover more material, they needed a chance to think more about what they had just learned. My way of doing that was to keep talking about the current example.

I told my colleague that there is probably a pedagogical pattern called Shut Up. And if not, then maybe there should be.

He said that the real pattern is Ask a Question.

I bowed down to him.

We talked a bit more, about how we both desire to use the Ask a Question pattern more often. We don't, out of habit and out of convenience. Professors lecture. It's what we do. The easiest thing to do is almost always: just keep talking, saying what I had planned to say.

I give myself some credit for how I ended class today. At the very least, I realized that I should not introduce new material. I was able to Let the Plan Go [1]

Better than sticking to a plan that is off track for my students is to keep talking, but about same stuff, only in a different way. This can sometimes be good. It gives me a chance to show students another side of the same idea, so that they might understand the idea better by seeing it from different perspectives.

Is Shut Up better than that? Sometimes. There are times when students just need... time -- time for the idea to sink in, time to process.

Is Ask a Question better still? Yes, in most cases. Even if I show students an idea, rather than telling them something, they remain largely passive in the process. Asking a question engages them in the idea. More and different parts of their brain can go to work. Most everything we know about how people learn says that this is A Good Thing.

Now, I do give myself a little credit here, too. I know about the Active Student pattern [2] and have changed my habits slowly over time. I try to toss in a question for students every now and then, if only to shut myself up for a while. But my holding pattern today probably didn't use enough questions. I was under time pressure (class is almost over!) and didn't have the presence of mind to turn the last few minutes into an exercise. I hope to do better next time.

~~~~~

[1] You can read the Let the Plan Go pattern in Seminars, an ambitious pattern language by Astrid Fricke and Markus Völter.

[2] The Active Student pattern is documented in Joe Bergin's paper "Some Pedagogical Patterns". There is a lot of good stuff in this one!

I'm a big tennis fan. I like to play and would love to play more, though I've never played well. But I also like to watch tennis -- it is a game of athleticism and strategy. The players are often colorful, yet many of the greatest have been quiet, classy, and respectful of the game. I confess a penchant for the colorful players; Jimmy Connors is my favorite player of all time, and in the 1990s my favorite was Andre Agassi.

Agassi's chief rival throughout his career was one of the game's all-time greats, Pete Sampras. Sampras won a record fourteen Grand Slam titles (a record under assault by the remarkable Roger Federer) and finished six consecutive years as the top-ranked player in the world (a record that no one is likely to break any time soon). He was also one of the quiet, respectful players, much more like me than the loud Agassi, who early in his career seemed to thrive on challenging authority and crossing boundaries just for the attention.

Sampras recently published a tennis memoir, A Champion's Mind, which I gladly read -- a rare treat these days, reading a book purely for pleasure. But even while reading for pleasure I could not help noticing parallels to my professional interest in software development and teaching. I saw in Sampras's experience some lessons that that we in CS have also learned. Here are a few.

Teaching and Humility

After Sampras had made his mark as a great player, one of his first coaches liked to be known as one of the coaches who helped make Sampras the player he was. Sampras gave that coach his due, and gave the two men who coached him for most of his pro career a huge amount of credit for honing specific elements of his game and strategy. But without sounding arrogant, he also was clear that no coach "made" him. He had a certain amount of native talent, and he was also born with the kind of personality that drove him to excel. Sampras would likely have been one of the all-time greats even if he had had different coaches in his youth, and even as a pro.

Great performers have what it takes to succeed. It is rare for a teacher to help create greatness in a student. What made Sampras's pro coaches so great themselves is not that they built Sampras but that they were able to identify the one or two things that he needed at that point in his career and helped him work on those parts of his game -- or his mind. Otherwise, they let the drive within him push him forward.

As a teacher, I try figure out what students need and help them find that. It's tough to do when teaching a class of twenty-five students, because so much of the teaching is done with the group and so cannot be tailored to the individual as much as I might like and as much as each might need. But when mentoring students, whether grad students or undergrads, a dose of humility is in order. As I think back to the very best of my past students, I realize that I was most successful when I helped them get past roadblocks or to remove some source of friction in their thinking or their doing. Their energy often energized me, and I fed off of the relationship as much as they did.

Agile Moments

The secret of greatness is working hard day in and day out. Sampras grew as a player because he had to in order to achieve his goal of finishing six straight years as #1. And the only way to do that was to add value to his game every day. This seems consistent with agile developers' emphasis on adding value to their programs every day, through small steps and daily builds. Being out there every day also makes it possible to get feedback more frequently and so make the next day's work potentially more valuable. For some reason, Sampras's comments on a commitment to being in the arena day in and day out reminded me of one of Kent Beck's early bits of writing on XP, in which he proclaimed that, and the end of the day, if you hadn't produced some code, you probably had not given your customer any value. I think Sampras felt similarly.

Finally, this paragraph from a man who never changed the model of racket he used throughout his career, even as technology made it possible for lesser players to serve bigger and hit more powerful ground strokes. Here he speaks of the court on which his legend grew beyond ordinary proportion, Centre Court at the All England Club:

I enjoyed the relative "softness" of the court; it was terrific to feel the sod give gently beneath my feet with every step. I felt catlike out there, like I was on a soft play mat where I could do as I pleased without worry, fear, or excessive wear and tear. Centre Court always made me feel connected to my craft, and the sophisticated British crowd enhanced that feeling. It was a pleasure to play before them, and they inspired me to play my best. Wimbledon is a shrine, and it was always a joy to perform there.

Whatever else the agile crowd is about, feeling connected to the craft of making software is at its heart. I like to use tools that give gently beneath my feet, that let me make progress without worry and fear. Even ordinary craftsmen such as I appreciate these feelings.

The latest issue of ACM's on-line pub Ubiquity consists of Chauncey Bell's My Problem with Design, an article that first appeared on his blog a year ago. I almost stopped reading it early on, distracted by other things and not enamored with its wordiness. (I'm one to talk about another writer's wordiness!) I'm glad I read the whole article, because Bell has an inspiring take on design for a world that has redefined the word from its classic sense. He echoes a common theme of the software patterns and software craftsmanship crowd, that in separating design from the other tasks involved in making an artifact we diminish the concept of design, and ultimately we diminish the quality of the artifact thus made.

But I was especially struck by these words:

The distinctive character of the designer shapes each design that affects us, and at the same time the designer is shaped by his/her inventions. Successful designs shape those for whom they are designed. The designs alter people's worlds, how they understand those worlds, and the character and possibilities of inhabiting those worlds. ...

Most of our contemporaries tell a different story about designing, in which designers fashion or craft artifacts (including "information") that others "use." One reason that we talk about it this way, I think, is that it can be frightening to contemplate the actual consequences of our actions. Do we dare speak a story in which, in the process of designing structures in which others live, we are designing them, their possibilities, what they attend to, the choices they will make, and so forth?

(The passage I clipped gives the networked computer as the signature example of our era.)

Successful designs shape those for whom they are designed. In designing structures for people, we design them, their possibilities.

I wonder how often we who make software think this sobering thought. How often do we simply string characters together without considering that our product might -- should?! -- change the lives of its users? My experience with software written by small, independent developers for the Mac leads me to think that at least a few programmers believe they are doing something more than "just" cutting code to make a buck.

I have had similar feelings about tools built for the agile world. Even if Ward and Kent were only scratching their own itches when they built their first unit-testing framework in Smalltalk, something tells me they knew they were doing more than "making a tool"; they were changing how they could write Smalltalk. And I believe that Kent and Erich knew that JUnit would redefine the world of the developers who adopted it.

What about educators? I wonder how often we who "design curriculum" think this sobering thought. Our students should become new people after taking even one of our courses. If they don't, then the course wasn't part of their education; it's just a line on their transcripts. How sad. After four years in a degree programs, our students should see and want possibilities that were beyond their ken at the start.

I've been fortunate in my years to come to know many CS educators for whom designing curriculum is more than writing a syllabus and showing up 40 times in a semester. Most educators care much more than that, of course, or they would probably be in industry. (Just showing up out there pays better than just showing up around here, if you can hold the gig.) But even if we care, do we really think all the time about how our courses are creating people, not just degree programs? And even if we think this way in some abstract way, how often do we let it seep down into our daily actions. That's tough. A lot of us are trying.

I know there's nothing new here. Way back, I wrote another entry on the riff that "design, well done, satisfies needs users didn't know they had". Yet it's probably worth reminding ourselves about this every so often, and to keep in mind that what we are doing today, right now, is probably a form of design. Whose world and possibilities are we defining?

This thought fits nicely with another theme among some CS educators these days, context. We should design in context: in the context of implementation and the other acts inherent in making something, yes, but also in the context of our ultimate community of users. Educators such as Owen Astrachan are trying help us think about our computing in the context of problems that matter to people outside of the CS building. Others, such as Mark Guzdial, have been preaching computing in context for a while now. I write occasionally on this topic here. If we think about the context of our students, as we will if we think of design as shaping people, then putting our courses and curricula into context becomes the natural next step.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On the PLT Scheme mailing list, someone asked why the authors of How to Design Programs do not provide unit tests for their exercises. The questioner could understand not giving solutions, but why not give the examples that the students could use to guide their thinking. A list member who is not an HtDP c-author speculated that if the authors provided unit tests then students would not bother to implement their own.

Co-author Matthias Felleisen responded "Yes" and added this stronger assertion:

I have come to believe that being able to make up your own examples (inputs, outputs) is the critical step in solving most problems.

Writing examples is one of the essential elements of the "design recipe" approach on which Felleisen et al. base How to Design Programs. The idea itself isn't new, as I'm sure the book's authors will tell you. Some CS teachers have been requiring students to write test cases or test plans for many years, and the practice is similar to what some engineers learn to do from the start of their education. Heck, test-driven design has gone from being the latest rage in agile development to an accepted (if too infrequently practiced) part of creating software.

What HtDP and TDD do is to remind us all of the importance of the practice and to make it an essential step in the student's or developer's programming process.

What struck me by Matthias's response is that making up examples is the critical step in writing code. It is certainly reasonable, for so many reasons, among them:

• It forces the programmer to write down her understanding of the problem in a concrete way early in the process. Concrete understanding is always preferable to the fuzzy-minded understanding that follows reading a problem statement. Besides, writing a program requires that level of understanding.


• Having examples in hand gives the programmer a way of talking to the client or teacher to see if her understanding matches that of the person who "owns" the problem.


• It gives the programmer a way of knowing how much code to write and so when to stop. Most students can use that guidance.

I usually give my students several examples as a part of specifying problems and ask them to write a few of their own. Most don't do much on their own and, uncharacteristically, I don't hold them accountable often enough. My next programming assignment may look different from the previous ones; I have an idea of how to sneak this little bit of design recipe thinking into the process.

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

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

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

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

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

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

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

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

My younger daughter entered seventh grade this year, and at the orientation session last week the teachers made a point of saying that timeliness matters. If a student turns in late work, they will be "docked". My mind ended up wandering away as I thought about what this means for her grade. If she ends up with a B, what does that say about her mastery of the material? About her timeliness?

Perhaps I was primed for this daydream by a conversation I had had recently with a colleague who teaches one of our CS1 sections. Traditionally, he has had a very lax policy on late work: get it done, even late, and he would grade it straight up. His thinking was that this would encourage students to stick with assignments and get the practice they need. In past years, this policy has worked all right for him, but in the last year or so he has noticed more students putting off more assignments, many students turning in several or all of their assignments at the end of the semester. Not surprisingly, these students do poorly on the exams for lack of practice and so do poorly in course overall.

He and I contrasted his policy with mine, which is that late work is not accepted for grading. I'm always willing to look at a student program after the deadline, but it will not count for credit. This is one of the few ways in which I draw a hard line with students, but I find that it encourages students to take assignments seriously and to get practice regularly throughout the semester.

Until I heard my daughters' teachers talk about their policy, I'm not sure I had realized quite so clearly: My late work policy conflates mastery of content with professional work habits. A student can learn everything I want him to learn and more, yet earn a low grade by not submitting assignment on time.

To be honest, that's probably not a problem. In our current system, it is not entirely clear what a grade means anyway. Across universities, across departments at the same university, and even across faculty within the same department, grades can signify very different results. Conflating the evaluations of knowledge and behavior is only one source of variation, and almost certainly not the most significant.

Employers who hire our graduates want employees who know their discipline and who deliver results in a professional many. Still, I can't help but think what it would be like to offer two grades for a course, one for content and one for all that other stuff: timeliness, teamwork, neatness, etc. Instructor: "Johnny, you get a B for your understanding of operating systems, and a D for behavior, because you don't color within the lines." Employer: "We really need someone with the right professional skills for this position; let's teach him what he needs to know after he gets here."

Increasingly, I am drawn to a competency-based scheme for grading what students know. West and Rostal have been advocating this idea for a while, as part of a larger overhaul of CS education. It takes some work do right, but the effect on what we expect of our students might be worth it. Unfortunately, within the broader university culture of grades and effort and time-delimited courses carved out of a discipline's body of knowledge, moving in this direction creates logistic costs that may be larger than the pedagogical ones.

In any case, I've been thinking of ways I might change my grading scheme. I'm not likely to change the "no late work" policy, at least not for upper-division courses, and to be honest I find that very few students have a problem getting their work in on time in face of the policy. (Whether the work is complete is another matter...) Still, I might consider changing how the homework grade figures into the overall grade. Perhaps instead of counting homework as 30% of the grade, I could count it for "up to 30%" and let the student select the percentage. Students who would rather not bother with falderol of assignment requirements could stake more or all of their grade on exams; students who worry about exams could stick with 30%. Perhaps having that be their choice and not mine would motivate them even more to make a good faith effort at completing the entire assignment on time.

I suppose that my real concern in all this thinking is with my seventh-grader. She, my wife, and I already pay close attention to her work behavior, trying help her develop good habits. She's already a conscientious student who just needs to learn how to manage her own time. We also pay close attention to her understanding of the content in her classes, but her assignment and test grades are a big part of how we track that progress. As the grades she receives begin to include both elements, we'll want to pay closer attention to her understanding of the material in other ways. I guess I'm in the same position as the employers who hire my students now!

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

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

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

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

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

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

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

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

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

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

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

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

Fall semester is just around the corner. Students will begin to arrive on campus next week, and classes start a week from Monday. I haven't been able to spend much time on my class yet and am looking forward to next week, when I can.

What I have been doing is clearing a backlog of to-dos from the summer and handling standing tasks that come with the start of a new semester and especially a new academic year. This means managing several different to-do lists, crossing priorities, and generally trying to get things done.

As I look at this mound of things to do I can't help being reminded of something Jeff Patton blogged a month or so ago: two secrets of success in software development, courtesy of agile methods pioneer Jim Highsmith: start sooner, and do less.

Time ain't some magical quantity that I can conjure out of the air. It is finite, fixed, and flowing relentlessly by. If I can't seem to get done on time, I need to start sooner. If I can't seem to get it all done, I need to do less. Nifty procedures and good tools can help only so much.

I need to keep this in mind every day of the year.

Oh, and to you students out there: You may not be able to do less work in my class, but you can start sooner. You may have said so yourself at the end of last semester. Heck, you may even want to do more, like read the book...

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

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

A Discipline, Not Just a Job

During his talk, I think, Owen Astrachan said:

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

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

When Good Students Are Too Good

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

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

Context Complicates

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

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

Overshooting Your Mark in the Classroom

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

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

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

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

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

A recent entry mentioned that one advantage of short source code for beginners is a smaller space for errors. If a student writes only three lines of code, then any error in the program is probably on one of those three lines. That's better than looking for errors in a 100-line program, at least when the programmer is learning.

This assertion may seem like an oversimplification. What if the students writes a bunch of three-line procedures that call one another? Couldn't an error arise out of the interaction of multiple procedures, and thus lie far from the point at which it is discovered? Sure, but that is usually only a problem if the student doesn't know that each three-line procedure works. If we develop the habit of testing each small piece of code well, or even reasoning formally about its behavior, then we can have confidence in the individual pieces, which focuses the search for an error in the short piece of code that calls them.

This is, of course, one of the motivations behind the agile practices of taking small steps and creating tests for each piece of code as we go along. It is also why programming in a scripting language can help novices. The language provides powerful constructs, which allow the novice programmer to say a lot in a small amount of code. We can trust the language constructs to work correctly, and so focus our search for errors in the small bit of code.

Even still, it's not always as simple as it sounds. I am reminded of an article on a new course proposed by Matthias Felleisen, in which he argues for the use of a limited proof language. Even when we think that a 'real' language is small enough to limit the scope of errors students can make, we are usually surprised. Felleisen comments on the Teach Scheme! experience:

... we used to give students the "simple language of first-order Lisp" and the code we saw was brutal. Students come up with the worst possible solution that you can imagine, even if you take this sentence into account in your predictions.

This led the Teach Scheme! team to create a sequence of language levels that expose students to increasingly richer sets of ideas and primitives, culminating in the complete language. This idea has also been in the Java world, via Dr. Java. Another benefit of using limited teaching languages is that the interpreter or compiler can provide much more specific feedback to students at each level because it, too, can take advantage of the smaller space of possible errors.

Felleisen does not limit the idea of limited language to the programming language. He writes of carefully introducing students to the vocabulary we use to talk about programming:

Freshmen are extremely limited in their vocabulary and "big words" (such as 'specification' and 'implementation') seem to intimidate them. We introduce them slowly and back off often.

When I read this a couple of weeks ago, it troubled me a bit. Not because I disagree with what Felleisen says, but because it seems to conflict with something else I believe and blogged about couple of weeks ago: speak to students in real language, and help the students grow into the language. I have had good experience with children, including my own, when talking about the world in natural language. What makes the experience of our students different.

As I write this, I am less concerned that these conflict. First, Felleisen mentions one feature of the CS1 experience that distinguishes it from my kids' experience growing up: fear. Children don't spend a lot of their time afraid of the world; they are curious and want to know more. They are knowledge sponges. CS1 students come out of a school system that tends to inculcate fear and dampen curiosity, and they tend to think computer science is a little scary -- despite wanting to major in it.

Second, when I speak to children in my usual vocabulary, I take the time to explain what words mean. Sometimes they ask, and sometimes I notice a quizzical curious look on their faces. Elaboration of ideas and words gives us more to talk about (a good thing) and connects to other parts of their knowledge (also good). And I'm sure that I don't speak to kids using only thirteen-letter words; that's not the nature of regular life, at least in my house. In computing jargon words of excessive length are the norm.

So I don't think there's a contradiction in these two ideas. Felleisen is reminding us to speak to students as if they are learners, which they are, and to use language carefully, not simplistically.

Even if there is a contradiction, I don't mind. It would not be the only contradiction I bear. Strange as it may sound, I try to be true to both of these ideas in my teaching. I try not to talk down to my students, instead talking to them about real problems and real solutions and cool ideas. My goal is to help students reach up to the vocabulary and ideas as they need, offering scaffolding in language and tools when they are helpful.

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

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

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

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

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

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

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

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

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

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

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

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

Loui's discussion of programming pragmatics reminds me of my time in studying knowledge-based systems. Our work was pragmatic, in the sense that we sought to model the algorithms and data organization that expert problem solvers used, which we found to be tailored to specific problem types. Other researchers working on such task-specific architectures arrived at models consistent w