Monday, September 19, 2005

How do we automate?

Read this excellent and reasonable post from Jacob Matthews on undergraduate curriculum in computer science.

Let me call attention to Jacob's characterization of CS: "computer science is fundamentally the study of how to best systematically solve problems." I think it's interesting to compare this to Knuth's definition of computer science (pp. 5-6) as the answer to Forsythe's question "what can be automated?" (With some quick googling I found a slight generalization of this formulation to the broader question "how do we automate?")

It's useful to place Jacob's definition in the context of our research culture. You could describe us as belonging to the academic diaspora of Matthias Felleisen, whose profound textbook How to Design Programs and corresponding pedagogy permeate our approach to computer science. (The book's title is an homage to Polya's How to Solve It, a landmark work in the history of mathematical pedagogy, which sought to elevate math education beyond the realm of black art by providing students with a systematic process for solving problems rigorously.) The HtDP approach to teaching computer science is to give students a repeatable process for solving problems--this is systematic both in the sense that students are given a dependable process that they can reliably use to solve new problems, and in the sense that expressing the solution in terms that a computer can execute and evaluate is more formal and reliable than a rote hand-calculation.

Nevertheless, I like Knuth's and Raatikainen's definitions. Computer science is not always about problems--both in research and industry, I think there's a place for exploration where the discovery of applications may not follow until later. The real common thread seems to be the ability to describe any process in a formal way so that it can be specified without unnecessary implementation detail and yet in a way that it can be repeated reliably.

2 comments:

Jacob said...

Okay, I've immigrated to Canada, found a personal success coach, and had an energy drink, and now I'm ready to respond to your post. I have to admit that I didn't really choose the phrase "how to best systematically solve problems" very carefully, and to the extent I was watching my words it was to make sure that I emphasized "best" so I could then point out the multiple interpretations of that word.

That said, I will freely admit to a bias towards thinking of computer science as "solving problems" rather than simply automating. What I don't like about the Knuth formulation is that there are plenty of things that are automatic — transmissions, thermostats, machine guns — without being the sort of thing you'd associate with computer science. It seems to me that the notion of automatically solving problems gets closer to the meat of the matter; every program, subroutine or algorithm I can think of can be posed as the answer to a "How do I ... ?" problem, whereas that's not true of machine guns and those other automated things. "How do I find whether an item is in a set?" A linear list search algorithm is an explanation of one possible answer; a database is another. "How do I convert all the files in a given directory from DOS to Unix newline conventions?" The bash line "dos2unix directory/*" is a concise but precise explanation of that answer.

I can't say I'm happy with my phrase either, mostly because I think the word "problem" still to mushy (you're right that it comes straight from Matthias, incidentally); maybe "data manipulation problem" would be a better phrase but that seems like begging the question to some extent. But I think something needs to be there, distinguishing us from those automatic dishwashers, automatic teller machines and "Automatic for the People" listeners. :)

vincent douzal said...

Raatikainen passed away in 2008.
The link is broken, and there is no easy way to find:
In Essence Of Computer Science

Can anyone make it available?