Teaching programming with Eiffel

November 2004

Meant for the most demanding industry applications, Eiffel has always been used for education too. There was a lull in the late nineties because of the forced march to Java in many universities; with the Java wave past and a return to reason, we are seeing a considerable surge of interest in Eiffel for teaching programming. The expressiveness of the language, the power of Design by Contract mechanisms, the focus on simplicity, combined with the attraction of the environment, the availability on every platform that a student may want to use (Windows, Linux, Macintosh, Solaris...), not to forget the availability of both specially priced academic licenses and free versions for students and others, all contribute to the increased visibility of Eiffel as a teaching tool. Perhaps the greatest selling point of Eiffel here is an almost paradoxical one: self-effacement. With Eiffel you teach the concepts thanks to the tool; with too many others you end up teaching the tool, desperately trying to get to the concepts.

It's been a new experience for me over starting last year, and for the second time right now, to teach introductory programming at ETH Zurich. That's not my background; I have always focused on industry and production environment. But it's a fascinating experience. The Web page that describes our approach (http://se.inf.ethz.ch/touch, with links to the actual course page) discusses the challenges that we face when teaching intro programming today, for example the incredibly diverse student backgrounds -- from those who have barely touched a computer, to those who have written an e-commerce server --, their high expectations, the need to provide exciting examples. We use a component- based, "outside-in" approach. On the Web page you can find a link to the current working draft of the supporting textbook-in-progress, "Touch of Class".

One of the benefits of teaching at an introductory level is the discipline that this forces on you. You can't leave anything approximate, fuzzy or implicit. For example I realized that drawing pictures of objects with string fields that show the actual strings (for example the name of a person), while a convenient abuse of a language for experienced programmers, causes terrible confusions in class, because students start thinking of the field as expanded even though it's a reference. It doesn't help much if the next slide explains that this is just a convention: that's too late, the picture sticks. (That's also a good reason for never starting with graphical notations, e.g. UML, with their vagueness and ambiguity.) We find that every detail counts, and every concept should be just right. A constant lesson in precision, rigor and clarity.

One of the most rewarding parts of the experience is to see how quickly beginning students get to the core of issues. I find myself answering questions that go straight to some of the issues that preoccupy the most expert among industrial users, and wanting to refer to language mechanisms that are right now being discussed in the the ECMA committee for the next version of the language.

Perhaps there's a psychological explanation: since I think about these issues myself, it's possible that I unconsciously tend to present existing mechanisms in a way that suggests what I know they may miss. But more likely it's because smart students approaching a concept with fresh eyes will get, right away, to the crux of the matter, witbout suffering from the weight of accepted practice. Some of the ETH students are indeed amazing. In the fifth lecture this year, I was illustrating object exploration, using the EiffelStudio debugger on a demo system built on EiffelVision and our TRAFFIC library (see the Web page for details); I muttered that something in the display wasn't quite as expected. From the first row came the explanation: "The once functions haven't been initialized yet!". Wow! These are students fresh out of high school, two weeks into their first semester.

At a time of ever tougher software challenges, ever more programmer competition from ever more places (at ever lower costs), ever more demands on speed and quality, we can't just let sheepish perceptions of fashion determine our educational choices. It's time for innovation in how we teach the next generations, and exciting to try to provide them the best we know.

-- Bertrand Meyer