Do We Need a New Pascal?

I just read a short article about “Why Johnny Can’t Code” which, in a nutshell, asks what an appropriate language for beginners is. Once upon a time, it was Pascal. Lots of people liked Pascal, and many still do. They don’t like the monstrosity of C++ or Java or C#. They’ve concluded the object-oriented programming is too tough to teach.

Now, I have a bias. Since I taught at the college level, I think of computer science education at that level. Given the title of my blog, however, I should really consider programming at high school and even earlier. How do we teach programmers to kids? Many kids learn to program using a language called Logo. Logo was pretty much a cursor, which you gave commands to, and it drew lines. It was visual, which gave plenty of feedback to the programmer. It didn’t do anything particularly useful, but the ideas behind logo (looping, conditions) are valuable to programmers.

These days, people want programming languages that allow users to do something interactive with the user, preferably of a graphical nature. This could be a GUI, but more likely is a game, or some interactive world.

Why do teachers want a new Pascal? Even at the college level? What’s wrong with C++ or Java?

Many programming teachers learned an imperative programming language like C or Pascal. It’s taken quite a few years for teachers to learn how to think in object oriented terms.

I’ll relate a story. I was teaching with someone who was bright (at least, enough to get a Ph.D.), but clearly her background was imperative programming. How so? She developed a project, where she wanted the students to break this complex task into three separate subtasks. Each of those subtasks were public methods. They had to be called in sequence. Call subtask A, then subtask B, then subtask C.

It was a good idea to break down the tasks into subtasks. It’s one of the oldest teaching ideas in programming: stepwise refinement (seems like we’ve always given fancy names to simple ideas). But it’s an awful idea in object oriented programming. In general, any class that requires you to sequence method calls is problematic. It forces an order that’s hard to check for in the program. For example, even the common programming idiom of opening and closing a file is a pain.

Ideally, you want the constructor to open a file, and the destructor to close it. But you may not want to open the file right away. Simple. Create two classes. One class, when it calls open() will return a second object. That object, when it gets destructed, will close the file.

But my point that a relatively bright person still thought imperatively, not in object-oriented terms, even though she was familiar with C++ syntax.

It’s been argued that it’s too hard to teach in a “objects first” approach. What is objects first? Many people teach C++ by teaching C first. Learn how to program imperatively, then learn how to program using good OO principles. The reasoning behind this was obvious, yet flawed. C++ came from C, thus object oriented programming comes from imperative programming. As big an authority as Bjarne Stroustrup argues that you can learn C++ directly.

Having said that, it’s tough to say whether Bjarne is right. After all, Bjarne’s a bright fellow, and we’re talking about teaching programming to the masses. It may even be that you can’t teach programming to the masses. It’s like teaching math to the masses. It may be that programming is at least as hard to learn as algebra, and many an American, despite taking algebra, are barely competent, years later, to do algebra.

I don’t know if teaching objects first would work or not. Many do try, and have the benefit that those who don’t get it can seek other majors. I’d like to try it myself at some point, just to see what would happen.

The reason there are objects-first advocates is Java. Java makes it very painful to write in a C-like style. While Java has a main() method, this is the primary remnant of C/C++. To write in a C-like style, you’d have to teach static methods and static variables early on.

Then, once you do that, you’d have to tell students not to use static methods and static variables, because no sane Java programmer codes in this style. Rather than teach this style, then have to convince students this is nuts, you have to teach objects early on. Even advocates of objects later still have to deal with objects really early on, as there’s objects everywhere (Strings are objects, for heaven’s sake).

One reason for teaching Java or C++ in college is that it builds a skill that’s directly usable in the real world. Well, almost. Java is evolving. They just came out with Java 1.5, with generics as the primary new feature. The nice thing about Pascal? It’s fixed. No one was adding new features, because there was no need. It was a teaching language. Sure, it lacked separate compilation, and certainly wasn’t OO, but no one was going to fix the language in major ways.

Even now, many a Java educator wants to teach a controlled version of Java, that limits what students need to know, and they would like to fix this version of Java so that students, and more importantly, teachers, don’t have to keep up with the latest changes in Java.

And that’s what this blog entry is finally all about. Why are teachers reluctant to teach real languages? Because real languages evolve, and many teachers aren’t thrilled that their knowledge of a programming language is going to go obsolete if they do nothing more. Which other disciplines does this affect? Math? Nope. English? Only very slowly. Many fields, once you learn it, that’s it. There’s no strong need to learn more, though you certainly can, and students benefit from it.

Programming? There are universities that won’t switch over to Java because the professors don’t want to learn the language. They spent time learning C++, and the languages don’t seem that different, so why bother?

A teaching language is clean; it avoids lots of details you may not care about to explain, that real languages have to deal with. When you have to learn minutae of the languages that seem to have no other purpose other than to confound you, you wonder why it should be taught in the first place.

But unfortunately, as nice as that is for teaching purposes, it avoids reality, and the reality is that real languages are not always so clean. Most teachers are content to say “They have to start somewhere, and I’d rather start them on a nice clean language”. Which means to say they don’t ever want to teach a language that’s grungy. We must do it for the children. The children!

But of course, the reasons are partly to insulate the teacher, who doesn’t want to teach these details, and partly because programming is simply hard. A programming teacher, at least, those who aren’t bitterly cynical, believes everyone can program. As they teach, they see some students struggle. Some struggly mightily. They begin to say “It’s not important to learn syntax! Look it up! The conditional operator is a nasty feature. Let’s not cover it!”.

Eventually, this teaches all sorts of bad habits to programmers. The lesson programming apprentices should learn is that experts learn the nooks and crannies of the language, the parts that may seem obscure. For example, continuations are a big feature of Scheme. To avoid teaching it is to avoid teaching a critical part of Scheme (well, maybe not “critical”). Great programmers learn the obscure features of a language, even it’s not widely familiar.
Having said that, I’ve been coding in C++ again, with STL, and find that I must think about const a lot, and how to use iterators, and all sorts of mess that I don’t have to deal with in Java, because I understand Java’s classes much better, and it makes a lot more sense to me. That may simply be familiarity, but the time I waste trying to think about const makes me that much less productive, despite my acknowledgement that const is an important issue which all C++ programmers need to know. (Again, my colleague found const correctness a pain to deal with and wanted to abolish it).

There are even more radical ideas (radical to me, anyway). There are universities that want to ditch strongly typed languages in favor of weakly typed languages like Python and Ruby. These languages often have powerful string methods and regular expression support. Powerful code can be written in a few lines.

I do see some advantage in this. I think I’d write a lot more useful tiny programs if I were more well-versed in Python or Ruby. I find writing some programs in Java or C++ really painful that would only take a few lines in these languages. But honestly, they should have some strongly typed subset of these languages so that there can be some error checking at compile time. Please. (Groovy, a scripting language, built on top of Java, and compiles to Java classes, seems like something that might fit the bill).

So I can see both sides of the issue.  On the one hand, all the plethora of features makes it difficult to learn a real-world language.  It’s hard on the teacher.  It’s hard on the student.  On the other hand, it’s also polite fiction.  If students are expected to learn real-world programming, they need to worry about all of this perceived nastiness.  Teachers want students to learn less (i.e., stick to the basics), while the real-world wants them to learn more.

It may be, in the distant future, the teachers will be right, but I doubt it.  Here’s one example. Internationalization.  Java had to switch to Unicode to deal with international character sets.  How many teachers really want to explain, to American students versed in English, anything about internationalization?  None, I’d imagine.  It’s hard enough to teach programming (loops, functions, inheritance) without having to even mention internationalization.  Yet, it’s a topic of concern for many developers.

Software development is getting more mature, but in the process, it’s making the teaching of computer science more challenging.  I can’t say I honestly know the answer about what language to teach first, only to say that the reasons teachers push students in that direction may be at odds with the real world.