05
Jul 10

In Retrospect: A .NET Rocks! F# Panel

Intense Discussion at the .NET Rocks! F# Panel

From left to right: Carl Franklin, Richard Campbell, Talbott Crowell, Richard Minerich and Richard Hale Shaw. (Photo taken by Ken Pespisa)

Just this past May I appeared on the .NET Rocks! radio show in a panel with Talbott Crowell and Richard Hale Shaw.   The show started with a short intro in which each of us discussed something we though was great about F#.  This was followed by an in-depth Q&A session with Carl Franklin and Richard Campbell.

Overall, the show went extremely well.  Talking with people afterward, it turned out that many who had previously been on the fence were now very excited to give F# a go.  One of the attendees, Ken Pespisa, wrote on his experience and I feel as though it sums up the feelings of many.  Even Bill and Lou from Atalasoft were moved to give F# a harder look.

It was a privilege and a pleasure to be on Carl and Richard’s show.   In only an hour’s time, they were able to showcase the entire breadth of common F# questions in a very concrete and intelligent way.   This well formulated Q&A style made for an exceptionally engaging and educational show.  I hope very much to work with them again at some point in the future.


21
Jun 10

Love the Lambda

Just this past Saturday I gave a completely new talk at the third Code Camp Hartford.  This talk was inspired by a previous mid-talk realization: most C# programmers (and almost the entirety of my audience) have never written a single lambda expression or anonymous delegate.  From this I further realized that I’d never be able to teach F# to those who are completely unfamiliar with the concept of functions as first class language constructs.  First, this idea and its ramifications would have to be taught.

lovethelambda

So the idea for Love the Lambda was born:  I would demonstrate both the usefulness and sheer novelty of first class functions and do so simultaneously in C# and F#.  More than that, I would use the opportunity as a kind of F# omnibus.

Here was the general game plan (as written by me imagining the thoughts of some intelligent, but yet uninformed, person sitting in the audience):

  1. First class functions sure are great!
    1. Oh man, and with closures they are even better!
    2. I’m going to use this stuff in C# all of the time!
    3. Wow, that F# code looks so much cleaner than the C#!
  2. Now check out what you can do with partial application!
    1. Oh wow, this pipelining stuff puts LINQ to shame…
    2. …and function composition is amazing!
    3. Hey, wait a minute, you can’t do this in C#…. :(
  3. Good thing F# integrates really nicely with C#.  I can pull it right into our existing projects!
    1. Plus F# has tons of other amazing stuff, I’m going to start playing with it tomorrow!
    2. I can’t believe how much less code I need to write when I use these features!
    3. F#, where have you been all my life?!

All that said, the first iteration of this talk worked out a bit different than my initial vision.  This was mostly due to running out of time when constructing the presentation.  I still think the ideas I was trying to convey are in there but not as sharp and as easy to grasp as I’d like.

Still,  the attendees seemed really happy with the talk and the review forms agreed.  Everyone left my talk loving the lambda at least a little bit more.

If you are interested, I’d encourage you to download my slides and code samples.  Also, I’m always interested in hearing about how I might improve my talks, or further spread my love of functional programming.  Please don’t hesitate to contact me if you want to share ideas.


29
Apr 10

The Ted Neward F# Folding Challenge

My friend, and fellow Professional F# 2.0 author, Ted Neward recently challenged me to a bit of a Code Kata.   Take a list of numbers and compress it in a particular simple way but without any mutable state.  What makes this problem interesting is that a tech interviewer mentioned that that he hadn’t seen a functional solution to this problem.  I also wanted to share this because I think it’s a great example of how to convert an imperative loop into a functional fold.

So, on to the problem.

Given a set of numbers like [4; 5; 5; 5; 3; 3], compress it to be an alternating list of  counts and numbers.

For example, the solution for [4; 5; 5; 5; 3; 3] would be [1; 4; 3; 5; 2; 3], as the list consists of one four, then three fives and finally two threes.  Ordering counts as the initial list must be reconstructable from the compressed list.  The answer to [4; 5; 4] would be [1; 4; 1; 5; 1; 4]

The imperative solution is rather simple, we use three variables outside of a loop:  a last value, a count and an accumulator list.

let clImp list =
    let mutable value = 0
    let mutable count = 0
    let output = new System.Collections.Generic.List<_>()
    for element in list do
        if element <> value && count > 0 then
            output.Add(count)
            output.Add(value)
            count <- 0
        value <- element
        count <- count + 1
    if count > 0 then
        output.Add(count)
        output.Add(value)
    output

Using the normal .NET mutable list type, this version works efficiently and produces the output we expect.

> let compressed = clImp numbers
   Seq.iter (fun e -> printf "%i " e) compressed;;

1 4 3 5 2 3

How might we convert this to a functional style?  In this example, the general type of operation could be thought of as the gradual building of a data structure while walking over a list.  F# just happens to have a list processing function designed just for this task.  This function is named fold and it is one of the most useful constructs in any functional programmer’s tool chest.

let clFold input =
    let (count, value, output) =
        List.fold
            (fun (count, value, output) element ->
                if element <> value && count > 0 then
                    1, element, output @ [count; value]
                else
                    count + 1, element, output)
            (0 , 0, [])
            input
    output @ [count; value]

Here, we are doing almost exactly the same thing as in the imperative version but with a fold instead of a loop.   The secret is that instead of putting variables outside of our loop and changing them with mutation, we have added them as elements in our accumulator tuple.  In this way, the values are updated when each element is visited with no mutation.

However, there is one serious problem with this example.  Appending to the end of a linked list requires recreating every node in that list.  This will make our algorithm grow exponentially slower approximately in proportion to the length of the input list.  To correct this we have two choices: do a head append with a normal fold and reverse the list when we are done, or use foldBack.  The foldBack version is a rather small step from here and looks much nicer, so let’s go in that direction.

let clFoldBack input =
    let (count, value, output) =
        List.foldBack
            (fun element (count, value, output) ->
                if element <> value && count > 0 then
                    1, element, [count; value] @ output
                else
                    count + 1, element, output)
            input
            (0, 0, [])
    [count; value] @ output

There are only two real changes here.  First, we are using foldBack instead of fold.  This change causes some argument reordering.  Second, we are appending to the head of the output list instead of the tail.  It works well, is rather fast and is easy to understand if you are comfortable with folds.

However, there is a bit of a dirty secret here.  Under the hood foldBack converts its input list into an array when the size is large.  As arrays have linear element look up time, they can be walked through backwards very quickly.  Does this make the solution not functional?  You’d never know unless you looked at the underlying implementation.  Anyway, however  you want to label it,  it sure works well.

If you liked this example and want to see more check out our book, Professional F# 2.0.   It’s just about to be done.  In fact, I better get back to editing.


10
Apr 10

The Repeating History of Closed Platforms

I was one of the many that loved the iPhone AppStore platform.  Consumers marveled at how we could easily buy any application we might want, vetted with a nice rating system.   Developers were shocked at the ease with which it seemed possible to monetize on simple applications.   The only downside seemed to be the occasional political or ambiguous AppStore rejection.

Looking back now, the recent changes to Apple’s developer terms of service are not so much of a shock.  They are just the continuation of Apple’s past policies.  It’s the same pattern of gradual erosion of Consumer and Maker rights we see on any platform over time.  If you look beyond the scope of software and include any marketable good, you see a long history of this pattern repeated over and over.  Consider cable television and the music industry.

At first, closed platforms are great.  They get the both the Consumer and the Maker what they need as fast and easily as possible, because that’s the platform provider’s job.  The platform providers are competing against each other and so must cater to both the Consumer and the Maker.  However, this soon changes.

Over time, one of two things happen, both bad:  Either a single provider wins out and gains a monopoly, or platform providers conspire together.  The platform then becomes a weapon in the corporate war chest.  The ultimate end is control over both the Makers and the Consumers until a new revolutionary platform emerges, catches the old players off guard and the process begins again.

The only escape from this pattern seems to be the open source community, a community in which the Makers have taken complete control by keeping out profit-seeking Providers.  However, this seems to have the unfortunate side effect of alienating Consumers.  Perhaps this can be remedied by a benevolent Platform Provider, but I’m not holding my breath.


14
Mar 10

Speaking Online at the Community For F#

In a moment of rash confidence, and possibly food-coma induced delirium, late last week I volunteered to give my F# for Testing and Analysis presentation for the online Community for F#.  The online talk will be on Tuesday, March 16th 2010 at 1PM EST.

The reason I am now feeling a bit of trepidation is that I agreed to give this talk without doing any research on who had recently spoken.   To my surprise I’ve now discovered that the very prolific Steffen Forkmann was the last to speak, on his own projects, which also constitute a large portion of this talk.   Of course, Steffen can cover these topics much better than I’d ever be able to.  In fact, now that I know he gives talks, I’m going to have to try and capture some of his time for our New England F# User Group.

So now, I’m in the process of trying to come up with additional interesting material. I’m thinking something along the lines of…

Of course, this will all be sprinkled liberally with reasons why F# is so fantastic for this particular type of application.

However, time is short and one hour of good presentation takes roughly 8 hours of work to build and refine.  That’s not including practice time at all.  I’m sure I’ll be able to pull together something interesting for the group but I’ll hope you’ll all be forgiving if I frequently need to reference my notes.

Post-Talk Update

Despite a two day delay due to technical issues and a few problems I had with the Live Meeting interface, the presentation went well.  Skip to 9 minutes into the video to avoid most of my fumbling with the software controls.

Links: Slides, code and video.


14
Mar 10

Code Bubbles and the Keyboard

I was catching up on reading one of my favorite blogs today, Lambda the Ultimate, and was not disappointed in the least.  At the top of the list sat Code Bubbles, a whole new take on the IDE.  Code Bubbles shocked me because it’s visually manifest much of what I had in mind when I wrote almost two years ago on leaving flat files behind.  That said, I think Code Bubbles has a long way to go before it’s a reasonable platform to choose for active development.

From a high-level point of view, Code Bubbles is a modern programmer’s dream.  With organized tasks it would be much easier keep your mind focused on what you are trying to accomplish.  With code represented outside of its restrictive flat file format, you would need not repeatedly wade through piles of irrelevant cruft to reach the small pieces of code you need to change or consider.  Even the integration with bug tracking and email looks quite promising.

However, the actual process of using Code Bubbles looks to be an experienced programmer’s worst nightmare.  To be tied so extensively to the mouse would mean we all would need to move to one handed keyboards.  To organize everything by drag and drop on the screen would mean we would end up spending much of our time organizing the layout of code on our screen instead of its actual contents.  Also, due to the nature of the scroll-and-select interface, finding what you need in a large project could quickly become quite annoying.

Even at the most basic level, just reaching for the mouse has a huge impact on programmer performance.  Many think of it much like a cache miss.

The good news is that none of these problems seem insurmountable.  An intelligent keyboard shortcut scheme could be invented.   A snap-in grid layout would speed drag and drop, although automatic layout needs to happen eventually.  Perhaps the scroll and select could be made less frustrating with a textbox filter (ala Firefox config).

An even more far reaching solution to this mousyness might be something like NDepend style querying.  Even just Windows 7-style keyword search would be a huge boon.  The IDE practically screams for keyboard queries.

That said, I for one am looking forward to the day I can use Code Bubbles (or something similar) as a mature and robust IDE.  With the monstrous computing beasts we have under our desks, the layout of on disk or in memory should not limit the ways in which we are able to interact with our code.

Update: Additional commentary is available on programming reddit.


06
Mar 10

Abstract Thoughts about F# Abstractions

My recent work on Professional F# 2.0 has left me thinking a lot about the nature of abstractions.

In computation, different types of abstraction are trade-offs between clarity and freedom in different areas.   As you move away from the machine architecture, you lose the freedom to push bits around in whichever way you might want.  In the case of garbage collection, this means you might not be able to hand optimize your memory usage.  For managed code, this might mean you can no longer hand optimize your code to a CPU-instruction level.  With even a small degree of abstraction, your choices are cut down to only a small subset of what was previously possible.

In exchange for this loss, you get to think about problems in a constrained way.  This means you can make more valid assumptions about what is going on.  You can express ideas cleanly, without additionally expressing the machine’s management of the resources involved in those ideas.  You can manage less and express more.

The benefit of these constraints goes beyond just what you personally have to worry about while programming.  Some types of abstraction, such as function signature standardization or managed assemblies, enable post-compilation binary compatibility.  Other types of abstraction, such as immutability, allow the compiler to do high level optimizations beyond what was previously possible.

So, while you might be able to do everything with the JMP instruction that you can with C#’s foreach, it takes much more effort to express the same idea with JMP, and a lot more can go wrong.  Similarly, while you may be able to express all of the ideas in C# that you can in F#, it takes much more effort to express those same ideas in C#, and a lot more can go wrong.

And who knows… In the future, we F# users might even get some sweet optimizations out of the deal.


26
Feb 10

Speaking at the Boston .NET User Group

I’ll be giving my widely acclaimed “F# and You!” presentation at the Boston .NET User Group on Wednesday March 10th.   There will be chills, thrills and spills as programmers watch their parallelism and asynchrony problems melt away.  Strap on your recursion goggles for in-your-face .NET functional programming action.

Slides and samples will be available here after the talk.


21
Feb 10

On Finding Mentors Through Issuing Challenges

I hear it again and again: the key to a successful career is in finding good mentors. According to the Women in Tech panel I attended at PDC, lack of female mentors is the number one reasons for our gender dichotomy in tech.  I’ve also seen much of my success through mentoring. Were it not for Steve Hawley and Lou Franco at Atalasoft, the paths to accomplishing things like applying for a patent or speaking at an event would have continued to remain a mystery.  Once something has been shown possible it becomes much more accessible.

So, how to find mentors?  As with anything people related, it’s all about generating good feelings. Consider two ways to accomplish this:  Making a personal connection and offering a defeatable challenge.

Finding Mentors through Friendship

Make friends with someone more knowledgeable than you and of course that person will want to share their knowledge with you. It’s always good to invest time in getting to know those who are more experienced. This can be accomplished with something as simple as asking someone if they’d like to go get lunch. This is the traditional way to find a mentor. It might even be considered common knowledge.

However, as you accomplish more and more in your career, the mentors you need are busier and busier people and thus harder and harder to gain access to. How might you incentivize them to spend time on your education?

Finding Mentors through Challenge

This one only occurred to me recently and was the impetus for this post.  The idea was inspired by the recent exchange of posts by Chris Smith and Brian McNamara on the F# Team. Through a series of technically escalating blog posts each out-optimized the other.  What better way is there to get someone to spend a lot of time on teaching you than to challenge them on a topic they know well? Nothing motivates like a challenge to the ego.

Did you ever get in a fight with someone in grade school and become fast friends after? I know it happened to me. When the victor reaches out his hand in friendship to the bested, acknowledging their strength in offering or standing to face a challenge, a strong bond can be created. The victor is now the mentor, the bested the student.

The big risk in a professional setting is in how things work out afterward. If things get too intense your relationship might be damaged. I believe this risk can be measured in terms of the work environment and how used to conflict the members are. If a large amount of tension was a allowed to build up before the challenge, people are likely to take the challenge personally. However, if things have been kept playful with a small amount of constant challenge, escalating is much less likely to have any repercussions.


14
Feb 10

Heading to the 2010 Microsoft MVP Summit

Tomorrow, at the ungodly hour of 6:00am, I will be boarding a plane headed to Seattle for the 2010 Microsoft MVP Summit.   This is my first year as a MVP and, like becoming part of any new ecosystem, it comes with a mix of excitement, anticipation and trepidation.   It was easy to feel like a rock star at PDC but the MVP Summit is essentially the Microsoft Ecosystem’s rock star conference.   I’m sure to meet many people with experience and wisdom far beyond mine and who also are able to articulate it well.

I think a reasonable approach is to meet as many of these people as possible and learn all I can.   As one my favorite quotes goes:

“Employ your time in improving yourself by other people’s writings, so that you shall gain easily what others have labored hard for.”
– Socrates

Although, it is my experience that reading is a poor substitute for discussion.