Tuesday, July 22, 2014

The promise of functional utopia (dippng my toes in F#)

Functional programming has been around for ages, but aside from a very brief introduction in my uni days I hadn't even considered using a functional language at work. Times are changing however, and functional programming is gaining a lot more mainstream attention. The key cited benefits are reduced bugs due to fewer side effects in code, better concurrency/scalability support due to the use of immutable types, and greater productivity due to the use of higher order functions and reduced "lines of code".

With that in mind I set out to gain some experience in functional programming and decide whether I could see the cited benefits and make use of it.

As a .NET developer I have focused on F# - advice from some experts has indicated that learning a stricter functional language like scala (scalaz) or haskell is recommended as F# allows for some 'cheating' to occur. I won't go into the details because it is beyond my level of understanding, but sticking to "pure" functional languages means you are less likely to fall into the traditional coding traps you might encounter. While I decided to stick with F#, I have tried to keep everything as strict and side-effect free as possible, using record types over classes and avoiding mutable types.


To start with, I recommend taking a look at a couple of Pluralsight classes if you have the opportunity, these are pretty useful. The basic introduction is useful to get an idea of the language features, and the intermediate level class is extremely useful for understanding how functional programming can be used in the real world.


The key outcomes I took from my initial look into F# is that it reminded me a bit of my early days of getting to know JavaScript; everything was a hodgepodge of dependencies and big unstructured files that were difficult to read. I am pretty sure there are better ways to structure things, so I am not overly concerned by that, but I do think it certainly leads you down an unstructured path and I would want to understand how to structure things better before trying to use it on anything "real".

On the positive side, I think the power of the language itself for data manipulation became apparent quickly. The sequence and list features are extremely powerful and really form the basis of anything you would want to do with the data at hand.

For standard "CRUD" systems I wouldn't expect to see a significant gain in using functional programming, but I can certainly see a benefit for data analysis and transformation activities. It is also fairly easy to combine F# with C# code, so you can use imperative code and libraries to do the imperative CRUD code (such as database querying) and then F# to work with the resulting data.

All in all, I think there is work involved in making F# code "enterprise ready" from a maintainability and supportability perspective. From examples I have seem, I believe this is likely an issue of functional languages in general, and not F# specific, but I don't have any experience to make that call. I would find it hard to justify the learning curve to a client, but I certainly think there are benefits to be had.