prose :: and :: conz


Scala: The language of agility?

I’ve been thinking about writing this post for a while now, and this post bidding farewell to Scala has prompted me to finally do it. In particular, this snippet from the first paragraph:

But as soon as I started working in teams writing Scala, your immense syntax started drowning me. At first, I took it as a compliment that you tried to please me by offering me to work the way I liked. But then I noticed that it wasn’t something you did for me in particular. Instead, you try to be everybody’s darling by offering every software development paradigm known to man.

Matthias raises a valid and oft-cited point here. Scala has no “Right Way” or opinion on how to do things. There is no prescriptive guidance offered. You can work with Scala as a better Java much like Groovy, or you can use it as Haskell-lite on the JVM with Scalaz. As Neal Ford once described Scala, it is “a vast parking lot from here to functional programming, where you can go anywhere or any distance and stop to set up camp where you like.” (Not really a quote because this is from memory, which is an unreliable source). I am in 100% agreement with Matthias and Neal.

However, I don’t agree that this is necessarily a bad thing. There are many merits to having a language (or any tooling for that matter) with a stricter paradigm for having a “Right Way” to do things. For instance, it allows less friction for developers moving among teams with similar stacks. It can also allow stronger more powerful invariants of your applications. But are there merits on the other side of the fence?

I think so. I’m not a big fan of prescriptive guidance. While such things can be good starting places (like Scrum for organizations which have been long-sentenced to waterfall), they don’t pan out well over time. Eventually the team sees that its needs are better met by breaking the rules. In fact, my team has recently cast aside scrum in favor of a continuous-flow/kanban approach to our development. I’m also rather fond of my tooling allowing the same freedom.

My team is able to decide what our approach is. Are we just a better Java? Nah, I think we’re further along than that. Are we Haskell-lite? Nope, Scalaz is not in the dependency list. Frankly, where we are today is a big stretch from where we were. There is no way I could have sold this team on Haskell or even Clojure. They weren’t ready for unadulterated functional programming. I’ve had to ease everyone (myself included) into this paradigm. As we get better, our standards change and the language is able to adapt to that.

Another good example of this is my beloved Lift. Even though former BDFL David Pollak recently lamented not having a “Right Way” to do things in Lift like Ruby on Rails, I think Lift got it right. This is one of the very things that attracted me to Lift from my previous love in web, Grails. While working with Grails, I was always forced to solve problems the way they want me to. Unfortunately for that approach, they wanted me to solve problems I didn’t have. In my past life in telecom, the management application I worked on was not focused on a database as the central source of information. Instead, the source of truth was a live network where the database was really just a cache. Having an MVC approach where all of the models autowired themselves to a database didn’t make any sense. With Lift, I’m able to write an application that is backed by whatever I want. It can have no database at all. It’s just a tool that solves problems related to serving HTML, resources, etc.

I’m not attempting to dismiss the objections of those who point out this characteristic of Scala. It is real, and it is a problem for some teams/people. I would just like to highlight some of the good things which can arise out of the approach taken by Scala. In agile, decisions are always left up to the team. I feel that we made the right choice with Scala for this reason. Rather than demand we mold our domain problem to the tooling, this malleable language molds itself to our domain.

Leave a reply below, or send me a tweet.


Olde Comments
  1. Thanks Joe for the blog post. I really enjoyed reading it and wholeheartedly agree with what you’re saying. And I’m glad it was very comprehensive – no fluff just stuff, I’d say. I think it’s very important in such blog posts as the point has to be clear and comprehensible.

    I remember the days when I almost hated Scala very well because…it got into my way to promote Clojure as the functional programming language for the masses since almost all (in Poland and around) were into “the better Java” – be it Groovy or Scala. I couldn’t explain why people were so fond of Scala – it’s so much more complex than Clojure (or Groovy). Soon I abandoned Groovy and later Clojure for Scala to teach myself and others functional programming and, guess what, after few bumpy “meetups” with Scala I’ve immersed into the language completely and have not since looked back (it’s not to say that Clojure in particular is a worse language – I’m far from it). I can’t explain the reasons exactly for me to stick to Scala, but it’s more about the language being **hard enough** to stretch my current thinking about programming and after few months Scala became my “better Java”.

    BTW, you also taught me two new phrasal verbs – pan out + cast aside. Thanks!

    • barnesjd says:

      Thanks for stopping by Jacek! I think you are the first person I have encountered who transitioned from Clojure to Scala. :) Indeed Scala is can be more challenging than Clojure… There is a lot more one has to learn. That doesn’t make it better or worse, just different.

      Be careful learning English idioms from me. We south-eastern US citizens are not well-regarded among the English speaking people in that regard! :D

Tagged with: scala (41), liftweb (9), agility (7), grails (2), groovy (2)