Harry R. Schwartz

Code writer, sometime Internet enthusiast, attractive nuisance.

The author at the Palais du Luxembourg in Paris, November 2022. hacker news gitlab sourcehut pinboard librarything 1B41 8F2C 23DE DD9C 807E A74F 841B 3DAE 25AE 721B


British Columbia



The Classical Code Reading Group of New York


Published .
Tags: meetups, computer-science, nyc.

Many fields, especially in the humanities, have a more-or-less agreed-upon body of work that they consider canonical. Everyone in the field is expected to be reasonably familiar with these works, and thereby share a common set of allusions and metaphors that permeate their thinking and subsequent work.

Software engineering, however, doesn’t have such a canon. We have plenty of canonical books and papers, and a few canonical programs, but little canonical code.

That’s a shame. We’ve tried to address this problem with design patterns, but each one is an abstraction without a concretion until you’ve found some useful examples; it’s a bit like trying to read The Hero with a Thousand Faces before you’ve watched Star Wars. Our associations with “Enkidu,” “Dr. Watson,” and “Han Solo” are much richer than our associations with “Hero’s Friend.” In the same way, “Composite” is much less evocative than <the image you mentally translate “Composite” into>1.

George and I have just started the Classical Code Reading Group of New York to help correct this perceived deficiency. It’s a knock-off of a suspiciously similar group started by our colleague Mike Burns in Stockholm. Every month we’ll be gathering to discuss some potentially canonical pieces of code.

This month we did a comparative analysis of the v5, v7, *BSD, and GNU implementations of echo. The format was similar to a seminar: we hooked up a projector and went through each implementation line-by-line, discussing any features of the code that we thought were interesting. We’d ask questions when we didn’t understand something, and we’d occasionally hit StackOverflow when none of us understood it.

The differences were extreme! The v5 implementation (from 1974) was only ten lines long, and worked exactly as you’d expect.2 Conversely, the modern GNU implementation is 272 lines of bewildering flags, case statements, and hex-to-bin conversions.

The whole process took about three hours. It was exhausting, but fun! We all got to learn about the various implementations of a classic Unix utility, and we got some concrete ideas about how we’d go about building our own implementation. I’m not sure it was the programming equivalent of Gilgamesh, but it’s a start.

We plan on looking at a couple of other Unix utilities in the next few months. There’s also been some interest in checking out some OS internals (possibly the OpenBSD scheduler, or selected parts of Plan 9), and I’d love to go through some of the old Genera code for the Lisp machines.

If you’re in the New York area, consider joining up! If not, why not start your own local chapter? Feel free to shoot me an email—I’d be happy to help you get started!

  1. Personally, I think of recipes! The cake recipe uses the frosting recipe, and so on. 

  2. One sometimes hears stories about Dennis Ritchie and Ken Thompson cobbling together whole new versions of Unix over long weekends—this seems much more believably now! 

You might like these textually similar articles: