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

A couple of months ago I was talking to Lou Franco, the head of our Software Engineering department and fellow functional programming enthusiast, about the possibility of using F# for projects in the future.  Being business minded, he replied that he would need a compelling reason to bring F# on board.  This presentation is dedicated to him and others who have functional programming on their radar but haven’t yet found a compelling reason to bring it in to their company.

I acknowledge that, as for now, it’s difficult to suggest anyone do more than play with F#.  I have been anxiously awaiting the stabilization of the F# API which will come along with the release of VS2010.  With the recent changes breaking backwards compatibility, maintaining my old F# samples has become quite a nightmare.  Indeed, not a single code sample I have from a year ago works out of the box with the current release.

However, VS2010 is only a few months away.  Now is the time to start learning about F# and the paradigms which make it so powerful.  Functional programming has amazing benefits in terms of parallelization, code compression and overall code robustness.  

At Code Camp 12 Boston, I will talk about the soon-to-be-realized world where programmers are divided into groups which each use different types of languages to build different kinds of things.  This is easy to predict as it is already occurring.  UI, data processing and data storage programmers are already diversifying both in working knowledge and tools.

As is evidenced by WPF, HTML and CSS it seems UI design is moving more and more to a declarative style.  Similarly, the rise of F#, Scala, Erlang and Haskell indicates that algorithmic programmers are migrating to the functional programming languages.  SQL has long been the language of those involved in data storage.  It’s no wonder that this has happened.  When your tool is better designed for your job, the work gets done faster and you end up with a better result.

Where does this leave imperative and object oriented languages?  Languages like Java, VB and C# will be relegated to being used as “glue” for existing systems while abstract languages slowly eat away their market share.  This will happen more and more as the number of cores per processor continues to increase and those with imperative implementations find that they are unable to scale.

When: Oct 16th, 2009 (11:50am)
Where: 201 Jones Rd, 6th Floor, Waltham MA USA (Room TBC)

Slides are available here.

Also, be sure to also check out my fellow F# User Group leader Talbott Crowell’s talk.  It’s right before mine (10:30) in the same room (Thanks Chris!).  You can find out more by heading over to Chris Bowen’s blog and reading his post on Code Camp 12.