Articles précédents : Logiciel
- [115] Nouvelle version 2.6.19 du noyau Linux
- [14] K3DSurf 0.6.0 : Mise à jour majeure
- [32] Hula devient un projet communautaire
- [90] Projet Ryzom Libre
- [80] aMSN 0.96
- [24] dblatex : Docbook XML -> LaTeX -> PDF
- [36] PeerTV pour Linux
- [24] MakeHuman 0.9 : modeleur de corps humains
- [18] Le Projet Firebird publie Firebird 2.0
- [13] Une nouvelle version des pilotes pour imprimante Samsung
Liens connexes
- Le site officiel (609 hits)
- Le Common Lisp sur Wikipedia (507 hits)
- Les plateformes supportées par SBCL (144 hits)
- CMU CL (77 hits)
- Le Common Lisp wiki (91 hits)
- Le Common Lisp directory (72 hits)
Dépêche modérée par
Dépêche éditée par
Logiciel : Sortie de SBCL 1.0
Posté par hocwp (Jabber id, page perso, ). Modéré le 30 novembre 2006.
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.
![[en]](../../../images/en.png)
Le site officiel (609 hits)![[fr]](../../../images/fr.png)
Le Common Lisp sur Wikipedia (507 hits)-
Les plateformes supportées par SBCL (144 hits)
-
CMU CL (77 hits)
-
Le Common Lisp wiki (91 hits)
-
Le Common Lisp directory (72 hits)
> Lire la suite (100 commentaires, moyenne: 2,5). [dépêche : 946 caractères]
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.
pourquoi le lip
Bonjour,
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 () le 30/11/2006 à 22:31. (lien). Évalué à 6.Par exemple le lisp presente il un avantage quelconque par rapport à des langages modernes ... ?
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 () le 30/11/2006 à 22:53. (lien). Évalué à 5.on échappe à 90% des parenthèses à la con ?
--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: pourquoi le lip
Posté par Laurent A. () le 01/12/2006 à 02:31. (lien). Évalué à 2.Et on a une syntaxe peu homogène avec des caractères choisis un peu au pif par les auteurs du langage et qui changent de signification selon le contexte ?
-
[^]Re: pourquoi le lip
Posté par taratatatata () le 01/12/2006 à 03:25. (lien). Évalué à 5.La familiarité avec le développeur prime au point qu'IBM a arrêté de pousser Smalltalk et sa syntaxe bizarre au profit de Java, et ce, malgré le fait que Smalltalk en tant que langage était bien plus évolué. Smalltalk n'aura pas réussi à bénéficier du dixième du succès qu'a eu Java. On retrouve Java partout, jusqu'à nos téléphones portables.
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 (page perso, ) le 01/12/2006 à 08:28. (lien). Évalué à 2.Le fait que Smalltalk, que je connais peu mais que je trouve très élégant et puissant, tourne dans une machine virtuelle, et qu'il soit difficile de le fait communiquer avec le "monde réel" n'a pas aidé à populariser le langage.
-
[^]Re: pourquoi le lip
Posté par taratatatata () le 01/12/2006 à 13:55. (lien). Évalué à 4.Tu as lu mon message ? Java tourne aussi sous une machine virtuelle, et a eu un succès, comment dire, qui dépasse les limites de l'imagination. On fait tourner ces machines virtuelles sur presque tous les téléphones portables modernes.
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 () le 02/12/2006 à 12:59. (lien). Évalué à 6.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.
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 () le 01/12/2006 à 06:28. (lien). Évalué à 2.Et on a une syntaxe peu homogène avec des caractères choisis un peu au pif par les auteurs du langage et qui changent de signification selon le contexte ?
non, il y a de vrais langages sans ça et qui permettent quand même le lambda calcul et autres.--
"Je n'aime pas votre regard, baissez les yeux!" - Patrick Devedjian, 2008-
[^]Re: pourquoi le lip
-
-
-
[^]Re: pourquoi le lip
Posté par Nicolas Legrand () le 01/12/2006 à 09:34. (lien). Évalué à 6.Les parenthèse ça impressionne au début, mais en fait, c'est sans doute une des syntaxes les plus clean que j'ai pu rencontrer.
Et pour le reste :
http://norvig.com/java-lisp.html-
[^]Re: pourquoi le lip
Posté par Pierre Jarillon (page perso, ) le 01/12/2006 à 11:19. (lien). Évalué à 4.Pour ceux qui n'auraient pas compris cette histoire de parenthèses : LISP="lots of Insidious Silly Parenthesis". La syntaxe de LISP fait effectivement appel à beaucoup de parenthèses et cette interprétation est devenue plus connue que l'origine du nom qui provient de list processing.
-
-
[^]Re: pourquoi le lip
Posté par hocwp (Jabber id, page perso, ) le 01/12/2006 à 11:55. (lien). Évalué à 3.Moui, enfin entre se tordre les doigts pour faire des { } [ ] # , ; et manipuler des parenthèses (que tout bon éditeur indente et repère très bien) et ainsi manipuler des blocs de code extrêmement facilement, il y a un choix à faire :-)
-
[^]Re: pourquoi le lisp
Posté par Obsidian () le 04/12/2006 à 10:31. (lien). Évalué à 1.Oui, enfin, on se tord surtout les doigts sur des claviers AZERTY.
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 ikonea () le 02/12/2006 à 10:05. (lien). Évalué à 0.L.I.S.P. = Langage Inutilisable Sans Parenthèse --> c'est ce qu'il me reste de mes cours de Fac...
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 toto29 () le 30/11/2006 à 23:29. (lien). Évalué à 10.Regarde:
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)-
[^]Re: pourquoi le lip
Posté par taratatatata () le 30/11/2006 à 23:52. (lien). Évalué à 2.Ce qui est top avec les lispers c'est que dans 20 ans on aura encore les mêmes exemples de grandes réussites, les mêmes gourous (Paul Graham, Philip Greenspun)..
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 Fremy (page perso, ) le 01/12/2006 à 15:42. (lien). Évalué à 3.Un gourou lisp a dit :
<< 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 (page perso, ) le 01/12/2006 à 08:46. (lien). Évalué à 5.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)
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 :
Oh and I know Paul told you [2] that he made his app in Lisp and then he made millions of dollars because he made his app in Lisp, but honestly only two people [3] ever believed him and, a complete rewrite later, they won't make that mistake again.
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 () le 01/12/2006 à 09:06. (lien). Évalué à 4.> Les problemes de Lisp sont:
> - 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 () le 01/12/2006 à 13:21. (lien). Évalué à 3.Au contraire, la syntaxe de Lisp est l'un de ses plus grands avantages :
- 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 toto29 () le 01/12/2006 à 20:07. (lien). Évalué à 1.
- elle permet l'existence des "macros" (rien à voir avec celles de C), qui sont un moyen puissant pour écrire des abstractions syntaxiques.
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>-
[^]Re: pourquoi le lip
-
[^]Re: pourquoi le lip
Posté par lasher () le 04/12/2006 à 19:40. (lien). Évalué à 1.Euh. Je peux me tromper, mais à ma connaissance, le langage C ne permet pas l'ordre supérieur (des fonctions qui renvoient d'autres fonctions comme valeurs [1]), donc son expressivité « directe » est moindre que celle des langages fonctionnels (LISP, OCaml, Haskell), et ce indépendamment des performances affichées par l'une ou l'autre des implémentations de ces langages.
[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 () le 02/12/2006 à 18:20. (lien). Évalué à 4.>Au contraire, la syntaxe de Lisp est l'un de ses plus grands avantages
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 (Jabber id, page perso, ) le 03/12/2006 à 13:48. (lien). Évalué à 0.> > Demandez donc l'avis d'un programmeur Lisp sur la syntaxe de Ruby, Java, C#, Python, etc..
> 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 (page perso, ) le 03/12/2006 à 16:10. (lien). Évalué à 0.Ce qui est amusant avec ton post, c'est que j'en conclu que le LISP est finalement asse proche de Python au niveau formatage, or sur ce forum, Python est très apprécié, bien plus que le LISP me semble-t-il.
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 (Jabber id, page perso, ) le 03/12/2006 à 19:05. (lien). Évalué à 3.Bien par exemple sur les deux exemples suivants il n'y a pas beaucoup de différences entre la version lisp et la version python
def test (x): (defun test (x)
y = "toto" (let ((y "toto"))
print x (print x)
print y (print y)))
test (10) (test 10)
Pour le rapprochement XML/lisp, j'utilise souvent la fonction suivante :
(defun produce-html (tree &optional (level 0) (stream *standard-output*))
(cond ((listp tree)
(print-space level stream)
(format stream "~(<~A>~)~%" (first tree))
(dolist (subtree (rest tree))
(produce-html subtree (+ 2 level) stream))
(print-space level stream)
(format stream "~(</~A>~)~%"
(if (stringp (first tree))
(subseq (first tree) 0 (position #\Space (first tree)))
(first tree))))
(t
(print-space level stream)
(format stream (if (stringp tree) "~A~%" "~(~A~)~%") tree))))
Ce qui permet de faire :
(produce-html
'(html
(head
(title "Un titre"))
(body (h1 "Le titre")
(p "plop plop" "Bla bla"
("a href=\"http://toto.org\"" "mon url")))))
qui produit :
<html>
<head>
<title>
Un titre
</title>
</head>
<body>
<h1>
Le titre
</h1>
<p>
plop plop
Bla bla
<a href="http://toto.org">
mon url
</a>
</p>
</body>
</html>
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 (page perso, ) le 01/12/2006 à 09:42. (lien). Évalué à 2.Euh... Le typage dynamique saibien, mais le typage statique saimieux (on choppe les erreurs plus tôt, un programme qui compile a de sérieuses chances de bien marcher, etc...). Donc avec cet argument, OCaml est meilleur que Lisp, puisqu'ayant un toplevel, un compilo et un typage statique.
-
[^]Re: pourquoi le lip
Posté par mvilleneuve () le 01/12/2006 à 11:17. (lien). Évalué à 5.Les deux systèmes ont des avantages : flexibilité pour le typage dynamique, détection des erreurs et optimisation pour le typage statique.
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 (page perso, ) le 01/12/2006 à 12:11. (lien). Évalué à 2.Flexibilité ? Je ne vois pas en quoi le typage dynamique serait plus flexible, à partir du moment où tu as des constructeurs de type suffisamment puissants dans ton langage statiquement typé (et c'est le cas de OCaml).
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 () le 01/12/2006 à 13:08. (lien). Évalué à 1.Dans cet exemple, 'a' n'est pas un tableau pouvant contenir des int et des string, c'est un tableau d'éléments de type Truc, lesquels peuvent référencer soit un int soit un string, ce n'est pas la même chose (et c'est plus lourd a utiliser).
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 (Jabber id, page perso, ) le 01/12/2006 à 13:53. (lien). Évalué à 3.haaa, bearkk!!!
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 () le 01/12/2006 à 14:18. (lien). Évalué à 1.Comme dit autre part, rien n'empèche le compilateur de faire du typage statique (SBCL le fait, par exemple), et rien n'empeche le développeur d'ajouter des annotations de types.
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 (page perso, ) le 01/12/2006 à 14:41. (lien). Évalué à 2.Oui bien sûr, mais ce genre d'argument est toujours spécieux, on ne va pas reprocher à une solution d'augmenter la sécurité d'un système sous prétexte que ça met trop en confiance (cf les débats sur l'ABS dans les voitures).
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 () le 01/12/2006 à 16:30. (lien). Évalué à 4.C'est le débat classique, typage statique vs. dynamique...
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 () le 02/12/2006 à 10:59. (lien). Évalué à 3.Bon, dans le bouquin sur OCaml, y'a un exemple pour additionner deux objets de type « Number » (int et float). Sauf que pour que OCaml infère correctement les types, il faut que tu prennes en compte toute les intéractions possibles entre les types. Si une fonction doit prendre en compte un grand nombre de types, ça commence à être folklorique...
-
-
-
-
[^]Re: pourquoi le lisp
Posté par Zakath (page perso, ) le 01/12/2006 à 14:30. (lien). Évalué à 4.Oui, exactement. Tout l'intérêt de construire ton type manuellement est de justement bien délimiter ce qu'on a le droit de faire (mettre des Bla int et des Bli string dans un tableau) et de le dire au compilateur, qui pourra ainsi te prévenir si quelque chose ne va pas.
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 () le 01/12/2006 à 16:34. (lien). Évalué à 1.Tout à fait, c'est élégant.
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 () le 01/12/2006 à 16:41. (lien). Évalué à 2.Oui mais maintenant il y a des ides digne de ce nom qui supportent le refactoring, l'un des piliers de l'agile programming.
-
[^]Re: pourquoi le lisp
Posté par Antoine () le 02/12/2006 à 13:05. (lien). Évalué à 4.L'IDE comme substitut aux faiblesses d'un langage de programmation, c'est vraiment un argument pourri. Un bon langage s'écrit correctement sans avoir besoin de fonctions "assistives", d'outils d'écriture automatique de code, de wizards et autres gizmos.
-
-
[^]Re: pourquoi le lisp
Posté par Zakath (page perso, ) le 01/12/2006 à 17:11. (lien). Évalué à 2.Sauf que si on fait des pattern matching corrects, on termine toujours par un cas
| _ -> 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 () le 02/12/2006 à 13:08. (lien). Évalué à 3.Sauf que si on fait des pattern matching corrects, on termine toujours par un cas
| _ -> 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 () le 01/12/2006 à 14:05. (lien). Évalué à 4.(performances équivalentes à celles de gcc).
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 () le 01/12/2006 à 14:22. (lien). Évalué à 1.Je ne vois honnêtement _rien_ dans la définition des langages C et Common Lisp, ni dans les styles de programmation idiomatiques de ces langages, qui implique une différence dans la performance des programmes. Pouvez-vous éclaircir ce point ?
-
[^]Re: pourquoi le lip
Posté par iug () le 01/12/2006 à 14:31. (lien). Évalué à 3.Je crois que tu as un morceau de pomme de terre dans l'oeil
-
[^]Re: pourquoi le lip
Posté par mvilleneuve () le 01/12/2006 à 14:52. (lien). Évalué à 1.Veux-tu dire que tu vois un exemple d'un extrait des specs de C et Common Lisp, ou des idiomes de programmation, qui implique une différence de performance ? Si c'est le cas, je serais très curieux de l'apprendre. Sinon, je pense qu'on peut ignorer ton message...
-
[^]Re: pourquoi le lip
Posté par taratatatata () le 01/12/2006 à 15:25. (lien). Évalué à 1.Tu ne comprends pas le raisonnement. On ne compare pas des langages qui ne s'utilisent pas de la même façon.
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 () le 01/12/2006 à 15:38. (lien). Évalué à 2.Je rajoute un lien sur le sujet :
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 () le 01/12/2006 à 15:44. (lien). Évalué à 2.Mais rien n'empèche le compilateur Lisp d'implémenter ces "outils puissants" de façon efficace. Ca demande plus d'intelligence de la part du compilateur et c'est vrai que pendant longtemps ce n'était pas entièrement le cas, mais un compilateur récent comme SBCL 1.0 est tout à fait capable de générer du code très optimal, même quand le code Lisp utilise des constructions de haut niveau.
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 () le 01/12/2006 à 15:49. (lien). Évalué à 2.Je me répète :
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 () le 01/12/2006 à 16:16. (lien). Évalué à 1.Je me répete aussi, je ne vois _rien_ dans les _langages_ qui interdisent les mêmes performances pour des programmes C et Lisp.
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 () le 01/12/2006 à 17:02. (lien). Évalué à 2."Je me répete aussi, je ne vois _rien_ dans les _langages_ qui interdisent les mêmes performances pour des programmes C et Lisp."
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 () le 01/12/2006 à 17:30. (lien). Évalué à 2.Le C est un peu une abstraction du langage machine des processeurs. Quand on code en C, on obtient naturellement un code très performant pour des logiciels qui se prêtent au langage C.
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 () le 01/12/2006 à 18:51. (lien). Évalué à 2.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,...
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
-
[^]Re: pourquoi le lip
Posté par Thomas () le 04/12/2006 à 10:48. (lien). Évalué à 1.Comme le faisait remarquer Richard P. Gabriel dans un de ses articles, un débutant en CL écrira des programmes plus lents qu'un débutant en C. Pourquoi? Parce que le C est bas niveau et qu'il faut tenir le compilateur par la main; et il est donc difficile d'écrire des programmes lents en C.
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 (Jabber id, page perso, ) le 01/12/2006 à 17:44. (lien). Évalué à 1.C'est les lispers eux même qui le disent. Et ils utilisent une version de SBCL de 2004, pas si vieille.
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 () le 01/12/2006 à 08:56. (lien). Évalué à 8.Comme on te l'a fait remarquer, tu prends le problème dans le mauvais sens. Un texte de Paul Graham est dispo là: http://paulgraham.com/icad.html
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 () le 01/12/2006 à 10:07. (lien). Évalué à 6.
C'est d'ailleurs cet aspect qui rend Lisp déconcertant au premier abord.
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 () le 01/12/2006 à 11:20. (lien). Évalué à 2.CLOS fait partie intégrante du langage Common Lisp, qui est le premier langage orienté objet a avoir obtenu un standard (ANSI, en 1994).
-
[^]Re: pourquoi le lisp
Posté par mvilleneuve () le 01/12/2006 à 13:12. (lien). Évalué à 1.Sinon, cette question est tout à fait légitime, il me semble que Paul Graham y répond bien dans le premier chapitre de son livre "ANSI Common Lisp" (chapitre disponible ici : http://lib.store.yahoo.net/lib/paulgraham/acl1.txt ).
-
[^]Re: pourquoi le lisp
Posté par golum () le 01/12/2006 à 13:33. (lien). Évalué à 2.
Suppose instead you want to write a function
that takes a number n, and returns a function that adds n to its
argument:
; Lisp
(defun addn (n)
#'(lambda (x)
(+ x n)))
What does addn look like in C? You just can't write it.
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 () le 01/12/2006 à 13:51. (lien). Évalué à 3.Le defun introduit une nouvelle fermeture lexicale.
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 () le 01/12/2006 à 13:57. (lien). Évalué à 1.Tu code un intrerpréteur Lisp en C et tu lui passes ton code, c'est la version "rouleau compresseur" ;)
Le faire le plus élégamment possible, je sais pas.-
[^]Re: pourquoi le lisp
Posté par Thomas () le 01/12/2006 à 14:09. (lien). Évalué à 0.C'est marrant, mais c'est l'approche utilisée par Yahoo lors de la conversion de Viaweb de Common Lisp vers C++ (les pages sont toujours sous forme de s-exp au final). L'auteur du commentaire plus haut qui faisait sarcastiquement remarquer que P. Graham ne se vantait pas de cette réécriture aurait dû le savoir.
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 () le 01/12/2006 à 14:41. (lien). Évalué à 1.Je n'avais pas compris qu'il fallait qu'elle renvoie une nouvelle fonction.
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 () le 01/12/2006 à 14:54. (lien). Évalué à 2.Justement, le petit exemple 'addn' n'est pas une fabrique de fonctions toutes identiques, chaque fonction qu'elle crée peut additionner un nombre différent à son argument. Par exemple, (addn 5) retourne une fonction qui ajoute 5 à son argument, (addn 10) retourne une fonction différente.
-
[^]Re: pourquoi le lisp
Posté par golum () le 01/12/2006 à 15:13. (lien). Évalué à 1.Merci.
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 () le 01/12/2006 à 15:31. (lien). Évalué à 2.Non non, les compilateurs Common Lisp (comme SBCL) sont tout à fait capables de compiler ce genre de constructions en code binaire efficace. Je ne connais pas les détails d'implémentation de SBCL, mais je sais que dans la lib CL-PPCRE [1], l'utilisation de ces constructions permet au moteur de regexp d'etre plus performant que celui de référence (celui de Perl, pourtant implémenté en C).
[1] http://weitz.de/cl-ppcre/
-
-
-
-
[^]Re: pourquoi le lisp
Posté par aurelj () le 02/12/2006 à 00:50. (lien). Évalué à 3.C'est bien évidemment possible en C !
#include <sys/mman.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
typedef int (*add_t)(int x);
int add(int x)
{
return x + 0x42424242;
}
add_t addn(int n)
{
char *p;
int size = (char *)addn - (char *)add;
add_t f = mmap(NULL, size, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
memcpy(f, add, size);
for (p=(char *)f; *(int *)p != 0x42424242; p++);
*(int *)p = n;
return f;
}
int main(void)
{
add_t f = addn(5);
printf("=> %d\n", f(7));
return 0;
}
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 () le 02/12/2006 à 13:18. (lien). Évalué à 3.C'est bien évidemment possible en C !
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 (page perso, ) le 02/12/2006 à 17:34. (lien). Évalué à 2.Je n'ai pas de source pour confirmer, mais il m'étonnerait beaucoup que ceci soit fonctionnel :
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 () le 02/12/2006 à 17:50. (lien). Évalué à 2.Je n'ai pas de source pour confirmer, mais il m'étonnerait beaucoup que ceci soit fonctionnel :
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 (page perso, ) le 02/12/2006 à 18:08. (lien). Évalué à 2.c'est bien ce que j'entends par "non-fonctionnel" :-)
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 () le 01/12/2006 à 14:03. (lien). Évalué à 1.Même avec des pointeurs de fonctions, je ne vois pas comment implémenter ce qui est demandé, soit : une fonction ('addn') qui prend un nombre n, et retourne une fonction qui ajoute n à son argument.
-
-
-
[^]Re: pourquoi le lisp
Posté par Thomas () le 01/12/2006 à 13:31. (lien). Évalué à 2."Ca signifie qu'à chaque fois que tu passes à un autre projet en lisp, tu dois réapprendre un nouveau langage"
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 () le 02/12/2006 à 13:29. (lien). Évalué à 4.Nope, je pense pas que tu ai répondu. Ce qu'il reprochait c'est justement que l'on peut recoder le "while" si on veut en lui donnant un autre nom. Ce qui fait que dans certains programmes, si le "while" a été maladroitement recodé, tu es
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 (Jabber id, page perso, ) le 03/12/2006 à 13:12. (lien). Évalué à 1.En géneral qu'en tu écris une fonction/macro comme le while en lisp tu test cette fonction depuis la boucle d'évaluation jusqu'à ce quelle fasse exactement ce que tu veux. Et ensuite tu peux utliser le while comme toute autre fonction sans différence et t'appuyer dessus parce qu'elle aura était testée (quitte à le restester avec d'autres arguments plus tard). Mine de rien ce mode de développement reduit pas mal le risque de bug.
-
[^]Re: pourquoi le lisp
-
-
-
-
-
[^]Re: pourquoi le lip
Posté par hocwp (Jabber id, page perso, ) le 01/12/2006 à 11:34. (lien). Évalué à 6.Pourquoi le lisp ? Pour moi parce que c'est souple, simple, efficace et ça me permet de faire tout ce que je veux de mon ordinateur.
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 () le 01/12/2006 à 12:52. (lien). Évalué à 2.Je suis allé naviguer un peu sur les liens que tu donnes, et ça va peut être me décider à faire le grand saut je crois. Je suis un fan de Eiffel, notamment pour le fort typage statique et la programmation par contrats. Problèmes: c'est un langage absolument inutilisé dans les entreprises, et chaque compilo (et il y en a très peu) utilise une variante du langage différente! De plus, la version en cours de normalisation (ECMA) s'est bien éloignée de l'original et ne sera pas implémentée dans le compilo du loria.
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 () le 01/12/2006 à 13:03. (lien). Évalué à 1.Il y a par exemple l'excellent livre "Practical Common Lisp" de Peter Seibel, disponible ici : http://www.gigamonkeys.com/book/
-
[^]Re: pourquoi le lip
Posté par golum () le 01/12/2006 à 13:15. (lien). Évalué à 2.L'implémentation des contrats citée en référence ne correspond qu'à un module en test, semble t'il
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 () le 01/12/2006 à 15:08. (lien). Évalué à 3.Je me suis mal exprimé:
<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 () le 01/12/2006 à 15:22. (lien). Évalué à 2.Tu te trompes :)
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 () le 01/12/2006 à 13:46. (lien). Évalué à 1.Après Practical Common Lisp (dispo en version papier aussi d'ailleurs), et si tu veux voir plus en détail l'un des aspects de Lisp qui le rend vraiment spécifique, je te conseille On Lisp de Paul Graham, qui traite spécifiquement des macros. Tu le trouveras ici: http://paulgraham.com/onlisp.html
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
-
-
[^]Re: pourquoi le lip
Posté par hocwp (Jabber id, page perso, ) le 01/12/2006 à 18:50. (lien). Évalué à 1.J'ai beaucoup aimé les livres de Paul Graham ANSI Common Lisp pour débuter puis On Lisp qui est plus ardu mais très impressionnant.
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 () le 01/12/2006 à 15:08. (lien). Évalué à 1.Je vois que tu as utilisé McCLIM pour ton éditeur de son. J'aimerais savoir quelles docs tu as utilisées pour apprendre. J'ai jeté un oeil à la doc de référence, mais je cherche plutôt un bon tuto. Tu me conseillerais quoi?
-
[^]Re: pourquoi le lip
Posté par mvilleneuve () le 01/12/2006 à 16:21. (lien). Évalué à 2.Personnellement, j'ai apprécié le "CLIM Guided Tour", fourni dans la distribution de McCLIM. Il est beaucoup plus "digeste" que la spec, et il donne une bonne introduction à la plupart des concepts courants, avec des exemples sympa...
-
[^]Re: pourquoi le lip
Posté par hocwp (Jabber id, page perso, ) le 01/12/2006 à 18:55. (lien). Évalué à 2.J'ai utilisé le guided tour qui est dans la doc et les exemples qui viennent avec McCLIM. Et bien sur la reference et pas mal de google.
http://www.ocf.berkeley.edu/~tfb/misc/lp90.pdf
http://common-lisp.net/project/mcclim/
-
-
Clos ?
Je vois qu'il parle de CLOS. J'avais utilisé une surcouche a clisp pour en pratiquer.
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 (Jabber id, page perso, ) le 02/12/2006 à 16:04. (lien). Évalué à 2.Si tu parles de l'implémentation clisp du Common Lisp, oui il y a eu des avancées depuis un certain temps dans la gestion du Meta-Object Protocol (MOP) qui respecte plus le standard.
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.
public! Cette erreur m'énerve. c pourtant pas dur... pourquoi ajouter un "e" à la fin?
-
[^]Re: Elle est en partie dans le domaine publique et sous licence BSD.
Posté par hocwp (Jabber id, page perso, ) le 02/12/2006 à 16:06. (lien). Évalué à 2.Je me suis relu et fais relire. Celle-ci est passée au travers des mailles du fillet. Désolé de t'avoir énervé...
long a apprendre ?
Il m'avait semblé avaoir lu quelque part (sans doute schemers.org) que la référence du langage lisp prenait beaucoup de place ... et que le sommaire était plus long que la référence du scheme.
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 (Jabber id, page perso, ) le 02/12/2006 à 16:16. (lien). Évalué à 2.En fait le noyau du Common Lisp ne doit pas être beaucoup plus gros que celui du scheme.
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
Cette page a été générée par Templeet en 0.3335s (dont 0.0423 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.