F# – In the Enterprise – I

This will be a series of posts on how-to use F# in the enterprise. I will strictly reduce this post to Windows based enterprise apps and it is not a debate about using F# over C#, it is more using Functional programming over pure OOP, And the ways in which we can use F# in different domains. Below are some common questions that you would see people asking around,

• Who and how is F# being used in Enterprise
• The tooling is not that good for Windows Forms / WPF platforms
• What impact does this make in developing apps, Does FP reduces the time and effort that you put in?

We will also take a look at how F# can be used in all these different thick client application platforms that we normally use. And also, how and when F# can be used in these application platforms.

Windows Forms Client Apps

Most day-to-day work by WF programmers can be categorized as below,

Work is mostly with UI design using Visual Studio designer and develop apps real quick with minimal code behind. The DB layer also involves minimal code as the apps would normally use LINQ / DataSet designer to generate the middle layer.

Using F# right now with minimal designer support would be a heck lot of problems. There would be too much of code to write the connection between the UI and designer. This may be lot of work to get all the tooling support up and running in Visual Studio. May be we can expect this in VS2012 or future.

There are other kinds of apps in which it requires more technical analysis based on the problem domain. Consider writing apps for 3D, high-frequency stock trading, complex measurement units, high-level data-structures for charting etc., For these domains where you find the complexity needs to be addressed in a more concrete manner, F# is the right tool to use. As F# brings in more functional way of writing code, and easy abstraction over OOP to use with other languages.

Points to take from this,

• Don’t use direct F# code if it is heavily relying on UI + DataBase. Unless you really want to take the pain of using it.
• If you find a complex problem domain, then try identifying the complexity in it and see if F# can really help. To make this decision, You need to know how F# can be used, It is not a decision to be made by someone who is learning F# or not knowing the language.
• Always build an OOP abstraction over F# code so it can be easily used with other languages (C# or VB.NET).

WPF Client Apps

WPF provides a new UX platform running on latest Windows OS. It’s core fundamental UX works with separation of UI code in XAML (a derivation of XML) and the Model provided to the UI. In 2005, John Gossman, currently one of the WPF and Silverlight Architects at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog. MVVM is identical to Fowler’s Presentation Model, in that both patterns feature an abstraction of a View, which contains a View’s state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF to simplify the creation of user interfaces. In that sense, I consider MVVM to be a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms.

F# fits very nicely when using MVVM pattern of development in WPF applications. Since most WPF developers prefer using MVVM as a pattern when developing WPF apps, it is really easy to use F# as the first-level language to build a full-fledged WPF app.

Of course, some developers may use heavy designer generated WPF app, but there is a difference in the way WPF designer works compared to Windows Forms. So once the WPF form gets designed, we can use pluggable F# code that can simply work out easily.

We will look into creating F# based WPF apps in the next post, and understand the small steps that we need to change to make it work.