Tao Liu: F# Design Patterns

The Discussion

• 

  Nice!

• 

  It's looks good!

• 

  Great presentation! Have been waiting for this long time. 

• 

  nice GI function on design pattern.

• 

  Woo!

• 

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

• 

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

• 

  @Heather: +1

• 

  @nim:nice nice

• 

   finally have a nice F# design pattern talk

• 

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

• 

  nice talk about F# and design patterns.

• 

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

• 

  I just fell in love with generic explicit member constraints.

• 

  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 !

• 

  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#,
  
  

• 

  Great, examples make things easily to understand. Thanks

• 

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

• 

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

• 

  Very nice!

• 

  very nice demo for F# design patterns.

• 

  Nice job!

• 

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

• 

  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.

• 

  Vice nice presentation. Excellent topoc!

• 

  Wonderful!

• 

  Very nice!
  

• 

  Great presentation and demo!

• 

  

• 

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

• 

  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.

• 

  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.

• 

  Wonderful topic and nice demo for F# design patterns.
  

• 

  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.

  

• 

  Great demo !

• 

  Wonderful!

• 

  Great, examples make things easily to understand.

• 

  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.

   

• 

  Wonderful presentation, need more deep materials like this.

• 

  Very nice.