The second annual F# survey(fsharpworks.com)
fsharpworks.com
The second annual F# survey
http://fsharpworks.com/survey.html
23 comments
Surprisingly (actually not) lack of functors makes the language completely different.
Indeed, I agree with you.
Object-orientation support on OCaml also sets it far apart from SML, for instance. Which can lead to a lengthy discussion, but that's beside the point.
This reasoning, however, is exactly my point: depending on where emphasis is placed, they can be argued to be similar or completely different languages.
Object-orientation support on OCaml also sets it far apart from SML, for instance. Which can lead to a lengthy discussion, but that's beside the point.
This reasoning, however, is exactly my point: depending on where emphasis is placed, they can be argued to be similar or completely different languages.
Every time I start getting into f# the Roslyn team comes out with new features taken from FP (tuples, local functions, pattern matching) and narrows the gap. So I postpone the move from c# to f# to a later date .
The things I know are never coming to c# (like data providers) are not important to me.
So for me c# is the greatest block against f# adoption.
The things I know are never coming to c# (like data providers) are not important to me.
So for me c# is the greatest block against f# adoption.
It is still a long way before:
* pattern matching / active patterns
* Discriminated Unions and many other crucial type system enhancements over POCO in C#
* real functional orientation (function composition, immutability by default, partial application)
* type providers (it is not necessarily about data provider)
* more compile time safety harness
* plenty of other things that become apparent when you get comfortable with the language
C# 7 is still doing catch-up with F# 1.
My hypothesis is that it is easier for many people to not try too hard to grasp at functional programming or just learn a new language.
* pattern matching / active patterns
* Discriminated Unions and many other crucial type system enhancements over POCO in C#
* real functional orientation (function composition, immutability by default, partial application)
* type providers (it is not necessarily about data provider)
* more compile time safety harness
* plenty of other things that become apparent when you get comfortable with the language
C# 7 is still doing catch-up with F# 1.
My hypothesis is that it is easier for many people to not try too hard to grasp at functional programming or just learn a new language.
The truth is that F#'s features are not that compelling to justify the move, ML syntax is too different and R# tooling is not there and never going to be.
You might be right about a small subset of people, but most developers using languages like ruby, python, basic, pascal, etc. would prove this wrong.
Also most of F# are fairly well experienced C# programmer, and I think they do find the language compelling.
Also most of F# are fairly well experienced C# programmer, and I think they do find the language compelling.
C# cannot gain the the aesthetics and ergonomics of F#, so there will always be something missing.
Out of curiosity: can a developer totally foreign to .NET, C#, and Windows programming in general become productive with F#?
(I mean, without having to learn the rest of the Microsoft ecosystem)
(I mean, without having to learn the rest of the Microsoft ecosystem)
Yes. I've had several people come onto an F# project with no prior experience in F# or ML or anything like it. They were all able to get up to speed. To start, F# makes it easy to write imperative, C#-style code anyways.
Over half of these people have since said they LOVE F#, and it makes them happy to use it. That it makes them better programmers, and that C# is just verbose and annoying in comparison.
As far as the Windows ecosystem, you don't need to learn much about it, though Visual Studio is a great IDE for F#. But there's IDEs on Linux and Mono specifically says they support F#.
Over half of these people have since said they LOVE F#, and it makes them happy to use it. That it makes them better programmers, and that C# is just verbose and annoying in comparison.
As far as the Windows ecosystem, you don't need to learn much about it, though Visual Studio is a great IDE for F#. But there's IDEs on Linux and Mono specifically says they support F#.
What do the other half say?
(Honest question. I'm very interested in the question of the approachability of functional languages)
(Honest question. I'm very interested in the question of the approachability of functional languages)
The other half aren't negative per-se, but they don't seem to care as much (view it as just a job). Or one guy moved to Haskell and then sorta looked down on F#. There's also some frustration sometimes when something hasn't clicked and "should" be easy. Often this is because F# is taught at a high level, without showing the simple primitives that built it up from scratch.
The non-programmers are less positive. From them, I hear "Yeah but it's so concise no one can understand it"[1]. I once got a "If we use F#, then when we exit for (huge figure) we might get less money.[2] Or the general "but this isn't mainstream" (MS's fault for shitty F# marketing.)
And there's also the "ok but we can't find hires". Which is the second worst one. Because on anything that's not some boring CRUD like app, the work to learn the domain and everything about the app dwarfs learning a new language.
(The worst excuse is the nonsense "best tool for the job" as if F# didn't out-class C# in essentially every single aspect. I find this excuse is pulled out a lot, as a way to handwave away real criticism or discussion.)
1: This is just unfamiliarity. In general, less code = less bugs, less work to understand. 2: True if you're selling a business that's a simple website. Not true if you're selling a business that revolves around all your code does.
The non-programmers are less positive. From them, I hear "Yeah but it's so concise no one can understand it"[1]. I once got a "If we use F#, then when we exit for (huge figure) we might get less money.[2] Or the general "but this isn't mainstream" (MS's fault for shitty F# marketing.)
And there's also the "ok but we can't find hires". Which is the second worst one. Because on anything that's not some boring CRUD like app, the work to learn the domain and everything about the app dwarfs learning a new language.
(The worst excuse is the nonsense "best tool for the job" as if F# didn't out-class C# in essentially every single aspect. I find this excuse is pulled out a lot, as a way to handwave away real criticism or discussion.)
1: This is just unfamiliarity. In general, less code = less bugs, less work to understand. 2: True if you're selling a business that's a simple website. Not true if you're selling a business that revolves around all your code does.
My hypothesis is that other half says:
* Code is less clear than C style (type inference, not used to some pervasive operators like function composition or piping)
* Code is terse and short names are more prevalent (Lost the way to kingdom of nouns)
* There is no Resharper support, and Visual Studio (the main IDE with F# support) tooling is not as advanced as for C#, which is impairing to some extent if you look use the language like a glorified C# and not too used to F# way (tooling is great compared to many other languages IMHO)
* There is no do/while or goto or break
* Code is less clear than C style (type inference, not used to some pervasive operators like function composition or piping)
* Code is terse and short names are more prevalent (Lost the way to kingdom of nouns)
* There is no Resharper support, and Visual Studio (the main IDE with F# support) tooling is not as advanced as for C#, which is impairing to some extent if you look use the language like a glorified C# and not too used to F# way (tooling is great compared to many other languages IMHO)
* There is no do/while or goto or break
FSharp Power Tools is about all the IDE tooling I care about. I think coming from the OO world developers just expect a whole bunch of add-on tooling. Once you are comfortable with the functional-first way of doing things you find almost all of this unnecessary, except perhaps for some rather basic refactoring support, which FSPT provides.
I'd say yes if you have exposure to Java library & ecosystem, because .NET Framework's Library has a similar flavor to Java Standard Library.
There are also a bunch of F# centric projects (http://fsprojects.github.io/) which might help you to stay in mostly functional programming land and not mingle too much with OOP.
The main difficulty is to get runtime working well, I think Mono has come a long way and is now well packaged and stable enough to get a good experience of the language, thanks to Xamarin who really invested a lot of efforts.
Microsoft is allegedly working on its open source implementation of .NET Framework and runtime, which just landed official F# support, but I think right now the experience and eco-system support has catch-up to do with what can be done with Mono.
Hope this helps!
There are also a bunch of F# centric projects (http://fsprojects.github.io/) which might help you to stay in mostly functional programming land and not mingle too much with OOP.
The main difficulty is to get runtime working well, I think Mono has come a long way and is now well packaged and stable enough to get a good experience of the language, thanks to Xamarin who really invested a lot of efforts.
Microsoft is allegedly working on its open source implementation of .NET Framework and runtime, which just landed official F# support, but I think right now the experience and eco-system support has catch-up to do with what can be done with Mono.
Hope this helps!
Anecdotally: I picked up Okasaki's book on Purely Functional Data Structures as a way of learning FP (to learn Haskell). All the examples were written in Standard ML, so I then started picking up SML. I heard that OCaml was more widely used than SML, so I tried OCaml. The libraries (which stdlib do I use? why is this JSON parsing lib so complex?), build toolchain (oasis? make? corebuild? ocamlbuild?), and cross-platform story of OCaml was another hurdle on top of just the language that I didn't want to deal with.
Ironically, I then jumped to F# since I figured at least the tooling had to be better (since it was a .NET language). I have zero experience with the .NET stack, and my entire use-case for Windows is "use Steam to stream games to my Linux machine hooked up to the TV."
The tooling in a non-VisualStudio, non-Windows way is actually pretty good; Installing Mono is easy, and from there I'd recommend grabbing Visual Studio Code and the Ionide plugin for it. (Or, if you're a vim guy like me, vim-fsharp is also pretty good).
Paket for dependency management is good and kinda like what you'd expect to see in the Ruby world, and and FAKE is a good build system so that you don't necessarily have to touch the nasty MSBuild stuff too much.
There's another project, Forge, in the works for automating away MSBuild's nonsense so that you don't have to deal with it (too much), which is good.
Ironically, I then jumped to F# since I figured at least the tooling had to be better (since it was a .NET language). I have zero experience with the .NET stack, and my entire use-case for Windows is "use Steam to stream games to my Linux machine hooked up to the TV."
The tooling in a non-VisualStudio, non-Windows way is actually pretty good; Installing Mono is easy, and from there I'd recommend grabbing Visual Studio Code and the Ionide plugin for it. (Or, if you're a vim guy like me, vim-fsharp is also pretty good).
Paket for dependency management is good and kinda like what you'd expect to see in the Ruby world, and and FAKE is a good build system so that you don't necessarily have to touch the nasty MSBuild stuff too much.
There's another project, Forge, in the works for automating away MSBuild's nonsense so that you don't have to deal with it (too much), which is good.
But why?
I mean, F# is a great language, but there are so much options for non-Windows systems with better tooling and ecosystem and larger communities etc.
F# is my primary language because it is the best on MS stack.
F# is my primary language because it is the best on MS stack.
F# depends on the .NET runtime for everything it does. Yes, you could write trivial programs in F# without delving far into .NET and its standard library. No, you can't go far beyond that without knowing stdlib APIs and using Microsoft's (or Mono's) implementations of said APIs.
This isn't a bad thing: knowing the runtime well is a very marketable skill, and helps you write better software anyway. See it as an opportunity rather than a liability.
This isn't a bad thing: knowing the runtime well is a very marketable skill, and helps you write better software anyway. See it as an opportunity rather than a liability.
Yes. I had experience with Scala which is another ML dialect, and that helped.
The more you end up using external libraries, the more you'll have to understand interop between F# and C#. That sort of thing bit me with Xamarin in the past, but it looks like it is getting better (I hope!).
The more you end up using external libraries, the more you'll have to understand interop between F# and C#. That sort of thing bit me with Xamarin in the past, but it looks like it is getting better (I hope!).
You don't need to learn either C# or Windows programming in general to use F# effectively. .NET is a different story, as it provides a lot of core functionality.
F# was the first cross-platform language from .NET, so it has better supported on OSX and Linux platforms.
F# was the first cross-platform language from .NET, so it has better supported on OSX and Linux platforms.
I have! Of course, I've only used F# with Unity3d.
2015 survey results https://docs.google.com/forms/d/1Ly_W1ZUH3x_ph4H6I_64uvEib2b...
I hope there will be more submissions this year!
I hope there will be more submissions this year!
IMHO, if you don't make a distinction between OCaml and SML languages, you should definitely not make a distiction between OCaml and F#.
I have a good experience with OCaml, and judging by most F# code I saw it seems F# and OCaml are much more similar than OCaml and SML.
Here you can see some examples comparing ML variants, which also illustrates my point a little further: http://hyperpolyglot.org/ml