On Sat, 14 Mar 2009, Gary Johnson wrote:
> Just ran across another great essay by Rich Hickey (the designer and
> benevolent dictator of the Clojure language), in which he reminds
> creators of contrib libraries of the wastefulness of adding classes
> and types to a language with pervasive map abstractions. Check it
> out. This isn't a Lisp or Clojure specific problem. The central
> principle at work here is Alan Perlis' off-cited quote:
> "It is better to have 100 functions operate on one data structure
> than 10 functions on 10 data structures."
> So dig it, and hack on.
There is a counter argument to this. The idea behind strongly typed
languages is to allow the programmer to use types to track logically
distinct concepts. The programmer specifically does *not* want those
concepts mixed arbitrarly. Mixing everything with everything else just
creates a big mess.
For example (using Ada)
-- Introduce two distinct types.
type Apple_Count is new Integer;
type Orange_Count is new Integer;
-- Create appropriate variables.
Apple_Basket_Size : Apple_Count;
Orange_Basket_Size : Orange_Count;
-- We are confused.
Apple_Basket_Size := Orange_Basket_Size;
The last line is a compile time error. Does it really make sense to store
a count of oranges in a variable intended to hold a count of apples? It
probably doesn't. If it does, an explicit type conversion can be applied:
-- After code review, this assignment deemed safe...
Apple_Basket_Size := Apple_Count(Orange_Basket_Size);
In languages that allow anything to be done to anything, logic errors like
the one above are detected (if they are caught at all) only during
testing. There is a time and place for such languages, but they definitely
have their disadvantages.
So to bring this back to the original posting... treating all classes
uniformally as maps has a certain elegance, but I wonder how many nasty
bugs it hides.