I was reading this month’s edition of ACM Queue magazine and I came across (until now) two gems.
The first one is at the end of an interview of Michael Stonebraker, creator of Ingres (ancestor of PostgreSQL) and now adjunct professor of computer science at MIT. He is being interviewed by Margo Seltzer, one of the founders of Sleepycat Software (now owned by Oracle), makers of Berkeley DB. She is now professor in computer science at Harvard.
Here is the gem:
STONEBRAKER […] I think MIT has some of the smartest people on the planet. So does Stanford. So does Berkeley.
SELTZER There’s another school up the river, Mike, that you’re missing.
STONEBRAKER I applaud your efforts to improve computer science at Harvard, and I wish Harvard would get deadly serious about computer science because there’s a tremendous upside that you can realize over time.
SELTZER Well, come meet our students!
Those two are (amicably) arguing about whether MIT is better than Harvard and Margo Seltzer says “Well, come meet our students!”. I find this beautiful… and enlightening. This is THE metric to use to judge a university: are the students good or not!?!
I dream of a University of Mauritius capable of producing young Torvalds, Jobs or Gates every year.
Programming in the 2000’s
The second gem is in an article written by Michi Henning, chief scientist at ZeroC, makers of Ice. He writes about APIs and how they should be designed. At one point, he goes lyrical about how programming should be taught in universities:
Back in the late ’70s and early ’80s, when I was cutting my teeth as a programmer and getting my degree, much of the emphasis in a budding programmer’s education was on data structures and algorithms. They were the bread and butter of programming, and a good understanding of data structures such as lists, balanced trees, and hash tables was essential, as was a good understanding of common algorithms and their performance tradeoffs. These were also the days when system libraries provided only the most basic functions, such as simple I/O and string manipulation; higher-level functions such as bsearch() and qsort() were the exception rather than the rule. This meant that it was de rigueur for a competent programmer to know how to write various data structures and manipulate them efficiently
We have moved on considerably since then. Virtually every major development platform today comes with libraries full of pre-canned data structures and algorithms. In fact, these days if I catch a programmer writing a linked list, that person had better have a very good reason for doing so instead of using an implementation provided by a system library.
Similarly, in the ’70s and ’80s, if I wanted to create software, I had to write pretty much everything from scratch: if I needed encryption, I wrote it from scratch; if I needed compression, I wrote it from scratch; if I needed inter-process communication, I wrote it from scratch. All this has changed dramatically with the open source movement. Today, open source is available for almost every imaginable kind of reusable functionality. As a result, the process of creating software has changed considerably: instead of creating functionality, much of today’s software engineering is about integrating existing functionality or about repackaging it in some way. […]
Little seems to have changed since then: my son, who is currently working toward a software engineering degree at the same university where I earned my degree, tells me that still no one bothers to explain these things. (Bold text mine)
Beautiful. Instead of focussing on implementing a linked list, it is better to teach young programmers (i.e. first year students) how to use one from the standard library of any modern programming language.
It’s important for young programmers to understand the characteristics of linked lists, things like the complexity of common operations, and what is feasible with them and not. Then, in a second course, the CS students (and not the IT students) could learn about implementing such data structures.
It’s difficult to resist something as obvious as this.
