¿Debo aprender Haskell o F # si ya conozco OCaml? [cerrado]

StackOverflow https://stackoverflow.com/questions/822752

Pregunta

Me pregunto si debo seguir aprendiendo OCaml o cambiar a F # o Haskell.

Estos son los criterios que más me interesan:

Por favor, apoya tu opinión con argumentos lógicos y citas de artículos. Gracias.

¿Fue útil?

Solución

  

Longevidad

  • Haskell es de facto el lenguaje dominante de la investigación de programación funcional. Haskell 98 durará muchos años más en forma estable, y algo que se llama Haskell puede durar de 10 a 30 años, aunque el lenguaje continuará evolucionando. La comunidad tiene una gran inversión en Haskell e incluso si los principales desarrolladores de GHC son golpeados por un autobús mañana (el famoso "error de autobús en el problema de Cambridge"), hay muchos otros que pueden ponerse al día. También hay otros compiladores menos elaborados.

  • Caml está controlada por un pequeño grupo en INRIA, el laboratorio nacional francés. También tienen una inversión significativa, los demás también se invierten en Caml, y el código es de código abierto, y el compilador no es demasiado complicado, por lo que también se mantendrá durante mucho tiempo. Predigo que Caml será mucho más estable que Haskell, ya que la gente de INRIA parece que ya no lo está utilizando como un vehículo para explorar nuevas ideas de lenguaje (o al menos lo están haciendo a un ritmo menor que en el pasado). p>

  • ¿Quién sabe qué hará una empresa? Si F # tiene éxito, Microsoft podría soportarlo durante 20 años. Si no tiene éxito, podrían desconectarlo en 2012. No puedo adivinar y no lo intentaré.

  

practicidad

     
    

Una tabla hash es la mejor estructura para una recuperación rápida. Los defensores de Haskell que están allí sugieren utilizar Data.Map, que es un árbol binario.

  

Depende de lo que estés buscando. Cuando sus claves son cadenas, árboles de búsqueda ternarios a menudo son más rápidos que las tablas hash. Cuando sus claves son enteros, Okasaki y Gill árboles binarios de Patricia son competitivos con hash. Si realmente quieres, puedes crear una tabla hash en Haskell usando la mónada IO, pero es raro que sea necesario.

Creo que siempre habrá una penalización de rendimiento para la evaluación perezosa. Pero " práctico " no es lo mismo que " lo más rápido posible " ;. Lo siguiente es cierto sobre el rendimiento:

  • Es más fácil predecir el comportamiento de tiempo y espacio de un programa Caml.

  • F # está en el medio (¿quién sabe realmente lo que hará .NET y el JIT?).

  • Es más difícil predecir el comportamiento de tiempo y espacio de los programas Haskell.

  • Haskell tiene las mejores herramientas de creación de perfiles y, a largo plazo, esto es lo que produce el mejor rendimiento.

  

Quiero poder desarrollar algo más que analizadores y programas de matemáticas.

Para tener una idea del rango de lo que es posible en Haskell, echa un vistazo al administrador de ventanas xmonad y gran variedad de paquetes en < código> hackage.haskell.org .

  

No me gusta estar atado a un gran marco .NET a menos que los beneficios sean grandes.

No puedo comentar:

  

Bien diseñado

     
    

Me gusta que mis idiomas sean consistentes.

  

Algunos puntos para evaluar la consistencia:

  • La sintaxis concreta de Haskell está extremadamente bien diseñada; Estoy continuamente impresionado por el buen trabajo realizado por el comité de Haskell. La sintaxis de OCaml está bien pero sufre por comparación. F # comenzó a partir de la sintaxis del núcleo de Caml y tiene muchas similitudes.

  • Haskell y OCaml tienen historias muy consistentes sobre la sobrecarga de operadores. Haskell tiene un mecanismo consistente y poderoso que puedes extender. OCaml no tiene sobrecarga de ningún tipo.

  • OCaml tiene el sistema de tipos más simple, especialmente si no escribes objetos y funtores (lo que no hacen muchos programadores de Caml, aunque me parece una locura no escribir funtores si estás escribiendo ML). El sistema de tipos de Haskell es ambicioso y poderoso, pero se mejora continuamente, lo que significa que hay alguna inconsistencia como resultado de la historia. F # utiliza esencialmente el sistema de tipo .NET, más el polimorfismo Hindley-Milner tipo ML (vea la pregunta " ¿Qué es? Hindley-Milner " .)

  • OCaml no es del todo coherente con respecto a si cree que las variantes deben tipificarse estáticamente o dinámicamente, por lo que proporciona ambos ("tipos de datos algebraicos" y "variantes polimórficas"). El lenguaje resultante tiene una gran cantidad de poder expresivo, lo cual es genial para los expertos, pero su construcción no siempre es obvia para el aficionado.

  • El orden de evaluación de OCaml está oficialmente indefinido, lo cual es una mala elección de diseño en un idioma con efectos secundarios. Peor aún, las implementaciones son inconsistentes: la máquina virtual bytecoded usa un orden y el compilador de código nativo usa el otro.

Otros consejos

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.

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.

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).

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.

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.

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.

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.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top