Functional Scala Benefits
The benefits of going functional are to get to code that is: Modular, Abstract, Composable.
Modularity is about being able to fit entire sections of code in your head without having to consider things going on outside that code, and also about being able to replace small parts without affecting the whole.
To write a total function (a function that returns a result for all possible input values), you need to elevate all possibilities into the type system. For example, you can’t throw an exception, you have to encode that possibility of an error into the return value somehow.
Abstraction should reduce changes to code, because unnecessary detail is not all across the code.
Whole systems can be composed from functional components.
Functional Scala at REA
The team at REA picked Scala partly because they wanted strong types, and having object-oriented capabilities made the learning curve smaller for the team of Java programmers. Also, someone converted part of a service to Clojure as an example, which made everyone want to try Scala.
They used Play2 as the web framework to start with, but found it too heavy, very opinionated, and they were fighting against it.
With the second Scala project, they forgot to invest in learning and that resulted in an okay technical result and a poor sentiment.
The second team to start on Scala (third project) picked a different tech stack (unfinagled, argonaut and slick). In went well, and the first team stole lots of their good ideas and learning for their next project.
They then tried to use monad transformers for dependency injection. This proved to be a massive learning curve, and even the senior devs didn’t get it. The technical result was okay, but only two people really understood the code.
Ken had two great comments after this experience:
“Ultimately, we have to bring people along, not leave them behind.”
“If you can’t make a new concept learnable, you shouldn’t use it.”
A team with no Scala mentors tried to employ Scala while learning through trial and error and code katas. It didn’t work out so well.
Emerging functional design trends at REA
Emerging design trends they’e converged towards:
- Replaced inheritance and mixins with static functions.
- Abandoned partial functions (eg throws exception) in favour of total functions.
- Replaced exceptions with sum types (Either)
- Says Ken: “exceptions are essentially a goto”
- Replaced strings and primitives with wrapper types. String has too many possible values. Your total functions don’t want to deal with all of those.
Learning Functional Scala
He said the “Functional Programming in Scala” book is really good.
It’s important that learning is done during work time. REA uses the “guild” model made famous at Spotify where groups of people from across the organisation but interested in the same technology meet together to learn from each other.
On their latest project, #17 with Scala, they’re using: unfiltered, argonaut, slick, and free monads for dependency injection. They put a huge investment into people’s learning for this project and consequently had a great result. People were able to understand the code and the service has a large pure functional core with thin layers of interpreter and web access at the front.
“The only purpose of mocks is to point out design flaws in your code, so you can fix them and remove the mocks.”
Ken finished off by observing:
“FP is a tall tree, but there is so much low hanging fruit.”
Want to learn more?