Pourquoi fermer sur d'autres lisps de la JVM: Kawa, Armed Bear ou SISC?
Avant que Clojure n'arrive sur les lieux, la machine virtuelle Java enregistrait déjà trois bips: Kawa , Armed Bear et SISC .
Quelle lacune Clojure comble-t-elle du sort de ces Lisps?
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 Java.
Clojure est une nouvelle langue. Il ne remplit 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 FP (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). Regarde 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 simultanés par défaut.
"Clojure est un LISP non limité par une compatibilité ascendante" (tiré du site Web de 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 Java platform .
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 le LISP (Clojure) spécialement conçu à cet effet?
Conçu avec la simultanéité à l'esprit.
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. C'est un nouveau langage construit pour la machine virtuelle Java.
Je n'étais tout simplement pas au courant de ces événements, ce qui constitue un avantage sérieux pour Clojure (le fait que les gens aient fait suffisamment de bruit, ce que j'ai découvert). La chose la plus importante que Clojure a eue et que je n’ai pas vue dans celles que vous avez énumérées est Software Transactional Memory .
Clojure a également été conçu pour la machine virtuelle Java, par opposition à une couche pour un autre langage. C'est donc un peu plus "Java-y" que je suppose que les autres le seraient lorsque vous devez effectuer une interopération.
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? Elles sont:
- Lisps (dialectes CL ou Scheme) ✓
- pour la programmation fonctionnelle ✓
- en symbiose avec une plate-forme établie (la JVM) ✓
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:
- STMX
- Testé en travaillant sur ABCL. En développement actif.
- CL-STM
- Morte? Le dernier changement était en 2007.
Hmm ... Alors pourquoi créer un nouveau Lisp? Principalement parce que ce sont bibliothèques. La page de justification sur clojure.org continue (soulignement ajouté):
Qu'en est-il du Lisps standard (Common LISP et Scheme)?
- Peu ou pas d'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 al)
- Les Lisps standard sont leurs propres plateformes
C'est un conception de la simultanéité du langage issue, 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 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 matière de LISP, mais surtout votre façon de penser, se retrouveront dans les autres dialectes du LISP.
Si j'étais cynique, je dirais que c'est parce que Clojure a un plus joli site web et un nom plus sexy.
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 qu’ils ne vendent donc 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 est un excellent exemple de cela. 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 obtenir le même succès que d’autres Lisps.
L'avantage de Clojure est qu'il vous donne 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 avec la concomitance en tête, ce qui n’est généralement pas prévu dans le 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 concurrence.
Cela dit, j’ai essayé Clojure et détestais la syntaxe et la douleur dans le fessier qui semble aller de pair avec tout ce qui est connecté à Java.
Clojure est "un LISP", ce n'est pas un LISP que vous connaissez déjà. J'ai passé les derniers jours à lire le matériel et à visionner les vidéos, et je suis impressionné. Son principe Est que les programmes fonctionnels (basés sur des données immuables) sont le meilleur moyen de gérer des accès simultanés. Clojure implémente un système de type LISP basé sur JVM pour le fournir.
C'est nouveau! Ce qui signifie que peu d'anciens utilisateurs l'utiliseront car la communauté LISP traditionnelle est bien, traditionnelle, mais cela signifie également que les personnes sans aucune expérience préalable de LISP le prendront comme nouvelle chose.
À mon humble avis, Clojure est pour les anciens Lisps ce que Ruby était pour Smalltalk. Pas forcément mieux, mais assez bon. Et surtout, il est plus acceptable pour votre employeur car il est dynamique et considéré comme un langage en plein essor, un peu comme Ruby.
Nous n'avons pas besoin d'une autre réponse (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 le LISP commun. Une partie de sa beauté réside dans son originalité, car elle a été conçue par des comités dans le but d’une compatibilité ascendante avec plusieurs dialectes incompatibles.
J'adore le programme. 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.
Les programmes LISP et Scheme communs ont des aspects tels 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 le point important : Hickey a conçu un langage bien pensé, élégant et qui, dès le départ, incluait une suite de fonctions systématiquement associées qui facilite la tâche pour faire 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. Le LISP commun a beaucoup de choses dont vous avez besoin dans le langage, mais c'est un désordre (je le dis avec amour), et quand vous avez besoin de quelque chose de plus que ce qui est dans le langage, il y a parfois plusieurs bibliothèques incompatibles avec différents compromis. Schéma par conception est petit, bien qu'il existe des bibliothèques disponibles. Clojure a un corps croissant de standard bibliothèques (contrairement à CL) qui font plus ou moins partie du langage. Le projet core.matrix, qui fournit une interface commune à plusieurs implémentations matricielles différentes, en est une belle illustration. Ceci est important, car il existe différentes implémentations de matrice qui conviennent le mieux pour une utilisation occasionnelle de petites matrices ou pour une utilisation intensive de matrices é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.