My two cents on F#

There is so much I could say about lots of interesting Silverlight and WPF projects but I’m not allowed to (you know, non-disclosure agreements, hyper-secret projects and whatnot), so let me write a few words about something which I’ve had in the back on my noodle now for months.

In the early days of .Net a lot of developers (yours included) moved from Visual Basic to VB.Net to discover that it was quite easy since the syntax was so similar. It would take you a while then to discover that though the syntax is similar the stuff under the cover was quite different, more powerful and lots of things were possible you could only dream of before. Eventually later on everyone would move from VB.Net to C# because C# was the development language for the ‘real’ ones and VB.Net more a Playmobil language. The fact that Microsoft clearly always has pushed C# first and the documentation was mostly giving examples in C# also helped of course. For the record, I remember fun forum comments like ‘…I’ll never move to .Net, ever. I have invested years in Visual Basic and will stick…‘. Recently I also came across comments similar to this with regards to F#:’…what is this let-keyword in F#, it’s going backwards to Visual Basic syntax. Will never use F#, ever…’. Some people say the same about ASP.Net MVC in fact, it’s a mixture of HTML and .Net code in one file and, hence, very much like the ASP code before ASP.Net came along (you have to be 30+ however to remember the days of ASP before .Net).

Anyway, so now we have F# on stage and everybody (that is 95% of the professional devs) is wondering: is this what we were waiting for? The comments regarding the F# syntax remind me of the VB-guys ten years ago cursing .Net because it’s typical when paradigm shifts occur in the industry. A characteristic of being human is that we adapt to everything but it doesn’t mean we do it with ease. The point is, however, that language syntax is just the top of the iceberg and the real revolution is going on underneath, the conceptual shift is what matters rather than just the way it’s written. In the margin of these remarks I have to admit I sometimes have difficulties to understand why certain things are so difficult to adopt by developers. For example, something close to my heart is diagramming and workflow and there is a clear explosion of visual programming these days (beside but in support of declarative programming). Workflow Foundation has been around for six years or so but for some reason devs don’t really like it. I wonder if the new diagramming gadgets (UML, flowcharts etc.) inside Visual Studio 2010 will incite devs to think more visually now? A lot of people find diagrams more confusing than enlightening. I fear the same can be said about F#, I fear a lot of devs don’t/won’t like it. For the following reasons:

• the learning curve is horrendous, you can hear your brain cracking, there is a bewildering amount of concepts. Computation expressions and quotations are tough things to grasp. Great fun, but tough.
• there is something intrinsically mathematical about the F# concepts (I even saw references to functors and endomorphisms in some introductory books!)
• Visual Studio pretends to have ‘Visual F#’ but it’s far from being ‘visual’ like C#. This is not the fault of Visual Studio, rather F#. How to browse through F# code? Because classes, functions and types can be defined inline, how would one jump into the right spot in the code? You don’t have something like ‘go to definition’ and tools like ReSharper and JustCode will for sure have a rough time to give support for F#. While C# enforces some kind of structure in F# you can organize things rather arbitrarily with files, namespaces, modules, classes, types and functions. The flexibility of the language demands more rigour from the developer. Also, things like code comments and the interface hierarchies tend to give you hypnotic feelings.
• the average developer doesn’t need the raw power of F# (and the underlying mechanisms) and will think ‘well, I don’t miss anything in C#, why should I try to do something in another language I can do now?’

C# has grown so much in ten years time that most developers will admit that the need for some feature or syntax construct never occurred to him/her. This then, re-affirms what I said above; the real shift is not the language but what’s underneath. F# is just a way to give you access to certain things which are either not possible of more difficult in C#:

• the whole multi-core, parallel programming world. The intricacies of multi-threading of parallelism are so much easier in F#
• language oriented programming and DSL developments. If you have ever written a lexer, parser and adjoint stuff you will blink a few time how much easier it is to develop your own ‘language’ in F#. I remember writing a Logo (Turtle graphics) language in C# which took me a few thousand line of code. Nowadays you write a logo language under 400 lines in F#!
• mathematical structures and algorithmics is easier and more natural in F#. For programmers using Wolfram’s Mathematica F# will be very recognizable, the idea of higher-order functions and using functions as data is a bit alien in C# in this respect.

Now, the question is obviously; how many programmers need this? Concerning the mathematical advantages I suppose it will always be a niche in the community. Parallel algorithms and DSL’s on the other hand, I think we’ll see a growth in the next ten years and it’s in this area that F# will stand out. Note, I’d be happy to see fancy Silverlight stuff written in F# but think about the developer profile you’d need for this: someone with a bit of design skills, fluent in math-concepts and F# abstractions, knowledgeable in Silverlight….hmmm, unlikely to find someone like this (I’ll consider myself as the exception that proves the rule).

To conclude, let me give you some material or a path which could be helpful if you want to pierce through the unfathomable F# world:

• the Escher drawing reproduced in F# really thrilled me and it’s a typical example of something which is easy to do in F# but would take you far away using C#
• a Logo interpeter in less than 400 lines is such a delight for the mind. If you want to see the power of language oriented programming then this is a great start.
• “Programming F#” by Chris Smith is supposed to be an introductory book and it does well but don’t be fooled by the subtitle ‘…writing simple code to solve complex problems…’. Simple code is a relative statement.
• “Real-world functional programming” is a great book because it puts C# and F# syntax side-by-side. Read it after you read ‘Programming F#’. The chapter on a fluent animation library particularly interested me because of our iSee library. I guess I could rewrite iSee in F# now.
• “Expert F#” is, well, for experts. Besides many other good things it gives you more professional advise regarding structuring your code, packaging and effective tips if you wish to have interop with other languages.
• Spend every day an hour in the F# interactive window of Visual Studio. I think (much like maths in fact) at some point there is faint difference between ‘understanding’ and ‘getting used to’. In the end you stop wondering ‘why?’ and you just use the concepts and syntax.

In case somehow you didn’t get the point; start learning F#. It’s an intellectual challenge but refreshing and a good investment, it’s just the beginning of new era.