Una vez tuve una discusión con un fundador de una startup israelí que desarrollaba una base de datos basada en GPU con un enfoque en la velocidad. La pila de trabajo incluía a Haskell y C ++, entre otros, y el fundador se quejaba de lo difícil que es encontrar programadores competentes. Lo cual era parte de la razón por la que vino a Moscú.
Pregunté cuidadosamente si consideraban usar algo más popular y nuevo. Y aunque la respuesta fue bastante educada y bien apoyada con argumentos, todavía sonaba como "Vamos, ni siquiera traigas estos juguetes".
Hasta entonces, todo lo que escuché sobre Haskell podría resumirse como "ten MUY cuidado al tratarlo". Para conocer mejor a los programadores de Haskell, llegué a un chat de Telegram con algunas preguntas. Al principio tenía bastante miedo, y resultó que tenía razón.
Haskell no se presta a la explicación popular, y la gente aparentemente ni siquiera lo intenta. Si alguna vez se menciona el tema, solo se habla en profundidad y de la manera más objetiva posible. Alguien me escribió: “Una de las características definitorias tanto de Haskell como de su comunidad es que no intentaron lograr ningún tipo de reconocimiento general. En cambio, se centraron en construir una forma lógica y principal de resolver problemas reales en lugar de tratar de apaciguar a la audiencia más amplia posible "
Sin embargo, un par de personas me contaron sobre sus experiencias, que se muestran a continuación.
Denis Mirzoev ( nolane ) : Cuando estaba en la universidad, me ofrecieron hacer un curso de Coursera en Haskell para obtener crédito adicional. Luego también tuvimos un curso de programación funcional que incluía a Haskell. He escrito uno de mis trabajos finales, más el trabajo de graduación, sobre GHC. Luego encontré un trabajo como programador de Haskell.
Fue y sigue siendo difícil. Cuando comienzas a aprender Haskell, tienes que meter muchos conceptos nuevos en tu mente. Es como aprender a codificar desde cero de nuevo.
Las personas tienden a olvidar (o suavizar) sus recuerdos anteriores: como cuando luchaban por comprender qué era un "puntero", una "función" o una "clase". Tal vez por eso es tan difícil para ellos aprender Haskell: cada vez es más difícil aprender cosas nuevas con la edad.
Doctor_Ryner : Una vez que fallé mi período de prueba en un trabajo debido a un error de Redux, traté de sentirme un poco más cómodo viendo videos de su creador. Primero practiqué en JavaScript, pero luego aprendí sobre Haskell, considerado el lenguaje funcional "verdadero". Me fascinaron sus conceptos únicos y lo ordenado que era.
Sin embargo, los tutoriales no son demasiado fáciles de usar, además de que su fondo imperativo evita que surjan nuevos conceptos.
Yuri Syrovetskiy ( cblp ) : lo más difícil es aprender Haskell como su segundo idioma, cuando los recuerdos de aprender el primero aún están frescos,
¿Qué es Haskell bueno y malo?
Doctor_Ryner : Es conciso, elegante y flexible. No es de extrañar que la mitad de las bibliotecas que hay en EDSL (o al menos así lo parezca).
Yuri Syrovetskiy : Es (subjetivamente) fácil adaptar sus pensamientos al código, tiene un gran equilibrio de paradigmas imperativos y funcionales. Construir abstracciones de datos y algoritmos es bastante simple, lo que permite pensar en la tarea en cuestión sin distraerse demasiado con pequeñas molestias.
John Doe : tipificación estricta, fuerte (incluso fascista, diría yo).
Igor Shevnin ( interphx ) : un gran sistema de tipos. No es tan poderoso como en Idris o Agda, pero aún así alcanza ese punto medio conveniente donde puede describir casi cualquier cosa, y sin embargo, la inferencia de tipos funciona bien. No tiene que marcarlos manualmente cada vez.
Pero un sistema de tipo poderoso te obliga a prestar más atención a los valores transmitidos. Un montón de definiciones de tipo podría parecer una repetitiva. Cada comando tiene su propio conjunto de extensiones, o no los tiene en absoluto. El código es "más denso": cada cadena a menudo contiene más información que en otros idiomas, por lo que es más difícil de leer para un desarrollador inexperto.
Doctor_Ryner : Al aprender Haskell, probablemente te toparás con este dicho: "Si se compila, probablemente sea correcto". No existe nulo, el paradigma funcional en sí mismo es muy estricto y lo mantiene dentro de ciertas pautas, que en la mayoría de los casos conducen a un mejor diseño.
Por ejemplo, Haskell no tiene variables, solo constantes. No tiene que hacer un seguimiento de lo que está asignado a dónde. Haskell incentiva el uso de funciones "puras", que no tienen efectos secundarios. El diseño funcional obliga al programa a funcionar como un todo, a diferencia de los lenguajes orientados a objetos, donde muchos objetos intentan comunicarse entre sí mediante estos efectos secundarios, convirtiendo la aplicación en un desastre impredecible. Hemos sufrido esto en C # y Unity mucho en el trabajo.
Denis Mirzoev : Cuando el lenguaje es naturalmente "vago", generalmente es más expresivo. Los algoritmos se vuelven más simples. Si no se utilizan resultados intermedios, aumenta en gran medida el rendimiento.
Igor Shevnin : La "pereza" a menudo ayuda, pero cuando el orden de las llamadas de función es importante, a veces es muy difícil entender lo que está sucediendo.
Doctor_Ryner : Si cumple, probablemente sea bastante rápido.
Denis Mirzoev : En cuanto al rendimiento, es comparable a Java, pero no tan rápido como C.
Igor Shevnin : tiene soporte de extensión
listo para usar , lo que le permite adaptar el idioma y el sistema de tipos a su gusto. Hay muchas extensiones que son ampliamente utilizadas por la comunidad y tienen muestras y documentación decentes.
Doctor_Ryner : La biblioteca estándar de Prelude tiene muchas funciones malas como read, head, readFile, que puede generar una excepción y bloquear la aplicación en lugar de devolver Quizás. Entonces tengo que usar alternativas o escribir la mía.
Igor Shevnin : el mayor problema es la falta de estándares, hasta el punto en que mucha gente reemplaza la biblioteca estándar con una de las alternativas, que de ninguna manera son compatibles entre sí. La división de la comunidad sobre lo que debería ser la biblioteca estándar, lo que debe incluirse en la distribución principal y lo que puede descargarse a las extensiones ... En mi opinión, ahoga el desarrollo del lenguaje.
Denis Mirzoev : Carece de herramientas: no hay un IDE adecuado, muy pocos puntos de referencia de rendimiento, ni depuración "paso a paso", es un problema fundamental.
¿Para qué proyectos se adapta mejor Haskell?
YS : Para tareas complejas, relacionadas con la seguridad y las finanzas, donde los errores son caros.
Doctor_Ryner : para todo lo que necesita para calcular, convertir y analizar. Me sorprende que Haskell sea menos popular en las aplicaciones de Data Science que Python.
IS : No me arriesgaría a usarlo para sistemas embebidos (es rápido, pero todavía hay una sobrecarga de memoria significativa debido a la computación "perezosa") o pequeños scripts (donde no se necesita su naturaleza estricta). También es importante comprender lo difícil que es encontrar desarrolladores en comparación con los idiomas principales.
John Doe : Para escribir código industrial que será leído por otros, pero luego se necesita un equipo completo de desarrolladores de Haskell. No hay muchos de ellos.
IS : Pero gracias a su naturaleza concisa y estricta, puedes usar Haskell para casi cualquier cosa.
¿Es una buena idea comenzar su carrera de desarrollo con Haskell?
IS : Probablemente no, porque la abrumadora mayoría de las bases de código con las que un desarrollador tiene que trabajar no está escrito en él.
John Doe : ¡Mala idea! Los idiomas que no son de ML, que es casi todo en aplicaciones industriales, serían un shock para usted.
DS : A menudo las personas aprenden matemáticas primero y luego cambian a programación. Entonces, teóricamente, aprender un lenguaje que requiere muchos conceptos matemáticos (tipos de datos algebraicos, funciones puras) debería ser más fácil que los lenguajes imperativos. Creo que es una buena idea.
Doctor_Ryner : Todos los desarrolladores novatos con los que trabajo primero los presento a Haskell. Las personas que no tienen el bagaje del estilo imperativo son mucho más rápidas para aprender código funcional, e incluso cuando trabajan con lenguajes orientados a objetos más tarde, tienden a utilizar buenas soluciones arquitectónicas porque están acostumbradas a ellos.
YS : Es mejor comenzar con un par de lenguajes fundamentalmente diferentes, por ejemplo, C, Haskell y Smalltalk, en cualquier orden. Ningún idioma puede darte una comprensión total del paisaje.
Haskell es un idioma bastante antiguo. ¿Es bueno o malo?
YS : El lenguaje se desarrolla de manera muy activa, no arrastra el peso de la compatibilidad con versiones anteriores por el simple hecho de hacerlo.
John Doe : fue estandarizado en 1998, pero no lo notarías: hasta el día de hoy, aproximadamente cada 6 meses hay una nueva versión del compilador que puede romper la compatibilidad con versiones anteriores.
DS : Haskell no es viejo, es simplemente probado. No (y nunca) introducirá cambios sin sentido. Por lo tanto, probablemente sea bueno para la salud de la comunidad.
A menudo se dice que Haskell es uno de los idiomas más difíciles de aprender. ¿Es realmente?
Doctor_Ryner : Como lenguaje en sí mismo, no. La parte más difícil son las abstracciones que usa. Una persona que nunca antes haya visto un código Haskell podría volverse loco por la cantidad de información nueva y las instrucciones extrañas. Lo que no ayuda es que el lenguaje "restringe" muchas cosas que no se ajustan a su concepto funcional.
John Doe : Me llevó dos meses de libros de texto, manuales y tutoriales antes de acostarse solo para obtener mi primer proyecto para compilar. Pensamientos, una vez que finalmente compiló, funcionó de inmediato a plena carga (6k RPS promedio, con picos de 15k) durante medio año sin ningún tipo de cambio.
DS : Apuesto a que si le das a Haskell a un estudiante universitario como primer idioma y él llega lejos con él, entonces la programación imperativa parecería complicada y menos intuitiva para él.
IS : Todo es relativo. Fuera de los lenguajes principales, considero que C ++ es el más difícil. Los lenguajes de prueba de teoremas (como Agda o Coq) son más difíciles que Haskell conceptualmente. Haskell no es un lenguaje difícil, pero lleva tiempo aprender su patrón y sus bibliotecas (tanto estándar como de terceros).
¿Está justificada su complejidad?
IS : Los patrones y un alto nivel de abstracción están justificados, ya que hace que el código sea más corto y más duradero. Pero creo que los operadores, los nombres de funciones y muchas otras cosas podrían haber sido un poco más fáciles de usar.
Doctor_Ryner : Muchas veces la complejidad de Haskell le permite hacer soluciones muy cortas, flexibles y modulares.
YS : Yo diría que solo el control de efectos es un poco inestable, aunque casi siempre es preferible a ningún control. Y hay un proyecto en curso para simplificarlo.
John Doe : Para las personas acostumbradas a Python / PHP / lo que sea, Haskell se siente alejado de la realidad. Para aquellos que aún no estaban interesados en la teoría de las categorías, es muy difícil aprender desde cero. Pero cuando lo entiendes, encuentras un nuevo enfoque para resolver un problema.
A menudo se dice que Haskell no es un lenguaje para desarrolladores, sino para matemáticos. ¿Es esta la razón por la que no es convencional?
DS : Muestra la idea principal de los principales desarrolladores de Haskell: "evitar el éxito a toda costa". No significa "evitar el éxito", sino "evitar un éxito demasiado costoso".
Podrían haber hecho popular a Haskell. Por ejemplo, Microsoft admite el idioma. Podrían haberlo hecho más imperativo, sacrificar la rigidez por la popularidad. Hay muchos trucos sucios que podrían haber usado, pero nunca lo hicieron.
Claro, el lenguaje no es popular, pero eso significa que su calidad no sufre. Las ventajas de Haskell en comparación con los lenguajes imperativos son obvias para mí y todos sus problemas pueden resolverse, por lo que creo que se volverá popular más adelante.
YS : Solo las personas que no saben nada al respecto lo dicen. Haskell se usa mucho en el desarrollo del "mundo real", probablemente pueda encontrar ejemplos en su motor de búsqueda favorito. En particular, nosotros en Kaspersky Labs estamos muy contentos con Haskell y no lo cambiaríamos por nada más.
IS : ¿Qué es un "lenguaje matemático"? Es R / MatLab / Mathematica creado específicamente para estadísticas y cálculos, o Python porque es más simple y no requiere tanta experiencia en ingeniería. Pero no Haskell. Tiene material de álgebra, como monoides, pero tiene una aplicación práctica.
La razón por la cual C / C ++ / Java es tan popular es porque históricamente han estado muy extendidos en el espacio empresarial. Llenaron un nicho. Pero hoy en día muchas empresas comienzan a usar Haskell y otros lenguajes funcionales.
¿Con qué PL compararías a Haskell?
John Doe : fuera de los populares, probablemente con Erlang. Pero Erlang es más simple de aprender y escribir.
DS : Sé C, C ++, Java y Haskell. C ++ es horrible y no se puede comparar con nada. C es excelente para el desarrollo de bajo nivel. En todas las demás aplicaciones, preferiría Haskell.
Elegir entre Java y Haskell es más difícil, pero depende de la aplicación. Por ejemplo, Java es mejor para Android, pero en las aplicaciones de servidor son casi iguales. Si el entorno (herramientas, bibliotecas) lo permite, a menudo elijo Haskell.
Doctor_Ryner : lo comparo con C #. Simplemente Google "cómo hacer Quizás en C # y Haskell". Es extraño que un lenguaje tan estrictamente funcional como Haskell se sienta mucho más flexible y gratuito. Pero en realidad, son los polos opuestos.
C # es uno de los lenguajes más orientados a objetos, y sus ventajas contrastan con Haskell. C # siempre te obliga a escribir muchas cosas adicionales, lo que ralentiza el código y a menudo lo hace menos elegante. Después de las soluciones cortas y ordenadas de Haskell, es difícil regresar.
IS : Con Rust, y hasta ahora Rust probablemente gana. Toma mucho de Haskell y otros lenguajes funcionales, pero combina enfoques funcionales e imperativos, además los desarrolladores han manejado su desarrollo de manera mucho más inteligente.
¿Cuál es tu opinión sobre la comunidad de Haskell?
John Doe : La gran mayoría de las personas son muy amigables y están listas para ayudar, lo cual es un buen contraste con muchos otros idiomas.
Doctor_Ryner : Las comunidades de Haskell a menudo están llenas de personas terriblemente inteligentes. Los memes locales sobre doctorados y académicos existen por alguna razón. En otras comunidades, la mayoría de las personas discuten problemas de producción regulares y estructuras de datos, mientras que en un chat de Haskell las personas discuten mónadas, ficticios aplicadores, tipos locos y cosas así.
Siempre aprendes algo en lo que nunca antes habías pensado.
Se dice que los desarrolladores de Haskell están demasiado llenos de sí mismos. ¿Es verdad?
DS : sí. Siento que es porque realmente les gusta su idioma y están decepcionados de lo impopular que es.
John Doe : Nada de eso.
Doctor_Ryner : La gente probablemente dice eso porque muchos desarrolladores convencionales se molestan con un Haskellist y comienza a hablar sobre programación funcional y sus ventajas. El Haskellist, mientras tanto, se molesta porque nadie lo escucha y comienza a tirar terminología, y por lo tanto se etiqueta como "lleno de sí mismo".
IS : Es un poco duro llamarlos así. Probablemente se deba a que la programación funcional, OOP, las diferencias entre las clases de OOP y los tipos de unión, el problema de extensión y muchas otras definiciones se incorporan lentamente en una imagen coherente, y luego es difícil entender a las personas que continúan las guerras santas de OOP vs FP.
¿Por qué los lenguajes FP son tan específicos?
DS : Sus ventajas no son suficientes para interesar a los programadores. Ser difícil de aprender tampoco ayuda. Los problemas de herramientas también ahuyentan a las personas, aunque ese problema probablemente se resolvería si hubiera más personas interesadas. Es un círculo vicioso.
IS : Bueno, los conceptos de FP se abren paso lentamente en otros idiomas ...
Doctor_Ryner : Los principios básicos de FP y sus lenguajes ya están bastante extendidos. Incluso Sharp tiene Linq y algunas otras bibliotecas similares. Pero los lenguajes puramente funcionales probablemente solo tienen demasiados conceptos nuevos para ser populares.
No olvide que hace 20 años el hardware aún no era lo suficientemente rápido como para manejar lenguajes funcionales, por lo que solo ingresó a la corriente principal recientemente, y Haskell en sí solo está creciendo.