I am betting on F# taking off big time.
None of the existing functional languages on linux could deliver on functional programming hype. Clojure is too ugly, Scala is too complicated, Haskell too arcane.
None of the existing functional languages on linux could deliver on functional programming hype. Clojure is too ugly, Scala is too complicated, Haskell too arcane.
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.
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.
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.
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-A...), but that's as much about great design of your project as well as what the project is making).
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.
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
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>
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>) // okAlso, F# is already in top 20 with relatively little fanfare.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
Rank 19. Clojure Rank 46. F#
Source https://jaxbot.me/articles/github-most-popular-languages
FWIW on that TIOBE list Delphi/Pascal is listed as more popular than F#.
This may not be the case in the world of enterprise, closed-source software.
Most of the enterprise projects are not even using Git!
And here is where OOP shines.. The probable "winners" of the languages of the next decade will be OOP ones that glue well with functional techniques and functional languages that are very good at OOP techniques.
F# is really good here, and from the OOP side C# and Java are also running for this trophy (again).
Maybe swift.. but we need to see if the adoption will have a limit, given its tied to a closed platform, and its also closed source
(But Rich Hickey is a bad ass and the framework design behind clojure is a piece of art)
The people in the Clojure community have already started exploring this issue. Component [1] [2], Jig [3], and others are trying to add just enough OOP back for the reasons you mentioned.
[1] https://github.com/stuartsierra/component
That is quite a while ago, back then it was mainly one guy who write a compiler, by kmow we have a awesome build and project tool, pretty good editor options, CSP, logic prrogramming, static typesystems, awesome validatiin librarys, a fantastic pattern match ...
In terms of organisation, I would suggest looking at the 'components' library, it takrs the good things of OOP design for things like managing services. Clojure has great namespaces also.
I'm a big fan of Clojure and a dabbler in OCaml/Haskell, and I feel that F# has a lot to offer in terms of library access, same as Clojure/Scala for the JVM. In any case, I'm certainly happy its there in case I ever have occasion to work with .NET.
I've seen Scala code styles within a wide spectrum of OO <---> FP, which can be both positive and negative. My only complaint, is that compilation takes longer than Java code. I learnt to live with it for now, and I am sure the Typesafe team are working hard to address it.
On my team we've got a mix of backgrounds. We've got people who've done Java, a gaggle of diehard Pythonistas, our CTO is a badass Rubyist, and I can't seem to shut the hell up about Haskell. Our Scala looks like it suffers from multiple personality disorder at times.
Scala: we like you. You don't have to try so hard to impress us. Just tell us how you really feel instead of trying to figure out what we want to hear.
I don't even use Clojure outside of Riemann for work but when I was learning Clojure the more I learned the more fantastic I felt it's syntax was.
I have also started investing a lot of my spare time into learning F# which I also really like. It's my first ML and the aspects that assist with domain modeling are fantastic(discriminated unions, option types, etc, etc). Fsharp interactive opens up a lot of possibilities too. While I like it's syntax better than Scala's and it's very terse, it still just bolstered my opinion on the elegance of Clojure.
The existing functional languages (which also notably include ocaml and common lisp on SBCL), "on linux", happen to also run on OS X, BSD, and some of them on Windows too. Could you really think those all suck, but F# is great?
If we discuss just tooling on windows, I heartily concur with the assessment that "F# delivers where other functional languages didn't".
I've tried those other languages. I've not yet met anything that would compare with the integration in Visual Studio with the F# command line, project tooling and the .Net ecosystem.
Unfortunately I've not tested F# on my Ubuntu boot, but on Windows as functional languages go it is an absolute joy to develop with. Clojure's toolchain comes pretty close, but not quite. For example, FFI to C is much nicer in .Net.
Whatever the overall company culture may be, Microsoft actually has lots of bright and well intending software folks working for them, and F# is clearly a labour of love brought to fruition there.
I would say F# is an implementation that includes all the good parts of Ocaml the language and .Net the ecosystem.
Very good tooling. A feasible multithreading story. Industry level support.
A pet of mine: Has ecosystem support for real time graphics (OpenTK, Monogame, etc).
I like F#, but this just isn't true:
- Polymorphic variants
- GADTs
- Module system
The last one, in particular, is one of the best features of OCaml.
Downside (on UNIX) will be that it fits in less with the UNIX philosophy than OCaml or Haskell will (though, with AOT compilation it will probably get closer).
F# can be used almost exactly like C#, and the ML-features can be used once understood.
While F# encourages immutability it can be used as a mutable language which means lots of familiar algorithms are easy to implement in it.