Wednesday, January 26, 2011

Type idiosyncrasies

My friend Doug says:
"...it would never occur to me to spend so much time thinking about a syntactical 'type' idiosyncrasy..."
Ah, life would be simpler if I did not need to worry about these kinds issues! Yet having probably written more than a million lines of code in the past (I started young!), I come to the conclusion that the higher the abstraction, the better is my productivity. Given the limited amount of time I have when working at home, I need to be as productive as possible.

Still, functional programming (FP) is a deadly sport. With procedural or object orientation, it is rare that refactoring completely changes the logic of your design. Such changes are not rare with FP. Here are a few examples:
  • Data can be passed around as arguments or carried by arguments or can be stored in monadic states
  • Specific operations can be made explicit to a monad. That is, made explicit to the higher level design of your code.
  • You can swap between a type centric recursion and a functional recursion. That is types can be defined recursive or be defined "open" with dangling parameterized type leafs which get resolved by the type inference through the recursion of functions.
  • ...
This type of design "swiveling" is not easy and puts your confidence as an architect to test, especially under time pressure.

No comments: