J'ai eu une fois une discussion avec le fondateur d'une start-up israélienne développant une base de données basée sur GPU avec un accent sur la vitesse. La pile de travail comprenait Haskell et C ++, entre autres, et le fondateur se plaignait de la difficulté de trouver des programmeurs compétents. C'est en partie pour cette raison qu'il est venu à Moscou.
J'ai soigneusement demandé s'ils envisageaient d'utiliser quelque chose de plus populaire et de nouveau. Et même si la réponse était plutôt polie et bien étayée par des arguments, elle sonnait toujours comme «Allez, ne parle même pas de ces jouets».
Jusque-là, tout ce que j'avais entendu à propos de Haskell pouvait se résumer comme suit: «soyez TRÈS prudent en le traitant». Pour mieux connaître les programmeurs Haskell, je suis venu à une discussion d'actualité sur Telegram avec quelques questions. J'avais très peur au début et, en fin de compte, j'avais raison.
Haskell ne se prête pas aux explications populaires et les gens n'essaient même pas. Si le sujet est soulevé, il n'est abordé que de manière approfondie et aussi objective que possible. Quelqu'un m'a écrit: «L'une des caractéristiques déterminantes de Haskell lui-même et de sa communauté est qu'ils n'ont pas essayé d'obtenir une quelconque reconnaissance générale. Au lieu de cela, ils se sont concentrés sur la construction d'une manière logique et principale de résoudre les problèmes réels plutôt que d'essayer d'apaiser le public le plus large possible »
Néanmoins, quelques personnes m'ont fait part de leurs expériences, qui sont présentées ci-dessous.
Denis Mirzoev ( nolane ) : Quand j'étais au collège, ils m'ont proposé de suivre un cours Coursera sur Haskell pour un crédit supplémentaire. Ensuite, nous avons également suivi un cours de programmation fonctionnelle incluant Haskell. J'ai écrit un de mes articles de fin d'études, plus le papier de fin d'études, sur GHC. Ensuite, j'ai trouvé un emploi en tant que programmeur Haskell.
C'était, et c'est toujours, difficile. Lorsque vous commencez à apprendre Haskell, vous devez fourrer beaucoup de nouveaux concepts dans votre esprit. C'est comme recommencer à zéro à partir de zéro.
Les gens ont tendance à oublier (ou à adoucir) leurs souvenirs antérieurs: comme lorsqu'ils avaient du mal à comprendre ce qu'était un «pointeur», une «fonction» ou une «classe». C'est peut-être pourquoi il est si difficile pour eux d'apprendre Haskell: il devient plus difficile d'apprendre de nouvelles choses avec l'âge.
Doctor_Ryner : Une fois que j'ai échoué ma période d'essai à un emploi à cause d'un putain de Redux, j'ai donc essayé d'être un peu plus à l'aise avec ça en regardant des vidéos de son créateur. J'ai d'abord pratiqué en JavaScript, puis j'ai découvert Haskell, considéré comme le «vrai» langage fonctionnel. J'étais fasciné par ses concepts uniques et sa netteté.
Cependant, les didacticiels ne sont pas trop conviviaux et son arrière-plan impératif empêche l'émergence de nouveaux concepts.
Yuri Syrovetskiy ( cblp ) : le plus difficile est d'apprendre le haskell comme deuxième langue, lorsque les souvenirs de l'apprentissage de la première sont encore frais,
Qu'est-ce que Haskell bon et mauvais?
Doctor_Ryner : C'est concis, élégant et flexible. Pas étonnant que la moitié des bibliothèques existent sur EDSL (ou du moins on en a envie).
Yuri Syrovetskiy : Il est (subjectivement) facile d'adapter vos pensées au code, il a un grand équilibre de paradigmes impératifs et fonctionnels. Construire des abstractions de données et d'algorithmes est assez simple, ce qui permet de penser à la tâche à accomplir sans trop se laisser distraire par de petits désagréments.
John Doe : Typisation stricte, forte (même fasciste, je dirais).
Igor Shevnin ( interphx ) : Un excellent système de type. Ce n'est pas aussi puissant que dans Idris ou Agda, mais atteint toujours ce point milieu pratique où vous pouvez décrire presque n'importe quoi, et pourtant l'inférence de type fonctionne bien. Vous n'avez pas besoin de les marquer manuellement à chaque fois.
Mais un système de type puissant vous oblige à porter une plus grande attention aux valeurs transmises. Un tas de définitions de type pourrait ressembler à un passe-partout. Chaque commande a son propre jeu d'extensions, ou n'en a pas du tout. Le code est «plus dense» - chaque chaîne contient souvent plus d'informations que dans d'autres langues, il est donc plus difficile à lire pour un développeur inexpérimenté.
Doctor_Ryner : En apprenant Haskell, vous tomberez probablement sur ce dicton: "Si ça compile, c'est probablement correct". Null n'existe pas, le paradigme fonctionnel lui-même est très strict et vous maintient dans certaines directives, ce qui dans la plupart des cas conduit à une meilleure conception.
Par exemple, Haskell n'a pas de variables - seulement des constantes. Vous n'êtes pas obligé de garder une trace de ce qui est attribué où. Haskell encourage l'utilisation de fonctions «pures», qui n'ont pas d'effets secondaires. La conception fonctionnelle oblige le programme à fonctionner dans son ensemble, contrairement aux langages orientés objet, où de nombreux objets tentent de communiquer entre eux en utilisant ces effets secondaires, transformant l'application en un gâchis imprévisible. Nous avons beaucoup souffert de cela en C # et Unity au travail.
Denis Mirzoev : Quand la langue est naturellement «paresseuse», elle est généralement plus expressive. Les algorithmes deviennent plus simples. Si les résultats intermédiaires ne sont pas utilisés, cela augmente considérablement les performances.
Igor Shevnin : La «paresse» aide souvent, mais lorsque l'ordre des appels de fonction est important, il est parfois très difficile de comprendre ce qui se passe.
Doctor_Ryner : S'il est conforme, c'est probablement assez rapide.
Denis Mirzoev :
Côté performances, il est comparable à Java, mais pas aussi vite que C.
Igor Shevnin : Il a un support d'extension
prêt à l'emploi , ce qui vous permet d'adapter la langue et le système de caractères à votre guise. Il y a beaucoup d'extensions qui sont largement utilisées par la communauté et qui ont des échantillons et une documentation décents.
Doctor_Ryner : La bibliothèque Prelude standard a beaucoup de mauvaises fonctions comme read, head, readFile, qui peuvent lever une exception et planter l'application au lieu de renvoyer Maybe. Je dois donc utiliser des alternatives ou écrire les miennes.
Igor Shevnin : le plus gros problème est le manque de normes, au point que beaucoup de gens remplacent la bibliothèque standard par l'une des alternatives, qui ne sont en aucun cas compatibles entre elles. La division de la communauté sur ce que devrait être la bibliothèque standard, ce qui doit être inclus dans la distribution principale et ce qui peut être déchargé vers des extensions ... Dans mon esprit, cela étouffe le développement du langage.
Denis Mirzoev : Il manque d'outils: il n'y a pas de véritable IDE, très peu de benchmarks de performances, pas de débogage «pas à pas» - c'est un problème fondamental.
À quels projets Haskell convient-il le mieux?
YS : Pour les tâches complexes, liées à la sécurité et aux finances, où les erreurs coûtent cher.
Doctor_Ryner : pour tout ce dont vous avez besoin pour calculer, convertir et analyser. Je suis surpris que Haskell soit moins populaire dans les applications de science des données que Python.
IS : Je ne risquerais pas de l'utiliser pour des systèmes embarqués (c'est rapide, mais il y a encore une surcharge mémoire importante en raison de l'informatique «paresseuse») ou de petits scripts (où sa nature stricte n'est pas nécessaire). Il est également important de comprendre à quel point il est difficile de trouver des développeurs par rapport aux langages traditionnels.
John Doe : Pour écrire du code industriel qui sera lu par d'autres, mais vous avez besoin d'une équipe entière de développeurs Haskell. Il n'y en a pas beaucoup.
IS : Mais grâce à sa nature concise et stricte, vous pouvez utiliser Haskell pour presque tout.
Est-ce une bonne idée de commencer votre carrière de développement chez Haskell?
IS : Probablement pas, car l'écrasante majorité des bases de code avec lesquelles un développeur doit travailler ne sont pas écrites dessus.
John Doe : Mauvaise idée! Les langages non ML - qui sont presque tout dans les applications industrielles - seraient un choc pour vous.
DS : Souvent, les gens apprennent d'abord les mathématiques et passent ensuite à la programmation. Donc, théoriquement, l'apprentissage d'un langage qui nécessite beaucoup de concepts mathématiques (types de données algébriques, fonctions pures) devrait être plus facile que les langages impératifs. Je pense que c'est une bonne idée.
Doctor_Ryner : Tous les développeurs débutants avec qui je travaille présentent d'abord Haskell. Les gens qui n'ont pas le bagage du style impératif apprennent beaucoup plus rapidement le code fonctionnel, et même lorsqu'ils travaillent plus tard avec des langages orientés objet, ils ont tendance à utiliser de bonnes solutions architecturales parce qu'ils y sont habitués.
YS : Il est préférable de commencer avec quelques langages fondamentalement différents, par exemple C, Haskell et Smalltalk, dans n'importe quel ordre. Aucune langue ne peut vous donner une compréhension complète du paysage.
Haskell est une langue assez ancienne. Est-ce bon ou mauvais?
YS : Le langage est développé très activement, il ne fait pas glisser le poids de la rétrocompatibilité pour le plaisir.
John Doe : il a été normalisé en 1998, mais vous ne le remarquerez pas: à ce jour, environ tous les 6 mois, il y a une nouvelle version du compilateur qui peut potentiellement briser la compatibilité descendante.
DS : Haskell n'est pas vieux, il a simplement fait ses preuves. Il n'introduit pas (et n'introduira jamais) de changements stupides. C'est donc probablement bon pour la santé de la communauté.
On dit souvent que le haskell est l'une des langues les plus difficiles à apprendre. C'est vraiment ça?
Doctor_Ryner : En tant que langue elle-même - non. La partie la plus difficile est les abstractions qu'elle utilise. Une personne qui n'a jamais vu de code Haskell auparavant pourrait devenir folle de la quantité de nouvelles informations et d'étranges instructions. Ce qui n'aide pas, c'est que le langage «restreint» beaucoup de choses qui ne correspondent pas à son concept fonctionnel.
John Doe : Il m'a fallu deux mois de manuels, de manuels et de tutoriels au coucher juste pour obtenir mon premier projet à compiler. Cependant, une fois qu'il a finalement compilé, il a fonctionné immédiatement à pleine charge (moyenne de 6 000 RPS, avec 15 000 pics) pendant six mois sans aucun changement.
DS : Je parierais que si vous donnez à un étudiant Haskell comme première langue et qu'il aille loin, la programmation impérative lui semblerait compliquée et moins intuitive.
IS : Tout est relatif. Hors des langages traditionnels, je considère le C ++ comme le plus difficile. Les langages prouvant les théorèmes (comme Agda ou Coq) sont plus difficiles que Haskell conceptuellement. Haskell n'est pas un langage dur, mais il faut du temps pour apprendre son modèle et ses bibliothèques (standard et tierces).
Sa complexité est-elle justifiée?
IS : Les modèles et un niveau d'abstraction élevé sont justifiés, car cela rend le code plus court et plus durable. Mais je pense que les opérateurs, les noms de fonctions et bien d'autres choses auraient pu être un peu plus conviviaux.
Doctor_Ryner : La complexité de Haskell vous permet souvent de faire des solutions très courtes, flexibles et modulaires.
YS : Je dirais que seul le contrôle d'effet est un peu bizarre, bien qu'il soit toujours presque toujours préférable à aucun contrôle. Et il y a un projet en cours pour le simplifier.
John Doe : Pour les gens habitués à Python / PHP / peu importe, Haskell se sent délogé de la réalité. Pour ceux qui n'étaient pas déjà intéressés par la théorie des catégories, il est très difficile d'apprendre à partir de zéro. Mais quand vous le comprenez, vous trouvez une nouvelle approche pour résoudre un problème.
On dit souvent que Haskell n'est pas un langage pour les développeurs, mais pour les mathématiciens. Est-ce la raison pour laquelle ce n'est pas courant?
DS : Il présente l'idée principale des principaux développeurs de Haskell - «éviter le succès à tout prix». Cela ne signifie pas «éviter le succès», mais «éviter un succès trop cher».
Ils auraient pu rendre Haskell populaire. Par exemple, Microsoft prend en charge la langue. Ils auraient pu le rendre plus impératif, sacrifier la rigidité à la popularité. Il y a beaucoup de trucs sales qu'ils auraient pu utiliser, mais ils ne l'ont jamais fait.
Bien sûr, la langue n'est pas populaire, mais cela signifie que sa qualité ne souffre pas. Les avantages de Haskell par rapport aux langages impératifs sont évidents pour moi et ses problèmes peuvent tous être résolus, donc je pense qu'il deviendra populaire plus tard.
YS : Seules les personnes qui n'en savent rien le disent. Haskell est beaucoup utilisé dans le développement «réel», vous pourriez probablement trouver des exemples dans votre moteur de recherche préféré. En particulier, chez Kaspersky Labs, nous sommes très satisfaits de Haskell et nous ne l'échangerions pour rien d'autre.
IS : Qu'est-ce qu'un «langage de mathématicien»? Il s'agit soit de R / MatLab / Mathematica spécialement conçu pour les statistiques et les calculs, soit de Python car il est plus simple et ne nécessite pas autant de connaissances en ingénierie. Mais pas Haskell. Il contient des éléments de l'algèbre, comme les monoïdes, mais il a une application pratique.
La raison pour laquelle C / C ++ / Java sont si populaires est qu'ils sont historiquement très répandus dans l'espace de l'entreprise. Ils ont rempli une niche. Mais de nos jours, de nombreuses entreprises commencent à utiliser Haskell et d'autres langages fonctionnels.
À quel PL compareriez-vous Haskell?
John Doe : parmi les plus populaires, probablement avec Erlang. Mais Erlang est plus simple à apprendre et à écrire.
DS : Je connais C, C ++, Java et Haskell. C ++ est horrible et ne peut se comparer à rien. C est idéal pour le développement de bas niveau. Dans toutes les autres applications, je préfère Haskell.
Choisir entre Java et Haskell est plus difficile, mais cela dépend de l'application. Par exemple, Java est meilleur pour Android, mais dans les applications serveur, ils sont presque égaux. Si l'environnement - outils, bibliothèques - le permet, je choisis souvent Haskell.
Doctor_Ryner : Je compare avec C #. Juste Google "comment faire peut-être en C # et Haskell". Il est étrange qu'un langage aussi strictement fonctionnel que Haskell se sente beaucoup plus flexible et gratuit. Mais en réalité, ce sont les opposés polaires.
C # est l'un des langages les plus orientés objet, et ses avantages contrastent avec Haskell. C # vous oblige toujours à écrire beaucoup de choses supplémentaires, ce qui ralentit le code et le rend souvent moins élégant. Après les solutions courtes et soignées de Haskell, il est difficile de revenir en arrière.
IS : Avec Rust, et jusqu'à présent, Rust gagne probablement. Il prend beaucoup de Haskell et d'autres langages fonctionnels, mais mélange des approches fonctionnelles et impératives, et les développeurs ont géré son développement beaucoup plus intelligemment.
Quelle est votre opinion sur la communauté Haskell?
John Doe : La grande majorité des gens sont très sympathiques et prêts à aider, ce qui contraste bien avec beaucoup d'autres langues.
Doctor_Ryner : Les communautés Haskell sont souvent remplies de gens terriblement intelligents. Les mèmes locaux sur les docteurs et les universitaires existent pour une raison. Dans d'autres communautés, les gens discutent principalement des problèmes de production réguliers et des structures de données, tandis que dans un chat Haskell, les gens discutent des monades, des foncteurs applicatifs, des types fous et des choses comme ça.
Vous apprenez toujours quelque chose auquel vous n'aviez jamais pensé auparavant.
On dit que les développeurs Haskell sont trop pleins d'eux-mêmes. Est-ce vrai?
DS : Oui. J'ai l'impression que c'est parce qu'ils aiment vraiment leur langue et sont déçus de leur impopularité.
John Doe : Rien de tel.
Doctor_Ryner : Les gens disent probablement cela parce que beaucoup de développeurs grand public se fâchent avec un Haskellist qui commence à parler de programmation fonctionnelle et de ses avantages. Le Haskellist, quant à lui, s'énerve que personne ne l'écoute et ne commence à jeter la terminologie, et est ainsi étiqueté comme «plein de lui-même».
IS : C'est un peu dur de les appeler ainsi. C'est probablement parce que la programmation fonctionnelle, la POO, les différences entre les classes de POO et les types d'union, le problème d'extension et beaucoup d'autres définitions s'intègrent lentement dans une image cohérente, et il est ensuite difficile de comprendre les gens qui continuent les guerres sacrées de la POO contre la PF.
Pourquoi les langues FP sont-elles si niches?
DS : Leurs avantages ne suffisent pas à intéresser les programmeurs. Être difficile à apprendre n'aide pas non plus. Les problèmes d'outillage effraient également les gens, même si ce problème serait probablement résolu si plus de gens étaient intéressés. C'est un cercle vicieux.
IS : Eh bien, les concepts de PF se répandent lentement dans d'autres langues ...
Doctor_Ryner : Les principes fondamentaux de la PF et de ses langages sont déjà assez répandus. Même Sharp a Linq et quelques autres bibliothèques similaires. Mais les langages purement fonctionnels ont probablement trop de nouveaux concepts pour être populaires.
N'oubliez pas qu'il y a 20 ans, le matériel n'était pas encore assez rapide pour gérer les langages fonctionnels, il n'est donc entré dans le courant que assez récemment, et Haskell lui-même ne fait que grandir.