An MIT Education Opens Doors

[dmaze]

I've heard a rant a couple of times -- around work, even -- along the lines of "why can't schools like MIT teach CS majors how to write code?" There are a couple of directions this goes. One is from interviewing too many people who did a "compiler" doctorate, and so they've spent the past six years doing type systems in ML. Another comes out of interviewing recent grads and expecting them to know C++/Python/Ruby/... and discovering that they only know Java and Scheme. "Shouldn't they have learned some real languages?"

I think the thing MIT needs to teach (not that I have any idea how to teach it) is how to learn a programming language. On some level every programming language is like Scheme or Java; perhaps it has explicit pointers (C/C++) or a stronger type system (Haskell) or is purely stack-based (PostScript) but none of these are fundamentally different. Maybe one thing that would be interesting is a 6-unit programming language overview? Spend a month on C, and a couple of weeks in Haskell/ML land, and then say "right, now here's Python and it's just like these other languages; here's Visual Basic and it's just like these other languages."

There should also be a little encouragement for side projects. If you want to learn how databases work, or how to write Makefiles, an actual project with some direction could provide inspiration. I don't know how many people graduate without taking any real programming classes besides 6.001, 6.170, and 6.034. Perhaps SIPB could produce one-sheets that say "hey, you could use MySQL and Python and the Census TIGER data to make your own maps!" or "hey, you could build Web pages using XSLT!" and provide support/hints. It's a thought.

Comments

[nonnihil.livejournal.com]

I'm with iabervon here. I am a good computer scientist because I know all kinds of cool stuff (mostly best done in Scheme). But I am a kick-ass computer programmer because I spent three years writing nothing but C -- macro-heavy setjmp/longjmp cross-platform standards-compliant code from hell.

Languages are languages -- I've used 40 of them at last count -- but some are special. C is incomparable. Java is fascinating (in good and bad ways). Scheme was a revelation at the time, though it got clunky pretty quickly. And the number of people with fond memories of CLU is really remarkable.

(Actually, I see a lot of that. CLU got a lot of things right. Even non-MIT people with CLU experience liked it. I think there's a huge latent CLU-nostalgia out there...)

An MIT education taught me how to learn languages effortlessly. That's been incredibly useful to me, because there are so many of the damned things (and so few worth more than a few minutes learning effort). What would have been most useful are two things: A hard-core practical '033-like lab in C (targeting multiple OS platforms, of course, and with horrible buggy library code like in '034), and a survey not of languages but of things you have to wire languages to -- databases, Makefiles, GUIs, filesystems, pipes, XML flavour-of-the-day, dumb-ass VB apps, installation scripts, HA watchdogging, and the like -- a solid warning about the 80% of programming that's really just plumbing.

[ukelele.livejournal.com]

From what I've seen, the way you've learned languages is being confronted with a project that required you to know them.

I suspect this is true of many people. If so, the way for MIT to teach programming languages is not to teach programming languages, per se -- beyond getting everyone a solid grounding in one, or maybe two if the second is built on very different principles -- but to give people projects which are best (or only) solved through the application of different computer languages and expect people to learn them. With, of course, more support than would be available for that in the real world, but on the left-hand side of the O'Reilly book--actual class spectrum.