From the archive: Originally posted in October 2011, I was reminded today of this post from my old blog, Graham Hacking Scala. I thought I should bring it over and give it a bit of a refresh…
In October 2011, I presented a talk at the 2nd meeting of the (then) new ScalaSyd Meetup. I talked through the “Top 10 Reasons Java Programs Envy Scala” in an attempt to give Java developers a taste of some little things that could make them much more productive if they switch to Scala.
Interestingly, in almost 4 years, very little has changed. Yes, Java 8 now has lambdas, but the standard collections library still makes very little use of them, forcing you to convert any collection to a stream before lambdas can be used, and pretty much nothing else mentioned in the talk has made its way into Java SE. People are still writing up lists of how to use Java better, but the fact is that a lot of Java best practices are either built into or easier to achieve in Scala.
Anyway, if you want get the real scoop on Java vs Scala and hear what all the Scala kids are raving about:
- hit play on the SoundCloud recording below, and then
- follow your way through the Prezi below that.
From the archive: Originally written in January 2010, this post from my old blog, Graham Hacking Scala, has been consistently popular ever since and I thought it deserved a new lease on life here…
Java at work: an increasingly frustrating experience
A colleague and I were writing a test in Java today and I had one of those “I can’t believe it takes this much work to write this stupid function” moments. If you do any Scala programming but still do a lot of Java programming, you’ll know exactly what I mean. I’ll walk you through a mock of what we were doing and you can see why Scala just pummels Java when it comes to expressiveness. (Early warning: do not use the word “expressive” when trying to convince your manager to let you use Scala at work.) Continue reading
From the archive: Originally written in January 2011, this post from my old blog, Graham Hacking Scala, has been consistently popular ever since and I thought it deserved a new lease on life here…
I started reading Joshua Bloch’s Effective Java last week. I’ll have to admit that I haven’t read it before, but only because I’ve been told by several people, “you already do most of what’s in there anyway.” Seeing as we tell all the new recruits to read it, I thought I should actually flip through it myself so I know what’s in there.
Books of best practices are always written in relation to domains that have many possibilities for bad practices (choosing otherwise would make for a very short book). Reading the first chapter of Effective Java, I was amused as I realised that, if you’re coding in Scala instead of Java, many of the book’s recommendations are either unnecessary, because Scala doesn’t permit the corollary bad practice, or built into the language of Scala, or made easier to implement than they are in Java. This isn’t a criticism of the book, but an observation that the state of the art is moving on, and Java is being left behind.
From the first 25 items in the book, here are my notes on practices that either become easier to follow or unnecessary if you are using Scala: Continue reading
You know Murphy’s Law, right? Or at least you know the way most people remember it: “Anything that can go wrong will go wrong.” It’s a fairly depressing way of summarising life, but we all recognise a large portion of truth within it. Things go wrong. All the time.
There’s actually contention over whether this is the original form of the law, which is named after aerospace engineer Capt. Edward A. Murphy, and there are several differing accounts of how the saying came about. My preferred account is that relayed by Australia’s Dr Karl Kruszelnicki, whose record of Captain Murphy’s original exclamation is:
If there are two or more ways to do something, and one of those results in a catastrophe, then someone will do it that way.
I like this version because it’s easier to see the qualified optimism that Murphy juxtaposed with his frustration. As Dr Karl explains, there is a hope embedded in this form of the law because it starts with a proposition: “IF there are two or more ways to do something…” Continue reading
The Story So Far
About two weeks ago, I wrote a blog post suggesting that Scala can make Java developers more productive. One of the comments on that post was that I had no metrics and so was spreading “folklore”. I took the criticism constructively and decided to solicit a small survey of Scala developers to try and get some insight.
What I Wanted to Learn
One of the most important things I’ve read about Lean Startups – and it’s important because it can be applied to a gamut of contexts, not just startups – is that, while the execution of the Lean process is Build, Measure, Learn, you actually have to apply this backwards to get good results: first you decide what you want to learn, that will inform what you need to measure, and that will determine what you need to build.
I employed this advice with this survey, asking first: “What do I hope we learn from this”, and using that to inform the content. Here are the questions for which I wanted the survey to provide some insight: Continue reading
Update: The survey has closed and you can have a look at the results here.
Yesterday I wrote a blog entitled ‘A New Java Library For Amazing Productivity‘, which was – in all honesty – a trap: a well-intentioned honey trap with the purpose of trying to convince developers that they should be looking at Scala and evaluating it on the merits of its potential to deliver productivity gains, just as they would with a library or framework, rather than discounting it because it’s a “language”.
One of the comments I received was from Stephan Schmidt who writes the ‘codemonkeyism’ blog. Stephan wrote:
The sad state of our industry: Folklore.
Huge claim: “A New Java Library for Amazing Productivity Posted on February 11, 2013″
No facts or numbers. Continue reading
I’ve found this great Java library that can make developers more efficient in pretty much every source file they write. It has the following features:
- a broad and powerful collections framework
- collection methods that greatly reduce boilerplate
- immutable collections that don’t have mutation methods (unlike java.util classes where e.g. List.add() throws an exception if the list is immutable)
- an awesome switch-like function that doesn’t just match numbers, enums, chars and strings, but can succinctly match all kinds of patterns in lots of different classes, even in your own classes
- an annotation that automatically writes meaningful equals, hashCode and toString methods for classes whose fields don’t change (without using reflection) Continue reading