Scala at Hello Heart – Adoption and a Bonus Training Plan

At 2016 I gave a lecture about Scala adoption in Hello Heart.

To make a long story short, while I personally really enjoy the language as a developer, we’ve experienced some problems in getting new developers up to speed. The language seems to be extremely frustrating to learn, even to – and I would dare to say especially to – the most experienced developers.

There are several factors that make Scala particularly hard:

The functional ideas in Scala are still new to many developers. While I don’t think Functional ProgrammingTM is necessarily “harder” than imperative programming, it is a new way to think about writing software. Learning ways to think is inherently hard, and the struggle can be a massive ego blow – especially if you are an experienced developer and expect to just “get” new languages easily.

You can end up with wildly different codebases, depending on the language features you use. The Scala language has many features, and it doesn’t constrain you too much in how you can use them. In a typical project, you wouldn’t use them all at once. Ideally, you would choose the subset of the features you prefer, and stick to them in order to achieve consistent style. This means you can see OOP Java-like style in one code base, functional, almost Haskell-y style in another, and any hybrid you can think of in between. Compare to Java code that is quite similar no matter where you look (a loop is a loop everywhere, as my mom would say).

Scala’s syntax is extremely flexible. Brackets? Which do you prefer? Because we do both. At the same time. Or either. Or none. Semicolons? Yeah you can use them. Or not. Hate dots? You can leave them out! Sure thing! Random punctuation marks for identifier name? Amazing! I’ve always wanted a codebase that looks like it was profanityped by a developer with massive anger management problems and an uncontrolled dirty mouth!

All these properties make Scala extremely fun to write DSLs in. And they do, my God, they do. So not only do you need to learn Scala when you learn Scala, you also need to learn the DSLs of all the different libraries used in your project.

All this brings me to my final point, which is that it is extremely hard to just open a source file and dive into the code. Unfortunately, that seems to be a preferred method of learning in our profession. Try that with Scala, and much hair pulling, curse words and cries for help are guaranteed.

So in order to shorten the learning curve, we created a training program that is meant to take a developer with some experience, and teach her everything she needs to know in order to be productive writing server code in about two weeks.

You can find our training plan here, and watch my lecture here:

Functional and Reactive Domain Modeling

When we introduced Scala into Hello Heart, one of our greatest challenges was not having anyone on the team with any kind of functional programming experience. We grappled with functional concepts and how they fit together and ended up with an object oriented/semi functional style code that can’t be considered even remotely good in any of these paradigms.

One of my realisations at the time was that as developers, we do most of our learning by reading and imitating other people’s code. We don’t always realise it when it happens because reading and imitating is what most of us do for a living at the beginning if our career, but when you are required to introduce a new paradigm you have no experience with as lead developer, the lack of that kind of experience becomes apparent.

Another thing I was lacking at the time was some understanding of common functional programming idioms and design patterns. Despite the community’s distaste for GoF, I still appreciate the way it shaped my object oriented thinking and the understanding it gave me of how the different object oriented concepts fit together, and how design patterns can be composed to build  software. I spent quite some time looking for a resource that will give me a similar experience with functional concepts.

I am now reading the book Functional and Reactive Domain Modeling, and it gives me exactly that. The book presents one functional design approach from the ground up and explains the different functional concepts that come into play on the way. While I’m not sure this is an approach I would like to adopt as is, it gives me great insight into the thought process of one functional system designer.

In other words, sh!t functional programmers say is starting to make sense to me.

Some Scala Randomness

I thought it’d be a fun exercise to implement a ?: operator for Scala, like the one Java has:

boolValue ? ifTrue : ifFales

I turned it into a ?! operator, though, because Scala didn’t like me trying to define a method called ‘:’.

implicit class FancyBoolean(val b: Boolean) {

	def ?[T] (ifTrue: => T) = if (b) {
		new TrueBranch[T] {
			override def ![A >: T, F <: A](ifFalse: => F): A = ifTrue
		}
	} else {
		new TrueBranch[T] {
			override def ![A >: T, F <: A](ifFalse: => F): A = ifFalse
		}
	}

	trait TrueBranch[T] {

		def ![A >: T, F <: A] (ifFalse: => F): A
	}
}

Let’s see how this stuff behaves:

scala> true ? 1 ! 2
res2: Int = 1

scala> false ? 1 ! 2
res3: Int = 2

scala> false ? 1 ! "Hi!"
res4: Any = Hi!

scala> true ? println("Evaluated true!") ! println("Evaluated false!")
Evaluated true!

Nice :)

Small Note About Concurrency

I’m reading Scala in Depth. In Section 2.3.2 on concurrency, the author gives the following example of a thread safe “index service” (removed trait definition for brevity):

class ImmutableService[Key, Value] {
  var currentIndex = new ImmutableHashMap[Key,Value]
  def lookUp(k : Key) : Option[Value] = currentIndex.get(k)
  def insert(k : Key, v: Value) : Unit = synchronized {
    currentIndex = currentIndex + ((k, v))
  }
}

The author shows that this implementation, is much faster than an implementation which uses a value reference to a mutable map, and synchronises both lookup and insert operation.

When I was reading this code, I was wondering whether this implementation is indeed safe. After all, the assignment operation to the var itself is not synchronised – do we have a guarantee that it is atomic?

The Java Language Specification answered my question:

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64-bit value from one write, and the second 32 bits from another write.

Writes and reads of volatile long and double values are always atomic.

Writes to and reads of references are always atomic, regardless of whether they are implemented as 32-bit or 64-bit values.

Note that in general, updating 64-bit chunks of memory in the JVM may not be atomic, but reference updates specifically must be atomic as per the JLS.

This is a rather delicate point – in the general case, if reference assignments were not guaranteed to be atomic (as is sometimes the case in other languages), this example would not be correct since the reading threads may see a partially initialised reference.

Since this is such a delicate point, I think it’s worth mentioning explicitly in the book’s text.

Reading List on Scala

Work in progress.

  1. http://www.scala-lang.org/
  2. Programming in Scala (by the man himself)
    Easy reading, clear explanations. Seems like the book was written with Java developers in mind, which is fine by me, being one. After working with the language for a while, I wanted do dive more deeply into some of the language features than what the book covers.
    It is still a good starting point, though.
  3. Twitter Scala School
  4. Effective Scala
  5. The Neophyte’s Guide to Scala
    Simple and clear explanations. Good stuff.
  6. The Scala tag in Stackexchange’s code review site (beta)
    So, learning language constructs is easy, but understanding how to think like a Scala developer and write idiomatic Scala is hard. Those of us who are lucky have senior developers who can guide us and from whose code we can learn, but those of us who must teach ourselves need to find alternative solutions.
    This site is a great resource. I skim the Scala section from time to time and read code reviews to get the feel of the language.
  7. A good article on transitioning to Scala