We all agree that Java needs simplicity – we just don’t agree what that means.<\/p>\n
Several things came together recently that made me think about simplicity in the Java language again, and what that might mean. And one thing is clear: simplicity is not simple!<\/p>\n
Events that prompt me to write about this again were feedback I recently received about another blog entry<\/a> (where I discussed simplicity in more general terms), a discussion by the Java Posse<\/a> guys about new language features, and my own teaching. (First term is about to draw to a close in our parts of the world, so I’ve just been through 12 weeks of teaching another cohort of freshmen programming in Java again.)<\/p>\n The executive summary is: I think many of the recent discussions for changes to Java are in danger of pulling the language downhill fast, and the term “Simplicity” has different meaning to different people that cause directly contradictory results for language design.<\/p>\n In episode #151<\/a> of their podcast, the Java Posse discussed a whole list of proposals for changes to the Java language (proposed for inclusion in Java 7). These include closures, certain instances of type inference, chained invocations, “extension methods”, and more. Most of the ones discussed in the podcast are described in a document here<\/a>.<\/p>\n Almost all of the changes were presented as making something simpler. Let’s look at an example, “Extension methods<\/em>“.<\/p>\n Extension methods are a mechanism where single static methods can be imported, and then called with a syntax similar to instance methods. The example presented in the document linked above is the following:<\/p>\n Extension methods<\/p>\n Existing interfaces cannot be extended with additional methods without breaking some clients. Instead, functionality is typically “added to an interface” by static methods in a separate utility class. Using them is somewhat awkward:<\/p>\n List list = …; With extension methods, client can designate utility methods to act as if they were members of the interface (or class)<\/p>\n import static java.util.Collections.sort; Now, this feature is proposed to make it simpler to write a certain kind of method call. Most of the other proposed features are in similar spirit: they make writing something simpler that is somewhat awkward in the current syntax. Chained invocations<\/em> simplify writing a certain sequence of method calls; Constructor <\/em>type inference<\/a><\/em> saves typing a whole string of characters in certain constructor calls; enum comparison<\/em> saves having to call .ordinal() before using comparison operators with enums, and so on.<\/p>\n But here’s the catch: simpler for whom?<\/p>\n The mindset of the argument here is that of the writer: it is simpler to write this new syntax than to write the current one. But this is a lazy sort of simplicity. I would argue that most of these changes make Java worse, because they make the language harder, not simpler.<\/p>\n They make Java harder to read, harder to understand and harder to learn.<\/p>\n Simplicity is not equal to simplicity. Simplicity for the writer can mean work for the reader. Putting an added burden on the writer can simplify things for a learner. Simplifying for the writer is the most counter-productive form of introducing simplicity.<\/p>\n Like all writing, code should be carefully written to make the reading experience as good as possible. Not the writing experience. I really don’t care about saving a few characters typing if that means that the reader has to use more brain cells to work out what’s going on.<\/p>\n They are really quite different meanings of simplicity.<\/p>\n Take another example that has already happened: auto-boxing. Does auto-boxing make Java code simpler?<\/p>\n In one meaning of the word it does. It is now simpler so write code that inserts primitives into collections. But does it make the language simpler? Hell, no!<\/p>\n When I teach my students now, I have to explain a lot more. I have to explain the new mechanism (list.add(3)<\/em>), and in the process of explaining it I explain about wrapper classes (list.add(new Integer(3))<\/em>). If I don’t, there is a real danger that students draw wrong conclusions from the code (that primitives can be in collections, or that ints are objects).<\/p>\n See, you can still not get away with pretending that ints can be added to lists. I see that every year when students try to write<\/p>\n private List myList;<\/span><\/p>\n That, of course, does not work. You have to write<\/p>\n private List myList;<\/span><\/p>\n even though you then proceed to apparently add ints to the list. In other words: To make sense of it all, you still have to understand the whole story, the primitive\/object distinction, the wrapping, and<\/em> the auto-boxing.<\/p>\n Compared to the Java 1.4 version without auto-boxing, that has made the story you need to learn more complicated, not easier. So what we have got is a gain in simplicity for the experienced writer, and a gain in complexity for the learner. The simplicity gain, however, is largely a saving of typing a few characters (with maybe a little bit of neater looking code) while the loss in understandability is a potential serious problem.<\/p>\n The fact just is: for initial learning, auto-boxing is a step back, not forward.<\/p>\n The same is true for almost all the improvements suggested now. They save typing for the experienced coder, so people who know what they are doing like many of them. They obfuscate, however, what is really going on underneath. Deeper understanding of more detailed language rules is required to correctly interpret the results, and the potential of error rises.<\/p>\n And it rises exponentially!<\/p>\n One problem with adding features to a language is that complexity does not rise in a linear fashion with every new feature, but language complexity is exponential. Because every feature can potentially interact with every other feature, the number of potential problems explodes.<\/p>\n Take auto-boxing as an example again (since this is such a nice and simple example – it gets worse with some of the other features!). Consider the following statement:<\/p>\n boolean result = !(i < j) && !(i > j) && !(i == j);<\/span><\/p>\n Assume i and j are numbers. What we are saying in this expression is quite simple: i is not less than j, i is not greater than j, and i is not equal to j. Now the question: Can this ever be true?<\/p>\n Take a moment to think about it.<\/p>\n Going by our intuition (and everything we knew up to Java 1.4), the answer would be no. Since Java 5, however, it can be true. Here is how:<\/p>\n Integer i = new Integer(13); With this definition, result<\/em> will be true. This is because the < and > operators auto-unbox, but the == operator does not and does object reference equality instead. It is counter-intuitive, completely useless for anything sensible in practice, and a potential for error.<\/p>\n Now, this problem comes in only through the unexpected combination of apparently simple features. Auto-boxing is simple. The primitive\/object distinction is simple. Comparison operators are simple. But put them together, and you get something that looks like a trick question that even experts have to think about for a moment (and beginners just cannot explain by themselves).<\/p>\n The real problem here is the interaction of features, combined with a deceivingly simple appearance that covers up more complex functionality.<\/p>\n The problem with the proposed language extensions for Java is that most of them do the same. They introduce simple syntax for more complex functionality, and knowing simple rules is not enough for the reader anymore. The reader needs to understand the full complexity of the additional rules to correctly interpret the code.<\/p>\n This is not how code should be written.<\/p>\n When you write code, you should always assume that the reader (a future maintainer) is not as smart as you are. That is not because you are the most brilliant programmer around (although you might be). That future not-so-smart maintainer might even be yourself, just having a bad day, or having your brain already full with a complex problem you are working on.<\/p>\n The fact of the matter is: making it easier to understand for someone a little slower on the uptake is always worth more than saving 20 seconds typing a few more characters.<\/p>\n Now, some of you will say that the proposed language changes are not only about saving typing, they also make the code simpler to read. That is just not true. They make the code appear<\/em> simpler, while actually making it harder. Simple code is code that does exactly what it appears to be doing. Simple code is not code that looks simple and then goes and does something different. Because there will be situations where you have to understand exactly what’s going on, and then having code that glosses over the details is not helping.<\/p>\n Look at one very simple example of this convenience design: the rule that states that you are allowed to leave out the constructor call to superclasses for default constructors. In other words:<\/p>\n class A extends B { public A() { }<\/span><\/p>\n is automatically interpreted as<\/p>\n class A extends B { public A() {<\/p>\n super();<\/p>\n }<\/p>\n } Convenience in not having to spell things out leads to problems in interpretation if you do not fully know the details of the rules.<\/p>\n Now you may say that this is an example about beginners, and you are a developer with experience. I claim that this, in fact, does not make a difference in principle. Most programmers display beginner-like behaviour in some situations.<\/p>\n When we start doing the same hidden-functionality-by-special-rule design with the proposed chained invocations, extension methods, type inference, and other such things, we are laying traps of misinterpretation, and someone will step into them. Worse, we are creating interactions with other constructs and start seeing odd behaviours that are hard to deal with.<\/p>\n This is also the problem with otherwise very nice language extensions. The most talked about proposal for Java currently is the addition of closures<\/a>. Now, closures<\/a> are a very nice idea, and I’d like to see them in a modern programming language. However, I am not convinced that retro-fitting them into Java is a good idea. Had they been properly designed in from the start, then, sure, go for it. But now we are constrained by all sorts of existing constructs that we cannot change without breaking the language, and will see strange interactions with these constructs. I think it’s a bad idea.<\/p>\n If we wanted to make a new language, say NewJava, where we had the freedom to drop compatibility and change existing language features, then closures could be made to fit. But as it is, it has a Frankenstein feel to it.<\/p>\n One of the problems with the whole discussion is that, by it’s very nature, the language evolution discussion is carried by people who understand the language well. If you already know all of Java, learning a new feature (such as closures) is quite manageable, even if we have to learn a number of spacial case rules for the weird interactions. For new learners it is quite different: every new language features bumps up the complexity of the language exponentially, and learning the language gets that much harder.<\/p>\n That is what happened with genericity. For all of us who grew up with Java, adding genericity was a manageable step that we could concentrate on in isolation, because we already understood the rest of the language. New programmers today do not have this luxury: they have to deal with it from the start (you can just not ignore it, since it’s all over the class libraries), and that makes getting started with Java harder. Adding even more features will increase this effect.<\/p>\n I am not sure what the solution is. I am tempted to say “Leave the language alone and make yourself a new one if you want different features”, but I know quite well that that’s not how it works. Java will evolve, and it will grow, and it will become more complex.<\/p>\n Maybe the solution is just that every generation needs their own new programming language. That language then can grow up with them. It starts simple while you’re a novice, and gets more powerful when you progress.<\/p>\n But I do know that I am not looking forward to teaching Java 7 if it includes many of the proposals currently floating around!<\/p>\n","protected":false},"excerpt":{"rendered":" We all agree that Java needs simplicity – we just don’t agree what that means. Several things came together recently that made me think about simplicity in the Java language again, and what that might mean. And one thing is … Continue reading
\nBut one step at a time.<\/p>\n
\nCollections.sort(list);<\/span><\/p>\n
\nlist.sort();<\/span><\/p><\/blockquote>\n
\nInteger j = new Integer(13);
\nboolean result = !(i < j) && !(i > j) && !(i == j);<\/span><\/p>\n
\n<\/span><\/p>\n
\n}<\/p>\n
\n<\/span><\/p>\n
\n<\/span>
\nNow, if B does not have a default constructor (a constructor without parameters), then the error message you get in the first version is completely cryptic. It highlights the signature of A() and says “cannot find symbol – constructor B()”. Every year I see students who struggle to interpret this message. The reason is that the error is caused by a call that is invisible.<\/p>\n