Skip to main content

Scala - Actors, or Back From Functional Programming to Object Oriented Programming

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 pitfalls. On the the other hand,  messages are now asynchronous, which increases the complexity of a system quite a bit.

As a consequence of that, I'm wary of sending messages to a bowl of actor spaghetti. Is the promise of a new non-blocking RMI worth it?

There are other ways.


Popular posts from this blog

Scala - Execution Order when Mapping Over Twitter Futures

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…

In Defence of the Software Engineer

It is often argued that software engineers are not real engineers as they lack the credentials and formal methods required to claim the title. I will counter that, first of all, these statements are simply false; and second, that this argument relies on a mistaken notion of what it means to be an engineer.

The credentials part is the easiest to argue as I am myself a Qualified Engineer certified by the engineering certification authority of my country, the Commission des Titres d'Ingénieur. Consider me the living proof that it can be done!

Now, that we don't rely sufficiently on formal methods as a profession can be argued either way. Some software developers will reject the idea of being engineers and prefer to call themselves craftsmen. It is true that in many cases a software developer has to come with unique and creative solutions to a problem, making it hard to apply formal methods. On the other hand, a lot of software engineering is rigorous and has a wide overlap with c…

The Engineering Mindset Overreliance Error

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 …