4 ms·

I thought the same too, back when I really started into F# (2007 or so). But is it really taking off? People are still scared, worried that "it's hard to unders

I thought the same too, back when I really started into F# (2007 or so). But is it really taking off? People are still scared, worried that "it's hard to understand" (despite it being the opposite). Or that "it's hard to find F# developers" (which isn't true, a: anyone good can easily pick it up, b: advertising F#, like Haskell, will get a lot of people to fight for the jobs since it's rare to get paid to work with a great language). Microsoft itself does not seem to give F# much resources. It's there, they've made some feature additions, improved VS support a bit. But not even 10% of what the C# team has for features. Microsoft refrains from telling people "you should use F#" which is good advice for all but the most terrible of enterprise environments. F# is amazing because it's a solid language with great tooling support and fantastic interop (C, .NET) for excellent library access. I honestly believe there's nothing that quite matches it. Scala might be closest with tooling and JVM access.

chii 12y ago
> anyone good can easily pick it up with emphasis on 'good'. A SME might not have 'anyone good', and if it's just a back office data entry application, you don't want to use F# (or any of them fancy stuff). You want something any dumb coder can change and add to.
- fsloth 12y ago
  A subset of F# can be used (more or less) as a terser C#. Functional languages make writing correct programs easier. I don't think modifiability of an existing program depends on the language as much from the quality of the code. F# is not difficult, just a bit different. Functional languages seem to have this odd halo around them that for some reason they are thought to be obscure and non practical. It's probably due to a historical baggage. If Ruby was originally picked up by compiler experts and language afficionados and the only resources that one could find were references to topics in those domains I bet people would be saying the same thing about it. The main problem for adoption IMO is not language complexity, but rather lack of educational resources that display how easy and nice it's to do simple things on the language. But since the simple things are so nice and easy it's really straightforward to do something a bit more complex and most of the published examples focus on these more advanced things.
  - hga 12y ago
    I would suspect that learning functional programming itself, after pretty much everyone gets started with imperative, could take as much effort as learning OO from the same imperative base (but of course a lot more people now start with something like Python and at least dabble with OO). I.e. more than an afternoon or probably a month to get good, vs. the few days it takes to learn another language with familiar paradigms. Not sure from personal experience because I learned functional style Lisp/Scheme really early, more than a decade before OO, which made learning Clojure a relative snap. OO in the form of C++ was harder for me, but maybe functional is just easier for my mind to wrap around. The quality of the Lisp and Scheme texts I used, especially SICP, also probably made a difference (the OO texts I used were good, but not as great, with the exception of OOSE (http://www.amazon.com/Object-Oriented-Software-Engineering-Approach/dp/0201544350/ http://www.amazon.com/Object-Oriented-Software-Engineering-A...), but that's as much about great design of your project as well as what the project is making).
pjmlp 12y ago
> But is it really taking off? In Europe yes. Check Skills Matter webcasts, Norwegian Developers Conference or Øredev. It is mainly used at financial and insurance industries for data modeling and big data. This is why type providers were so big for the language. > Microsoft refrains from telling people "you should use F#" which is good advice for all but the most terrible of enterprise environments. I already saw some presentations where this was explained as not wanting to scare the traditional enterprise guys. I kind of understand them, for our customers JVM == Java, .NET == C# or .NET == VB.NET for projects that used to be VB 6 shops. So how to sell F# to these guys? By making it easy to integrate into their exiting code, as library code not full stack replacements.
CmonDev 12y ago
It just doesn't have too many selling points for an enterprise app today. I have looked at it many times but it doesn't offer enough for me to start persuading people to switch. Terse ML-based syntax, lack of ReSharper and C# moving towards the functional side all make F# a less attractive choice. And I don't care about type-providers and all that other jazz they are adding lately too much. I tried to be excited about units of measure, but there isn't even a way to annotate third-party libraries (no, I am not going to rewrite e.g. third-party physics libraries from scratch)!
- latkin 12y ago
  You can certainly annotate 3rd-party libraries. You basically just copy the signatures of the relevant APIs, and decorate arg types and return types with units that enforce the semantics of the problem domain. Say you have some unit-free external library like this, which you can't modify: type RectLib = static member Perimiter(w:int, h:int) = 2*w + 2*h static member Area(w:int, h:int) = w * h Wouldn't it be great if we could enforce in our code that `w` and `h` have the same units? Or that the result of `Area` has squared units compared to the result of `Perimiter`? You can do exactly that, by defining extensions like so: module UnitExtensions = open LanguagePrimitives type RectLib with static member Perimiter(w:int<'u>, h:int<'u>) = RectLib.Perimiter(int w, int h) |> Int32WithMeasure<'u> static member Area(w:int<'u>, h:int<'u>) = RectLib.Area(int w, int h) |> Int32WithMeasure<'u^2> Now units are enforced by the type system: open UnitExtensions RectLib.Perimiter(1<m>, 2<ft>) // error - <m> doesn't match <ft> RectLib.Perimiter(3<m>, 4<m>) // ok RectLib.Area(5<m>, 6<m>) + RectLib.Perimiter(7<m>, 8<m>) // error - <m> doesn't match <m^2> RectLib.Area(9<ft>, 10<ft>) + RectLib.Area(11<m>, 12<m>) // error - <ft^2> doesn't match <m^2> RectLib.Area(9<ft>, 10<ft>) + RectLib.Area(11<ft>, 12<ft>) // ok
  - CmonDev 12y ago
    What about third party types?
    - 12y ago

chii 12y ago

> anyone good can easily pick it up with emphasis on 'good'. A SME might not have 'anyone good', and if it's just a back office data entry application, you don't want to use F# (or any of them fancy stuff). You want something any dumb coder can change and add to.

fsloth 12y ago
A subset of F# can be used (more or less) as a terser C#. Functional languages make writing correct programs easier. I don't think modifiability of an existing program depends on the language as much from the quality of the code. F# is not difficult, just a bit different. Functional languages seem to have this odd halo around them that for some reason they are thought to be obscure and non practical. It's probably due to a historical baggage. If Ruby was originally picked up by compiler experts and language afficionados and the only resources that one could find were references to topics in those domains I bet people would be saying the same thing about it. The main problem for adoption IMO is not language complexity, but rather lack of educational resources that display how easy and nice it's to do simple things on the language. But since the simple things are so nice and easy it's really straightforward to do something a bit more complex and most of the published examples focus on these more advanced things.
- hga 12y ago
  I would suspect that learning functional programming itself, after pretty much everyone gets started with imperative, could take as much effort as learning OO from the same imperative base (but of course a lot more people now start with something like Python and at least dabble with OO). I.e. more than an afternoon or probably a month to get good, vs. the few days it takes to learn another language with familiar paradigms. Not sure from personal experience because I learned functional style Lisp/Scheme really early, more than a decade before OO, which made learning Clojure a relative snap. OO in the form of C++ was harder for me, but maybe functional is just easier for my mind to wrap around. The quality of the Lisp and Scheme texts I used, especially SICP, also probably made a difference (the OO texts I used were good, but not as great, with the exception of OOSE (http://www.amazon.com/Object-Oriented-Software-Engineering-Approach/dp/0201544350/ http://www.amazon.com/Object-Oriented-Software-Engineering-A...), but that's as much about great design of your project as well as what the project is making).

pjmlp 12y ago

> But is it really taking off? In Europe yes. Check Skills Matter webcasts, Norwegian Developers Conference or Øredev. It is mainly used at financial and insurance industries for data modeling and big data. This is why type providers were so big for the language. > Microsoft refrains from telling people "you should use F#" which is good advice for all but the most terrible of enterprise environments. I already saw some presentations where this was explained as not wanting to scare the traditional enterprise guys. I kind of understand them, for our customers JVM == Java, .NET == C# or .NET == VB.NET for projects that used to be VB 6 shops. So how to sell F# to these guys? By making it easy to integrate into their exiting code, as library code not full stack replacements.

CmonDev 12y ago

It just doesn't have too many selling points for an enterprise app today. I have looked at it many times but it doesn't offer enough for me to start persuading people to switch. Terse ML-based syntax, lack of ReSharper and C# moving towards the functional side all make F# a less attractive choice. And I don't care about type-providers and all that other jazz they are adding lately too much. I tried to be excited about units of measure, but there isn't even a way to annotate third-party libraries (no, I am not going to rewrite e.g. third-party physics libraries from scratch)!

latkin 12y ago
You can certainly annotate 3rd-party libraries. You basically just copy the signatures of the relevant APIs, and decorate arg types and return types with units that enforce the semantics of the problem domain. Say you have some unit-free external library like this, which you can't modify: type RectLib = static member Perimiter(w:int, h:int) = 2*w + 2*h static member Area(w:int, h:int) = w * h Wouldn't it be great if we could enforce in our code that `w` and `h` have the same units? Or that the result of `Area` has squared units compared to the result of `Perimiter`? You can do exactly that, by defining extensions like so: module UnitExtensions = open LanguagePrimitives type RectLib with static member Perimiter(w:int<'u>, h:int<'u>) = RectLib.Perimiter(int w, int h) |> Int32WithMeasure<'u> static member Area(w:int<'u>, h:int<'u>) = RectLib.Area(int w, int h) |> Int32WithMeasure<'u^2> Now units are enforced by the type system: open UnitExtensions RectLib.Perimiter(1<m>, 2<ft>) // error - <m> doesn't match <ft> RectLib.Perimiter(3<m>, 4<m>) // ok RectLib.Area(5<m>, 6<m>) + RectLib.Perimiter(7<m>, 8<m>) // error - <m> doesn't match <m^2> RectLib.Area(9<ft>, 10<ft>) + RectLib.Area(11<m>, 12<m>) // error - <ft^2> doesn't match <m^2> RectLib.Area(9<ft>, 10<ft>) + RectLib.Area(11<ft>, 12<ft>) // ok
- CmonDev 12y ago
  What about third party types?
  - 12y ago