Scala

Why I Introduced Scala In Our Project

I don’t like Scala. And I think it has some bad and very ugly aspects that make it a poor choice for mainstream development.

But recently I still introduced it in our project. Not only that, but the team has no experience with Scala. And I’ll try to explain why that is not a bad idea.

  • First and most important – I followed my own advice and introduced it only in a small, side module. We didn’t have acceptance tests and we desperately needed some, so the JBehave test module was a good candidate for a scala project.
  • Test code is somewhat different from “regular” code – it is okay to be less consistent, more “sketchy” and to have hacks. On the other hand it could benefit from the expressiveness and lesser verbosity of scala, as tests are generally tough to read, especially in their setup phase. So Scala seems like a good choice – you can quickly write concise test code without worrying too much that you are shooting yourself in the foot in the long term, or that multiple team members do things in a different way (as Scala generously allows). Also, in tests you don’t have to face a whole stack of frameworks and therefore – all the language concepts at once (like implicits, partial functions, case objects, currying, etc.)
  • I didn’t choose a scripting language (or groovy in particular), because I have a strong preference for statically typed languages (yeah, I know groovy has that option for a couple of years now). I it should’ve been a JVM language, because we’d want to reuse some common libraries of ours.
  • It is good for people to learn new programming languages every now and then, as it widens their perspective. Even if that doesn’t change their language of choice.
  • Learning Scala I think can lead to better understanding and using of Java 8 lambdas, as in Scala you can experience them “in their natural habitat”.

(As a side-note – IntelliJ scala support is now better than last time I used it (unlike the Eclipse-based Scala IDE, which is still broken))

If writing acceptance test code with Scala turns out as easy as I imagine it, then it can mean we’ll have more and betters acceptance tests, which is the actual goal. And it would mean we are using the right tool for the job, rather than a hammer.

Reference: Why I Introduced Scala In Our Project from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.

Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE, as well as Android, Scala and any framework you throw at him. creator of Computoser - an algorithmic music composer. Worked on telecom projects, e-government and large-scale online recruitment and navigation platforms.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Mariusz
Mariusz
7 years ago

Hi, I don’t think you really explain why you went with Scala. I’m not really a Groovy advocate but all the points you raised are just as relevant for Groovy. I mean which concrete language feature made you go for Scala? If its ease of writing concise tests you have Spock have you looked at that?

Back to top button