DEV Community

Discussion on: A .NET Manager's Perspective on F#

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.