Je pense que CL est LA raison pour laquelle les lisp ont mauvaise réputation.
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 iter pour faire tout type de boucles, m'avait bien impressionné).
[^] # Re: Ah non !
Posté par anaseto . En réponse au journal Découvrons Common Lisp. Comparaison avec l'environnement Python.. É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é).