Category: computing

Implicity
If there is something I really hate is when people try to hide things from me. Maybe that’s why I find Scala’s implicit stuff so annoying. They try to make things easier by, for example, allowing you to declare implicit type converters. So imagine that you have some class ChocolateCake and then you declare an implicit converter to class Cake. This means that a casting from ChocolateCake to Cake will be made implicitly when necessary. But what happens is that sometimes the compiler is able to infer this conversion, and sometimes not! And when it is not capable, it will throw a typing error on the compilation. And then you realize that you wanted to use Cake the whole time… But you notice that the objects have ChocolateCake type in lots of places. Then you stop and think: what the fuck? And you start searching the code around and find this mini-method ChocolateCakeToCake. And you search the project for places where this method is used, but you find none! So nothing more natural than commenting these three lines of code that are not called anywhere, but then what happens? Your code stops compiling!! Giving errors in places you have never touched… What the fuck, again?? You look one more time and notice the “implicit” word in front of this method. Then you google it around and finds the explanation in Scala’s documentation.
After reading it you understand, but c’mon!!! Was this really necessary? In my opinion, that is not really improving readability of the code or anything… People need to realize that hiding some implementation sometimes makes sense, but then searching for errors on something hidden is *extra* difficult. You either hide stuff that really do not matter and should not be the programmer’s concern, or just make it explicit!
PS: Also holds for the implicit factories… nothing intuitive about that! I prefer all the code duplication, really.

Map[Map[A]]
You want to declare a smart matrix of some type A, what do you do? Map[Map[A]], of course, such as in old C++. Then you want to assign some value to a position: Map(i)(j) = x, right? Wrong! Scala will give an error that Map(i) does not exist… Of course not, I am declaring its existence with this assignment. Of all the robust implementation of the various (really, millions!) of datatypes in Scala, they could not make this simple and intuitive thing work? Such a shame… In C++ it works like a charm!

Data Types
Scala users are very proud about the amount of libraries and datatypes that are already built-in the language. It puzzles me why… I don’t think that having 4 ways to represent a list is particularly good. On top of that, each of these 4 ways have tiny little annoying differences, such as different operators for concatenation. Also, some have assignment and others don’t. And because of these small differences, changing your code from using List to using Seq can be quite a headache.

Mutable and Immutable
Why having sooooo many different datatypes?? Just pick mutable or immutable objects and stick with them! This makes C pointers look like a piece of cake. And because of all the types, we never know which library scala is automatically importing for you…
This is actually a real error: type mismatch.
Found: scala. collection.Map[bla bla bla]Required: scala.collection.mutable.Map[same bla bla bla]And guess what? Importing scala.collection.mutable.Map does not help…. So what is going on? I was using a map method that returned a collection.Map (although it is applied to a collection.mutable.Map). And the weird thing is, the method is available in both types (mutable or not), but it only returns the non-mutable Map. For me this really does not make sense.

Well… there’s a lot more. Maybe if you use this language carefully, some good might come out of it. I just haven’t found it yet. We all know that programming languages, such as operating systems, are like soccer and religion: do not start a discussion on that! But I really needed to get this out of my chest, and it’s good for other anti-scala people to realize they are not alone in the world.

So in programming we often use some functions, right? These functions have arguments (which can be themselves functions). Call-by-value and call-by-name are two different strategies to deal with these arguments (and please do not confuse this with passing parameters as values and as references… these are actually two ways of passing parameters in the call-by-value paradigm, if I understand correctly). Here’s a brief explanation of both:

Call-by-value
The arguments of a function are evaluated and then their results are passed to the function.

Call-by-name
The arguments of a function are substituted directly on the function’s body and evaluated only when necessary.

Take, for example, the following function:

let f x = x +x

and apply it to (print “hi!!”; 4).
If  f (print “hi!!”; 4) is evaluated using a call-by-value strategy, the argument will be evaluated once, hi!! will be printed and the return value will be 8.
If  f (print “hi!!”; 4) is evaluated using a call-by-name strategy, the argument will be copied to the body of the function, which will become: (print “hi!!”; 4) + (print “hi!!”; 4). Then, each part of the sum will be evaluated, hi!! will be printed twice and the return value will be 8.

Now, as far as I know, most of the languages use the call-by-value strategy. Maybe because of efficiency, since the repeated use of an argument would cause it to be evaluated several times in the call-by-name strategy. But sometimes it is the case that we actually want a call-by-name strategy to be used. This happened to me when I was implementing a continuation passing style. Basically my function had two arguments, which were functions themselves, called success and fail. Some computation was done and depending on the result the function would be continued by success or fail. Now, I did not want these functions to be executed right away, of course, but only when I had already computed something and decided which was the case. This was implemented in OCaml, which uses the call-by-value strategy. So, in order to simulate a call-by-name, I had to use something called thunking.

Thunk
Thunks are types such as ()-> A which are used to delay evaluation, i.e., if a parameter of a function is of thunk type, it is not evaluated until needed, in a call-by-name style. Thunks simulate CBN in a CBV language.

This is easier to see with an example:

(* Quick OCaml example of call-by-value, call-by-name and thunking *)


let arg () = 
  print_endline “Function evaluated.”
;;


let cbv f =
  print_endline “=> Not using the argument, evaluated anyway.”
;;


let cbn f = 
  print_endline “=> Not using the argument, not evaluated.”
;;


let _ = 
  print_endline “Call-by-value:”;
  cbv (arg ());
  print_endline “Call-by-name:”;
  cbn (fun () -> arg ())
;;

You can try this by saving a file and executing it with ocaml. Cool, isn’t it?