Programming

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.

I’ve decided to teach the Programming Methodology course to first year Computer Science & Engineering students as from next academic year. I love programming. And I want to share my enthusiasm to the young people who join the CSE department. For me, programming is art and, fortunately, I am not alone to think that.

This is the course outline from the official CSE programme:

Pseudocode; Structured Programming Techniques; Program Structure; Simple Data Type; Control Structures; Modularity; Structured Data Types; Introduction to Object Oriented Programming; Programming Style and Testing, Abstract Data Types, Arrays, Linked Lists, Stacks, Queues, Trees, Graphs, Operations on Trees and Graphs.

(Astute readers will have noticed that ; (semicolons) are used initially and , (commas) afterwards – this is an indication that this one year-long course is the concatenation of two previous semester-long courses – Programming Methodology and Data Structures)

Lately, I have been discussing with some colleagues about the reasons why many of our current students have lots of difficulties to tackle this course. One reason might be that many of them have chosen CS for the bad reasons (I don’t want to get into that…) and they don’t have the necessary skills to be good programmers no matter what we do. Another reason might be the way the course is taught by focussing a lot on programming language constructs instead of solving problems. Another possibility might be the actual programming language used (i.e. C++) etc. etc.

I’ve realized that one good way to teach programming is to use the same techniques used in the best universities in the world. Naturally (and this has been pointed out to me by one colleague), there is a risk that what is good for exceptional students (like what you have in top universities) might be catastrophic for our Mauritian students but, personally, I don’t buy this. The first reason is that we are trying to teach art and, as far as I know, to learn art, one needs to have taste (aka aptitudes aka interest aka resonance etc.) That’s it. No need for 3 A’s at A-Level. The second reason is that we are a university and not a university– and therefore we should not lower our standards to accommodate more students. I’ll be direct. If the student cannot follow a university-level course, then he/she has no place in a university. Once I asked a professor from a South-African university about how to handle students who don’t like to read and she told me:

Throw them out!

Ok. This is drastic. But this is how universities become top universities. And this is how they help create the Silicon Valley.

Anyway, I looked at what is taught in top universities and I found out the following:

• Harvard’s Introduction to Computer Science I – The course has three goals (i) to teach problem solving through the development of algorithms (ii) to teach computer programming as a means to express algorithms (iii) and to convey a broad picture of the different aspects of computer science in the real world. The programming languages used are C and Ruby. According to me, C is a beautiful language to understand what a computer is and Ruby is perfect to write algorithms solving complex problems as the language is so expressive.
• Cambridge’s Foundations of Computer Science – At the end of the course, the student should (i) be able to write simple programs (ii) understand the importance of abstraction in computing (iii) be able to estimate the efficiency of simple algorithms (iv) and know how to use currying, higher-order functions and lazy evaluation. The programming used is the functional language ML.
• Stanford’s Programming Methodology – The course covers fundamental programming concepts and software engineering techniques. It uses Karel the Robot which is a simulator to learn programming in Java.
• And finally MIT’s Structure and Interpretation of Computer Programs and Berkeley’s version – The course is an introduction to computer science, with particular emphasis on software and on machines from a programmer’s point of view. It concentrates mostly on the idea of abstraction, allowing the programmer to think in terms appropriate to the problem rather than in low-level operations dictated by the computer hardware. The programming language used is the functional language Scheme and the textbook is obviously the world-renowned SICP.

This is what I understand:

• Focus is on solving problems (and not in low-level operations dictated by the computer hardware)
• Very high-level languages (or environments) are used: Ruby, ML, Karel the Robot and Scheme. Interestingly, Harvard uses Ruby and C I guess to give the student a grasp of both worlds.
• Three of the top five universities of the world use functional programming languages to introduce programming. I may be on the right track after all in my quest to learn Haskell. Incidentally, the first programming language I used at university when I was a student was Scheme.
• Python is not used by the top 5 (Pascal Grosset won’t like that). Must be because it’s not different enough from C (apart from the syntax) i.e. it is not very high-level.
• Those top university are not afraid to use non-mainstream languages and environments. This is an indication of being intelligent by the way: the people there think different!

My conclusion?

Let’s see. First of all, I’ll propose that the course be very progressive but ultimately tough. I’ll try to propose to my colleagues that we completely rework the lectures and lab sessions to focus on problem solving. I’ll also propose that we use a very high-level language. Scheme is great (especially DrScheme) but it might be a little too much for my colleagues. Haskell (and especially Hugs) might also be a little too much. Ruby is the next best choice. But I better find a good interactive and multiplatform and free environment first. Any idea?

(An update: I’ve (re)discovered jEdit which coupled with the Ruby Editor Plugin seems to be a fantastic free IDE for Ruby and it works on all platforms which run Java i.e. on everything!)

(Artwork by Piet Mondrian)