The Problem with F# Evangelism
thomasbandt.com
The Problem with F# Evangelism
1–10 of 203 posts
Re: The Problem with F# Evangelism
#2Re: The Problem with F# Evangelism
#3404
Re: The Problem with F# Evangelism
#4Re: The Problem with F# Evangelism
#5Re: The Problem with F# Evangelism
#6I'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
#7I'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
#8By 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
#9Ocaml 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.