- no NULL- just use option types and pattern matching
- how powerful pattern matching is
- pipelining
- units of measurement- we all know the billion dollar disasters caused by distributed teams all thinking in their respective units- these should always be in the signature of a method
but when starting I can still remember how I struggled with the rather mathematical notation of int -> int -> int for signatures- I often failed to quickly spot the error in calling a function.
brace placement just felt wrong (when nesting function calls, which could be necessary despite pipelining)- I understand why, but for the most part it just felt wrong coming from Java/C#.
unfortunately it is a rather niche language- being a .net language does not help here as the main features such as algebraic datatypes are largely incompatible with C# syntax.
I am just glad that more and more features are adopted by C#- only downside is, that C# suffers of feature bloat :(
F# selling point to me is type providers. Being able to write a SQL query and the IDE/compiler knowing the result types is magic. Screw ORM this is how it's supposed to work.
I have to admit I only used F# on a small project a few years back, but the type providers made the job super simple - the job was basically generating some fancy reports from multiple data sources and being able to just specify database connection strings and have everything work in the IDE/compiler was a huge win. Setting up CI was a bit of a PITA because I remember needing to spinup a DB to create schema, there was some option to do it from schema directly but didn't want to waste time.
what I was missing: "dotting into" in the sense that I have a object/data I want no manipulate and quickly see what can be done with an data in FP
after getting into FP some years ago I have significantly altered my programming style in C#, using much more extension methods for pure functions, and recently NonNullable, pattern matching etc...
- computation expressions [0], which can be used to easily create a DSL (domain specific language) so you can define workflows and keywords to abstract big business logic
- currying [1] and partial application, which lets you call functions with incomplete parameters and pipe along the new function. It's like a much more flexible version of Func<t,..> in a C# method parameter.
Once you get comfortable with these, you'll find yourself using them all over.
If you have any specific questions I can probably answer them, one of the projects I lead at work has ~500kloc of F# which interops with C# and unmanaged languages. The largest value-add for us is probably the units of measure though, since the domain involves a lot of physics.
I think that's one of the difficulty which is hard to understand for people used to it which is why it might be hard to find material explaining it to you as you would like.
As someone who was taught programming with Ocaml as my first real language, I find currying intuitive (the rightmost type is the result, everything else is an argument) but sometimes I have difficulty with functions taking other functions as arguments and which are suffisently complex for their comportement to not be obvious from their type signature. But that's inherent complexity not really a problem with currying.
I don't know, I think once you're passing in results from functions rather than functions themselves to curry, the complexity is not centralised in the same way, but broken down.
It's a bit like occasionally needing to create intermediate variables to grok precisely what is being made at a specific point in highly chained code (I do this occasionally in LINQ too). My brain is only small and cannot keep track of things clearly
- no NULL- just use option types and pattern matching
- how powerful pattern matching is
- pipelining
- units of measurement- we all know the billion dollar disasters caused by distributed teams all thinking in their respective units- these should always be in the signature of a method
but when starting I can still remember how I struggled with the rather mathematical notation of int -> int -> int for signatures- I often failed to quickly spot the error in calling a function.
brace placement just felt wrong (when nesting function calls, which could be necessary despite pipelining)- I understand why, but for the most part it just felt wrong coming from Java/C#.
unfortunately it is a rather niche language- being a .net language does not help here as the main features such as algebraic datatypes are largely incompatible with C# syntax.
I am just glad that more and more features are adopted by C#- only downside is, that C# suffers of feature bloat :(