Tag Archives: Scala

Bad Java, no cake for you! – Java 8 default methods versus Scala traits

Java 8 was released recently and one of the much heralded features is Default methods. Simply put, these allow you to inject functionality to classes via interfaces. This is a new feature in that prior to Java 8, Interfaces could only have method signatures and not have the implementation and only Abstract classes could have method implementations but that has now changed.

Here’s a simple example that prints out “In InterfaceOne”

In Scala, another JVM language, you can do something similar but more awesome with Scala’s traits (its version of interfaces) you can override similar implementations and have a version of multiple inheritance. This example prints out “In TraitTwo”

The secret that avoid that diamond of death is that whichever trait is declared last wins. If I’d swapped around the order that the traits were declared then it would have printed “In TraitOne”

What is even nicer in Scala is that you can declare your class with traits when you instantiate it. You don’t have to declare it at the compile time of the class. This means that you have a powerful way to extend functionality of classes but without the insanity of monkey patching. ThisThe below example also prints out “In TraitTwo” but the class does not extend any trait. This of course is Scala’s cake pattern where you can mix in the traits.

What is slightly disappointing with Java 8 is that you cannot mimic this behaviour. If you try to do this in Java 8, you get a nice compile time error telling us the class inherits unrelated defaults.

I wonder why they chose not to support this. The cake patterns seems like a feature that adds flexibility without being able to shoot yourself in the foot too much.

 

2012 Technical Goals

I hate making resolutions but I like making goals. That might seem slightly contradictory but consistency is the bugbear of small minds and all that. Here’s a list of my current technical goals:

  • Write an iPhone application – I even have a half decent idea of what this should do thanks to Abe’s angry ranting at lunchtime. Thanks Abe!
  • Write a Node.js application – I’m not a fan of event loops since they are implicitly single threaded and so single cored. While this is a good fit for simple scatter gather web applications, as soon as you have any sort of processing you are a bit fucked. That said, one of my mottos is “don’t knock it til you’ve tried it” and while I’ve knocked up the obligatory chat server, I need to have a better understanding of
  • Write a Scala/Play!/Akka application and host it on Heroku – this should be an easy one and I’m looking forward to it. Scala, Play! and Akka could be the new JVM stack of choice and Heroku certainly looks the polyglot cloud platform of choice.
  • Write a Clojure application and host it on Heroku – not so easy since I don’t grok LISP but the constant chatter about the REPL and the power of immutability has a certain attraction.
  • Write a book – since my previous post was about this it should not be a surprise.
  • Present at more conferences – I popped my speaking cherry in 2011 and really enjoyed it. Now to really get out there.
  • Get more involved in the London Java Community – the LJC is an awesome group and the more you put in the more you get out.
  • Put more stuff on Github and open source it.
  • Convince my current client that they should open source their code – my current client have some really sweet code and they are happy to open source it but they’ve never done it. I have to push for this to happen.
  • Be technically excellent – I have some really challenging work coming up. It’s going to be tough and demanding and I’m going to have to be at my best.

What ever your goals are, I hope you have an awesome 2012.

Job Ads Are A Valid Indicator Of Programming Language Acceptance

I found an article from a mystery blogger here called Job Ads Do Not Reflect Programming Language Popularity that covered my post on Scala, Groovy, Clojure, Jython, JRuby and Java: Jobs by Language. It’s well written and pretty fair and I think that anyone who found the my original article interesting should go over there and read it. That said, there are a few points that I’d like to expand on if you will indulge me.

1) The job percentage of 3.5% for Java is across ALL jobs on indeed.com not just IT related ones (there are 2x as many Java jobs as there are listings for accountants 🙂 ) which makes the 3.5% value quite respectable.

2) The stats do seem to imply that Scala and Groovy have far more momentum than Clojure. I know some real Clojure fans but compared to the relevant Scala and Groovy user groups they seem to be a little more active. Also, both Scala and Groovy have killer weapon in the Akka and Grails frameworks. I don’t know if the same can be said for Clojure (Noir?) and would be happy to be proven wrong. I don’t think that the importance of having these weapons can be underestimated. It gives both languages great leverage in getting in the door of businesses and once they are in the door then I would expect more general usage to follow.

In the original article I showed the graph below and mentioned that it was likely that Scala would overtake Jython and that in fact, Scala’s growth rate had overtaken Groovy’s (although with a caveat that it was only a few data points and so could be a ‘flash in the pan’).

Now this is the same graph 6 weeks later…

It looks like I was right on both predictions (cue outrageous smugness!) but they both seemed reasonably obvious. The one thing I did not guess was the Groovy’s grow rate would have stalled like it has. I hope it’s only temporary.

The author goes on to give a very good time line of the development of a language but doesn’t mention that crossing the chasm is the hardest thing for any language and that’s where both Scala and Clojure are right now.

3) I completely agree with the average Java developer caring less for programming since it is currently the default language of the majority. By this fact you will find more close-to-the-mean programmers using it than any other language. Given the volume of jobs out there the stickiness of the jobs can’t be that different and because of this I think that job listings are a valid metric of the industry acceptance of a language. Even if they are only slightly indicative, you would have to show that jobs in other languages are 60x stickier to be on a par with Java or that Clojure jobs are 6x stickier than Scala jobs.

4) I hope that I never gave the impression that if you are a Java developer that you shouldn’t bother to learn new JVM languages. I completely agree with my mystery friend that knowing new languages makes you more employable. As someone deeply involved in the recruitment process at my current employer I can personally attest to this. I would go as far as to suggest that knowing more languages makes you a better programmer since it exposes you to more ways of doing the same thing. More tools in your toolbox gives you a better chance of picking the right one and using it correctly.

As for whether my final paragraph was too strong, I can only say that I call ’em as I see ’em. Yes I am a bigger fan of Scala and Groovy than I am of Clojure but please don’t take this as evidence that I am somehow against Clojure. Clojure is a beautiful language but it suffers from the fact that it lacks the aforementioned ‘weapon’ and is just so different from Java that companies will shy away from it worried about how long it will take them to spin up their entire workforce, not just their elite teams.

Maybe I can phrase it differently this time; it doesn’t matter whether you are a Java developer or not, the best thing you can do is to read “Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages” by Bruce Tate. Learning Ruby, Io, Prolog, Scala, Erlang, Clojure, Haskell will do great things for anyone’s understanding of programming languages.

 

Staying Sharp: Playing With New Technologies

My work has kicked into top gear in the last couple of weeks. I’ve had so many demands on my time that I have been unable to do any coding. Now I know that that is part and parcel of being a Tech Lead but the moment you step away from the code you start to lose the qualities that make you so useful to the business, i.e. being able to stick your nose into the codebase and shout “Yep, I know what this bit does.”

So I’ve been spending a few hours every night keeping my skills sharp on a project that a) has a direct impact on what I do everyday and b) is bloody good fun. How much fun I here you ask? So much that my wife forced me to sleep in the “huff” bed (the spare room – where you go when you are too angry or too drunk to sleep together) since I kept talking about what I was doing.

So what is it? Some multi-threaded mayhem of course!

Not really of course. I regard manual thread manipulation and the last refuge of fools and geniuses and I ain’t either. My current project is a web application which makes a large number of concurrent requests for each page request. We use various bits of the java.util.concurrent libs to do this. This works great but at scale can cause issues since each thread takes a few MB. Once you’ve spun up a couple of thousand of them, your machine has eaten itself. A solution to this would be to use Actors instead and since the excellent Akka framework can be used in Java and not just Scala I thought I would give it a go. At the same time, since it was a home project I thought I would use Git for version control.

I finished up the project today and it’s pretty cool. Akka’s syntax in Java is comparatively clunky to its syntax in Scala but I’ve seen far worse. Some perf testing on Monday should show what difference it makes and if it is good enough I might take it to the next LJC meeting.

Scala, Groovy, Clojure, Jython, JRuby and Java: Jobs by Language

In a previous post I pointed out that one of the more obvious recent changes in the Java landscape has been the meteoric rise in popularity of other languages for the JVM.  Some are old and some are new but JVM compatible versions of established languages with the likes of JRuby and Jython, Java-esque languages like Groovy and Scala and brand new languages like Clojure and Kotlin offer genuine options for those that appreciate the performance and reliability of the JVM but also want a different syntax.

In an ideal world all developers would be able to develop in the language of their choice. The reality is that as developers we are constrained by the suitability of the language, the tooling support and by what languages companies are actually using. Firstly, you choose the language appropriate to the domain – one that lets you do your job quickly and easily but with the appropriate level of support for your non-functional requirements like performance.  Secondly no one wants to be slogging through the coding process in a simple editor. Yes, I know that we could all use vim or emacs but being able to refactor large swathes of code easily and quickly (hello TDD!) kind of demands a modern IDE like IntelliJ or Eclipse. Thirdly, the reality of the situation is that very few of us are in the position to be able to dictate to our employers what language we should be using. Learning a language with rising popularity also means that you have a greater chance of being employed in the future (which is nice) but employers drive the acceptance of new languages.

The fact is that many companies boast about using the latest and greatest languages since it makes them more attractive to candidates. You can barely move for the blog posts and tweets of people raving about how their company has completely changed their development process with a new language but what is the real picture?

For a useful indication of industry acceptance we can go on the job trends on indeed.com. The grand daddy of language charts is Tiobe but it’s no use at this point since a) it does not provide sufficient information and b) is too easily gamed – yes Delphi dudes, we know what you did. Now before you complain, I know that using something like this is far from perfect and a long way from scientific but unless you fancy doing a longitudinal study going asking all the companies what they are using and believing their answers are real rather than marketing fluff, it’s probably good enough to be illustrative.

So what can this tell us about the how the industry sees the major language of the JVM: Java, Groovy, Scala, Clojure, Jython and JRuby*. What happens when we have a look at the percentage of all jobs that mention these languages

Umm, well… it’s pretty obvious that despite all the industry noises about other languages, Java is still massively dominant in the job marketplace with almost 3.5% of the jobs requiring Java knowledge. We all know that Java is an industry heavyweight but it is a bit of a surprise that in comparison the other languages are an indistinguishable line. Welded close to the 0 line, they would need some seriously exponential grow to start to threaten Java.

So what happens when you remove Java….

This is a lot more interesting. Firstly Jython was the first language other than Java that was really accepted on the JVM. Groovy started to pick up in 2007 and quickly became the first of the alternate languages, no doubt driven by Grails. Clojure and JRuby have never really garnered much support despite the recent rise in the last 18 months or so. I think the most interesting point is the recent increase in the acceptance of Scala. Currently third behind Jython, the gradient indicates that it will soon move into second. Comparing the grow rate of Scala and Groovy on a relative basis we see the following.

So we can see that Scala has finally crossed over Groovy’s growth rate. It’s completely reasonable to say that this could be temporary and that we should not read too much into this but there are a few data points there so it does not appear a flash in the pan.

So what can we say; while you’ll want to dust off the old Groovy text books and maybe have a look at some Scala tutorials, the best thing you can do is to keep your Java-fu in top notch order. As far as the industry is concerned Java is still the Daddy of the JVM languages and seems to being staying this way for some time.

* – I did originally include Kotlin and Gosu but since there were 0 jobs for Kotlin and only about 9 for Gosu they would only have been noise.

The First Class Languages of the JVM

The announcement of Kotlin, a JVM based language from JetBrains, drew quite a bit of attention. Firstly, when the makers of the best Java IDE in the world announce their own language you pay attention and secondly, it wasn’t that long ago that to the average developer the JVM meant Java and only Java and the rise of other languages on the JVM was some sort of bizzaro dream. While Jython (1997) and JRuby (2001) predate Groovy (2003-ish) it was the latter that really seemed to show everyone that something other than Java could be run on the JVM. The fact that Groovy is a super-set of the Java language meant that the barrier to adoption was very low and developers seemed to lap it up. This encouraged adoption but the push from the likes of SpringSource and the rise of Grails piggy-backing on Ruby on Rails’ success seemed to drive its acceptance. Even the fairly poor tooling support seemed to not be too much of a barrier as many companies started using it and benefiting from something other than Java.

Kotlin’s emergence does raise an interesting question;  from the developers perspective, what are the first class languages for the JVM right now and who will be in that list in 3-5 years time, and more importantly why?

Of all the languages that can run on the JVM, I would say that the the list of the premier league languages can be restricted to the following: Java (natch), JRuby, Jython, Clojure, Groovy and Scala (Kotlin is interesting but until Jetbrains write IntelliJ in it I won’t take it too seriously). Of these 6 languages it also interesting to note that only 2, Java and Scala, are statically typed and 3 are versions of a previous language: JRuby (Ruby somewhat obviously!), Jython (Python) and Clojure (Lisp dialect).

Scala has been seen as the language most likely to supplant Java but its complexity (especially the multiple different ways you can write and do the same thing) has held it back. It’s functional nature has also meant that many Java/OOP developers freeze in the headlights when Scala code switches to this mode. Scala is awesomely powerful and the likes of Twitter, Foursquare and GridGain use it in missions critical systems but it currently lacks that magic sauce that makes it accessible to mere mortal developers.

The same goes for Clojure. Lisp and its dialects has never really found a massive following in the commercial environment despite being held in high regard elsewhere. Even with the increasing interest in functional languages it still does not have the momentum required to be wildly successful but it is still early days for Clojure.

Ruby (1995) and Python (1991) are not new languages. Since there appear to be about 3.5 times as many jobs currently being advertised for Java than for Ruby and Python combined  it appears unlikely that even JVM friendly versions of them will be the next big thing. Don’t get me wrong, Jython and JRuby are great languages but they are hardly new kids on the block.

Groovy‘s similarity to Java makes it’s adoption very easy but its performance historically has not not great. I’m being polite since it’s actually sucked pretty hard.. Whether this is still an issue with the inclusion of JSR 292 in JDK 7(Supporting Dynamically Typed Languages on the Java Platform) remains to be seen but the dynamic typing does not tend to be as accepted as static typing in the enterprise context. I know this is a contentious point but Nuxeo moved from Python to Java and Twitter’s adoption of Scala indicate that context is important: if you have a large-scale performance orientated application, static typing is your friend and this is where Java is used heavily. Should you really like Groovy’s syntax and want static typing, Groovy++ offers what you need but again, does it offer enough to replace Java. I’d have to say no.

So what will be the language that retires Java? I have no idea and I don’t think that anybody else does either but I suspect that the language that finally does has not been written yet. It appears that the usage of Scala, Groovy, Clojure, Jython and JRuby will increase in the next few years but none of them seem to be the Java killer. The increasing adoption of languages with better type systems than Java seems assured for the the next few years but none of them seem to offer the combination of features to supplant Java.

If I had to back one of the runners, Scala appears to be the one with the most momentum as well as arguably the most power and functionality. The perception of complexity can be dealt with by education and training so it may well grow to be a contender to Java but given the learning curve, it is hard to see it ever replacing it. Who knows, it may be a language from an IDE company that finally sees Java developers cry “The King is dead, long live the King.”

Closure Syntax in Java 8

The expert group for Java 8 have announced the syntax for closures. Thankfully, they have chosen the sane route of choosing a similar syntax to Scala and C#. Quoting from http://mail.openjdk.java.net/pipermail/lambda-dev/2011-September/003936.html

The decision to choose this syntax was twofold:
– The syntax scores “pretty well” on most subjective measures (though
has cases where it looks bad, just like all the others do). In
particular, it does well with “small” lambdas that are used as method
arguments (a common case), and also does well with large
(multi-statement) lambdas.

– Despite extensive searching, there was no clear winner among the
alternatives (each form had some good aspects and some really not very
good aspects, and there was no form that was clearly better than the
others). So, we felt that it was better to choose something that has
already been shown to work well in the two languages that are most like
Java — C# and Scala — rather than to invent something new.

There is still some argument around fat versus thin arrow (surely a huge issue!) but for those of us that program in multiple languages it’s nice that they haven’t fallen for the “not invented here syndrome” and have chosen something that doesn’t require us to perform massive context switches when using something different.

Why we don’t use Doubles for Financial Calculations

My current client is in the middle of hiring some Java developers and as I mentioned earlier in March (Interviewing – the importance of PASSION!) I’ve been doing some of the interviewing. One of the things we’ve done is to create a technical task to see how the candidates actually code. It’s a simple exercise that requires them to think through some of the basics of financial operations and one thing that has surprised me has been the common use of doubles to represent financial values. It’s been highlighted for some time that this is not a great thing to do but someone actually challenged me to show that it wasn’t.

So here we go…

package com.bloodredsun;

public class DoubleOperation {

    public static void main(String[] args) {

        double t1 = 10.266d;
        double t2 = 10.0d;

        //Outputs 0.266
        System.out.println(t1-t2);

        double h1 = 100.266d;
        double h2 = 100.0d;

        //Outputs 0.26600000000000534
        System.out.println(h1-h2);
    }
}

Ouch! That is not what we want but it is the classic behaviour of doubles. The inability to represent some decimals in the IEEE-754 format (as binary fractions) causes this. If we want correct precision the answer is to use BigDecimals but we have to remember to use Strings in the constructors or you end up with the same issues that you were trying to avoid.

package com.bloodredsun;

import java.math.BigDecimal;

public class BigDecimalOperation {

        public static void main(String[] args) {

        BigDecimal t1 = new BigDecimal("10.266");
        BigDecimal t2 = new BigDecimal("10.0");

        //Outputs 0.266
        System.out.println(t1.subtract(t2));

        BigDecimal h1 = new BigDecimal("100.266");
        BigDecimal h2 = new BigDecimal("100.0");

        //Outputs 0.266
        System.out.println(h1.subtract(h2));
    }
}

That’s great but wouldn’t it be nice to use the normal operators rather than the overly-verbose method calls for the mathematical operations.

Now there is no way that we can do this in Java but if we let ourselves use another language on the JVM…

package com.bloodredsun

object ScalaBigDecimalOperation {

  def main (args: Array[String]) {
    var t1 = BigDecimal("10.266")
    var t2 = BigDecimal("10.0")
    //Outputs 0.266
    println(t1 - t2)

    var h1 = BigDecimal("100.266")
    var h2 = BigDecimal("100.0")
    //Outputs 0.266
    println(h1 - h2)
  }
}

Scala FTW!

PS if you want to know more about floating point operations have a read of What Every Computer Scientist Should Know About Floating-Point Arithmetic