haskell

Haskell

Haskell is a great inspiration to all great programmers

Writing a simple declarative sort algorith in Haskell feels like an eye opener comming from imperative languages. Suddenly all those for(int i=0;i<count;i++) loops seem extremely ad-hoc, inelegant and over-specific.

Fortunately for the world, many concepts of Haskell have become mainstream in other languages, especially lambdas ( closures / blocks) and optional values; Closing the gap between mathematical perfection and everyday pragmatism.

On the other hand Haskell increasingly fixes those shortcomings or oddities, which unneccissarily complicated tasks. E.g. since only very recently you can access fields via dot syntax: RecordDotSyntax

Fundamental issues

Limited polymorphism

There are some kinds of polymorphism that Haskell doesn't support, or at least not natively, e.g. inclusion polymorphism and subtyping, common in OO languages, where values of one type can act as values of another type.

The following example, while beautiful, only works for pairs of numbers:

newtype Pair a b = Pair (a,b)  deriving (Eq,Show) 
instance (Num a, Num b) => Num (Pair a b) where
   Pair (a,b) + Pair (c,d) = Pair (a+c,b+d)
   Pair (a,b) * Pair (c,d) = Pair (a*c,b*d)
   Pair (a,b) - Pair (c,d) = Pair (a-c,b-d)
   abs    (Pair (a,b)) = Pair (abs a,    abs b) 
   signum (Pair (a,b)) = Pair (signum a, signum b) 
   fromInteger i = Pair (fromInteger i, fromInteger i)

Limited overloading

As a consequence of limited polymorphism, you can only overload operators in very specific contexts.

Imperative thoughts

While mathematical functional code can be very concise and elegant at times, often an imperative list of steps and tasks feels more natural or beautiful to our brain. The standard mathematical notation runs contra the intuitive time axis:

serve(cook(wash(buy(food)))) is absurd versus the natural order