Hi. Sorry on the lack of updates — I've got net connection, but it turns out I've been way too busy to write proper accounts of the talks so far. I have been keeping notes, though, so I'll catch you all up as soon as I can.

Estonia itself is quite a strange place, Old Town is a very-old-looking area and it's difficult to tell what's real and what's a recreation. Parts of it are very pretty, though, so that's nice.

More later ...

Greetings from Tallinn! Looks like I've got Internet access at the conference here. More later ...

So it seems that other people have noticed the article I linked to in my last post too. Matt Jadud over at Untyped wrote an interesting rant about about it that points out its obvious deficiencies. In the course of doing so, he points out the ACM's Model Curricula documents, a great resource I didn't know existed before. I can't yet comment on the particular documents, but Matt's comments about them combined with the obviously tremendous effort they must have been to create really illustrates that teaching is very very hard.

Dave Herman noticed my post and comments on my definition of computer science. I suggested that it was "the study of how to best systematically solve problems"; Dave prefers a more general formulation by Raatikainen: "How do we automate?" I made a comment over on his weblog about it which you can read over there if you care to. (Just realize that when I wrote it there were three comment spams above it that said things like "Great post! There are lots of resources on my web page about immigrating to Canada!")

Anyway, I'm headed off to Estonia later today for the Scheme Workshop and ICFP. I hope I'll be able to update this webpage from there; if so I'll try to do a regular conference update as it goes on, and if not I'll try to take good notes and do one comprehensive update when I get back.

For as long as I've been paying attention to computer science as an academic field, people have been arguing about how to design an undergraduate curriculum. To what extent is CS a branch of math, or of electrical engineering? How should academic CS be tied to industry? To what extent do we teach good-programming skills like modular design or "design patterns" or abstraction (which has apparently been discovered yet again and dubbed the "Don't Repeat Yourself" principle by the Ruby people), and to what extent do we teach more academic subjects like computability, rigorous asymptotic analysis and the like?

I found today that O'Reilly's OnLamp website recently ran an opinion piece on the subject. If you take even a glance at it you'll see that the author is very much an industry-only guy and it's tempting to just say that if he thinks diplomas from DeVry are more useful than ones from MIT then it's just his loss. But though I think this article betrays its author's fundamental misunderstanding of what a computer science education is all about, and as much as I think some of the `academic' skills he denigrates are actually quite a bit more useful than the `practical' skills he praises (hey, I'm a PL person, I think every problem is a compiler problem!), I'm going to go out on a limb and say he's got a good point. More specifically, I think his list of things that CS departments ought to be teaching probably contains more good ideas than bad ones.

The way I read it, his list breaks down into two major categories and a little miscellany. The first major category is what I'd call programming competence, which he addresses with the items:

• The basics of Programming
• Problem analysis
• Basics of good code architecture: Loose Coupling, etc.
• Testing, Debugging, Performance, Re-factoring
• Code Reading
• The importance and tools of Planning
• Patterns and Anti-Patterns
• OO Design, Interfaces
• Architectures: client/server, SOA, P2P, etc.

What these things have in common is they're all skills that have nothing to do with particular problems but only with managing the general difficulty of writing a program, particularly a big program that needs to exist for a long time. That isn't usually thought of as a core CS topic, but it should be: computer science is fundamentally the study of how to best systematically solve problems. The academics have traditionally decided that 'best' means 'using the smallest set of resources possible,' but in situations where resources are relatively abundant and programs live a long time I think it makes more sense to define 'best' as 'most maintainably'. Therefore I see no reason why topics like abstraction shouldn't be considered as fundamental to computer science education as efficiency is.

The second major category is what I'd call modern programming cultural awareness. I'd include these items:

• Real world Databases
• A 'Big' language or two (Java, C#, C/C++)
• A scripting/'agile' language or two (PHP, Perl, Python, Ruby)
• XML (DOM/SAX, XSLT/XPath, etc.)
• Internationalisation, Localisation, Encoding, Unicode
• Interface Design, Usability, Accessibility, HCI
• Security
• Common Protocols (TCP/IP, HTTP, SMTP, FTP)
• Source control, change management
• The typical Software lifecycle
• Metadata, Information Architecture, etc.

These are all about learning the state of the art in industry for solving various problems. I certainly don't think a CS undergrad should focus on this — that's what industry is about, after all — but I can't say I'd be that happy graduating a CS undergrad who didn't know anything about any of them. To the extent that computer science is an engineering discipline, its practitioners ought to have a working knowledge of the great feats of engineering that have already been done, and ought to be conversant in the language the engineers use. As a programming languages researcher, I'm not a big fan of C++, say, but it's so much a part of the culture that it was absolutely useful for me to have learned it.

And then there are some miscellaneous items. I certainly agree that anyone with a bachelor's degree ought to learn about Grammar, punctuation, concise and clear writing but in general these points are kinda silly. And of course this list leaves off practically the entirety of what computer science is traditionally about, and I don't want to give anyone the impression that I think we ought to replace all our algorithms and computability classes with lectures about design patterns and Unicode or that SAX vs DOM ought to replaces P vs NP. And please don't take me to mean that I basically endorse this guy's view of how CS departments ought to be. But I do think that academic CS and the programming industry benefit very little from each other's existence, and that's a shame. Physics, biology, and even psychology enjoy a fruitful exchange of ideas between their industrial and academic branches — computer science should too, and I think those of us in academia can do our part by trying to understand the industry programmers even when they don't seem to understand us.

This is an odd, reasonably pointless expression that returns 7 in any R5RS-compliant Scheme implementation:

(let ((x (lambda (z) z)) (y 7))
    (let ((x (lambda () x))) y))

This is an infinite loop in any R5RS-compliant Scheme implementation:

(let let ((x (lambda (z) z)) (y 7))
    (let ((x (lambda () x))) y))

Gotta love overloaded syntax.

So, I'm a big fan of the "everything I do appears on Lambda the Ultimate" policy.

I'm pretty surprised about this latest mention, though, since I'd figure that only a pretty narrow range of specialists would make it past the abstract.

Finally! As of today, I am done with my Scheme Workshop paper.

Now all I've got to do is figure out how to keep an audience awake for 45 contiguous minutes while at the same time presenting the material that paper contains ...

Strange how things work out. I scheduled a more-or-less spontaneous visit out to Boston, nominally to do a few things related to online surveys but more realistically just to see the people I know out there. I mentioned to Robby that I was going, he called Matthias, and now I'm going to be giving a talk at Northeastern about the interoperability stuff.

The Meaning of Multilanguage Programs

Jacob Matthews
University of Chicago, Chicago

Monday, October 17, 2005

Software developers have long understood that real applications are built out of components in different languages and connected using a variety of different strategies. For example, foreign function interface systems like SWIG connect high-level languages to low-level languages; component frameworks like COM and CORBA connect high-level languages to each other; and domain-specific languages such as Yacc are embedded into their host languages in such a away that control and data flow back and forth between the programs.

In this talk I will present a general technique for modelling the operational semantics of multilanguage systems such as these. The technique is simple and general, and surprisingly connects traditional multilanguage systems to seemingly unrelated concepts such as contracts.

Joint work with Robert B. Findler

Pretty cool. I'm very excited about this talk because it'll be the first time I'll have given a public talk about the interoperability stuff, though it's probably been nearly a year that I've been working on it. Also, since the talk will be on October 17 and ESOP's deadline is October 14, I may decide to take my talk outline and turn it into an ESOP paper as I'm writing it. That'd be good. I've already figured out easily enough for a paper, but I haven't really properly documented it yet, so this will be a good opportunity for that.

The Scheme Workshop paper revisions are done — it's been massively rewritten since the first submission, so hopefully people will find it clear and useful. Even for computer science, in which paper turnaround time is a few months rather than a few years, writing and revising papers seems like a distraction from research sometimes. Of course writing things up is crucial, but I'd much rather be making progress than fiddling with figures and wording to make the things I was working on last year make sense to other people.

Unrelatedly: there's been a lot of activity with the PLT web server recently, and a lot of new features are coming in. There's now a new feature that allows a servlet to attach a special k-url handler to expired k-urls — finally it's possible to give good servlet timeout messages! I can't tell you how much it irked me that there was no good way to give someone a message telling them that their session had expired and what to do to make things work again.