Perso, je dirais que non (et je vais travailler pour que ça devienne oui).
Pourquoi ?
D'une part, il n'y a pas de gestion correcte des erreurs (et la lib standard n'est pas très jolie). On a les contrats (formidable) mais ils ne permettent pas de gérer toutes les erreurs. Comment gérer par exemple une erreur d'allocation mémoire.
Pour le moment, si une allocation échoue, on a droit à un exit(1) ... Je n'aime pas trop.
D'autre part, le temsp de compilation est exponentiel. De ce coté, Benoît a fournit un travail extraordinaire ! Mais cela n'empêche pas que ce soit quelque chose que je considère gênant.
Si on arrive a modulariser le compilateur (compiler des modules séparément) alors on aura peut être un temps de compilation exponnentiel sur chaque module (mais raisonnable car chaque module aura une taille limitée). Bien sûr, il faut bien concevoir l'application et déterminer où seront les interfaces. Ces choix influront probablement sur les optimisation que Lisaac pourra faire.
Enfin pour le moment c'est juste une idée (que je n'ai même pas encore soumise à la mailing liste).
Et bien sûr, le dernier point, c'est le problème des bibliothèques que j'ai résolu en local mais qui n'est pas (encore ?) dans le tronc. En gros, actuellement, tu as un fichier path.li global (installé dans /usr, donc un utilisateur ne peux pas le modifier) qui liste les dossiers de ton projet et les dossiers des bibliothèques.
Impossible d'installer une bibliothèque sans toucher à ce fichier
Impossible de commencer un projet (organisé en plusieurs dossiers) sans toucher à ce fichier.
A mon avis, il faut se mettre au boulot et sans doute que dans un an ces problèmes auront disparu. J'espère.
[^] # Re: Prêt à être utilisé par les masses?
Posté par Mildred (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 4.
Pourquoi ?
D'une part, il n'y a pas de gestion correcte des erreurs (et la lib standard n'est pas très jolie). On a les contrats (formidable) mais ils ne permettent pas de gérer toutes les erreurs. Comment gérer par exemple une erreur d'allocation mémoire.
Pour le moment, si une allocation échoue, on a droit à un exit(1) ... Je n'aime pas trop.
D'autre part, le temsp de compilation est exponentiel. De ce coté, Benoît a fournit un travail extraordinaire ! Mais cela n'empêche pas que ce soit quelque chose que je considère gênant.
Si on arrive a modulariser le compilateur (compiler des modules séparément) alors on aura peut être un temps de compilation exponnentiel sur chaque module (mais raisonnable car chaque module aura une taille limitée). Bien sûr, il faut bien concevoir l'application et déterminer où seront les interfaces. Ces choix influront probablement sur les optimisation que Lisaac pourra faire.
Enfin pour le moment c'est juste une idée (que je n'ai même pas encore soumise à la mailing liste).
Et bien sûr, le dernier point, c'est le problème des bibliothèques que j'ai résolu en local mais qui n'est pas (encore ?) dans le tronc. En gros, actuellement, tu as un fichier path.li global (installé dans /usr, donc un utilisateur ne peux pas le modifier) qui liste les dossiers de ton projet et les dossiers des bibliothèques.
Impossible d'installer une bibliothèque sans toucher à ce fichier
Impossible de commencer un projet (organisé en plusieurs dossiers) sans toucher à ce fichier.
A mon avis, il faut se mettre au boulot et sans doute que dans un an ces problèmes auront disparu. J'espère.
Mildred