Strangelights

As Don Syme points out in his piece on asynchronous workflows, they are not about getting the whole of concurrency right but rather about getting asynchronous I/O.  I think that to fully appreciate the beauty of asynchronous workflows one must understand the ugliness of what it’s like to do asynchronous I/O without them. I think this may be true for many areas of software development,  hell even good old C looks great if you’ve been forced to spend some time assembler, and I guess Joel and his law of “leaky abstractions” is saying something along a similar lines. So I guess the aim of this article is to make you think that workflows are great by show you the “assembler” of asynchronous programming, or at least the asynchronous I/O part of it.

Took advantage of the nice weather and went for a long cycle today, we came across quite a few chestnut trees and could help taking advantage of this free food. I think we got over 3 KG in the end

So I was going to start this series with an over of concurrency options on the .NET framework, but after playing F# asynchronous workflows, I decided to blog about them as they just too exciting to keep quiet about. Maybe I’ll spin back at the end of the series and do a summary of other options at the end of the series.

There will be two F# presentations at TechEd Europe this year, one by Don Syme on concurrent programming in F#. See the full abstract below for more details

[Update 05-09_2007: minor change to both source and binary release to fix F# interactive intergration, if you download a version before this date please redownload]

In part one we build a couple of simple frameworks that allow the programmer to specify that a value should be cached until one of its dependencies changed. I wanted to put these frameworks though their paces in a semi realistic environment.

I recently started working on the F# integration with #Develop. #Develop is a free and open source IDE base that in many respects is very similar to Visual Studio. I actually found getting the basic integration going fairly easy, I have something that allows you to edit text files and build them. But as there’s not yet any colouring or auto-completion there no signification advantage over using that to any other text editor, so I’m not going to release it just yet, but watch this space.

I had an interesting exchange of emails with a reader recently. They wanted to be able to execute a function and cache the result and revaluate the function only when one of the values in depends on changes. It’s a common enough problem I guess, but one that’s surprisingly tricky to get right. This is because when you evaluate a function it’s difficult to know what it depends on and therefore difficult to know when the results of the evaluation become dirty.

As promisted on yesterdays blog post you can listen to me talking about F# on Hansel Minutes:
http://hanselminutes.com/default.aspx?showID=94

You may also want to take a look at this accompanying blog post about what we talked about on the show:

When I was doing my A-levels way back in 1997 I often used to stay up late to listen to the Mark Radcliff Show in its grave yard shift phase on Radio 1. One catch phrase that does seem to be completely covered in the catch phrase guide is a “Another Quality Radio Item” although in later versions of the show this was shorten to “Quality Item” and used to refer to any feature on the show, I believe its origins came from when Mark and Lard would invite some guest on the show and they would proceed to have conversion about something very visual, realising the listener had no frame of reference they would stop themselves and say “Another Quality Radio Item” and then often carry on talking whatever they were talking about.