Monday, December 29, 2014

Where FP meets OO

A strong feature of Scala is the embracing of both Functional Programming (FP) and Object Orientation (OO). This was a very deliberate and early design decision of Scala in recognition of the strengths of both approaches over the decades. I hope to show you that utilising both approaches to developing software can work together.

Over the past two years of using Scala on a daily basis I’ve found myself adopting a predominantly FP approach to development, while embracing true OO in the form of Akka’s actors. What this boils down to is side-effect-free programming with functions focused on one purpose. Where state is required to be maintained, typically for IO style scenarios, then actors come to the rescue. Within those actors if there are more than 2 state transitions then I find myself using Akka’s FSM where upon it maintains the state through transitions. As a consequence, there are very few “var" declarations in my code, but I don’t get hung up on their usage where the code becomes clearer or there is a performance advantage in some critical section of code.

I can’t even remember the last time I used a lock of some type...

Thus my actor code looks something like this:

object SomeActor {
  def props(): Props =

  // My actor’s other pure functions,
// perhaps forming the bulk of code.
// The functions are typically private
// to the package and therefore
// available for tests within the
// same package. 
class SomeActor extends Actor {
  override def receive: Receive =

  // Functions that break down the
// receive handling calling upon the
  // pure functions of the companion and
// possibly other traits

What I find is that as I expand the companion object with pure functions, patterns of behaviour emerge and its functions are factored out into other traits which of course become re-usable and remain highly testable. Sometimes I form these behavioural abstractions ahead of creating the companion object, but more often than not it is the other way round. I’m big on continuous re-factoring and spend a lot of time attempting to get the functional abstractions right. This can mean that the functions are often re-written once the behavioural patterns emerge.

So why then is the above representative of OO? Actors permit only message passing and are completely opaque to the outside of their instance. This is one of Alan Kay’s very early requirements of OO. Actors combined with Scala also mostly fit his following requirements (taken from

  1. Everything is an object.
  2. Objects communicate by sending and receiving messages (in terms of objects).
  3. Objects have their own memory (in terms of objects).
  4. Every object is an instance of a class (which must be an object).
  5. The class holds the shared behavior for its instances (in the form of objects in a program list).
  6. To eval a program list, control is passed to the first object and the remainder is treated as its message.

Point 3 is a weak point of the JVM and one should be careful about message payloads remaining immutable, but at least with Scala, immutability is the default way of coding. It’d be great if actors themselves had their own address space. However this has never raised itself as a problem in my world.

Scala is one of the few languages that marries the world of FP and OO and thus does not need to “throw the baby out with the bathwater”. Many other languages force you to make a choice. That said, just like most marriages, there’s always the dominant party making the most sense, and that’d be FP!

Wednesday, January 1, 2014

Reflections on Java, JavaScript and Maven for 2013

About a year ago I made some predictions on Java, JavaScript and Maven for 2013. There has been some movement, so time to report back:


Java 8 didn't quite make it as a GM release, but mid-March 2014 now appears to be the date. Java 8 has been available for playing with for some time during 2013 though.

I must confess to having been excited at the prospect of Java 8's lambda support a year ago, and I still think that what's coming is a great boost to the language. However I'm now squarely in the functional camp and, well, Java simply won't cut it. If you have an interest in functional programming, my personal recommendation is to move to a language designed for the job. Languages such as Scala which offer the best of the imperative and functional worlds are the ones to look at.


This one is mostly pinned to the release of Java 8 and Nashorn - DynJs hasn't really taken hold as I thought it might. So, may be March 2014 for this also.

Projects such as Trireme are particularly interesting as they bring the Node API to Rhino. I suspect that projects like this can be adapted to Nashorn, and I also see that Nashorn may provide its own Node API implementation, although the details on this are light. No matter what happens regarding Nashorn and its Node offerings, I suspect the Trireme and Rhino combination will remain relevant for some time given their Java 6 focus.


Maven continues to be strong however my hope for an alternate DSL for the pom hasn't materialised… sort of… Tesla polyglot is ready for a release and offers Groovy, Ruby and Scala DSLs for Maven. I actually wrote the Scala dsl :-)

I suspect that Tesla polyglot will be released sometime during the first quarter of 2014.


I feel that my predictions were largely on track, although they certainly haven't materialised within the timeframe that I expected. There's been considerable progress across all three fronts though and I'd be very surprised if they haven't materialised by the first half of 2014.