Software Engineering Consulting

Lies, damned lies, and mathematics. - Mark Twain

You know that something is fishy when people start using complex math when they don't need it.

Immutability, no side effects? Yes, when it makes sense. Every smart developer will get to this point eventually.

But category theory everywhere? I call it math envy.

Do you really think that because you are using only pure functions your program will be bug free? More performant? Faster to develop? Easier to maintain?

I started my Scala journey 7 years ago in a pragmatic way compared to the functional programming enthusiasts of nowadays (although a research lab made me program a media player using only XSLT — you can't get anymore functional than that!). At the time I had written a few Java programs of medium complexity and I often bumped into the limitations of object oriented programming.

Modeling everything as objects — with their promise of encapsulation — seems nice and tidy in theory but, as the size of the program grows, side effects create unforeseen interactions. I found it easier to reason in terms of immutable data and functions, which led me to write my programs in a more functional way over time.

Fast-forward to the present day and Scala has now become partly synonymous with Akka Actors which, with their message passing semantics and encapsulated internal state, are a new incarnation of object oriented programming.

Granted, it does not include inheritance and its associated pitfall…

If you program in Java, you probably know that the compiler performs type erasure for performance and backwards compatibility reasons. Thus, parameterized types of generic collections are normally not accessible (although you can work around the limitation using reflection or by passing the class  explicitly).

Scala comes with the concept of ClassTag and TypeTag which enable you to enrich the accessible type information. Using type bounds, it makes it easy to access type information at runtime.

However, using ClassTags and TypeTags requires importing from scala.reflect. Does this mean that it uses reflection, a scary thought when considering performance? Here is a quick unscientific benchmark to figure things out with Scala 2.12.4:


As you can see, using ClassTags incurs no performance penalty compared to case class pattern matching. On the other hand, TypeTags is significantly slower due to it bringing along richer type information. Only use the latest if you really need it!

In my previous startup life, I built a web application which purpose was to help companies screen applicants during the recruitment process, so that they could recruit employees that were the best fit for them. Our product was quite innovative in the sense that it matched the personality of applicants with the culture of the recruiting company. In order to do that, we would first send questionnaires to the current employees of the company to determine its culture, and then we used statistics, machine learning, artificial intelligence to compute a fitness score for applicants, based on their answers to their own questionnaire. The idea was well-received and we got a few clients pretty fast.

Problems began we started improving our solution. Reading the scientific literature on recruitment, it soon appeared that IQ was the single most important factor for predicting future performance of employees. As our goal was to help companies recruit the best people for them, it seemed logical for …

As Twitter Futures don't have the concept of ExecutionContext (unlike plain Scala Futures), it is at first hand hard to know what gets executed when and where...

One creates a Twitter Future by specifying the FuturePool in which it will run:
In this case, the content of the code-block will be scheduled to run immediately as the unbounded pool has no limit to the number of concurrently running tasks.

One can also create one's own FuturePool. For example, in the code example below, we create a FuturePool limited to two concurrent tasks:
Now, getting to the crux of the matter, the question is: in what pool does the code passed into the map function run?
Looking at the output copied at the end of the snippet, you will notice that it runs immediately after its corresponding Future has completed. The total number of active tasks stays limited to two, from which we can deduce that it gets run in the same thread pool as its Future.

Could one run the map statements in another pool? Yes…

The major goodie of (micro)services is low coupling, i.e. isolation. Isolation of domains with bounded contexts; isolation of technology choices (one service will use a relational database while the other requires NoSQL); and finally, organizational isolation (different teams can work on different services with low friction).

But then, I have seen situations where it was decided to share some common libraries between all services within an organization. To me, it seems like a slippery slope on the way of losing the benefits of a service architecture.

If you are sharing a common entities library, then your bounded contexts are at risk of merging too much. If you are sharing a common utility library, then you are sharing technological choices, often dragging some external dependencies with specific versions which will make it hard to evolve services independently. You will also be introducing organizational friction as teams start to depend on each other's libraries.

Is the economy …