[USNetizen]

Not so. Learning on an interpreted language is akin to learning how to fly a plane by simply riding in one. There is a lot to learn in a CS program, and it really requires a single language from start to finish. Python doesn't have some of the advanced capabilities and adoption of an enterprise-class language like Java. Believe me, I love Python - I've created a ton of apps with it, but I also have a CS degree and have seen the practicality of using a single language from start to finish.

How are you going to reinforce the notion of how a compiler works with an interpreted language? How would you teach and force the use of static types on a dynamically typed language? How would you teach true concurrency and thread safety with a language that is limited by a global interpreter lock (GIL)? These are introductory things a CS student would take in their first year.

[brownbat]

I wrote my compiler in Python, and I know perfectly well what a compiler does.

It slows down development. :)

Pointer math and garbage collection are lessons better taught in C++, lessons about the stack make more sense in assembly, and it probably helps to learn about high level design patterns using a simple syntax (like Ruby or Python). Lisp, so I hear, teaches you pure enlightenment. We can play this game with any language we like.

Java, for its part, taught me a lot about installing a massive IDE and scouring pre-existing libraries full of absurd design decisions with nominal documentation. (To be fair, this is probably an enormously important lesson for working on large projects.)

Despite the fact none of these languages hits all of these notes, if we had to choose one, Java would be last on my list. Because in Java, there's a risk that you will never learn the most important thing about coding: that it can actually be fun.

http://xkcd.com/353/

[nnq]

> There is a lot to learn in a CS program, and it really requires a single language from start to finish.

Why would a CS program require one language from start to finish?! Wouldn't exposing students and researchers to as many languages and technologies as possible be the actual point? This is how you get people to come with new ideas, you expose them to as many existing ideas as possible, in as many forms and languages as possible... If I were to design a CS curriculum, language wise, I'd first expose people to Scheme via SICP, then push them from theory to practice with a language like Common Lisp and on a parallel track, more related to EE, move up from an idealized teaching-optimized assembly to real-assembly to C and then to very basic C++, then expose them to "engineery" concepts like OOP in two ways at the same time (the classic C++ way and the multiple-dispatch way in CL), and on a third more "pure CS" track have students choose any of the languages or techs from the other 2 tracks to solve the programming parts of the theoretical problems in this part - yeah, grading and teaching a class of such "polyglots" with their minds all over the map would be hell for any teachers, same as managing a research project with the same maddening diversity, but imho the people that are mentally equipped to handle such environments should be the ones teaching the new generations, not the ivory-tower one-problem-focused types.

Don't get me wrong, I'm against this new "hyperpoliglot wave" of using half a dozen languages in one project, but I'm against it in industry, and from a business perspective, because it wastes brainpower that can be put to other use and bring actual business value, but not in academia, because here the whole point is to explore everything, and you don't really have ugly time constraints and the need to provide "quality of service" assuring to real customers - something like a phd program lasts a few years and at it the end of you don't even have to provide a product that works in the real world (like support a certain load, not be littered with security exploits, be extendable to easily surpass or match the competition on new features etc.).

Maybe I have a weird way of looking at things, but the whole software universe seems upside down to me: academia / CS programs limit themselves to a very small number of technologies to use and problems to solve and this way they do very little "exploration of the problems' space", while the industry jumped into a madness of polyglot-everything way of doing things, with 100 choices of doing everything, none proven to work better for a particular case, and 90% of the time spend learning the tools instead of solving the problems. Shouldn't industry standardize and academia explore? Why are things the other way around in the IT world?

[andrewflnr]

I did mention SML, which is a compiled language commonly regarded as an excellent language for writing compilers. I don't believe your analogy of interpreted languages being like riding a plane is accurate. If you want to be "closer to the metal" or whatever, start with C, or assembly. But actually, computational theory is done with Turing machines, which no one uses directly in real life, and lambda calculus, which is far closer to scheme than Java. Which is more appropriate for learning the deepest basics of programming?

As for using a single language, I really don't know. I'm self-taught so far. I can't imagine a good CS degree to not use multiple languages to some degree. Can you do everything from process scheduling to web dev with one language, and do it well?

Further, I'm not sure an "enterprise-class" language is appropriate for learning. Mybe it's just all the OO ceremony that bugs me. I was watching a friend try to explain some C++ code to some ostensibly interested but inexperienced people. He kept having to say "you'll learn what this does later, it just has to be there..." to stuff like includes, int main, type declarations. That's no way to learn. Java is better, but not much. "What's a class?" they ask on their first day. A distraction, mostly.

[eru]

> Learning on an interpreted language [...]

Interpretation or not is a property of the implementation, not of the language. And it's a sliding scale as well, as you can see with Java.

[kyllo]

How are you going to teach pointers or recursion in Java, though?

More on that from Joel Spolsky here: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...

There is a lot to learn in a CS program, and it really requires a single language from start to finish.

There is really no single language that you can use to teach everything that a CS student needs to learn. A computer science education should teach concepts that transcend languages, and use whichever language is best suited to demonstrate the concept at hand.

[dragonwriter]

> How are you going to teach pointers or recursion in Java, though?

Pointers, okay sure, but what's the problem with teaching recursion in Java? See, e.g., http://danzig.jct.ac.il/java_class/recursion.html

[kyllo]

Sure, recursion is possible in Java, but it's rarely used because of the inevitability of hitting a StackOverflowError given a sufficiently large value of n.

Teaching recursion doesn't make a whole lot of sense unless you're using a functional language where loop iteration is not the paradigm.

[dragonwriter]

> Sure, recursion is possible in Java, but it's rarely used because of the inevitability of hitting a StackOverflowError given a sufficiently large value of n.

That's a good reason for not using recursive algorithms in production Java code, but it doesn't make Java unsuitable for teaching CS including recursion (Python, which IMO is a much better general purpose teaching language than Java, faces the same problem; plenty of intro CS classes that cover recursion well use Python.)

> Teaching recursion doesn't make a whole lot of sense unless you're using a functional language where loop iteration is not the paradigm.

It makes perfect sense independently of what is idiomatic in the language: teaching CS using a language isn't teaching the idioms of the language. Teaching iteration and recursion in the same language is useful, particularly because doing so is useful in underlining that recursion and iteration are different approaches for the same problems, even though in most languages one of the two options will tend to be more idiomatic.

[abraininavat]

Very few first year CS students do any concurrency your first year. Your first year you're just learning Java.