Rick Minerich's Development Wonderland : talks

F# Discoveries This Week 11/09/2009

RickM — Mon, 09 Nov 2009 16:24:59 GMT

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

F# and You! - New Hampshire User’s Group and Beyond

RickM — Mon, 26 Oct 2009 16:24:49 GMT

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

Code Camp 12: Boston – Why F#?

RickM — Fri, 16 Oct 2009 15:18:54 GMT

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.

F# Discoveries This Week 08/23/2009

RickM — Mon, 24 Aug 2009 02:18:00 GMT

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.

Code Camp Hartford 2 Presentation – F# for Testing and Analytics (June 13th)

RickM — Fri, 12 Jun 2009 19:22:00 GMT

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

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.

As a FP Ambassador - F# for Testing and Analysis at Code Camp 11

RickM — Thu, 19 Mar 2009 16:00:00 GMT

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:

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.

The Future of Programming Languages

RickM — Wed, 15 Oct 2008 14:18:00 GMT

Yesterday, my coworker Lou Franco pointed me to a fantastic talk by Anders Hejlsberg on the future of programming languages. In this talk Anders argues that the future of programming language development will be focused on three events: the explosion in the use of Dynamic Languages, the creation of many new Domain Specific Languages and the rising need for Concurrency.

In this article I'm going to focus on Dynamic Typing and Metaprogramming in particular. It's interesting to consider what the impact on the maintainability of our code from their increased prominence might be.

Dynamic vs Static Typing

Over the last decade the use of dynamic programming languages has exploded. Working at the higher level of abstraction that dynamic languages provide allows the programmer to spend much more time building things and much less time worrying about the details. For sure, when prototyping or experimenting the speed of dynamic languages is a huge boon. However, without type checking at compile time the potential for really difficult to track down bugs is huge.

Just think about the kinds of strange bugs that can happen when any type can be passed into any argument of any method. It gets even worse when you consider that these types may be silently converting themselves. Without great care, the number of potential execution paths in your program could skyrocket.

This can be offset by really strict unit testing and extremely high code coverage. However, I have yet to see a large real world project that had this level of testing.

For these reasons I find the new C# "dynamic" keyword rather worrying. It allows the programmer to declare variables which are only type checked at runtime instead of at compile time. I would hate to have to maintain a code base where it was liberally used.

Anders also mentions F#'s static but implied typing system. He talks a bit about the two worlds of static and dynamic meeting in the middle in this kind of way. I agree, this is really the best of both worlds. You gain the "dynamic feel" but get almost none of the downsides. The security of static types without all the extra typing.

Metaprogramming

I agree that Metaprogramming is a powerful tool, especially for testing. In a ecosystem designed around objects having meaning, it only makes sense to be able to ask questions about those objects and be able to dynamically manipulate how they operate. However, I am worried that it may in some cases become a substitute for well designed architecture.

Also, because of it's nature, in many cases Metaprogramming necessitates the use of strings to represent information about the application. Strings whose contents will not be checked at compile time. Because of this it is very easy to make breaking changes to an application which won't be caught when the program is compiled.

Take for example the idea of a class with a single property. In the code for the application in which that class lives, a code branch depends on reflection to check if that property exists. If you were to rename that property that path would no longer be taken and a bug would result. If the creator of that code had used an interface instead of reflection it would have broken at compile time.

Conclusion

I'm not saying that these kinds of powerful tools shouldn't exist. They are extremely useful in many cases. We just need to be very careful in their use. As Steve Hawley likes to say, when you have a shiny new hammer everything starts to look like nails.

Edit: I want to note that I had intended to include a subsection on the direct modification of abstract syntax trees but ran out of time. Also, a good friend of mine also pointed out to me that Lisp style macros actually do let you work with the underlying code in a much more meaningful way than C++ style text manipulation.

F# at Code Camp 10 In Waltham, MA

RickM — Fri, 19 Sep 2008 20:02:00 GMT

I'll be at New England Code Camp 10 tomorrow giving another talk about functional programming and concurrency in F#. It will be fairly similar to my previous talks in terms of ideas and content, however, I have put a lot of work into making the functional programming ideas easier to understand. The code samples have also been updated and are now 100% compatible with the F# CTP Release.

~~Our internet connection is going down soon for testing. I'll be updating this post later on tonight with more information. I'll be posting my slides and updated code examples.~~

I did manage to get my slides and new code samples uploaded on Friday but I didn't have time to change my blog text. You can find them here.

The sites of interest for my presentation:
Microsoft's F# Developer's Center ( Download F# here. )
F#'s Microsoft Research Site
hubFS: THE place for F# ( The forums here are a great resource. )

Here are some additional links you might find interesting:
Don Syme's Blog
Robert Pickering's Blog
Matthew Podwysocki's Blog
My F# Ant Colony Work

More F# At Code Camp Hartford

RickM — Sat, 16 Aug 2008 18:03:00 GMT

I am down in Bloomfield, CT today at Hartford CodeCamp which has been put on by the Connecticut .NET Developer's Group . I just gave a very similar version my talk on the 5th. The room was completely full and I was a bit weak and foggy from my recent...(read more)

Talkin Bout' F# - Presenting at the Western Mass .NET Users's Group

RickM — Tue, 05 Aug 2008 13:36:00 GMT

I'm going to be giving a presentation at the my local .NET User's group tonight. The goal of my talk will be to expose the audience to F# as well as some Functional Programming Ideas. Here's a basic rundown of what the talk is about (in order): - What...(read more)

10 Hours in F#: Exploring Concurrency Through An Ant Colony Simulation

RickM — Fri, 25 Apr 2008 19:33:00 GMT

Synopsis I gave an hour long talk today, here at Atalasoft, on Concurrency in F# . It featured some slides and a small ant colony simulation to demonstrate different kinds of threading. Overall, I liked developing in F# quite a bit; however, puzzling...(read more)