Wednesday - Lambdas: Myths and Mistakes

This evening I went to see the presentation by Richard Warburton at Skills Matter regarding the new functional features of Java 8, about which I mentioned previously.

A few words of explanation for those not familiar with the terminology.

The JSR mentioned is a Java Specification Request, which is what you create when you have a suggestion for how you want Java to change in the future. These are submitted as part of the Java Community Process, set up by Sun when they realised they had something big on their hands releasing Java. In theory it allows everyone to have a voice, but in practise it's mostly those with very extensive knowledge of the language (such as Richard), although the Adopt-a-JSR he talks about is a move to allow the average code-cutter their ten-penn'th, as well as field testing the resulting change. The JCP has been criticised for slowing down changes to Java which might make it more competitive: Microsoft just releases their software to beta without any real consultation, while Google just seems to keep everything in permanent beta, killing it off when they get tired of it.

The "lazy" and "eager" he talks about are functional concepts that are easier to grasp by watching them in action rather than talking about them, but the nearest non-programming equivalent would be the just-in-time of logistics and manufacturing (a part is ordered to arrive just in time to be used, thus eliminating the need to store it and the resulting cost of doing so). The lazy algorithm is executed when it's needed, whereas the eager one is executed completely. This is why there's a problem when the different algorithms are mixed and why the lazy ones play havoc with profilers (software that tries to work out how efficient your code is, amongst other things).

Richard was quite eloquent, highlighting the changes and giving examples of the way in which they should be used, but it became clear that Java 8 is not the radical change that everyone thought it might be. The functional features, like interfaces and generics before them, look like they've been added onto the existing features and even create conflicts with them (the "streams" and collections Richard talks about).

While it's looking as if they are not going to be usurping Scala and Clojure any time soon, the new features look very Scala-like, which does look a little ominous for the latter. Mind you, they also look a little Erlang-like as well, so make of that what you will.

Bizzare aside: While on the way home on the train, I sat opposite the reddest man I have ever seen. It reminded me of this.