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