Elle fournit un compilateur en code natif, un débogueur et un environnement interactif où les fonctions sont compilées à la volée.
Elle est en partie dans le domaine publique et sous licence BSD.
Après six ans de développement, la version 1.0 est sortie le 30 novembre 2006. Les précédentes versions étaient toutefois déjà très utilisables.
A la base, SBCL est un fork de CMU CL de l'université de Carnegie Mellon qui devait permettre de rendre CMU CL plus portable et maintenable.
SBCL a été porté sur beaucoup d'architectures et sur la plupart des systèmes d'exploitation courants. En particulier, on pourra trouver une version pour presque chaque architecture supportée par Linux.
SBCL peut se compiler lui même ou à partir d'une autre implémentation du Common Lisp. Le Common lisp est un langage qui permet la programmation impérative, fonctionnelle et/ou orientée objet (CLOS). Il offre un typage dynamique avec une déclaration de type optionnelle qui permet d'améliorer les performances et la sûreté du code.
En particulier, le compilateur de SBCL donne des informations très précieuses sur le type des variables grâce à une inférence de type.
La principale puissance du Common Lisp provient de son système de macros qui permet d'étendre le langage comme on le souhaite. En effet, il n'est pas difficile de créer de nouvelles structures de boucles ou une syntaxe complètement différente qui s'adapte à ce que l'on veut faire.
Aller plus loin
- Le site officiel (14 clics)
- Le Common Lisp sur Wikipedia (8 clics)
- Les plateformes supportées par SBCL (2 clics)
- CMU CL (1 clic)
- Le Common Lisp wiki (2 clics)
- Le Common Lisp directory (1 clic)
# pourquoi le lip
Posté par Troy McClure (site web personnel) . Évalué à 5.
Je m'interroge sur l'interet que présente encore le lisp en 2006, alors qu'il existe tellement (trop?) de langages qui ont bénéficié de toute l'expertise acquise depuis l'époques glorieuse du Cobol, du Fortran et du Lisp. Par exemple le lisp presente il un avantage quelconque par rapport à des langages modernes tels Java, Ruby, Ocaml, C++, ou Haskell ? Est-il utf8 aware ? supporte-il nativement le XML et la programmation par contrats ? Y'a-t-il des gens qui utilisent le lisp pour faire des choses sérieuses en entreprise (en faisant abstraction de emacs) ?
[^] # Re: pourquoi le lip
Posté par thecat . Évalué à 6.
Tu te pose la question dans le mauvais sens:
Qu'apporte les langages dit "modernes" par rapport à Lisp ?
[^] # Re: pourquoi le lip
Posté par Gniarf . Évalué à 5.
[^] # Re: pourquoi le lip
Posté par Laurent A. . Évalué à 2.
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 5.
Le C++ et son paradigme objet borderline est devenu un succès énorme rien que parce qu'il ressemblait à un super-set du C.
Faut croire que la syntaxe, c'est important. Parce qu'à part la familiarité avec le développeur, bon nombre de langages employés actuellement auraient dû mourir au profit de précurseurs mieux développés.
[^] # Re: pourquoi le lip
Posté par Farzad FARID (site web personnel) . Évalué à 2.
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 4.
Smalltalk est la preuve qu'il ne suffit pas d'être un langage puissant pour gagner le coeur des développeurs. Il faut avoir un minimum de familiarité avec ce qu'ils utilisent déjà, ce qui n'est pas le cas du Lisp.
Java est un petit peu devenu le smalltalk du commun des mortels. Il n'en a pas toute l'essence, mais il en a assez, et il est assez familier, pour être devenu l'un des langages les plus utilisés en ce monde. Good Enough Prevail.
[^] # Re: pourquoi le lip
Posté par Antoine . Évalué à 6.
Il ne faudrait pas oublier le marketing délirant promu par Sun et relayé par une myriades de magazines idiots ("pour décideurs"), qui nous expliquaient que Java allait tout enterrer, que les OS seraient écrits en Java, etc.
Cela a certainement bien plus favorisé le succès de Java que n'importe quelle qualité objective du langage. Pour le coup, un Lisp-like avec le même marketing se serait sûrement imposé de la même façon.
[^] # Re: pourquoi le lip
Posté par Gniarf . Évalué à 2.
non, il y a de vrais langages sans ça et qui permettent quand même le lambda calcul et autres.
[^] # Re: pourquoi le lip
Posté par iug . Évalué à 0.
[^] # Re: pourquoi le lip
Posté par Nicolas Legrand (site web personnel) . Évalué à 6.
Et pour le reste :
http://norvig.com/java-lisp.html
[^] # Re: pourquoi le lip
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
[^] # Re: pourquoi le lip
Posté par Gniarf . Évalué à 2.
[^] # Re: pourquoi le lip
Posté par golum . Évalué à 8.
Langage Inutilement Surchargé en Parenthèses.
Bon! si on la fermait .... la parenthèse ;-)
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . Évalué à 3.
[^] # Re: pourquoi le lisp
Posté par Obsidian . Évalué à 1.
D'un autre coté, si la plupart des symboles ont quand même du sens (telles les accolades pour définir un bloc d'instructions), il faut bien reconnaître que la plupart des lexiques des langages informatiques (américains pour la plupart) ont été conçus en fonction de ce que le clavier proposait.
[^] # Re: pourquoi le lip
Posté par Alkaan . Évalué à 0.
Reste qu'une fois la logique acquise ça reste un langage puissant, mis à par les (((((((( ))))))) euh encore une ? ) je n'en garde pas un mauvais souvenir
[^] # Re: pourquoi le lip
Posté par Matthieu Lemerre (site web personnel) . Évalué à 10.
SBCL est une implémentation libre du langage ANSI Common Lisp.
Elle fournit un compilateur en code natif, un débogueur et un environnement interactif où les fonctions sont compilées à la volée.
Avec SBCL tu as:
- Un environnement interactif, comme en Ruby, Ocaml ou Haskell
- Un typage dynamique comme en Ruby
- Un compilateur comme en Java, C++, Ocaml ou Haskell
Mais tu remarqueras que c'est le seul de ces langages a tout combiner. Rien que pour cela, tu peux appeller Lisp un langage moderne.
Lisp est un langage toujours d'actualite: beaucoup de fonctionnalites de Lisp ne sont presentes que dans Lisp.
En particulier, l'utilisation des macros qui permet de redefinir des operateurs du langage, et d'implementer vraiment des mini (ou maxi) compilateurs a l'interieur de Lisp. Ce qui en fait un langage beaucoup plus puissant que les langages existants.
Les problemes de Lisp sont:
- La syntaxe rebutante a prime abord (mais a laquelle on s'habitue en 1h)
- La non uniformisation des librairies, et la taille de la librairie de base (tout common lisp) (mais c'est la meme problematique qu'en C++)
Et oui, des gens font des programmes serieux en Common Lisp (par exemple Viaweb, un logiciel ecris par seulement 2 personnes et vendu a yahoo pour je ne sais plus combien de million de dollars)
http://l-lang.org/ - Conception du langage L
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 2.
Après Viaweb, un grand classique c'est Naughty Dog, la seule boite qui ai conçu un jeu moderne avec un peu de lisp dedans, forcément, ce nom est devenu un Culte. Quand quelqu'un demande dans un newsgroup des conseils pour coder un jeu vidéo il y aura toujours un gogo qui va dire que le Lisp est LE langage pour coder des jeux vidéo, qu'il faut absolument utiliser lisp et pas autre chose, que Jak&Daxter a été une réussite grace au Lisp, et vive Naughty Dog.
[^] # Re: pourquoi le lip
Posté par Philippe F (site web personnel) . Évalué à 3.
<< Dans tout programme de plus de 10000 lignes, il y a forcement un compilateur LISP cache quelque part >>
Je me souviens plus du nombre de lignes, mais je tend a etre d'accord. Des que tu fais un gros projet, tu tombes souvent sur des problematiques de calcul intelligent interne ou de notion de logique, qui au final pourraient tres bien se resoudre avec du LISP.
[^] # Re: pourquoi le lip
Posté par Farzad FARID (site web personnel) . Évalué à 5.
Sauf que, peu après, le projet a été réécrit dans un autre langage. Et ça, Paul Graham ne s'en vante pas... Voir par exemple l'article de Joel on Software [1] pour des liens sur cette histoire. Je cite :
Je n'ai rien contre Lisp, qui est un excellent langage en théorie, mais j'aimerais voir des exemples concrets plus récents si tu en as.
Note : je n'ai pas dit non plus qu'il faut absolument faire comme tout le monde du Java (que je n'aime pas, trop lourd, trop de code verbeux et inutile, trop de surcouche) ou du C++. Personnellement je m'oriente vers Ruby, qui hérite un peu de Lisp et de Smalltalk et qui est plus "pragmatique" comme langage.
[1] : http://www.joelonsoftware.com/items/2006/09/01.html
[2] : http://www.paulgraham.com/avg.html
[3] : http://www.reddit.com/
[^] # Re: pourquoi le lip
Posté par reno . Évalué à 4.
> - La syntaxe rebutante a prime abord (mais a laquelle on s'habitue en 1h)
Pas vrai pour la partie "on s'habitue en 1h".
Et c'est vraiment *le* gros problème du Lisp pas un point de détail..
Les programmeurs veulent utiliser des langages avec une syntaxe lisible (Ruby..) facilitant la maintenance, pas un langage avec une syntaxe d'arbre syntaxique, même si cette syntaxe facilite la méta-programmation.
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 3.
- elle est très simple et uniforme, compréhensible en 5 minutes, et du code indenté correctement (l'éditeur s'en charge très bien) est très facilement lisible,
- elle permet l'existence des "macros" (rien à voir avec celles de C), qui sont un moyen puissant pour écrire des abstractions syntaxiques.
La syntaxe de Lisp est déroutante pour un programmeur C / C++ / Java / PHP / etc. car elle est très différente, mais elle reste beaucoup plus simple à comprendre. Demandez donc l'avis d'un programmeur Lisp sur la syntaxe de Ruby, Java, C#, Python, etc...
[^] # Re: pourquoi le lip
Posté par Matthieu Lemerre (site web personnel) . Évalué à 1.
Attention, on peut tout a fait faire un langage qui a des macros "a la lisp" et utilisable avec une syntaxe normale.
<pub inside>Je suis d'ailleurs en train d'en developper un (en gros un langage avec un typage statique fort, des possibilites low-level a la C, une syntaxe extensible, et des possibilites de macros a la lisp)</pub inside>
http://l-lang.org/ - Conception du langage L
[^] # Re: pourquoi le lip
Posté par HappyPeng . Évalué à 2.
[^] # Re: pourquoi le lip
Posté par lasher . Évalué à 1.
[1] Non, les pointeurs de fonction ne sont pas suffisants, car ils ne sont que des adresses sur des fonctions définies statiquement ; rien à voir avec des fonctions générées à la volée.
[^] # Re: pourquoi le lip
Posté par reno . Évalué à 4.
Un super-avantage quand on voit que les programmeurs Lisp representent une fraction ridiculement faible des programmeurs comparés au shell, Perl, Java, C#, Ruby..
> Demandez donc l'avis d'un programmeur Lisp sur la syntaxe de Ruby, Java, C#, Python, etc..
Pas facile: je n'en connais pas!
Il y a probablement bien plus de programmeurs Ruby que de programmeurs Lisp et pourtant Ruby est un langage très récent avec des performances faibles (purement interprété), comment tu explique ça a part la syntaxe?
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . Évalué à 0.
> Pas facile: je n'en connais pas!
De ce que j'ai testé, les parenthèses sont en général plus accessibles que les { } [ ] # @.
Ensuite chaque groupe de parenthèses délimite un bloc qui est très facilement manipulable.
exemple: (ma-fonction (prend "toto") (donne "titi"))
tu peux manipuler et déplacer facilement les blocs que sont les fonctions ma-fonction, prend et donne. Il suffit de prendre les parenthèses.
D'autre part, on indente en général le code. Ce qui fait dire à certain qu'on se retrouve à écrire en python si on enlève les parenthèses.
Donc on fait assez vite abstraction des parenthèses et on se fie à l'indentation. Les parenthèses étant là pour vérifier le groupement s'il y a lieu. D'ailleurs certains éditeurs permettent de mettre les parenthèses dans une couleur très discrète comme le gris clair sur du blanc.
Par contre si on enlève les parenthèses on perd la correspondance code<->donnée et la flexibilité des macros.
Comme exemple, un fichier de configuration en lisp est aussi simple que :
Écriture : (print '(defparameter ma-variable 10) fichier-de-conf)
Le fichier de configuration contient : (defparameter ma-variable 10)
Lecture : (load fichier-de-conf)
Le (defparameter ma-variable 10) est une donnée en écriture mais est un bout de code qui est exécuté en lecture .
(ma-variable prend la valeur 10 quand le fichier de conf est chargé).
Donc j'ai du mal à recoder en C ou dans un autre langage parce qu'il me manque toujours des facilités apportées par la syntaxe du Lisp (et je ne parle que de la syntaxe...).
[^] # Re: pourquoi le lip
Posté par Sytoka Modon (site web personnel) . Évalué à 0.
Par ailleurs, le LISP et ses dériveés proche (type Schme) n'ont pas la cote, notament pour la syntaxe, à la fois géniale et pas toujours humainement lisible, et pourtant, l'un des dérivées du LISP a super la cote sur ce site, ainsi qu'auprès des décideurs, j'ai nommé XML !
Bref, sa propre impression sur un langage me semble tout sauf objectif la plupart du temps.
Personnellement, je code pas mal en BASH et en Perl mais je préfère de loin les blocs de type Pascal, Ada et Fortran :
begin
....
end
C'est quand même se qui se relie le mieux, surtout si on n'est pas l'auteur initial du code.
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . Évalué à 3.
Pour le rapprochement XML/lisp, j'utilise souvent la fonction suivante :
Ce qui permet de faire :
qui produit :
Je m'en suis servi pour générer automatiquement la doc de clfswm à partir des tables de hashage des touches et de la documentation des fonctions ( http://hocwp.free.fr/clfswm/keys.html ). En lisp ce n'est pas la peine d'aller chercher des outils extérieur comme doxygen ou autre. Tout est déjà dans le langage.
Pour le reste, c'est effectivement tout sauf objectif. Chacun ses goûts :)
[^] # Re: pourquoi le lip
Posté par Zakath (site web personnel) . Évalué à 2.
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 5.
Lisp est traditionnellement typé dynamiquement, mais le standard Common Lisp n'impose aucune limitation. Le compilateur est donc libre et peut déterminer les types à la compilation (typage statique).
En l'occurrence, un compilateur moderne comme SBCL utilise du typage statique (déclarations optionnelles, inférence de type), et il est capable de détecter un grand nombre d'erreurs de type, et d'optimisations de code très poussées (performances équivalentes à celles de gcc).
[^] # Re: pourquoi le lip
Posté par Zakath (site web personnel) . Évalué à 2.
Si tu veux un tableau dans lequel on peut mettre des int ou des string, tu fais :
type Truc = Bli of int | Bla of string
let a = Array.create 2 (Bli 0)
a.(1) <- (Bla "prout")
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 1.
Avec du typage dynamique, on pourrait faire quelque chose comme :
let a = Array.create 2 0
a.(1) <- "prout"
[^] # Re: pourquoi le lip
Posté par TeXitoi (site web personnel) . Évalué à 3.
Et tu te retrouves avec des bugs étranges que tu remarques que lorsque ce bout de code pose problème...
L'interet du typage statique, c'est que ce genre d'erreur (lorsque c'est involontaire), tu peux pas la faire. Ca enleve une grosse partie des bugs possibles.
Perso, je trouve illogique que a.(1) n'aie pas le même type que a.(0).
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 1.
Par exemple, dans le cas ci-dessus, si on est surs que 'a' ne doit contenir que des entiers et des chaines, il est possible de le dire au compilateur, qui pourra s'en servir pour détecter des bugs et optimiser le code.
L'avantage de Lisp est de permettre les deux approches.
D'autre part, un compilateur statique ne permet de détecter qu'un certain nombre de bugs, il serait dangereux de "trop" se reposer dessus...
[^] # Re: pourquoi le lip
Posté par Zakath (site web personnel) . Évalué à 2.
Pour ma part, je pense que le typage statique est bon à prendre et ne présente quasiment pas d'inconvénients par rapport à un typage dynamique, voire à pas de typage, s'il est bien intégré au langage.
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 4.
Je trouve OCaml très sympa, avec un typage statique rigoureux mais relativement léger à utiliser comparé à Java, C++, etc.
Je préfère quand même Common Lisp, que je trouve plus flexible (typage statique _et_ dynamique), et qui supporte des concepts de plus haut niveau.
Le typage dynamique est spécialement appréciable pendant la phase où on ne sait pas encore exactement de quoi seront constitués les objets du programme. Dans cette phase, même avec un système de types aussi puissant que celui d'OCaml, chaque changement d'un type entraine une modification du code en plusieurs endroits. Et il se trouve que dans la majorité des projets, cette phase dure pratiquement pendant tout le développement...
Cela dit, la présence de typage statique dans Lisp est tout aussi bénéfique, car elle permet de détecter un grand nombre d'erreurs de type (et aussi d'optimiser le code généré).
Un langage supportant les deux systèmes me semble donc l'idéal...
[^] # Re: pourquoi le lip
Posté par lasher . Évalué à 3.
[^] # Re: pourquoi le lisp
Posté par Zakath (site web personnel) . Évalué à 4.
Quant au fait que ce soit plus lourd à utiliser, je ne suis pas d'accord, ça rajoute quelques lignes et ça fait gagner en clarté. Avec du typage dynamique, si tu te balades avec un tableau dans lequel tu n'as que des int, et que subitement tu lui mets une string à l'intérieur, ça n'est vraiment pas clair et il faudra souvent se fendre d'un commentaire. Avec du typage statique, tu préviens dès le départ, tu poses tes règles et tu t'y tiens.
Enfin, si tu mets plusieurs types différents dans un tableau, il va vraisemblablement falloir discriminer sur leur type quand tu voudras agir sur ces éléments. Avec les constructeurs de type, la solution est particulièrement élégante :
match a.(i) with
| Bla j -> print_int j
| Bli s -> print_string s
[^] # Re: pourquoi le lisp
Posté par mvilleneuve . Évalué à 1.
Mais admettons que comme dans tout projet, on se rende compte que le type Truc doive pouvoir contenir, dans un petit nombre de cas, un autre type de données. Il faut donc modifier la définition de Truc, et _tous_ les morceaux de code qui l'utilisent (comme le pattern matching ci-dessus). Même si on sait pertinemment que le nouveau type n'intervient que dans 1% de ces morceaux de code...
[^] # Re: pourquoi le lisp
Posté par golum . Évalué à 2.
[^] # Re: pourquoi le lisp
Posté par Antoine . Évalué à 4.
[^] # Re: pourquoi le lisp
Posté par Zakath (site web personnel) . Évalué à 2.
| _ -> raise unmatched_entry
ce qui permet de ne pas avoir à modifier les cas où l'on sait, par un argument X ou Y, qu'on ne donnera jamais à manger le mauvais type. Ou si on est sale, on ne rajoute pas ce cas et on laisse le compilateur râler en disant que des cas ne sont pas gérés.
Dans tous les cas, ce n'est pas plus lourd qu'avec du typage dynamique.
[^] # Re: pourquoi le lisp
Posté par Antoine . Évalué à 3.
| _ -> raise unmatched_entry
Ce qui revient à écrire à la main ce que fait un système de typage dynamique, à savoir : lever une exception à l'exécution si le type ne correspond pas aux opérations demandées.
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 4.
En fait, c'est vrai et c'est faux à la fois. C'est comme quand on dit que le C++ est aussi rapide que le C. C'est vrai si tu codes le C++ comme tu coderais du C mais ça ne l'est pas si tu codes avec les abstractions fournies.
Les performances de langages fondamentalement différents ne peuvent être comparées honnêtement. C'est possible de faire des comparaisons du type "Python - Ruby", "C - Pascal", mais "C - Lisp" ou "C - C++" non.
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 1.
[^] # Re: pourquoi le lip
Posté par iug . Évalué à 3.
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 1.
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 1.
Si tu utilises la partie "primitive" du lisp, que tu fais du code comme un programmeur C, ça sera aussi rapide que du C.
Si tu utilises toutes les abstractions et la puissance du langage Lisp, non, on ne peut rien comparer.
On ne peut comparer des langages qui ne sont pas utilisés dans un même contexte. Tu peux coder des trucs aussi performants que du C en Lisp mais ce n'est pas le but. Un lisper quand il code en lisp il ne se retient pas d'utiliser les puissants outils de son langage. Le codeur C n'a pas le choix et fait avec les limitations du C.
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 2.
http://bc.tech.coop/blog/040308.html
Le code vainqueur d'un benchmark n'utilise pas le lisp comme un lisper l'utilise.
> So what have we learned? We confirmed what we pretty much knew: you
> can write a C program in CL, at which point the relative speed of your
> C and CL versions will depend on the relative quality of the code
> generation. It's worthwhile to know the specifics of your
> implementation (for instance, it seems that a substantial amount of
> the last-mile speed up for this benchmark on CMUCL came from figuring
> out ftruncate could be fast inside a macro, but not inside an inline
> function).
> What would be even more interesting to me would be an example more
> like what I feel I experience anecdotally --- that I write programs
> that are a bit slower than C (maybe 25% to 50%), but they're much more
> flexible, more abstract, cleaner, easily modifiable, and so on. I
> don't really feel like the CL version of almabench we currently have
> shows any of the benefits of CL.
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 2.
L'exemple traditionnel est la bibliothèque CL-PPCRE (moteur de regexps compatibles avec le format Perl), qui est programmée de façon très idiomatique et claire, et dont les performances (avec un compilateur comme SBCL ou CMUCL) n'ont rien à envier à des implémentations optimisées en C.
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 2.
http://bc.tech.coop/blog/040308.html
C'est les lispers eux même qui le disent. Et ils utilisent une version de SBCL de 2004, pas si vieille.
Pour faire du code aussi rapide que du C, il faut optimiser comme un codeur C le ferait, dans la majorité des cas. Ce n'est pas *toujours* le cas mais c'est une généralité bien réelle.
Bref, on ne peut pas comparer les langages directement quand ils ne sont pas du même niveau. Le C ne se compare pas au Lisp. Tu peux comparer le Pascal au C, ça va pas plus loin.
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 1.
Le fait que certaines personnes, en utilisant certains compilateurs à une certaine époque, voient une différence de performance, n'est en aucun cas une preuve du contraire, simplement un signe de manque de performance du compilateur utilisé ou de leur programme.
Je ne prétends pas qu'un programme Lisp typique d'étudiant, qui ne connait qu'une petite partie du langage, souvent mal enseigné par ailleurs, sera systématiquement compilé vers du code optimal, mais que le fait d'utiliser Lisp (et de "bien" programmer en Lisp) n'induit pas à lui seul une baisse de performance.
Note: SBCL a pas mal évolué en 2-3 ans, y compris au niveau des optimisations.
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 2.
Mais on s'en fout ça que sur le papier le langage lui même ne l'interdise pas. On parle de la pratique. C'est comme dire que Ruby n'interdit pas non plus la performance. C'est la vérité, mais la vérité c'est aussi que Ruby n'a pas d'implémentation performante.
Avec de la théorie on pourrait refaire le monde.
[^] # Re: pourquoi le lip
Posté par iug . Évalué à 2.
Du coup tu as un algorithme très simple pour contrer ce que tu dis :
tu prend le programme optimal dont tu parles, écrit en LISP, et tu joue les algorithmes de compilation utilisés dans SBCL en écrivant du C dont tu sais qu'il va produire le code natif générer par SBCL, en utilisant au passage des optimisations qui ne peuvent s'appliquer que dans le cas de l'algorithme à implémenter, s'il y en a.
Tu obtiens alors, soit un programme équivalent si tu n'as trouvé aucune optimisation supplémentaire, soit un programme plus rapide. La vitesse est donc supérieure ou égale.
Autre argument, le LISP est une bonne abstraction de la LISP machine, pas d'un processeur impératif, non fonctionnel. Avec un processeur classique, un appel de fonction coute très cher.
Etant développeur C avec un minimum d'expérience, je peux te garantir qu'un développeur C aguéri raisonne vraiement comme cela, quand il n'a pas d'autre choix que d'utiliser C.
Evidemment, cela pose le problème qu'une même personne doit maîtriser tous les tenants et aboutissants du compilateur LISP. L'intérêt d'utiliser directement LISP, c'est de gagner du temps à ne pas réinventer la roue à chaque fois (ou beaucoup moins) et d'avoir un code plus lisible à la fin.
Le combat du "je suis plus rapide" ne s'applique pas aux langages de haut niveau : leur intérêt réside dans le gain de temps, de maintenance, ....
Un programme bien conçu qui ferait 100000 lignes de Lisp ou de Prolog ou de Caml ou autre n'est en fait pas possible à écrire en C. Il faudrait des dizaines de millions de lignes de code, le code ne serait pas maintenable,...
[^] # Re: pourquoi le lip
Posté par taratatatata . Évalué à 2.
Le combat du "je suis plus rapide" ne s'applique pas aux langages de haut niveau : leur intérêt réside dans le gain de temps, de maintenance, ....
Un programme bien conçu qui ferait 100000 lignes de Lisp ou de Prolog ou de Caml ou autre n'est en fait pas possible à écrire en C. Il faudrait des dizaines de millions de lignes de code, le code ne serait pas maintenable,...
Tu as lu le contraire où dans mes reply ? je dis juste que ces langages ne sont pas comparables sur un même terrain.
Le pire c'est que l'un des textes que j'ai cité dit exactement la même chose que ce que tu dis. Je le re-cite, parce que ça a l'air de passer mal dans les oreilles.
> So what have we learned? We confirmed what we pretty much knew: you
> can write a C program in CL, at which point the relative speed of your
> C and CL versions will depend on the relative quality of the code
> generation. It's worthwhile to know the specifics of your
> implementation (for instance, it seems that a substantial amount of
> the last-mile speed up for this benchmark on CMUCL came from figuring
> out ftruncate could be fast inside a macro, but not inside an inline
> function).
> What would be even more interesting to me would be an example more
> like what I feel I experience anecdotally --- that I write programs
> that are a bit slower than C (maybe 25% to 50%), but they're much more
> flexible, more abstract, cleaner, easily modifiable, and so on. I
> don't really feel like the CL version of almabench we currently have
> shows any of the benefits of CL.
[^] # Re: pourquoi le lip
Posté par iug . Évalué à 1.
[^] # Re: pourquoi le lip
Posté par Thomas . Évalué à 1.
Par contre en Lisp, on utilise d'habitude l'approche suivante:
- on code une version naïve (plus ou moins rapide selon le compilateur) avec des fonctionnalités de haut niveau.
- on teste la perf. Généralement c'est acceptable donc on s'arrête là et on gagne 90% de temps sur le même projet en C.
- si les perfs sont insuffisantes on commence par saupoudrer le code de déclarations de types, et on laisse le compilo faire notre boulot à notre place.
- On peut ensuite demander au compilo de ne pas faire certaines vérifications de sécurité sur les types (avec (safety 0)).
- Si ça ne suffit pas on réécrit les routines critiques dans un style proche du C.
- Dans le pire des cas, on écrit les routines critiques en C et on les appelle de Lisp.
Le dernier point est celui qui a été utilisé par ITA software (pour mapper quelques gigas de données sans le charger dans Lisp directement).
Donc pour résumer, du lisp idiomatique est plus lent que du C idiomatique, mais plus succint et de plus haut niveau. En cas de lenteur on peut passer en "mode C" (bas niveau) directement en Lisp.
Sinon le temps d'implémenter une solution en C, on a le temps d'en implémenter et tester plusieurs en CL pour choisir un meilleur algo.
[^] # Re: pourquoi le lip
Posté par Xavier Maillard . Évalué à 1.
On voit bien que tu ne connais pas le monde du Common Lisp. 2004 c'est la prehistoire bonhomme. Il faut voir a quel rythme sorte les nouvelles versions de SBCL et tu comprendras mieux (et surtout lire les changelog)...
[^] # Re: pourquoi le lisp
Posté par Thomas . Évalué à 8.
Il y explique que peu à peu les langages courants intègrent des capacités de Lisp, qu'il était le seul à avoir auparavant. Ca a commencé par les conditionnelles, et ca a fini par le GC. On attends encore de voir un système de macros équivalent en termes de puissance et d'expressivité à celui de Lisp.
Quand tu demandes "supporte-il nativement le XML et la programmation par contrats" je serais tenté de te répondre que tu peux l'implémenter dans Lisp toi-même. C'est là toute la difficulté d'apprendre Lisp d'ailleurs. On n'utilise pas Lisp pour résoudre un problème comme on le ferait avec un langage classique, mais on modifie Lisp pour créer un langage adapté à son problème.
C'est d'ailleurs cet aspect qui rend Lisp déconcertant au premier abord.
Sinon la news concerne SBCL, qui est un compilateur Common Lisp. En Common Lisp tu as le compilateur disponible au runtime, ce qui permet de faire des trucs sympas. Je crois me souvenir que cl-ppcre (une bibliothèque qui implémente les regex en lisp) utilise cela pour compiler (vraiment) les regex. Jette un oeil là: http://weitz.de/cl-ppcre/
"Y'a-t-il des gens qui utilisent le lisp pour faire des choses sérieuses en entreprise (en faisant abstraction de emacs) ?"
On t'a déjà indiqué Naughty Dog (un doctorant du MIT a réalisé un compilateur en Lisp avec un langage spécifique à la création de jeux en un an, il y a un article à ce sujet quelque part sur Gamasutra il me semble). Tu as aussi ITA Software, qui ont réalisé le moteur de recherche de trajets par avion et de réservations utilisé notamment par Orbitz. Enfin, dans la catégorie des trucs sympas faits en Lisp, tu as par exemple ça: http://franz.com/success/customer_apps/data_mining/pepite.lh(...)
Pour plus d'info tu as les grands classiques: http://www.common-lisp.net
http://cliki.net
http://planet.lisp.org
Pour finir, si tu veux tester quelque chose comme cl-ppcre, sbcl intègre asdf-install de base. Donc (de mémoire), tu peux tester avec:
(require 'asdf-install)
(asdf-install:install :cl-ppcre)
La liste des projets installables par asdf-install est dispo sur common-lisp.net
(Désolé tout ça était un peu brouillon, je me réveille à peine :-) )
[^] # Re: pourquoi le lisp
Posté par golum . Évalué à 6.
Ca signifie qu'à chaque fois que tu passes à un autre projet en lisp, tu dois réapprendre un nouveau langage et passer des heures à comprendre ce qu'a voulu exprimer l'auteur du projet.
En outre, même s'il existe peut-être des librairies réutilsables, le fait que tu te sentes obligé d'adapter en permanence les briques ou de réinventer la roue, ne doit pas contribuer pas à établir des standards que chacun peut intégrer.
Pas moyen de capitaliser en dehors de la structure d'un projet.
Ca doit aussi compliquer la mise en place d'architectures à base de composants.
Tout ca n'est-il pas un peu "contre-productif" ?
C'est peut-être ca la faiblesse du LISP. Combien pèse la souplesse face à la réutilsabilité dans l'industrie logicielle ?
Ce n'est pas une attaque juste une question.
Sinon la news fais allusion à CLOS. SBCL compile-t'il aussi du CLOS ?
[^] # Re: pourquoi le lisp
Posté par mvilleneuve . Évalué à 2.
[^] # Re: pourquoi le lisp
Posté par mvilleneuve . Évalué à 1.
[^] # Re: pourquoi le lisp
Posté par golum . Évalué à 2.
Hem, Hem, ca commence mal.
Les pointeurs de fonctions c'est fait pour les chiens ?
Un poil plus chiadé d'accord mais pas "You just can't write it."
Bon, je ferai l'effort de jeter un coup d'oeil plus tard, il ne faut pas se fier aux impressions.
[^] # Re: pourquoi le lisp
Posté par Thomas . Évalué à 3.
Dans l'exemple en lisp, chaque appel à addn avec en argument x renvoit une nouvelle fonction qui additionne x à son argument.
Je ne vois pas comment faire ça en C (et j'aimerais bien savoir, donc si tu pouvais me montrer un morceau de code ...)
[^] # Re: pourquoi le lisp
Posté par iug . Évalué à 1.
Le faire le plus élégamment possible, je sais pas.
[^] # Re: pourquoi le lisp
Posté par Thomas . Évalué à 0.
L'approche que tu décris porte un nom d'ailleurs:
http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule
[^] # Re: pourquoi le lisp
Posté par golum . Évalué à 1.
Bon je n'ai que de vieux souvenirs du C (ca fait 10 ans que j'ai oublié).
Mais en gros ce que tu cherches a faire c'est une fabrique de fonction.
J'ecrirais donc la fonction en dur,
Et la fonction addn retourne l'adresse de cette fonction
Bref ca ne renvoie pas une "nouvelle" fonction mais ca renvoie un pointeur.
Les pointeurs de fonction sont très utiles lorsque des traitements géneriques doivent s'appliquer en faisant appel
à des contrats.(un polymorphisme sans les objets en quelque sorte)
Dans mon ancienne boîte, j'avais implémenté un algorithme de parcours trajet (sedgewick et vitter, dérivé de dijkstra dans un système à coordonnées cartésiennes). On lui passait des pointeurs sur des fonctions qui définissaient differentes heuristiques (le +court, le + rapide, le - cher, ....)
La vraie question est: Quel est l'intêret d'avoir une fabrique de fonctions "toutes" identiques.
Bon en tout cas, on dévie du sujet initial sur lequel je pointais la faiblesse du lisp. Sa réutilisabilté.
Je regarderai à tête reposée le reste de l'argumentation qui a été donnée.
[^] # Re: pourquoi le lisp
Posté par mvilleneuve . Évalué à 2.
[^] # Re: pourquoi le lisp
Posté par golum . Évalué à 1.
Je comprend mieux l'intêret de la programmation fonctionnelle maintenant.
Notes qu'avec python on dispose aussi de toutes ces possibilités et que la syntaxe est moins rebutante que le lisp.
Je garde un mauvais souvenir de mes cours de lisp avec les "cons" &co :D
Par contre, ce genre de constructions ne doit pas pouvoir être compilé.
Le compilateur SBCL est-il donc en fait un peu l'éqivalent d'un runtime java qui travaille sur du bytecode semi-compilé.
[^] # Re: pourquoi le lisp
Posté par mvilleneuve . Évalué à 2.
[1] http://weitz.de/cl-ppcre/
[^] # Re: pourquoi le lisp
Posté par aurelj . Évalué à 3.
Je ne dis pas que c'est propre et parfait mais c'est en tout cas parfaitement fonctionnel (y compris sur les CPU gérant la protection en execution des pages de données, style NX bit).
C'est certe loin d'être aussi élégant qu'en lisp, mais de toutes facon, un programmeur C n'aurait jamais eut l'idée d'écrire ce genre de fonction. Il aurait pris le problème global d'une tout autre manière. Les langages et la manière de les utiliser ne sont absolument pas comparables.
[^] # Re: pourquoi le lisp
Posté par Antoine . Évalué à 3.
Mort de rire. Pour le coup ça revient à peu près (mais en très limité) à faire ce que disait un autre intervenant, à savoir écrire un morceau de compilateur Lisp en C.
Les langages et la manière de les utiliser ne sont absolument pas comparables.
Bien sûr que si. On peut prendre la résolution d'un problème donné dans divers langages, et voir laquelle est la plus élégante, la plus courte, la plus facile à écrire, la moins susceptible de bugs, la plus performante...
Si les idiomes d'autres langages de C étaient totalement inintéressants dans le cadre du C, pourquoi crois-tu que des gens se seraient amusés à réécrire des systèmes objets en C (cf. gobject) ?
[^] # Re: pourquoi le lisp
Posté par Yann Hodique (site web personnel) . Évalué à 2.
int size = (char *)addn - (char *)add;
(et je ne parle même pas du 0x42424242, trop facile)
Et ce genre de problème ne viendrait peut-être pas à l'esprit d'un programmeur C, mais très certainement à celui d'un programmeur C++ : d'où la surcharge de l'opérateur () et la notion de foncteur (ce qui donne d'ailleurs une piste pour l'écrire en C, mais en perdant l'homogénéité de la forme des appels). Finalement ce n'est peut-être pas si éloigné d'une idée simple, et ne pas y penser relève peut-être de l'acceptation profonde du fait qu'on ne peut pas l'écrire simplement. :-)
[^] # Re: pourquoi le lisp
Posté par Antoine . Évalué à 2.
int size = (char *)addn - (char *)add;
Si si, c'est "fonctionnel".
Par contre le résultat peut être faux si le compilateur décide de ne pas respecter l'ordre dans lequel les fonctions sont définies lorsqu'il émet le code objet (il peut décider de faire cela, par exemple, pour optimiser l'utilisation du cache processeur en tenant compte du flot d'exécution).
Si l'entier "size" en devient négatif, j'imagine que ça peut être amusant.
[^] # Re: pourquoi le lisp
Posté par Yann Hodique (site web personnel) . Évalué à 2.
Que ça compile (avec warnings), je n'en doute pas.
Il me semble en effet que le résultat de ce calcul a de fortes chances d'être aléatoire, suivant le compilateur, le niveau d'optimisations demandé, et l'âge du capitaine.
[^] # Re: pourquoi le lisp
Posté par mvilleneuve . Évalué à 1.
[^] # Re: pourquoi le lisp
Posté par Thomas . Évalué à 2.
J'ai l'impression que tu viens du monde des langages descendants d'algol, genre C/C++/Java/C#. Du coup on ne comprend pas "modifier Lisp pour l'adapter au problème" de la même manière.
En Lisp, si tu ajoute une structure de contrôle ou un opérateur (par macro), ou des fonctions, elles auront le même niveau que le reste du langage. Il n'y a pas de distinction comme en Java où tu as le langage, et les bibliothèques.
Imaginons que tu veuilles rajouter le "while" que l'on retrouve dans tous les langages mainstream . En Lisp tu écriras une macro, qui aura par ex. la forme (while (var test-fin) @body). Quelle différence y aura-t'il entre ta macro et le reste des opérateurs prédéfinis comme dotimes, loop, etc? Aucune.
Par contre, le point positif c'est que la syntaxe reste la même. Du coup te familiariser avec un nouveau langage bâti sur Lisp n'est pas plus difficile qu'apprendre à utiliser une API donnée.
Concernant CLOS, d'autres ont répondu. D'ailleurs je te conseille de jeter un oeil au livre de Peter Seibel (gigamonkeys.com/book/) pour des infos sur CLOS. Ca ne te prendras pas beaucoup de temps et tu pourras voir les possibilités offertes par l'approche objet utilisée.
J'espère avoir levé tes doutes ;-)
[^] # Re: pourquoi le lisp
Posté par Thomas Douillard . Évalué à 4.
obligé de plonger dans le code dudit "while" pour reconnaître sa sémantique. Perte de temps et d'énergie dans ce cas.
[^] # Re: pourquoi le lisp
Posté par hocwp (site web personnel) . Évalué à 1.
[^] # Re: pourquoi le lisp
Posté par Thomas . Évalué à 1.
(documentation 'function 'ma-fonction)
(describe ma-macro)
Et en plus pour les macros comme un "while" que tu aurais codé:
(macroexpand '(while (a (< a 3)) (print 'plop)))
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . Évalué à 6.
Certaines implémentations du Lisp supportent l'utf8 (1). ll supporte le XML (2), la programmation par contrats (3) (je n'est pas testé). Et les expressions régulières. Par exemple les regexps du perl sont compilées en code natif (assembleur) donc elles sont extrêmement rapides.
Pour ce qui est de l'entreprise, je ne suis pas informaticien, donc je ne sais pas...
Par contre j'ai pu faire mon propre gestionnaire de fenêtres (4) en un mois en lisant le code de plusieurs autres projets. L'argument qu'un code en Lisp est illisible est pour moi completement faux.
Ca m'a permis de faire un éditeur de sons (5) exactement comme je le voulais. Un lecteur de mail avec filtre anti spam (6), de la 3D (7), un jeu de tarot distribué (client/serveur) (8)...
Sinon, j'avais déjà parlé de ce sujet auparavent (9).
Et je suis tout à fait satisfait de ce langage pour ce que je veux faire !
(1) http://clisp.cons.org/propaganda.html
(2) http://www.cliki.net/CL-XML
(3) http://www.gauss.muc.de/tools/dbc/dbc-intro.html
(4) http://hocwp.free.fr/clfswm/
(5) http://common-lisp.net/project/cl-wav-synth/
(6) http://hocwp.free.fr/glmf/article_clmail/clmail-v2/
(7) http://hocwp.free.fr/ah2cl/ (à la fin)
(8) http://www.nongnu.org/maitretarot/ (dans le cvs)
(9) https://linuxfr.org/~Montaigne/20315.html#661910
[^] # Re: pourquoi le lip
Posté par left . Évalué à 2.
J'hésite encore entre OCaml et Lisp. Saurais tu me conseiller de saines lectures pour démarrer mon apprentissage du Lisp du bon pied ?
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 1.
[^] # Re: pourquoi le lip
Posté par golum . Évalué à 2.
Si tes critères de recherches sont réellement
typage fort
typage statique
programmation par contrats.
Je ne suis pas certain que Lisp soit le meilleur candidat.
Il y a pléthore d'offre et y compris ... C, C++ ou Java qui sont nettement plus représentée dans les "entreprises"
http://en.wikipedia.org/wiki/Design_by_contract#Languages_im(...)
Maintenant, si tes critères sont d'un autre ordre notamment subjectif, c'est autre chose.
[^] # Re: pourquoi le lip
Posté par left . Évalué à 3.
<ma-vie>
j'aime le concept de Eiffel parce qu'il répond à ces critères, surtout celui de la programmation par contrats (ceux-ci faisant partie intégrante de la signature de la méthode à laquelle ils sont attachés et étant hérités, etc). Il répond à un vrai manque des languages impératifs. Alors j'ai essayé, mais l'instabilité du langage même est découragante (plus d'autres points que je développerai pas ici). Je cherche donc un autre langage pour m'amuser et apprendre. Les entreprises ne recherchent pas ce qu'il y a de mieux, mais ce qui répond à leurs contraintes et leur rapporte le plus. Genre le C, le C++ et le java. Au passage, les contrats et le typage fort avec ces 3 langages, comment dire ... j'en ris encore. Ah si, on me dit dans l'oreillette qu'il y a 'assert' ;)
</ma-vie>
Voila pourquoi OCaml et Lisp me tentent.
[^] # Re: pourquoi le lip
Posté par golum . Évalué à 2.
Certaines de ces implémentations proposent pré/post conditions et les invariants.
Par contre les différences se font plutôt sur l'héritage, ...
J'avais lu un article qui faisait une comparaison détaillée sur feu "développeur reference" et qui permettait de miuex faire le tri.
Il doit être accessible sur archive.org
Si tu veux je peux refaire une recherche et te la pointer.
[^] # Re: pourquoi le lip
Posté par Thomas . Évalué à 1.
Par contre je te recommande vivement de lire et comprendre Practical Common Lisp avant de t'attaquer à On Lisp , car ce dernier devient vraiment poussé après quelques chapitres.
Tu comptes apprendre Lisp sur quelle plateforme? Si tu es sous Linux/BSD, essaie le trio (X)Emacs/SLIME/SBCL. Marco Baringer avait fait une vidéo de présentation de Slime où il détaille ses fonctionnalités; tu la trouveras là: http://common-lisp.net/movies/slime.mov
Tu dis aussi hésiter entre Ocaml et Lisp. Je te dirais d'apprendre les deux. Personnellement j'ai pris la décision d'apprendre Haskell en parallèle de Common Lisp. Haskell/Ocaml et CL sont tous les deux des langages avec une approche plus ou moins fonctionnelle (Ocaml et CL en offre d'autres: objet, impérative), mais les deux premiers sont à typage statique, et le second à typage dynamique. En apprenant CL et Ocaml, tu auras plus de modes de pensée et d'outils à ta disposition.
[^] # Re: pourquoi le lip
Posté par left . Évalué à 2.
Merci pour tes liens et conseils.
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . Évalué à 1.
Le Paradigms of Artificial Intelligence Programming (PAIP) de Peter Norvig qui est tout aussi impressionnant même si on ne veut pas faire de l'IA.
Et un point d'entrée cité habituellement est le très bon livre de Peter Siebel.
http://www.gigamonkeys.com/
http://www.paulgraham.com/acl.html
http://www.paulgraham.com/onlisp.html
http://norvig.com/paip.html
[^] # Re: pourquoi le lip
Posté par Thomas . Évalué à 1.
[^] # Re: pourquoi le lip
Posté par mvilleneuve . Évalué à 2.
[^] # Re: pourquoi le lip
Posté par hocwp (site web personnel) . Évalué à 2.
http://www.ocf.berkeley.edu/~tfb/misc/lp90.pdf
http://common-lisp.net/project/mcclim/
# Clos ?
Posté par bastien (site web personnel) . Évalué à 1.
C'est un language que j'utilise peu, mais qui - je trouve - fourni vraiment de très belle chose pour le paradigme objet, comme un "meta-object protocol" tres clair, les fonctions "before, after, around", les "call-next-method" ou "validate-superclass" et j'en oublie... en plus des qualités que je trouve à LISP.
Savez vous si ce compilateur/interpreteur permet l'utilisation de tous ces outils, je sais que clisp par defaut, meme s'il permet de faire des objets, ne permettait pas toute cette puissance (dumoins de l'experience que j'en ai eu, corrigez si je me trompe). Je connais pas sblc, mais la mention de CLOS dans l'article fait que je vais le tester :) (et découvrir ses qualités, je suppose)
[^] # Re: Clos ?
Posté par hocwp (site web personnel) . Évalué à 2.
Sinon, toutes les implémentation tendent vers un support du CLOS/MOP et à part GCL qui est en retard, toutes les autres le supporte correctement (CMUCL, CLISP, SBCL, ECL, OpenMCL...).
# Elle est en partie dans le domaine publique et sous licence BSD.
Posté par ewasx . Évalué à 3.
[^] # Re: Elle est en partie dans le domaine publique et sous licence BSD.
Posté par hocwp (site web personnel) . Évalué à 2.
# long a apprendre ?
Posté par Mildred (site web personnel) . Évalué à 3.
Alors, je me demande si ce n'est pas un langage un peu complexe et long a apprendre ?
Sinon, vous savez-vous comment faire en sorte que Kwrite/Kate gère la syntaxe lisp ? Je veux dire avec une indentation automatique.
[^] # Re: long a apprendre ?
Posté par hocwp (site web personnel) . Évalué à 2.
Par contre pour être qualifié d'implémentation du Common Lisp, il faut gérer en standard les objets (CLOS), les structures, les conditions (error, assert, throw/catch...), les packages, les nombres, les sequences, les tableaux, les tables de hachage, les nom de fichiers portables sur plusieur systemes, les flux...
Tout ceci est dans le standard et doit fonctionner de la même manière quelque soit l'implémentation. Ce qui fait que la référence est beaucoup plus grosse que celle du scheme. Par contre tu peux ainsi passer d'un systeme et d'une implémentation à une autre et ton programme _doit_ fonctionner de la même manière.
Donc ce n'est pas long à apprendre. Quand tu as besoin de quelque chose, tu vas le chercher d'abord dans la réference avant de le réinventer. Il ne faut pas chercher à tout ingurgiter d'un seul coup.
http://www.lisp.org/HyperSpec/FrontMatter/Chapter-Index.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.