Quantcast
Channel: prose :: and :: conz by joescii » Software Development
Viewing all articles
Browse latest Browse all 13

Scala: The language of agility?

0
0

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.



Viewing all articles
Browse latest Browse all 13

Latest Images

Trending Articles





Latest Images