mvilleneuve a écrit 17 commentaires

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...

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...

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...

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.

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.

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/

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.

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...

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 ?

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...

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.

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...

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 ).

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"

Il y a par exemple l'excellent livre "Practical Common Lisp" de Peter Seibel, disponible ici : http://www.gigamonkeys.com/book/

CLOS fait partie intégrante du langage Common Lisp, qui est le premier langage orienté objet a avoir obtenu un standard (ANSI, en 1994).

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).