The topic of Java as a first programming language came up recently and spurred me to write this short bit on teaching CS and programming languages.
To answer this, we have to first decide what is the goal of a CS program. This is not an easy question - there are several possible and laudable goals and they are not entirely consistent.
Far too often the goals are a single goal :
Most colleges claim (at least) that these are their goals, but the real goal of the colleges is far too frequently simple and single faceted.
To do this colleges (and universities) like to teach popular languages (whichever the popular language of the day is). It makes the students think they're learning the right thing to be eventually employed. It makes it easier to get textbooks. It makes it easier to find people who can teach the language. It rarely has anything to do with how good or useful the language is. And it rarely has anything to do with how effective the educational process is.
What I would (ideally) like to teach is much, much more difficult - all the more so as I'm still trying to figure this out for myself. The only hope I have of even beginning to teach these is is that in a CS context, we have enough constraints on these things to (perhaps) make them accessible to our students.
So here are my goals (don't laugh too hard) :
These questions are really the essence of all software, and all the tools of software design and implementation won't help you if you can't do the basics. They're the hard things to teach, and the hard things to learn. Teaching these, nowhere near as well as I might like, makes the students uncomfortable.
From time to time, people have thought about this and agreed that these are the most important things to teach, so it has come in and out of fashion to teach CS with a fair amount of theory and with little or no programming. (The "Think System" if you like (go watch "The Music Man")) I've dealt with students who have done this - often only passing in paper verions of programs and for the most part the students think that they've learned something, and for the most part they've wasted their time (but because they think they're happy, they stay in the program and the department and the university stay happy).
I tend to distrust this myself - mostly because I've seen the results - people who think they know how to program, do software design and the like, but who should probably be kept as far away from real software work as possible to avoid wasting the time of those who've really learned the process. I also distrust this because I'm pretty sure that my mind (at least) does not usually work well from the abstract to the particular - my mind works best given a bunch of concrete examples and then generalizing from them. And most of the humans I've met seem to think in about the same way.
I also distrust this because software design and development are very practical things and the only way to learn is to practice. Its like (drag out the creaking, aged metaphor once again) learning to ride a bike. You don't learn to ride a bike by understanding the physics of bicycles, or by watching the Tour De France on TV. You learn to ride a bike by getting on the thing and falling down until you figure out how not to.
So, I think its important to program and program a lot in the first few courses. Shakespeare had probably been speaking English for more than a few years and probably knew a bit about the theatre when he began to write plays. Once you have that background in programming, the other kinds of things start to make more sense. Why should your code be readable? Well, try working on some unreadable code and you'll see. Why should you plan testing? Don't do it a few times and you'll understand. Why is table look up a good thing? Do it with if/elsif, then multiply the things to look up by a factor of 20 and see how you feel.
So, perhaps we should pick a programming language - say Java or C or Basic, teach everyone that and then let them program in that language for the first few courses. Seems a reasonable idea until you've done it a couple times and discover that by the end of two years programming only in language X that the students have decided that language X is the only language they want to learn and, even when pressed to program in another language, it looks a lot like X. (The old saying was that you could write Fortran in any programming language. The newer saying is "If all you have is a hammer, everything looks like a nail.") Indeed, reading the slashdot responses to the Java thing, it was pretty clear that half the people responding had learned one language, managed to get good at it and now felt threatened by any other language being considered useful.
This also came up recently on a mailing list I subscribe to on the topic of XSL in which someone asked essentially how to iterate over a list of items in XML - where what they really wanted to do was build a transform that would act on the items independently and glue the results together right. That notion was probably so foreign that it may take quite a while for the light to dawn for that person.
I also recently dealt with a student taking (by distance ed) a course in programming languages. I think this person had probably learned visual basic and now programmed everything in that style - in particular all variables were global - even when declared in the function. And he did not understand why his professors kept telling him that he used too many global variables.
So, I've come to believe that learning different languages - as many as possible, is a good strategy. It gives the brain specifics on which to chew in generating theories. It helps the student learn how to learn. It forces the students to abstract away from their programming language of choice and think more about what the problem is and how to implement a solution. I hope that this teaches them out to think about a problem one step away from the language involved and also teaches them how to learn new programming languages. In the best of all possible worlds I would then hope to get back later and address the other hard stuff more directly.
This process is uncomfortable though - the students often ask "why should I learn language X when I already know how to solve the problem in language Y". (I'm being tossed out of this university in large part for doing exactly that, and probably being replaced by someone who uses the Think System - or worse.)
So, for a first (and second) programming course, my main concern is just to get the students exposure to code and coding - and which language is used is relatively unimportant.
My criteria therefore for a first course are simple :
The only languages that currently seem to me to meet these criteria are Java and (even though there are few texts) Python. Squeak (Smalltalk) is tempting, and the environment is wonderful - but probably a bit intimidating for a beginner. Haskell (through Hugs) is close and offers some very nice advantages - but the graphics support is weak and the language seems more than usually intimidating.
But again, in many ways IT DOESN'T MATTER . Most languages will do one way or another - but students need to learn another language quickly to avoid setting their minds in language cement.
Ideally, in the first two years a CS student should see languages (plural emphasized) with the following characteristics :
By the time students graduate with a degree in computer science, they should know at least a dozen programming languages and be confident of their ability to learn a new one when needed. (Note that this is not that hard - many working programmers use four or five languages on a day to day basis (when you count don't forget to include things like HTML, sh, make and the like)).
So, in sum, in a good CS program the first lanaguage doesn't matter that much, as long as other languages are covered and the students are not allowed to sink into the "the only language worth using is X" swamp. But then, if they do, I would not want to hire them myself and perhaps they'll be better off switching to political science or something equally nebulous and suitable for maroons.