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

language-comparisons (8)

¿Debes aprender F # o Haskell si conoces OCaml?

Creo que la respuesta es ciertamente sí, lo ideal es que aprendas los tres idiomas porque cada uno tiene algo que ofrecer, pero F # es el único con un futuro significativo, así que, si solo puedes aprender un idioma, aprende F # leyendo mi Visual F # 2010 para el libro de Informática Técnica o para suscribirse a nuestro The F # .NET Journal .

Longevidad

Microsoft se comprometió a admitir F # cuando lo lanzaron como parte de Visual Studio 2010 en abril. Así que F # tiene garantizado un futuro prometedor por al menos unos años. Con una poderosa combinación de características prácticas importantes como un REPL de código nativo de alto rendimiento, construcciones de alto nivel para paralelismo incorporadas a .NET 4 y un modo IDE de calidad de producción, F # está muy por delante de cualquier otra programación funcional El lenguaje en términos de aplicabilidad en el mundo real ahora. Francamente, nadie está trabajando en algo que pueda competir con F # en un futuro próximo. Mi propio proyecto HLVM código abierto es un intento de hacerlo, pero está lejos de estar listo.

En contraste, tanto OCaml como Haskell se están desarrollando en direcciones extremadamente improductivas. Esto ha estado matando a OCaml durante varios años y espero que Haskell siga su ejemplo en los próximos años. La mayoría de los ex programadores profesionales de OCaml y Haskell ya pasaron a F # (por ejemplo, Credit Suisse, Flying Frog Consultancy) y la mayoría del resto sin duda migrará a alternativas más prácticas como Clojure y Scala en un futuro próximo.

Específicamente, la licencia QPL de OCaml evita que cualquier otra persona corrija su creciente número de fallas de diseño fundamentales (límites de cadena y matriz de 16Mb en máquinas de 32 bits, sin paralelismo de memoria compartida, sin tipos de valores, polimorfismo paramétrico mediante borrado de tipo, REPL interpretado, FF incómodo etc.) porque deben distribuir trabajos derivados solo en forma de parches al original y los mantenedores de paquetes de Debian se niegan a reconocer una alternativa ascendente. Las nuevas características que se agregan al lenguaje, como los módulos de primera clase en OCaml 3.12, no son tan valiosas como lo habría sido la capacidad de múltiples núcleos.

Algunos proyectos se iniciaron en un intento por salvar OCaml, pero demostraron ser demasiado tarde. El GC paralelo es prácticamente inútil y David Teller abandonó el proyecto de baterías incluidas (aunque ha sido recogido y lanzado en forma recortada). En consecuencia, OCaml ha pasado de ser el lenguaje funcional más popular en 2007 a un grave declive en la actualidad, ya que el tráfico de caml-list se redujo en más del 50% desde 2007 .

Haskell tiene menos usuarios industriales que OCaml y, aunque tiene soporte para múltiples núcleos, aún se está desarrollando en una dirección muy improductiva. Haskell está desarrollado casi en su totalidad por dos personas en Microsoft Research en Cambridge (Reino Unido). A pesar del hecho de que la programación puramente funcional es mala para el rendimiento por diseño, continúan intentando desarrollar soluciones para Haskell en paralelo dirigidas a los multinúcleos cuando las enormes cantidades de copias innecesarias en las que incurre llegan a la memoria y destruyen cualquier esperanza de paralelismo escalable en un multinúcleo

El único usuario importante de Haskell en la industria es Galois con alrededor de 30 programadores de Haskell de tiempo completo. Dudo que dejen que Haskell muera por completo, pero eso no significa que lo desarrollen en un lenguaje más útil en general.

Sentido práctico

Escribí el artículo que citaste sobre tablas hash. Son una buena estructura de datos. Otras personas se han referido a alternativas puramente funcionales como los árboles ternarios y los árboles de Patricia, pero en la práctica estas son generalmente ~ 10 × más lentas que las tablas hash. La razón es simplemente que las fallas en la memoria caché dominan los problemas de rendimiento hoy en día y los árboles incurren en indirecciones de puntero O (log n) adicionales.

Mi preferencia personal es por la holgazanería opcional y la pureza opcional porque, en general, ambas son contraproducentes en el mundo real (por ejemplo, la pereza hace que el rendimiento y el consumo de memoria sean impredecibles y la pureza degrada el rendimiento promedio de la caja y hace que la interoperabilidad sea una pesadilla). Soy una de las únicas personas que se gana la vida por completo de la programación funcional a través de mi propia empresa. Basta con decir que, si creía que Haskell era viable, lo habría diversificado hace años, pero sigo eligiendo no hacerlo porque no creo que sea comercialmente viable.

Usted dijo "No me gusta estar atado a un abultado framework .NET a menos que los beneficios sean grandes". Los beneficios son enormes. Obtiene un IDE de calidad de producción, un compilador JIT de calidad de producción que realiza optimizaciones enormemente efectivas, como genéricos especializados en tipos, bibliotecas de calidad de producción para todo, desde la programación de GUI (consulte Game of Life en 32 líneas de F # ) hasta el procesamiento de números. Pero el beneficio real de .NET, al menos para mí, es que puedes vender las bibliotecas que escribes en F # y ganar mucho dinero. Nadie ha logrado vender bibliotecas a los programadores de OCaml y Haskell (y soy una de las pocas personas que lo han intentado), pero las bibliotecas de F # ya se venden en cantidades significativas. Así que el abultado .NET framework vale la pena si quieres ganarte la vida escribiendo software.

Bien diseñado

Estos idiomas están todos bien diseñados pero para diferentes propósitos. OCaml está diseñado específicamente para escribir probadores de teoremas y Haskell está diseñado específicamente para investigar Haskell. F # fue diseñado para abordar todos los problemas prácticos más graves con OCaml y Haskell, como la interoperabilidad deficiente, la falta de recolección de basura simultánea y la falta de bibliotecas modernas y maduras como WPF para brindar un lenguaje moderno y productivo a una gran audiencia.

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

Estos son los criterios que más me interesan:

Longevidad
- ¿Qué idioma durará más? No quiero aprender algo que pueda ser abandonado en un par de años por usuarios y desarrolladores.
- ¿Inria, Microsoft y la Universidad de Glasgow continuarán apoyando a sus respectivos compiladores a largo plazo?
Sentido práctico
- Artículos como this me dan miedo de usar Haskell. Una tabla hash es la mejor estructura para una recuperación rápida. Los defensores de Haskell sugieren utilizar Data.Map, que es un árbol binario.
- No me gusta estar atado a un abultado framework .NET a menos que los beneficios sean grandes.
- Quiero poder desarrollar algo más que analizadores y programas de matemáticas.
Bien diseñado
- Me gusta que mis idiomas sean consistentes.

Por favor apoye su opinión con argumentos lógicos y citas de artículos. Gracias.

Longevidad

Nadie puede predecir el futuro, pero

OCaml y Haskell han estado saliendo bien durante varios años, lo que es un buen augurio para su futuro.
cuando F # se envíe con VS2010, MS tendrá la obligación legal de mantenerlo durante al menos 5 años

Sentido práctico

Perf: no tengo suficiente experiencia de primera mano con Haskell, pero según la información de segunda mano y de tercera mano, creo que OCaml o F # son más pragmáticos, en el sentido de que creo que es poco probable que puedas para obtener el mismo rendimiento en tiempo de ejecución en Haskell que haces en OCaml of F #.

Bibliotecas: el fácil acceso a .Net Framework es un gran beneficio de F #. Puedes verlo como "atado a esta cosa voluminosa" si quieres, pero no olvides que "tienes acceso a una enorme biblioteca voluminosa de cosas a menudo increíblemente útiles". La ''conectividad'' a .Net es uno de los grandes puntos de venta para F #. F # es más joven y, por lo tanto, tiene menos bibliotecas de terceros, pero ya FsCheck , por ejemplo, FsCheck , FParsec , Fake y FParsec otras, además de las bibliotecas "en la caja" en .Net.

Herramientas: No tengo suficiente experiencia personal para comparar, pero creo que la integración de VS con F # es superior a lo que encontrará hoy para OCaml / Haskell (y F # continuará mejorando un poco aquí durante el próximo año).

Cambio: F # sigue cambiando a medida que se acerca a su primera versión compatible en VS2010, por lo que hay algunos cambios de última hora en el idioma / biblioteca que puede tener que soportar en un futuro próximo.

Bien diseñado

Haskell es definitivamente hermoso y consistente. No sé lo suficiente, pero mi corazonada es que es igualmente atractiva. Creo que F # es ''más grande'' que cualquiera de los dos, lo que significa más rincones polvorientos e inconsistencias (en gran parte como resultado de la mediación de la falta de coincidencia de impedancia entre FP y .Net), pero en general F # todavía me parece ''limpio'', y el las inconsistencias que existen son al menos bien razonadas / intencionadas.

En general

En mi opinión, estará en "buena forma" si conoce alguno de estos tres idiomas. Si conoce un gran proyecto a largo plazo para el cual quiere usarlo, uno puede sobresalir, pero creo que muchas de las habilidades serán transferibles (más fácilmente entre F # y OCaml que a / desde Haskell, pero también más fácilmente entre cualquier de estos tres que con, digamos, Java).

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á controlado 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á usando 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).
¿Quién sabe lo que hará una empresa? Si F # tiene éxito, Microsoft podría soportarlo durante 20 años. Si no tiene éxito, podrían desconectar el 2012. No puedo adivinar y no lo intentaré.

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

Depende de lo que estés buscando. Cuando sus claves son cadenas, los árboles de búsqueda ternarios suelen ser más rápidos que las tablas hash. Cuando sus claves son números enteros, los árboles binarios Patricia de Okasaki y Gill compiten con el hash. Si realmente lo desea, puede crear una tabla hash en Haskell utilizando 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án .NET y el JIT?).
Es más difícil predecir el comportamiento de tiempo y espacio de los programas de 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, visite el administrador de ventanas de xmonad y la amplia gama de paquetes en hackage.haskell.org .

No me gusta estar atado a un abultado framework .NET a menos que los beneficios sean grandes.

No puedo comentar:

Bien diseñado
Me gusta que mis idiomas sean consistentes.

Algunos puntos sobre los que 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 functores (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 # usa esencialmente el sistema de tipo .NET, más el polimorfismo Hindley-Milner similar a 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 tanto ("tipos de datos algebraicos" como "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 codificada usa un orden y el compilador de código nativo usa la otra.

En términos de longevidad, es muy difícil juzgar la popularidad de los idiomas, pero solo haciendo una rápida comprobación aquí, estos son los números de preguntas etiquetadas con el lenguaje apropiado (funcional):

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

Diría que esta fue una buena indicación de qué idiomas están aprendiendo activamente las personas en este momento y, por lo tanto, podría ser una buena indicación de cuáles podrían ser populares en los próximos años.

Este no era uno de sus criterios, pero ¿ha considerado la disponibilidad de trabajo ? Haskell actualmente lista 144 trabajos en efecto, Ocaml lista 12 y C # lista 26,000. Estos números no son perfectos, pero te apuesto a que una vez que F # se envíe, no pasará mucho tiempo antes de que supere a Haskell y Ocaml en el número de ofertas de trabajo.

Hasta ahora, cada lenguaje de programación incluido en Visual Studios tiene miles de ofertas de trabajo para él. Me parece que si desea tener la mejor oportunidad de usar un lenguaje de programación funcional como su trabajo diario, pronto será F #.

Esto no está directamente relacionado con la pregunta del OP sobre si aprender o no F #, sino más bien, un ejemplo del uso real de OCaml en el sector financiero: http://ocaml.janestreet.com/?q=node/61

Charla muy interesante.

F # y OCaml son muy similares en sintaxis, aunque, obviamente, F # es mejor con .NET.

La que aprenda o use dependerá de la plataforma a la que apunta.

En VS2010 se incluirá F # y, como se compila en el código de bytes .NET, se puede usar en un sistema operativo Windows que admita la versión .NET que usó para él. Esto le dará una gran área, pero hay límites, actualmente con F # que OCaml no tiene, ya que F # parece no aprovechar todos los procesadores de una máquina, pero eso probablemente se deba a que F # aún está en desarrollo. , y esta puede ser una característica que no es tan importante todavía.

Hay otros lenguajes funcionales, como Erlang, que puede ver, pero, básicamente, si es fuerte en un lenguaje de PF, debería poder aprender otro con bastante rapidez, así que, elija uno que le guste e intente Desarrollar aplicaciones interesantes y desafiantes en ella.

Con el tiempo, los escritores de idiomas encontrarán la manera de hacer que los idiomas de OO funcionen bien con varios núcleos y la FP puede caer nuevamente en el camino, pero eso no parece estar sucediendo en el corto plazo.

No hay una respuesta simple a esa pregunta, pero aquí hay algunas cosas a considerar:

Haskell y OCaml son lenguajes maduros con implementaciones sólidas. En realidad, hay múltiples buenas implementaciones de Haskell, pero no creo que ese sea un punto importante a su favor para su propósito.

F # es mucho más joven, y ¿quién puede predecir dónde decidirá Microsoft tomarlo? Cómo se siente al respecto depende más de cómo se siente con respecto a Microsoft que cualquier otra cosa que alguien pueda decirle acerca de los lenguajes de programación.

OCaml (o ML en general), es una buena opción de lenguaje práctico que admite hacer cosas geniales y funcionales sin obligarlo a trabajar de una manera que pueda ser incómoda. Obtienes el beneficio completo de cosas como tipos de datos algebraicos, coincidencia de patrones, inferencia de tipo y las cosas favoritas de todos los demás. Oh, y los objetos.

Haskell le brinda todo eso (excepto los objetos, en gran medida), pero también lo obliga a repensar todo lo que cree que sabe sobre programación. Esto podría ser algo muy bueno, si está buscando aprender algo nuevo, pero podría ser más de lo que quiere morder. Digo esto como alguien que tal vez está a medio camino del camino para ser un programador de Haskell productivo y feliz.

Tanto OCaml como Haskell se utilizan para escribir muchos tipos diferentes de programas, no solo compiladores y AI o lo que sea. Google es tu amigo.

Una última nota: OCaml te da la tabla hash, pero no es sensato usarlo en código si realmente quieres utilizar la programación funcional. Los árboles persistentes (como Data.Map) son realmente la solución correcta para Haskell, y tienen muchas propiedades agradables, que es una de las mejores cosas que aprender cuando retire Haskell.