Lambda the Ultimate

It seems to me that if a student cannot code a loop or understand primitive recursion, this isn't the fault of the language (Java supports both) but is the fault of the instructor.

I don't think there is anything wrong with using Java as a first language if the courses which use it are taught well. Because it is strongly and statically typed, many feel it is a good language to use with students because it will prevent them from making mistakes that C-based languages allow. (Actually Modula-2 goes even further in this respect, but try convincing someone it is a better language....)

I had heard of problems similar to the ones Ehud Lamm describes when the university taught C++ has a first language. This led me to believe that instructors were not concentrating on the basics of computer programming, but instead were covering specific language features which don't really belong in introductory classes.

Another issue is that in Java you have a lot of syntatic overhead, around a simple procedureal code. You have to define classes etc. If you don't explain what all this means, you are just confusing students. If you try to explain it, you lose the focus required for an intro to programming.

It's a tricky issue, and there are reasonable arguments as to why or why not one should use Java as a teaching language. I think departments have to make the choice based on the ability and knowledge of their faculty to teach good OOP vs. procedural programming, as well as what suits the needs of their students.

(Myself, after thinking about it, I would choose Python as a teaching language.)

I think that it is not a question of OOP vs. procedural programming. You simply can not be a programmer (of any sort) without understanding the basics.

Someone was telling me that near the end of the class the professor was trying to teach C++ operator overloading. Gah! That is definately a language feature, not a core part of basic programming knowledge (like, say, recursion).

But it gets worse! The class they were supposed to implement was a Boolean class, and the operators to overload were the logical operators.

Why is this worse? When you overload the logic operators they no longer use short-circuit evaluation. Since C/C++ short-circuit on native types, overloading these operators is blecherous.

I think I agree with Chris above about the Scheme/ASM thing!

Except that I would start out with LOGO, no joke, to give them something visual, and them move onto Scheme.

I'd also let them do Python or Smalltalk for extra credit. :)

I think that going the functional route (starting, say, with Scheme) is a viable option. I still think that the procedural way (starting with Pascal) works pretty well.

Choosing between these two options, I'd consider the curriculum as a whole, and see how things add up.

Pascal is bletcherously simple, close to useless if you limit yourself to standard Pascal. This should leave plenty of room for learning real computer science instead of language details. And still, Pascal is close enough to C/C++/Java that the transition there would be very easy. Ada, Modula-3, Modula-2, Oberon, Simula, Delphi, etc would also be good choices.

But it all depends on where you want to end up. While there are good reasons for teaching a "typical" language, such as one of those above, there are also reasons for avoiding the mainstream choice of imperative (or OO) statically typed compiled languages. So I guess Scheme, Common Lisp, Dylan, Erlang, Smalltalk, Python, Ruby, Rexx, tcl, Standard ML, OCAML, Haskell, assembly language, Mozart/Oz, Prolog, Mercury, Forth, Joy, PostScript, Logo, APL, J, K, A+, Beta, Eiffel, Sather, Icon, Mathematica, or any other reasonably clean language that supports other programming styles would also be a good choice.

The important thing is that they don't stop learning...

For example if you use a functional language, students may have to learn about the procedural way of doing things for their next course, which may use C or C++.

That's the main reason I am reluctant to advocate Scheme, if all the subsequent courses present things in a procedural style.

I'm a big fan of Smalltalk. I admit that I'm a little partial to Smalltalk, but having learned C, C++, Pascal, Python and BASIC before touching Smalltalk, I feel that it really has the potential of being used for one of it's original intents: as a language for normal folks, and for the beginenr. Hell, you could even do programming in straight bytecode for a Smalltalk VM to teach some low level concepts.

As far as LISP, something like ISLISP (free-beer implementation called OpenLisp available), which isn't quite as barebones as Scheme, but isn't as intimidating, or doesn't retain all of the kludgeness preserved in CL. But then again, what is more useful, CL, ISLISP, or Scheme? If that's the idea, teach them CL which probably sees more "real world" action than the other two.

My school used C and C++ for CSI and CSII respectively. It did a pretty poor job of getting kids to understand how a lot of C/C++'s low-level features work, confusing a lot of kids. Now, this could be remedied by teaching these topics better, but also by using a language that doesn't provide these kind of neccesary but comfusing features that do nothing but confuse many of the first-year students.

I wish I could remember the name of the school, but I heard about a college that had three sections of introductory CS- one for Scheme, Java and C. I imagine a setup like this would work well, teaching concepts in lecture, and language specifics (syntax, semantics) during discussion.

What is intimidating about Scheme?