14 ms·

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 ye

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

mastazi 3y ago
Also, you correctly anticipated that Swift would become mainstream long before F#, which happened. Of course hindsight is 20/20, but this wasn't that obvious back in 2015. Your reasoning was sound.
- zokier 3y ago
  Swift is still very much a niche language. Its a big niche, but niche nevertheless.
7thaccount 3y ago
I really wanted to learn it, but I wanted to learn F# & not C#. The problem is...you can't really learn F# without knowing .NET and how it does all the OO stuff. Even the most basic things that require one easily googleable line in Python would return no results for F#. You just have to figure it out in C# and then you can apply to F#.
throw868788 3y ago
Would be interesting to see actual stats in F# usage which I doubt are relatively available. Given the reaction to this post from what is an old article there's still probably an underground interest in the language and some use in general. People seem to have built strong views on it either way. Especially with some posters admitting they use it professionally with a closed source culture (finance, insurance, etc). Most metrics would not be accurate given interoperability with C# - e.g Google searching I would typically look up C# code and port it for example. Maybe it doesn't need to thrive for everyone; maybe it just needs to continue being useful for the people who employ it and add value. That's probably OK. They could be just busy building stuff instead of blogging, especially if the community is mostly compromised of senior developers (10 years +).
aaronmu 3y ago
> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive. C# will always be more popular because it easier to learn. Why? Because it looks familiar to most developers. Why would you learn this unfamiliar thing called F# if C# is right there and you basically already know it? On top of that, C# almost has feature parity with F#. However, F# is a simpler language than C#. That is a fact. It has less concepts that you need to learn. I've found that onboarding someone in an F# codebase takes a lot less time compared to onboarding someone in a typescript,C#,... codebase. A lot less time. I've found that new people can start contributing after a single introduction. The things they build often just work. I think that an F# code base costs a lot less money to maintain over longer periods of time. Can't prove it but I think that the difference is huge.
Andys 3y ago
Seeing your name pop up was a blast from the past for me too - I used to read back in the "The Business of Software" days.. circa 2005 I think?
systems 3y ago
I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling Objects calling Objects and more Objects OOP is bad because eventually OO systems becomes too complex, OO API is intimidation Separating Data from Behavior manages complexity better If the only flaw in C# is knowing which method calls requires the new keyword because its a constructor, and which dont because its a factory, that is bad enough to want to avoid it
- CrimsonCape 3y ago
  I empathize with your characterization of "a tree of object/classes" and I yearn for an example of how else to model a complex, domain-specific system not using the aforementioned tree.
  - heywhatupboys 3y ago
    well you see! What we can do is to namespace our functions, e.g. by naming them component_create, component_add_button, etc. We then create a plain dictionary with key value pairs that gets passed onto these functions! The functions then possibly return a new map, which is a modified map! This allows us to write code like dog = dog_create({name: "foo", age: 12}) dog = dod_add_friend(dog2) print(dog["friends"]) and we can avoid OO completely. oh... wait a minute
    - epgui 3y ago
      This comment shows a total misunderstanding of what functional programming is…
      - heywhatupboys 3y ago
        While tongue in cheek, this is one if the OP in non-OP patterns that is used heavily for large projects in FP alike.
CrimsonCape 3y ago
If you had to chose right now and abandon the other, would you pick LINQ or discriminated unions?
- Turskarama 3y ago
  Not OP but I would choose discriminated unions. Why? because Linq is basically just syntactic sugar for regular IEnumerable methods, while discriminated unions have no equivalent at all. Even if you wanted to claim that those IEnumerable methods ARE linq, then it would still be possible to implement them with a library while discriminated unions have to be a compiler feature.
  - pharmakom 3y ago
    Yep, Linq could be replaced by the more general Computation Expressions in F#
    - WorldMaker 3y ago
      F# has a query { } expression for LINQ already.
      - pharmakom 3y ago
        I'm talking about improving C# by replacing LINQ with the more general Computation Expressions.
        WorldMaker 3y ago
        Ah. The C# compiler "duck types" LINQ so you can already (ab)use LINQ for general computation in C#. You can use nearly any Monad you want with LINQ syntax. It isn't always a strong fit for some types of Monads, but it is more capable than it seems. You might get some funny looks if you do, though. (Similar with async/await: it is "duck typed" at compile time so you can write other Monads for that, if they make more sense in that form of transformer than LINQ. Or support both LINQ and async/await together.) There's definitely some more interesting power in F#'s Computation Expressions that can't easily be done even with (ab)using the tools that already exist like that, but it is still interesting what can be done with the existing tools.
lambdaxymox 3y ago
F# always struck me as one of the most terribly underrated languages. I'm a lover of MLs in general, but F# lands on one of the sweet spots in PL space with ample expressive power without being prone to floating off into abstraction orbit ("pragmatic functional" is the term I believe). It is basically feature complete to boot.
- epgui 3y ago
  > without being prone to floating off into abstraction orbit What do you mean by this?
  - c00lio 3y ago
    "Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"
    - ykonstant 3y ago
      >NullUnderstanding compiler extension brilliant! lol
      - epgui 3y ago
        Is brilliant the best word? :P
    - momentoftop 3y ago
      You're thinking of Haskell. F# was modelled after OCaml, which doesn't attract monad transformer stacks, and doesn't have a zoo of compiler extensions.
      - seanhunter 3y ago
        I haven’t used it for some time but OCaml certainly used to have a zoo of incompatible compiler extensions. Circa 2008 or so I once hit on the brilliant idea of using protobufs to get two mutually incompatible halves of an ocaml program to talk to one another only to find that required yet another compiler extension to work.
caseysoftware 3y ago
Another "blast from the past" for me too.. Your "career calculus" article has been top of mind for me recently as I've talked about it a bunch of people. Amusing how those core concepts don't change much.
ThinkBeat 3y ago
C# in its current state has IMHO acquired many features from F#. You can get close to writing purely functional code in C# now. I think with all the changes and extensions over time to add ever more features to C# so you can write whatever paradigm you want in it is a bad idea. I would much have preferred to keep C# OO and use F# when you want to go functional. Or just create G# which is the everything mashed together language that C# is close to being.
- progmetaldev 3y ago
  I don't dispute your claims, as they are subjective. I do know that I enjoy a lot of the functional aspects to C#, but I think it's something where you need to have a real discussion with your team and decide a coding style and feature implementation for your code. If your team can't all speak the same dialect, you're going to have issues. Having seniors able to work with juniors and discuss the functional aspects, as well as when to use things link LINQ, goes a long way towards a consistent and easily understood codebase. I know not every shop has this luxury, which is why I still agree with your statement.
  - ThinkBeat 3y ago
    You bring up good points. I often think about C. I learned C a long time ago, I still have the KR book, and if I look at C code I can get a good idea of what is happening, even though I haven't kept up with all the changes. In C# now, two developers can write code that accomplishes the same but might not be able to read each other's code. I dont think that is healthy. It is somewhat the Microsoft Office / Word approach to programming languages. Just Keep adding features on top of features.
- pjc50 3y ago
  > You can get close to writing purely functional code in C# now. It seems that FP advocates overlook just how great LINQ is, even if it exists within the impure swamp of regular C#.
  - ReleaseCandidat 3y ago
pharmakom 3y ago
I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!
- michielr 3y ago
  I agree this was a problem, but with the current Minimal API's, there is no boilerplate, looks a lot like Express to me! var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); app.MapGet("/", () => "Hello World!"); app.Run();
  - _gabe_ 3y ago
    >> The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Your code snippet certainly has a lot of unnecessary ceremony. Why use a builder object at all? Why use a static class with a function to build the builder object? var builder = createBuilder(args); // etc... Would be better. But var app = createWebApp(args); // etc... Is even better. No ceremony at all!
    - progmetaldev 3y ago
      There is a lot that gets done behind the scenes in createBuilder(). I understand where you're coming from, but this allows you to override any defaults that you don't like, in order to provide your own. I personally still stick to the standard MVC pattern, and don't go crazy with abstractions. I place my business logic within services and inject those in my controllers, but if you were to run a debugger, you would not have to jump through interfaces and other useless abstractions that were a thing of the past (and present if you follow current tutorials and books). I have used Node.JS, and still use it to provide my frontend developers with an environment using Express to build out templates using Gulp for minification/transpilation/compression for use in Umbraco (a .NET Core CMS). My frontend developers don't need to know C#, and can work in standard EJS templates and HTML, but benefit from SCSS and modern JavaScript. I can then build out the Razor syntax for views, and just drop their CSS and JS files directly into the CMS projects.
pjmlp 3y ago
F# also tried to pivot into data science of lately, only to have Microsoft themselves jumping into Python and being the entity that finally managed to convince Guido and others to invest into improving CPython's performance, and possible JIT integration. Basically having the pivot efforts being sabotaged by the same company.
- WorldMaker 3y ago
  Microsoft has always been a polyglot company. They also invested heavily in R and I believe even contributed some things to Julia. I don't think the pivot entirely failed, there's definitely a small niche for "data science, but it needs to run in .NET" and F# still to my understanding fills it well. It's a very small niche and I don't expect to hear a lot of data scientists directly training for it, but there's a lot of advantages in places that use the Azure stack, for instance, for faster/better/more integrated data science when done with F#. F# would probably need a lot more investment in dynamic types to truly attract a lot of data scientist attention. (Though the .NET DLR still exists and could use some fresh, modern love.) Relatedly, I appreciate a lot that Microsoft's polyglot approach helped standardize the ONNX runtime, and even if the data scientists I'm working with prefer Python or R, I can still take ONNX models they build and run them in a C# or F# library with very little sweat.
  - progmetaldev 3y ago
    I think if Microsoft would have continued to invest in projects such as IronRuby and IronPython, we'd be much further along in integrating different paradigms in a way that feels more natural, while also continuing to grow the DLR (for both features and performance).
- progmetaldev 3y ago
  I am only scratching the very surface of data science, but coming from .NET 1.0 and just starting to learn Python, I'm still finding it far easier to use Python for these tasks. It's most likely just the library ecosystem, and I'm hoping that Microsoft continues to add officially supported libraries to .NET for these tasks. ML.NET feels very foreign to me compared to using other libraries in Python, even as a beginner in Python (although I have experience with various languages, but only minimal experience in functional languages, mostly F#).
DennisP 3y ago
I think another problem was that Microsoft downplayed F#. They didn't support it in SSIS packages, or fully support it in MVC projects. Those were the main things I did back then. I really wanted to use F# and had the freedom to do so, but had to conclude I'd be faster sticking with C# than switching back and forth.
orthoxerox 3y ago
> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive. That's right. I mostly switched to writing "dumb records + service classes" code in C#, and while F# is terser, there's just not enough pain to cause me to switch. When DU's come to C#, the gap will get even narrower.
sproketboy 3y ago
[dead]
mochaki 3y ago
[dead]

mastazi 3y ago

Also, you correctly anticipated that Swift would become mainstream long before F#, which happened. Of course hindsight is 20/20, but this wasn't that obvious back in 2015. Your reasoning was sound.

zokier 3y ago
Swift is still very much a niche language. Its a big niche, but niche nevertheless.

7thaccount 3y ago

I really wanted to learn it, but I wanted to learn F# & not C#. The problem is...you can't really learn F# without knowing .NET and how it does all the OO stuff. Even the most basic things that require one easily googleable line in Python would return no results for F#. You just have to figure it out in C# and then you can apply to F#.

throw868788 3y ago

Would be interesting to see actual stats in F# usage which I doubt are relatively available. Given the reaction to this post from what is an old article there's still probably an underground interest in the language and some use in general. People seem to have built strong views on it either way. Especially with some posters admitting they use it professionally with a closed source culture (finance, insurance, etc). Most metrics would not be accurate given interoperability with C# - e.g Google searching I would typically look up C# code and port it for example. Maybe it doesn't need to thrive for everyone; maybe it just needs to continue being useful for the people who employ it and add value. That's probably OK. They could be just busy building stuff instead of blogging, especially if the community is mostly compromised of senior developers (10 years +).

aaronmu 3y ago

> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive. C# will always be more popular because it easier to learn. Why? Because it looks familiar to most developers. Why would you learn this unfamiliar thing called F# if C# is right there and you basically already know it? On top of that, C# almost has feature parity with F#. However, F# is a simpler language than C#. That is a fact. It has less concepts that you need to learn. I've found that onboarding someone in an F# codebase takes a lot less time compared to onboarding someone in a typescript,C#,... codebase. A lot less time. I've found that new people can start contributing after a single introduction. The things they build often just work. I think that an F# code base costs a lot less money to maintain over longer periods of time. Can't prove it but I think that the difference is huge.

Andys 3y ago

Seeing your name pop up was a blast from the past for me too - I used to read back in the "The Business of Software" days.. circa 2005 I think?

systems 3y ago

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess Learning, how to use an Object System (a tree of objects/classes) is inherently hard The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling Objects calling Objects and more Objects OOP is bad because eventually OO systems becomes too complex, OO API is intimidation Separating Data from Behavior manages complexity better If the only flaw in C# is knowing which method calls requires the new keyword because its a constructor, and which dont because its a factory, that is bad enough to want to avoid it

CrimsonCape 3y ago
I empathize with your characterization of "a tree of object/classes" and I yearn for an example of how else to model a complex, domain-specific system not using the aforementioned tree.
- heywhatupboys 3y ago
  well you see! What we can do is to namespace our functions, e.g. by naming them component_create, component_add_button, etc. We then create a plain dictionary with key value pairs that gets passed onto these functions! The functions then possibly return a new map, which is a modified map! This allows us to write code like dog = dog_create({name: "foo", age: 12}) dog = dod_add_friend(dog2) print(dog["friends"]) and we can avoid OO completely. oh... wait a minute
  - epgui 3y ago
    This comment shows a total misunderstanding of what functional programming is…
    - heywhatupboys 3y ago
      While tongue in cheek, this is one if the OP in non-OP patterns that is used heavily for large projects in FP alike.

CrimsonCape 3y ago

If you had to chose right now and abandon the other, would you pick LINQ or discriminated unions?

Turskarama 3y ago
Not OP but I would choose discriminated unions. Why? because Linq is basically just syntactic sugar for regular IEnumerable methods, while discriminated unions have no equivalent at all. Even if you wanted to claim that those IEnumerable methods ARE linq, then it would still be possible to implement them with a library while discriminated unions have to be a compiler feature.
- pharmakom 3y ago
  Yep, Linq could be replaced by the more general Computation Expressions in F#
  - WorldMaker 3y ago
    F# has a query { } expression for LINQ already.
    - pharmakom 3y ago
      I'm talking about improving C# by replacing LINQ with the more general Computation Expressions.
      - WorldMaker 3y ago
        Ah. The C# compiler "duck types" LINQ so you can already (ab)use LINQ for general computation in C#. You can use nearly any Monad you want with LINQ syntax. It isn't always a strong fit for some types of Monads, but it is more capable than it seems. You might get some funny looks if you do, though. (Similar with async/await: it is "duck typed" at compile time so you can write other Monads for that, if they make more sense in that form of transformer than LINQ. Or support both LINQ and async/await together.) There's definitely some more interesting power in F#'s Computation Expressions that can't easily be done even with (ab)using the tools that already exist like that, but it is still interesting what can be done with the existing tools.

lambdaxymox 3y ago

F# always struck me as one of the most terribly underrated languages. I'm a lover of MLs in general, but F# lands on one of the sweet spots in PL space with ample expressive power without being prone to floating off into abstraction orbit ("pragmatic functional" is the term I believe). It is basically feature complete to boot.

epgui 3y ago
> without being prone to floating off into abstraction orbit What do you mean by this?
- c00lio 3y ago
  "Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"
  - ykonstant 3y ago
    >NullUnderstanding compiler extension brilliant! lol
    - epgui 3y ago
      Is brilliant the best word? :P
  - momentoftop 3y ago
    You're thinking of Haskell. F# was modelled after OCaml, which doesn't attract monad transformer stacks, and doesn't have a zoo of compiler extensions.
    - seanhunter 3y ago
      I haven’t used it for some time but OCaml certainly used to have a zoo of incompatible compiler extensions. Circa 2008 or so I once hit on the brilliant idea of using protobufs to get two mutually incompatible halves of an ocaml program to talk to one another only to find that required yet another compiler extension to work.

caseysoftware 3y ago

Another "blast from the past" for me too.. Your "career calculus" article has been top of mind for me recently as I've talked about it a bunch of people. Amusing how those core concepts don't change much.

ThinkBeat 3y ago

C# in its current state has IMHO acquired many features from F#. You can get close to writing purely functional code in C# now. I think with all the changes and extensions over time to add ever more features to C# so you can write whatever paradigm you want in it is a bad idea. I would much have preferred to keep C# OO and use F# when you want to go functional. Or just create G# which is the everything mashed together language that C# is close to being.

progmetaldev 3y ago
I don't dispute your claims, as they are subjective. I do know that I enjoy a lot of the functional aspects to C#, but I think it's something where you need to have a real discussion with your team and decide a coding style and feature implementation for your code. If your team can't all speak the same dialect, you're going to have issues. Having seniors able to work with juniors and discuss the functional aspects, as well as when to use things link LINQ, goes a long way towards a consistent and easily understood codebase. I know not every shop has this luxury, which is why I still agree with your statement.
- ThinkBeat 3y ago
  You bring up good points. I often think about C. I learned C a long time ago, I still have the KR book, and if I look at C code I can get a good idea of what is happening, even though I haven't kept up with all the changes. In C# now, two developers can write code that accomplishes the same but might not be able to read each other's code. I dont think that is healthy. It is somewhat the Microsoft Office / Word approach to programming languages. Just Keep adding features on top of features.
pjc50 3y ago
> You can get close to writing purely functional code in C# now. It seems that FP advocates overlook just how great LINQ is, even if it exists within the impure swamp of regular C#.
- ReleaseCandidat 3y ago

pharmakom 3y ago

I used to write lots of C#, but now I consider it a bad ecosystem. The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Just look at building a simple HTTP endpoint in C# compared to Node or even F#!

michielr 3y ago
I agree this was a problem, but with the current Minimal API's, there is no boilerplate, looks a lot like Express to me! var builder = WebApplication.CreateBuilder(args); var app = builder.Build(); app.MapGet("/", () => "Hello World!"); app.Run();
- _gabe_ 3y ago
  >> The problem is the amount of ceremony, silly OOP abstractions, dependency injection, etc. Your code snippet certainly has a lot of unnecessary ceremony. Why use a builder object at all? Why use a static class with a function to build the builder object? var builder = createBuilder(args); // etc... Would be better. But var app = createWebApp(args); // etc... Is even better. No ceremony at all!
  - progmetaldev 3y ago
    There is a lot that gets done behind the scenes in createBuilder(). I understand where you're coming from, but this allows you to override any defaults that you don't like, in order to provide your own. I personally still stick to the standard MVC pattern, and don't go crazy with abstractions. I place my business logic within services and inject those in my controllers, but if you were to run a debugger, you would not have to jump through interfaces and other useless abstractions that were a thing of the past (and present if you follow current tutorials and books). I have used Node.JS, and still use it to provide my frontend developers with an environment using Express to build out templates using Gulp for minification/transpilation/compression for use in Umbraco (a .NET Core CMS). My frontend developers don't need to know C#, and can work in standard EJS templates and HTML, but benefit from SCSS and modern JavaScript. I can then build out the Razor syntax for views, and just drop their CSS and JS files directly into the CMS projects.

pjmlp 3y ago

F# also tried to pivot into data science of lately, only to have Microsoft themselves jumping into Python and being the entity that finally managed to convince Guido and others to invest into improving CPython's performance, and possible JIT integration. Basically having the pivot efforts being sabotaged by the same company.

WorldMaker 3y ago
Microsoft has always been a polyglot company. They also invested heavily in R and I believe even contributed some things to Julia. I don't think the pivot entirely failed, there's definitely a small niche for "data science, but it needs to run in .NET" and F# still to my understanding fills it well. It's a very small niche and I don't expect to hear a lot of data scientists directly training for it, but there's a lot of advantages in places that use the Azure stack, for instance, for faster/better/more integrated data science when done with F#. F# would probably need a lot more investment in dynamic types to truly attract a lot of data scientist attention. (Though the .NET DLR still exists and could use some fresh, modern love.) Relatedly, I appreciate a lot that Microsoft's polyglot approach helped standardize the ONNX runtime, and even if the data scientists I'm working with prefer Python or R, I can still take ONNX models they build and run them in a C# or F# library with very little sweat.
- progmetaldev 3y ago
  I think if Microsoft would have continued to invest in projects such as IronRuby and IronPython, we'd be much further along in integrating different paradigms in a way that feels more natural, while also continuing to grow the DLR (for both features and performance).
progmetaldev 3y ago
I am only scratching the very surface of data science, but coming from .NET 1.0 and just starting to learn Python, I'm still finding it far easier to use Python for these tasks. It's most likely just the library ecosystem, and I'm hoping that Microsoft continues to add officially supported libraries to .NET for these tasks. ML.NET feels very foreign to me compared to using other libraries in Python, even as a beginner in Python (although I have experience with various languages, but only minimal experience in functional languages, mostly F#).

DennisP 3y ago

I think another problem was that Microsoft downplayed F#. They didn't support it in SSIS packages, or fully support it in MVC projects. Those were the main things I did back then. I really wanted to use F# and had the freedom to do so, but had to conclude I'd be faster sticking with C# than switching back and forth.

orthoxerox 3y ago

> F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive. That's right. I mostly switched to writing "dumb records + service classes" code in C#, and while F# is terser, there's just not enough pain to cause me to switch. When DU's come to C#, the gap will get even narrower.

sproketboy 3y ago

[dead]

mochaki 3y ago

[dead]