Over the last six months I’ve given variations on the same F# presentation on six separate occasions.  Each time I’ve gotten a similar response: enthusiasm from a small percentage of the audience and glazed-over stares from the majority.  In retrospect it seems obvious that I’ve been missing one of the major tenets of making great presentations, know thy audience.  It’s time for a new approach.

 

Information Overload

When thinking about how to get people excited about F# I immediately jumped to the learning format that I found the most exciting.  There was no time in my life when I was as overwhelmed by information like I was working on my Computer Science degree at UMass Amherst and I loved every minute of it.  When I started out, it seemed that using a university lecture as a model was the best possible format for sharing this kind of information.

I’ve since come to realize that this style of soaking the audience with “a fire hose of information” is a poor format for Code Camps.  While using this technique, I could see people turning off one by one as they became overloaded with information.  This is not in the spirit of code camp which aims to be a much more laid back kind of experience. 

 

As a FP Ambassador

Let’s invert perspectives and think about what an audience member would want.  When a person comes to a Code Camp presentation, it’s likely to be one of their first times being exposed to the topic being presented.  They don’t want to be taught as if they were in a classroom.  Instead, they want to be exposed to new and exciting information.  If their interest is piqued, they will seek details later.

So, instead of focusing on the details of F#, this new presentation will be built around the goal of instilling five key ideas to the audience:

• F# will save you time
• F# will help you become a better programmer
• F# is beautiful
• Immutability is next to godliness
• You can start using F# right now

It must be understood that almost every Code Camp attendee will have had little or no exposure to functional programming.  To many attendees, to be presenting on F# is to be an ambassador from the strange and nebulous functional programming world.  Instead of building walls of information, the goal should be to instead focus on connecting with the audience on the benefits of functional programming.

 

Planned Talk Structure

• Depending on an Audience Poll, Broad Concepts
• Testing with F#
• nUnit Examples (as a baseline)
• xUnit Examples
• FsStory Examples
• Analysis with F# (A Real Example From Atalasoft)
• Using The F# Interactive Window To Build Tests
• Data Collection
• Visualizing Data
• Conclusion
• Why F#?

More details will follow soon.

Over the last six months I’ve given variations on the same F# presentation on six separate occasions.  Each time I’ve gotten a similar response: enthusiasm from a small percentage of the audience and glazed-over stares from the majority.  In retrospect it seems obvious that I’ve been missing one of the major tenets of making great presentations, know thy audience.  It’s time for a new approach.

 

Information Overload

When thinking about how to get people excited about F# I immediately jumped to the learning format that I found the most exciting.  There was no time in my life when I was as overwhelmed by information like I was working on my Computer Science degree at UMass Amherst and I loved every minute of it.  When I started out, it seemed that using a university lecture as a model was the best possible format for sharing this kind of information.

I’ve since come to realize that this style of soaking the audience with “a fire hose of information” is a poor format for Code Camps.  While using this technique, I could see people turning off one by one as they became overloaded with information.  This is not in the spirit of code camp which aims to be a much more laid back kind of experience. 

 

As a FP Ambassador

Let’s invert perspectives and think about what an audience member would want.  When a person comes to a Code Camp presentation, it’s likely to be one of their first times being exposed to the topic being presented.  They don’t want to be taught as if they were in a classroom.  Instead, they want to be exposed to new and exciting information.  If their interest is piqued, they will seek details later.

So, instead of focusing on the details of F#, this new presentation will be built around the goal of instilling five key ideas to the audience:

• F# will save you time
• F# will help you become a better programmer
• F# is beautiful
• Immutability is next to godliness
• You can start using F# right now

It must be understood that almost every Code Camp attendee will have had little or no exposure to functional programming.  To many attendees, to be presenting on F# is to be an ambassador from the strange and nebulous functional programming world.  Instead of building walls of information, the goal should be to instead focus on connecting with the audience on the benefits of functional programming.

 

Planned Talk Structure

• Depending on an Audience Poll, Broad Concepts
• Testing with F#
• nUnit Examples (as a baseline)
• xUnit Examples
• FsStory Examples
• Analysis with F# (A Real Example From Atalasoft)
• Using The F# Interactive Window To Build Tests
• Data Collection
• Visualizing Data
• Conclusion
• Why F#?

More details will follow soon.

I will be speaking at tomorrow’s Code Camp Hartford 2 on the topic of using F# for the Testing and Analysis of existing code. This talk will be composed of much of the same material I used at Code Camp Waltham 11, although I will be preparing additional introductory material as many of my Waltham attendees had no prior exposure to F#. 

I hope the audience will find this new introduction short and sweet.  In this case my goal will not be to teach F# per se, instead I would like to impress upon the audience the power of using functional programming constructs.

 

Presentation Details

F# for Testing and Analytics will be held in Room E-Echo at 10:30am.

As I often like to make changes up to the last minute, this post will be updated with my slides after the presentation. Slides are now available here.

 

The Plan

• Talk Introduction
• Shameless Plug: Upcoming F# User Group Speakers
• Survey the audience
• F# Introduction
• Why F#?
• Some Quick and Elegant Examples contrasted with C#
• F# Testing Toolbox
• xUnit.NET
• TestDriven.NET and NCover
• NaturalSpec
• FsCheck

For more information, see my post on the Code Camp Waltham 11 Presentation.  I wrote quite extensively in that post on most of the things I will be discussing in this talk.

This week Steve Horsfield continues his adventures with WPF while Matthew Podwysocki posts more on the .NET Event Model.  Meanwhile, John Harrop shares a video tutorial on F# interactive and Chris Smith provokes meta discussion on the best way to present F#.

 

Upcoming Events

• Houston F# Users Group – Meeting August 27th 7:00pm.
• New England F# User Group – Meeting September 7th 6:30pm.

If you would like your F# event to be listed here, please let me know via the email link at the top of this page.

 

Posts of Note

Steve Horsfield on WPF, Resources and F#

The problem is a simple one: add a toolbar image into an assembly and make it available as a resource in WPF, but use only XAML and F#.

 

Steve Horsfield on Chaining Side Effects in F#

The first question that any functional programmer should ask is, “why are there side effects?!” Side effects are anathema to functional programming purists because they introduce many kinds of undesirable characteristics into code, limiting optimization and restructuring options.

 

Matthew Podwysocki on Creating and Disposing .NET Event Handlers

So far in this series, I’ve covered a bit about what first class events are in F# and how you might use them. […] This time, let’s look at how we might manage the lifetime of a given event subscription. 

 

Jon Harrop’s F# Interactive Tutorial Video for Beginners

This is a quick teaching on the use of the F# Interactive Mode which  lets you, like the OCaml top level, type code in in real time.

 

Chris Smith’s F# for Architects: Hitting the Sweet Spot

When I was at DevLink last week I gave a talk designed to specifically identify why and when you should use F#. I was going to post the slides, but then I realized that they are in the form of a ‘presentation deck’ rather than a ‘reading deck’. So rather than having a few vague slogans and images in a .pptx file, I’ve transcribed my talking points.

I would consider Chris Smith’s post a must read for anyone giving talks on, or otherwise promoting, F#.  I gave much thought to a number of different aspects of my F# presentations after reading this.

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.

I’ve been working for a while on a new presentation which I was finally able to give last week at the New Hampshire .NET User Group.  F# and You! focuses on painting the big picture about F# instead of the off-putting details like having to learn new syntax.

 

For this new presentation I start by discussing the adoption of functional programming on other platforms by using Scala, Erlang and Haskell as examples.  I then continue on to how the algorithmic programmers are moving to functional languages while UI developers are moving towards declarative.

This then naturally raises the question of why programmers would choose a specific style of programming for a specific task.  The answer, of course, is that when you work close to a domain you can build things more quickly and with a lower error rate.

This then transitions easily into the specific beneficial properties of functional programming (and F#).

 

General Overview:

• The Separation of UI and Back End
• What is Functional Programming? (Functional Concepts)
• Pure functions
• Immutability
• Lambda Expressions
• Higher Order Functions
• Recursion
• The Benefits of Functional Programming
• Code Compression
• Parallelism
• Robustness
• Proof is in the Pudding
• TrueSkill
• Grange Insurance Rating Engine
• MSN adCenter
• Wrap-up

 

I’ve also found that it is useful to show the latest circulating version of the Ant Colony simulation I wrote over a year ago.  I found a version in Don Syme’s JAOO Talk code samples but am not sure who has been keeping it up to date.  A big thanks to whoever that person is.  It provides some sweet eye candy to dull the bitterness of the technical Functional Concepts section.

 

Planned (and Past) “F# and You!” Locations:

11/10/2009 – CT .NET Developers Group (Farmington, CT)
10/28/2009 – Technology Users Group (Charleston, SC)
10/21/2009 – New Hampshire .NET User Group (Nashua, NH)

See the new Other Events section of our F# User Group site for information on other upcoming F# talks.

 

Downloads:

Latest Slides
VS2008 Code Samples

As momentum builds for the F# release with Visual Studio 2010, so too does the number of people blogging about the language.  This week we have a spec update, clarified comparisons, decision trees, porting gotchas and in depth explorations of the debug IL generated by F#.  Please do enjoy.

 

Speaking on F# at the Connecticut .NET Developer’s Group

Tomorrow (Tuesday November 10th, 2009) I’ll be speaking on F# at the Connecticut .NET Developer’s group.  For more information check out the ClickToAttend event.

 

From Don Syme’s Blog - F# Spec Updated for the 1.9.7 Release

Many thanks to all those who sent so much helpful feedback on the specification during Beta1. And for those using 1.9.7 already, thanks for your patience in the last couple of weeks - it took us a little longer to get this out the door than we had planned, since a development deadline for Visual Studio 2010 intervened.

 

Don Syme’s Equality and Comparison Constraints in F#

F# 1.9.7 introduces two new constraints to the F# language to help uncover issues in your code when using equality and comparison operators. In this blog entry we'll take a look at these constraints in a bit more detail.

The F# team has inherited quite a mess in terms of the lack of any kind of concrete definition of equality in the .NET framework.  It seems that they’ve been able to do much with it though.

 

Chris Smith’s Decision Trees Part 1 and Part 2

Now that we got all that painful math out of the way, let’s write some code! Here is an implementation of the algorithm in F#.

I’m just dying to see this extended to Bayesian network.  Perhaps I’ll try and extend it myself.

 

Bart De Smet’s Stack-Friendly Recursion

Recursion is a widely known technique to decompose a problem in smaller “instances” of the same problem. For example, performing tree operations (e.g. in the context of data structures, user interfaces, hierarchical stores, XML, etc) can be expressed in terms of a navigation strategy over the tree where one performs the same operation to subtrees.

A detailed look at tail recursion optimization in F# and how to achieve something similar in C#.

 

On StackOverflow, is a program F# any more efficient (execution-wise) than C#?

I'm guessing that it is not because they both boil down to the same IL.

It turns out that F# is in fact much faster in some cases.  For more on F# performance see this roundup post.

 

Steve Gilham’s F# under the covers parts 1, 2, 3, 4, 5, 6, and 8

I'm in the tidying up stages for the little project I've been working on lately, a set of FxCop rules, mainly aimed at providing some complementary features for nCover-style code coverage, including static analysis for trivial methods -- or compiler generated ones.

In this series Steve takes a very careful approach to exploring the IL generated by the F# compiler in debug mode.

 

Matt Moloney’s Lessons Learned in Porting [from] C# to F# (WPF)

I encountered a ton of difficulties while porting code from C# to F#. Fortunately / unfortunately, so have many other people. Thankfully they took the time to write about these problems so my solutions were often only a quick search away. Here is a collection of some of the finds that were able to help me in my endeavors.

An excellent post well worth reading for anyone getting ready to port to F#.