Ben j'en sais les benchs que vous donnez...
Ce n'est pas parce que l'implémentation d'un concept à un instant T est moins performante, que ce concept est invalide. Ce n'est pas une condition nécessaire, tu n'as rien prouvé là.
Oui t'as répondu : on peut faire ses propres constructions. Alors faut savoir, tu dis c'est génial on peut faire ses propres constructions et d'autre part "oué je vois mal un type choisir autre chose que le if"... C'est tout sauf logique les objectifs là.
La librairie est en libre (Cecill), si quelqu'un a une primitive intéressante, on l'intègre.
Pour le reste, s'il y a au moins 1% de codeur qui toucheront à Boolean.li, je serai très étonné.
mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
C'est hors de question. Le compilateur restera hyper minimaliste, comme je l'ai expliqué en bas, ça permet de se concentrer sur la sémantique du code. de plus, comme on te l'a expliqué ailleurs, cela permet de faire un compilo plus propre, donc moins de bug, etc...
Seront rajoutées des primitives lorsqu'on tombera sur du très haut niveau, genre le SQL intégré ou des primitives très haut niveau comme "qqsoit x de l'ensemble".
>Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il >manque quelque confort pour la chose c'est un détail qui se règle en quelques heures >au niveau du compilateur.
Ah ben heureux de l'entendre ! Jusqu'ici t'avais "oui peut être qu'il faudrait que".
Il y a une ML pour le projet, tu as le droit de contribuer.
Mais je prend pas les gens pour des cons ! C'est un constat bon sang : dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final". Que faut il comprendre ? On laisse la possibilité à la classe dérivée de réécrire cette méthode ? Non, dans la plupart des cas c'est un "oubli" et la réécriture peut provoquer une modification du comportement de la classe complètement inatendu.
Des gens prennent des décisions baeucoup plus pragmatique, et tu vas le voir pas juste "parcque les gens sont cons" : http://www.artima.com/intv/nonvirtual.html
Envoi un mail à Benoit, je ne me sens pas assez qualifié pour répondre à ça.
[héritage dynamique, prototype]Moi je veux bien, mais ca sert à quoi ? Ca apporte quoi ?
C'est à toi de répodnre à cette question lorsque tu designe une application.
Premièrement, cela apporte que la structure objet que tu codes, restera la même à l'exécution, ce qui n'est pas le cas avec l'objet à classe. Une classe n'est qu'un moule, il faut l'instancier pour qu'elle devienne vivante, tandis qu'un prototype est vivant dès le début.
Deuxièmement, l'héritage dynamique te permet de simplifier considérablement l'arbre d'héritage.
On met beaucoup de temps à comprendre l'intérêt de ces possibilités. Même son auteur a mis beaucoup de temps à utiliser l'héritage dynamique dans son langage. Le compilo actuel n'en n'utilise pas, le futur qui sortira bientôt, l'utilise massivement.
C'est en designant ton appli que tu en vois l'intérêt.
Toutafé d'accord. D'où l'ensemble de mes remarques : dans un projet c'est pas le temps passé à code qui bouffe en productivité : c'est le temps passé à résoudre les bugs, intégrer le code à l'existant, documenter le code, concevoir des API "friendly" et pertinents, écrire des tests, etc. Et le langage en lui même contribue à tout ca.
Pour résoudre les bugs, ya pas de debugger mais ça viendra.
intégrer le code à l'existant, c'est dors et déjà possible, on va travailler à améliorer la cosmétique.
Pour la doc, un générateur de Doc, un peu dans le style de Javadoc sera intégré dans la prochaine version du compilateur.
Pour concevoir des API friendly, le haut niveau du langage et son expressivité sont là pour ça. Observe la lib de la GUI par exemple, elle est à mon sens beaucoup mieux pensée que ce qu'on peut trouver ailleurs.
Pour les tests, tu as les contrats.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Euh ...
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 4.
Ce n'est pas parce que l'implémentation d'un concept à un instant T est moins performante, que ce concept est invalide. Ce n'est pas une condition nécessaire, tu n'as rien prouvé là.
Oui t'as répondu : on peut faire ses propres constructions. Alors faut savoir, tu dis c'est génial on peut faire ses propres constructions et d'autre part "oué je vois mal un type choisir autre chose que le if"... C'est tout sauf logique les objectifs là.
La librairie est en libre (Cecill), si quelqu'un a une primitive intéressante, on l'intègre.
Pour le reste, s'il y a au moins 1% de codeur qui toucheront à Boolean.li, je serai très étonné.
mais je défend une autre voie : Le compilateur doit posséder un utilitaire qui vérifie que certaines normes de codages sont respectés, et dénonce les formes dangereuses.
C'est hors de question. Le compilateur restera hyper minimaliste, comme je l'ai expliqué en bas, ça permet de se concentrer sur la sémantique du code. de plus, comme on te l'a expliqué ailleurs, cela permet de faire un compilo plus propre, donc moins de bug, etc...
Seront rajoutées des primitives lorsqu'on tombera sur du très haut niveau, genre le SQL intégré ou des primitives très haut niveau comme "qqsoit x de l'ensemble".
>Pour le reste, oui on peut faire des API pour d'autres langages en Lisaac, s'il >manque quelque confort pour la chose c'est un détail qui se règle en quelques heures >au niveau du compilateur.
Ah ben heureux de l'entendre ! Jusqu'ici t'avais "oui peut être qu'il faudrait que".
Il y a une ML pour le projet, tu as le droit de contribuer.
Mais je prend pas les gens pour des cons ! C'est un constat bon sang : dans baeucoup de classes Java je vois des méthodes qui ne sont pas marqués comme "final". Que faut il comprendre ? On laisse la possibilité à la classe dérivée de réécrire cette méthode ? Non, dans la plupart des cas c'est un "oubli" et la réécriture peut provoquer une modification du comportement de la classe complètement inatendu.
Des gens prennent des décisions baeucoup plus pragmatique, et tu vas le voir pas juste "parcque les gens sont cons" :
http://www.artima.com/intv/nonvirtual.html
Envoi un mail à Benoit, je ne me sens pas assez qualifié pour répondre à ça.
[héritage dynamique, prototype]Moi je veux bien, mais ca sert à quoi ? Ca apporte quoi ?
C'est à toi de répodnre à cette question lorsque tu designe une application.
Premièrement, cela apporte que la structure objet que tu codes, restera la même à l'exécution, ce qui n'est pas le cas avec l'objet à classe. Une classe n'est qu'un moule, il faut l'instancier pour qu'elle devienne vivante, tandis qu'un prototype est vivant dès le début.
Deuxièmement, l'héritage dynamique te permet de simplifier considérablement l'arbre d'héritage.
On met beaucoup de temps à comprendre l'intérêt de ces possibilités. Même son auteur a mis beaucoup de temps à utiliser l'héritage dynamique dans son langage. Le compilo actuel n'en n'utilise pas, le futur qui sortira bientôt, l'utilise massivement.
C'est en designant ton appli que tu en vois l'intérêt.
Toutafé d'accord. D'où l'ensemble de mes remarques : dans un projet c'est pas le temps passé à code qui bouffe en productivité : c'est le temps passé à résoudre les bugs, intégrer le code à l'existant, documenter le code, concevoir des API "friendly" et pertinents, écrire des tests, etc. Et le langage en lui même contribue à tout ca.
Pour résoudre les bugs, ya pas de debugger mais ça viendra.
intégrer le code à l'existant, c'est dors et déjà possible, on va travailler à améliorer la cosmétique.
Pour la doc, un générateur de Doc, un peu dans le style de Javadoc sera intégré dans la prochaine version du compilateur.
Pour concevoir des API friendly, le haut niveau du langage et son expressivité sont là pour ça. Observe la lib de la GUI par exemple, elle est à mon sens beaucoup mieux pensée que ce qu'on peut trouver ailleurs.
Pour les tests, tu as les contrats.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker