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