5 ms·

It allows you to envision your application as a series of data transforms, instead of a list of steps. This allows much more proximal abstractions for tasks inv

It allows you to envision your application as a series of data transforms, instead of a list of steps. This allows much more proximal abstractions for tasks involving data manipulation.

dleslie 6y ago
You can treat your application as a series of data transforms with C#, as well.
- freeone3000 6y ago
  It's.. not as nice. LINQ gets halfway, but, you end up getting back to procedural modeling soon. With sufficient discipline and structure, and liberal use of LINQ and lambdas, you can mostly get there, but it lacks the purity of pure functional.
  - dleslie 6y ago
    And in the process you've incurred a devastating amount of micro-allocations. When using Unity with an older version that doesn't have incremental GC this is a serious problem. Does F# avoid that?
    - freeone3000 6y ago
      Oh, god no. Performance even on fairly trivial number crunching tasks is half of C#, nevermind anything where GC is important or you'd consider writing it native. It's not a performant language, that's not the point.
      - moonchild 6y ago
        That's not a fundamental limitation, though. Implementations of SML (f# is effectively an ML implementation), OCaml, and Haskell are all quite performant.
        buybackoff 6y ago
        F# generates weird, verbose, opinionated IL code that is often JIT-unfriendly and rather focused on reference types. JIT is tailored to C# patterns and JIT is rather simple in .NET (e.g. vs JVM), so it's easy to break or miss some optimizations. Yes, it's not a fundamental limitation of the language itself. But considering the amount of hypothetical efforts required to fix all that vs investments from MSFT in F#, it is fundamental. F# lags by several years behind JIT and TPL improvements, the issues are mostly known. But it feels like it's not that important for F#. It's is not for writing fast libraries, but for Python-like use cases, explorative programming, or writing code fast when performance is not important (no hot loops in F# code) but strict typing discipline makes code less buggy and more maintainable from the first attempt. They used to say that "if F# code compiles, it's probably correct" - that is close to the truth, but do not expect top performance without fighting with the F# compiler. Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling.
        piaste 6y ago
        > Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling. To be more specific, it has a C# library so it can use _unsafe {}_ blocks to perform manual memory management. This is one key performance-oriented feature that F# lacks. Other than that, you _can_ write F# that's about as fast as non-unsafe C#, although it means giving up most of the nicer and safer features of F#. Use mutable structs and classes instead of immutable records, for/while loops instead of higher-order functions, magic values instead of option/result types, etc... I've done it in a couple of hot paths where it made sense, but quite reluctantly. Inline functions are still fine though for writing zero-cost helpers, and I don't think C# has them (there's an <AggressiveInlining> attribute but IIRC it's just a hint, the compiler isn't required to actually obey). Ironically, F# _could_ become the best language for high-performance .NET programming, because it supports directly inlining IL instructions intermixed with regular code (whereas C# has to go through the ILGenerator class). Unfortunately it's considered such a niche case that it's not planned to be expanded beyond the standard library, and to use it in your code you have to enable an undocumented / unsupported compiler flag.
  - Stolpe 6y ago
    But F# isn't a pure functional language, is it? https://www.google.com/search?q=is+f%23+a+pure+functional+language https://www.google.com/search?q=is+f%23+a+pure+functional+la...
    - deleted 6y ago
      [deleted]
- 29athrowaway 6y ago
  You can use a teaspoon instead of a spoon to eat soup. That doesn't mean it's the best utensil for that specific task.
oblio 6y ago
> proximal abstractions Proximal? Maybe you mean appropriate? Or incremental?
pjmlp 6y ago
Without the Visual Studio tools for GUI and database modeling, so it ends up being just usable for writing general purpose libraries. So, we just carry on using VB.NET, C# and C++ instead.
- chrisseaton 6y ago
  Isn't 'writing general purpose libraries' most programming? I think GUIs and database modelling are pretty niche.
  - pjmlp 6y ago
    Code isn't written in isolation unless we are speaking about programming interviews. Libraries spring to life as reusable parts from large scale projects. So the ROI of context switching to F# in the middle of a project, isn't that much if the language is reduced to expressing algorithms.

It allows you to envision your application as a series of data transforms, instead of a list of steps. This allows much more proximal abstractions for tasks involving data manipulation.

dleslie 6y ago

You can treat your application as a series of data transforms with C#, as well.

freeone3000 6y ago
It's.. not as nice. LINQ gets halfway, but, you end up getting back to procedural modeling soon. With sufficient discipline and structure, and liberal use of LINQ and lambdas, you can mostly get there, but it lacks the purity of pure functional.
- dleslie 6y ago
  And in the process you've incurred a devastating amount of micro-allocations. When using Unity with an older version that doesn't have incremental GC this is a serious problem. Does F# avoid that?
  - freeone3000 6y ago
    Oh, god no. Performance even on fairly trivial number crunching tasks is half of C#, nevermind anything where GC is important or you'd consider writing it native. It's not a performant language, that's not the point.
    - moonchild 6y ago
      That's not a fundamental limitation, though. Implementations of SML (f# is effectively an ML implementation), OCaml, and Haskell are all quite performant.
      - buybackoff 6y ago
        F# generates weird, verbose, opinionated IL code that is often JIT-unfriendly and rather focused on reference types. JIT is tailored to C# patterns and JIT is rather simple in .NET (e.g. vs JVM), so it's easy to break or miss some optimizations. Yes, it's not a fundamental limitation of the language itself. But considering the amount of hypothetical efforts required to fix all that vs investments from MSFT in F#, it is fundamental. F# lags by several years behind JIT and TPL improvements, the issues are mostly known. But it feels like it's not that important for F#. It's is not for writing fast libraries, but for Python-like use cases, explorative programming, or writing code fast when performance is not important (no hot loops in F# code) but strict typing discipline makes code less buggy and more maintainable from the first attempt. They used to say that "if F# code compiles, it's probably correct" - that is close to the truth, but do not expect top performance without fighting with the F# compiler. Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling.
        piaste 6y ago
        > Even one of the best known and oldest F# library FParsec has it's high-performance parts in C# - that's telling. To be more specific, it has a C# library so it can use _unsafe {}_ blocks to perform manual memory management. This is one key performance-oriented feature that F# lacks. Other than that, you _can_ write F# that's about as fast as non-unsafe C#, although it means giving up most of the nicer and safer features of F#. Use mutable structs and classes instead of immutable records, for/while loops instead of higher-order functions, magic values instead of option/result types, etc... I've done it in a couple of hot paths where it made sense, but quite reluctantly. Inline functions are still fine though for writing zero-cost helpers, and I don't think C# has them (there's an <AggressiveInlining> attribute but IIRC it's just a hint, the compiler isn't required to actually obey). Ironically, F# _could_ become the best language for high-performance .NET programming, because it supports directly inlining IL instructions intermixed with regular code (whereas C# has to go through the ILGenerator class). Unfortunately it's considered such a niche case that it's not planned to be expanded beyond the standard library, and to use it in your code you have to enable an undocumented / unsupported compiler flag.
- Stolpe 6y ago
  But F# isn't a pure functional language, is it? https://www.google.com/search?q=is+f%23+a+pure+functional+language https://www.google.com/search?q=is+f%23+a+pure+functional+la...
  - deleted 6y ago
    [deleted]
29athrowaway 6y ago
You can use a teaspoon instead of a spoon to eat soup. That doesn't mean it's the best utensil for that specific task.

oblio 6y ago

> proximal abstractions Proximal? Maybe you mean appropriate? Or incremental?

pjmlp 6y ago

Without the Visual Studio tools for GUI and database modeling, so it ends up being just usable for writing general purpose libraries. So, we just carry on using VB.NET, C# and C++ instead.

chrisseaton 6y ago
Isn't 'writing general purpose libraries' most programming? I think GUIs and database modelling are pretty niche.
- pjmlp 6y ago
  Code isn't written in isolation unless we are speaking about programming interviews. Libraries spring to life as reusable parts from large scale projects. So the ROI of context switching to F# in the middle of a project, isn't that much if the language is reduced to expressing algorithms.