Bon, tu me gonfles :-)
Oué sauf qu'au final c'est :
- moins performant que du C (ils l'ont montré)
Qu'en sais-tu ? Pour le moment, le compilateur crache du code légèrement mois rapide que du C, mais peut être que celui-ci sera plus rapide bientôt ?
Je crois beaucoup aux optimisations de gestion de la mémoire, à la réécriture de boucle, etc...
- pas spécialement plus maintenable que le comme je l'ai montré : pas de reflexion sur l'intégration avec l'existant, pas de reflexion sur le versionning ou les outils de documentation, une trop grande liberté dans les constructions, etc.
Ce langage date de deux ans, et depuis deux ans son auteur a pas eu le temps de faire grand chose (post-doc, cours à la fac, etc...).
On débute ! On est pas SUN ni Microsoft ! Laisse nous le temps de lister, réfléchir à tout le travail qui doit être effectué à ce propos et de l'implémenter !
Quand à la trop grande liberté dans les constructions, je vois franchement mal un type décidé d'utiliser autre chose que le if.
On t'as déjà répondu là dessus, j'insisterais pas.
Là où d'autres langage l'ont naturellement inclu dans la grammaire parcque c'est justement "standard". for_each est le parfait exemple d'un pattern courant qui a sa place dans la grammaire du langage. D'ailleur MS l'a compris et c'est dans leur cuvée du C++ 2005 (oui je sais c'est MS gnagna mais c'est pour l'exemple).
foreach est dans la lib à ma demande, de toutes façon, c'est une fonction qui prend 15 secondes à s'écrire. dans collection.
- foreach_do blk : BLOCK <-
(
1.to self.count do blc.value self;
);
Terminé.
Pourtant dans Java ils ont parfois laisser un peu trop de "liberté" au programmeur : les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Mais arrête de prendre les gens pour des cons !!
Je comprend ce point de vue même si je ne le partage pas du tout :) Pour moi on n'est plus à la course aux performances, on doit de plus en plus faire face à des logiciels de millions de lignes de code, et ce qui prime à mon goût c'est la qualité. Empêcher le programmeur de faire des conneries est pour moi une première étape dans la recherche de qualité. Mais bon chacun ses objectifs hein ;)
Je suis totalement d'accord avec toi, 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.
Oui mais encore faut il que les API soit exprimable en Lisaac et soit exploitable dans un autre langage, qu'il n'y ai pas de conflit dans les environnements d'exécution, etc. Et ca doit être réfléchi dès le départ., c'est pas forcement une "simple évolution".
Je te signale que tu as un exemple de code plus haut bourré d'Inline en C...
Tu inline ton C dans le code tout simplement, et le compilateur le pose dans le fichier généré.
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 non désolé mais dans la news on me parle uniquement de remplacer le C, on me propose des bench avec le C, etc.
C'est un de ses intérêts, mais pas le seul.
Pour 50 % de gains de productivité, perdre 2% en vitesse, c'est vraiment peanuts.
Moi j'essai de montrer qu'un langage ne doit (et n'est plus) pensé comme une simple grammaire : c'est un ensemble comprennant une grammaire, un environnement d'exécution et une bibliothèque standard. Lisaac l'a bien compris puisqu'il propose tout cela. C'est un ensemble indissociable, et ce que tu appels "une petite bête", moi j'appel ca des points essentiels qui peuvent influencer la conception même du langage.
Chaque chose en son temps.
On conçoit le compilateur, mais on peut aussi travailler sur la lib, la doc, etc...
De toutes façons c'est indépendant.
Oui mais voilà, moi j'aurai aimé qu'on me le présente justement comme un langage de recherche avec des concepts innovant (les prototypes). Et plutôt que de raconter que ca va "sans doute remplacer le C" j'aurai préférer qu'on m'explique ce que les prototypes apportent et ce que le compilateur peut apporter comme technique, mais là c'est top-secret-breveté. Désolé mais c'est décevant, Je n'ai obtenu aucune info sur ces parties innovantes à part que c'est "top-secret". Génial quoi.
C'est vrai que les centres d'intérêts prioritaire de nicO transparaissent dans cette news.
Pour le reste on t'a expliqué ce que ça apporte (voire mon dernier post de tout à l'heure, tout en bas).
Pour l'objet à prototypes, je te renvoi en aux transparents sur le site, ainsi qu'au manuel d'utilisateur.
La différence entre le proto et la classe,c'est que le prototype est vivant à l'exécution et se clone, tandis que la classe s'instancie.
Cela signifie que lorsque tu dit B hérite de A. L'instance de B est objet unique, un mix de A et B. Tandis qu'en prototypes A et B restent deux objets indépendants, ils peuvent avoir une existance physique séparée en mémoire (Pagination, voir segmentation par objet avec pour chacun leur zones de code, de donnée et leur pile à eux).
Cela signifie que tu peux changer de parents à l'exécution car les objets sont indépendants entre eux.
De plus Lisaac permet de jouer avec les opérateurs '-','+','*' que tu met avant chaque slot, cela permet des subtilités très poussées dans le partage des variables entre enfants d'un parent, la possibilité d'embarquer des méthodes, comme en Java/C++/etc.. et plein de choses qui sont expliquées pas très clairement dans le manuel.
Un des gros challenge futur, c'est de faire ue doc pour expliquer tout ça, parce que c'est très puissant.
[^] # 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.
Oué sauf qu'au final c'est :
- moins performant que du C (ils l'ont montré)
Qu'en sais-tu ? Pour le moment, le compilateur crache du code légèrement mois rapide que du C, mais peut être que celui-ci sera plus rapide bientôt ?
Je crois beaucoup aux optimisations de gestion de la mémoire, à la réécriture de boucle, etc...
- pas spécialement plus maintenable que le comme je l'ai montré : pas de reflexion sur l'intégration avec l'existant, pas de reflexion sur le versionning ou les outils de documentation, une trop grande liberté dans les constructions, etc.
Ce langage date de deux ans, et depuis deux ans son auteur a pas eu le temps de faire grand chose (post-doc, cours à la fac, etc...).
On débute ! On est pas SUN ni Microsoft ! Laisse nous le temps de lister, réfléchir à tout le travail qui doit être effectué à ce propos et de l'implémenter !
Quand à la trop grande liberté dans les constructions, je vois franchement mal un type décidé d'utiliser autre chose que le if.
On t'as déjà répondu là dessus, j'insisterais pas.
Là où d'autres langage l'ont naturellement inclu dans la grammaire parcque c'est justement "standard". for_each est le parfait exemple d'un pattern courant qui a sa place dans la grammaire du langage. D'ailleur MS l'a compris et c'est dans leur cuvée du C++ 2005 (oui je sais c'est MS gnagna mais c'est pour l'exemple).
foreach est dans la lib à ma demande, de toutes façon, c'est une fonction qui prend 15 secondes à s'écrire. dans collection.
- foreach_do blk : BLOCK <-
(
1.to self.count do blc.value self;
);
Terminé.
Pourtant dans Java ils ont parfois laisser un peu trop de "liberté" au programmeur : les méthodes sont virtuelles par défaut, si ca c'est pas du gros danger :)
Mais arrête de prendre les gens pour des cons !!
Je comprend ce point de vue même si je ne le partage pas du tout :) Pour moi on n'est plus à la course aux performances, on doit de plus en plus faire face à des logiciels de millions de lignes de code, et ce qui prime à mon goût c'est la qualité. Empêcher le programmeur de faire des conneries est pour moi une première étape dans la recherche de qualité. Mais bon chacun ses objectifs hein ;)
Je suis totalement d'accord avec toi, 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.
Oui mais encore faut il que les API soit exprimable en Lisaac et soit exploitable dans un autre langage, qu'il n'y ai pas de conflit dans les environnements d'exécution, etc. Et ca doit être réfléchi dès le départ., c'est pas forcement une "simple évolution".
Je te signale que tu as un exemple de code plus haut bourré d'Inline en C...
Tu inline ton C dans le code tout simplement, et le compilateur le pose dans le fichier généré.
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 non désolé mais dans la news on me parle uniquement de remplacer le C, on me propose des bench avec le C, etc.
C'est un de ses intérêts, mais pas le seul.
Pour 50 % de gains de productivité, perdre 2% en vitesse, c'est vraiment peanuts.
Moi j'essai de montrer qu'un langage ne doit (et n'est plus) pensé comme une simple grammaire : c'est un ensemble comprennant une grammaire, un environnement d'exécution et une bibliothèque standard. Lisaac l'a bien compris puisqu'il propose tout cela. C'est un ensemble indissociable, et ce que tu appels "une petite bête", moi j'appel ca des points essentiels qui peuvent influencer la conception même du langage.
Chaque chose en son temps.
On conçoit le compilateur, mais on peut aussi travailler sur la lib, la doc, etc...
De toutes façons c'est indépendant.
Oui mais voilà, moi j'aurai aimé qu'on me le présente justement comme un langage de recherche avec des concepts innovant (les prototypes). Et plutôt que de raconter que ca va "sans doute remplacer le C" j'aurai préférer qu'on m'explique ce que les prototypes apportent et ce que le compilateur peut apporter comme technique, mais là c'est top-secret-breveté. Désolé mais c'est décevant, Je n'ai obtenu aucune info sur ces parties innovantes à part que c'est "top-secret". Génial quoi.
C'est vrai que les centres d'intérêts prioritaire de nicO transparaissent dans cette news.
Pour le reste on t'a expliqué ce que ça apporte (voire mon dernier post de tout à l'heure, tout en bas).
Pour l'objet à prototypes, je te renvoi en aux transparents sur le site, ainsi qu'au manuel d'utilisateur.
La différence entre le proto et la classe,c'est que le prototype est vivant à l'exécution et se clone, tandis que la classe s'instancie.
Cela signifie que lorsque tu dit B hérite de A. L'instance de B est objet unique, un mix de A et B. Tandis qu'en prototypes A et B restent deux objets indépendants, ils peuvent avoir une existance physique séparée en mémoire (Pagination, voir segmentation par objet avec pour chacun leur zones de code, de donnée et leur pile à eux).
Cela signifie que tu peux changer de parents à l'exécution car les objets sont indépendants entre eux.
De plus Lisaac permet de jouer avec les opérateurs '-','+','*' que tu met avant chaque slot, cela permet des subtilités très poussées dans le partage des variables entre enfants d'un parent, la possibilité d'embarquer des méthodes, comme en Java/C++/etc.. et plein de choses qui sont expliquées pas très clairement dans le manuel.
Un des gros challenge futur, c'est de faire ue doc pour expliquer tout ça, parce que c'est très puissant.
Encore une fois, je te renvoi au manuel http://isaacos.loria.fr/download/Lisaac_RM_02.pdf
Tu auras quelques explications ici http://isaacos.loria.fr/download/lisaac_overview.zip
Et la grammaire est là : http://isaacos.loria.fr/li_docs.html
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker