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

[iabervon.livejournal.com]

Personally, I think 6.170 should be in C, or at least start in C, because you can't really teach the fundamentals of what is going on with OOP in a language which handles all of the fundamentals for you, and OOP in Scheme isn't the same (since Scheme doesn't have any static typing, so method tables don't make sense). Since Java (or CLU) takes care of implementing inheritance and interfaces, it's hard for someone who knows only Java to pick up C (to the extent of being able to do complex programs), because they don't know how Java does the things they rely on.

I'd also be pleased if the courses using microcontrollers switched to using gcc to compile C for avr, because it's completely standard C (with an obviously limited standard library).

Aside from that, the main part of learning new languages is really finding out their weird quirks: syntax errors can't be detected until they're reached, because symbols can be added to scopes at any time; NULL isn't equal to itself; allocating a new object is faster on the whole than modifying and reusing an old object; you need to escape things an implausible number of times.

Of course, the languages I've been asked to know for jobs are: C++ (back when C++ was a completely different language from what it is now), Scheme, Java, Haskell (which I didn't know), C (bit of C++, but not using any significant language features), Java again, C for microcontrollers and otherwise, and Java again. So my impression of real languages is Java, C, and maybe Scheme and Haskell.

[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.

[arcanology.livejournal.com]

I vigorously disagree about teaching 6.170 in C. But I don't think Java is correct either, for a huge number of reasons it's not a good teaching language. CLU was a lot better, if only because it was so totally bent on teaching you the thing it was teaching you.

Real languages accumulate too much cruft and too many libraries to be good at teaching. Except for C, which assuming you ignore the libraries doesn't accumulate cruft. It IS cruft.

Which is not to say everyone shouldn't learn some C. They should. But it's not the correct one to start in, or to do a class about design in.

I dunno about the survey of extras either - that would be like learning to cook by doing a semester in a sausage factory. Most peripherals are so incredibly ill designed (don't get me started about the genius who distinguished tab from spaces in early make files, or XML-flavor-of-the-day) that you'd get a huge drop-out rate right in the middle of that course. Also vomiting during exams.

Which actually leads to another answer about "why can't X teach CS majors how to write code". Which is dude, I've read a lot of code now, and apparently ALMOST NO ONE teaches how to write code. Or maybe, people just suck.

I agree that MIT has to teach how to learn a programming language - the best way to do that being to make you use a variety of them. That's thing one. But the other thing it needs to teach is program design independent of language (which is why it's nice to teach that in a useless language like CLU). I don't care if you can code in C like god's own compiler, if your design is like some of the designs I've seen recently what you've got is a pile of crap that runs really fast.

[nuclearpolymer.livejournal.com]

Actually, having interviewed some folks, and having sat in on some debriefs of other interviews, I think MIT would best serve its students by teaching them how to be comfortable talking with people and presenting themselves as smart, capable people. I feel like this company is pretty reasonable about both valuing and recognizing intelligence, but it seems like MIT students are at a big disadvantage compared to the average new grad as far as being able to meet people, make the people like them, and make the people believe they are competent. Getting good at doing rush may get you more jobs than getting good at coding.