Real World F#: Part One

i’ve been playing with f# on and off for about one year, but only recently i was able to complete a few “real world” projects. i was so impressed that i decided to share my experience. in this two-part series i will talk about two very different projects to give you an idea of how wide the spectrum of applications is where f# feels right at home.

the first project

the first project is named velosizer. you can check it out here (i may release it as open source but i’m still undecided on what to do with it). i assume you are not a cycling geek so i’ll spare you the details, but in short this application computes the bike setup given your position and the frame geometry. if you’re interested there’s a detailed description on the application page. surprisingly enough, i’ve never found anything that does this very thing (except for full blown and expensive cads), so i decided to write it myself.

the application is built in silverlight: the xaml frontend is basically a glorified input form. it’s not particularly complex, some details are more complicated than it may look at first sight, but still there’s nothing extraordinary. i took a rather standard approach and employed the mvvm pattern (using mvvm-light ) for a clear separation of concerns. the view model is c# while the model –where the interesting stuff happens– is written in f#.

solving this particular problem does not require very complicated mathematics, but involves a large number of geometrical operations (trigonometry and the likes). without abstracting and hiding away all the math, the solution quickly becomes a nightmare that spirals out of control (don’t ask how i know). for this reason i’ve implemented a simple 2d cad engine that sits at the application core.

how it went

here are some things i noticed while using f# in a “real” project for the first time.

units of measure

f#’s support for units of measures built straight into the type system has been very helpful to avoid stupid errors like mixing degrees with radians with millimeters, etc. it is really a plus when dealing with physical dimensions.

conciseness

the language syntax is very light and unobtrusive, which makes it ideal to write mathematically-oriented code. the main benefit to me has been that the math stands out clearly, without parenthesis, type annotations or artifacts that make things harder to read. also writing the code is a joy: you can really focus on the reasoning and almost forget that you are actually programming. in fact translating the equations written on paper to code is almost copy & paste.

testability

i heartily agree with richard minerich when he says that testing does not replace a strong, theoretically-validated model . it’s the very same reason that pushed me to build most of this application’s engine on paper before writing a line of code. however i still make (lots of) mistakes when implementing a model –regardless of how correct it is– so i feel safer with the additional support of a solid testing framework.
the nature of functional programming makes it an ideal target for unit tests. short, side-effects free functions are a joy to test. result: it has been very easy to create a nice safety net in form of an nunit project.
i must admit i would probably have written this library more or less using the same style in c#, but in functional programming this is the default .

interoperatibily with c#/gui

this is somewhat of a sore point. i don’t know if it is due to my lack of experience (likely) or the nature of a gui-driven application, but i’ve ended up with many mutable (and not very idiomatic in general) classes, for two main reasons:

• i had to persist the business objects (using the sterling nosql database) and all the serializers for silverlight need public setters as they are not allowed to use reflection.
• with mvvm, each view is bound to its respective view model, which is nothing more than a wrapper around its respective business object defined in the model (f#).
  now when for instance the user changes a value in a textbox, the new value is propagated to the view model, which in turns propagates it to the model. you can tell it’s not very practical to create a new instance of the model every time a value changes, so immutable objects do not adapt so well to the situation.

this means that the business objects are very c#-like. they still benefit from the lighter syntax, type inference, etc…, but they don’t fully leverage the power of the language. fortunately the “application brain” does not suffer much from this.

is this due to mvvm, xaml and in general gui patterns being oriented towards the object-oriented paradigm? i don’t know. i’ve heard of a gui framework specifically written for f#, but i don’t know much more.
i would be very interested to hear your opinion on this subject.

note: as stephen points out, keeping the model immutable may not be so much of a problem. i’ll give it a try.

guidance and community support

the f# community is still small, but it more than makes up for it in quality. the active users on stackoverflow and other sites are extremely competent. it’s rare to get bogus answers or to get stuck on a problem for long.
what i’ve found difficult though is getting guidance. i often ask myself if my code is well written or a pile of junk. i suppose the only solution is to refine my own sense by reading other people’s code.

intellisense

visual studio’s intellisense for c# is spectacular and has made us very lazy. f# support is much better than it was at the beginning, but it’s still not up to the same level of c#. in the end though it’s only lacking a few details like parameter names or support for the pipeline operator –the next release already includes some improvements in this area.

debugging

setting breakpoints and watching state change is not simple in functional code because (usually) there is no state . if you debug a lot, this may be a bit unsettling at first, but then you realize it is not so much of a drawback. it is a benefit in fact. breakpoints are evil: building a half-working solution, running it through breakpoints and tune it until the result matches what you expect is very close to the definitions of cargo-cult programming / programming by coincidence .
it is my opinion that functional programming makes you think more and write/edit/debug less . i believe this has made me a better developer because i now tend to stop, think about the solution “offline” and only write it down when i get it.

productivity

i can’t give any judgment on productivity because this application has been a pet project i’ve built alone without any deadline, working literally 15 minutes at a time. we recently welcomed another family member, which has made things even harder. anyways it took me about 7 months to complete this project, but it’s very hard for me to tell if f# has given any productivity boost at all. more on this in part two.

conclusion

it has been a real pleasure to write the f# part of this application. when you look at the application source, the first things that jumps to the eye is that the view model (c#/oo) is way larger (in lines of code) than the model (f#/mostly functional), yet it only does “stupid” things: it’s almost exclusively made of property definitions, raisepropertychanged events, brackets, etc. it is like a very large box full of bubble wrap sheet, with only a small, precious gift in the middle.

that said i’ve been left with the impression that i haven’t used all of the language’s power. writing the view model in f# would only have slightly alleviated its ineffectiveness, what i need is probably a different pattern for gui interaction.

in part two i’ll talk about a very different (and more interesting) project, where f# really shined. in the mean time i would be very interested to hear your opinions.

thanks a lot to steffen forkmann and samuel bosch for proof reading and general feedback!

source: http://www.frenk.com/2012/01/real-world-f-my-experience-part-one/