[Haskell-cafe] Re: State of OOP in Haskell

Al Falloon afalloon at synopsys.com
Wed Jan 31 07:49:54 EST 2007


Bulat Ziganshin wrote:
> Hello Al,
> 
> Tuesday, January 30, 2007, 6:01:16 PM, you wrote:
> 
>> Design of functional programs is very bottom-up. The general plan is to
>> identify the primitives for your domain and embed them in the language,
> 
> oh, really? may be i'm using Haskell in OOP way? :)
> 
> i strongly prefer to use top-down style for application programming -
> i.e. i solve problem introducing auxiliary functions, then fill up
> these functions and so on recursively
> 
> i use bottom-up style for library development, though, adding more and
> more higher-level functionality as library evolves

The method I use is actually more of a "meet-in-the-middle". Its hard to 
know what your primitives are unless you know what you are trying to do.

I find that the best approach is to try and write my program using 
whatever constructs feel natural for the domain, then see if I can 
define the domain constructs starting with the smallest, most obvious 
ones and combining them into the more complex nuanced constructs needed 
to solve my actual problem.

Usually some tweaking is required to get a nice fit. Writing usable 
software is more craft than science.

The OOP community has contributed a lot to the craft of programming. 
There are many concepts that have been refined by them that IMHO can be 
applied more easily in a functional style. IMO the major driving 
principle of good software design (OO, FP, or otherwise) is 
Once-And-Only-Once 
(http://c2.com/ppr/wiki/WikiPagesAboutRefactoring/OnceAndOnlyOnce.html).
If you stick to OAOO, then no matter where you start you tend to 
converge toward a good solution(*).


(*) However, depending on where you start OAOO does not always give the 
same good solution. I find that interesting. To me that implies that the 
solutions from different approaches form a Pereto optimal set 
(http://en.wikipedia.org/wiki/Pareto_efficiency) of the possible 
solutions, and that each approach buys you some sort of advantage at the 
expense of another.

--
Alan Falloon



More information about the Haskell-Cafe mailing list