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.
This evening I went to a YOW Night where Ken Scambler (@KenScambler) spoke about the introduction and evolution of using Scala at REA Group. Here’s my notes…
Functional Scala Benefits
The benefits of going functional are to get to code that is: Modular, Abstract, Composable.
Modularity is about being able to fit entire sections of code in your head without having to consider things going on outside that code, and also about being able to replace small parts without affecting the whole.
To write a total function (a function that returns a result for all possible input values), you need to elevate all possibilities into the type system. For example, you can’t throw an exception, you have to encode that possibility of an error into the return value somehow.
Abstraction should reduce changes to code, because unnecessary detail is not all across the code.
Whole systems can be composed from functional components.
Functional programming is not about picking up a hipster language. It’s about producing better software.
I didn’t think anyone would seriously ask this question. However, after yesterday’s post about why your company should let you use Scala at work, which used a simple example showing the use of lambdas in Scala, I had someone write in the comments:
“java 8 equivalent of your example would be identical, no need for Scala…”
and someone else commented on Twitter:
The call to compare against Java 8 is a fair one, so here we go… Continue reading
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
I recently used RxJava while creating an add-on for Stash, the Git repository management tool from Atlassian. The plugin’s called “Who’s the Expert?” and it analyses commits to a repository to help answer two questions:
- “Who has contributed the most to this project over the past few years?” and
- “Who has made the most significant changes in recent months?”
A Problem Worthy of RxJava’s Attention
In order to achieve this, the plugin has to process a lot of data: it pulls all commits on the default branch for the last 2.5 years and analyses the content of every single one. I knew two things about this code in advance: first, there were going to be a lot of steps to go from a repository name to a leaderboard of the most influential committers, and second, I was pretty certain I’d need some multi-threading mojo in order to get it to perform in an acceptable time frame.
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
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
I think the term ‘Domain Specific Language’ (DSL) is starting to become over-used and is being applied to things that aren’t really languages at all.
A Tale of Two Designers
When I think about explaining DSLs to people, the examples that spring to mind are languages like SQL, Regular Expressions, maybe even BNF, or CORBA IDL. And if I think about Why these languages exist, I imagine that somewhere, at some time, somebody thought:
I’m going to design a new language that is specifically crafted for solving this particular problem.
I like DSLs. Or maybe it would be more accurate to say I love them. They are powerful, expressive, and allow people who are eager to describe a solution or encode information (be they programmers or otherwise) to escape the complexities of imperative paradigms and Von Neumann thinking, permitting a strong focus on the actual problem.
In contrast to the above, the way in which I’ve most frequently seen the term DSL used of late is from people thinking something more like this: Continue reading