J'ai parlé une fois avec le fondateur d'une startup israélienne qui développait une base de données GPU à haute vitesse. Haskell et C ++ étaient sur leur pile, et le fondateur s'est plaint de la difficulté de trouver des gens dans l'équipe. Il s'est envolé pour Moscou, notamment pour chercher de bons programmeurs.
J'ai soigneusement demandé s'il était préférable d'utiliser quelque chose de plus commun et de nouveau. Et bien que la réponse ait été polie et constructive, entre les lignes, il m'a semblé: "Pff, ne parle même pas de ces jouets."
Tout ce que j'ai entendu parler de Haskell depuis ce moment-là se résumait à une chose - "les blagues sont mauvaises avec lui". Pour mieux connaître les Haskellistes, je suis venu au chat télégramme pour leur poser des questions. C'était assez effrayant, et en fin de compte, pas en vain.
Ils ne veulent pas parler de Haskell de façon populaire, et il semble qu'ils envisagent ces entreprises avec mépris. Déjà en train de parler - avec un maximum d'exhaustivité et d'objectivité. «L'une des qualités caractéristiques de Haskell en tant que langue et communauté est qu'ensemble, ils n'ont pas cherché à devenir populaires, donnant une réponse simple aux questions populaires. Au lieu de cela, ils ont construit une façon logique de résoudre des problèmes réels plutôt que de pénétrer rapidement dans le cœur d'un passant par une personne intéressée », m'ont-ils écrit là-bas.
Cependant, plusieurs personnes ont partagé leurs expériences et j'ai rassemblé leurs opinions ici.
Denis Mirzoev ( nolane ) : À l'université, sur le thème des «langages de programmation», on m'a proposé de suivre un cours à Haskell Coursera pour un point supplémentaire sur cent. Ensuite, il y a eu un cours de programmation fonctionnelle au cours duquel Haskell a eu lieu. Il a écrit un article de fin d'études et un travail d'études supérieures du baccalauréat sur GHC. Trouvé un emploi en tant que programmeur Haskell.
C'était dur, et toujours dur. Lorsque vous commencez à étudier Haskell, vous devez comprendre de nombreux nouveaux concepts. C'est un travail difficile. Vous réapprenez littéralement à programmer.
Il sera difficile pour beaucoup maintenant de se rappeler comment ils ont commencé leur voyage dans la programmation, combien il était difficile de comprendre ce qu'est un «pointeur», ce qu'est une «fonction», ce qu'est une «classe». C'est peut-être la raison pour laquelle étudier Haskell est si difficile. Avec l'âge, il devient plus difficile d'apprendre de nouvelles choses.
Doctor_Ryner : Une fois en période d'essai, je suis tombé dans Redux, alors en regardant les leçons de son créateur, j'ai décidé de mieux connaître tout le monde. Au début, j'ai appliqué les pratiques apprises en JavaScript, mais j'ai ensuite découvert Haskell, qui est considéré comme un véritable langage fonctionnel. J'ai tout de suite été attirée par son élégance et un tas de nouveaux concepts qui m'étaient inconnus.
Ce n'était pas facile avec des tutoriels sans fin sur les monades sur l'exemple des burritos, qui sont très déroutants. De plus, un contexte impératif rend difficile l'ouverture de nouveaux concepts.
Yuri Syrovetsky ( cblp ) : La chose la plus difficile à apprendre est la seconde de Haskell, lorsque le syndrome du caneton n'est pas passé dans la première langue.
Qu'est-ce qui est bon et mauvais langage?
Doctor_Ryner : Le langage est très concis, élégant et flexible, pas pour rien que la moitié des bibliothèques qu'il contient sont EDSL (au moins cette impression).
Yuri Syrovetsky ( cblp ) : haute expressivité, facile à transférer le domaine à coder, combinaison optimale de paradigmes impératifs et fonctionnels. Il est facile de construire des abstractions sur des données et des algorithmes, ce qui vous permet de penser au problème sans être distrait par de petites choses sans rapport.
John Doe : typage strict fort (je dirais fasciste).
Igor Shevnin ( interphx ) : Un système de type très expressif. Pas aussi puissant que Idris ou Agda, mais il atteint ce terrain d'entente quand presque tout peut être exprimé, et l'inférence de type fonctionne bien. Vous n'avez pas besoin de les marquer manuellement partout.
Mais un système de type puissant vous fait prêter attention aux valeurs transmises. Un tas de définitions de types pourrait ressembler à un passe-partout. Chaque équipe utilise son propre ensemble d'extensions ou ne les utilise pas du tout. Le code est plus "dense" - une ligne contient souvent plus d'informations que dans d'autres langues, il est donc plus difficile pour un développeur inexpérimenté de le lire.
Doctor_Ryner : Lorsque vous étudiez Haskell, vous rencontrerez très probablement le dicton "si cela se compile, c'est probablement correct". Il n'y a pas de null, le paradigme fonctionnel lui-même est très strict et vous oblige à suivre certaines règles, qui dans la plupart des cas conduisent à une meilleure conception.
Par exemple, il n'y a pas de variables dans le langage, uniquement des constantes. Vous n'avez pas à garder une trace de quoi et où vous attribuez. Haskell encourage l'utilisation de fonctions pures, ce qui n'entraîne aucun effet secondaire. La conception fonctionnelle fait simplement fonctionner le programme dans son ensemble, contrairement à la POO, où un tas d'objets sont jetés dans le monde et les objets essaient de communiquer les uns avec les autres par des effets secondaires, transformant l'application en un gâchis imprévisible. Au travail, nous en souffrons assez avec C # dans Unity.
Denis Mirzoev : La paresse intégrée augmente l'expressivité de la langue. De nombreux algorithmes deviennent plus faciles. Il peut augmenter la productivité si les résultats des calculs intermédiaires ne sont pas utilisés. (Par exemple, `head. Sort` fonctionne en temps linéaire).
Igor Shevnin : Un modèle de calcul paresseux aide généralement, mais lorsque l'ordre des fonctions d'appel est important, il peut être difficile de comprendre ce qui se passe.
Doctor_Ryner : Il est compilé, ce qui donne immédiatement une énorme augmentation de vitesse.
Denis Mirzoev : Comparé à Java en vitesse, mais pas aussi vite que C.
Igor Shevnin :
Prêt à l'emploi , il existe un support pour les extensions qui vous permettent de terminer le système de langue et de type. Cependant, il existe de nombreuses extensions largement utilisées qui sont familières à la communauté, ont des exemples et une documentation décents et ne sont pas des niches.
Doctor_Ryner : La bibliothèque standard de Prelude a des fonctions très médiocres comme read, head, readFile, qui peuvent lever une exception et mettre dans un programme, au lieu de retourner peut-être. Par conséquent, vous devez utiliser des alternatives ou écrire vos propres implémentations.
Igor Shevnin : Le principal problème est le manque de standardisation, dans la mesure où beaucoup remplacent la bibliothèque standard par l'une des alternatives incompatibles. Il y a des désaccords dans la communauté sur ce qu'une bibliothèque standard devrait être, ce qui devrait être inclus dans le noyau de la langue et ce qui devrait être complété par des extensions, et il me semble que cela ralentit le développement de la langue.
Denis Mirzoev : Il n'y a pas assez d'outils: il n'y a pas d'IDE à part entière, il y a très peu d'outils pour mesurer les performances, il n'y a pas de débogage "pas à pas" - c'est généralement un problème fondamental.
Pour quels projets Haskell est-il le mieux adapté?
Yuri Syrovetsky : Pour les tâches complexes liées à la sécurité ou à l'argent, où le coût des erreurs est élevé.
Doctor_Ryner : Pour tout ce dont vous avez besoin pour effectuer des calculs, des transformations et l'analyse de données. Très surpris que Haskell soit moins populaire en Data Science que Python.
Igor Shevnin : Je ne risquerais pas de l'utiliser pour des systèmes embarqués (les performances ne sont pas mauvaises, mais il y a encore une surcharge importante pour la consommation de mémoire en raison de calculs paresseux) et de petits scripts (cette rigueur n'est tout simplement pas nécessaire là-bas). Vous devez également comprendre qu'il est beaucoup plus difficile de trouver des développeurs dans une équipe que pour les langages traditionnels.
John Doe : Pour écrire du code de l'industrie que d'autres liront, vous aurez besoin de toute une équipe de Haskellistes. Ces quelques personnes ont réussi à se rassembler.
Igor Shevnin : Mais en raison de sa brièveté et de sa rigueur, Haskell convient à presque toutes les tâches.
Commencer à apprendre le développement avec Haskell est une bonne idée?
Igor Shevnin: Il est peu probable que cela commence, car la grande majorité des bases de code avec lesquelles une personne devra travailler ne sont pas écrites dessus.
John Doe : Mauvaise, mauvaise idée! Les langues non pas de la famille ML - mais des langues industrielles en général - seront alors un choc pour vous.
Denis Mirzoev : Habituellement, les gens étudient d'abord les mathématiques, puis passent à la programmation. Par conséquent, l'apprentissage d'une langue à l'aide de concepts mathématiques (types de données algébriques, fonctions pures) devrait être plus simple qu'impératif. Autrement dit, je pense que c'est une bonne idée.
Doctor_Ryner : Tous les nouveaux arrivants que je forme, je vais certainement vous présenter Haskell. Les gens qui n'ont pas étudié le style impératif sont beaucoup plus faciles à naviguer dans le code fonctionnel et à apprendre plus rapidement, puis même s'ils travaillent avec des langages orientés objet, ils apportent de bonnes solutions architecturales et des pratiques fonctionnelles.
Yuri Syrovetsky : il vaut mieux commencer tout de suite avec plusieurs langues fondamentalement différentes, par exemple, C, Haskell et Smalltok, dans n'importe quel ordre. Pas une seule langue en
séparément ne donnera pas une compréhension complète.
Haskell est une langue assez ancienne. Est-ce bon ou mauvais?
Yuri Syrovetsky: Le langage se développe très activement, la charge de compatibilité juste pour des raisons de compatibilité ne tire pas.
John Doe : La norme a été adoptée en 1998, mais cela n'est pas perceptible: jusqu'à présent, de nouvelles versions du compilateur, susceptibles de rompre la compatibilité descendante, sont publiées environ tous les six mois.
Denis Mirzoev : Haskell n'est pas vieux, mais a fait ses preuves. Des changements irréfléchis n'entreront jamais dans la langue. C'est donc plutôt bien.
Haskell serait l'une des langues les plus complexes. En est-il ainsi?
Doctor_Ryner : Comme la langue elle-même, non. Les abstractions qui y sont utilisées sont plus probables. Une personne qui n'a jamais vu le code Haskell peut simplement devenir folle avec le flux de nouvelles informations et diverses constructions inhabituelles.
Le pétrole ajoute au feu que le langage impose un tas de "restrictions", ne permet pas ou complique grandement un tas de choses qui ne rentrent pas dans un concept fonctionnel.
John Doe : Pour que le premier projet élémentaire soit au moins compilé, il a fallu près de deux mois pour fumer des manuels, des manuels et des tutoriels le soir. Certes, après la compilation, le projet a immédiatement commencé à fonctionner et les figues à pleine charge (6k rps avec des pics jusqu'à 15) pendant six mois, sans aucun changement.
Denis Mirzoev : Je parie que si un étudiant commence à étudier la programmation à partir de Haskell et va assez loin, la programmation impérative lui semblera plus compliquée et moins intuitive.
Igor Shevnin : La complexité est relative. Parmi les langages traditionnels, je trouve toujours le C ++ le plus complexe. Les langages de démonstration des théorèmes (Agda, Coq) seront plus compliqués que Haskell au sens conceptuel. Haskell est un langage simple, mais ses modèles et bibliothèques - standard et tiers - peuvent être apprises immédiatement.
Sa complexité est-elle toujours justifiée?
Igor Shevnin : Les modèles et un haut niveau d'abstraction sont justifiés, car ils rendent le code plus fiable et plus court. Mais je pense que les opérateurs, les noms de fonction et bien d'autres choses pourraient être plus clairs.
Doctor_Ryner : Souvent, les constructions Haskell complexes vous permettent de créer des solutions très courtes, qui s'avèrent également très flexibles et modulaires.
Yuri Syrovetsky : Sauf que la gestion des effets est lourde, bien que presque
c’est toujours mieux que le manque de contrôle. Mais par trop simplifier
les travaux sont en cours.
John Doe : Le langage pour ceux qui sont habitués au python / php / habituel le fait généralement sembler orthogonal à la réalité. Pour les personnes qui n'étaient pas initialement intéressées par la théorie des catégories, obtenir des résultats à partir du zéro absolu est très difficile.
Mais lorsque vous comprenez la langue, vous obtenez une nouvelle façon de penser au problème résolu.
Haskell semble être un langage pour les mathématiciens, pas pour les développeurs. Pensez-vous que ce n'est pas répandu à cause de cela?
Denis Mirzoev : Ceci est une démonstration du principe que les principaux développeurs de Haskell suivent - «éviter le succès à tout prix». Il ne s'agit bien sûr pas d'éviter le succès, mais d'éviter le succès dont le prix est trop élevé.
Haskell pourrait être rendu populaire. Par exemple, Microsoft prend en charge cette langue. Il était possible de rendre le langage plus impératif, de prendre des décisions rapides et mal conçues pour gagner en popularité. Il était possible d'utiliser beaucoup de trucs sales, mais grâce à une telle position des développeurs principaux, il n'y avait rien de tel.
Oui, la popularité de la langue n'est pas très élevée, mais sa qualité n'en souffre pas. Les avantages de Haskell par rapport aux langues impératives sont évidents pour moi, la plupart de ses problèmes sont résolubles, donc je suis sûr qu'une grande popularité viendra à mesure qu'elle se développera.
Yuri Syrovetsky : Il n'est donc vu que par des gens qui ne savent rien de lui. Dans
Haskell utilise le "vrai" développement depuis longtemps, les exemples sont faciles à trouver dans
votre moteur de recherche préféré. En particulier, nous sommes en LC en utilisant
Haskell est satisfait et nous ne voyons rien d'autre à sa place.
Igor Shevnin : Qu'est-ce qu'un "langage pour les mathématiciens", je ne sais vraiment pas. Il s'agit soit de R / MatLab / Mathematica pour les calculs et les statistiques, soit de Python, car il est simple et nécessite moins de connaissances en ingénierie. Mais pas Haskell. Des concepts algébriques tels que les monoïdes y sont utilisés pour des raisons pratiques, et pas seulement pour une rigueur supplémentaire.
Le rôle principal dans la popularité a été joué par la prévalence historique du C / C ++ / Java / C # dans l'entreprise, ils occupaient une niche. Mais maintenant, de nombreuses entreprises commencent à utiliser Haskell et d'autres langages fonctionnels.
À quoi pensez-vous comparer Haskell et en faveur de qui?
John Doe : Plus ou moins commun - avec Erlang. Mais Erlang est toujours plus facile à écrire et à apprendre, me semble-t-il.
Denis Mirzoev : Je connais bien C, C ++, Java et Haskell. Le C ++ n'a même pas besoin d'être comparé à quoi que ce soit, le langage est terrible. C est un bon langage pour le développement de bas niveau. Dans ce créneau, il ira mieux. Sinon, je préférerais Haskell.
Le choix entre Java et Haskell est déjà plus difficile, mais ici vous devez également regarder une tâche spécifique. Pour Android sur Haskell, il sera probablement difficile d'écrire, dans ce cas, Java est meilleur. Mais le serveur pour écrire en Haskell est presque aussi pratique qu'en Java. Si l'environnement le permet - réglage, accessibilité des bibliothèques - alors je choisis habituellement Haskell.
Doctor_Ryner : Avec C #, il suffit de google pour implémenter Maybe en C # et en Haskell. Il est très étrange que le Haskell dictatorial purement fonctionnel se sente beaucoup plus flexible et libre. En fait, ce sont deux extrêmes.
C # est l'un des langages les plus orientés objet, et les avantages de Haskell sont en contraste frappant avec lui. En C #, vous devez constamment écrire un tas de choses inutiles, et tout cela est très désagréable. L'utilisation de fonctions d'ordre supérieur peut gâcher le code en termes de syntaxe. Au milieu de tout cela, il est déjà difficile de revenir des solutions courtes et élégantes de Haskell.
Igor Shevnin : Avec Rust, jusqu'ici en faveur de Rust. Cela prend beaucoup de Haskell et d'autres langages FP, mais en même temps, l'approche fonctionnelle est amicale avec l'impératif, et les développeurs et la communauté sont beaucoup plus compétents et plus cohérents dans le développement du langage dès le début.
Que pensez-vous de la communauté haskelliste?
John Doe : La grande majorité sont des gens très sympathiques qui sont toujours prêts à aider. Une belle différence avec les communautés de nombreuses autres langues.
Doctor_Ryner : Les communautés Haskell contiennent souvent des gens
extrêmement effrayants qui sont toujours prêts à aider. Ce n'est pas pour rien que les mèmes locaux sur le doctorat, la théorie des catégories et les universitaires vont. Si vous entrez dans le chat dans d'autres langues, vous voyez que les gens discutent des problèmes de production ordinaires et des structures de données. Dans une conversation Haskell, des monades, le lemme de Yoneda, des foncteurs applicatifs, des types fous, etc., apparaissent immédiatement devant vous.
Vous voyez immédiatement tellement de nouveautés que vous ne connaissiez pas auparavant - compositions folles, transformations et transformations élégantes, solutions à des problèmes qui occupent des dizaines de lignes dans les langues traditionnelles, presque en une seule ligne.
Ils disent que les Haskellistes sont arrogants. Non?
Denis Mirzoev : Oui. Il me semble que l'arrogance est due au fait qu'ils aiment vraiment leur langue et sont bouleversés par sa sous-estimation.
John Doe : Nifiga comme ça.
Doctor_Ryner : Très probablement, cette opinion a disparu, car de nombreux développeurs grand public sont très ennuyés lorsque les Haskelists commencent à parler de la programmation fonctionnelle et de ses avantages. Un terrible malentendu, à son tour, peut agacer le Haskelist lui-même, et il commencera à se précipiter en termes, pour lesquels il est stigmatisé par la FAQ.
Igor Shevnin : L'arrogance est un mot trop fort. Le point ici est plutôt que FP, OOP, la différence entre les classes OOP et les types d'union, le problème d'extension et de nombreux autres concepts s'ajoutent une fois à une image très claire, et après cela, il devient difficile de percevoir les personnes qui essaient de s'opposer à OOP et FI ou imaginent autrement problème répandu dans une perspective étroite.
Pourquoi les langues FP sont-elles encore des niches?
Denis Mirzoev : Leurs avantages ne sont pas encore suffisants pour intéresser un grand nombre de programmeurs. La difficulté d'apprentissage n'est pas propice à la popularité. Les problèmes de réglage en effrayent également beaucoup, mais il me semble que l'augmentation de la taille de la communauté pourrait résoudre ce problème. Il en résulte un cercle vicieux.
Igor Shevnin : La niche passe progressivement et les concepts fonctionnels sont tirés vers d'autres langues.
Doctor_Ryner : Les principes fonctionnels eux-mêmes et les langages qui les prennent en charge sont déjà omniprésents. Même pour les objets tranchants, il existe Linq et quelques autres bibliothèques. Les créneaux sont des langages plutôt purement fonctionnels, car ils utilisent des concepts non standard.
N'oubliez pas qu'il y a 20 ans, le fer n'était pas suffisamment productif pour les langages fonctionnels, de sorte que le fonctionnalisme a commencé à entrer dans le courant dominant ces dernières années, et l'intérêt pour Haskell ne fait que croître.