March, 2010

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.

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.

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.