Le prix (d'un point de vue langage, mettant de côté les conséquences sur la complexité du compilo), c'est que tout se ressemble, le simple et le compliqué sont difficiles à distinguer, la syntaxe n'encourage pas certaines approches par rapport à d'autres, et les idioms ont tendance à être moins prévisibles.
Si on parle de Common Lisp, le langage se présente effectivement comme multi-paradigme, mais c'est moins le cas pour Scheme ou Clojure.
J'aime bien cette approche assez souple mais ce qui me plaît le plus c'est vraiment la capacité à construire des couches de plus haut niveau, à finir par ne plus te demander comment faire entrer ce que tu veux exprimer dans le moule du langage mais à te demander assez librement d'un côté ce que tu veux réaliser et de l'autre comment tu veux l'écrire, Lisp te permettant presque automatiquement de faire le lien entre les deux (il n'y a pas que les macros, c'est un ensemble).
Et effectivement il n'y a pas vraiment d'avantage pour un programme de quelques centaines de lignes : pour un programme relativement modeste tu choisis une approche et tu t'y tiens. J'aime bien Lisp quand même dans ce cas, je trouve les choses assez simples à lire/écrire, mais ce n'est clairement pas là qu'il se distingue. Je ne trouve pas gênant d'utiliser du Lisp pour un petit programme ni de lire un petit programme en Lisp (en général il n'y a pas tellement d'approches mélangées à cette échelle), mais l'avantage réel n'apparaît que pour des programmes plus importants.
Malheureusement je pratique mais ça ne se montre pas encore, pour des raisons diverses. Et décrire comment tous les éléments de Lisp s'emboîtent pour arriver à ce résultat est assez difficile, c'est mieux avec des exemples. Je suppose que cette discussion resurgira d'elle-même quand je présenterai ici une partie de ce que je fais. J'essaierai de donner des exemples plus concrets parce que j'imagine que là ça fait un peu discussion entre gens qui savent déjà de quoi ils parlent et que pour le reste du monde c'est difficile à saisir sans avoir vraiment mis le nez dedans.
Pour juste un petit exemple : écrire un générateur html qui permet de mêler du code Lisp et du code html (comme les jsp de java mais avec tout le langage Lisp sous la main, sans un (en fait deux dans le cas des jsp, sans compter les balises personnalisées) langages supplémentaires à apprendre) ça nécessite même pas 100 lignes de code, avec les échappements html appliqués automatiquement. Et si tu écris des applications web tu sais à quel point la sécurité de la génération des pages est difficile (sinon je te le dis ;) : ajouter du texte dans des pages dont les méta-données sont du texte c'est assez délicat parce qu'il faut faire attention partout et que par définition les humains ne sont pas très doués dans ce domaine). Étendre ce générateur pour qu'il traite tous les cas (échappement des paramètres javascript, échappement correct des url, jetons dans les urls, ...) c'est quelques centaines de lignes de code. Avec une syntaxe finale qui mêle harmonieusement lisp et html (ou ce qui le représente), sans avoir rien d'autre à apprendre, y compris pour créer tes propres composants de présentation (de simples fonctions/macros Lisp). C'est un exemple où il y a peu de choses à apprendre pour savoir comment ça marche, qui libère le développeur de pas mal de problèmes (moins de choses à penser partout) et qui permet à des gens ayant une expérience modérée du développement web d'éviter les conneries. À l'échelle d'un site de 3 pages ce n'est pas intéressant mais si tu réalises des applications plus complexes c'est vite rentabilisé.
Pour l'analyse statique on en reparle dans un peu plus longtemps :) . Mais rien ne s'oppose a priori à réaliser une analyse statique du code : ce n'est pas parce que le langage est dynamique qu'en pratique on redéfinit pendant son exécution les fonctions existantes.
[^] # Re: C'est bien dommage
Posté par ylsul . En réponse au journal C++17 est sur les rails. Évalué à 1.
Si on parle de Common Lisp, le langage se présente effectivement comme multi-paradigme, mais c'est moins le cas pour Scheme ou Clojure.
J'aime bien cette approche assez souple mais ce qui me plaît le plus c'est vraiment la capacité à construire des couches de plus haut niveau, à finir par ne plus te demander comment faire entrer ce que tu veux exprimer dans le moule du langage mais à te demander assez librement d'un côté ce que tu veux réaliser et de l'autre comment tu veux l'écrire, Lisp te permettant presque automatiquement de faire le lien entre les deux (il n'y a pas que les macros, c'est un ensemble).
Et effectivement il n'y a pas vraiment d'avantage pour un programme de quelques centaines de lignes : pour un programme relativement modeste tu choisis une approche et tu t'y tiens. J'aime bien Lisp quand même dans ce cas, je trouve les choses assez simples à lire/écrire, mais ce n'est clairement pas là qu'il se distingue. Je ne trouve pas gênant d'utiliser du Lisp pour un petit programme ni de lire un petit programme en Lisp (en général il n'y a pas tellement d'approches mélangées à cette échelle), mais l'avantage réel n'apparaît que pour des programmes plus importants.
Malheureusement je pratique mais ça ne se montre pas encore, pour des raisons diverses. Et décrire comment tous les éléments de Lisp s'emboîtent pour arriver à ce résultat est assez difficile, c'est mieux avec des exemples. Je suppose que cette discussion resurgira d'elle-même quand je présenterai ici une partie de ce que je fais. J'essaierai de donner des exemples plus concrets parce que j'imagine que là ça fait un peu discussion entre gens qui savent déjà de quoi ils parlent et que pour le reste du monde c'est difficile à saisir sans avoir vraiment mis le nez dedans.
Pour juste un petit exemple : écrire un générateur html qui permet de mêler du code Lisp et du code html (comme les jsp de java mais avec tout le langage Lisp sous la main, sans un (en fait deux dans le cas des jsp, sans compter les balises personnalisées) langages supplémentaires à apprendre) ça nécessite même pas 100 lignes de code, avec les échappements html appliqués automatiquement. Et si tu écris des applications web tu sais à quel point la sécurité de la génération des pages est difficile (sinon je te le dis ;) : ajouter du texte dans des pages dont les méta-données sont du texte c'est assez délicat parce qu'il faut faire attention partout et que par définition les humains ne sont pas très doués dans ce domaine). Étendre ce générateur pour qu'il traite tous les cas (échappement des paramètres javascript, échappement correct des url, jetons dans les urls, ...) c'est quelques centaines de lignes de code. Avec une syntaxe finale qui mêle harmonieusement lisp et html (ou ce qui le représente), sans avoir rien d'autre à apprendre, y compris pour créer tes propres composants de présentation (de simples fonctions/macros Lisp). C'est un exemple où il y a peu de choses à apprendre pour savoir comment ça marche, qui libère le développeur de pas mal de problèmes (moins de choses à penser partout) et qui permet à des gens ayant une expérience modérée du développement web d'éviter les conneries. À l'échelle d'un site de 3 pages ce n'est pas intéressant mais si tu réalises des applications plus complexes c'est vite rentabilisé.
Pour l'analyse statique on en reparle dans un peu plus longtemps :) . Mais rien ne s'oppose a priori à réaliser une analyse statique du code : ce n'est pas parce que le langage est dynamique qu'en pratique on redéfinit pendant son exécution les fonctions existantes.