Scala - Just enough rope to hang yourself

Last week Dan and I did a presentation at the Springer offices for the Functional Media meetup about our experiences with Scala. We thought it would be interesting to talk about the mistakes we had made with Scala as we thought that would be more interesting than rehashing a number of other talks about why Scala is or isn't good.

You can find the slides here

Scala is a very feature rich language and because of this there are many ways of doing things. This was how Scala was designed, to allow developers to express themselves in a flexible way in comparison to languages like Java.

This flexibility is a double-edged sword and I think this not only effects our team but can also effect the OSS community around Scala. Some developers see the power in being able to write DSLs or construct cool type systems which they think will be really useful but aren't actually as generalised and good as they think and can hamstring other developers. As Jeff Atwood says writing re-usable code is hard and that is especially true when with a flexible language like Scala.

This immediately comes to mind when I read this post by Giles Alexander.

I can actually appreciate some of the author's sentiments. If I started Scala without the aid of working with some very experienced programmers in a pair programming environment I imagine I would find it a nightmare too.

His complaints about def and val to me seem like inexperience in his team with Scala, which then means the resulting code is difficult for everyone. Again, this is Scala's flexibility hurting a team. I actually think good Scala code reads really well, but it takes some discipline and knowhow. Scala can tempt you into writing code you think looks great but is very hard for other people to read.

Lessons from our talk

If you want to have a productive team working with Scala, we feel you need

• An enthusiastic team - A team that really wants to learn Scala where individuals demonstrate new powerful ways of getting stuff done to the rest of the team
• Pair programming - This helps newer people get up to scratch with Scala.
• Code review - You want to encourage your team to learn how to weild Scala's power but at Springer we make sure we have weekly team code review where we go over code so everyone understands
• Question things - "The functional way" is not a catch-all argument winner. Leveraging Scala's power is great but readability is the most important factor in code for us.
• Monitor build times - You cant really avoid Scala's compilation problems. But if you invest a little time with CI to measure it, you can take steps to manage it.

Generalists

There seems to be a demand on a lot of developers to be "generalists" who know a number of languages and can be productive with them. This is a perfectly valid goal as it means developers generally have a broad and open mind about technical approach.

I'm not entirely sure if Scala is well suited to this as to write good Scala requires you to put effort into learning and appreciating the language. It is a power tool and it means you have to spend time to know how to use it responsibly so you can write concise, readable code.

Some would say this is a bad thing, but after working with Scala for a number of years now and if I was to change language I would want to make sure I picked a language which offers the same power and flexibility of Scala; otherwise I would probably feel like I am fighting the language to get things done.

I totally understand when people accuse Scala being cryptic and bloated, but I think that mainly comes from either using a horrible library of just being inexperienced. I think the true power of Scala is that it gives me the opportunity to express the intent of my code without the need of complicated boilerplate. However, it takes time to get good at it and to be honest that's what I like about it, there's always more to learn.