Tag: scala programming

Scala Job Interview – Reactive Programming

Here we are with the fourth installment in this Scala Job Interview series. The first was on general questions, the second on Scala language, and the third on functional programming.

Explain the actor model

In this case, the Actor Model has nothing to do with the Star System 🙂 I’m not sure where the term actor in “actor model” comes from. but, quite for sure, it has nothing to do with Hollywood, but more with the idea of something that “acts”, i.e. makes actions.

In fact, the Actor in the Actor Model is a processing entity that receives and reacts to messages. More precisely an Actor can only perform computation on the receipt of a message, when message processing is done, the actor just idly waits for the next incoming message.

Continue reading “Scala Job Interview – Reactive Programming”

Scala Job Interview – Language Questions

This is the second installment of this series. The first post in the series gives you a bit more context. Anyway, this is my try to answer Scala Interview grade Questions I found in a blog post by Signify. You can find alternate answers here.

Language Questions

What is the difference between a var, a val and def?

All these keywords are for declaring something. var declares a variable, val declares a variable that cannot be re-assigned and def declares a function.

scala
var a = 3
val b = 3
def c = 3

In the above code, a is a variable as you can find in almost every language, you can increment it, re-assign it. Standard stuff.

b is a variable bound to value 3 forever? Attempting to change its value results in a compile-time error. c is a parameterless function that returns 3. Interestingly a, b and c evaluate to the integer 3. Also note that val just prevents reassignment, not value change. E.g. in the following code:

scala
class Foo {
  private var a: Int = 3
  def change( newA : Int ) : Unit = { a = newA }
}

val x = new Foo()
x.change(8)

There is no compile-time error because you are not changing the bound between x and the instance that references. You are just changing the instance.

Continue reading “Scala Job Interview – Language Questions”

Scala Job Interview Answers

Idling over Twitter I came across a post on Signify blog about a list of Scala Job Interview Questions. The post in fact referenced a GitHub repository. Now the post came with a pointer to ready-made answers, but I decided to take the exercise and try to reply myself. The intent was both to check my knowledge and to learn something new since I’m no Scala guru.

The post contained many questions, grouped by topic. So I prefer to split my answers along several posts to keep them short and manageable.

Let’s start with general questions.

Continue reading “Scala Job Interview Answers”

Our Father’s Faults – Wrapping it up

Well, I’m running out of anti-patterns and oddly looking code from the legacy of my job-ancestors. I thinks that there are a few that are worth mentioning but don’t build up to a stand-alone post, and then its space for questions and discussions and whether exists or not a way out.

Continue reading “Our Father’s Faults – Wrapping it up”

Our Fathers’ Faults – Actors – Explicit State

This post is not really specific to Scala/Akka, since I’ve seen Finite-State Machine (AKA FSM – not this FSM) abuse in every code base regardless of the language. I’ll try to stick with the specificities of my code base, but considerations and thoughts are quite general.

FSM is an elegant and concise formal construct that helps in designing and encoding and understanding simple computational agents.

Continue reading “Our Fathers’ Faults – Actors – Explicit State”

Our Fathers’ Faults – Mixing Actors and OOP 2 – Acting is not an inherited trait

This is the second part of the post on why Actors and OOP are really a bad match. In the last post we have seen how adding types and methods to actors could turn into a bad idea, now we look at another aspect of OOP – actors and inheritance.

Once you have wrapped an actor inside an object as our fathers did, you can hardly resist the temptation of composing by inheritance. On paper this is also a good idea, think for example to some sort of service that has some housekeeping to do (registering/unregistering clients, notify clients), what’s wrong in having a base class Service from which LedService can be inherited?

Continue reading “Our Fathers’ Faults – Mixing Actors and OOP 2 – Acting is not an inherited trait”

Our Fathers’ Faults – Mixing Actors and OOP 1, Actors with methods

This was intended to be a single comprehensive post about what’s wrong in mixing the Actor model with OOP. After a while I was writing this I discovered that there is a lot of stuff to be told, so I split the post in two. This is the first and talks about why you would like to add typing to Actors and then why you would like to get back. The next one (that I would likely publish in 2020) is about why you would like to add inheritance among actors and why guess what… you would refrain to do it. Let’s start.

Once that the concept of Actor as implemented by the Akka framework is clear, we can proceed to the first issue in mixing Actors and OOP, that is brilliantly depicted by the sentence “No good deed goes unpunished”.

Continue reading “Our Fathers’ Faults – Mixing Actors and OOP 1, Actors with methods”

Our Fathers’ Faults – Akktors and Ekkstras

After the first four posts of “Our Fathers’ Faults” it’s time to turn a specific aspect of the application – the Akka framework. The code I’m managing is strongly based on this framework offering endless inspiration for misuse and abuse. Before going straight to the sins parade, I think it is proper a brief introduction to the Akka framework actors and their usage. Half of my two readers are ludicrously proficient in Akka and Scala that they might think of skipping this post wouldn’t it be for my witty ranting prose style, the rest of you two may actually be interested in the content as well.

BTW, actors, as most innovations in programming, are no longer that innovative. The actor model dates back to 1973 (geez, I was 5! I couldn’t even spell “actor”!), but it has been largely popularized by the reactive manifesto as a viable model for reliable concurrent programming.

Continue reading “Our Fathers’ Faults – Akktors and Ekkstras”

Our Fathers’ Faults – Scantly Typed Language

Scala tries to help the programmer in many ways. Verbose and repetitive code can be often syntactic-sugarized into concise statements. This is very convenient but encourages the programmer to produce write-only code. Let’s talk about types. In many contexts, you can is very good at inferring types. Consider

val n = 1

This Is the most obvious case, you don’t need to specify Int because the language manages to infer the type of the variable from the type of the expression to the right of the equal sign.

Continue reading “Our Fathers’ Faults – Scantly Typed Language”

Our Fathers’ Faults – The Chain of Death

The functional programming core concept is about composing functions together to craft more complex and convoluted functions. In Scala (not unlike what happens in many other programming languages) there are two ways to combine functions: the first is to apply a function to the result value of another function and the latter is to use a function to produce the argument value of another function.

Written in this way they may look not so different, in fact, even if in practice they show up in quite a different look, the abuse of the mechanism leads to the same problem.
The first way of combining functions, is also called chaining since you chain functions together – the result of function fn is the input of function fn+1. (Interestigly this very same mechanism will get a boost in C++ starting from C++20 ISO standard thanks to range and pipes).

Take the following example:

List(1,2,3,4).filter( _ > 2 ).map( _.toString ).fold( "" )( _ + _ )

(If you already know Scala, you may safely skip this paragraph 🙂 ) If you are unfamiliar with Scala or function programming this may look suspiciously like bad code, (this could be some meat for another post), but trust me it is not. Function List(…) constructs a List. List, containers, and iterators in general in Scala have a set of methods that can be chained together. You may think of them as taking an iterator and producing an iterator in a different sequence. Back to the example above, filter produces an iterator that scans only elements of the input sequence that fulfill the given condition (being greater than 2 in the example). map produces an iterator over a sequence whose elements are computed by the given function on the source elements. Eventually fold collapses the sequence by accumulating items iteratively using the provided expression.

Each small block performs an operation. Note that I haven’t written “simple” operation, on purpose. In fact the operator (filter, map, fold) is simple in itself, but it is programmable via a lambda that can be as convoluted as you want. Therfore the operation performed by the block may become really complex.

While you are focused on your goal, it may be easy and convenient to dump your mind into an endless chain. This has two drawbacks, first, it is unreadable and second, it is uninspectable.

It is unreadable because you need to start from the beginning and analyze the sequence up to the point to where you want to focus and know what the inputs are and from there onward to understand how the output is processed into the final result. Pair this with complex lambdas and you may find yourself in quite a nightmare to figure out what this code is supposed to do or where is the bug.

It is uninspectable because you cannot use the debugger to stop execution and show intermediate results of your operation (I’ve noticed over the years that Scala programmers are usually reluctant in using a debugger preferring print/log debug).

The other form of the problem – functions calling functions calling functions – despite the differences in syntax, is not that different in how it is produced and in the result. The code you may see, such as –

context.become(
    enqueuer(
        resourceManagement(
            Queues( queues.execution.filterNot( x =>
                ( x == realFree || context.child( childName( x.getUUID ) ).isEmpty ) ), queues.waiting ) ) ), true )

can be written in any language, but it seems that our fathers was quite fond of this approach.

It is important to recognize that when writing code you have (or, at least you should have) a crystal clear and detailed comprehension of the data flow, and even if you strive to write clear code, you’ll tend to pack these things together because a) it is faster (less typing, less naming of values, less effort to add structure) and b) you don’t feel the need to make it clearer since it is so straightforward in your head.

Lesson learned – resist the temptation of dumping the mental flow into a coded data flow, use the old “divide et impera” to split the flow into manageable units with names reflecting the content e the intent. A good indication is the line length, if your statement, properly formatted to fit in 80 columns, happens to span over more than 3 lines, then splitting it is a good idea.

Additional thought Attending some FP conferences I had the clear impression that FP pundits encourage complex aggregation of functions, even the justification for having short indent space (2 characters is the recommended indentation for Scala) has the purpouse of make the writing of chains more convenient. For these reasons I suspect that this point could be a little controversial in FP circles. I stay with my idea that industrial quality code must be first easy to read and understand and then easy to write.