C++ is ugly, so is Haskell

Author’s state of mind — 1: I have been rereading Zen and the art of motorcycle maintenance (ZAMM), for the third time. Every time I read it, I fall in love with it some more.

Author’s state of mind — 2: I have also been learning Haskell and category theory andsk it has been a lovely lovely experience. I consider myself a Math enthusiast and understanding Monads, Applicatives and Functors is a delightful puzzle - one which I think, I understand reasonably.

When we look at something from a romantic perspective, we are trying to answer the question “What it is?”. It insists on naming stuff. It insists on naming its parts. This is a motorcycle, this is a screw, that is an engine, that is a MessageCommunicator. OOP is an example of this. When we say that Book is made up of Pages, we are using the romantic perspective. This outlook sucks when we have to talk about something whose sole purpose in life is to perform a function. Face it, naming a class MessageCommunicatorFactory sucks.

When we look at something from a classical perspective, we try to answer the question “What does it do?”. It lists everything as its function, it shifts our focus towards the relationship. What is used to communicate the message is not important, we just want to communicate <message>. As we can see, functional programming follows this approach and it is cleaner than MessageCommunicator. But unfortunately, how do we talk about book. Is everything which can be read a book? What if I want to scan a page? There is no concept of Book in the classical perspective, it is a romantic concept.

When the romantic approach goes haywire, it looks ugly. For a haskell programmer, C++ is ugly, very. After a few days with haskell, I found C++ code unreadable and too verbose. Its ugliness is like that of looking too closely at a painting, seeing every square micro meter of it. I won’t give you an example for this, because if you have made it till here, you are probably interested in functional programming and know of all the cases which they show-case as far more elegant.

When the classical approach goes haywire, it looks, umm, well, ugly. But its ugliness is of a different nature. It looks like a foggy glass. It shouts in your face that you are using the wrong tool. For example, trying to code up a file format in haskell or message structure in haskell. It is brilliant when it says communicate, but sucks big time when it comes at defining the structure message. In haskell, we cannot say that a Person has a name and a PetAnimal has a name, instead we have to write -

data Person = Person { personname :: String -- and some other details
                     } 

data PetAnimal = PetAnimal { petanimalname :: String  
                           } 

class HasName a where
  name :: a -> String

instance HasName PetAnimal where
   name = petanimalname

instance HasName Person where
   name = personname

Holy fuck! Who the hell does this? For a language which boasts of its type system, this is just plain lame. A person has a name, having a name is not a relationship. For me, this code is uglier than template meta programming in cplusplus, which happens beautifully in haskell.

So, if C++ is ugly and haskell is ugly, which should I use for my project which is going to last an year? Which is the correct point of view — classical or romantic?
People who support haskell cite its beauty in programs which suit the requirement and deliberately skip over the problems over which haskell is simply laborious. People who cite impracticality of haskell, write programs which only god and the machine can understand.

I think, the problem is not in the classical thought or the romantic thought, the problem is in the dichotomization to classical and/or romantic. We, as humans are capable of both, classical and romantic perspectives simultaneously. We are not bound to one or the other. But the programming languages which we use bind us to one, arguing that the other is ugly.

The zen of motorcycle maintenance is attained when one realizes that when you can unite your classical and romantic view points, you are at peace with yourself and with the machine. Similarly, the complete programming language will be one which does not force one to choose between OOP and functional, instead one in which we fine tune our vision so that we can enjoy the beautiful painting from the right distance.