∴ikura

CRON Gone Wild … with ikura.

sep 11

Logic makes me hungry

There is no doubt that hacking makes me famished. With every decision made, I can feel a certain whittling away in my brain; and it’s not impossible to have zero will-power by noon.

A nicety of Erlang is one can do away with the classical true/false logic in your program flow. This usually takes the form of if statements in other languages. When I have zero will-power, I have noticed it’s this brand of logic that piles up quickly and wears me out.

So, how do we control the flow of a program then? In Erlang we tend to eschew decisions and hand them off to other functions that will deal with the particulars. This is where pattern matching comes in. Humans are amazing at pattern matching. We are pretty good at logic, too, but if you have ever noticed a subway-car full of ‘Candy-Crush’ playing commuters, you will tend to agree with me.

Let’s consider an example written in Ruby first:

def self.split_decision(where_to)
  state = 99
  case where_to
  when "farm"
    return nil
  when "ohio"
    res = do_something_else(state)
    return res
  end
end

’Nothing wrong with the above. One does have to keep the whole flow of that routine in mind when considering it, though.

In Erlang, we could write it as follows:

split_decision(Where) ->
    State = 99,
    split_decision1(Where, State).

split_decision1("farm", _) -> void;
split_decision1("ohio", X) -> 
    do_something_else(X).

Now, at first glance they are quite similar. But the waterfall approach in Erlang makes me have to think less when I actually code the problem and read it later. With Ruby, the routine contains all the business logic. The Ruby version could be equated to a run-on sentence, while the Erlang version, a Haiku.

In Erlang, decisions usually come down to ‘what do I name this function.’ That can be hard, too, but for some reason, I need fewer carbohydrates to get me through the day when doing it the Erlang way.

THIS END UPWhat’s ikura?