4 ms·

FP tends to have a disregard for practicality, and performance especially. Yes, it's elegant, by being abstract, but this abstraction comes at a cost. After fa

FP tends to have a disregard for practicality, and performance especially. Yes, it's elegant, by being abstract, but this abstraction comes at a cost. After falling in love in it, I wrote a large project in F#, but eventually had to ditch it and rewrite in C#. A simple analysis of any F#-generated IL will reveal this.

asp_net 7y ago
Can you tell more about what kind of project this has been, and at what point you decided to turn around?
- jaked89 7y ago
  It was a WPF desktop application, with a parser component. I managed to write large portions of the UI (all in code, no XAML), but when debugging I discovered that the language and the IDE are slowing me down. Especially, it's very easy to pass the wrong values to functions (functions instead of final values, etc). Debugging this is very time-consuming. IDE-niceness is also a factor. Devs tend to disregard this, but all the intellisense, code lens, go to, find refs, etc are huge time savers. You lose many of these capabilities (or get them in a degraded manner) with F#. Yes, I used all the plugins, etc, but what you get is simply 2nd-grade. This is in part unfixable; the language is simply not designed with such aspects in mind. And, as said, performance played a factor as well.
  - akra 7y ago
    As someone who has done some dev in F# professionally I think a lot of the comments above could come from trying to use F# like C#. WPF (and in general older .NET Microsoft frameworks) is probably one of the worst cases for F# however; the framework is designed pretty much exclusively for C# usage (i.e. PropertyChangedEventHandlers, generated C# classes from XAML, etc). From a functional language perspective there's different ways of solving the above problems. While you could code WPF in F# it's clunky and doesn't pass the cost/benefit test IMO in its current state; you would be coding in C# style with just a different syntax since the framework enforces a given coding style. Performance wise I find it depends on what your doing. I've had nicer code run faster in F# than C# with inlining and such. You can resort to mutable coding if you have to in F# as well so I don't think its truly the case. If your using immutable data structures and writing a WPF app on top without understanding them I can see why you would get the performance hit as an example. I haven't had a problem with Intellisense, IDE niceness (e.g. Rider, VS Code), Go To Refs seem to even work in VS Code etc. All the Resharper goodies aren't there; but after awhile you find you just don't need them as much in a more leaner language.
  - smush 7y ago
    > 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.
deleted 7y ago
[deleted]
thelazydogsback 7y ago
F# code can certainly be written in C# style (no DU's, use nulls instead of option types, mutables, etc.) and should not differ much from the C# IL. Seems like doing this on the hot-path (or re-write a few fn's in C#) should be enough -- why did you need to ditch re-write the whole project? EDIT: Just saw your reply. I do agree about the IDE -- having ReSharper, OzCode, etc., on my side is a great advantage on the C# side, even though I'm an F# fan as well. Also at this point C# is a fine FP programming language itself. (Can 8.0 finally pattern-match tuples sanely?) The only thing missing are DU/sum-types.
- platz 7y ago
  unfortunately C# pattern matching is really only a glorified switch with destructuring that doesn't provide any level of exhaustiveness checking that is very helpful in maintaining code under conditions of change.
  - thelazydogsback 7y ago
    Agreed. Even w/o DU's/sum-types/case-classes, there could be a compiler option when matching an instance against a lists of sub-classes that a warning/error is generated if the list of sub-classes does not fully cover the parent class. (It should be fairly easy to write a Rosyln-based plug-in that enforces this.) Typescript allows you to express this kind of thing pretty well -- maybe some of that work will end up migrating to C#. F# used to be the C# feature playground, but that's probably changing now. Not sure if TypeProviders will ever make it...
    - platz 7y ago
      TP's I don't think have quite borne out the usefullness-to-complexity ratio
      - thelazydogsback 7y ago
        Agreed, but anything is better than some 3rd-party tool (that may or may not be integrated into the build) doing one-off ad-hoc code generation. I think any C# meta-programming facility would be a good step. Certainly the TP interface(s) could be simplified for C#.
TurboHaskal 7y ago
This is my experience as well, although I can't speak for F#. Functional programming languages work, until you hit a performance wall and need to dig a bit lower in the stack. It is when things get ugly that they start to look like fancy calculators. Besides ATS (which is not very practical), only Common Lisp seems to accommodate to that (and maybe just because Lisp is old and had to deal with performance issues for decades), but it still lacks a state of the art GC.

asp_net 7y ago

Can you tell more about what kind of project this has been, and at what point you decided to turn around?

jaked89 7y ago
It was a WPF desktop application, with a parser component. I managed to write large portions of the UI (all in code, no XAML), but when debugging I discovered that the language and the IDE are slowing me down. Especially, it's very easy to pass the wrong values to functions (functions instead of final values, etc). Debugging this is very time-consuming. IDE-niceness is also a factor. Devs tend to disregard this, but all the intellisense, code lens, go to, find refs, etc are huge time savers. You lose many of these capabilities (or get them in a degraded manner) with F#. Yes, I used all the plugins, etc, but what you get is simply 2nd-grade. This is in part unfixable; the language is simply not designed with such aspects in mind. And, as said, performance played a factor as well.
- akra 7y ago
  As someone who has done some dev in F# professionally I think a lot of the comments above could come from trying to use F# like C#. WPF (and in general older .NET Microsoft frameworks) is probably one of the worst cases for F# however; the framework is designed pretty much exclusively for C# usage (i.e. PropertyChangedEventHandlers, generated C# classes from XAML, etc). From a functional language perspective there's different ways of solving the above problems. While you could code WPF in F# it's clunky and doesn't pass the cost/benefit test IMO in its current state; you would be coding in C# style with just a different syntax since the framework enforces a given coding style. Performance wise I find it depends on what your doing. I've had nicer code run faster in F# than C# with inlining and such. You can resort to mutable coding if you have to in F# as well so I don't think its truly the case. If your using immutable data structures and writing a WPF app on top without understanding them I can see why you would get the performance hit as an example. I haven't had a problem with Intellisense, IDE niceness (e.g. Rider, VS Code), Go To Refs seem to even work in VS Code etc. All the Resharper goodies aren't there; but after awhile you find you just don't need them as much in a more leaner language.
- smush 7y ago
  > 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.

deleted 7y ago

[deleted]

thelazydogsback 7y ago

F# code can certainly be written in C# style (no DU's, use nulls instead of option types, mutables, etc.) and should not differ much from the C# IL. Seems like doing this on the hot-path (or re-write a few fn's in C#) should be enough -- why did you need to ditch re-write the whole project? EDIT: Just saw your reply. I do agree about the IDE -- having ReSharper, OzCode, etc., on my side is a great advantage on the C# side, even though I'm an F# fan as well. Also at this point C# is a fine FP programming language itself. (Can 8.0 finally pattern-match tuples sanely?) The only thing missing are DU/sum-types.

platz 7y ago
unfortunately C# pattern matching is really only a glorified switch with destructuring that doesn't provide any level of exhaustiveness checking that is very helpful in maintaining code under conditions of change.
- thelazydogsback 7y ago
  Agreed. Even w/o DU's/sum-types/case-classes, there could be a compiler option when matching an instance against a lists of sub-classes that a warning/error is generated if the list of sub-classes does not fully cover the parent class. (It should be fairly easy to write a Rosyln-based plug-in that enforces this.) Typescript allows you to express this kind of thing pretty well -- maybe some of that work will end up migrating to C#. F# used to be the C# feature playground, but that's probably changing now. Not sure if TypeProviders will ever make it...
  - platz 7y ago
    TP's I don't think have quite borne out the usefullness-to-complexity ratio
    - thelazydogsback 7y ago
      Agreed, but anything is better than some 3rd-party tool (that may or may not be integrated into the build) doing one-off ad-hoc code generation. I think any C# meta-programming facility would be a good step. Certainly the TP interface(s) could be simplified for C#.

TurboHaskal 7y ago

This is my experience as well, although I can't speak for F#. Functional programming languages work, until you hit a performance wall and need to dig a bit lower in the stack. It is when things get ugly that they start to look like fancy calculators. Besides ATS (which is not very practical), only Common Lisp seems to accommodate to that (and maybe just because Lisp is old and had to deal with performance issues for decades), but it still lacks a state of the art GC.