Live data from Hacker News

The Problem with F# Evangelism

thomasbandt.com

1–10 of 203 posts

Re: The Problem with F# Evangelism

#4
I'm the lone F# developer in a shop full of experienced and talented C# developers. I have clout, but not enough to convince any of them that F# is a better choice for many of our purposes. It's frustrating, but I try to understand that people are just naturally resistant to big changes like this.

Re: The Problem with F# Evangelism

#5
Good article. F# would find much better adoption if there were more FP style libraries out there. I have tried to move to F# but it's a real uphill battle when pretty much all sample code and most libraries are in C#. I would do it if I was alone but it's hard to convince a team of the benefits.

Re: The Problem with F# Evangelism

#6
I'm currently a C# developer, but have tried functional languages before. As mentioned in the article, I think a lot of people are satisfied with the functional capabilities C# already provides. I don't need to write functional code all the time, but if I can model a problem more elegantly using higher-order functions I will gladly do that.

I'd be interested to read a more in-depth description of the recent project which the OP chose to implement with F#.

Re: The Problem with F# Evangelism

#7

I'm the lone F# developer in a shop full of experienced and talented C# developers. I have clout, but not enough to convince any of them that F# is a better choice for many of our purposes. It's frustrating, but I try to understand that people are just naturally resistant to big changes like this.

Same for me. Do you think that in the end F# would be that much better for good C# devs? I am not so sure.

Re: The Problem with F# Evangelism

#8
The best way to get someone to tune out when you are trying to convince them to get out their . bubble is to casually introduce words that they don't know.

By doing this, you separate yourself from the listener, giving a clear delineation between the noob and the l337 wizard.

It also helps to feign surprise, "you dont know about monadic entropy lenses?" or use the word _just_ as in "Just run the parser combinator in reverse, its easy".

Re: The Problem with F# Evangelism

#9
I think F#'s larger problem is that it doesn't dip into many of the wells that even OCaml (its original inspiration) has dipped into. C# developers are wrong that C#'s functional facilities are just as good, but it's a big struggle to point to a place in F# and say, "THERE! THAT IS THE BEST BIT!" The closest I can get is type providers (which are cool and I wish for them elsewhere) but they're kinda specialist.

Ocaml folks have these. Haskell folks have these. Heck, even psuedo-functional languages like Clojure and Scala have these.

The other problem is one of tooling (disclaimer, last time I tried this was just over a year ago). F# not only has pretty obscure tooling, but in conventional tooling it introduces a total linear order to your entire source tree, and it's one YOU must maintain with a GUI list. What's more, the F# community is very keen to disseminate the language.

I think F# would be more popular if it did more to differentiate itself from imperative programming. There is a longstanding argument that this is "unfriendly to data scientist", but I'm really not convinced by this, as I meet very few mathematicians outside of the stats world who don't on some way, shape or form espouse functional programming.

Re: The Problem with F# Evangelism

#10
Very nice list of very practical problems functional languages like F# are meant to address. After a certain amount of experience, pretty much every OO developer will have experienced these problems, so makes for a good entry point to describe the benefits of a functional language.
Post reply on HN