Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 522 posts at DZone. You can read more from them at their website. View Full User Profile

Scala: Our Retrospective of the benefits/drawbacks

11.30.2011
| 5070 views |
  • submit to reddit

As the closing part of a Scala Experience Report Liz and I gave at XP Day we detailed a retrospective that we’d carried out on the project after 3 months where the team outlined the positives/negatives of working with Scala.

The team members who were there right at the beginning of the project 3 months earlier had come up with what they thought the proposed benefits/drawbacks would be so it was quite interesting to look at our thoughts at both times.

Some of this is available in our slides from the talk but Nat Pryce suggested it’d be interesting to post it up in more detail.

We weren’t aware that we’d be doing this exercise until the session where we did it and noone looked at the original answers so hopefully some of the potential biases have been removed!

JUNE
  • +++ Increased developer productivity
    • Higher-level language constructs (functional programming, actors, pattern matching, mixins, etc.)
    • Less code -> less time spent reading code / less defects
    • Syntax is better suited for writing DSLs (e.g. SBT, Scalatra, ScalaTest, etc.)
  • +++ Bigger potential to attract talented developers (not using the same old ‘boring’ stack)
  • ++ Gentle learning curve for Java devs
  • + Built-in support at language-level for handling XML
  • + Comes with SBT, a powerful build tool
  • + Seamlessly integrates with Java and it’s ecosystem
  • + Runs on the JVM (i.e. no operational concerns)
  • — Bigger potential to screw things up (think: “with great power comes…”)
  • – Tool support is less mature and polished (e.g. IDEs, profilers, metrics, etc.)
  • - Community is younger and smaller
  • - Scala compiler seems to be slower than Java counterparts
SEPTEMBER

Liked:

  • +8 Easy to learn
  • +8 Functional Language (Immutable, closures, etc)
  • +6 Concise code
  • +5 SBT power
  • +4 Case classes
  • +4 XML support
  • +4 Java integration
  • +3 List processing
  • +3 DSL support
  • +2 Helpful community (IRC, StackOverflow)
  • +2 Performance

Disliked:

  • -8 IDE support (refactoring, plugin quality)
  • -5 Slow compiler
  • -3 Code can become complex to read
  • -2 Lack of XPath support in XML
  • -2 SBT complexity
  • -2 Immature frameworks

Quite a few of the expected benefits from June were observed in June, such as having to write less code, functional programming constructs, XML support and the ability to write DSLs.

The community was one benefit which wasn’t expected – we’ve found that every time we get stuck on something we can go on Stack Overflow and find the answer and if that doesn’t work then someone on IRC will be able to help us almost immediately.

Complexity

Our experience with Scala’s complexity partly matches with that of Stephen Coulbourne who suggests the following:

Scala appears to have attracted developers who are very comfortable with type theory, hard-core functional programming and the mathematical end of programming.

There is also a sense that many in the Scala community struggle to understand how other developers cannot grasp Scala/Type/FP concepts which seem simple to them. This sometimes leads Scala aficionados to castigate those that don’t understand as lazy or poor quality developers.

We’ve tried to be reasonably sensible with the language and only used bits of it that the whole team are likely to understand rather than learning some obscure way of solving a problem and checking that in.

On the other hand reading the code of Scala libraries such as scalaz or SBT is something that I, at least, find extremely difficult.

Changing the SBT build files can be quite a scary experience while you try and remember what all the different symbols mean and how they integrate together.

Learning curve

The learning curve for Java developers has been a bit of a mixed experience.

When we started working on the project we were effectively writing Java in Scala and we’ve slowly learnt/introduced more Scala features into our code as time has passed.

I think everyone who has come on that journey has found the transition reasonably okay but we’ve had other team members who joined later on and went straight into code that they weren’t familiar with and for them it’s been more difficult.

Again, again!

It will be interesting to see the team’s thoughts if we do the exercise again 3 more months on.

I would imagine there would be more ‘dislikes’ around code complexity now that the code has grown even more in size.

It probably also mean the lack of IDE support becomes more annoying as people want to refactor code and can’t get the seamless experience that you get when editing Java code.

 

From http://www.markhneedham.com/blog/2011/11/28/scala-our-retrospective-of-the-benefitsdrawbacks/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Otengi Miloskov replied on Wed, 2011/11/30 - 7:56am

Java supposed to be the complex, verbose and old language and we need a new fresh air of language that will relieve us of it and here enters Scala but wait a moment instead of relieve us it is making more complex and difficult the situation. So for what is Scala?.
Scala, It has the speed of C++? Nah, Easier than Java? Nah, Dynamic as Ruby? Nah, So Scala where match in all this?, Me NO CLUE. Im not sure what the Scala people are advocating.

Functional Paradigm?, Right now almost all the programming languages on earth use in one way on another functional concepts so that is not the point, What is Scala point on all this?, Scala advocates please speak it up?!.

Nicholas Sterling replied on Wed, 2012/11/14 - 5:25pm

I'd like to offer some additional perspective.

Speaking of "programmer productivity" as if it were about how long it takes to write code might give people the wrong impression.  Sure, it's a joy to write 30 lines instead of 100, and it does save time.  But 2/3 of the cost of software, typically, is in its maintenance, and the big win is that you have that much less code to grok 6 months from now.  And it's not just that there is less code to look at -- it's also that functional code is easier to reason about.  When code consists largely of functions on immutable data, the state being processed is not a moving target.  And actors are far easier to get right than a bunch of threads mutating shared state and using locks to avoid tripping over one another.

And if it's hard for you to grok a blob of your own code 6 months later, consider the poor guy or gal who inherits it when you move on.  The time you saved writing less code is a pittance by comparison.  Who among us hasn't spent hours analyzing some imperative hairball, ultimately testing a desired change into existence and thinking "I wonder if I missed any cases in my testing..."?

Also, whenever I hear that Scala's tool support isn't as good as Java's, I feel compelled to say that I consider a REPL one of the most important tools in the tool chest.  Scala wins big on that one.  And now you can add the Scala Worksheet to the plus side of the ledger as well.

To each his/her own, but I am *much* happier using Scala.  I can't see myself going back to Java.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.