I've seen this in a couple places, but I'm not sure I understand why. Does anybody know of a good reason for teaching java first?
Furthermore, it has very mature support for everything from GUIs (Swing) to web development (Servlet) to high-powered concurrency to advanced data structures. There are literally thousands of libraries and frameworks for every need and a wealth of talent and knowledge out there. Its performance is also orders of magnitude better than interpreted languages like PHP, Python or Ruby. It simply scales better in just about every way and is universally supported almost everywhere.
So, to summarize, for all the reasons listed above Java is the bread and butter of enterprise software. Personally, I prefer Python and C#, but Java is unavoidable if you want a good paying job or are serious about building a high-performance, platform-independent, scalable application.
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.
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.
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.
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
Teaching recursion doesn't make a whole lot of sense unless you're using a functional language where loop iteration is not the paradigm.
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.
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.
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.
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?
Any CS student should be able to do that at least by their second year, regardless of what language they started off with. If colleges were not starting with Java there would be zero risk of students not knowing it if they needed it by the time they were ready to enter the workforce.
The usual justification is "we're not a vocational college" which I think is kind of bullshit.
We got one quarter of C++, then everything else was "you are all grownups, use whatever the hell you want so long as it works on [cs cluster]". Most people continued to use C++ of course. It was not until an intro to languages course (preceding a few compilers courses, if you elected to take them) that course material again included learning a new language (scheme).
This, aside from the initial obnoxious first quarter, seems like the absolute proper way to run a CS department. A bunch of courses teaching different languages, as I would expect from some sort of "vocational college", is absolutely not what I was paying for.
Then people graduate and start a job, and they can't code their way out of paper bag, but they sure can write the tuple relational calculus for some given query.
Another example is my OS class. We just spent half a semester going over concurrency problems. Now we're rushing through everything else that goes on in an OS. We spent one day on filesystems and I/O. Not once have we said anything like "well this is how Linux or FreeBSD does it".
We also had a Software Engineering major which a lot of people in CS took courses from. The only required (non-track) CS courses in our suggested 4th/5th year were software engineering classes though. I think the coverage there was more than adaquate. Honestly it got a bit too "vocational" for my tastes.
On the other hand, most of my peers (70-80%?) took the AI/Games track; they probably got closer to the sort of coverage on the other topics that you're mentioning. IIRC only two arch classes (MIPS), no OS to speak of, and a single 3-month quarter of concurrent programming. I don't think that is satisfactory, but the last I have heard most of them have been doing fine in the real world. That stuff is neat and good fun, but I don't think it will really effect your ability to perform in the industry.
1) Every University has some courses which need a refresh.
2) The OS and Compilers courses certainly need refreshing at the moment at CWRU.
3) We have created a new class called "Software Craftsmanship" which address much of the concerns placed at the foot of the "Software Engineering" class.
4) It isn't the job of the university to teach any particular technology. It is the job to teach the theory and fundamentals.
5) Java probably isn't the best language but we have a new intro professor how is doing a good job with the intro course.
6) You never know who you will meet on the internet.
7) TRC and relational algebra are actually a pretty useful formalisms that helped me become a better user of databases.
8) The early circulum refresh has introduced many more software engineering principles earlier in the curriculum.
9) The best place to learn software engineering principles is on the job at a good company. There is no replacement for doing things for real.
10) There are good and bad things about our department but that is the same everywhere.
^ an exam which offers college credit at most universities to high school students
- typed languages that are too low level to start (C/C++)
- scripting languages that are high level, not typed, and therefore do a lot of things under the hood (Python, Ruby, Javascript)
MIT switched away, though to python iirc which isn't terrible. Northeastern still uses Scheme first though.