Sommaire
Salut journal,
Je suis de plus en plus frustré par le langage Python, et comme j'aime bien le Emacs Lisp, à la fois le langage et l'environnement de développement, j'ai retenté le coup avec Common Lisp. C'était assez frustrant mais j'ai pris quelques notes qui pourraient servir aux suivants, d'où ce journal (ça fait un paquet d'années qu'on n'a pas parlé de Common Lisp par ici, ni d'aucun Lisp d'ailleurs même ceux à succès comme Clojure (et à part Guix et Guile)).
Pour ci-dessous: je suis toujours un noob hein.
Introduction
Impressions générales
Mes impressions après quelques semaines:
- la documentation remontée par google est vieille et moche mais il y a mieux, je vous donne les liens,
- le langage a plein de bizarreries mais plein de projets sont là pour les réparer (cl21 et autres bibliothèques),
- l'écosystème est moderne (gestionnaire de paquets, frameworks web, libs pour des trucs modernes), mais il reste des lacunes,
- ça bouge.
Deux liens pour commencer
Je n'ai pas découvert ce site de suite, or c'est pour moi de loin le meilleur: présentation du langage, exemples à succès, tutoriaux concis, modernes et clairs, liste de bibliothèques recommandées, sous github, j'ai nommé:
- http://lisp-lang.org/ (saviez-vous que CL est plus rapide que NodeJS ?)
(petite leçon: je n'avais qu'à cliquer sur tous les liens donnés dans /r/common_lisp)
L'auteur était timide et ne l'avait pas publié «officiellement» mais son soft est super: Portacle, un environnement de développement portable et multiplateforme qui fournit Emacs, l'interface Slime, une implémentation de Common Lisp, Quicklisp le gestionnaire de paquets, et Git. Le plus simple pour tester maintenant, tout de suite, sans installation:
Pourquoi (Common) Lisp ?
Vite fait, ce qui m'intéresse:
- langage extensible, toujours avec la même syntaxe. Je veux des pipes, du pattern matching, du typage statique, de l'async, plus d'orienté objet, du message passing (Erlang/Elixir),… ? Ok, j'installe une lib, je n'attends pas que le langage évolue via des PEP et des nouvelles versions non rétro-compatibles. Voyez comment Hy a backporté "yield from" vers Python2. C'était possible car Hy est un lisp (un lisp qui transpile en Python).
- je veux débugger en direct du code qui tourne dans l'espace (dernier paragraphe).
Pourquoi pas…
- Clojure ? Ça a l'air génial, mais pas de stacktraces de 2km de long avec 50 projets java pour moi, merci…
- Scheme ? Racket ? Je ne vois pas des trucs de fous sur reddit, je ne vois pas de liste "Awesome Racket", la communauté a l'air encore plus petite, les macros ont l'air moins puissantes et plus verbeuses à définir.
- Guile ? Le langage d'extension officiel de GNU, utilisé entre autres pour étendre the Gimp, utilisé par Guix. Oui, j'aimerais bien, mais la communauté et l'écosystème est encore plus minus…
- Hy ? Je souhaite changer d'environnement.
- Elixir ? Je devrais !!! Plus fonctionnel, avec des macros à la lisp… oui, je devrais sûrement, mais voilà j'aime les parenthèses qui sont une syntaxe claire et sont je trouve expressives: ce bloc de parenthèses, c'est un bloc qui va ensemble, que je peux évaluer. (et puis, la dernière fois je n'ai pas vraiment trouvé les libs dont j'avais besoin).
- LFE, Joxa (pour du Erlang) ? Pourquoi pas.
Python, un sous-ensemble de Lisp
Lisp a de l'orienté objet plus évolué. On peut créer des méthodes génériques par exemple. Je cherche des explications de Julien Danjou que je ne retrouve pas :]
Avec Python on peut construire des context managers (with …) mais: ils ont une syntaxe spéciale et on ne peut pas tout faire. Par exemple, on ne peut pas retourner de variables et c'est dommage, ça me permettrait d'intercepter des exceptions et de retourner un message pour l'utilisateur, bref de factoriser un peu plus mon code.
Or, Lisp a les fameuses macros ! Je prends des listes en paramètres, ce peut être des arguments ou des listes qui représentent du code: "code is data". Je peux former du nouveau code, placer tout ou partie du code en paramètre où je veux. C'est ça qui permet d'étendre le langage. Or CL a même des macros pour le "reader", le lecteur du compilateur qui va représenter le code en structure interne: on peut donc modifier des symboles. Ainsi on peut utiliser la syntax @ pour des décorateurs (à l'œuvre dans un framework web pour définir des routes) ou permettre l'interpolation de strings type print "hello #{name}".
Et re-voyez mon point plus haut: Lisp est extensible, avec une syntaxe cohérente.
Bon, mon objectif principal est de parler de l'écosystème.
L'écosystème Common Lisp
- gestionnaire de paquets: pip => Quicklisp. Re-construit une fois par mois, bien peu. Système qui repose sur une personne. Sinon, marche nickel, facile à installer et à utiliser:
(ql:quickload :project). Mais aussi Roswell, qui permet l'installation de libs en ligne de commande, le partage et l'installation de scripts, l'installation d'implémentations (pyenv). - CPython => Steel Bank Common Lisp (SBCL), et d'autres implémentations
- pyenv => Roswell
- virtual envs => Qlot
Doc:
- Read the docs => Quickdocs
- Sphinx => Sphinx aussi, ou Common Doc
- doc officielle => CL Ultra Specs (en construction, par l'auteur de Portacle)
Listes de libs:
- http://lisp-lang.org/wiki/article/recommended-libraries à recouper avec https://github.com/CodyReichert/awesome-cl
Projets:
- frameworks web: Lucerne, Caveman2
- WSGI => Clack
- ORMs => plusieurs, pour Postrgre, SQLite etc, dont Crane avec des migrations automatiques (pas mal ! mais… ne permet pas encore des allés et retours, comme avec Django qui numérote les fichiers de migration, et ne marche pas pour SQLite).
- le système de paquets: setup.py => définition asdf, équivalent.
- requests => dexador
- tests => prove
- et il y a des choses modernes comme un accès à l'api twitter, authentification Oauth2, les web apps dans Électron avec Ceramic, etc
La première chose qui m'a fatiguée, c'est travailler sur des listes de charactères: join, replace, trim, etc. Il fallait utiliser 4-5 librairies ou fonctions différentes avec des constructions bizarres. Trop dingue qu'il n'y ait pas une lib qui donne un tout cohérent. J'ai donc regroupé quelques fonctions dans cl-str puis découvert après (évidemment) cl-strings (qui cependant a une implémentation un peu bizarre car ne reprend pas les libs existantes).
Petite note, pour éviter des critiques faciles: oui écrire est (caaadr (cddddr… est possible mais il y a first, second… last, tail dans le langage.
Alors, où sont les projets géniaux ? Eh bien, chez Grammarly par exemple qui fait tourner du CL dans un environnement de production exigeant, chez OpusModus:
chez Mirai qui a produit la tête de Gollum:
et en sciences, on crée toujours des programmes en Lisp, après des essais avec Python, pour de la métaprogrammation moléculaire avec LLVM et C++ (CLASP)…
mais les applications libres ? À part Turtl qui sert les framanotes, Guix en Guile (Scheme) ou le navigateur Lispkit en construction, je ne vois pas !!
ps: une ancienne discussion, Lisp, pourquoi est-ce différent ?
# Haskell
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Marrant qu'on trouve pas Haskell dans ta liste des "pourquoi pas", alors que c'est quand même un langage fonctionnel majeur. Une raison particulière ?
[^] # Re: Haskell
Posté par dzecniv . Évalué à 3.
Oui, j'ai juste cité d'autres lisps pour rester dans le sujet, à l'exception d'Elixir, qui cependant a un système de macros similaire.
# Coquilles
Posté par Pol' uX (site web personnel) . Évalué à 6.
Adhérer à l'April, ça vous tente ?
[^] # Re: Coquilles
Posté par dzecniv . Évalué à 2.
Merci.
Je pense d'abord au système d'objet, qui a des fonctionnalités en plus, par exemple le fait que les méthodes ne soient pas ratachées à des classes, l'existence de hooks, des méthodes génériques (types différents en entrée) https://en.wikipedia.org/wiki/Common_Lisp_Object_System (rah mince, je ne retrouve pas un texte "d'autorité" :D ) Puis l'extension du langage (plus un sentiment de ma part). En python on a des décorateurs, des
withstatements: ces constructions permettent d'encapsuler du code par d'autre code. Pour ce faire il faut utiliser des constructions spéciales, différentes. Or en lisp, les macros permettent d'enrober du code avec d'autre code, au moment de la compilation, programmatiquement, en connaissant la structure de ce qu'on manipule (python AST), en évaluant ou pas le code qu'on insère (ce genre de choses qu'on ne peut pas faire en python), etc. Donc je me dis: ce système de macros, général, est un sur-ensemble des décorateurs et autres.[^] # Re: Coquilles
Posté par Pol' uX (site web personnel) . Évalué à 5.
Oui c'est l'homoiconicité. Perso je trouve ça génial.
Beh non c'est assez différent, en fait. Il ne me semble pas pertinent de vouloir les imbriquer :
Un décorateur python, c'est une fonction qui prend une fonction en argument. Ce n'est pas de l'enrobage « syntaxique » de code. Et tu peux facilement imiter la même chose en lisp (enfin je suppose, perso je connais bien scheme mais pas lisp) ou dans la plupart des langages qui se revendiquent un tout petit peu fonctionnels.
Une macro, en scheme (mais je suppose que c'est la même chose pour lisp), c'est juste un genre de eval un peu spécial. Et tu pourrais (péniblement) le faire en python à coup de tableaux de strings concaténés.
Là où scheme (lisp) est très très fort (et de ce point de vue supérieur à python, si on part du principe que la métaprogrammation est quelque chose de désirable dans un programme), c'est qu'il est homoiconique. Donc au lieux de te faire chier comme en python avec de strings, ou comme en C avec un préprocesseur idiot et pénible, tu peux prendre n'importe quelle donnée et la réïfier comme un morceau de code. Et tu peux prendre n'importe quel code et le réifier comme de la donnée définie dans les types de base du langage. A volonté. Je n'ai jamais essayé de faire ça en python, mais j'imagine que ça doit être assez ardu car sa grammaire me semble très complexe en comparaison de scheme (lisp).
Bref, pour moi, en présentant les macros comme un « sur ensemble » des décorateurs, tu confonds un enrobage que je qualifierais de « syntaxique » avec un enrobage que je qualifierais de « fonctionnel ».
Adhérer à l'April, ça vous tente ?
[^] # Re: Coquilles
Posté par anaseto (site web personnel) . Évalué à 2.
En fait, les décorateurs ne sont pas un sous-ensemble des macros, mais il faut des macros pour ajouter une syntaxe ad hoc à la python pour ce motif fonctionnel :)
# Ah non !
Posté par foobarbazz . Évalué à 6.
Disclamer : J'adore la programmation fonctionnelle, je pense que les lisp-1 sont langages absolument magnifique, du lambda calcul avec pile ce qui faut pour en faire un langage moderne. C'est magnifique.
Mais les lisp-2 (deux espaces de nom, un pour les valeurs, un pour les fonctions, on s'éloigne du lambda calcul) ? Et particulièrement Common Lisp ? :-s
Pour la petite histoire… Common lisp est né à une époque ou chacun faisait son lisp dans son coin, avec son propre ecosystème. C'était coûteux, et ces gens là ont dit « on arrête les conneries, on va se regrouper pour faire un truc beau qu'on utilisera tous ». Et au lieu de prendre l'intersection de ce que chacun utilisait… Ils ont pris l'union…
Du coup, ça fait une espèce de gloubiboulga monstrueux.
Je pense que CL est LA raison pour laquelle les lisp ont mauvaise réputation.
https://www.google.fr/#q=common+lisp+sucks
[^] # Re: Ah non !
Posté par dzecniv . Évalué à 2.
Pas trouvé d'arguments imparables à priori… plein de critiques sont sur le langage, or celui-ci est réparable, il me semble (voir cl21 et d'autres librairies qui donnent des structures de données plus modernes, etc).
Du coup tu aimes quel lisp/scheme ? Lequel a un écosystème satisfaisant pour du travail moderne (serveur web, etc) ?
[^] # Re: Ah non !
Posté par anaseto (site web personnel) . Évalué à 8. Dernière modification le 01 février 2017 à 15:21.
J'en doute un peu. Si je devais parier où se trouve le plus gros obstacle, je pense que c'est surtout une question de culture autour du langage, un peu trop concentrée sur l'expressivité théorique du langage, et beaucoup moins sur d'autres aspects plus pragmatiques. Oui, le langage de base est documenté dans plusieurs livres ici et là (qui malheureusement commencent souvent par toute une tartine légèrement philosophique/abstraite expliquant que ça fait des dizaines d'années que tout le monde réinvente Lisp en moins bien), mais pour ce qui est des librairies, quand j'avais regardé il y a quelques temps, ça m'avait semblé assez chaotique : chacun y va de sa façon de documenter (ou ne pas documenter), avec son propre dialecte du langage construit à l'aide de macros avec un style personnel (oui, ça fait des super dsls très concis, mais c'est aussi une barrière : en tombant sur du code écrit par d'autres au hasard, on comprend pas grand chose sans avoir assimilé le vocabulaire et les abstractions d'abord). Les packages recommandés par la communauté sont souvent en beta ou des choses comme ça depuis X années (à commencer par quicklisp). Le déploiement est pas super facile non plus (faire une image exécutable avec sbcl produit un binaire énorme). Au final, ça me semblait assez déconcertant. D'ailleurs, à tout ça il faudrait rajouter, qu'en gros, c'est très biaisé vers emacs (sinon on a un peu l'impression d'être citoyen de deuxième classe) ; perso, ça ne m'a pas dérangé d'utiliser emacs (ou plutôt spacemacs) quand j'apprenais le Lisp, mais c'est une barrière de plus.
Je dirais que c'est un langage qui peut tout à fait convenir pour un projet par un petit groupe de personnes aguerri, et suffisamment gros pour justifier de réécrire quelques librairies à sa façon et rendre rentable l'utilisation de macros. Et ça vaut aussi pour les dialectes de scheme : malgré leur côté plus puritain, et souvent une documentation plus homogène, ils ne font pas beaucoup mieux en termes de popularité, et c'est pas juste une question de parenthèses.
Ceci dit, c'est des langages que je trouve personnellement bien amusants (par exemple, le package
iterpour faire tout type de boucles, m'avait bien impressionné).[^] # Re: Ah non !
Posté par ylsul . Évalué à 1.
Pas tout à fait faux pour les bibliothèques plus ou moins finies, mais on trouve quand même pas mal de choses. Et Quicklisp (pour la gestion de bibliothèques) est peut-être considéré comme en beta mais ça marche bien et c'est un outil très pratique.
SBCL génère des exécutables assez gros, c'est vrai (45Mo environ), d'autres compilateurs moins. Si générer un exécutable est très important (le code source est un autre moyen portable de distribuer un programme, comme en python par exemple), note quand même qu'une fois compressé cet exécutable ne fait "plus que" 5-6Mo. Pour un petit utilitaire c'est un peu lourd, pour un programme plus important c'est moins gênant. SBCL permet aussi de générer un exécutable auto-extractible mais la compression est moins bonne (et ralentit un peu le démarrage) ; peut-être utile à l'occasion.
Pour ce qui est de la lecture des bibliothèques je ne fais pas souvent mais celles que j'ai lues utilisaient du code assez basique, je n'avais pas trouvé ça trop difficile. Après certaines ont tendance à proposer une nouvelle syntaxe (cl21, citée par l'auteur), je ne suis pas forcément convaincu que se jeter dessus soit forcément bien, effectivement : à moins d'être dans un groupe qui utilise les mêmes (ou d'être tout seul dans le groupe), mieux vaut une syntaxe plus commune à mon avis (dans le cas contraire on tombe sur ta remarque sur le fait que le langage puisse être pas mal transformé, parfois pour des gains mineurs et que ça gêne l'entrée de nouveaux développeurs ; à l'échelle d'un gros projet c'est une possibilité parfois très intéressant quand même).
[^] # Re: Ah non !
Posté par ylsul . Évalué à 3.
Pour les lisp-1 / lisp-2 (en clair : espace de nom unique ou deux espaces de noms distincts pour les fonctions et les variables) : les lisp-1 permettent d'écrire des choses parfois plus simples/élégantes mais je trouve l'avantage marginal (note que je n'ai pas essayé en vrai). C'est vrai que (funcall f-truc …) à l'occasion c'est moins bien que (f-truc …) mais ça n'arrive pas si souvent et ça ne change pas fondamentalement les capacités d'expression du langage. D'un autre côté j'aime bien définir des variables portant parfois le même nom qu'une fonction, et devoir changer les noms pour que ma variable ne masque pas ma fonction ça m'ennuie un peu :
Après Common Lisp est un langage multi-paradigme alors que scheme est plus centré sur la programmation fonctionnelle. Donc si tu pars du lambda-calcul et des langages fonctionnel ça peut te parler plus, effectivement ;) . Common Lisp a un passé, mais de là à dire que c'est un "gloubiboulga monstrueux" il y a loin : la base du langage est assez simple à apprendre et l'utiliser dans la vie de tous les jours n'est pas difficile.
Sinon on peut aussi trouver des critiques sur scheme ;) : https://www.google.fr/#q=scheme+sucks
(sans offense pour scheme, juste qu'il est facile de trouver des critiques ; et des éloges…)
# clasp
Posté par Thomas Douillard . Évalué à 3.
J'ai regardé la présentation que tu as lié. J'ai l'impression d'avoir compris tous les bouts, c'est passionnant et tout, mais j'ai pas bien saisi l'ensemble.
J'adore la manière dont le gars se repère dans le labyrinthe de techno informatique (ou pas), prend ce qui l'intéresse, réimplémente les truc qu'il veut maîtriser et l'analyse qu'il a des problèmes. Je suis infoutu (et je me permettrai pas) de critiquer ce qu'il fait à mon niveau, en même temps j'ai l'impression qu'il y a des milliards de trucs à dire. Le type est un génie du touche à tout. Il a aussi une motivation à toute épreuve, des années de travail sur un projet à très long terme …
Bref, j'ai un curieux sentiment mélange de "wtf" et d'admiration sans borne :) Du travail passionnant à plus d'un titre, mélange de physique, d'informatique et de biologie à en inspirer des réflexions métaphysiques.
# Conjonction des temps
Posté par jbbourgoin (site web personnel) . Évalué à 4.
Marrant ce journal LISP au moment même où je suis en train de m'y remettre :) Ça tombe plutôt bien.
Ce serait amusant de refaire une bibliographie LISP à partir de tes liens. J'en avais fait une à une autre époque ( et sous un autre compte parce que l'on change dans la vie ) :
https://linuxfr.org/users/camille_b/journaux/bibliographie-lisp
[^] # Re: Conjonction des temps
Posté par dzecniv . Évalué à 1.
eh bien au plaisir de lire tes avancées dans les journaux !
[^] # Re: Conjonction des temps
Posté par Colin Pitrat (site web personnel) . Évalué à 1.
Pareil pour moi. Je ne retrouve plus ce qui m'a donné envie de m'y remettre par contre. Une nouvelle récente expliquerait cette coïncidence ou est-ce juste une coïncidence ?
[^] # Re: Conjonction des temps
Posté par dzecniv . Évalué à 2.
Marrant :) Non pas de nouvelle spéciale pour moi. Néanmoins depuis que je me suis remis à suivre les nouvelles, j'ai découvert et vu passer de beaux projets (l'effort de traduction CLUS, lisp-lang, Portacle, …). Aussi le fait que sont récemment sortis des versions plus fonctionnelles de python (Mochi, Coconut, Hask,…) mais qui laissent un goût d'insatisfaction, car pas aussi fonctionnelles que les vrais langages fonctionnels.
Mais toi, qu'as-tu essayé de faire et t'en sors-tu ? Je trouve quand même que c'est dur de se retrouver dans la non-documentation et de mettre bout à bout un projet.
# Docs pour commencer
Posté par ylsul . Évalué à 2.
Concernant les bizarreries, on en trouve un peu dans tous les langages. Après certains ont plus vécu que d'autres ;) . Peut-être que des surcouches pour les gommer c'est bien, peut-être que ça passe vite (on s'habitue) et que savoir lire le code "standard" c'est bien aussi. Pourquoi pas, mais je ne suis pas sûr que ça aide un débutant plus qu'autre chose (à voir pour chacun ; j'ai l'impression que certaines syntaxes proposées par cl21 correspondent à des choses qu'on trouve en python par exemple, peut-être que ça simplifie un peu la transition ?). En tout cas pas indispensable pour débuter, pour ceux qui s'inquiètent :) .
Pour essayer, avec un tuto et sans installer des outils/paquetages spécialisé comme Portacle (sur lequel je n'ai pas d'avis, je ne connaissais pas), voilà ce que j'utilise :
C'est assez basique mais c'est facile pour commencer et les paquets (rlwrap, sbcl, kwrite) se trouvent dans les distributions courantes.
Côté documentation (des choses ont déjà été citées, mais une liste que je trouve intéressante pour débuter) :
Pour les projets libres importants en Lisp : ça vient, ça vient ;) .
Merci pour les liens en tout cas, il y a toujours quelque chose d'intéressant… :)
[^] # Re: Docs pour commencer
Posté par dzecniv . Évalué à 2.
je te reprends juste sur ça, car télécharger et ouvrir Portacle est plus simple qu'installer sbcl puis quicklisp puis x et y à la mano !
Et Cliki montre clairement son âge… on doit éditer les pages en html ! Enfin quoi.
# la limite des extensions
Posté par c^3 . Évalué à 3.
Je me demande à quel point c'est juste du marketing, ce genre d'affirmations (venant de la communauté, pas des débutants enthousiastes, bien sûr). En pratique, est-ce qu'on peut vraiment écrire du code statiquement typé (au delà de int/float) et avec du pattern-matching en CL ? Il me semble qu'il faudrait écrire des milliers de lignes d'un compilateur (qui implémente le typechecker et la machinerie du pattern-matching) entièrement en macros, et que ça ne serait pas compatible avec les libs.
The cake is a lie.
[^] # Re: la limite des extensions
Posté par anaseto (site web personnel) . Évalué à 3. Dernière modification le 02 février 2017 à 10:05.
Je ne suis pas un spécialiste, mais j'ai un peu creusé plusieurs dialectes. En CL j'ai jamais regardé pour le typage, mais en racket (dialecte de scheme, macros plus « propres », mais avec plus ou moins d'efforts on peut faire plus ou moins les mêmes choses), il y a : typed racket. C'est assez complet et c'est une sur-couche d'un langage sans types statiques à coup de macros. Après, c'est pas tout rose (inférence de type moins puissance que dans ml, et pas de types aussi évolués). Après, par contre, le pattern-matching en racket n'est pas statique, mais assez évolué quand même (on peut déconstruire des structures, par exemple). Mais oui, a priori on peut faire à peu près n'importe quoi, en pratique il y a quand même un fossé entre théorie et pratique.
Edit : quand je dis pas des types « aussi évolués », c'est assez vague et pas très correct. Ça va quand même plus loin que juste flottant, entier, etc.
[^] # Re: la limite des extensions
Posté par dzecniv . Évalué à 2.
Eh bien les libs sont https://github.com/chriskmanx/abacus avec https://github.com/CodyReichert/awesome-cl#language-extensions
[^] # Re: la limite des extensions
Posté par c^3 . Évalué à 1.
Intéressant cette extension, merci. Malheureusement, si ce n'est pas adapté par tout l'écosystème, c'est beaucoup moins utile :-/
The cake is a lie.
# Macros
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 2.
Avoir des macros hygiéniques par défaut est très sympa. C'est pas vraiment moins puissant, et c'est surtout beaucoup plus sûr car tu ne risques pas de capturer un nom par erreur. Dans les (rares?) cas où tu as besoin de macros non-hygiéniques, le prix à payer est une syntaxe différente. Pas vraiment un problème.
Oui, la communauté Racket est plus petite ; probablement plus académique aussi, mais Racket propose un environment pratique et puissant.
J'ai fait du Scheme et du CL professionnellement, et j'adore les deux. J'ai une préférence pour CL maintenant, mais je n'hésiterai pas à coder en Scheme si j'en avais l'occasion.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.