There is now (well, 2020) a Haskell version of this idea (Moore's "Crossing the Chasm") too, as a conference talk: https://www.youtube.com/watch?v=fNpsgTIpODA
Why F# evangelism isn't working (2015)
181–190 of 333 posts
Re: Why F# evangelism isn't working (2015)
#182(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.
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 togethe…
> 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#.
Re: Why F# evangelism isn't working (2015)
#183Earlier quoted context omitted.
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.
Are you thinking of preprocessors? Back then, it would have been via Camlp4 and Camlp5.
Aah yes I am
Re: Why F# evangelism isn't working (2015)
#184Earlier quoted context omitted.
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 togethe…
> 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#.
I don't really know Linq (and haven't used F# for 2 years, using .Net 5), but isn't F#'s `query` the interface to Linq?
https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref... https://fsharp.github.io/fsharp-core-docs/reference/fsharp-l...
Re: Why F# evangelism isn't working (2015)
#185(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.
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 togethe…
> I would much have preferred to keep C# OO and use F# when you want to go functional.
What's stopping you? You can mix and match C# and F# on the .Net platform, no?
Re: Why F# evangelism isn't working (2015)
#186Earlier quoted context omitted.
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 O…
The worst part of OOP is that all the properties of an object can be a mishmash of values and are mutable. In any method, you never know if the object is in some undesirable state without checking properties within the method itself. Multiply that headache across all methods and all other classes and it becomes a mutable mess. It makes it weird that we pass around objects as types when they encapsulate so much state…
> The worst part of OOP is that all the properties of an object can be a mishmash of values and are mutable.
Const-ness is one of the things I really miss from C++. I could look at an object and be reasonably sure I wasn't mutating it by calling foo.length() for example.
Re: Why F# evangelism isn't working (2015)
#187I think it shows in the community management that F# originated in a closed-source environment. For example, it is required to be a member of the F# Software Foundation to get access to F# Slack. Putting such a roadblock early in the discovery of the community is a sure way to limit your growth.
Re: Why F# evangelism isn't working (2015)
#188(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.
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.
Totally agree; F# really feels like a language designed by someone who really does understand the theory, why it's important, but also wanted to make the language realistic to use in industry.
When I was at Jet and Walmart, I never really felt "limited" by F#. The the language was extremely pleasant to work with, and I think most importantly, it was opinionated. Yeah, you can write Java/C#-style OOP in F# if you really want, but it's not really encouraged by the language; the language encourages a much more Haskell/OCaml-style approach to writing software.
Even calling C# libraries wasn't too bad. MS honestly did a good job with the built-in .NET libraries, and most of them work without many (or any) issues with the native F# types. Even third-party libraries would generally "just work" without headache. .NET has some great tools for thread-safe work, and I'm particularly partial to the Concurrent collections (e.g. ConcurrentDictionary and ConcurrentBag),
I also think that F# has some of the best syntax for dealing with streams (particularly with the open source AsyncSeq package); by abusing the monadic workflow ("do notation" style) syntax, you can write code that really punches above its weight in terms of things it can handle.
Now, on the JVM side you something like Scala. Scala is fine, and there are plenty of things to love about it, but one thing I do not love about it is that it's not opinionated. This leads to a lot of "basically just Java" code in Scala, and people don't really utilize the cool features it has to offer (of which there are many!). When I've had to work with Scala, I'm always that weirdo using all the cool functional programming stuff, and everyone else on my team just writes Java without semicolons.
But the basic point of the article does make a reasonable point; part of the reason that Scala has gotten more traction is because Java is just such a frustrating language to work with. Scala isn't perfect but being "better than Java" is a pretty low bar in comparison.
C# is honestly not too bad of a language; probably my favorite of the "OOP-first" languages out there. The generics make sense, the .NET library (as stated before) is very good, lambdas work as expected instead of some bizarre spoof'd interface, there are some decent threading utils built into the language, and it's reasonably fast. Do I like F# more? Yeah, I think that the OCaml/Haskell style of programming is honestly jsut a better model, but I can totally sympathize with a .NET shop not wanting to bite the bullet on it.
Re: Why F# evangelism isn't working (2015)
#189Earlier quoted context omitted.
"Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"
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.
You have to add extra syntax to do very normal things like have more than one expression in a function.
Re: Why F# evangelism isn't working (2015)
#190Earlier quoted context omitted.
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 togethe…
> I would much have preferred to keep C# OO and use F# when you want to go functional. What's stopping you? You can mix and match C# and F# on the .Net platform, no?
Yes, its pretty straightforward to have a .NET solution with a mix of C# and F# projects that can refer to each other.