Java has undoubtedly been the most popular language of the last decade.
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.
Java has been dominating introductory programming teaching at universities for years now. But is it time to throw it out?
Not 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.
Currently, there are no real signs of this dominance being broken, but I think change has to come one day.
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.
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.
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.
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.
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.
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.
How many people, for example, can confidently explain the difference between
public void m(Collection a);
and
public void m(Collection a);
And I’m not talking about students – I mean the teachers!
Or look at the standard class library: How many introductory programming teachers can really explain why the signature of the standard Class class is
class Class
Then look at its first method:
Class asSubclass(Class clazz)
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 – I am not saying that you can’t.
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).
These changes all make it easier to write Java programs if you already know what you’re doing, 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.
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.
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.
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.
Maybe it is time for a new teaching language…
hello!
altough i agree with you in the sense that generics does make the language more dificult, they are all optional and, IMO, shouldnt be taught until the studants are ready.
Anyways, its a great great tool (and not only for teaching / learning) and something i was looking for for quite some time, especially the visual part of creating object / invoking methods, much clearer than, say, naked objects.
now i was wondering if there is any plan on integrating it to eclipse?
many thanks and keep up the good work
One word: Python.
It is a clean language with an enthusiastic community, many of whom are educators. It’s also about as intuitive as possible for beginners as it uses duck typing (http://en.wikipedia.org/wiki/Duck_typing).
— Todd
I have to agree with you on the introduction of features to java that do not add anything to the language but simply make it easier for what I personally call lazy developers. I get very frustrated when I see that Sun has spent another year on a release adding another way to do something I could already do and not adding features to the platform that I can’t do. I won’t go into that here, but your point about this making teaching difficult is interesting.
Just one counter point. I’m not saying I believe this, but consider maybe java should be a little more difficult to learn. I have seen some of the worst code ever written in java (opposed to C). The developer GOT it to work, but had massive problems with it. I sometimes feel java is so easy to work with that it allows people who don’t take the time to really understand it to create really bad applications. This makes java look bad. Example: I still to this day hear how slow java is. MOST of the speed issues I come across are caused by improper usage of the language.
BluePy?
In response to takeshi’s comment (comment #1):
I don’t think you can avoid generics in your Java teaching. In any reasonable course you need to teach the Java data structures. And they are based on generics – no way around it.
It is, however, partially possible: What I do with my students is to teach use of (generic) data structures fairly early, while writing generic classes is not covered in the first year. That can come later.
Michael
Python.
Yeeeesss….
When I wote this post I knew someone would say ‘Python’ before the ink on the screen was dry.
Let me say that I’m not convinced about Python as the next teaching language. Sure, it has a number of nice characteristics, and I quite like dynamic typing for various purposes. (I think dynamic typing will become more popular in the future again because of pervasive computing systems, btu that’s another story.)
Overall, I favour an approach to teaching programming that’s based on software engineering principles. And there I feel that Java still has the stronger concepts than Python. That’s why, despite my whinging about Java, I wouldn’t want to replace it with Python.
I want to replace it with something, but I haven’t seen that something yet.
Michael
Michael,
Isn’t this a bit of a chicken-and-the-egg problem? What will emerge as the next teaching language without proper tool support? And, paraphrasing your comments above, tool support won’t emerge until a clear favorite exists.
Good software engineering principles are language independent. (Corollary: “You can write FORTRAN in any language.” http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=271)
— Todd
I have to agree with Todd, good software engineering principles are truly language independent. Way back in the early ’70’s I learned Assembly/360 followed by various flavors of Fortran over the subsequent decade (F, G, WATFOR, WATFIV) and in every case I used structured techniques that I had to develop on my own as they didn’t even exist until much later. I still use the flow-charting and coding techniques today in the languages that I’ve picked up since (over two dozen, easy). Frankly, I don’t think I’ve used the same language, or set of languages for multi-lingual projects, twice in a row; the decision on what language(s) to use was driven by the installed base. I might add that one extremely large project was created entirely in Enable macro-programming language and yes it was fast, structured, self-documenting, and bug-free.
As for Java, the design by committee shows all too well and that is why I still don’t use it today (although for you Java types out there, Netbeans is installed and ready to fire). Frankly, I rather like the way .NET, especially C#, is set up. On my first encounter I had no problems figuring out the example code, no matter how complex, just as I had no problems drilling down to particular “libraries”, functions and objects. It’s the libraries that really have kept me away from Java more than anything else. Who came up with their organization let alone naming conventions? Even the various flavors of Forth and APL/J do a better job.
Now where did I tuck that Java Blackbook ;-).
I am sort of a beginner in Java. I got introduced to it in the last semester. our teacher has also tried to get around these new features of Java 1.5. He just mentioned them as ignorable but the documentation was in fact very hard to read for me. As Java interested me a little more i went on reading some books (online tutorials) about it and i think now i have an overview over the collection classes and their generics (but i think i still couldn’t explain your guru code examples). So these features show extremely well what happens when you dont follow the KISS principle.
I have also seen on other places that the for each loop is seen as source code sugar. there to i want to say that even the ordinary for loop is already sugar. IMHO it should only be used to run through a complete collection or array and then do just one action with each found object. For everything else that looks more complicated there are the while and do while loops. Each for loop can be transformed into such while loops. So iterators have to be tought anyway IMO. and when you know about these constructions and used generics in collections the for each loop looks for me even clearer and is better readable than the for loop.
Btw even the ordinary for loop with iterators is often used wrong (in my eyes). for example like this:
for(Iterator it = list.iterator(); it.hasNext(); ) {
it.next().doSomething();
}
although the code is absolutely right the update parameter of the loop looks a bit wrong to me, because it is missing completely. It has been moved into the body to give it the look as if there was anything. But to really match the for loop there should be an update in the parameters like this:
for(Iterator it = list.iterator(); it.hasNext(); it.next().doSomething() );
now the loop hasn’t got a body anymore and for a single line the loop is also often too long. Another big disadvantage of this kind of notation is that you don’t know what kind of objects you have (except when you just put them out on the console). This kind of notation was once (in the good old C times) a counting loop which had nothing to do with object collections.
Therefor the for each loop looks much better: there is a temporary variable of an object you can work with (so you have a certain type), not an iterator with which you can’t do anything directly (typecasting!?); there is no question about the update parameter anymore (the action has to be written into the body of the loop) and there are some other benefits too (i.e. nested iterations) just look at this:
for(Thing t : list) {
t.doSomething();
}
for me this looks much easier to understand. So if my teacher explained that earlier to me it hadn’t been a great problem as well. As long as this sugar is as simple and only used for the problems they should enhance, i don’t see a problem. but therefor it needs teacher’s who explain that and who say clearly when these things should be used and also as important when not to.
Ron
ALU, boolean logic, machine language, goto considered harmfull, NS/PSD diagrams better than flowcharts, pseudocode better than PSD, oo better than imperative, design by contract better than just OO, GC rather than memory leaks, UML (MDA) rather than sourcecode… Where is the language in all this?
I guess a Blue.NET or Blue# version shouldn’t be so hard to make but the main concept is still OO isn’t it? Comparing with information system (dbase) building with ERD/MDA tools that auto-generate query and data entry forms where the teaching focus is in information analysis and not on SQL, I guess requirement engineering and UML is what will replace a part of teaching Java.
Then students must learn to outsource the coding development to India and the hardest part will be to audit and verify the results they get. Maybe learning the language by reading a lot first, not writing.
And the classic understanding of the sequence, selection and iteration concepts will in future be part of some high-school project on the basics of computing or handling cheap household appliances that don’t have AI built in yet..
But for now BlueJ and Java will do just fine 🙂