Some interesting gems this week.  Revit, Closures and MathTools won the day.  However, I do hope you'll take a look at the IL post as well.

Blog – Jeremy Tammik’s Use F# Directly in Revit

In Jeremy’s post he discusses what is initially necessary to get F# and Revit working together.  He also provides a sample of a Revit addin written in F#. 

Revit is Autodesk’s architecture and design studio.  It allows physical engineers to coordinate and play with, design and visualize data while integrating directly with AutoCad.  It also provides a .NET 2.0 API.  Given F#’s support for units as well as it’s concise and mathy style, it makes sense that it would be an ideal language for engineers.

Site - WikiBooks FSharp Programming

Before I stumbled upon this site, I had never head of of WikiBooks.  That’s why I was incredibly surprised to find that it has the best online general F# reference around.  It has extensive sections on functional, immutable and imperative programming with rich examples and references to the math behind the ideas presented.  It’s a great site to have at hand for both those learning about the language and those experienced but still needing to occasionally look something small up.

StackOverflow -  A practical example of a closure in F#

Learning how to program functionally is much more than just learning some  new ideas and a new syntax.  It comes along with a ton of new jargon, some of which can be quite foreign sounding.  I find that it often turns out that the jargon actually represents a very simple idea and that becomes immediately obvious when discussed with a simple example.

Software – FSharp.MathTools

As you might have suspected by its name, MathTools is an extensive set of mathematics libraries for F#.  It provides, among other things, statistical functions, fast fourier transforms, optimization algorithms, Matlab compatibility and extended mathematical notation.  With a little development this combined with VSLab could provide a viable alternative to tools like Matlab while still allowing for collaboration with colleagues.

Article – Introduction to IL Assembly Language

It’s the responsibility of any serious programmer to know how how his or her tools work all the way down the chain.  In this relatively short article (given the topic) everything you would need to write a .NET compiler is distilled.  It’s the best reference of it’s kind I’ve seen.

Some interesting gems this week.  Revit, Closures and MathTools won the day.  However, I do hope you'll take a look at the IL post as well.

Blog – Jeremy Tammik’s Use F# Directly in Revit

In Jeremy’s post he discusses what is initially necessary to get F# and Revit working together.  He also provides a sample of a Revit addin written in F#. 

Revit is Autodesk’s architecture and design studio.  It allows physical engineers to coordinate and play with, design and visualize data while integrating directly with AutoCad.  It also provides a .NET 2.0 API.  Given F#’s support for units as well as it’s concise and mathy style, it makes sense that it would be an ideal language for engineers.

Site - WikiBooks FSharp Programming

Before I stumbled upon this site, I had never head of of WikiBooks.  That’s why I was incredibly surprised to find that it has the best online general F# reference around.  It has extensive sections on functional, immutable and imperative programming with rich examples and references to the math behind the ideas presented.  It’s a great site to have at hand for both those learning about the language and those experienced but still needing to occasionally look something small up.

StackOverflow -  A practical example of a closure in F#

Learning how to program functionally is much more than just learning some  new ideas and a new syntax.  It comes along with a ton of new jargon, some of which can be quite foreign sounding.  I find that it often turns out that the jargon actually represents a very simple idea and that becomes immediately obvious when discussed with a simple example.

Software – FSharp.MathTools

As you might have suspected by its name, MathTools is an extensive set of mathematics libraries for F#.  It provides, among other things, statistical functions, fast fourier transforms, optimization algorithms, Matlab compatibility and extended mathematical notation.  With a little development this combined with VSLab could provide a viable alternative to tools like Matlab while still allowing for collaboration with colleagues.

Article – Introduction to IL Assembly Language

It’s the responsibility of any serious programmer to know how how his or her tools work all the way down the chain.  In this relatively short article (given the topic) everything you would need to write a .NET compiler is distilled.  It’s the best reference of it’s kind I’ve seen.

With the start of our F# User’s Group this next Monday and New England Code Camp 11 last weekend, things have been extremely busy this past week.  Meanwhile, the F# sociocosm is growing at a rapid pace.  This week we have a talk by Don Syme, a look at F# quotations, and finally, some discussion on Seq.unfold.

Chris Bowen’s Post, Announcing F# User Group in Cambridge - April 6

A shameless plug here for our new user group.  A big thanks to Chris for helping us find the resources we needed to start out.  Without him this might never have come together.

Don Syme’s Talk, F# and functional programming in .NET

As Don Syme is the father of F#, when he speaks the community listens.  In this talk Don focuses on the pleasure and speed inherent in using FP and F#.  He does this by describing the functional methodology and constructs which provide a simpler and more elegant model for building programs.

Alex P’s Post, F# quotations at their simplest

A simple example on the surface for sure.  However, if you haven’t seen the power of F#’s language oriented programming features this is sure to be of interest.

For a deeper look at the power of quotations check out Tomáš Petříček’s F# quotations visualizer.  If his past projects are any indication Tom’s upcoming book is a must have for any F# enthusiast.  I preordered a copy just today.

Martin Peck’s Post, Solving Problems in C# and F# - Part 2 
(and update)

One of the most fantastic things F# has to offer is the rich functional programming heritage of sequence operations.  To demonstrate how elegant they can make your code, I would like to offer the following alternative F# solution:

let fibs = 
  Seq.unfold (fun (a, b) -> Some( a, (b, a+b) )) (0I, 1I)

Seq.find (fun n -> n >= 10I ** 999I ) fibs

I’m going to take this opportunity to point out the obvious: we have here two lines of F# which does almost exactly the same thing as thirty six of C#.   Now that’s what I call power and elegance.  The unfold function pretty much does exactly what yield was doing before, but implicitly in terms of the unfold function.  The idea of unfold can be confounding at first and so here is a breakdown of how it works:

let fibs =
  Seq.unfold 
    (fun (a, b) -> //generator function, 
                   //(a, b) is the previous state
      Some //Option monad, needed for unfold
        (a, (b, a + b))) //returned tuple: (value, state)
                         //or (first, (second, third))
      (0I, 1I) //Initial function state (first, second)

Note that in this version the state of the next two values in the sequence are always pre-calculated.  However, it is easy to avoid this if you instead consider the state in terms of the previous two values: 

let fibs = 
  Seq.unfold (fun (l, l2) -> 
    let n = l + l2 in Some( n, ( n, l ) ))
    (0I, 1I) //(previous, second previous)

If you want to learn more about unfold I recommend checking out:

Dustin Campell’s Post, Apples and Oranges

This is the best description of how unfold works I’ve seen to date. 

This week we have ActionScript byte code manipulation, COM interop in F#, a quick look at the option type, and finally, a very elegant cross product implementation.

Blog – Luis Diego Fallas’s Manipulating AVM2 byte code with F#

This article focuses on using AbcExplorationLib to parse AVM2 ActionScript byte code.   AbcExplorationLib is still rather new and does not yet have complete support for all AVM2 instructions.  However, it may eventually be useful for static analysis or, in the best possible case, flash generation from within .NET languages. 

Article – Richard Marsden’s Functional Programming with MapPoint and F# (Part One)

In this post Richard initially walks through the steps involved in getting COM Interop in F# via both early and late binding.  He then goes on to programmatically load up a new MapPoint instance and instantiate a pushpin on it.  Once the painful COM stuff is out of the way it seems F# could make a rather nice scripting language for Microsoft apps such as this.

We’ve been told that C# 4.0 will offer COM interoperability that is significant less painful due to it’s new named arguments, dynamic typing and language binding layers.  After reading this article, I can’t help but wonder how much of this (if any) will be available in F#.  In the CTP release both early and late binding are rather painful.

Stack Overflow – How does the option type work in F#?

It’s a rather simple question, but I do like how the community came out to help answer it.  Although, I do think it’s very debatable whether null or -1 make for a better answer to the question “how long is this null string?”.

Generally, I’m opposed to hiding information inside of a type meant to hold something else, especially if it’s a scalar value.  Were it not for the overhead involved, in C# I would think the best solution would be to throw an exception.  Inside F#, at least with option types you know you are handling an exceptional case and not just an empty variable.  Yet another great benefit of immutability.

Stack Overflow – F# – Cross Product of Two Lists

I wanted to include this as Tomas Petricek’s solution was extremely elegant.

This week we have MapReduce, WebTools and yet another F# to C# language comparison.  I spent yesterday at a seminar led by Michael de la Maza.  He, Talbot Crowell and I will soon be starting a F# user’s group in Boston, Massachusetts.  I’m interested in any comments you might have.  Please feel free to send me an email if you would like to discuss speaking at it or content you would like to see covered.

Blog - Matthew Podwysocki’s Exploring MapReduce with F#

Google’s MapReduce software framework has revolutionized the way software engineers think about processing large data sets.  Since it’s introduction at least 15 variants have been developed.  Thorough as always, Matthew explores what MapReduce is, how it relates to functional programming and, finally, shows his own light-weight MapReduce implementation.

Software – Thomas Petricek’s FSharp.WebTools

The F# Web Tools augment the F# distribution with tools to author homogeneous client/server/database web applications in one type-checked project.

It does this by generating Javascript from F#.  The big advantage here is that you can effectively have statically checked Javascript and so avoid a whole class of bugs that come along with dynamically typed programming.  While many are excited about this prospect, at least one person seems to have had trouble getting it to work.  Currently, only the source tree is available and it must be manually compiled.  I know I’m not the only one hoping for a tested release in the near future.

Blog – Martin Peck’s Solving Problems in C# and F# – Part 1

In this post Martin compares solutions to Project Euler problems 10 and 12 in both C# and F#.  In competition with his friend Giles Knap, he wrote his answers in C# while Giles wrote in F#.  Afterward, each set of answers is discussed independently.  He concludes that the languages were equally readable but the F# implementations were slower. 

I wish Giles had written a rebuttal post as Martin seems to be a die hard C# fan.  I don’t agree that they were equally readable.  The F# problems lacked much of the syntactic cruft and whitespace found in the C# examples. 

Also, as single core results are fast becoming meaningless, it would be very if they would agree to use asynchronous workflows in F# and compare that with the .NET Parallel Extensions in C#.  By constraining the answers to be single thread only, it seems like they avoided much of F#’s inherent benefit in multicore processing. 

I also can’t help wondering how each of their prime generating examples would compare with the memoizing example I mentioned two weeks ago.  I’d be shocked to see a similar C# implementation in anywhere near as little space.

This week I have a very diverse set of topics:  First, using the functional programming concept of folds in C# to reimplement much of LINQ.  Then a bit of reflection on F# Grammar Parsers.  Finally, some community discussion on real world F# applications.

Blog – Matthew Podwysocki’s Functional C#, Fun With Folds

In this post Matthew reimplements much of LINQ using folds over IEnumerable.  This post is a great opportunity for those who are living in the C# world to see how some of the constructs in the functional programming world work.  I particularly like how Matt went the extra mile and included Pex tests for his examples.  It gives extra clarity to his already well defined extension methods.

Software – FParsec, A Parser Combinator Library for F#

The basic idea behind a Parser Combinator is that you use it to build a parser with a large vocabulary out of a set of single vocabulary sub parsers.  The claim is that, while this technique may not result in code that is as easy to read as something along the lines of fsyacc, it supports grammars which are much more complex while simultaneously allowing for an ultimately more extensible implementation.

I personally have not yet spent much time with either fsyacc or FParsec, but it’s interesting to contrast their different bottom up and top down approaches.  Fsyacc seems ideal for parsing simple grammars such as SQL.  The resulting code is very to understand and looks as though it would be similarly fast to write.  However, if you wanted to implement something along the lines of regular expressions, FParsec seems a much better choice due to it’s direct support of infinite look-ahead.

Stack Overflow – What areas of code are you using F# for?

A quick survey of Stack-Overflowers shows some uses cases for F# beyond DSL and Concurrency.  My personal favorites are statistical calculations and visualizations as they can be a nightmare to deal with in C#.  Also, as Talbott Crowell awed many with at the recent MSDN Boston conference, F# can be leveraged to easily make some amazing time-sensitive visualizations. 

I was also surprised that more people weren’t using F# for testing or scripting as they are also both very good use cases. 

A Note From Rick

I apologize for so frequently changing the name of my weekly roundup post.  Over the last few months it’s moved more and more in the direction of FP in .NET and so I felt “Discoveries this Week” was no longer appropriate.  Last week I decided to change the name but, after some reflection, it seems my choice was much too wordy.  I think I’ve finally found a name that fits.

This week we have practical examples of Lazy Evaluation with Memoization, an interview with Don Syme and a discussion on the Visitor Pattern’s place in F#.  Also, any comments on the new title for my weekly posting would be appreciated.

Forum – Memoization and Lazy Evaluation in F# on HubFS

In this thread brianmcm (Brian McNamara) and divisortheory (???) explore using memorization and LazyLists to optimize a Trial Division driven prime generator.  It’s interesting to look at how their prime generator evolved over time as they incorporated these ideas and optimized.

Article – Kathryn Edwards interviews Don Syme on F# Development

In this technically light but still extremely interesting interview, Kathryn mainly directs the conversation in the direction of the development and adoption of the F# programming language.  The most interesting thing I gleaned from the interview?

One of the key designers of Haskell, Simon Peyton-Jones, is just down the corridor from me at Microsoft Research Cambridge and has been a great help with F#.

Perhaps my F#/Haskell genealogy graph needs an additional arrow.

Blog – Stephen Easey’s (?) Visitor Patten in C# and F#

In this post Stephen explores the Visitor Patten in both C# and F#.  I always love to see examples of how much more beautiful and concise F# is than C#.  The 218 line C# implementation shown beside the same implementation in 64 lines of F# makes for a great comparison in this regard. 

I agree with Stephen’s conclusion in that, given the purpose of the visitor pattern is to separate algorithm from object via a double dispatch layer, in many situations the visitor pattern is unnecessary in F# because of its advanced pattern matching capabilities.

However, I feel that he may not have considered the perspective of an API provider.  In this context, it may be desirable for the consumer of an API to be able to extend the dispatch process to handle new cases.  The issue with a single monolithic matching function is that all of the logic is contained within that single function and so the system is no longer nearly as open to extension.  This violation of the Open Closed Principle (which applies to building APIs in any type of language) will make for difficult to reuse software. 

Perhaps a F# pattern matching equivalent could be made with lambda functions for each branch.  Lambdas could be curried into the matching function and so each branch could potentially be replaced with new logic by the consumer.  However, this is feels to me like reimplementing OO with FP constructs.

This week we have practical examples of Lazy Evaluation with Memoization, an interview with Don Syme and a discussion on the Visitor Pattern’s place in F#.  Also, any comments on the new title for my weekly posting would be appreciated.

Forum – Memoization and Lazy Evaluation in F# on HubFS

In this thread brianmcm (Brian McNamara) and divisortheory (???) explore using memorization and LazyLists to optimize a Trial Division driven prime generator.  It’s interesting to look at how their prime generator evolved over time as they incorporated these ideas and optimized.

Article – Kathryn Edwards interviews Don Syme on F# Development

In this technically light but still extremely interesting interview, Kathryn mainly directs the conversation in the direction of the development and adoption of the F# programming language.  The most interesting thing I gleaned from the interview?

One of the key designers of Haskell, Simon Peyton-Jones, is just down the corridor from me at Microsoft Research Cambridge and has been a great help with F#.

Perhaps my F#/Haskell genealogy graph needs an additional arrow.

Blog – Stephen Easey’s (?) Visitor Patten in C# and F#

In this post Stephen explores the Visitor Patten in both C# and F#.  I always love to see examples of how much more beautiful and concise F# is than C#.  The 218 line C# implementation shown beside the same implementation in 64 lines of F# makes for a great comparison in this regard. 

I agree with Stephen’s conclusion in that, given the purpose of the visitor pattern is to separate algorithm from object via a double dispatch layer, in many situations the visitor pattern is unnecessary in F# because of its advanced pattern matching capabilities.

However, I feel that he may not have considered the perspective of an API provider.  In this context, it may be desirable for the consumer of an API to be able to extend the dispatch process to handle new cases.  The issue with a single monolithic matching function is that all of the logic is contained within that single function and so the system is no longer nearly as open to extension.  This violation of the Open Closed Principle (which applies to building APIs in any type of language) will make for difficult to reuse software. 

Perhaps a F# pattern matching equivalent could be made with lambda functions for each branch.  Lambdas could be curried into the matching function and so each branch could potentially be replaced with new logic by the consumer.  However, this is feels to me like reimplementing OO with FP constructs.

This week I have a very diverse set of topics:  First, using the functional programming concept of folds in C# to reimplement much of LINQ.  Then a bit of reflection on F# Grammar Parsers.  Finally, some community discussion on real world F# applications.

Blog – Matthew Podwysocki’s Functional C#, Fun With Folds

In this post Matthew reimplements much of LINQ using folds over IEnumerable.  This post is a great opportunity for those who are living in the C# world to see how some of the constructs in the functional programming world work.  I particularly like how Matt went the extra mile and included Pex tests for his examples.  It gives extra clarity to his already well defined extension methods.

Software – FParsec, A Parser Combinator Library for F#

The basic idea behind a Parser Combinator is that you use it to build a parser with a large vocabulary out of a set of single vocabulary sub parsers.  The claim is that, while this technique may not result in code that is as easy to read as something along the lines of fsyacc, it supports grammars which are much more complex while simultaneously allowing for an ultimately more extensible implementation.

I personally have not yet spent much time with either fsyacc or FParsec, but it’s interesting to contrast their different bottom up and top down approaches.  Fsyacc seems ideal for parsing simple grammars such as SQL.  The resulting code is very to understand and looks as though it would be similarly fast to write.  However, if you wanted to implement something along the lines of regular expressions, FParsec seems a much better choice due to it’s direct support of infinite look-ahead.

Stack Overflow – What areas of code are you using F# for?

A quick survey of Stack-Overflowers shows some uses cases for F# beyond DSL and Concurrency.  My personal favorites are statistical calculations and visualizations as they can be a nightmare to deal with in C#.  Also, as Talbott Crowell awed many with at the recent MSDN Boston conference, F# can be leveraged to easily make some amazing time-sensitive visualizations. 

I was also surprised that more people weren’t using F# for testing or scripting as they are also both very good use cases. 

A Note From Rick

I apologize for so frequently changing the name of my weekly roundup post.  Over the last few months it’s moved more and more in the direction of FP in .NET and so I felt “Discoveries this Week” was no longer appropriate.  Last week I decided to change the name but, after some reflection, it seems my choice was much too wordy.  I think I’ve finally found a name that fits.

This week we have MapReduce, WebTools and yet another F# to C# language comparison.  I spent yesterday at a seminar led by Michael de la Maza.  He, Talbot Crowell and I will soon be starting a F# user’s group in Boston, Massachusetts.  I’m interested in any comments you might have.  Please feel free to send me an email if you would like to discuss speaking at it or content you would like to see covered.

Blog - Matthew Podwysocki’s Exploring MapReduce with F#

Google’s MapReduce software framework has revolutionized the way software engineers think about processing large data sets.  Since it’s introduction at least 15 variants have been developed.  Thorough as always, Matthew explores what MapReduce is, how it relates to functional programming and, finally, shows his own light-weight MapReduce implementation.

Software – Thomas Petricek’s FSharp.WebTools

The F# Web Tools augment the F# distribution with tools to author homogeneous client/server/database web applications in one type-checked project.

It does this by generating Javascript from F#.  The big advantage here is that you can effectively have statically checked Javascript and so avoid a whole class of bugs that come along with dynamically typed programming.  While many are excited about this prospect, at least one person seems to have had trouble getting it to work.  Currently, only the source tree is available and it must be manually compiled.  I know I’m not the only one hoping for a tested release in the near future.

Blog – Martin Peck’s Solving Problems in C# and F# – Part 1

In this post Martin compares solutions to Project Euler problems 10 and 12 in both C# and F#.  In competition with his friend Giles Knap, he wrote his answers in C# while Giles wrote in F#.  Afterward, each set of answers is discussed independently.  He concludes that the languages were equally readable but the F# implementations were slower. 

I wish Giles had written a rebuttal post as Martin seems to be a die hard C# fan.  I don’t agree that they were equally readable.  The F# problems lacked much of the syntactic cruft and whitespace found in the C# examples. 

Also, as single core results are fast becoming meaningless, it would be very if they would agree to use asynchronous workflows in F# and compare that with the .NET Parallel Extensions in C#.  By constraining the answers to be single thread only, it seems like they avoided much of F#’s inherent benefit in multicore processing. 

I also can’t help wondering how each of their prime generating examples would compare with the memoizing example I mentioned two weeks ago.  I’d be shocked to see a similar C# implementation in anywhere near as little space.