ezyang’s blog

the arc of software bends towards understanding

Class Reflections

Last February, I posted about classes that I was going to be taking. Here are some reflections, now that final projects and examinations are over.

6.005: Software Construction. Teaching students how to engineer large software projects is one of the oddest paradoxes that you might encounter in academic life. The institute is certainly capable of teaching concepts, tools and methodologies, but, to actually be capable of constructing a system from scratch? It's not really something you can learn, it something that you have to do. And the amount of work you have to put in to start getting the taste of real code as opposed to school code (which gets thrown away at the end of the term) doesn't fit into one term. We've joked that MIT ought to have a two part series, where the second part you are asked to go modify some code you wrote a year ago in the face of shifting requirements. (Unfortunately, I suspect a large number of people will rewrite the thing: one of the problems of not actually being able to do large systems.)

When you get past this fundamental issue, the class was relevant and even a smidge enjoyable. While I didn't personally get much out of it, I was delighted to see the class trace course across all of the big tricky ideas that I encountered when I was cutting my teeth as a programmer: roughly, the course can be divided into state machines, functional ideas and relational modeling. Despite what others say, I find these formalisms useful, and the key ways I helped develop intuition for what a traditional imperative program should smell like. Unfortunately, each of these are really big ideas, and the course doesn't manage to do it justice.

6.02: Intro to EECS II. MIT seems to like threes: for 6.02 the big three was signals, encodings and networks. The class was a pleasant walk through the three subjects, even though, while the class professes to be "introductory", none of the topics are what I'm really interested these days in computer science.

One of the notable rough patches I hit taking the course was when the class hit frequency analysis. I'm a big believer in understanding the underlying principles behind complex systems: it's one of the reasons why the calculus driven mechanical physics class worked so much better for me. Here, this predisposition was counterproductive: as Robert put it (and I paraphrase), yes, you could do it that way, but it is messy and not particularly insightful.

6.045: Automata, Computing and Complexity. So much fun! Scott Aaronson is a charming lecturer and after dealing with the bread and butter of automata and complexity (which the course teaches well; as one math major taking the class put it, "I can actually understand these lectures!") it veers off into the magical worlds of cryptography, probably approximately correct learning and quantum computing (three out of ten questions on the comprehensive final, to be precise). By the end, you will know how to conduct a Diffie-Helman key exchange, why babies might be able to break RSA, and when to apply a Hadamard gate to a qubit! Unfortunately the graders weren't exactly "quick" about grading problem sets, but in my opinion 6.045's troubles were solely administrative.

6.945: Large-scale Symbolic Systems. The subject-matter of the class is well worth having in the toolkit of any enterprising programmer: combinators, pattern matching and generic dispatch all our powerful tools with wide applicability in many systems. You also learn how to use continuations (gee!)

Sussman as a lecturer is an interesting phenomenon, especially when you reach the ending lectures when they are essentially talking about ideas that they cooked up last night. It's rare that electrical engineering and highly symbolic programming come together, but that's precisely the problem Sussman knows best: he knows how to solve circuit engineering and he wants to figure out the implementation details of an essentially artificially intelligent system that has this knowledge too. Unfortunately, if you're not completely versed in this analysis the analogies being made may be difficult to understand, and this was a primary blocking point later on in the term. Feedback was late to nonexistent; take this course if you don't need too much motivation to learn about these things.

21M.283: Musicals of Stage and Screen. I watched lots of musicals. It was great.

2 Responses to “Class Reflections”

  1. Cesium says:

    As I believe Josh said:

    foo.getClass().newInstance();

    There’s your reflection for the day.

  2. Josh says:

    I think 6.035 actually did involve a large enough system that it taught good design by implicit punishment (“when you have to go back at the end of term and make this work with FancyOptimization, you’ll be sorry”). Our team wound up writing about 10,000 SLOC over the course of the term. I doubt this would be sustainable for a class everyone had to take, though; it’s just too much work to justify on that large a scale.

Leave a Comment