Blog Post

Tao Liu: F# Design Patterns

Sign in to queue

Description

Tao Liu, an engineer on the F# team, explains (and demonstrates) the importance and value of design patterns for F#. Many programmers who work on large or complex software systems are accustomed to employing design patterns in the development of these systems.  For experienced C# developers wanting to add F# to their toolchain for large scale software development, design patterns play a very important role. Historically, there have been little to no formal design patterns for F#. This is no longer the case. Tune in.

Further reading and sample code employing design patterns in F# 3.0:

http://fsharp3sample.codeplex.com/

Embed

Download

Download this episode

The Discussion

  • User profile image
    nim

    Nice!

  • User profile image
    Jane

    It's looks good!

  • User profile image
    anita89

    Great presentation! Have been waiting for this long time. 

  • User profile image
    Joh_box

    nice GI function on design pattern. Smiley

  • User profile image
    Bubble_Jane

    Woo!

  • User profile image
    Heather

    Wonderful topic. Now more convinced F# is ready for a main stream language. Love the cat/dog sample. Powerful language.

  • User profile image
    8west

    this talk makes me think F# is something for real world app. Nice talk.

  • User profile image
    paulKJ

    @Heather: +1

  • User profile image
    parm

    @nim:nice nice

  • User profile image
    parm
     finally have a nice F# design pattern talk
  • User profile image
    victor

    new F# design pattern, example helps understand a lot.
    thanks @@

  • User profile image
    footelevator

    nice talk about F# and design patterns.

  • User profile image
    harry

    terrific F# topic enabling the language much appealing. wonderful pattern for the functional language!

  • User profile image
    philjay

    I just fell in love with generic explicit member constraints.

  • User profile image
    DazedAnd​Confused

    Nice little video, and it grabbed me, but can't make up my mind if i like the idea. Tao mentiones that some people don't think functional programming needs design patterns, but he thinks they are useful - so i'm sure he has a deeper understanding than just what he discussed. The points i'd raise are:
    - The patterns raised are Patterns of Reusable **Object Oriented** Software. So they show how to use the OO side of F# - using it's language features - not really F#'s functional features.
    - These mostly pertain to statically typed OO. e.g Ruby and other dynamically typed languages don't need an explicit visitor pattern - or many other patterns. So if this set don't really belong in dynamically typed languages - do they belong in a multi-paradigm functional language ?
    - C++ - multiparadigm - and look at how long it has taken for people to catch on to the functional derived STL. Not until Boost and Lambdas did most c++ programmmers venture into algorithms - i.e functional - territory.
    - Most programmers i know barely write OO code - it's procedural with classes. But then it's hard to write OO code when your talking for example to a WCF services that are in pretty much procedural.
    - I really thought Axum or spec# might shake this up a bit - really make people think about using the right language for the task at hand - but I guess they are too different for now.

    As a programmer in a time of lots of change (fun) i would love to see some clarification of how to use all these varied techniques and languages well - I'm just wary of multiparadigm confuzzling !

  • User profile image
    DazedAnd​Confused

    It was remiss of me to rant about these patterns without at least providing some backup to my point of view

    http://www.haskell.org/haskellwiki/The_Monad.Reader/Issue3/Functional_Programming_vs_Object_Oriented_Programming - and specifically look at
    5 OO and FP Styles Contrasted

    This link is haskell oriented, but really i think it highlights OO and functional styles being almost opposed. Big brains like Dr Lammel could probably discuss this, and i think it ties in with the expression problem. Charles - after the fantastic expression/type class series - any chance of interviewing Dr Ralf again about OOHaskell and combined OO / Functional F# languages ?

    Simple question - guess i'm a bit of an idiom..... err i mean idiot
    "Help me Obi Wan Kenobi ! If i were to write a enterprise app in F# when should i even use an object (record type with members/mutable data) ?" In ViewModels (e.g for binding too), for interop with c#,

  • User profile image
    Christ

    Great, examples make things easily to understand. Thanks

  • User profile image
    Wei

    Wonderful! Microsoft is working hard to make designers' life easier. Now, "F" does not only mean facebook. Good job Tao and F# team.

  • User profile image
    paulqing

    A very timely presentation. Now I believe more F# is suitable as a language for commercial applications.

  • User profile image
    Bella

    Very nice!

  • User profile image
    Andrew

    very nice demo for F# design patterns.

  • User profile image
    Jie

    Nice job!

  • User profile image
    harveyhuo

    Wonderful! Now, "F" does not only mean facebook. Good job Tao and F# team.

  • User profile image
    Adam​Speight2008

    Do the generic explicit member constraints, permit a form of generic operators? If we know the actual method used by the operator to perform the operation.

  • User profile image
    Jack Lu

    Vice nice presentation. Excellent topoc!

  • User profile image
    coco

    Wonderful!

  • User profile image
    may

    Very nice!

  • User profile image
    Sandy

    Great presentation and demo!

  • User profile image
    ETBoy

    Big Smile

  • User profile image
    Annlee

    Very nice presentation. I am more convinced to use F# for commercial applications.

  • User profile image
    fwaris

    Recently did a poc with F# and Solver Foundation for an optimization model for part purchasing.

    The model's input data comes in multiple Excel files.

    F# came in really handy for the complex data manipulation that was required to take the source data and feed it to the solver foundation model.

    Data manipulation is one of the areas where functional languages do exceptionally well. Such processing would have been untenable with Java (and even C# despite LINQ).

    Suffice is to say that the PoC is very well received and has already saved the company mega bucks.

  • User profile image
    WinInsider

    Following and using F# allows to stay on forefront of new language developments... async workflows, generic invoke, TypeProviders... domain exploration, and so much more... keep up the amazing features coming...  I have used F# for prototyping financial calculations for a bank; really extremely pleasant development experience.

  • User profile image
    Rachel

    Wonderful topic and nice demo for F# design patterns.

  • User profile image
    LUKE5201

    Recommended by one of my team members, great demo on F# and agree with the above comments about commercial use F#, it is time to use F# to our product.

    Devil

  • User profile image
    Victor_123

    Big Smile Great demo !

  • User profile image
    Lisa

    Wonderful!

  • User profile image
    TechNeting

    Great, examples make things easily to understand.

  • User profile image
    Thorium

    Hello,

    First of all, thanks, F#-team is making a great job. And these kind of videos are good to get a great language some attention.

    But I have some small critics to these samples... Samples teach programmers so they shouldn't teach bad things. They should teach best practices, not tricks or hacks.

    Tricks are good to know also... But maybe these samples could be divided to two sections: 1. howto, 2. tricks.

    1. Why to teach programmers to use mutable state so much? There is a very good reason why mutable state is not default in F#.

    2. Why using inline keyword in samples? Inline is usually just for interactive. Msdn says this: "you should avoid using inline functions for optimization unless you have tried all other optimization techniques". So why do we need this in basic samples? http://msdn.microsoft.com/en-us/library/dd548047.aspx

    I'm F#-programmer, and one of those who thinks that Design Patterns are common "best practice" ways to manage object-oriented problems that doesn't exist in functional language.

     

  • User profile image
    MattC2

    Wonderful presentation, need more deep materials like this.

  • User profile image
    dwu777

    Very nice.

Comments closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to send us feedback you can Contact Us.