BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Functional Design Patterns

Functional Design Patterns

Bookmarks
51:05

Summary

Aino Vonge Corry reviews a number of well known design patterns showing that their implementation is simpler in functional languages because such languages have pattern-based constructs.

Bio

Aino Corry is technical conference editor and retrospectives facilitator at Trifork. She holds a masters degree and a PhD in Computer Science from the University of Aarhus, Denmark. She has 12 years of experience with patterns in software development as a developer, architect and mentor. Corry was the architecture and coordinator for the EU project PalCom, responsible for the common architecture.

About the conference

QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community.QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.

Recorded at:

Oct 27, 2010

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Educational and entertaining

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Monads still elude patterns though!

  • Re: Educational and entertaining

    by Nat Pryce,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "Monads" *is* a pattern.

    Unfortunately the functional programming community do not come up with as communicative pattern names as the object-oriented programming community!

  • Re: Educational and entertaining

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "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.

  • Re: Educational and entertaining

    by Sadek Drobi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Educational and entertaining

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Educational and entertaining

    by Nat Pryce,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: Educational and entertaining

    by Sadek Drobi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • functional patterns

    by Chris Angus,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

  • Re: functional patterns

    by Faisal Waris,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: functional patterns

    by Jaime Metcher,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Patterns

    by Channing Walton,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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 ;)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT