Pourquoi fermer sur d'autres lisps de la JVM: Kawa, Armed Bear ou SISC?

Question

La machine virtuelle Java comptait déjà trois Lisps avant l'arrivée de Clojure: Kawa , Ours armé et SISC .

Quelle lacune Clojure a été laissée par ces Lisps?

Answer 1

Kawa, ABCL et SISC sont des réimplémentations de langages existants assez longs dans la dent. Ils sont excellents si, pour une raison quelconque, vous souhaitez utiliser un schéma standard ou un Common Lisp standard sur la machine virtuelle.

Clojure est une nouvelle langue. Cela ne comble pas un espace . Cela ajoute des possibilités entièrement nouvelles. Il privilégie une approche purement fonctionnelle. Scheme et CL sont tous deux des paradigmes multiples. Clojure emprunte énormément à la conception de divers langages de PF (ML, Haskell).

Et oui, vous pouvez ajouter la prise en charge de la simultanéité à d’autres Lisps, mais cela manque tout à fait. Clojure a été conçu dès le début comme langage concourant. À tel point que l'écriture de programmes simultanés est triviale dans Clojure - et non pas sournoise comme dans les langages non fonctionnels (Scheme, CL non exclu). Regardez comme ça:

Les gens disent que C vous permet d'écrire des programmes rapides par défaut.

Eh bien, Clojure vous permet d’écrire des programmes concurrents par défaut.

Answer 2

1. "Clojure est un Lisp non limité par la compatibilité ascendante" (sur le site Clojure). C'est un nouveau départ. C'est du progrès. Utilisez les idées qui rendent Lisp / Scheme puissant, mais repensez-les autour de la plate-forme Java .

2. Clojure sera toujours le plus récent Clojure. Avec toute autre langue portée sur la machine virtuelle, la version de la machine virtuelle peut toujours être en retard. Si vous n'avez pas besoin de la plate-forme Java, pourquoi utiliser SISC sur un autre schéma? Si vous le faites, pourquoi ne pas utiliser celui Lisp (Clojure) spécialement conçu à cet effet?

3. Conçu pour la simultanéité.

Answer 3

La réponse la plus simple que je puisse trouver est que Clojure n’est pas Common-Lisp. Clojure n'est pas limité par l'histoire des autres Lisps. Il s'agit d'un nouveau langage construit pour la machine virtuelle.

Answer 4

Je n’étais tout simplement pas au courant, ce qui est un avantage sérieux pour Clojure (le fait que les gens aient fait suffisamment de bruit que j’ai découvert). La chose la plus importante chez Clojure que je n'ai pas vue parmi celles que vous avez énumérées est la mémoire transactionnelle logicielle .

Clojure a également été conçu pour la machine virtuelle Java, par opposition à une couche pour un autre langage, il est donc un peu plus "Java-y". que j'imagine que les autres seraient quand vous devez faire de l'interopération.

Answer 5

La page de justification sur clojure.org indique:

  

Pourquoi ai-je écrit encore un autre langage de programmation? Essentiellement parce que je voulais:

     

  
• Un Lisp
  
• pour la programmation fonctionnelle
  
• symbiotique avec une plate-forme établie
  
• conçu pour la concurrence
  

     

et n'a pas pu en trouver un.

Les 3 langues que vous avez mentionnées (kawa, ABCL et SISC) répondent-elles à ces exigences? Ils sont:

• Lisps (dialectes CL ou Scheme) & # 10003;
• pour la programmation fonctionnelle & # 10003;
• symbiotique avec une plate-forme établie (la machine virtuelle Java) & # 10003;

mais ils ne sont pas conçus pour (STM) Concurrency; cependant, pour être juste et complet, il y a au moins 2 bibliothèques STM que j'ai trouvées pour CL qui n'ont pas encore été mentionnées:

1. STMX
   • Testé en travaillant sur ABCL. En développement actif.
2. CL-STM
   • mort? Le dernier changement date de 2007.

Hmm ... Alors, pourquoi créer un nouveau Lisp? Principalement parce que ce sont des bibliothèques . La page de justification sur clojure.org continue (soulignement ajouté):

  

Qu'en est-il du Lisps standard (Common Lisp et Scheme)?

     

  
• Lente / aucune innovation après la normalisation
  
• Structures de données de base mutables, non extensibles
  
• Pas de simultanéité dans les spécifications
  
• De bonnes implémentations existent déjà pour JVM (ABCL, Kawa, SISC et autres)
  
• Les Lisps standard sont leurs propres plates-formes
  

C’est un problème de conception de la simultanéité linguistique , comme d’autres l'ont déjà mentionné.

En outre, pourquoi s’arrêter à la JVM? Le support Clojure CLR est en cours de développement .

Ce sont les 2 lacunes qu'il comble, de mon point de vue. Vous devriez utiliser Clojure si cela répond à vos besoins. Ne craignez pas de perdre vos compétences si Clojure laisse tomber la carte. Vos compétences en Lisp, mais surtout votre façon de penser, seront appliquées aux autres dialectes en Lisp.

Answer 6

Si j'étais cynique, je dirais que c'est parce que Clojure porte un site web plus agréable et un nom plus sexy.

Answer 7

Je devrais également ajouter que Clojure est un langage relativement nouveau, mis en œuvre par une seule personne, doté de bonnes compétences en marketing et de beaucoup d’énergie. Il investit beaucoup de temps et de battage dans le clojure ... parfois, le battage est une prophétie auto-réalisatrice dans le sens où, si vous pouvez convaincre suffisamment de gens que c'est la dernière chose à faire, vous pouvez obtenir suffisamment de soutien et d'élan pour le réaliser. travail.

Je soupçonne que les développeurs de Kawa, etc. n’ont pas autant en jeu, et donc ne vendent pas leur produit. D'ailleurs, qu'y a-t-il à dire? "Nous avons une excellente langue ... elle s'appelle Lisp" C'est une vente marketing plus difficile.

Je pense que Java en est un excellent exemple. Il présentait de très sérieuses carences, mais parce qu’il avait été mis sur le marché et suscité à fond, il a pris un élan considérable, ce qui a nécessité l’appui de vendeurs de matériel informatique et de logiciels, de producteurs d’outils, d’investissements de l’industrie, etc. succès, même si je détestais y programmer. Clojure pourrait connaître le même succès que les autres Lisps.

Answer 8

L’avantage de Clojure est qu’il vous donne l’accès à toutes les bibliothèques / codes java et au support multi-thread car il est basé sur la JVM. En outre, il a été conçu pour la simultanéité, quelque chose qui n’est généralement pas conçu dans lisp, bien qu’en raison des primitives de mappage, il ne serait probablement pas difficile de concevoir un lisp qui prendrait bien en charge la simultanéité.

Cela étant dit, j'ai essayé Clojure et détesté la syntaxe et la douleur dans le facteur de blocage qui semble aller de pair avec tout ce qui est connecté à Java.

Answer 9

Clojure est "un lisp", ce n'est pas un lisp que vous connaissez déjà. J'ai passé le dernier quelques jours à lire le matériel et à regarder les vidéos, et je suis impressionné. Ses La prémisse est que les programmes fonctionnels (basés sur des données immuables) sont le meilleur moyen de gérer la simultanéité. Clojure implémente un système de type lisp basé sur JVM pour le fournir.

Answer 10

Nous n'avons pas besoin d'une réponse supplémentaire (et je ne m'attends pas à des votes pour celle-ci), mais voici quelques améliorations mineures à plusieurs autres réponses.

Plus récent n’est pas nécessairement meilleur. Plus récent et mal conçu n'est pas bon, plus récent et non entretenu n'est pas bon, et plus récent sans une communauté d'utilisateurs plus large (ou du moins en croissance) n'est pas bon. (De nouvelles langues apparaissent régulièrement, mais la plupart d'entre elles sont abandonnées à cause de leur désuétude.)

J'aime Common Lisp. Une partie de sa beauté réside dans son originalité, qui découle du fait qu’il a été conçu par des comités dans l’objectif de la compatibilité en amont avec plusieurs dialectes incompatibles.

J'aime Scheme. C'est une belle langue élégante. Néanmoins, son développement dépend des comités, ce qui l’a peut-être parfois ralenti. En tout état de cause, ses objectifs sont différents de ceux de Clojure.

Common Lisp et Scheme ont des priorités telles que la récursion de la queue qui ne conviennent pas à l'efficacité sur la JVM. Dès le début, Clojure a été conçu pour bien s’intégrer à la JVM et pour interopérer (assez) bien avec Java. (Je ne sais pas ce que cela signifie pour les dialectes Clojurescript et CLR.)

Le fait que Clojure ait été développé initialement par une personne, Rich Hickey, et qu’il soit contrôlé par lui avec une petite équipe ne le rend pas nécessairement meilleur qu’un langage contrôlé par des comités. Si cette personne prenait de mauvaises décisions, Clojure ne serait pas un bon langage.

Cependant, et c’est là le point important : Hickey a conçu un langage bien pensé, élégant et intégrant dès le départ une suite de fonctions systématiquement associées qui facilitent la beaucoup avec un peu. Cela vaut pour l’interopérabilité de base de la machine virtuelle Java ainsi que pour le reste du langage. Les gens qui contrôlent Clojure continuent à faire preuve de rigueur dans le respect des objectifs de la langue, jusqu'à présent.

C’est une grande partie de ce que j’aime dans Clojure: c’est bien conçu dans son ensemble et dans ses détails. Cela signifie qu’une fois que l’on s’y habitue, c’est un plaisir de programmer.

Ce ne serait qu’un peu exagéré de dire que Clojure a le pouvoir de Common Lisp avec l’élégance de Scheme. Common Lisp a énormément de ce dont vous avez besoin dans le langage, mais c'est un désordre (je le dis avec amour), et lorsque vous avez besoin de quelque chose de plus que ce qu'il est dans le langage, il existe parfois plusieurs bibliothèques incompatibles avec des compromis différents. Schéma par conception est petit, bien qu'il existe des bibliothèques disponibles. Clojure a un nombre croissant de bibliothèques standard (contrairement à CL) qui font plus ou moins partie du langage. Le projet core.matrix, qui fournit une interface commune à plusieurs implémentations de matrices différentes, en est une belle illustration. Ceci est important, car il existe différentes implémentations de matrices qui conviennent le mieux pour l’utilisation occasionnelle de petites matrices ou pour une utilisation intensive d’énormes matrices, par exemple.

Rien de tout cela ne veut dire que Clojure est meilleur que Common Lisp ou Scheme; ce n'est pas. Les trois langues ont des vertus différentes.

Answer 11

C'est nouveau! Ce qui signifie que peu de vieux lispers l'utiliseront car la communauté lisp traditionnelle est bien, traditionnelle, mais cela signifie également que les personnes n'ayant aucune expérience de lisp auparavant le prendront comme nouvelle chose.

Imho, Clojure est pour Lisps plus âgé ce que Ruby était pour Smalltalk. Pas forcément mieux, mais assez bon. Et surtout, c’est plus acceptable pour votre employeur, car il est dynamique et considéré comme un langage en plein essor, un peu comme Ruby l’était.