Learning F# – Part 1

I decided to take some time out on Silverlight and have a play around with Microsoft’s new language F#, I’ll be making notes as I go along and post them here so maybe they’d help satisfy some of your curiosity too!

Disclaimer: I do not claim credit for the code examples and much of the contents here, these are mostly extracts from the book by Chris Smith, Programming F#: A comprehensive guide for writing simple code to solve complex problems. In fact, if you’re thinking of learning F# and like what you read here, you should buy the book yourself, it’s easy to read and the author has gone go great lengths to keep things simple and included a lot of code examples for you to try out yourself.

Before you start, you need to download F# from:


and install it for either VS2008 or VS2010 beta.

Hello, World

In VS2008, open a new project and choose F# Application, in Program.fs type in:

printfn “Hello, World”

Hit Ctrl+F5, and voila:

You might notice that your program worked without an explicit Main method.

Here’s a slightly more complex Hello, World to show off the syntax of F#:


The let keyword binds a name to a value, unlike most other programming languages, in F#, values are immutable by default (meaning they cannot be changed once initialized).


F# is also case-sensitive. The name of a variable can contain letters, numbers, underscore, or apostrophe (‘) and must begin with a letter or an underscore. However, you can enclose the value’s name with a pair of tickmarks in which case the name can contain any character except for tabs and newline:

let “this.Isn’t %A% good value Name$!#“ = DateTime.Now.ToString(“hh:mm tt”)

printfn “%s, %s at %s” greeting thing “this.Isn’t %A% good value Name$!#“

Other languages like C# use semicolons and curly braces to indicate when statements and blocks of code are complete, but it clutters the code.

In F#, whitespace (spaces and newlines) is significant. The F# compiler allows you to use whitespace to delimit code blocks. For example, anything indented more than the if keyword is considered to be in the body of the if statement. Because tab characters can indicate an unknown number of space characters, they are prohibited in F# code. You can configure the Visual Studio editor to automatically convert tab characters into spaces in Tools -> Options -> Text Editor -> F#.

The earlier code also demonstrated how F# can interoperate with existing .Net libraries:

let timeOfDay = DateTime.Now.ToString(“hh:mm tt”)

F# can take advantage of any .Net library by calling directly into it, conversely any code written in F# can be consumed by other .Net languages.


Like any language, F# allows you to comment your code. To declare a single line comment, use two slashes (//).

For larger comments that span multiple lines, you can use the multiline comments using (* and *) characters.

For F# applications written in Visual Studio, there is a third type of comments: an XML documentation comment. If a comment starting with three slashes (///) is placed above an identifier, Visual Studio will display the comment’s text when you hover over it:


F# Interactive

Visual Studio comes with a tool called F# Interactive or FSI. F# Interactive is a tool known as a REPL (read-evaluate-print loop), it accepts F# code, compiles and executes it, then prints the results. This allows you to quickly and easily experiment with F# code similar to how snippet editor allows you to do the same with C# code.

Once it’s open, it accepts F# code until you terminate the input with ;; and a newline, the code entered will be compiled and executed. After each code snippet is sent to FSI, for every name introduced you will see val <name> : type value, for example:

Notice when you don’t give a variable a name, FSI will simply call it ‘it‘.

FSI allows you to write code in Visual Studio editor which offers syntax highlighting and IntelliSense, but test your code in the FSI window. You can copy the entire code body from the example earlier and test the main method in FSI by calling it:

Managing F# Source Files

The F# language has some unique characteristics when it comes to managing projects with multiple source files. In F#, the order in which code files are compiled is significant.

You can only call into functions and classes defined earlier in the code file or in a separate code file compiled before the file where the function or class is used. If you rearrange the order of the source files, your program may no longer build!

The reason for this significance in compilation order is type inference, a topic to be covered later on.

F# source files are compiled in the order they are displayed in Visual Studio’s Solution Explorer, from top to bottom. You can rearrange the files by right-clicking and selecting Move Up or Move Down. The equivalent keyboard shortcuts are Alt+Up and Alt+Down, though these don’t seem to be working in VS2008 with Resharper, or maybe I just need to tweak my key mapping.

Buzzword Buster – AOP


Aspect Oriented Programming (AOP) is a programming paradigm where each application can focus on its primary functions and core concerns by encouraging greater modularity and increasing separation of cross-cutting concerns (such as logging and authentication).


In any real-world applications, when you’re writing code to address the problem domain (say, booking an order) you might need to address other concerns such as:

  • persistence – writing to the database for example
  • transaction handling – defining transaction scope and setting rollback strategy, etc.
  • security – user authentication for example
  • logging – for auditing and debugging

So effectively you’re mixing multiple domains with fine-grained intersections and likely to end up with:

  • tangled code – making it more difficult to work out what the code is doing to address the core concern
  • boilerplate code at every intersection point – introducing duplicated code and increasing the size of the code base and the blast radius of any change that are not related to the problem domain, e.g. changing the persistence media..

AOP aims to address these problems by separating cross-cutting concerns into single units called aspects, each aspect encapsulates behaviours that affect multiple classes into reusable modules.

Parting thoughts..

As far as I can think of, the only drawback of AOP is that you no longer see all the behaviours of your class when you open it and it requires knowledge of the whole system to know what else are happening under the cover. Which interestingly, is the flip side of the same coin because you employ AOP when you don’t want to deal with cross-cutting concerns all the time!

One of the ways to mitigate this problem is to build up a culture in your team and standardise how AOP is implemented so that everyone is on the same page and there are few surprises.


PostSharp provides a lightweight AOP framework for the .Net platform and is establishing itself as the de facto standard much like the way AspectJ has done for Java.

Good old days!

My good friend Raj sent me some pictures he took from Chinese new year 2006, and really brought back some nice memories from the days gone by!

As some of you may know, I performed on stage for Chinese new year in 2006 in Trafalgar Square, in the middle of the freezing cold in Feb! It was definitely one of the best experiences I ever had, the adrenalin rush of performing in front of thousands of people was simply amazing! So, to show you what I’m on about, here’s some pictures ;-)

63_430x330 CNY%20290106%20-%20%2814%29

CNY%20290106%20-%20%2820%29 DSC00032

DSC00033 DSC00036

100_0163030406 (2)

and don’t we all love a poser lol


Adoption problems with WPF

I was having an email conversation with a friend on WPF yesterday and he suggested putting it into a blog post after I went on and on for a bit (sorry Raj!).

Having spent some time learning Silverlight (which is a subset of WPF for the web, Microsoft’s equivalent of Flash) I have really come to like the new programming model in WPF and how easily it allows you to do things that were simply impossible to do in WinForms (ever tried to put a rounded corner to a rectangle anyone?).

To those not familiar with WPF, it’s powered by DirectX so you get hardware acceleration and can use features such as transparency, gradients and transformations. Its programming model enables clear separation of the UI from business logics because you now have to build your UI using a declarative language – XAML (Extensible Application Markup Language).

The event model has also been revamped and it’s now possible to ‘route’ an event so it originates from one element but is raised by another. WPF supports several types of routed events, but Silverlight only allows bubbled events which cascades up the containment hierarchy from deeply nested element to its containers.

Why is Declarative UI better?

Whilst declarative UI is something of a shock to the system to most of us (web developers not included!) it actually makes perfect sense because it helps solve one of the biggest problems in UI development – business logic embedded in UI.

A declarative UI makes it harder to write business logic into the UI because you’re writing less code. However, it’s not about separation of tiers, but separation of concerns, so when you find problems there is a smaller blast radius! Which again, all comes down to loose coupling – the same thing people are trying to achieve with IoC and Dependency Inversion from a dependency point of view.

So all’s well with WPF and industry veterans are all raving about it (there’s a number of shows on DotNetRocks alone which covers WPF and Declarative UI) so why is there still a distinct lack of real-world apps out there? Besides the odd project on CodePlex like Family Show and Scott Hanselman’s BabySmash, I haven’t found too many examples out there (it’s a shame Photology‘s dead.. :-( )


I think there are two main reasons why a lot of people are still not adopting WPF, neither has anything to do with the technology itself which is like a fancy new drug which makes you never want to go back! And there are plenty of industry support both in terms of third party support (well known UI controls producers like teleriks, infragistics already offer numerous UI packages for WPF and Silverlight) and backing from the industry veterans.

1. it’s still fairly young

Having only made it into the core .Net platform since .Net 3.0 (nov 2006) it is still fairly new to most developers considering that most people are still happy using .Net 2.0 (I know this is definitely true in the banking/enterprise world!) which equates to:

  • a lack of existing expertise in the field, making it hard for would-be adopters because it adds to the cost of adoption in time and expense regardless of their strategy to acquire these expertise, i.e. new recruit vs. training existing staffs
  • an additional risk with adopting WPF because you have to first migrate your platform to .Net 3.0, which, should be minimal because it’s really just an add-on to the .Net 2.0 framework. But then again, “why fix what’s not broken?”

2. it’s only a viable option for new developments

Because WPF introduces a completely new set of technologies and a new programming model to boot, it’ll require significant time and effort to convert an existing UI application. This means WPF is only worth considering for new developments.

The future:

As with all things Microsoft, there’s a strong focus on enterprise users and I’m sure their representatives would continue to make a push for their partners to adopt WPF and dare I say once they decide to jump on board MS would have a problem stopping them from coming back for more! Yup, WPF is that good!

With the .Net platform going strong as ever (mentioned in 44% of developer jobs posted in the UK in the last 6 months), the universal adoption of WPF as the de facto standard for developing UI application should only be a matter of time. Given the risk-adverse nature of large enterprises (who, given their size and financial muscles, have more say on technology trends than anyone else), it’s no surprise to me that WPF has not really caught on, but as more and more enterprises jump on the WPF bandwagon they’ll in turn increase the size of the talent pool available to others and really set the ball rolling.

Further reading:


Prism: patterns & practices Composite Application Guidance for WPF and Silverlight site

Imperative vs. Declarative Languages

Following my previous post on multi-language (polyglot) and multi-paradigm (poly-paradigm) development, I thought I’d continue on the same thread for a little and do some comparisons on some of the popular types of programming languages.


An imperative programming language such as C# or Java allows you to specify step-by-step how a problem should be solved using a series of statements which change a program’s state. It’s important to remember that whilst Object Oriented Programming is how we are all taught to do imperative programming these days, it’s not the only way – C and other procedural languages are also imperative languages.

A declarative programming language on the other hand, is a higher level programming language which allows you to express what you want without specifying how to get it. SQL is probably the most widely used declarative language today and in SQL you don’t tell the query analyzer how to go about fetching the data, you just state what data you want to retrieve and it takes care of the rest. It’s also worth nothing that

How they compare:

The benefit of declarative language is that it separates the process of stating a problem from the process of solving it. It’s essentially an extension of design by contract where producers of the declarative input describe what they need and how they need it, allowing producers of the declarative program to determine the best way to get it.

Approximating this in an imperative language is possible because at heart, everything is imperative. The challenge in doing so is that an imperative program operating on declarative input must be prepared to check pre and post conditions and have a plan to deal with every eventuality!

Declarative languages allows for greater extensibility, agility and productivity. Think how quickly you can create a table, input some data and then get the data back in some form or another in SQL and then imagine the time and effort it’d require if you were to implement these in C#.

However, as a user of a declarative language, you have limited or no control over how your inputs are dealt with and therefore have no option but to mitigate the impact of any imperfections/bugs in the underlying language and rely on the providers of the declarative language to address the issues.