Dovrei imparare Haskell o F # se conosco già OCaml? [chiuso]

Question

Mi chiedo se dovrei continuare a imparare OCaml o passare a F # o Haskell.

Ecco i criteri che mi interessano di più:

• Longevità

  • Quale lingua durerà più a lungo? Non voglio imparare qualcosa che potrebbe essere abbandonato tra un paio d'anni da utenti e sviluppatori.
  • Inria, Microsoft, Università di Glasgow continueranno a supportare i rispettivi compilatori a lungo termine?

• La praticità

  • Articoli come this farmi paura di usare Haskell. Una tabella hash è la struttura migliore per il recupero rapido. I sostenitori di Haskell suggeriscono di usare Data.Map che è un albero binario.
  • Non mi piace essere legato a un framework .NET ingombrante a meno che i vantaggi non siano grandi.
  • Voglio essere in grado di sviluppare qualcosa di più di semplici parser e programmi di matematica.

• Ben progettato

  • Mi piace che le mie lingue siano coerenti.

Supporta la tua opinione con argomenti logici e citazioni da articoli. Grazie.

Answer 1

  

La longevità

• Haskell è di fatto il linguaggio dominante della ricerca di programmazione funzionale. Haskell 98 durerà per molti altri anni in forma stabile, e qualcosa chiamato Haskell potrebbe durare da 10 a 30 anni --- anche se la lingua continuerà ad evolversi. La comunità ha un grande investimento in Haskell e anche se domani i principali sviluppatori di GHC saranno colpiti da un autobus (il famoso problema "errore del bus a Cambridge"), ce ne sono molti altri che possono salire sul piatto. Ci sono anche altri compilatori meno elaborati.

• Caml è controllato da un piccolo gruppo all'INRIA, il laboratorio nazionale francese. Hanno anche un investimento significativo, altri sono anche investiti in Caml, e il codice è open source, e il compilatore non è troppo complicato, quindi anche questo verrà mantenuto a lungo. Prevedo che Caml sarà molto più stabile di Haskell, poiché la gente di INRIA sembra non usarlo più come veicolo per esplorare nuove idee linguistiche (o almeno lo stanno facendo a un ritmo inferiore rispetto al passato).

• Chi sa cosa farà un'azienda? Se F # ha esito positivo, Microsoft potrebbe supportarlo per 20 anni. Se non ha successo, potrebbero staccare la spina nel 2012. Non posso immaginare e non ci proverò.

  

La praticità

     

    

Una tabella hash è la struttura migliore per il recupero veloce. I sostenitori di Haskell suggeriscono di usare Data.Map che è un albero binario.

  

Dipende da cosa stai cercando. Quando le tue chiavi sono stringhe, alberi di ricerca ternari sono spesso più veloci delle tabelle hash. Quando le tue chiavi sono numeri interi, Okasaki e Gill's alberi binari di Patricia sono competitivi con l'hashing. Se vuoi davvero, puoi costruire una tabella hash in Haskell usando la monade IO, ma è raro averne bisogno.

Penso che ci sarà sempre una penalità per la valutazione pigra. Ma "pratico" non è uguale a "il più veloce possibile". Quanto segue è vero riguardo alle prestazioni:

• È più semplice prevedere il comportamento temporale e spaziale di un programma Caml.

• F # è nel mezzo (chissà cosa faranno .NET e JIT?).

• È più difficile prevedere il comportamento temporale e spaziale dei programmi Haskell.

• Haskell ha i migliori strumenti di profilazione e, a lungo termine, questo è ciò che offre le migliori prestazioni.

  

Voglio essere in grado di sviluppare qualcosa di più di semplici parser e programmi di matematica.

Per un'idea della gamma di ciò che è possibile in Haskell, dai un'occhiata al xmonad e al vasta gamma di pacchetti all'indirizzo < code> hackage.haskell.org .

  

Non mi piace essere legato a un framework .NET ingombrante a meno che i vantaggi non siano grandi.

Non posso commentare:

  

Ben progettato

     

    

Mi piace che le mie lingue siano coerenti.

  

Alcuni punti su cui valutare la coerenza:

• La sintassi concreta di Haskell è estremamente ben progettata; Sono continuamente impressionato dal buon lavoro svolto dal comitato Haskell. La sintassi OCaml è OK ma risente del confronto. F # è iniziato dalla sintassi principale di Caml e presenta molte somiglianze.

• Haskell e OCaml hanno entrambi storie molto coerenti sul sovraccarico dell'operatore. Haskell ha un meccanismo coerente e potente che puoi estendere. OCaml non ha alcun sovraccarico di alcun tipo.

• OCaml ha il sistema di tipi più semplice, specialmente se non scrivi oggetti e funzioni (cosa che molti programmatori Caml non fanno, anche se mi sembra folle non scrivere funzioni se stai scrivendo ML). Il sistema di tipi di Haskell è ambizioso e potente, ma viene continuamente migliorato, il che significa che c'è una certa incoerenza a causa della storia. F # utilizza essenzialmente il sistema di tipo .NET, oltre al polimorfismo Hindley-Milner simile a ML (Vedi domanda " Che cos'è Hindley-Milner ". )

• OCaml non è abbastanza coerente sul fatto che pensi che le varianti debbano essere tipizzate staticamente o dinamicamente, quindi fornisce entrambi ("tipi di dati algebrici" e "varianti polimorfiche"). Il linguaggio che ne risulta ha un grande potere espressivo, il che è ottimo per gli esperti, ma quale costruzione usare non è sempre ovvio per l'amatore.

• L'ordine di valutazione di OCaml è ufficialmente indefinito, che è una cattiva scelta progettuale in una lingua con effetti collaterali. Peggio ancora, le implementazioni sono incoerenti: la macchina virtuale codificata usa un ordine e il compilatore con codice nativo usa l'altro.

Answer 2

Should you learn F# or Haskell if you know OCaml?

I believe the answer is certainly yes, ideally you should learn all three languages because each one has something to offer but F# is the only one with a significant future so, if you can only feasibly learn one language, learn F# by reading my Visual F# 2010 for Technical Computing book or subscribing to our The F#.NET Journal.

Longevity

Microsoft committed to supporting F# when they released it as part of Visual Studio 2010 in April. So F# is guaranteed a rosy future for at least a few years. With a powerful combination of practically-important features like a high performance native-code REPL, high-level constructs for parallelism built-in to .NET 4 and a production-quality IDE mode, F# is a long way ahead of any other functional programming language in terms of real world applicability now. Frankly, nobody is even working on anything that might be able to compete with F# in the near future. My own open source HLVM project is an attempt to do so but it is far from ready.

In contrast, both OCaml and Haskell are being developed in extremely unproductive directions. This has been killing OCaml for several years now and I expect Haskell to follow suit over the next few years. Most former professional OCaml and Haskell programmers already moved on to F# (e.g. Credit Suisse, Flying Frog Consultancy) and most of the rest will doubtless migrate to more practical alternatives such as Clojure and Scala in the near future.

Specifically, OCaml's QPL license prevents anyone else from fixing its growing number of fundamental design flaws (16Mb string and array limits on 32-bit machines, no shared-memory parallelism, no value types, parametric polymorphism via type erasure, interpreted REPL, cumbersome FFI etc.) because they must distribute derivative works only in the form of patches to the original and the Debian package maintainers refuse to acknowledge an alternative upstream. The new features being added to the language, such as first-class modules in OCaml 3.12, are nowhere near as valuable as multicore capability would have been.

Some projects were started in an attempt to save OCaml but they proved to be too little too late. The parallel GC is practically useless and David Teller quit the batteries included project (although it has been picked up and released in a cut-down form). Consequently, OCaml has gone from being the most popular functional language in 2007 to severe decline today, with caml-list traffic down over 50% since 2007.

Haskell has fewer industrial users than OCaml and, although it does have multicore support, it is still being developed in a very unproductive direction. Haskell is developed almost entirely by two people at Microsoft Research in Cambridge (UK). Despite the fact that purely functional programming is bad for performance by design, they are continuing to try to develop solutions for parallel Haskell aimed at multicores when the massive amounts of unnecessary copying it incurs hits the memory wall and destroys any hope of scalable parallelism on a multicore.

The only major user of Haskell in industry is Galois with around 30 full-time Haskell programmers. I doubt they will let Haskell die completely but that does not mean they will develop it into a more generally-useful language.

Practicality

I wrote the article you cited about hash tables. They are a good data structure. Other people have referred to purely functional alternatives like ternary trees and Patricia trees but these are usually ~10× slower than hash tables in practice. The reason is simply that cache misses dominate performance concerns today and trees incur an extra O(log n) pointer indirections.

My personal preference is for optional laziness and optional purity because both are generally counter productive in the real world (e.g. laziness makes performance and memory consumption wildly unpredictable and purity severely degrades average-case performance and makes interoperability a nightmare). I am one of the only people earning a living entirely from functional programming through my own company. Suffice to say, if I thought Haskell were viable I would have diversified into it years ago but I keep choosing not to because I do not believe it is commercially viable.

You said "I don't like being tied to a bulky .NET framework unless the benefits are large". The benefits are huge. You get a production-quality IDE, a production-quality JIT compiler that performs hugely-effective optimizations like type-specializing generics, production-quality libraries for everything from GUI programming (see Game of Life in 32 lines of F#) to number crunching. But the real benefit of .NET, at least for me, is that you can sell the libraries that you write in F# and earn lots of money. Nobody has ever succeeded selling libraries to OCaml and Haskell programmers (and I am one of the few people to have tried) but F# libraries already sell in significant quantities. So the bulky .NET framework is well worth it if you want to earn a living by writing software.

Well designed

These languages are all well designed but for different purposes. OCaml is specifically designed for writing theorem provers and Haskell is specifically designed for researching Haskell. F# was designed to address all of the most serious practical problems with OCaml and Haskell such as poor interoperability, lack of concurrent garbage collection and lack of mature modern libraries like WPF in order to bring a productive modern language to a large audience.

Answer 3

This wasn't one of your criteria but have you considered job availability? Haskell currently list 144 jobs on indeed, Ocaml list 12 and C# list 26,000. These numbers are not perfect but I bet you that once F# ships it won't be long before it blows past Haskell and Ocaml in the number of job listings.

So far every programming language included in Visual Studios has thousands of job listings for it. Seems to me that if you want the best chance to use a functional programming language as your day job then F# will soon be it.

Answer 4

Longevity

No one can predict the future, but

• OCaml and Haskell have been surving well for a number of years, which bodes well for their future
• when F# ships with VS2010, MS will have legal obligations to support it for at least 5 years

Practicality

Perf: I don't have enough first-hand experience with Haskell, but based on second-hand and third-hand info, I think OCaml or F# are more pragmatic, in the sense that I think it is unlikely you'll be able to get the same run-time perf in Haskell that you do in OCaml of F#.

Libraries: Easy access to the .Net Framework is a huge benefit of F#. You can view it as being "tied to this bulky thing" if you like, but don't forget that "you have access to a huge bulky library of often incredibly useful stuff". The 'connectivity' to .Net is one of the big selling points for F#. F# is younger and so has fewer third-party libraries, but there is already e.g. FsCheck, FParsec, Fake, and a bunch of others, in addition to the libraries "in the box" on .Net.

Tooling: I don't have enough personal experience to compare, but I think the VS integration with F# is superior to anything you'll find for OCaml/Haskell today (and F# will continue to improve a bit here over the next year).

Change: F# is still changing as it approaches its first supported release in VS2010, so there are some breaking changes to language/library you may have to endure in the near future.

Well Designed

Haskell is definitely beautiful and consistent. I don't know enough OCaml but my hunch is it is similarly attractive. I think that F# is 'bigger' than either of those, which means more dusty corners and inconsistencies (largely as a result of mediating the impedence mismatch between FP and .Net), but overall F# still feels 'clean' to me, and the inconsistencies that do exist are at least well-reasoned/intentioned.

Overall

In my opinion you will be in 'good shape' knowing any of these three languages well. If you know a big long-term project you want to use it for, one may stand out, but I think many of the skills will be transferable (more easily between F# and OCaml than to/from Haskell, but also more easily among any of these three than with, say, Java).

Answer 5

There's no simple answer to that question, but here are some things to consider:

Haskell and OCaml are both mature languages with strong implementations. Actually, there are multiple good implementations of Haskell, but I don't think that's a major point in its favor for your purpose.

F# is much younger, and who can predict where Microsoft will decide to take it? How you feel about that depends more on how you feel about Microsoft than anything anyone can tell you about programming languages.

OCaml (or ML in general), is a good practical language choice that supports doing cool functional stuff without forcing you to work in a way that might be uncomfortable. You get the full benefit of things like algebraic data types, pattern matching, type inference, and everybody else's favorite stuff. Oh, and objects.

Haskell gives you all that (except objects, pretty much), but also more or less forces you to rethink everything you think you know about programming. This might be a very good thing, if you're looking to learn something new, but it might be more than you want to bite off. I say this as someone who is only maybe halfway along the path to being a productive, happy Haskell programmer.

Both OCaml and Haskell are being used to write lots of different kinds of programs, not just compilers and AI or whatever. Google is your friend.

One last note: OCaml gives you hashtable, but it's hardly sensible to use it in code if you really want to embrace functional programming. Persistent trees (like Data.Map) are really the right solution for Haskell, and have lots of nice properties, which is one of the cool things to learn about when you pick up Haskell.

Answer 6

F# and OCaml are very similar in syntax, though, obviously, F# is better with .NET.

Which one you learn or use should be dependent on which platform you are aiming for.

In VS2010 F# is going to be included, and since it compiles to .NET bytecode, it can be used on a windows OS that supports the .NET version you used for it. This will give you a large area, but there are limits, currently with F# that OCaml don't have, in that F# appears not to take advantage of all the processors on a machine, but, that is probably due to F# still being developed, and this may be a feature that isn't as important yet.

There are other functional languages, such as Erlang that you could look at, but, basically, if you are strong in one FP language then you should be able to pick up another fairly quickly, so, just pick one that you like and try to develop interesting and challenging applications in it.

Eventually language writers will find a way to get OO languages to work well with multi-cores and FP may fall to the wayside again, but, that doesn't appear to be happening anytime soon.

Answer 7

This is not directly related to the OP's question as to whether or not to learn F#, but rather, an example of real world OCaml usage in the financial sector: http://ocaml.janestreet.com/?q=node/61

Very interesting talk.

Answer 8

In terms of longevity, it's very difficult to judge popularity of languages, but just doing a quick check on here, these are the numbers of questions tagged with the appropriate (functional) language :-

2672 Scala, 1936 Haskell, 1674 F#, 1126 Clojure, 709 Scheme, 332 OCaml

I'd say this was a good indication of which languages people are actively learning at the moment and therefore might be a good indication of which ones might be popular in the next few years.