Discussion :

[stendhal666]

Bonjour,

Une question pour les développeurs, expérimentés ou non, du forum:

Avez-vous essayé les différents dialectes de LISP (au moins les trois les plus connus: common LISP, Scheme et Clojure) et pouvez-vous donner vos impressions?

Je navigue depuis quelques semaines dans le monde lispien, à la recherche d'une voie d'entrée bien balisée. J'avais commencé par Common LISP mais sans trouver d'introduction vraiment structurée et systématique. Je suis tombé sur le livre SICP, écrit pour Scheme, qui a l'air magnifique. Enfin j'ai fait quelques recherches sur Clojure, qui semble encore apporter de nombreuses choses, en particulier pour la programmation concurrentielle.

Première constatation: ces langages sont bien différents les uns des autres. Alors, avant d'approfondir l'un ou l'autre, je voulais connaître l'opinion de meilleurs connaisseurs que moi.

Merci!

[byjav]

Mon hobby c'est Common Lisp. C'est un langage bien pensé dont le but est d'offrir à un programmeur expérimenté des instruments puissants. Telles choses comme funcall et un espace de noms pour les fonctions peuvent paraître une complication superflue à un débutant, mais tout ça a ses raisons et, en plus, on s'y habutue.

Common Lisp n'est pas un langage fonctionnel au contraire que l'on le qualifie souvent. (En effet, il suffit de le comparer superficiellement à Haskell.) Le trait « le plus fonctionnel » de Lisp ce sont les fonctions comme les citoyens de première classe, ce qui n'est plus exotique de nos jours. Il a aussi bien d'autre traits utils, comme plusieurs types de donnés, variables dynamiques, etc. Les moyens de programmation orientée objet et la gestion des exceptions sont superbes et la métaprogrammation est inégalé. Lisp et pionnier de REPL; il y a des EDIs de dévéloppement interactif (Emacs, vim). Il y a des réalisations libres, par exemple SBCL, qui est un compilateur très efficace.

Moi, je m'intéresse surtout à la métaprogrammation. Les programmes en Lisp existe en forme de listes. En effet, c'est un type de donnés que Lisp manipule très effectivement. Donc on peut écrire fonctions qui transforment le code. Ça permet de créer un syntaxe qui s'assortit au problème. De cette façon on sépare la structure logique de la réalisation et obtient du code bien déclaratif.

D'autre part, il y a des questions naïves auxquelles il est difficile de trouver une réponse assez simple : par exemple, exécutables autonomes ou GUI.

[jack-ft]

Première constatation: ces langages sont bien différents les uns des autres. Alors, avant d'approfondir l'un ou l'autre, je voulais connaître l'opinion de meilleurs connaisseurs que moi.

J'ai fait beaucoup de Le_Lisp (avec Aida, Smeci, Masai) et de Common Lisp (avec CLOS), que j'ai beaucoup appréciés.
Pour moi, CLOS (et son art of meta-object protocol) est la rolls des langages objet.
Je ne connais pas bien Scheme, mais c'est un lisp "propre/rigoureux".

Mais, pour de petits projets, je préfère emacs-lisp car je l'ai toujours sous la main, que ce soit sur mac, sous Unix, sous linux ou sous Windows et même sous Android!

Il faudrait savoir quel est ton but pour répondre plus précisément!

Si c'est juste pour étudier lisp pendant quelques mois, tu peux prendre n'importe lequel (même emacs-lisp)!

Si c'est pour un gros projet avec interface graphique, accès SGBD, connexion internet, etc., faut voir...

[stendhal666]

Bonjour, et merci pour vos réponses!

Common Lisp n'est pas un langage fonctionnel

En effet, j'ai quelques doutes même sur sa compatibilité avec la programmation fonctionnelle. J'ai fait quelques tests (sous Emacs+SLIME) et j'ai atteint assez rapidement les niveaux de récursivité possibles (à 37000 à peu près). Comme j'avais fait attention à respecter le principe de tail-recursion j'espérais que le compilateur l'optimiserait automatiquement en boucle, mais ça n'a pas fonctionné. Du coup j'ai l'impression qu'on est obligé de passer à un style itératif pour les gros volumes de données ou les grandes précisions. Je ne sais pas en revanche si c'est lié à mon implémentation ou au standard Common Lisp, et il faudrait que je teste sur Scheme pour voir si le problème est le même...

Il faudrait savoir quel est ton but pour répondre plus précisément!

Pour une simple étude, je pense que je choisirais Scheme, qui est plus pur et plus élégant (à mon humble avis). Byjav dit que 'funcall' et autres #'est un inconvénient mineur et qui se justifie, je n'en doute pas mais il est vrai que l'homogénéité totale dans Scheme des fonctions et des variables est assez agréable. Néanmoins, j'aimerais bien que cette étude débouche sur la possibilité de faire de plus gros projets. Avec Common Lisp on trouve facilement des bibliothèques pour faire des GUI ou des applications réseaux?

[byjav]

C'est ça, l'optimisation de la tail-recursion n'est pas obligatoire en CL, de même comme d'autres optimisations. Pourtant certaines réalisations peuvent effectuer cette optimisation, peut-être à condition que le programmeur fournisse certaines déclarations.

En effet, en CL il est difficile (ou biens impossible?) de définir rigoureusement la position `taile' à cause des variables dynamiques.

En tout cas, la récursion n'est pas le moyen typique d'itération en CL. Par exemple, le « Google Common Lisp Style Guide » dit, « You should favor iteration over recursion ».

Cela dit, CL supporte bien les opérations principales de la programmation fonctionnelle: filtration (REMOVE-IF-NOT), mapping (MAP, MAPCAR, etc), filtration+mapping (MAPCAN), folding (REDUCE). En plus, il offre bien d'autres fonctions pratiques comme FIND/FIND-IF, SOME/EVERY/..., COUNT/COUNT-IF, POSITION, etc. Elles acceptent des arguments fonctionnels et aussi sont-elles très générales. Donc, on peut souvent se passer de boucles.

> Pour une simple étude, je pense que je choisirais Scheme, qui est plus pur et plus élégant (à mon humble avis).

Avec Scheme il est difficile d'apprendre à programmer les macros.

> Avec Common Lisp on trouve facilement des bibliothèques pour faire des GUI ou des applications réseaux?

Les applications réseaux - oui, il y a plusieures bibliothèques. Les GUI... Ben, il y en a aussi... On utilise plutôt commonqt (on dit qu'elle est peu « lispy »), et LTK qui est médiocre, mais suffit pour des tâches simples. Toutes les autres sont mortes, je pense. Les réalisations commerciales proposent ses propres GUIs.

[stendhal666]

Les applications réseaux - oui, il y a plusieures bibliothèques. Les GUI... Ben, il y en a aussi... On utilise plutôt commonqt (on dit qu'elle est peu « lispy »), et LTK qui est médiocre, mais suffit pour des tâches simples. Toutes les autres sont mortes, je pense.

Je ne savais pas que Qt était disponible aussi pour CLisp! C'est sûr que c'est un très bon framework. Je me demande ce que ça peut donner en revanche. Déjà pour C++ il est très déconseillé d'utiliser la bibliothèque standard et il faut tout faire avec les classes Qt... Du coup j'hésite un peu avec Clojure, qui compile en bytecode java et permet de réutiliser les bibliothèques écrites en Java, abondantes dans la plupart des domaines.

En tout cas, la récursion n'est pas le moyen typique d'itération en CL. Par exemple, le « Google Common Lisp Style Guide » dit, « You should favor iteration over recursion ».

Cela dit, CL supporte bien les opérations principales de la programmation fonctionnelle: filtration (REMOVE-IF-NOT), mapping (MAP, MAPCAR, etc), filtration+mapping (MAPCAN), folding (REDUCE). En plus, il offre bien d'autres fonctions pratiques comme FIND/FIND-IF, SOME/EVERY/..., COUNT/COUNT-IF, POSITION, etc. Elles acceptent des arguments fonctionnels et aussi sont-elles très générales. Donc, on peut souvent se passer de boucles.

Merci, cela répond très bien à ma question! L'idée en fait c'est qu'on "simule" plutôt la récursion / programmation fonctionnelle avec les fonctions natives comme MAPCAR mais que, comme tu le disais dans ta première réponse, la vraie nature de LISP c'est plus la métaprogrammation que la programmation fonctionnelle. Est-ce que ça ne pose pas des problèmes pour faire de la programmation concurrentielle? Les partisans des langages fonctionnels avancent souvent cet argument selon lequel sans données immuables, la programmation concurrentielle (et donc, de fait, le traitement d'un très grand nombre de données) est largement compliquée.

Avec Scheme il est difficile d'apprendre à programmer les macros.

Donc tu as une expérience de Scheme aussi? Je peux te demander dans quel cadre?
J'ai abordé Scheme il y a quelques jours, je n'ai pas encore vu l'aspect macro mais effectivement ce serait un vrai désavantage car les macros permettent vraiment d'améliorer beaucoup la concision et l'expressivité du code.

[byjav]

La concurrence ne fait pas partie du standard. Ça veut dire 1) qu'elle est laissé à la discrétion des implémentations; 2) qu'il vaut mieux se servir des wrappers portables entre les implémentations plutôt que des idiosyncrasies des implémentations. En effet, les implémentations majeures la supporte et il y a des wrappeurs comme bordeaux-threads. Alors, la concurrence est possible.

Est-ce qu'elle est facile ? Moi, je ne sais pas, je ne m'en ai jamais servi. Je pense que oui, avec propres précautions.

En effet, en Lisp il est pratique et désirable d'organiser le code « à la fonctionnelle »: préférer les fonctions pures, éviter les effets secondaires, séparer l'entrée et la sortie des calculations, etc. Si une fonction se porte comme une fonction pure, il importe peu si sa réalisation utilise des affectations ou des boucles.

> Donc tu as une expérience de Scheme aussi? Je peux te demander dans quel cadre?

J'ai lu quelques introductions. En effet, la Scheme proprement dite est un langage très petit. Naturellement, les implémentations utilisables y ajoutent bien d'extensions. Pour moi c'est call/cc qui est le plus difficile à comprendre. En plus, les uns mettent en relief que les continuations sont très puissantes, alors que les autres affirment qu'elles ne sont pas tout-puissantes...

Il y a deux différences entre les macros en Scheme et en Common Lisp: 1) les macros en Scheme sont « hygiéniques » et donc moins puissants; 2) alors qu'en Common Lisp on écrit les macros en Lisp ordinaire, en Scheme on utilise un langage spécifique que je n'arrive jamais à retenir. Cependant, les macros y sont utiles aussi. En Racket il y a un autre type de macros, mais ils sont trop difficiles pour moi.

A mon avis, Scheme et Common Lisp sont différents à tel point qu'ils ne sont pas compétiteurs. Il faut seulement se rendre compte que CL a un seuil d'entrée plus élevé.

(A propos, CLISP est le nom d'une implémentation, www.clisp.org; l'abréviation usité pour Common Lisp est CL.)

[Kurodiam]

Le plus grand inconvénient de lisp reste le nombre incalculable de parenthèses ,déjà que coder n'est pas évident

Mais sinon Common lisp est le meilleur dialecte pour un apprentissage serein

[byjav]

Le plus grand inconvénient de lisp reste le nombre incalculable de parenthèses ,déjà que coder n'est pas évident

Personne ne les calcule, tout le monde (sauf moi) utilise Emacs qui les calcule lui-même. Moi, j'utilise vim qui les calcule aussi. Ceux qui utilisent d'autres éditeurs sont ennemis pour soi.

[Trap D]

Le plus grand inconvénient de lisp reste le nombre incalculable de parenthèses ,déjà que coder n'est pas évident

Mais sinon Common lisp est le meilleur dialecte pour un apprentissage serein

LISP = Liste Interminable de Stupides Parentheses
LISP = Langage Insipide Stupidement Parenthésé

[jack-ft]

Le plus grand inconvénient de lisp reste le nombre incalculable de parenthèses

Juste pour information, avant de coder en lisp (pendant des dizaines d'années), j'ai commencé par un écrire un moteur d'inférence de système expert (d'ordre 1) en LOGO.
Pour faire extrêmement bref, LOGO c'est exactement comme lisp, mais sans les parenthèses! ;-)
Et avec des graphismes sympa grâce à la tortue Léa, en turtle geometry (idéal pour faire des fractales, par exemple).

Sinon, pour emacs, je plussoie cent fois! ça fait belle lurette que je ne compte plus les parenthèses (merci emacs )!

[stendhal666]

(A propos, CLISP est le nom d'une implémentation, www.clisp.org; l'abréviation usité pour Common Lisp est CL.)

Au temps pour moi, et merci pour cette précision!

Après avoir approfondi mes recherches sur Clojure ce week-end, je voudrais souligner les différences avec ce qui s'est dit dans cette discussion sur CL et Scheme:

En effet, la Scheme proprement dite est un langage très petit. Naturellement, les implémentations utilisables y ajoutent bien d'extensions

Clojure propose en natif vecteurs et tables de hachage entièrement pris en charge, c'est-à-dire:
- avec une syntaxe propre et lisible ([vecteur] {table: hachage}
- un support du langage égal à celui des listes en matière de fonctions natives et de support de la récursivité
- évaluation paresseuse et immuabilité
De plus l'interfaçage réciproque avec Java donne accès à toutes les bibliothèques Java et permet d'appeler Clojure depuis Java.

Common Lisp n'est pas un langage fonctionnel au contraire que l'on le qualifie souvent.

Clojure est conçu pour être utilisé de façon fonctionnelle. En particulier:
- les structures de données natives sont immuables.
- pour ne pas nuire aux performances, un système de révisions (un comme celui de git, par ex) permet de ne pas copier la structure donnée en argument: une référence à la structure constante accompagnée des modifications effectuées est retournée.

La concurrence ne fait pas partie du standard. Ça veut dire 1) qu'elle est laissé à la discrétion des implémentations; 2) qu'il vaut mieux se servir des wrappers portables entre les implémentations plutôt que des idiosyncrasies des implémentations. En effet, les implémentations majeures la supporte et il y a des wrappeurs comme bordeaux-threads. Alors, la concurrence est possible.

Clojure supporte la programmation concurrentielle avec deux concepts en particulier:
- point déjà évoqué, les structures de données immuables
- un modèle transactionnel de gestion de la mémoire partagée, c'est-à-dire que les variables partagées (l'exception à la règle fonctionnelle) sont accessibles uniquement via des transactions semblables à celles des bases de données, pour permettre un accès cohérent par différents threads, sans gestion des locks et autres joyeusetés.

Dernier point, le confort d'utilisation: l'installation n'est pas compliquée (qqs bugs tout de même qui m'ont ralenti mais pas de véritable difficulté), l'intégration avec Emacs est bonne. Surtout, il y a un gestionnaire de build facile d'utilisation, Leiningen, donc, contrairement à CL pour lequel

il y a des questions naïves auxquelles il est difficile de trouver une réponse assez simple : par exemple, exécutables autonomes ou GUI.

il est très facile d'obtenir un exécutable (Java, certes).

CL est un très bon choix recommandé par des programmeurs expérimentés, mais j'ai l'impression en effet que

CL a un seuil d'entrée plus élevé

et qu'il faut bien connaître l'éco-système autant que le langage lui-même...