Is Java dying? A response

This is actually a response to an article,  "Is Java dying? Dependency injection and other Java necessary evils", written by my friend Juanfri. Like his article was a response to another article that turned out to be too large, mine started out that way as well. In the end I decided to just post it to my own blog (that way it at least gets some attention).

I must say I liked the original article, but in the end I don't agree with some of it's assertions.

I don't agree for example that there is anything wrong with GWT using overlay types. The code example is disingenuous because it solves a different problem. In fact I have written the same code (using simple-json) this weekend and it's completely similar:


The integration in Ruby is nicer and simpler? Sure, but the mapping provided by GWT sure is useful and the implementation is normally completely hidden from view.

The examples about dependency injection, and his efforts to create a DI framework for Ruby are really funny, especially because they are so recognizable, all of us in this business have gone through the same moments (and will probably still do so a couple of more times during the years that come). Encountering a new technology and then using it for absolutely everything that you come across is normal.

It is the reason almost everything in Java is configured with XML, it was just the way it was done some years ago and will probably still stay that way for some years more. But the whole drive to use annotations shows that people are looking for different ways (and making the same mistakes where suddenly everything uses annotations). And Guice is a prime example where configuration is done using code instead of configuration files. Of course, with the limitations of the Java syntax the result will be less "beautiful" than the same in some other languages.

And finally I also don't agree that there is a huge movement to dynamically typed languages. Instead I would say there is a strong desire to find "The Next Big Thing", in this case "The Next Big Language".

I agree it probably has to do with the fact that Java is already with us for a long time and we have come to know its limitations, 15 years ago it was brilliant, today it's still nice but we know we can do much better.

And of course we know we can do better because there are several examples: C# is already somewhat better (but too similar, not revolutionary), dynamically typed languages like Groovy and Ruby have many advantages (but too messy and too much testing needed for my tastes), or functional languages like Haskell and Erlang that might become essential in the future where having large numbers of processors becomes the norm (but highly functional and therefore unknown to many programmers) and some that try to combine to best features of all like Scala.

Personally I don't really like dynamically typed languages for anything large. It's really cool to be able to work your way into the innards of any object in any way you like but real soon I feel the need to "formalize" in some way what I'm doing, some way of saying "I know what I'm doing, trust me" or even "this is the way to do it, don't try it some other way!".

At this moment I'm trying to learn Haskell and Scala because my "functional side" is really underdeveloped. Scala because it's not so much of a big step coming from Java and Haskell because I want some experience with a language that was made from a fully functional point of view from the beginning. The problem of course is that neither has yet attracted a huge following so I'm not really sure I'll ever be able to use any of them for work. But in the mean time at least I can enjoy learning something new and interesting.

In the end I think "The Next Big Language" doesn't exist yet, but it seems we're all, consciously or unconsciously, waiting for it.

Curried and Confused

In the article Curried and Confused on coderspiel the author gives us this example of Scala code that people supposedly think is too difficult for regular folks:

def sum(nums: List[Int]) = (0 /: nums) { _ + _ }

He then goes on to say that it might be because of the /: symbol, but that this version does not make it any better:

def sum(nums: List[Int]) = (nums foldLeft 0) { _ + _ }

And this is the point where we differ completely. For me if the first version hadn't been called "sum" I would have had no idea what the code does. The moment I read the second version and I saw "foldLeft" I knew this was about an application of some function to a list of numbers resulting in a single result (hence the folding).

For me this isn't about reading (nums foldLeft 0) and not knowing it's the same as nums.foldLeft(0), you learn that once when reading about Scala's syntax and it will stick. Maybe you need to think about it a bit more the first couple of times, but it's not hard, the basics are still the same, the order is still the same, you can still think: "I've got this object nums on which I'm going to perform a foldLeft and... what's this 0 here? Oh must be an argument".

It also isn't about the whole closure bit where you suddenly see braces at the end of a statement, because getting used to Functional Programming you know that this is normally part of this brand new toolbox you've got. The _ + _ part does pose a bit of a problem for Scala first-timers, I agree.

But in the end for me the real problem is this /: symbol. What does it mean? If I see it, it doesn't ring any bells! There is no mathematical symbol that looks like this, in fact it looks like the symbol we've been using for ages now to denote division!

This is about readability, I always agreed with the Java-tenet where they would say that you tend to read code many many more times than that you write it. And it might be read by many people who don't have a way to look into your mind so it's important to write code in a way that it's function is as obvious as possible.

/: is NOT obvious.

But reading foldLeft is, once you've read at least once about folding and what it is used for. Because it doesn't matter in the end which language you use to implement the folding, it's a concept that's easy to grasp, but what happens if you have to go and learn by heart all the strange symbols that one can come up with? Especially when each language decides to use different symbols to express the same thing.

I now understand why they left out operator overloading in Java.
(yes, I know that in Scala this is not operator overloading strictly speaking, take your nitpicking somewhere else)