Pourquoi Clojure sur d’autres Lisps JVM: Kawa, Armed Bear ou SISC?

La JVM avait déjà trois Lisps avant l’arrivée de Clojure: Kawa , Armed Bear et SISC .

Quel écart comble Clojure qui a été laissé par ces Lisps?

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

Clojure est une nouvelle langue. Cela ne comble pas une lacune . Cela ajoute de nouvelles possibilités. Il privilégie une approche purement fonctionnelle – Scheme et CL sont tous deux multi-paradigmes. Clojure emprunte beaucoup à la conception de plusieurs langages de PF (ML, Haskell).

Et oui, vous pouvez append un support de concomitance à d’autres Lisps, mais cela manque complètement le point. Clojure a été conçu dès le début en tant que langue concurrente. À tel point que l’écriture de programmes simultanés est insignifiante dans Clojure – et non pas de la science comme dans les langages non fonctionnels (Scheme, CL non exclu). Regardez de cette façon:

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

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

  1. “Clojure est un Lisp non contraint par la rétrocompatibilité” (issu du site Clojure). C’est un nouveau départ. C’est du progrès Utilisez les idées qui rendent puissant Lisp / Scheme, mais repensez-les autour de la plate- forme Java.

  2. Clojure sera toujours la Clojure la plus récente. Avec toute autre langue scope sur la machine virtuelle Java, la version de la machine virtuelle Java pourrait toujours être à la traîne. Si vous n’avez pas besoin de la plate-forme Java, pourquoi utiliser SISC sur un autre système? Si vous le faites, pourquoi ne pas utiliser le Lisp (Clojure) spécialement conçu pour cela?

  3. Conçu avec la concurrence en tête.

La réponse la plus simple que je puisse trouver est que Clojure n’est pas Common-Lisp. Clojure n’est pas contraint par l’histoire des autres Lisps. C’est un nouveau langage conçu pour la JVM.

Je n’étais tout simplement pas au courant de cela, ce qui est un avantage sérieux pour Clojure (que les gens ont fait assez de bruit, j’ai découvert). La plus grande chose que Clojure ait jamais vue dans ceux que vous avez répertoriés est la mémoire transactionnelle logicielle .

Clojure a également été conçu pour la JVM, par opposition à être une couche pour un autre langage, donc c’est un peu plus “Java-y” que j’imagine que ce serait quand vous devez faire de l’interopérabilité.

La page de justification sur clojure.org indique:

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

  • Une lisp
  • pour la functional programming
  • 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? Elles sont:

  • Lisps (les dialectes CL ou Scheme) ✓
  • pour la functional programming ✓
  • symbiotique avec une plate-forme établie (la JVM) ✓

mais ils ne sont pas conçus pour la concurrence (STM); 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. Sous 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 (emphase ajoutée):

Qu’en est-il des Lisps standard (Common Lisp et Scheme)?

  • Slow / no innovation post standardisation
  • Structures de données de base mutables, non extensibles
  • Pas de concurrence dans les spécifications
  • De bonnes implémentations existent déjà pour JVM (ABCL, Kawa, SISC et al)
  • Les Lisps standard sont leurs propres plates-formes

Il s’agit d’un problème de conception de concurrence entre les langues , comme d’autres l’ont mentionné.

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

Ce sont les deux lacunes qu’il remplit, de mon sharepoint vue. Vous devriez utiliser Clojure si cela répond à vos besoins. Ne craignez pas de perdre vos compétences si Clojure tombe sur la carte. Vos compétences en Lisp, mais surtout votre façon de penser, se répercuteront sur les autres dialectes Lisp.

Si j’étais cynique, je dirais que c’est parce que Clojure a un site plus sympa et un nom plus sexy.

Je devrais également append que Clojure est un langage relativement nouveau, mis en œuvre par une seule personne, avec de bonnes compétences en marketing et beaucoup d’énergie. Il investit beaucoup de temps et de battage dans la clarté … parfois, le battage médiatique est une prophétie auto-réalisasortingce en ce sens que si vous pouvez convaincre suffisamment de gens que c’est la dernière chose à faire, alors vous pouvez obtenir suffisamment de soutien travail.

Je soupçonne que les implémenteurs de Kawa etc. n’ont pas autant en jeu, donc ne font pas de publicité pour leur produit. D’ailleurs, qu’est-ce qu’il y a à faire? “Nous avons un excellent langage .. il s’appelle Lisp”.

Je pense que Java en est un excellent exemple. Il présentait de graves lacunes, mais parce qu’il était commercialisé et diffusé à un tel niveau, il a pris beaucoup d’élan, c’est-à-dire des fournisseurs de matériel et de logiciels, des producteurs d’outils, des entresockets, etc. succès, même si je détestais la programmation. Clojure pourrait connaître un succès similaire, contrairement aux autres Lisps.

L’avantage de Clojure est qu’il vous donne access à toutes les bibliothèques / codes java et à la prise en charge de plusieurs threads car il est basé sur la machine virtuelle Java. En outre, il a été conçu en pensant à la concurrence, quelque chose qui n’est généralement pas conçu dans lisp, bien qu’à cause des primitives de mappage, il ne soit probablement pas difficile de concevoir un lisp compatible avec la concurrence.

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

Clojure est “un lisp”, ce n’est pas du tout ce que vous savez déjà. J’ai passé les deux derniers jours à lire le matériel et à regarder les vidéos, et je suis impressionné. Son principe est que les programmes fonctionnels (basés sur des données immuables) constituent le meilleur moyen de gérer la concurrence. Clojure implémente un système de type lisp basé sur JVM pour le fournir.

Nous n’avons pas besoin d’une autre réponse (et je ne m’attends pas à des votes pour celui-ci), mais voici quelques petites améliorations apscopes à plusieurs autres réponses.

Le plus récent n’est pas nécessairement meilleur. Les nouveaux et les mal conçus ne sont pas bons, les plus récents et non maintenus ne sont pas bons, et les nouveaux utilisateurs sans communauté d’utilisateurs plus importante (ou du moins croissante) ne sont pas bons. (Les nouvelles langues sortent régulièrement, mais la plupart d’entre elles sont abandonnées à cause de la désuétude.)

J’adore Common Lisp. Une partie de sa beauté est son caractère bizarre, qui vient du fait qu’il a été conçu par des comités dans un but de compatibilité avec plusieurs dialectes incompatibles.

J’adore Scheme. C’est une belle langue élégante. Néanmoins, son développement dépend des comités et cela a peut-être ralenti quelquefois. En tout état de cause, ses objectives sont différents de ceux de Clojure.

Common Lisp et Scheme ont des accents tels que la récursion de la queue qui ne sont pas bien adaptés à l’efficacité de la JVM. Clojure a été conçu dès le départ pour bien mapper sur la JVM, et pour interopérer (assez bien) avec Java. (Je ne suis pas sûr de ce que cela signifie pour les dialectes Clojurescript et CLR.)

Le fait que Clojure ait été développé, au départ, par une seule personne, Rich Hickey, et contrôlé par lui avec une petite équipe, ne le rend pas nécessairement meilleur qu’une langue contrôlée par des comités. Si cette personne prenait de mauvaises décisions, Clojure ne serait pas une bonne langue.

Cependant, et c’est là le point important : Hickey a conçu un langage bien pensé, élégant et qui, dès le début, comprenait une suite de fonctions systématiquement liées qui facilitent le travail avec un peu. Cela vaut pour l’interopérabilité de base de la JVM ainsi que pour le rest de la langue. Les gens qui contrôlent Clojure continuent à respecter les objectives de la langue jusqu’à présent.

Ceci est une grande partie de ce que j’aime chez Clojure: il est bien conçu dans son ensemble et dans ses détails. Cela signifie qu’une fois que vous vous y êtes habitué, c’est un plaisir de le programmer.

Il serait seulement un peu exagéré de dire que Clojure a le pouvoir du Common Lisp avec l’élégance de Scheme. Common Lisp a beaucoup de choses dont vous avez besoin dans le langage, mais c’est un gâchis (je dis cela avec amour), et quand vous avez besoin de quelque chose de plus que ce qu’il y a dans le langage, il y a parfois plusieurs bibliothèques incompatibles avec des compromis différents. Le schéma par conception est petit, bien qu’il existe des bibliothèques disponibles. Clojure a un corps croissant de bibliothèques standard (contrairement à CL) qui sont plus ou moins des parties du langage. Le projet core.masortingx, qui fournit une interface commune à plusieurs implémentations de masortingces différentes, en est une belle illustration. Ceci est important, car il existe différentes implémentations de masortingces qui sont les meilleures pour une utilisation occasionnelle de petites masortingces, ou pour une utilisation extensive de masortingces énormes, 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.

C’est nouveau! Ce qui signifie que beaucoup de vieux lispers ne l’utiliseront pas, car la communauté traditionnelle des lisp est bien, traditionnelle, mais cela signifie aussi que les personnes n’ayant aucune expérience préalable vont la chercher.

Imho, Clojure est aux vieux Lisps ce que Ruby était à Smalltalk. Pas nécessairement mieux, mais assez bon. Et surtout, cela est plus acceptable pour votre employeur parce qu’il a pris de l’élan et qu’il est considéré comme une langue à la hausse, à l’instar de Ruby.