Last week I trekked up to beautiful Andersonville, Chicago to take Dave Beazley’s week-long course on The Structure and Interpretation of Computer Programs.
In this series, I’ll share memorable insights from the course (here’s where you can see all the posts so far). But I suspect you have one of two questions right now, so I want to spend this post addressing them both.
- What is SICP?
- SICP in a single week? Are you out of your MIND?!
- It’s a book.
I highly recommend you invest in the course it if you’ve written enough code to compare and contrast a few different languages’ rules around collections, mutability, and threads.
SICP has a reputation as a dense, esoteric book. Though the book has flaws, I think its reputation comes from the circumstances of its use. MIT used SICP as the textbook for its introductory electrical engineering and computer science course from 1987 until at least 2005, and several universities copied the idea. Here’s the thing: if you’ve never written code, SICP is probably not the book for you.
Why: SICP focuses on concepts in programming language design. These high-level abstractions are necessary to produce a deeper understanding of how programming languages work, but they are not sufficient.1
To fully appreciate these concepts, you also need to have used some programming languages.
Why: humans can remember, and even respond emotionally, to a single level of abstraction. Understanding, though, develops at the transitions between levels of abstraction. Bret Victor articulates this phenomenon beautifully:2
How do we explore? If you move to a new city, you might learn the territory by walking around. Or you might peruse a map. But far more effective than either is both together — a street-level experience with higher-level guidance.
Likewise, the most powerful way to gain insight into a system is by moving between levels of abstraction. Many designers do this instinctively. But it’s easy to get stuck on the ground, experiencing concrete systems with no higher-level view. It’s also easy to get stuck in the clouds, working entirely with abstract equations or aggregate statistics.
This can work in both directions: up or down. So, it’s possible for folks who are new to programming to dive into SICP, come out somewhat confused but having committed parts of it to memory, then start using a few different programming languages and retroactively make connections to the material. It’s doable.
However, for the majority of people, it is the hard direction. The easier direction is to work with a few different programming languages and then jump levels of abstraction to understand why those languages work the way they do.
Why: many programming languages have a lower barrier to entry than SICP does. Take Python. The reputation of the Python learning experience alone is far more favorable than the reputation of the SICP learning experience. Python’s explicit formatting, expressive syntax, and broad functionality make it discoverable (easy to poke around and get something working, which motivates further learning). The cornucopia of tutorials written for the language and pride that Pythonistas take in supporting new Python developers add to a relatively pleasant onboarding.
It also helps, of course, to have a skilled teacher. It’s clear that Dave knows this book well and has taught this course a bunch of times. On many occasions, he departs from the lessons in the book where he finds the explanations sketchy or the examples distracting. He replaces these with explanations and examples that have worked better for his students. You’ll see some of this in future posts that discuss specific concepts we covered.
I want to get to the course concepts, so I’m keeping this post on the shorter side. The bottom line: SICP in a week isn’t unrealistic for polyglot programmers, even though the book has a reputation for incomprehensibility among folks for whom it was their first exposure to computer science.
I also got lucky enough to learn the material from Dave, who does an excellent job of explaining things and choosing examples for students to work through. He didn’t pay me to say this; in fact, he didn’t even know this post was going to happen. I’d be remiss not to mention it, though, prior to getting into the examples.
In the next post, we’ll begin looking at some of the concepts from the first chapter of the book.
1 According to a guy who taught the course, the course numbered among students’ favorites. He seems to be getting his data from alumni emailing him to tell him this. I suspect these emails come from students who took easily to the course material; perhaps many of them had some CS background beforehand. The majority, for whom this wasn’t the case, aren’t sending emails to tell the professor. Instead, they are on the internet aiding and abetting this book’s reputation as incomprehensible, which absolutely exists regardless of how many emails this professor receives.
2 If you like getting meta with it, you’ll notice that Bret switches between levels of abstraction to explain the value of transitioning between levels of abstraction. First, he provides a specific, relatable example (learning a new city). Then he explains the phenomenon at work and describes some trends in a specific population’s awareness of it.
If you liked this post, you might also like:
Watching me scream at computers (just kidding, I have a pretty long fuse…usually)
The API Design Series (people have opinions about APIs, so get some tea first)