For any of you that are aware of the newly updated Xamarin Web site, you may have seen the following:

Objective-C was ahead of its time 30 years ago. C# is ahead of its time today. Anything you can do in Objective-C or Java, you can do in C# with Xamarin—usually more succinctly and with fewer bugs.

What is also true is that F# is way ahead of its time, and you can produce even more succinct code with even fewer bugs than C#!

It also allows you to use C# in a Read Evaluate Print Loop - REPL. This is nothing new to F# and indeed lots of other languages have REPL’s too. One of the other benefits of ScriptCs is that it also integrates nicely with Nuget allowing you to use your favourite libraries quite easily. Finally there are Script Sacks which can be used to further reduce the amount of code you need to write when working with common frameworks.

What am I talking about here? Maybe it’s Monster Zero or King Ghidorah as it’s sometimes known. No it’s TPL Dataflow!

Yeah, yeah, I have a penchant for being over dramatic and writing quirky intros. This post is about TPL Dataflow otherwise known as TDF. I have blogged about this before in my TDF agent series but I thought it might be worth while returning to it while on the subject of monsters.

Lately on one of my projects I have been doing a lot of stream manipulation, and although I solved the problem quite easily using F# async workflows, there were other solutions available to help solve the problem. I could of used things like async await, TPL Dataflow(TDF), and Reactive Extensions (Rx). This is going to be a short post on using Rx with F#.

What is Edge.js?

Unless you live in a hole you have probably heard of node.js so I’ll not bother to explain what it is or what it does. An interesting project has come to light lately, namely Edge.js. The Edge.js project allows you to connect node.js with .Net.

The creator of Edge.js Tomasz Janczuk sums this up nicely:

An edge connects two nodes
This edge connects node.js with .NET

Currently Edge.js is only available on Windows but there is work underway to bring this to Mono, thus opening up the possibilities even further.

In this post weare going to look as async again, but from the perspective of F#.

Xamarin Evolve 2013

I was going to title this post as ‘Now for something completely different’ but felt that a little bit too Pythonesque, and when I thought about it a bit it isn’t really completely just slightly different, namely C# rather than my usual F# posts.

Right, enough of the waffling, this post is a little tour into the relatively unknown area of async on iOS. Xamarin announced the alpha preview of async await on March 11th this year (2013). There are a couple of blog post floating around on the net if you look around, Rodrigo Kumpera posted a small example here.

If I walk into my garage now and open up a toolbox, whats inside?

Here’s a quick selection:

• Ball-peen hammer
• Jointer plane
• 1/2 inch mortise chisel
• Soldering iron
• Set square
• Low angle block plane
• Torx screw drivers
• Hack saw
• Monkey wrench
• Pipe cutter

Notice it doesn’t just contain:

• A sledge hammer.

Different tools have different purposes, you wouldn’t use a hammer and try to cut down a tree, or use a chisel to hammer a nail.

In the last post I discussed an asynchronous version of the ManualResetEvent and as promised this time we will be looking at an asynchronous version of the AutoResetEvent. I’m using Stephen Toubs post as reference and we will be building a version that is functional in style that maps straight into asynchronous work flows without and conversion or adaptors.

What is an AutoResetEvent?

An AutoResetEvent can be described as a turnstile mechanism, it lets a single waiting person through before re-latching waiting for the next signal. This is opposed to a ManualResetEvent which functions like an ordinary gate. Calling Set opens the gate, allowing any number of threads that are waiting to be let through. Calling Reset closes the gate.

In this edition we are going to be doing a taste test, C# vs F#. Oh yeah, if you quickly glanced at the title you may have thought this was a recipe for black scones, as interesting and tasty as that may be, unfortunately its going to be finance related.

I recently presented a paper on the benefits of F#, part of this was a comparison of the famous Black-Scholes equation in both C# and F#. I was mainly going to be looking at code succinctness and the inherent suitability of the language for calculation based work, but there ended up being more to it than that.

I recently wrote an article for Developer Fusion on the changes in mindset required when moving from C# to F#.

The article has proved to be more more popular than I envisaged.  I think a lot of .Net developers are interested in F# but are unsure on the path to take when trying to accomplish this.  For me it was almost a leap of faith, I saw the potential benefits and just jumped right in.