A wide range of subjects this week including testing, concurrent performance, exception handing and data structures.

 

Software – FsStory, a library for writing executable user stories in F#

I feel that F#, with it’s concise syntax, is an ideal framework for writing tests.  Combined with FsStory F# is made much more powerful in this regard as it becomes possible to write user case tests and have them read very much like simple English.   F# has a huge advantage here over C# as it has much less syntactic cruft and so much less for your brain to process while reading.   For example:

  1: [<Fact>]
  2: let MoveTurtleToPosition() = 
  3:        given ATurtle
  4:     |> andGiven IsRotated90DegreesToTheRight
  5:     |> whens (TurtleWalksSteps 9)
  6:     |> thens (TurtleIsLocatedAt (0,9))   
  7:     |> endStory

It’s obvious exactly what this is testing and how.  Yet, it takes very little time to read.  Very impressive.

 

Blog –Jan Varwig’s F# Observations

While this post is rather old, I was very excited by Jan’s analysis of an article on comparing C# and F# using the distributed .NET computing framework Alchemi. 

Optimizing this application showed that F# would finish in 1.5 seconds while C# would not complete any faster than 2.6 seconds.

It’s important to note that these results are a year old now and that with newer F# optimization the results might be even better.

The other interesting thing in this post is the discussion of the cost of heavyweight threads on the CLR.  Which is directly related to our next discovery:

 

Blog – Daniel Moth’s New and Improved CLR 4 Thread Pool Engine

A first glimpse of that is in store for us in the next iterating of the Thread Pool.  Not surprisingly, the optimizations seem to focus on sharing work across multiple threads. 

With F#’s thread-friendly nature and new the optimized thread pool, I'm very excited to see how .NET compares to other grid computing platforms after it’s 4.0 release.

 

Blog – Arthur Herczeg’s F# Exceptions

An informational post on managing and throwing both F# native and general .NET exceptions in F#.  Included are examples of imperative style try, catch and try, finally patterns.

 

Blog – Karl Krukow’s Understanding Clojure’s PersistentVector

Rich Hickey, the father of the Clojure language, has gone out of his way to optimize Clojure’s structures for data sharing with immutability.  I was very impressed with Clojure when, back last march, Rich Hickey came to Northampton and presented it in a talk.  While, Clojure runs on the JVM and so comes along with all of the baggage that it entails, it’s a fantastic language and people in the java community are flocking to it.

I would love to see some of these data structures ported to the .NET framework so that F# could take advantage of them.  As far as I am currently aware, F# data structures are instead implemented via binary trees and so are much less efficient in terms of the amount of data shared.

A wide range of subjects this week including testing, concurrent performance, exception handing and data structures.

 

Software – FsStory, a library for writing executable user stories in F#

I feel that F#, with it’s concise syntax, is an ideal framework for writing tests.  Combined with FsStory F# is made much more powerful in this regard as it becomes possible to write user case tests and have them read very much like simple English.   F# has a huge advantage here over C# as it has much less syntactic cruft and so much less for your brain to process while reading.   For example:

  1: [<Fact>]
  2: let MoveTurtleToPosition() = 
  3:        given ATurtle
  4:     |> andGiven IsRotated90DegreesToTheRight
  5:     |> whens (TurtleWalksSteps 9)
  6:     |> thens (TurtleIsLocatedAt (0,9))   
  7:     |> endStory

It’s obvious exactly what this is testing and how.  Yet, it takes very little time to read.  Very impressive.

 

Blog –Jan Varwig’s F# Observations

While this post is rather old, I was very excited by Jan’s analysis of an article on comparing C# and F# using the distributed .NET computing framework Alchemi. 

Optimizing this application showed that F# would finish in 1.5 seconds while C# would not complete any faster than 2.6 seconds.

It’s important to note that these results are a year old now and that with newer F# optimization the results might be even better.

The other interesting thing in this post is the discussion of the cost of heavyweight threads on the CLR.  Which is directly related to our next discovery:

 

Blog – Daniel Moth’s New and Improved CLR 4 Thread Pool Engine

A first glimpse of that is in store for us in the next iterating of the Thread Pool.  Not surprisingly, the optimizations seem to focus on sharing work across multiple threads. 

With F#’s thread-friendly nature and new the optimized thread pool, I'm very excited to see how .NET compares to other grid computing platforms after it’s 4.0 release.

 

Blog – Arthur Herczeg’s F# Exceptions

An informational post on managing and throwing both F# native and general .NET exceptions in F#.  Included are examples of imperative style try, catch and try, finally patterns.

 

Blog – Karl Krukow’s Understanding Clojure’s PersistentVector

Rich Hickey, the father of the Clojure language, has gone out of his way to optimize Clojure’s structures for data sharing with immutability.  I was very impressed with Clojure when, back last march, Rich Hickey came to Northampton and presented it in a talk.  While, Clojure runs on the JVM and so comes along with all of the baggage that it entails, it’s a fantastic language and people in the java community are flocking to it.

I would love to see some of these data structures ported to the .NET framework so that F# could take advantage of them.  As far as I am currently aware, F# data structures are instead implemented via binary trees and so are much less efficient in terms of the amount of data shared.

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.

Over this past week at PDC I was lucky enough to see some fantastic sessions and spend time with members of the F# and greater Visual Studio language teams.  Naturally, these experiences have left me both floored and swimming in new ideas.  This edition of Discoveries This Week includes both the very best of what I saw at PDC 2009 and the most outstanding things I’ve glimpsed going on in the F# community.  Please do enjoy.

 

Reflection on the PDC Keynotes

For the most information in the shortest amount of time I suggest watching the day one and day two PDC keynotes.  They are both jam packed with exciting announcements and demos.  While at PDC I wrote about my experience watching these here (day one) and here (day two).

 

Microsoft Perspectives on the Future of Programming

Come hear from several of the Microsoft senior technical leaders about the future of programming, programming languages, and tools.

If you watch just one PDC session let this be it. 

With Butler Lampson, Erik Meijer, Don Box, Jeffrey Snover, Herb Sutter, and Burton Smith, Microsoft’s best gathered to debate the future of programming in a twitter driven panel at PDC.  I was happy to be able to contribute with a question on type systems which erupted into quite a disagreement.  I will be writing about this session at length, and reflecting on my past thoughts about this topic, in the near future. 

 

Luke Hoban’s F# for Parallel and Asynchronous Programming

F#, a functional and object-oriented language for Microsoft .NET, adds many tools to make parallel and asynchronous programming both fun and easy. Come hear the core concepts of the F# language, and see how ideas like immutability, functional design, async workflows, agents, and more can be used to meet the challenges of today’s real-world applications.

By combining small, easily understood, ideas Luke constructs F#’s big picture in the most engaging way I’ve seen to date.  This is now my go to talk for people who are interested in, but new to, the F# programming language.

 

Jomo Fisher’s F# Scripting, .NET 4.0 and Mixed-mode assemblies

One of the recent problems we’ve seen is that, because of the support for side-by-side runtimes, .NET 4.0 has changed the way that it binds to older mixed-mode assemblies. These assemblies are, for example, those that are compiled from C++\CLI. Currently available DirectX assemblies are mixed mode.

This clever approach to switching the F# REPL to 2.0 binding mode is particularly handy to know.

 

Matthew Moloney’s Collaborative Development Using F# Interactive

This is a proof of concept of an interactive collaborative development environment I built using  F# Interactive. The aim here is to explore different ideas for further development, not so much as to present an alternative to Visual Studio.

I couldn’t pass this very cool idea up.  I can’t help but think about extending this to full feldged explorative programming community websites.

 

Bart Czernicki’s Silverlight 3 and F# Support in Visual Studio 2010

The goal of this blog post is to make you aware of F# support in Silverlight in Visual Studio 2010.  In addition, this blog post shows an example why F# is going to be very important for Silverlight architects and developers.  Note:  This is NOT an intro to F#.

A great post.  I am always interested in seeing concrete examples of F# adding value to existing technologies and platforms.  I have a sneaking suspicion that there are very few places where it won’t.