where we went in 2005

algorithms, really?

I've been noticing lately that there's a lot of, hmm, software engineers, to put it softly (meaning, not exactly programmers) that are kind of proud to be proficient in "algorithms". They know how to sort in n*ln(n), how to implement a queue using two stacks, what is skiplist, what is Patricia trie (not sure here), and how to find a median on a distributed system (I never knew the answer; my guess is it takes ln(n) iterations).

What I notice regularly, though, is that the same smart algorithm people routinely use arrays to keep a list of processed items, and check whether an item was processed already by scanning the array; they use Map to store a set of things to do (map.put(myThing, myThing)); and they create a complicated tangled network of listeners/events queues/managers/factories/delegates where a simple solution (a five-liner) would suffice.

So, in short, no understanding of base data structures, and no artistic feeling of simple beauty.

For a change, let me show you something from Scala.

Option[T] is a class that kind of "replaces null": it either contains a value, or is equal to None. (I won't go deep into toposophical representation of this, but there is one).

Now imagine we have a method that returns an Option[A], then we have to process that A, if there is one, and produce a B; what we need is to have Option[A] -> Option[B].

Would you use if, switch, or something like that, what we use to use in Java? Ha, here's Scala solution:


val opt_a: Option[A] = ....
val result = opt_a map(a => dosomething(a))


See? The dosomething processes the value; the method map wraps it, producing an Option[B] (no, you don't need to declare the type of result, since it is obvious.