Journal : Lisaac plus rapide que le C !
Posté par Nicolas Boulay () le 24 avril 2008
Tout le monde s'en fout, mais cela fait des années que je suis persuadé qu'un langage de très haut niveau à plus de potentiel d'optimisation qu'un langage aussi bas niveau que le C. Et pourtant dés que l'on veut de la performance, on pense C.
C'est fait, Lisaac, un langage impératif à prototype, a plus de point que le C dans le langage shoutout. Il s'agit de microbenchmarks, dont l'algorithme est imposé.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
Cela fait un test un peu plus complet que le code mpeg2 qui servait de test.
http://isaacproject.u-strasbg.fr/li/li_benchs.html
Chapeau à Ben !
C'est fait, Lisaac, un langage impératif à prototype, a plus de point que le C dans le langage shoutout. Il s'agit de microbenchmarks, dont l'algorithme est imposé.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
Cela fait un test un peu plus complet que le code mpeg2 qui servait de test.
http://isaacproject.u-strasbg.fr/li/li_benchs.html
Chapeau à Ben !
> Lire le journal (157 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #926344.
Run by 
Cette page a été générée par Templeet en 0.1178s (dont 0.0098 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Langage de "très haut niveau"?
Pour moi langage de haut niveau ça veut dire "code concis". Eh bien, pour lisaac, c'est loin d'être le cas!
http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t(...)
Lisaac arrive pratiquement en dernière position, et, à en croire ce benchmark, il est plus de deux fois plus verbeux que python et ruby, et même plus verbeux que le vénérable C. Autant programmer en C donc, c'est aussi rapide et pas plus verbeux que lisaac, et beaucoup plus mature et mieux supporté.
[^]Re: Langage de "très haut niveau"?
Oui enfin le nombre de ligne ne fait pas tout.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Langage de "très haut niveau"?
C'est pas le nombre de lignes, c'est la taille du code zippé. Ok, c'est pas ultime comme benchmark, mais je pense que ça reflète quand même la réalité. D'ailleurs, il suffit de jetter un coup d'oeil au code pour voir que c'est très verbeux. Alors, appeler ça un "langage de très haut niveau", c'est un peu abuser...
[^]Re: Langage de "très haut niveau"?
Bonjour,
ce n'est pas vraiment la définition d'un langage de haut niveau. Un langage de haut niveau se définit plutôt par ses possibilités de programmation "conceptuelle", "abstraite". En gros l'idée est de s'éloigner de toute notion trop concrète (vis à vis du matériel informatique du moins), pas d'allocation mémoire (et toute gestion de mémoire d'ailleurs, pour que les segfaults ne soient plus qu'un lointain souvenir...), encore moins de libération mémoire (garbage collector...), ne plus se poser de questions s'il est plus optimisé de mettre une variable par valeur ou par référence, s'il est mieux d'utiliser un pointeur, une référence, une copie, ne pas avoir à gérer des tailles de conteneur (prévoir les tailles des chaînes de caractère, les vecteurs & co à l'avance, puis les redimensionner ensuite notamment), etc.
En gros, plus un langage est haut niveau, moins on s'occupe de l'ordinateur et essentiellement du but et de comment on veut y arriver éventuellement (quoique le plus haut niveau qui soit, on pourrait imaginer qu'il n'y a même plus du tout à s'occuper du "comment").
- L'une des manières d'y arriver est parfois effectivement de faire dans la simplicité, ou la flexibilité, notamment du langage, et donc d'avoir un langage concis. Beaucoup pour cela vont par exemple abstraire un peu les notions de type (typage faible) sans déclaration de variable souvent (et donc du type).
- Mais aussi souvent c'est d'aller de plus en plus au sémantique par exemple, et pour cela, un langage va souvent devenir verbeux. Notamment on veut que quelqu'un puisse lire et comprendre votre programme du premier coup sans le connaître par exemple.
- Le conceptuel est aussi très présent. Ainsi la prog objet a été un pas vers le haut niveau: c'était l'idée de concevoir la prog comme une manipulation d'objets qui "savent" faire certaines choses. D'autres se sont dits qu'ils allaient plutôt concevoir le "monde" comme un endroit avec des faits (prédicats) et des règles. Ca donne des langages logiques comme Prolog. Il y a aussi d'autres concepts, pour enregistrer les données par ex, a-t-on besoin d'une pile (on met les objets les uns sur les autres), d'une liste, etc.
En fait il y a beaucoup de façon de concevoir du "haut niveau" et cela peut mener à divers types de langage, parfois verbeux, parfois non. Mais la seule constante, c'est s'abstraire de la machine. Et la verbosité n'a rien à voir là dedans.
[^]Re: Langage de "très haut niveau"?
Je suis tout à fait conscient que j'utilise une définition très restreinte de ce qu'est un langage de très haut niveau. Mais c'est le seul aspect du haut niveau qui m'intéresse, donc je l'assume :)
Franchement, quel est l'intérêt de s'abstraire de la machine si ça ne résulte pas en un code plus clair et plus concis?
[^]Re: Langage de "très haut niveau"?
En fait plus concis ne signifie pas forcément plus clair. Ca peut l'être, mais ça peut aussi être tout l'inverse. Pour le développeur en particulier, c'est clair que plus y a de touches à taper, plus c'est chiant. Par contre pour un relecteur, un nouveau mainteneur, ou même le développeur lui-même mais 3 mois après quand il revient sur du code qu'il a écrit pour le changer et s'en rappelle plus, des fois c'est chiant si on comprend pas tout de suite ce que le développeur a voulu faire.
Un exemple (parmi tant d'autres) très simple de ce qu'apporte la verbosité est les paramètres labellisés/nommés par ex. C'est un système que je n'ai vu que sur Ocaml et Ada95, mais je ne connais pas tous les langages du monde et ça existe sûrement ailleurs.
Par exemple, imaginez la fonction "attaque" qui prend 2 paramètres: l'attaquant et l'attaqué. Comment savoir si le premier paramètre est l'attaquant ou l'attaqué, surtout que les 2 params ont le même type (un "personnage")? Dans notre cas, sémantiquement nous ferons souvent plutôt: attaque (attaquant, attaqué). Néanmoins il y a de nombreux cas de fonctions où ce n'est pas si évident (et même là, après tout rien n'interdit à un dév d'estimer que c'est mieux dans l'autre sens!). Donc si on lit le script suivant: attaque (robert, martin). Qui attaque qui? Simple et concis, c'est sûr; clair, sûrement pas. On se reporte à la doc, on perd du temps. Et là c'est un exemple facile, encore une fois (quand t'as une fonction avec 10 paramètres et une sémantique beaucoup moins "vie courante", y a plus rien de clair). Mais les langages qui implémente le nommage de variables donnent la possibilité d'écrire:
attaque (attaquant => robert, attaqué => martin).
Là, c'est réellement clair. Et pourtant c'est sacrément plus verbeux. Mais au moins n'importe quel pecno qui relit le code le comprend immédiatement et on gagne un temps fou.
Donc non concis n'implique absolument pas clair, encore moins réciproquement.
[^]Re: Langage de "très haut niveau"?
Pour reprendre ton example, robert.attaque(martin), c'est encore plus clair, et plus concis. Le truc le plus clair est forcément concis (même si c'est pas forcément le plus concis. La concision absolue n'est pas un objectif en soi, sur ce point je suis bien d'accord).
[^]Re: Langage de "très haut niveau"?
Il a volontairement pris un exemple simple... Comment tu aurais fait s'il y avait eu d'autres paramètres ?
[^]Re: Langage de "très haut niveau"?
Lis le commentaire de CrEV :) De toutes façons, je n'ai rien contre un peu de verbosité volontaire, pour résoudre une ambiguité. Ce qui est mal, c'est la verbosité imposée par le langage.
[^]Re: Langage de "très haut niveau"?
c'est surtout que
attaque (attaquant => robert, attaqué => martin)et
robert.attaque(martin)ne sont pas du tout la même chose
dans le premier cas, on a un 'attaque' qui est "global" alors que dans le deuxième attaque s'applique à 'robert'
Cet exemple montre justement que le premier est plus verveux et pourtant pas plus clair...
En ce sens, les nomages à la objective C me semblent intéressant. On aurait écrit (en gros) :
[robert attaque:martin]D'ailleurs, il suffit de rajouter un paramètre pour le voir un peu mieux :
attaque(attaquant => robert, attaqué => martin, arme => machette)robert.attaque(martin, machette)[robert attaque:martin avec_arme:machette]D'ailleurs, on retrouve parfois ce genre de construction en ruby (en jouant sur les hash) :
robert.attaque margin, arme => machetteTout ça pour dire que je trouve vraiment que les langages concis et bien foutu permettent d'avoir des codes bien plus lisibles, plus compréhensible. Il est d'ailleurs au pire toujours possible de faire du verbeux, du lourd avec un langage concis, mais malheureusement pas le contraire (et les langages trop verbeux ... beurk)
En fait, ce qu'il faut à mon avis ces des langages expressif, et je trouve que ruby en est justement un pas trop mauvais exemple. Il est concis, lisible et suffisament expressif pour avoir des codes lisibles et propres
[^]Re: Langage de "très haut niveau"?
La notation la plus claire me semble [robert attaque:martin] car elle met en avant la sémantique de l'expression: [sujet > prédicat > objet ] plus une propriété pour arme>machette. Cette notation se rapproche du langage naturel sans impliquer la compréhension de trop de concepts abstraits. J'aime bien.
[^]Re: Langage de "très haut niveau"?
Nuance : ça se rapproche des langages naturels de type SVO (sujet-verbe-objet).
Cet ordre n’est pas universel. Tous les ordres possibles ont au moins un exemple de langue qui l’utilise (cf. Langue_VSO).
Tu préfères cet ordre parce que le français est SVO. Un Japonais, un arabophone, etc., préfèreront un autre ordre.
C’est fou où ça va se cacher les préjugés culturels…
[^]Re: Langage de "très haut niveau"?
+1
Il s'agit plutôt d'ignorance que de préjugé, je l'ai perçu comme ça de prime abord, ta remarque est juste.
[^]Re: Langage de "très haut niveau"?
En Lisaac/Smalltalk (syntaxe à mot clé)
robert.attaque martin avec manchette;
[^]Re: Langage de "très haut niveau"?
En smalltalk ce serait plutôt:
robert.attaque: martin avec: manchette;Ce que je trouve plus approprié et moins ambiguë. Cela permet aussi de pouvoir faire référence aux slots ainsi: attaque:avec: au lieu de ce qu'on a en Lisaac: attaque__avec (enfin je crois bien que c'est ça)
La Roue du Temps
[^]hRe: Langage de "très haut niveau"?
En haskell :
attaque :: perso -> perso -> resultat
robert `attaque` martin
attaque :: perso -> perso -> arme -> resultat
avec a b = a b
robert `attaque` martin `avec` manchette
[aussi disponible en version avec manchette (robert `attaque` martin), pour une autre définition de avec ou de attaque]
[^]Re: Langage de "très haut niveau"?
Même si clair et concis ne sont pas antinomiques en développement ils sont parfois durs à concilier.
Si je prend l'exemple de Ruby, certains codes biens écrits peuvent se lire quasiment comme un texte en anglais.
A contrario Perl est très concis, mais celui qui me diras qu'il est clair ....
Mais vu tes posts je suppose que tu as un langage préféré à mettre en avant. Alors vas y ne te gène pas.
[^]Re: Langage de "très haut niveau"?
>A contrario Perl est très concis, mais celui qui me diras qu'il est clair ....
Perl est beaucoup plus claire pour faire le boulot pour lequel, il a été conçu (notamment car je connais aucun autre langage intégrant si bien les expressions régulières).
Pour rappel, PERL ça signifie :
"Practical Extraction and Report Language" ou "langage pratique d'extraction et de génération de rapports"
[^]Re: Langage de "très haut niveau"?
La clarté et la concision sont deux choses totalement indépendantes.
Un langage plus verbeux peut t'éviter de faire des erreurs subtiles.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Langage de "très haut niveau"?
La clarté et la concision sont deux choses totalement indépendantes.
Pas du tout. La verbosité pénalise la lisibilité du code (sans parler du temps passer à l'écrire) . Un truc écrit concisement (par concis j'entends peu de symboles, pas peu de charactères. Un nom de variable, même long de 40 charactères ne compte que comme un symbole. Cela est pris en compte en considérant la taille du code zippé, et non le nombre de lignes ou de charactères), si il est bien écrit, sera plus facile à maintenir qu'un truc verbeux équivalent.
En fait, concis n'implique pas clair, mais parfaitement clair implique concis.
[^]Re: Langage de "très haut niveau"?
non, car un code concis peut etre ambigue.
Bref, clair (code lisible, facilement compréhensible et maintenable) et concis (code avec peu de construction, etc...) n'ont strictement rien a voir.
C'est pas en affirmant "si c'est concis alors c'est plus clair qu'un truc verbeux équivalent" que c'est vrai.
Bref affirmation sans fondement n'est que ruine de la discussion :P
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Langage de "très haut niveau"?
Comme je l'ai dit dans un autre commentaire, je n'ai rien contre un peu de verbosité volontaire pour éviter une ambiguité. Ce qui n'a rien à voir avec la verbosité imposée par un langage.
[^]Re: Langage de "très haut niveau"?
je n'ai rien contre un peu de verbosité volontaire pour éviter une ambiguité
On parle d'un langage qui dois être compréhensible.
Et tu nous dis toi même qu'un langage concis est plus compréhensible.
Et derrière tu nous dis "ben euh non en réalité c'est au developpeur d'expliquer ce qu'il fait finalement"...
Avec de l'ASM c'est concis (très peu de symbole != ) et tu peux le "verbositer" si tu veux. (mettre des commentaires, tout mettre bien dans plein de registres, toussa)
Perso je trouve pas ça très clair pourtant
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Langage de "très haut niveau"?
Un programme en assembleur comptera énormément de symboles même pour faire une chose simple. Bref, tu ne comprends pas ce que je dis.
[^]Re: Langage de "très haut niveau"?
si je comprend ce que tu dis, mais un programme en assembleur ne comptera pas énormément de symboles pour faire une chose simple.
Tu as les n instructions du proc (tu peux faire des procs avec très peu de symboles), tu aura tes registres (assez peu) et des accès mémoire.
Nombre de symbole différent : peu.*
Nombre d'instructions : beaucoup.
Tu définis toi même qu'une variable comme un seul symbole , je te cite :
Un nom de variable, même long de 40 charactères ne compte que comme un symbole. Cela est pris en compte en considérant la taille du code zippé, et non le nombre de lignes ou de charactères)
Et on peu s'amuser a faire exactement l'inverse un langage avec énormément de symboles (fonction, variables, ...), et extrêmement peu d'instructions.
Et ça ne sera pas non plus beaucoup plus lisible.
Et puis supposons que je comprenne pas (après tout je n'ai pas la science infuse) , pourquoi tu ne m'explique pas ce que tu as voulu dire plutot que "tu comprend pas ce que je dis" ?
Bref, la tu joue ton "grand maître ténébreux" :
- aucune argumentation, juste des trucs parachuté (un code clair est forcément concis. Pas d'explication du pourquoi. Du raisonnement ni rien.
Pas de définition de ce que tu entend par concis ni verbeux, vu que visiblement on a pas du tout la meme définition)
- aucune explication de ce que tu utilise. (Typiquement ce que tu entend par symbole)
- seul contre argument "Tu comprend pas" ou encore "Pas du tout" ou "relis moi bien" (aucune remise en cause ou volontée que l'autre comprenne).
Ca fait cours quand même comme argumentation...
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Langage de "très haut niveau"?
Je pense que son "tu ne comprends pas ce que je dis" s'adressait uniquement à la question de l'assembleur, qui effectivement ne permet pas la concision (sauf cas extrèment particulier)
En fait la concision n'est pas tant liée aux nombre de symboles et de paramètres des opérations élémentaires d'un langage qu'à la capacité à spécifier simplement et sans ambiguité des algorithmes résolvants des problèmes complexes. Le cerveau humain étant ce qu'il est, la concision est souvent souhaitable afin de permettre au programmeur d'avoir plus de choses en tête à un instant T, le langage influant à mon avis fortement sur la manière de penser pendant un développement. La possibilité de concision est fortement liée aux abstractions fournies par un langage.
Alors évidemment on peut faire du concis qui ne soit pas particulièrement clair (à la one liner Perl qui descramble du CSS :D ), mais cela n'empeche pas au concis de facilité la clarté lorsqu'il est bien utilisé.
[^]Re: Langage de "très haut niveau"?
Merci!
[^]Re: Langage de "très haut niveau"?
Le grand intérêt avec ta réponse (et je t'en remercie) c'est que tu définie précisement le périmètre que tu étudies.
Toutefois elle ne me satisfait pas totalement, et je vais détaillé pourquoi :
à la capacité à spécifier simplement et sans ambiguité des algorithmes résolvants des problèmes complexes.
1°) Ce n'est pas un critère qui peut vraiment servir à comparer des langages alors.
Les différents types de langages (fonctionnel, objet, ...) sont eux comparé par ça : ils permettent de s'approcher de la logique de l'algorithme afin de simplifier l'implémentation des algorithmes résolvants des problèmes complexes.
2°) Cette capacité différe automatiquement (par application du principe 1) suivants les algorithmes!
un algorithme très simple a développer (prog de généalogie) en prolog peut être une horreur en C ... Et inversement!
Donc le prolog est plus concis que le C, ou inversement. \o/
mais cela n'empeche pas au concis de facilité la clarté lorsqu'il est bien utilisé.
Et idem pour la verbosité ;)
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Langage de "très haut niveau"?
C'est pas en affirmant "si c'est concis alors c'est plus clair qu'un truc verbeux équivalent" que c'est vrai.
Relis moi bien, j'ai pas dit ça. Tout ce que je dis, c'est qu'un truc clair est forcément raisonablement concis.
[^]Re: Langage de "très haut niveau"?
Relis moi bien, j'ai pas dit ça.
Vraiment ?
je te cite alors
En fait, concis n'implique pas clair, mais parfaitement clair implique concis.
Donc on a
clair => concis. (c'est ce que tu dis).
Comme verbeux = |(concis) (complémentaire de concis)
Donc clair =/=> verbeux.
Alors effectivement ce n'est pas une équivalence entre clair et concis, mais tu as bien dis que si c'était clair alors c'était concis. Donc si on a le choix entre un truc concis et un truc verbeux , équivalent (dans mon message "truc verbeux équivalent" ) alors le concis est plus clair.
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Langage de "très haut niveau"?
Donc si on a le choix entre un truc concis et un truc verbeux , équivalent (dans mon message "truc verbeux équivalent" ) alors le concis est plus clair.Non il n'a pas dit ça, il a dit que si c'est clair c'est concis, ça n'implique pas qu'un truc concis est forcément clair... A => B != B=> A
All those moments will be lost in time, like tears in the rain.
[^]Re: Langage de "très haut niveau"?
personne vois le mot "équivalent" que j'ai marqué 3 fois ?
et personne ne vois "Alors effectivement ce n'est pas une équivalence entre clair et concis," ?
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Langage de "très haut niveau"?
Le equivalent voulait dire, "aussi bien écrit". Mais bon, c'était pas très clair :)
[^]Re: Langage de "très haut niveau"?
Je suis plutôt d'accord. Néanmoins la verbosité n'est pas complètement décorrelée du niveau du langage, surtout d'un point de vue pratique : il est beaucoup plus difficile (généralement...) d'être concis en utilisant un langage de bas niveau, et les abstractions fournies par les langages de haut niveau n'auraient en pratique pas beaucoup d'interêt s'il fallait au final écrire 10x plus de code qu'en ASM (sauf si on ne documente pas son code ASM :)
Disons que si les abstractions ne permettent pas la concision, elles sont moins intéressantes en terme de productivité.
En ce qui concerne les bench d'alioth, les programmes sont très courts et à mon avis on ne peut pas vraiment estimer et comparer les concisions des langages sans prendre en compte certaines caractéristiques comme le niveau du typage. Sans compter que le paradigme peut jouer énormement selon le type de problème posé (penser à du backtracking en logique versus en impératif ... :)
[^]Re: Langage de "très haut niveau"?
Pour certains, les langages de haut niveau sont ceux dont les livres sont sur l’étagère du haut, la poussiéreuse.
Pour certains, les langages de bas niveau sont ceux dont les livres servent à caler la bibliothèque.
[^]Re: Langage de "très haut niveau"?
C'est intéressant comme remarque..
C'est vrai que quand on regarde le code ruby, c'est beaucoup plus concis.
Lisaac est effectivement "encore" trop verbeux.
Mais l'avantage dans tous cela, c'est que ça peut facilement changer : quasiment toutes les structures de contrôles sont définis en librairie, et il suffira d'avoir les même fonctions que ruby dispose dans sa librairie, pour se retrouver avec un code à peine plus gros.
Il y a eu un gros travail de réflexions là dessus, de la part de Mildre et votre serviteur : pas mal de foreach ont été implémentés, avec différentes variantes. Il existe aussi des map/fold/filter.
Les utiliser ne devrait pas couter en performances, vu que l'on retombe sur des boucles classiques.
Il y aussi beaucoup de choses à implémenter : quand je regarde fasta par exemple, il y a des fonctions slices, join, etc... qu'on a pas encore, et ce genre de fonctions racourcissent le code...
Bref, Lisaac est bien un langage de haut niveau, et comme Ruby dont il est assez proche, tout est une question de libraire.
[^]Re: Langage de "très haut niveau"?
Mais l'avantage dans tous cela, c'est que ça peut facilement changer : quasiment toutes les structures de contrôles sont définis en librairie, et il suffira d'avoir les même fonctions que ruby dispose dans sa librairie, pour se retrouver avec un code à peine plus gros.
Tout est dans le "facilement". C'est probablement facile techniquement, mais concevoir une bonne librairie standard est un challenge, et c'est très important pour la réussite du langage. J'aimerais beaucoup essayer Lisaac, mais en l'absence d'une bonne librairie standard (jette un coup d'oeil à celle de python (au sens large, ça inclut les types inclus dans le langage, tels que {}, [], set, frozenset, string, etc.) pour voir ce que je veux dire.), ce langage n'a pas d'intérêt pour moi.
La librairie doit être bien fournie, sans superflu, et être extrêmement cohérente pour que son utilisation soit intuitive et facile. Pas si évident que ça à mon avis :)
[^]Re: Langage de "très haut niveau"?
Je confirme, c'est extrêmement difficile.
Il faut savoir que la librarie de Lisaac, est la copie conforme de la librairie SmartEiffel pour tous les types de bases, à quelques exceptions près.
Elle reprend donc toute l'expérience de celle de SmartEiffel, qui est elle même parait-il basée sur celle de smalltalk-80.
Pour le moment, elle recouvre un minimum :
- entiers, structures de contrôle, IO, chaines
- conteneurs de bases (collections, ensembles, hashtables)
- accès fichier
- Quelques formats de fichiers (bmp, ai, tga)
- Une gui totalement native, qui s'améliore de jour en jour, mais encore jeune.
- Un super binding open-gl (merci Damien), qui gère plein de choses, lit les md2 de quake...
- Un binding lua
Notons qu'avec tout ça, on peut d'ors et déjà faire un jeu 3D en Lisaac... sans le son.
En passant, citons d'autre outils :
- Un player mpeg2
- Un compilateur de compilateur SLR (Sanglier)
- Une lib freetype qui marchait il y a quelques années, et qu'il faut remettre au gout du jour.
Il nous manque pas mal de choses (réseau, regexp, gestion du temps, maths avancé, logging, xml, html, ...).
[^]Re: Langage de "très haut niveau"?
- Quelques formats de fichiers (bmp, ai, tga)
Que des formats que tout le monde utilise tous les jours, quoi..
[^]Re: Langage de "très haut niveau"?
Sans compter que le code qui gère ça n'a pas l'air bien propre ... il me semble que la dernière fois, j'avais vu un slot 'open_bmp' dans ABSTRACT_ENTRY (représente un élément du système de fichiers) ...
C'est là: http://svn.gna.org/viewcvs/isaac/trunk/lisaac/lib/file_syste(...)
Je pense que la lib mériterait d'être revue à fond. Mais il y a d'autres choses plus urgentes à faire.
La Roue du Temps
[^]Re: Langage de "très haut niveau"?
La lib collection me parait assez bien faites, mais il est vrai que tout ce qui est fichier, format, et même à la limite vidéo mériterait d'être revu.
Bref, en fait, tout ce qui ne vient pas d'Eiffel...
Même la Gui, qui devient vraiment intéressante pourrait être simplifiée.
Après vu tout le code que tu produis en lisaac, tu aurais peut être des critiques sur la core library ;)
[^]Re: Langage de "très haut niveau"?
Si tu prends l'exemple du codeur mpeg2, lisaac a 30% de ligne de code en moins car il n'a pas besoin de gérer la mémoire pour les buffer interne.