Quel est le langage de production le plus compatible et le plus utilisé pour exporter les connaissances et les compétences acquises de Haskell?


14

J'aime Haskell, simple et simple. Bien que Haskell soit utilisé dans les logiciels de production, il n'est pas particulièrement largement déployé à partir de ce que j'ai vu. Quel est le langage le plus similaire et le plus utilisé en ce qui concerne les projets de production afin que je puisse avoir la chance d'une boule de neige d'utiliser quelque chose de génial dans l'industrie?

La même langue de la première partie est-elle également disponible sur un grand nombre de plates-formes? Sinon, quelle est la meilleure alternative qui offre un large déploiement de plate-forme? J'aimerais une seule langue à mettre sur ma liste de tâches plutôt qu'un essaim massif ou une famille. Des preuves tangibles seraient un plus.

Réponses:


21

Haskell est le plus étroitement lié à la famille de langues ML. Cela inclut des choses comme OCaml , bien sûr, mais aussi F # sur la plate-forme .NET. Ces langages partagent avec Haskell les fondements du système de types et la façon dont les données sont utilisées - types de données algébriques, correspondance de modèles, inférence de types, etc. , pour commencer, et la popularité de Haskell comme véhicule de recherche dans les systèmes de types et la conception de langage signifie que la plupart des langages de style ML ont tendance à avoir des systèmes de type moins puissants (mais potentiellement plus faciles à comprendre). Il est probablement prudent de dire que même si vous pouvez manquercertaines choses à propos de Haskell, en particulier au début, la plupart des programmeurs Haskell se sentiraient probablement à l'aise dans un ML assez rapidement, à un niveau de base. Si vous voulez un langage avec la même structure globale que Haskell, un ML est votre meilleur pari.

Le côté fonctionnel de Scalas'inspire également fortement de la tradition ML, et intègre également des fonctionnalités de système de type avancées familières à Haskell, ainsi qu'un système OOP plus standard intégré à ce qui précède. Alors que OO dans les langages de style ML a tendance à être considéré comme davantage un "modèle OO avec des outils fonctionnels de base", Scala vit et respire OO de style Java. Cela présente des avantages pour Java Interop, comme vous pouvez l'imaginer, et présente un environnement de travail plus familier pour les programmeurs OO. Cependant, venant d'un arrière-plan Haskell, vous êtes plus susceptible d'être ennuyé par les façons dont le mélange des choses dans Scala rend les idiomes fonctionnels plus maladroits et trouve la plupart des API Java mal conçues et inutilement difficiles à utiliser.

Enfin, même si cela peut sembler étrange à considérer, Clojure a en fait beaucoup de choses en commun avec Haskell à un niveau plus philosophique. La plupart de ce que vous trouverez dans l'approche de Clojure de l' état et des valeurs par rapport aux identités est très proche de ce que Haskell formalise à travers le système de type. En conséquence, Clojure met l'accent sur l'interopérabilité Java dans une moindre mesure et ne se soucie pas autant de glisser dans la POO, donc à certains égards, l'approche de Clojure de la programmation fonctionnelle elle - même peut être la plus proche de ce que vous connaissez déjà. Je pense qu'il est révélateur à cet égard que, à ma connaissance, Clojure est la seule langue en plus de Haskell qui a une implémentation de STMc'est simple, efficace et ça marche. D'un autre côté, Clojure est issu de la tradition Lisp et n'a donc pas le système de type statique et l'accent sur les types de données algébriques et la correspondance de motifs trouvés dans les langages influencés par ML. Et bien sûr, c'est un Lisp, qui est en soi un point négatif pour certaines personnes (même si je ne sais vraiment pas pourquoi).

Pour ma part, avec l'avertissement que ma première expérience avec la programmation fonctionnelle était dans Scheme, je pencherais probablement vers Clojure, avec OCaml un deuxième choix probable.


1
F # aurait été inspiré, sinon dérivé, d'OCaml. Une précédente question SO, F # et OCaml , couvre une bonne discussion de cette relation. Si vous êtes du côté .NET, F # serait un excellent choix et Microsoft considère désormais F # comme un langage .NET de "première classe". Du côté de la JVM, Scala a des antécédents d'utilisation industrielle et Clojure semble être en hausse dans les charts. Je ne connais pas de meilleur choix à l'heure actuelle, car le marché n'a pas encore déclaré un gagnant clair dans cet espace objet-fonctionnel.
John Tobler

4

Je ne l'ai jamais utilisé moi-même, mais je vois parfois Scala apparaître dans des blogs ou des descriptions de projets et je crois que cela a pris des concepts majeurs de Haskell. Scala se compile sur la JVM et peut interagir avec Java.


3

Une alternative fonctionnelle est Erlang . Bien qu'il s'agisse d'un langage très simultané, le sous-ensemble séquentiel est un langage fonctionnel pur avec de nombreuses propriétés des langages fonctionnels, par exemple les fermetures, les données immuables et la correspondance de modèles. Il fonctionne sur de nombreuses plates-formes, y compris linux, divers unix, windows et macosx. Il y a même maintenant une implémentation sur la JVM, erjang . Il peut facilement communiquer et coexister avec d'autres langues, c'est ainsi qu'il est souvent utilisé.

Consultez le site principal .


3

Clojure est de plus en plus largement utilisé, et bien qu'il ne ressemble pas à Haskell à un niveau superficiel, si vous regardez un peu plus en profondeur, il est clairement très inspiré par Haskell et encourage un style fonctionnel très similaire.

Fonctionnalités clés de Clojure que les utilisateurs de Haskell peuvent trouver familières et convaincantes:

  • Le langage principal est purement fonctionnel - bien que des effets secondaires soient possibles, ils sont enfouis dans des endroits spécifiques (par exemple, références STM, fonctions IO, interopérabilité Java)
  • Toutes les structures de données sont immuables et persistantes
  • Paresse - obtenue en grande partie grâce aux séquences paresseuses omniprésentes de Clojure, cela semblera très familier aux utilisateurs de Haskell. Les séquences paresseuses infinies sont très bien.
  • Mémoire transactionnelle logicielle - est le principal moyen de gérer l'état mutable dans Clojure. Cela vaut la peine de regarder cette excellente vidéo où Rich Hickey explique l'approche de Clojure en matière d'identité et d'État: http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

Différences clés (peuvent être positives ou négatives selon votre point de vue):

  • C'est impur - bien que mon observation soit que le style idiomatique de Clojure consiste à coller des fonctions pures dans la mesure du possible.
  • Typage dynamique plutôt que statique (bien que des conseils de type statique puissent être utilisés en option pour des optimisations de performances)
  • C'est un langage JVM avec un accès facile à l'ensemble de l'écosystème des bibliothèques Java - c'est à mon avis le plus grand avantage en termes d'applicabilité dans le monde réel
  • Syntaxe Lisp. Ainsi, vous obtenez tous les avantages de l' homoiconicité , au prix d'avoir à apprendre à voir à travers toutes les parenthèses :-)

Point de vue personnel: j'ai appris Haskell avant Clojure et j'ai adoré Haskell pour son élégance et sa pureté mathématique. Clojure tire beaucoup d'inspiration et emprunte beaucoup de bonnes fonctionnalités à Haskell, mais est une langue beaucoup plus pragmatique / pratique. Surtout lorsque vous comptez l'énorme valeur de pouvoir tirer parti de l'écosystème de la bibliothèque Java, c'est un excellent langage pour "faire avancer les choses".


1

Si vous aimez Haskell, mais devez faire du code pour la JVM, frege peut vous intéresser. Il est conçu pour être aussi proche que possible de Haskell 2010, tout en générant du code Java.

Bien sûr, frege lui-même n'a rien à voir avec le «langage de production largement utilisé» (il vient d'être publié récemment), mais Java l'est certainement.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.