DEV Community

Cover image for A .NET Manager's Perspective on F#

A .NET Manager's Perspective on F#

Matt Eland on December 15, 2019

For me, 2019 was a year of learning as much as I could about software quality – to the extent that I launched a blog to share many of my findings. ...
Collapse
 
nickholmesde profile image
Nick Holmes • Edited

I put my first F# code into production in the summer of 2009, and have completed a number of projects with it since, although in total I have done more C# work in that period. If I was free to choose without regard to any real-world constraints, I'd just switch over to F# (to the greatest extent possible).

Unfortunately, it doesn't (yet?) have critical mass, and this causes real-world limits on its adoption. Too many developers have got invested in the belief that OOP is the ultimate approach, and are simply not interested learning a whole new paradigm. The few that are interested quickly realize that its not likely to be a skill many employers are looking for.

I'll keep on evangelizing F#, and I'll keep using when I get the chance, but after ten years of campaigning for broader adoption, I'm don't hold much hope it will break of out its current niche.

And I'd switch jobs in a heart-beat to work with an organisation that was really embracing F#, but they are indeed few and far between.

Collapse
 
shimmer profile image
Brian Berns

Glad to see this. I’m an F# developer in a typical C# engineering group. The two languages get along fine because they’re both .NET. The functional paradigm scales up to real world solutions with few, if any, problems. I prefer functional programming to OOP at this point. It’s conceptually simpler once you’re past the initial learning curve.

Collapse
 
jakoboffersen profile image
JakobOffersen

Really nice article, thanks for sharing your insights. F# was my first introduction to the functional paradigm at my university, and Im grateful for being introduced to it that early in my studies while I still really hadn’t developed the usual preference for OO.

I do believe that the functional paradigm is on the rise given that more students are introduced to it as part of their degree - at least here here at danish universities. Im also about to take an intermediate F# unit at uni to dig a step deeper.

What do you think is the main hindering of larger adaption of F# (or functional in general)? Is it mostly because of the limited talent pool?

Cheers!

Collapse
 
shimmer profile image
Brian Berns • Edited

What do you think is the main hindering of larger adaption of F# (or functional in general)?

I think that F# (and FP in general) is simpler than C# (and OOP in general), but not easier. This has several implications:

  • For small problems, it's easier for the typical developer to get stuff done using OOP/procedural logic (e.g. for loops instead of Seq.fold), at the cost of a slightly higher bug rate.
  • For large problems, the complexity of OOP bogs things down because it becomes difficult to reason about behavior (e.g. mutable variables), while FP scales up more linearly (e.g. no side-effects).

This means that an FP developer will sometimes seem stuck on an isolated problem longer, because solving it with correct types and without side-effects can be like a puzzle. However, once the solution actually compiles and runs, it's likely to be superior to whatever an OOP programmer might slap together quicly.

So, eventually, I expect FP to be picked up by more disciplined teams creating large systems, while smaller projects will continue to be implemented in C#, Python, etc., where the benefits of FP don't matter as much.

Collapse
 
a1300 profile image
a1300 • Edited

Matt, what is your preferred Data Access Library when working with F#? What is the most elegant way (in your opinion) to interact with a RDBMS?
Thanks!