Tuesday, December 23, 2008

Stroustrup on What's Wrong With CS Programs

Similar to thinking of Joel Spolsky (and me), Bjarne Stroustrup (the inventor of C++) says the way we teach CS today is broken.  That is, it is at odds with the needs of the industry.  Having just completed a Masters in CS I can say first hand that this is true.  Some of what I learned was applicable to my work at Microsoft, but I could see the tension in the higher-level classes especially between the needs of preparing someone for research and preparing them for industry.  Research is not about programming.  It is about thinking in new and innovative ways about problems.  Industry needs good programmers and the best solutions to problems.  CS research students often ignore the best solutions to problems because those have already been discovered and you can't get published writing about the same thing again.  Industry prefers the proven solutions. 

Stroustrup bemoans the use of Java in so many programs today.  He doesn't attack Java per se but rather the emphasis on the libraries.  Students don't learn to solve fundamental problems (like sorting) because the library can do that for them.  It is easy to become an expert in Java rather than an expert in programming, something Rovert Dewar states well in this interview.  When the Java (or C# or Ruby) language wanes in popularity, it is the underlying CS skills that translate, not the intimate knowledge of the Java collections hierarchy.  I have a more fundamental problem with higher-level languages for learning.  It is important to learn how the machine works because someday everyone will be stuck with a leaky abstraction and will have to solve the deeper problem.  Without an understanding of what is below the byte code (or code), doing so can become very difficult.  It is easy to code oneself into a corner without knowing it if the understanding of the underlying system is missing.

He also talks about the lack of quality in the code written by students.  Too many projects are littered with magic constants, not well factored, etc.  This probably comes from the fact that code written for classes is thrown away.  Most of my professors never even asked for our code let alone actually read it.  A TA in my OS class actually said they didn't care about memory leaks.  In a freaking OS class of all things!!! 

The takeaways:

  • Learn a lower-level language.  Joel Spolsky says everyone should learn C.  I'm inclined to agree.  It's not too hard to learn and it is as close to the metal as you usually want to get.

  • Learn to express your ideas in more than 1 language.  Each is a little different.  Learning other languages gives you tools to think about problems in new ways.  This also ensures your knowledge is about the algorithms, not the base class libraries.


  1. "Everyone should learn C" - I strongly believe in this but not as a first language. I think Scheme should be taught as a first language to translate some of the fundamemtal mathematical concepts into Computing and let the student get an idea for computing from a purely mathematical perspective. Then follow it up with C. One should also taste C++.  And then to Java/C#. And finally to the dynamic language paradigm - Ruby, Python. Somewhere in between one should dabble with functional programming - Haskell, F#, Scala, Erlang to name a few. Taking a microcontroller course has helped me see many things that were just black boxes to me, so if one is up to it add it to the list. That should be a solid platter.

  2. I've had a similar argument with a CS lecturer in the past, when after interviewing a few honours CS graduates, found out they couldn't program and knew precious little about current computer technology and techniques.  The response I got was that CS wasn't about teaching programming, and I'd be better off with Computer applications grads.  As it happens, I ended up hiring engineering grads with domain knowledge who had an interest in programming.  So it goes.
    I agree that learning low level langauges is hugely important, as it forces you to learn how to abstract for yourself, rather than rely on another persons abstractions.  IMHO, if you can't abstract you can't really program.  If you start by teaching languages with very rich libraries, you lend the false impression that all the hard work has already been done.  I think we see the effect of this in so many modern slow and bloated applications.  Programmers don't want to be responsible for performance, UI or a host of other items; they expect the libraries and hardware to take up the slack.
    I wonder how many of todays CS grads could write a game like DOOM on a 8mhz VGA DOS box.