Java has undoubtedly been the most popular language of the last decade.<\/p>\n
It has taken over large parts of the educational and professional sector. It is its use as a language for programming teaching that I want to talk about today.<\/p>\n
Java has been dominating introductory programming teaching at universities for years now. But is it time to throw it out?<\/p>\n
\nNot since the days of Pascal was there such a universal agreement about the programming language of choice for the introductory programming course. I don’t have real numbers, but a guess that 80% of introductory courses use Java may be in the right ballpark.<\/p>\n
Currently, there are no real signs of this dominance being broken, but I think change has to come one day.<\/p>\n
In 1995, when Java was first published, it presented a substantial and clear improvement over the state of the art of languages used for programming teaching in that day. People were happy. Happy to see such a nice, small, well-designed language that could be used for a wide variety of tasks.<\/p>\n
A large part of this happiness resulted from the fact that many people were teaching C++. And C++, let’s face it, is about as bad as you can get for teaching beginners to understand object orientation. And when you’re in the dark, any little spark seems bright.<\/p>\n
Java really was a nicely designed language. It was (for what it wanted to achieve) small, clean and elegant. It really had the feel of a single designer who had clear goals in mind. James Gosling got a lot of things right.<\/p>\n
And then the committees got their hands on it. In the latest Java releases, the design changes really smell of design by committee. Look at the design of generics in Java, for example.<\/p>\n
In the original design a principle seems to have been to make common things simple, and to accept that some less frequent tasks may require more coding or compromises. This managed to keep the language design clean. There are many examples where explicit support for certain specialised tasks has not been included in the language so that the design could remain clear.<\/p>\n
When we look at genericity in Java, that feeling is not there anymore. It now feels like they tried to put support for anything into the language that anyone may ever possibly want to do. The inclusion of wildcards, bounded wildcards, generic methods, and all their combinations, together with the re-writing of the standard class libraries, makes some things so complicated that the feel of simplicity as a design goal evaporates.<\/p>\n
How many people, for example, can confidently explain the difference between<\/p>\n
public void m(Collection a);
\n<\/span><\/p><\/blockquote>\nand<\/p>\n
public void m(Collection a);
\n<\/span><\/p><\/blockquote>\nAnd I’m not talking about students \u2013 I mean the teachers!<\/p>\n
Or look at the standard class library: How many introductory programming teachers can really explain why the signature of the standard Class<\/em> class is<\/p>\n
class Class<\/span><\/p><\/blockquote>\n
Then look at its first method:<\/p>\n
Class asSubclass(Class clazz)<\/span><\/span><\/p>\n
<\/span><\/p><\/blockquote>\n
I don’t know about you, but that’s not something I really usually explain to my first year students. Now, I know perfectly well that there are reasons for this design. And I do understand the semantics of these definitions \u2013 I am not saying that you can’t.<\/p>\n
What I am saying is this: Recent changes in the Java language have made it significantly more complicated for beginners to understand the language. This includes not only generics, but also auto-boxing, the for-each loop, and just about any other change they have done to the language. And it does not stop there. The trend looks to continue unchanged in Java 7, with various changed being currently under discussion (such as method references, new parameter types, and various other things).<\/p>\n
These changes all make it easier to write Java programs if you already know what you’re doing<\/em>, but actually make it harder to learn initially. The reason is that just about none of the new concepts completely replaces an old concept. We now have to introduce the for-each loop, but we still have to teach iterators as well. We have to teach auto boxing, but we also have to teach the wrapper classes, since understanding the exact semantics of auto-boxing is crucial to the understanding of Java’s object model. And so on.<\/p>\n
Every one of the language changes, which saves a programmer to type a few characters, puts another concept on the large pile of concepts to be taught in finite time in a first year programming course. It doesn’t make it easier, it makes it harder.<\/p>\n
One strategy could be to ignore the new concepts. Teach a subset using the concepts of your choice. Only you can’t, because you will run into the libraries. If you were to decide, for instance, not to teach generics, your students will still run into the javadoc including generics in the standard libraries.<\/p>\n
What is actually happening here is the re-emegence of the eternal conflict between learning and professional development. Changes that make the language more convenient for professionals make it less suitable for initial teaching.<\/p>\n
Maybe it is time for a new teaching language…<\/p>\n
<\/span><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"
Why is Java becoming lass suitable for teaching. Some observations. Continue reading