2 ms·
In my experience, business logic is often relatively easy to express in pure FP. Where things start to get trickier is the boilerplate and boundaries, e.g. I'm
by davedx 10y ago
In my experience, business logic is often relatively easy to express in pure FP. Where things start to get trickier is the boilerplate and boundaries, e.g. I'm writing a Rails app at the moment where the business logic is in pure functions, but the boundaries with other systems like ActiveRecord and external webservices tends to end up being more object-oriented.
For example, the ruby library I use to connect to webservices is very OO, and requires you to derive from its base class to build each webservice client.
This is of course very natural in Ruby, but I do see lots of OO in Scala libraries too (e.g. Spray).
- whateveracct 10y ago> In my experience, business logic is often relatively easy to express in pure FP. Agreed. This makes it a pretty easy sell to get everyone to commit to using immutability and purity and all those nice things in the business logic layer. > Where things start to get trickier is the boilerplate and boundaries, e.g. I'm writing a Rails app at the moment where the business logic is in pure functions, but the boundaries with other systems like ActiveRecord and external webservices tends to end up being more object-oriented. We're in the same boat, except in an in-house Java-based service framework. The "shell" of the program reads from the DB/makes service calls to gather input, passes this input to the pure business logic layer, and then based on the output throws exceptions, writes to the DB, makes other service calls, etc. This conscious division between effects and logic alone makes programs better. In areas where we need concurrency or have more complicated effects we wish to unit test, we have started to use scalaz.concurrent.Task and scalaz.Free.