Tag: Scala

Scala Job Interview – FP questions

Welcome to the third installment of the Scala Job Interview Questions series. This time I’ll try to answer functional programming questions, likely my score will be a bit less than the first two editions (General Questions and Language Questions) because I like Functional Programming, but I’m still a traditional programmer (imperial?) who studied Algebra at high school and uni and then consider Algebra as useful (for programmers) as a doorstop in a tent.

Young and foolish I was, but who could imagine, back then that to run the dance of the bits I would ever need monoids?

Let’s not waste other time in void introduction, and start with the questions and my answers.

Continue reading “Scala Job Interview – FP questions”

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”

Comprehensive For in C++

Switching back and forth between Scala and C++ tends to shuffle ideas in my brain. Some ideas from Scala and the functional world are so good that is just a pity that can’t be applied directly and simply in C++.

If you carefully look into idiomatic C code for error handling, it is easy to find a lousy approach even in industrial code. I’ve seen a lot of code where not every return value was examined for an error, or not everything was thoroughly validated, or some code was executed even when it was not needed because an error occurred but was too cumbersome to provide the escape path.

In C++ things are a bit better, thanks to the exception mechanism, but exceptions are such a pain in the neck to get right and to handle properly that error management could soon turn into a nightmare.

Error handling in C and C++ is so boring and problematic that the examples in most textbooks just skip it.

(featured image by Nadine Shaabana)

Continue reading “Comprehensive For in C++”

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”