> Especially, it's very easy to pass the wrong values to functions (functions instead of final values, etc). Debugging this is very time-consuming. I have the

> Especially, it's very easy to pass the wrong values to functions (functions instead of final values, etc). Debugging this is very time-consuming. I have the opposite anecdote. I use F# specifically for its strong type system and domain modelling capabilities. A method signature in C# might look like public static void HireHandyman(string handymanName, bool sweepFootpaths, bool waterGardens, bool emptyLitterBin, bool mowLawn) I can do in F# as HireHandyMan(handymanName:EmployeeName,sweepFootpaths:SweepFootpaths,waterGardens:WaterGardens,emptyLitterBins:EmptyBins,mowLawn:MowLawn) Each type listed there is a thin wrapper over the bool type, but I can add additional business logic at the type definition and it is enforced throughout the codebase at compile time (for the most part). Is it a contrived example? Somewhat. Does it prevent me from putting the emptyBins argument in the waterGardens slot? Yes, at compile time. I do concede the lack of first-class tooling (CLI is not enough, mediocre programmers like me like designers and GUIs! shakes cane) is one of the bigger costs to using F# in particular.