Y aura-t-il un langage fonctionnel qui fasse pour la communauté Java ce que F # fait pour la communauté .NET?

Question

Y aura-t-il un langage fonctionnel qui fasse pour la communauté Java ce que F # fait pour la communauté .NET?

Quels langages de programmation fonctionnels sont disponibles ou en développement pour la machine virtuelle Java?

Answer 1

Peut-être Clojure . Ce n'est pas typé statiquement, mais il met davantage l'accent sur l'immutabilité et la concurrence que F #. Cependant, comme F # (et contrairement à Common Lisp), il est conçu pour être un langage principalement fonctionnel, capable de consommer des bibliothèques OO de la plate-forme sous-jacente.

Answer 2

Scala serait la langue.

Bien que n'étant pas strictement fonctionnel (c'est un mélange de fonctionnel et orienté objet) et qu'il ne soit pas strictement pour Java (il existe un . NET de Scala ), ce serait l'analogue le plus proche de F # dans la machine virtuelle.

Answer 3

La première chose qui m'est venue à l'esprit était Scala mais vraiment Ocaml-Java se rapproche car F # est une variante de Ocaml. Voir cet article qui compare Ocaml-Java à Scala :

  

Les programmeurs OCaml sont généralement 10 fois plus productifs que Java ou C ++.   programmeurs pour un large éventail de tâches pratiques. Bien que basé sur un   fondamentalement la plate-forme OOP, F # contribue grandement à capturer la productivité   augmenter les avantages d’OCaml (et de toute la famille ML). En revanche, Scala   ne parvient pas à saisir de nombreux avantages, y compris certains très basiques et,   Par conséquent, écrire du code correct est beaucoup plus difficile en Scala qu'en   toute vraie ML.

     

De plus, la famille de langues ML est conçue pour être succincte mais Scala est   Inutile de faire des commentaires pour tout ce qui concerne "Bonjour tout le monde!" vers le haut. La famille ML   des langages fournissent une inférence de type étendue (OCaml plus que la plupart) mais   La scala n'a qu'une inférence rudimentaire par comparaison. OCaml a exceptionnellement   système de type expressif mais Scala ajoute peu à la POO qui soit pratique   importance.

Answer 4

Pour l'instant, je dirais Scala. Mais pour le futur, je regarderais Fortress. La première mise en œuvre de la spécification a été publiée le 1er avril 2008. Et non, ce n'est pas une blague. Les principales caractéristiques sont les suivantes:

• Typiquement, mais beaucoup d'inférence de type pour éviter l'encombrement
• Rendu Unicode et 2D de fonctions mathématiques
• Conçu pour une exécution parallèle (par défaut)
• Prise en charge importante des bibliothèques personnalisées (influence de Guy Steele)
• Surcharge d'opérateur, y compris l'opérateur de juxtaposition

Plus d'informations sur le Site Web de la communauté Project Fortress et la page Wikipedia Fortress .

Answer 5

Sans doute aucune, car la machine virtuelle Java manque d’appels de fin de ligne et est tenue de rendre presque tout le code fonctionnel robuste en ce qui concerne la consommation de la pile.

La solution la plus proche des implémentations de langage fonctionnel sur la machine virtuelle Java est Clojure , Scala et le OCaml-Java projet. Bien qu'il existe des solutions de contournement pour le manque d'appels de queue (par exemple, le trampoline), aucune de ces implémentations de langage ne le fait parce que les solutions de contournement introduisent des problèmes encore plus graves, par exemple. Des performances rédhibitoires et un débogage complètement obscurcissant.

Sun parle d’appels de queue depuis des années et, plus récemment, ont indiqué leur intention de les mettre en œuvre prochainement. Dès que cela sera fait, je suis sûr que nous verrons beaucoup plus de diversité linguistique sur la JVM et, en particulier, certaines implémentations de langage fonctionnel de qualité production. Jusque-là, je considère toutes ces langues comme des jouets.

Salut, Jon Harrop.

Answer 6

Il existe une bonne liste de langages de programmation pour JVM, y compris le paradigme de programmation fonctionnelle et d’autres langages de paradigme sur:

• fr.wikipedia.org/wiki/List_of_JVM_languages ??

Mon premier choix est Scala (multi-paradigme; OO & FP). J'ai passé plus de 5 mois à étudier Scala en 2009 et j'ai créé une fiche de référence rapide: bchiprog.blogspot.com/2009/05/scala-cheat. -sheet.html

J'ai remarqué que d'autres paradigmes de programmation sont intéressants, d'autres se concentrant sur le traitement parallèle, tels que X10, Fortress et Chapel. X10 est implémenté au sommet de Scala - http: // www. scala-lang.org/sites/default/files/odersky/scalaliftoff2009.pdf

Cela dépend vraiment du problème que vous devez résoudre, puis choisissez le langage qui le résout le mieux. Je pense que les développeurs souhaitent qu’un seul langage puisse résoudre tout type de problème facilement et simplement.

Answer 7

@Marc Gravell - les langages fonctionnels sont de plus en plus utilisés dans les entrailles des systèmes financiers de niveau entreprise. Nous utilisons beaucoup de fonctionnalités (pures ou "semi-pures") à la banque pour laquelle je travaille ...

Answer 8

Entre-temps, il existe Frege , un langage purement fonctionnel et non strict dans l'esprit de Haskell qui compile en Java, qui est ensuite compilé avec javac ou le compilateur eclipse, en fonction de l’environnement (ligne de commande ou eclipse).

Answer 9

En fait, je me trompe peut-être, mais je ne m'attends pas à ce que F # soit aussi courant que les autres langages .NET; utile dans quelques cercles (académiques, compilateurs, quelques autres scénarios), mais n'oubliez pas que C # offre l'utilisation de la PF - et que cela s'améliore à chaque fois: C # 1.2 a des délégués; C # 2.0 a des méthodes anonymes et des captures / fermetures; C # 3.0 a lambdas pour la simplicité et Expression pour l'abstraction. Les types anonymes (C # 3.0) partagent quelques similitudes avec les n-uplets (en termes de commodité), mais sont évidemment très différents, alors il ne s'agit certainement pas d'une comparaison à l'identique.

Peut-être pas aussi optimisé que F #, mais pour la plupart des cas d'utilisation quotidiens de la PF, c'est plus que suffisant.

Il est également tout à fait clair que l’équipe C du langage C # devrait être mieux prise en charge pour l’avenir (en particulier pour les threads).

Mon argent repose sur l'amélioration de C # chez FP et sur l'offre de FP .NET pour la plupart des tâches quotidiennes. Bien sûr, il y aura une certaine utilisation de F # - mais (purement subjectif), je ne vois tout simplement pas une migration énorme.