Recorded at:

Functional Design Patterns

Sections

Architecture & Design,

Development

Topics

Design Pattern ,

Functional Programming ,

QCon ,

Architecture ,

Patterns ,

Object Oriented Design ,

Design ,

Language ,

Conferences ,

Programming ,

QCon London 2010

The next QCon is in London March 5-9, Join us!

Share |

1. Back to top

   Educational and entertaining

   by Faisal Waris

   Monads still elude patterns though!

   Reply

2. Back to top

   Re: Educational and entertaining

   by Nat Pryce

   "Monads" *is* a pattern.
   
   Unfortunately the functional programming community do not come up with as communicative pattern names as the object-oriented programming community!

   Reply

3. Back to top

   Re: Educational and entertaining

   by Faisal Waris

   "Monads is a pattern" may be true. The presenter's point is that describing monads in (presumably) a GoF style pattern language is untenable.
   
   Language support seems to be required to effectively work with monads - at least for statically typed languages.
   
   For example, F#, C# (LINQ) have language support for monads. I have limited familiarity with Haskell but that also provides native support for monads.
   
   I confess that even after using mondads (primarily as F# async{} monads and C# LINQ) I am still fuzzy. I have not had the 'aha' moment yet - even though I understand the mechanics of monad construction, the monadic 'laws' and such.
   
   It just seems that coding becomes magically easier with monads. When/how to create that magic myself is where I lack.

   Reply

4. Back to top

   Re: Educational and entertaining

   by Sadek Drobi

   Monads are NOT patterns. They are implementation. They are offered in api's and you can use them without caring about the way they are implemented (the plumping code).
   Patterns are about encoding featured, monads are about abstraction of plumping code.

   Reply

5. Back to top

   Re: Educational and entertaining

   by Faisal Waris

   Well, I finally got to write my first monad. Seems I am getting the hang of it now. Reading about monads only takes you so far. Its not until you do it yourself that you truly grok monads.
   
   In my case I have a monad implementation to manage COM object references. I am pulling data from Excel into F# for an optimization problem. Excel interaction is via COM. COM requires that if you acquire an object reference then you have to eventually release it. My code was getting messy managing COM object references. Now with a monad managing object references the code ends up being a lot cleaner.

   Reply

6. Back to top

   Re: Educational and entertaining

   by Nat Pryce

   You misunderstand.
   
   Individual monad types are, as you say, implementations.
   
   But the *concept* of a monad type, why you would want one, what they give you, what constraints they impose: that's a pattern.

   Reply

7. Back to top

   Re: Educational and entertaining

   by Sadek Drobi

   I strongly disagree. Patterns as in GOF Design Patterns are concepts to be reimplemented each time you need them. Monads are like say, arrays or hashmaps in Java. Already implemented and ready for use. You can implement your arrays in case you need something different but you won't everyday. You'd spend good time in FP without implementing your own monads. And you won't frequently anyway.
   Please don't call monads patterns. THEY ARE NOT

   Reply

8. Back to top

   functional patterns

   by Chris Angus

   Check out
   
   www.haskell.org/wikisnapshot/CommonHaskellIdiom...
   
   This is a list of common idioms or patterns in Haskell which includes memoization
   
   www.haskell.org/wikisnapshot/MemoisingCafs.html

   Reply

9. Back to top

   Re: functional patterns

   by Faisal Waris

   A few subtleties...
   
   a) Design patterns in the GoF sense are meant to be implemented as part of your main application code.
   
   Note the underlying assumption is that the above technique will work for most languages. The point of this presentation is that functional languages are expressive enough such that you can create pattern abstractions that can live separate from your main application code.
   
   b) Monads are implementations that your main code would just use and such are not design patterns in the GoF sense
   
   c) Putting together a monad implementation requires some method (and madness) and as such can be considered a pattern... but at a different level than GoF patterns.

   Reply

10. Back to top

    Re: functional patterns

    by Jaime Metcher

    I'm sorry, but a pattern is a pattern. I don't care if it's in application code, library code, the language interpreter/compiler, or implemented in silicon, it's still a pattern. You might care more about some patterns than others, depending on where in the stack you work, but that's no reason to pretend the rest of the stack doesn't exist. This speaker has published a nice paper about how your set of useful patterns will vary depending on your context, which I'd recommend searching out. I think the presenter's point was to extend those ideas to the FP context and to assert the general validity of the patterns approach.
    
    Nowhere did I hear her say anything about monads being patterns or otherwise - I've no idea why you guys latched on to that.

    Reply

11. Back to top

    Patterns

    by Channing Walton

    Sounds like we need a definition of pattern before we argue about whether monads are patterns or not. Personally, I have difficulty describing monads, a mathematical concept, as a pattern, whatever that is ;)

    Reply

• Older >