Re: Functional design patterns (was: How to get functional software engineering experience?)
On Wed, May 15, 2002 at 08:13:22PM +0200, [EMAIL PROTECTED] wrote: Yet another problem is that design patterns are all about design and less about coding. Many challenges in functional programming are about coding, and just about coding. This is something I've chatted about with a colleague of mine. When one deals with objects and mutable state, one can build models of a system at various levels of abstraction, and meaningfylly relate the models to each other with data refinement. What would be the corresponding notions in functional programming? It is certainly true that functional programs are often much more abstract than their imperative counterparts, but even in my relatively small compiler project I have already felt a need for a compact design notation. Another issue is that when one uses a functional language to design something that is inherently stateful, one would really want to see the state explicitly at some level of abstraction. Would people recommend something like UML for doing this? -- pertti ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Functional design patterns (was: How to get functional software engineering experience?)
[EMAIL PROTECTED] wrote: Joost Visser and I, we worked out a few maybe not so obvious functional programming patterns such as Success By Failure, Role Play, Rewrite Step, Keyhole Operation just to mention a few. By not so obvious I mean that they deal with generic programming rather than functional programming in general. http://www.cs.vu.nl/Strafunski/dp-sf/ We use a certain FORMAT for design patterns, and there is some modest analysis why this format is appropriate. Also, there is some discussion why design patterns would do good for functional programming. This might be interesting in the further process of accumulating design patterns for functional programming. I have added the design pattern description format to the Haskell wiki: http://haskell.org/wiki/wiki?DesignPatternsForFunctionalStrategicProgramming Perhaps it would be interesting to see if some of the CommonHaskellIdioms described on this wiki can be cast into the proposed design pattern format as well. Joost -- http://www.cwi.nl/~jvisser/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Functional design patterns (was: How to get functional software engineering experience?)
Andrew J Bromage wrote: On the other hand, it's an exciting time to do engineering in declarative languages, because we can invent the design patterns and discover what the good habits are as we go along. BTW, FP is older than OOP. So why are we so late :-) ? Joost Visser and I, we worked out a few maybe not so obvious functional programming patterns such as Success By Failure, Role Play, Rewrite Step, Keyhole Operation just to mention a few. By not so obvious I mean that they deal with generic programming rather than functional programming in general. http://www.cs.vu.nl/Strafunski/dp-sf/ We use a certain FORMAT for design patterns, and there is some modest analysis why this format is appropriate. Also, there is some discussion why design patterns would do good for functional programming. This might be interesting in the further process of accumulating design patterns for functional programming. I am in complete agreement with Jeffrey Palmer who wrote: From the research I've done to date, functional programming provides enough of a paradigm shift that there are significant new patterns/idioms I have the feeling that the FP community has a hard time getting started with design patterns. Part of the problem is that design patterns are inherently vague and this is maybe something the authors in our field do not like to consider. That is, if something is being written that is meant to document design experience for functional programming, it ends up being complex (say, Stop programming this or that; you will definitely fall in love with Haskell if you can parse this article.). Another more technical part of the problem is that it is not obvious what format would be appropriate, especially because the driving ingredient of an OO design pattern is the class hierarchy or an object structure, and this does not make sense in a functional setting. Yet another problem is that design patterns are all about design and less about coding. Many challenges in functional programming are about coding, and just about coding. We might need a different understanding of what design patterns are because we would like to cover the rich set of programming idioms in functional programming. I feel tempted to say there aren't that many in OOP. I guess there are more reasons why there is no GoF book out yet for FP. But at least Jeffrey, Joost, and I, we are working on that :-) Jeffrey Palmer wrote, too: To avoid any pattern debates: I personally believe that patterns are especially useful for getting novices up to speed on concepts that might not be readily apparent at first glance. Rather than treating patterns as anything special in their own right, for me they're simply a really convenient way of teaching people new and interesting concepts. Why do you say this if you want to AVOID a debate ;-) ? Design patterns are maybe convenient for teaching ... But they are ESSENTIAL to gather design experience, and to regulate the terminology in a field. They are also CRUCIAL for the interaction of design and programming in the implementation phase, AND for the idea of refactoring. Also, the idea of a design pattern catalogue is just a kind of SELF-CHECKING notion to address all concerns a programmer could possibly have. By self-checking I mean that the firm adherence to a well-designed format for a catalogue is the key. Ralf -- Dr.-Ing. Ralf Laemmel CWI VU, Amsterdam, The Netherlands http://www.cwi.nl/~ralf/ http://www.cs.vu.nl/~ralf/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Functional design patterns (was: How to get functional software engineering experience?)
Ralf Laemmel wrote: Joost Visser and I, we worked out a few maybe not so obvious functional programming pattern [...] http://www.cs.vu.nl/Strafunski/dp-sf/ Neat! I have the feeling that the FP community has a hard time getting started with design patterns. I believe quite the opposite: there are plenty of FP design patterns in common use, it's just that FP'ers don't usually use the term design patterns to describe them. I'm thinking of things like catamorphisms, anamorphisms (aka folds/unfolds), monads and functors, the zipper, and of course the various catalogues of polytypic routines. Part of the problem is that design patterns are inherently vague and this is maybe something the authors in our field do not like to consider. That's the main difference between FP patterns and OO patterns. OO patterns tend to be informal, intuitive guidelines; and though some FP patterns are like this (e.g., combinator library, embedded domain-specific language), the majority can be described rigorously. This gives them an added usefulness -- you can actually calculate with them. --Joe English [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Functional design patterns (was: How to get functional software engineering experience?)
--- Joe English [EMAIL PROTECTED] wrote ... there are plenty of FP design patterns in common use, it's just that FP'ers don't usually use the term design patterns to describe them. I'm thinking of things like catamorphisms, anamorphisms (aka folds/unfolds), monads and functors, the zipper, and of course the various catalogues of polytypic routines. Almost agreed. But, I adhere to an extreme and pragmatic point of view here: A design pattern is only real if it is part of design pattern catalogue which in turn is formatted in a structured manner. IMO, it is misleading to confuse APIs, libraries, frameworks, catalogues of whatever routines with design patterns. I completely agree that all of the cited notions are worth design patterns. But I don't like to confuse notions such as this or that morphism, strictness annotation, monad transformation, modular programming, reactive programming or polytypic programming with the related design patterns I would like to see. To give a simple example, think of parser combinators. Does the mere combinator library of parsing combinators tell me how to write parsers? Not really! What are the patterns here? Here are few clumsy names: - Deal with a priority - Handle left recursion - Enforce non-nested notation - Separate out reusable syntax schemes - Use this or that naming convention - Integrate lexer - Integrate pre-processor - Define abstract syntax - Handle semantics-directed constructs - ... That's the main difference between FP patterns and OO patterns. OO patterns tend to be informal, intuitive guidelines; and though some FP patterns are like this (e.g., combinator library, embedded domain-specific language), the majority can be described rigorously. This gives them an added usefulness -- you can actually calculate with them. Yes, that's nice, and we should be able to use that to the advantage of FP but this does not imply that all the other ingredients of a design pattern (tradeoffs, alternatives, ...), and the general format are not needed to claim a design pattern. Ralf = Dr. Ralf Laemmel CWI VU Amsterdam http://www.cwi.nl/~ralf [EMAIL PROTECTED] __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Functional design patterns (was: How to get functional software engineering experience?)
G'day all. On Wed, May 15, 2002 at 08:13:22PM +0200, [EMAIL PROTECTED] wrote: BTW, FP is older than OOP. So why are we so late :-) ? I know you meant it as an offhand remark, but I think there are two serious reasons why. The first one is that OOP and GUIs happened at around the same time and were found to be an excellent fit. To a great extent, one fed the other. So OOP really found its niche early. The second is that FP is like RISC in that it requires _other_ technology improvements to realise its benefits. RISC CPUs need better caches and better compilers than CISC CPUs in order to compete. Similarly, FP needed better compilers, better garbage collections, better type systems and better abstractions. http://www.cs.vu.nl/Strafunski/dp-sf/ Great stuff! Can't wait to read it. I have the feeling that the FP community has a hard time getting started with design patterns. That's something I've noticed too. Design patterns are maybe convenient for teaching ... But they are ESSENTIAL to gather design experience, and to regulate the terminology in a field. Absolutely. Design patterns are really just a way to try to understand engineering experience in a systematic way. To overuse the natural language analogy: If idioms are the pragmatics of a language, design patterns are the literary forms. Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
