Lisaac est le seul langage à prototype compilé. Il propose de bonne performance, tout en ayant des concepts de haut niveau. Il permet par exemple l'héritage multiple et dynamique. Il est suffisamment bas niveau pour faire un OS (isaacOS). C'est le grand écart entre smalltalk (et self ) et le C.
Après une léthargie apparente, le projet vient de sortir une version 0.39beta et un nouveau site web. Le but est de trouver les derniers bugs pour sortir une version stable 0.39 avant de partir dans de nouvelles fonctionnalités.
"On" essaye d'améliorer le rythme de sortie pour éviter d'avoir des troues de plus de 6 mois.
Lisaac est donc maintenant compatible 16, 32, 64 bits et non plus seulement 32 bits. La sortie est du C89 ce qui permet d'utiliser d'autre compilateur que gcc (pour l'embarquer par exemple).
Par rapport à la précédente version, on peut signaler un meilleur système de build : les .lip. Et encore une amélioration des performances avec de la gestion d'aliasing de structures. Le système de type est encore renforcé avec la couverture des derniers troues de typage comme les type block (en lisaac, il y a des slots qui sont indifféremment une donnée ou une méthode).
La syntaxe ne devrait plus être modifié, seul quelques ajout sont prévus pour le future.
Pour anticiper les remarques sur le langage, il faut savoir que sa syntaxe "étrange" est dû à la grande simplicité de sa grammaire. Celle-ci tient sur 30 lignes. Il est ainsi impossible d'avoir des "surprises", tout s'écrit toujours de la même façon.
Je signal la mise en ligne de présentation vidéo en français sur le sujet : http://www.lisaac.org/documentation/about
http://www.lisaac.org/
Bon visionnage/lecture/test !
Journal Lisaac: sorti de la 0.39beta
30
nov.
2009
# C89
Posté par barmic . Évalué à 4.
Le C99 est plus compliqué à générer ? Il y a moins de compilateurs qui le gère ?
Ne serai-t'il pas intéressant de passer par llvm qui est, il me semble, relativement souple de se point de vu ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: C89
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
llvm n'est pas aussi performant que gcc et moins universel. Donc pourquoi s'embéter ? De plus, il compile du C89.
"La première sécurité est la liberté"
# Under construction
Posté par dinomasque . Évalué à 5.
Y'a pas encore de doc sur le site, mais de belles images "under construction" qui fleurent bon le web qui savait prendre le temps de vivre de 1997 :)
(forcément à l'époque il n'y avait pas encore le Pentium III pour accélérer l'internet multimédia).
BeOS le faisait il y a 20 ans !
[^] # Re: Under construction
Posté par Antoine . Évalué à 1.
[^] # Re: Under construction
Posté par ʭ ☯ . Évalué à 4.
MMX c'était marketé pour les Jeux.
Le Pentium III c'était l'arrivée de SSE, soit la réponse au 3Dnow! d'AMD, qui était lui-même un MMX qui sait faire du flottant.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Under construction
Posté par hsyl20 (site web personnel) . Évalué à 4.
[^] # Re: Under construction
Posté par Larry Cow . Évalué à 5.
[^] # Re: Under construction
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# Surprise
Posté par Antoine . Évalué à 6.
Un peu comme en Lisp quoi... Après, chacun jugera si cette absence de « surprise » n'est pas en soi une mauvaise surprise.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Yusei (Mastodon) . Évalué à 10.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Mais tout cela est déjà écrit dans le journal.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Yusei (Mastodon) . Évalué à 8.
Je ne dis pas que tu as tort, simplement que pour un néophyte tout ça n'est pas très parlant.
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 6.
C'est aussi expliqué dans la vidéo.
Les données au même niveau que le code implique que tu peux écrire une fonction foo, qui à la fin de son exécution, lorsque que le calcul est effectué devient une données avec le résultat.
Ca évite de gérer des booléen pour savoir si ça a déjà été calculé, ça permet de gérer des système de cache aisément, etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Antoine . Évalué à 3.
Hum oui et quand tu as plusieurs threads qui exécutent la fonction en même temps, c'est quel résultat qui est pris en compte ?
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Un même proto ne peut pas écrire dans 2 threads différents. En gros, si tu refiles à un proto en paramètre à un autre thread il devient read only.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Surprise
Posté par patrick_g (site web personnel) . Évalué à 3.
Je n'y connais rien mais l'article wikipedia dit que le langage ActionScript est aussi un langage à prototype qui peut être compilé.
Vrai, pas vrai ?
[^] # Re: Surprise
Posté par ɹǝıʌıʃO . Évalué à 5.
[^] # Re: Surprise
Posté par kowalsky . Évalué à 3.
Sinon, javascript aussi c'est du prototype.
[^] # Re: Surprise
Posté par ɹǝıʌıʃO . Évalué à 4.
Et il y a un compilateur de Javascript qui produit du code natif ? Une recherche rapide ne me donne que la solution d'utiliser un outil de traduction de JS vers Java, et appeler gcj sur le résultat. Alors techniquement on obtient du code natif, mais bon… bof.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 6.
Ou alors t'utilises TraceMonkey, le moteur JavaScript de Mozilla, qui fait de la compilation en code natif à la volée.
Ou alors t'utilises JScript.NET une implémentation pour .NET qui se compile donc également en code natif (à la volée ou même avant) avec l'utilitaire NGEN.
En fait Lisaac est tout sauf le premier langage à prototype compilé.
[^] # Re: Surprise
Posté par ɹǝıʌıʃO . Évalué à 2.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Ensuite j'ai pris soin de mettre un exemple qui produit un fichier exécutable avant l'exécution : JScript.NET + NGEN. Ce qui montre qu'on peut aussi se passer de JIT.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
De plus, javascript n'est pas un vrai langage à prototype mais je ne serais plus dire pourquoi :)
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 3.
Tu ne lit que la moitier des commentaire auquels tu répond ?
Ensuite j'ai pris soin de mettre un exemple qui produit un fichier exécutable avant l'exécution : JScript.NET + NGEN. Ce qui montre qu'on peut aussi se passer de JIT.
Je croi qu'on ne peut pas être plus clair :
lisaac --> c89 --> code natif
jscript.net --> code intermediaire --> code natif
Et dans les deux cas sans JIT, donc c'est exactement la même chose.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"Ngen.exe crée des images natives, lesquelles sont des fichiers qui contiennent le code machine spécifique au processeur compilé et les installent dans le cache des images natives sur l'ordinateur local. Le runtime peut utiliser à la place des images natives du cache à l'aide du compilateur juste-à-temps (JIT) pour compiler l'assembly d'origine."
Si je comprends bien la mauvaise traduction de msdn, le runtime est toujours présent.
Je serais curieux de voir la taille de ses images.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Qu'il y ait un runtime ou pas, le code obtenu est du code natif qui va être exécuter directement sur le processeur sans passer par la case JIT.
Je ne comprend pas pourquoi ça te gène autant d'admettre que tu as fait une petite erreur dans le journal en disant que Lisaac est le premier langage à prototype compilé. D'autant qu'il y avait déjà une erreur dans le fait de ne pas préciser "compilé en code natif".
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Tu ne peux pas comparer la taille d'un runtime C avec celui de .NET.
C'est facile pour n'importe quel jit de sauver les parties de binaires converti. Il reste tout de même une énorme part d'interprétation. C'est obligatoire par exemple pour garder fonctionnel tous les mécanismes de sécurité, si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 1.
Il reste tout de même une énorme part d'interprétation.
Non non non et non ! .NET a été conçu dès le départ (contrairement à Java) pour faire exclusivement de la compilation (JIT ou AOT) sans interprétation.
Il n'y a pas de phase d'interprétation, uniquement de la compilation.
si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut.
Non non non et non ! Le code ne fait pas ce qu'il veut, parcque justement le compilateur du langage initial (C#, VB ou JScript ou cequetuveux) cible une machine "virtuelle", qui défini un modèle de sécurité précis. C'est tout l'intérêt de la machine virtuelle. Le compilateur doit générer des instructions dans un langage intermédiaire, il ne peut pas générer directement de code machine, il ne fait donc pas ce qu'il veut.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour la partie compilé, j'aime beaucoup comment il rende le code "rapide" : il change le langage !
The other major performance improvement added to JScript .NET is the introduction of Option Fast. This option tells the compiler to enforce certain rules that allow additionally optimizations, at the cost of some reduced functionality. When Option Fast is enabled, the following JScript behavior is activated:
* You must declare all variables.
* You cannot assign values to, or redefine, functions.
* You cannot assign to, or delete, predefined properties of the built-in JScript objects.
* You cannot add expando properties to the built-in objects.
* You must supply the correct number of arguments to function calls.
* The arguments property is not available within function calls.
The new Option Fast feature helps you write faster code, but it does change the behavior of the language—so just adding Option Fast to an existing JScript program may result in one or more compiler errors. Nevertheless, with some small changes to your program, you should see some significant performance improvements.
Il n'y a pas de phase d'interprétation, uniquement de la compilation.
Je veux bien une source. Car cela m'étonnerait qu'un .NET soit entièrement compilé avant utilisation, ce qui aurait des startup time catastrophique (ou des performances catastrophiques).
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Oui c'est exactement ce que j'ai dis : le langage utilisé par le développeur cible obligatoirement une VM. Mais derrière il y a compilation en langage natif (x86 ou autre), et c'est ce dernier qui est exécuté. Il n'y a pas d'interprétation du langage intermédiaire.
Je veux bien une source. Car cela m'étonnerait qu'un .NET soit entièrement compilé avant utilisation, ce qui aurait des startup time catastrophique
2 modes :
- JIT : compilation faite en "live" lorsque le runtime rencontre du "nouveau" code. Donc oui, ca a un impact au début de l'exécution du programme, on parle de démarrage "à froid". Généralement c'est pas génant, si ca l'est, on passe dans le mode suivant :
- AOT : avant (typiquement pendant l'installation du programme) : l'image en code "natif" est conservée dans un cache du système.
Mono propose la même chose, tu peux regarder la doc par ici :
http://www.mono-project.com/Mono:Runtime
[^] # Re: Surprise
Posté par thedude . Évalué à 7.
D'un point de vue purement theorique, oui, tu peux compiler ton code javascript vers un code machine qui va faire ce que tu veux.
Va bien falloir si tu veux le faire tourner sur un processeur de toutes facons.
Apres, si JavaScript (et pas un langage derive de JavaScript, du javascript quoi), est compilable en code natif, donne moi le code natif (archi de ton choix), du bout de code suivant:
var x=5;
eval("var z=5");
eval("x+=z");
alert(x);
Et encore, je suis gentil, les parametres d'eval sont des constantes, ton compilo js pourrait etre assez malin pour derouler le contenu d'eval (mais bon courage pour implementer ca de facon semantiquement correct, genre redeclaration de variable qui doit generer une erreur runtime et non a la compilation et tout ce genre de joyeusete).
Rajoute les closures par dessus toutes ces joyeusete, tu vas t'amuser.
Mon petit doigt me dit que tu vas devoir embarquer un bout de code natif tellement gros qu'on pourra aisement qualifier ton binaire de VM compilant un code inexecutable tel quel, et donc le placer dans la categorie des langages non compile nativement.
Apres, tu peux te limiter a subset du langage, comme Mono le fait si j'en crois le site web. Ca ne supporte d'ailleurs pas les generics, c'est ballot quand meme, ca fait un peu retour a java 1.4.
Reste apres le pignolage pour savoir ce que compiler veut dire, par opposition a compiler nativement, qui qu'est arrive le premier et qui qu'a la plus grosse, je ne m'aventurerais pas sur cette pente savonneuse. Sauf pour la plus grosse, c'est moi bien evidemment.
Personellement, dans le contexte, j'ai compris ce qu'il voulait dire, mais c'est surement aussi parce que je connais deja lisaac et que je sais qu'en vrai, ca genere du C derriere, donc j'ai naturellement fait l'association compiler = compiler nativement.
Toujours est il que certain langages sont par nature tres dynamiques et leur execution de facon semantiquement correcte ne peut se faire qu'en compilant a la volee leur code.
JavaScript en fait partie.
D'aucuns considerent qu'une compilation a la volee en prerequis exlue d'emblee pour le qualificatif "compilation native", et quelque part, c'est dur de leur donner tord.
Apres, ca veut pas dire que le code compile, c'est du code de tatoue, de dur, de vrai, avec des couilles grosses comme des pasteques et que le bytecode c'est pour les tapettes ne pouvant se passer de leur flexi felix.
Allez, pti bisou la?
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à -1.
Le but était de trouver un langage à prototype compilé. JScript.NET en est un, il est compilable, CQFD.
donne moi le code natif (archi de ton choix), du bout de code suivant:
Super, je vais pas te donner tout le code généré par le compilateur.
Mais si tu regardes l'implémentation de eval dans Microsoft.JScript.dll tu verras qu'il génère dynamiquement du code IL (bycode donc). Ce bytecode est traité après de manière classique par le CLR, et donc compilé en code natif à la volée avant exécution.
Mon petit doigt me dit que tu vas devoir embarquer un bout de code natif tellement gros qu'on pourra aisement qualifier ton binaire de VM compilant un code inexecutable tel quel, et donc le placer dans la categorie des langages non compile nativement.
Oui, celà nécessite un runtime qui s'occupe d'implémenter eval, n'en reste pas moins que le code est tôt ou tard compilé en code natif avant exécution (plutôt tard pour le cas de eval).
Apres, tu peux te limiter a subset du langage, comme Mono le fait si j'en crois le site web. Ca ne supporte d'ailleurs pas les generics, c'est ballot quand meme
2 choses :
- cette limitation s'applique à l'AOT pour Mono 2.0. En mode JIT, qui reste de la compilation sans aucune interprétation, les generics sont totalement supportés.
- cette limitation n'existe plus dans les version plus récentes, Mono 2.0, c'est vieux.
mais c'est surement aussi parce que je connais deja lisaac , ca genere du C derriere, donc j'ai naturellement fait l'association compiler = compiler nativement.
Bah oué tu vois j'ai fais le même raisonnement que toi : c'est sûrement aussi parcque je connais déjà JScript.NET, ca génère du code IL derrière, donc j'ai naturellement fait l'association compiler = compiler nativement.
D'aucuns considerent qu'une compilation a la volee en prerequis exlue d'emblee pour le qualificatif "compilation native", et quelque part, c'est dur de leur donner tord.
Le but de la compilation à la volée est avant tout de produire du code natif exécutable, c'est quand même extrêment osé de dire que la technique de JIT n'est pas de la compilation native.
Faut pas déconner, c'est dans le premier paragraphe de la définition de JIT sur Wikipedia :
" It converts code at runtime prior to executing it natively, for example bytecode into native machine code. "
Ensuite le soucis vient d'une fonction, eval. Aucun doute que si Lisaac avait l'équivalent ils n'auraient d'autre choix que de faire de la compilation à la volée.
En fait il aurait fallu remplacer :
Lisaac est le seul langage à prototype compilé.
par
Lisaac est le seul langage à prototype compilé en code natif statiquement avec exécution qui n'offre pas de fonction de type eval.
[^] # Re: Surprise
Posté par thedude . Évalué à 1.
Je sais bien, c'etait une question rethorique.
Tu sais tres bien qu'il faut embarquer un compilateur pour ca, c'etait juste une facon (certes qq peu trollesque) de le faire remarquer.
Ce bytecode est traité après de manière classique par le CLR, et donc compilé en code natif à la volée avant exécution.
Oui, je suis pas idiot et je me doute bien que c'est comme ca qu'il fonctionne, MS a une VM plutot bien gaulee, ca serait dommage de pas l'utiliser.
Oui, celà nécessite un runtime qui s'occupe d'implémenter eval, n'en reste pas moins que le code est tôt ou tard compilé en code natif avant exécution (plutôt tard pour le cas de eval).
Oui, j'ai fait la meme remarque (et pour eval, c'est meme tres tres tard, puisque semantiquement tu ne peux pas compiler avant d'arriver sur l'appel. Mais c'est pas ce qui est important aussi).
On pourrait aussi dire la meme chose pour un langage interprete: au final, ca va tourner sur le processeur, ya donc du code machine qui est genere d'une facon ou d'une autre.
Tu n'oserais pas pretendre pour autant qu'un langage interprete est compile?
Pour une implem vraiment bateau d'un langage interprete, c'est effectivement pas compile, mais quiconque de cense va implementer un cache pour pas reinterpreter la meme focntion en permanence, et tu te retrouves donc avec une generation de code, aka compilation.
Ce que je veux dire c'est que l'argument: au final, on genere du code machine pour l'executer, donc c'est compile un peu biaise, tu vas necessairement devoir generer du code machine a un moment ou un autre, sinon ton bout de code, il va pas te servir a grand chose.
2 choses :
- cette limitation s'applique à l'AOT pour Mono 2.0. En mode JIT, qui reste de la compilation sans aucune interprétation, les generics sont totalement supportés.
- cette limitation n'existe plus dans les version plus récentes, Mono 2.0, c'est vieux.
Oui, je me doute bien, j'ai pas precise dans mon commentaire, mais je n'ai jamais doute un instant que MS ne supportait pas ca, donc pas de raison que mono ne puisse le faire.
Ensuite le soucis vient d'une fonction, eval. Aucun doute que si Lisaac avait l'équivalent ils n'auraient d'autre choix que de faire de la compilation à la volée.
Certes, mais eval fait partie de javascript. Supporter tout javascript sauf eval, c'est supporter un subset de javascript. Si tu peux pas supporter eval en natif, tu ne supportes pas JavaScript en natif, juste un subset.
Tres honnetement, ca me derangerais pas plus que ca, je trouve ca heretique de pouvoir executer du code qui vient de n'importe ou, mais ca reste un truc qui fait partie du langage.
Bref, au final, tout ce long thread vient, je pense d'un probleme tout con: vous avez l'air de considerer qu'il n'y a que 2 type de langages: compile ou pas.
Tu vois mono comme compile, vu qu'il y a une phase de compilation. On peut pas dire que t'as tord, mais on peut pas dire que t'as raison non plus.
Il voit mono comme non compile, vu qu'il target une archi qui n'existe pas, et que le bytecode est de trop haut niveau pour etre considere comme du code machine. On peut pas dire qu'il a tord, mais on peut pas dire qu'il a raison non plus.
Bref, le probleme c'est peut etre qu'il faut introduire une troisieme categorie, ce qui nous laisse avec:
- interprete
- langage a VM
- langage compile.
Auquel cas, lisaac serait le premier langage compile a prototype, mais il s'est fait grille la politesse par les langage a VM a prototype.
[^] # Re: Surprise
Posté par thedude . Évalué à 1.
Auquel cas, lisaac serait le premier langage compile a prototype, mais il s'est fait grille la politesse par les langage a VM a prototype.
en fait non, il s'est meme fait griller la politesse par les langage compile a prototype, vu que si j'ai bien suivi, jscript.net sans l'utilisation d'eval peut compiler AOT et ne pas utiliser de generation de code en runtime?
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
les langages interprétés tel que les premiers basics par exemple. L'interpreteur va lire lire une instruction dans le langage source et l'interpréter avant de passer à la suivante. Le code n'est jamais compilé et cela à pour conséqueces par exemple que l'éxecution du programe commence très rapidement, mais qu'elle est très lente, et qu'une erreur de syntaxe à la ligne 243 ne sera détectée que si cette ligne est éxecutée.
les langages compilés en code natif dans ce cas le code est transformé en code natif pour un processeur donné. On peut faire plein d'optimisation spécifiques mais c'est pas ortable, mais surtout on obtient un binnaire directement utilisable en général, avec souvent des dépendance à des libs externes qui peuvent contenir un runtime.
les langages compilé pour une VM ou la compilation cible une architecture virtuelle. Dans ce cas, on obtient pas un executable indépendant mais un code qui va être executer par une machine virtuelle qui doit être distribuée avec le programme. Cette machine virtuelle va éxecuter des instruction particulière mais ces instruction ne seront jamais transformées en code natif.
En gros, ces 3 la correspondent au 3 catégoreis que tu donnais, mais ce qu'il faut bien voir c'est que il y a compilation dans les deux dernier cas. Ce qui donnait la première ambiguité de la phrase du journal. Mais on va pas s'étaler là dessus, je pense que tou le monde à copris qu'il parlait de compiler en code natif.
Le truc c'est que entre le 2 et le 3 il y a d'autres étapes :
les langage avec JIT la le code pour la machine virtuelle est transformé en code natif au juste avant l'éxécution, donc on a du code pour une VM mais qui devient du code natif. Sans vraiment le dire dans le journal, il excluait ce cas là. Donc pour reformuler plus clairement la phrase du journal on en serait à «lisaac est le premier langage à prototype compiler directement en code natif sans jit». Là c'est déjà beaucoup plus discutable comme phrase. C'est un peu plus vrai (mais pas completement) mais considérer le JIT comme n'étant pas vraiment du natif car la conversion est faite tardivement, je suis pas sur que tout le monde sera d'accord, moi le premier, mais bon.
Il y a encore une autre catégorie :
les langage un peu mixte que je sais pas comment appeler Dans cette catégorie, il y a les langages dont le compilateur de base cible une VM, mais qui offre aussi un compilateur qui va de cette VM vers du code natif. C'est le principe par exemple du compilateur CLang du projet LLVM. Le compilateur CLang va compiler du C vers la machine virtuelle de LLVM. Ce code peut ensuite être interpreter avec même du JIT, il y a tout ce qu'il faut pour ça dans le projet, mais surtout il peut être compiler vers du code natif, ce qui est le principal interet. Je pense que personne ne prétendra qu'un binnaire produire par CLang n'est pas compilé en code natif.
Et le problème est là... Il y a une implementation de javascript dans .net qui cible une VM et qui offre un compilateur qui traduit le code de cette VM vers du code natif. Donc ça devient dur de modifier la phrase de départ sans qu'elle deviennent ridicule.
Donc on a bien un autre langage «à prototype» compiler vers du «code natif». Histoire de ce rattraper à des branches mortes, on peu encore critiquer les deux choses que j'ai mise entre guillemets.
- Est-ce que javascript est un langage à prototypes ? Personnellement, j'ai trouvé beaucoup de source sur internet avec des gens plus ou moins serieux qui le prétendent. Il n'y a que ici qu'on voit des personnes prétendre le contraire. Donc avant que je considère que ce n'est pas un langage à prototypes, il va falloir un peu argumenter.
- Est-ce que c'est vraiment du code natif ? Indéniablement oui, mais en cherchant bien, il y a une fonction qui est impossible à implémenter directement... la fonction eval en question...
Le problème c'est que, d'une cette fonction utilise le JIT donc, pour pas mal de personne ça va quand même rester du natif, mais on va faire comme si on avait pas vu.
Mais... si on enleve cette fonction, bien sur on a plus tout-à-fait du javascript, on peut appeller le résultat du jvscrpt. Donc on a du jvscrpt qui est compilé en code natif et qui reste un langage à prototype. La fonction eval n'est pas indispensable pour ça. (heureusement car sinon lisaac ne serait pas un langage à prototype...)
Petits exercices de réflexion :
- Lisaac ce sert, si je me souvien bien, de gcc pour compiler le code C qu'il génére. GCC passe, tout comme CLang par une représentation intermédiaire un peu différente mais qui restes une représentation sous forme un peu virtuelle du code que l'on pourrais vaguement interprété à l'aide d'une VM. Est-ce que ça veut dire que Lisaac n'est pas un langage compilé (au sens du journal ?)
- on peut reprocher à l'exemple du javascript de .net de ne faire la compilation que au moment de l'instalation en général. Si on oublit le fait que cette compilaion peut-être faite sur l'ordi du dev, on peut quand même ce demander si dans ce cas un programme compiler par clang en fichier .lm et transformer en code natif au moment de l'instalation est vraiment compiler au sens du journal. Ça voudrait dire que le gestion de paquet qui à été présenter il y a quelques temps dans un autre journal qui proposait justement de faire cela permettrait d'avoir une distrib ou la majoritée des composants ne sont pas compilés au sens du journal ?
Tout cela pour dire que le problème viens, d'une part de l'ambiguité de la phrase du journal. Ambiguité qui ne peut pas être levé sans rendre la phrase fausse. Et d'autre par de la mauvaise foi de son auteur qui ne veut pas admettre qu'il à été un peu vite dans son affirmation.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Evidemment qu'au final c'est du code machine qui s'exécute !
M'enfin faut arrêter, y'a 2 méthodes classiques pour y arriver : l'interprétation et la compilation. Ce sont 2 techniques bien distinctes, je vois pas pourquoi t'essai de les mélanger.
Pour une implem vraiment bateau d'un langage interprete, c'est effectivement pas compile, mais quiconque de cense va implementer un cache pour pas reinterpreter la meme focntion en permanence
Bah non, c'est comme ca qu'on marché pendant très longtemps les interpréteurs JavaScript dans les navigateurs. Jusqu'à l'arrivée (relativement récente) de la technique de JIT.
Ce n'est absoluement pas le fait de mettre en cache qui permet de passer de l'interprétation à la compilation. Refais tes TP de fac bon sang :)
Tres honnetement, ca me derangerais pas plus que ca, je trouve ca heretique de pouvoir executer du code qui vient de n'importe ou, mais ca reste un truc qui fait partie du langage.
On est d'accord :)
on genere du code machine pour l'executer, donc c'est compile un peu biaise, tu vas necessairement devoir generer du code machine a un moment ou un autre, sinon ton bout de code, il va pas te servir a grand chose.
Bah non, surtout pas : dans l'interpréteur, le code machine il est déjà présent... dans l'interepréteur.
C'est toute la différence avec la compilation dont le but est de traduire et de produire du nouveau code. C'est ce code qui est exécuté.
Regarde les problèmes qu'il y a sur l'iPhone : faire un interpréteur, c'est possible car il n'y a pas de création de nouveau code, juste interprétation. Utiliser un moteur JIT c'est pas possible, parcque par nature (c'est un compilateur), il génère du code, et l'OS de l'iPhone refuse catégoriquement d'exécuter ces nouvelles instructions. D'où la technique AOT pour contourner.
Je penses que t'as vraiment pas bien saisie la différence entre compilation et interprétation.
Il voit mono comme non compile
Non, il connaît juste pas Mono.
- interprete
- langage a VM
- langage compile.
Ridicule. Un langage est un langage, point.
Beaucoup de langages peuvent se compiler et s'interpréter. La présence d'une VM est une problématique différente.
Pour Lisaac, la VM c'est le langage C89, pour JScript.NET c'est le bytecode. Les 2 sont suffisament de haut niveau pour être portable.
Faut arrêter de tordre la réalité dans tous les sens pour essayer de lui donner en partie raison : la compilation est un concept qui existe depuis un bon moment en informatique, et il s'oppose classiquement à l'interprétation. Ces sont 2 techniques totalement différentes.
Les moteurs JIT n'efface en rien cette différence : ca reste avant tout des compilateurs car ils utilisent la technique de compilation et en aucune manière l'interprétation, ils sont juste conçus pour être très rapides afin bosser "en live".
[^] # Re: Surprise
Posté par thedude . Évalué à 3.
Je defend pas boulay, il troll comme un fou et le post de beagf plus bas sur l'ouverture de la communaute me parait tres pertinent a la lecture de ce fil.
Cela dit, meme si je saisi tres bien la difference entre interprete et jit, j'ai toujours tendance a faire une distinction entre jit et compile nativement. Le code compile nativement tourne tout seul. Le code a jit ne peut pas tourner sans un enorme bout d'autre code qui va se placer entre le cpu et le bytecode pour le transformer en code executable a la volee.
Meme si je trouve que l'approche jit est plus maline, souple et agreable pour le developpeur, ca n'empeche pas que ce sont des approches tres differentes, et qu'il est comprehensible de faire une difference entre compilation native et compilation bytecode.
Je sais tres bien que mettre du code interprete en cache n'est pas du jit, mais s'il ya cache, c'est qu'il ya une forme de compilation, non? Le texte est analyse lexicalement, syntaxiquement, puis semantiquement et transforme en tokens de haut niveau, token qui seront ensuite execute par l'automate de l'interprete, mais t'as une bonne partie de la chaine de compile qui est faite et cachee, donc l'un dans l'autre...
Les frontieres sont extremements floues dans ce domaine, c'est pourquoi j'ai du mal a accepter une vision tranchee (d'un cote comme de l'autre, tu noteras).
Et oui, j'ai tres bien saisi que le bytecode est targete pour une machine virtuelle (hence, le terme compilation), et que ta vm peut etre retournee sous forme de lib.
Ridicule. Un langage est un langage, point.
Beaucoup de langages peuvent se compiler et s'interpréter. La présence d'une VM est une problématique différente.
Un langage est un langage, certes, mais tu ne m'enleveras pas de l'idee est que chaque langage vient avec une philosophie.
Et cette philosophie inclue la chaine de compilation, interprete, bytecode ou natif pur.
Et ca inclue aussi le runtime de base du langage, et le fait de savoir si on peut faire confiance a une couche en dessous, qui va verifier que tu ne dereference pas un pointeur null, que t'as acces a tel api d'ecriture sur le disque qui va verifier tes droits et tout ce genre de connerie, couche qui s'appelle une VM, verifie la signature du code, que la version de la lib est la bonne etc.
Faire du java sans le rt.jar ni la jvm je vois pas franchement l'interet. Tu te tapes un langage ultra verbeux avec une semantique ultra limitee et peux expressive, avec une implem des generics inutilisable des que tu cherches a aller plus loin que List et tu doit en plus te taper tout les checks d'integrite pour pas que ton code explose en plein vol.
De meme pour les "libs" d'aop qui fonctionnent en manipulant en temps reel le bytecode, je doute que ca soit faisable decemment avec du code natif (ou en tout cas, j'aimerais bien voir comment).
Java, c'est un langage a VM, meme si la spec du langage en soit est techniquement decorrelle de la vm, mais je n'arrive pas a imaginer un seul interet a implementer le langage en dehors de la vm. De meme, j'ai jamais compris a quoi pouvait bien servir gcj (bon, ok, jvm pas libre tout ca, mais c'est plus le cas).
Certes, ta la lib de base, mais c'est quoi l'interet de perdre la portabilite pour des perfs sensiblement equivalentes?
C'est pareil pour C#, python, javascript et tout le tralala.
Javascript est designe pour tourne sur une VM. Un interpreteur etant une forme tres primitive (mais vraiment tres primitive) de VM, et vu que personne n'a utilise le js pour autre chose que de faire des bandeaux dans la barre d'etat, les navigateurs ont toujours eu une approche interpretation, c'est pas parce qu'il se sont reveille face a flex et silverlight et on sorti l'artillerie lourde de VM efficace que ca veut dire que le langage a un quelconque sens compile en code natif sans avoir de jit. Et si t'as du jit, t'as une vm en dessous, on retombe donc sur: js est un langage designe pour avoir une vm (primitive ou evoluee) en dessous.
Lisaac qui est designe pour etre execute de facon native.
Mais s'il est faisable d'ecrire un compilo lisaac qui target mono ou le bytecode de la jvm, personne ne le fera parce que ca n'a pas de sens.
De meme pour du C, compiler un langage aussi aride que C vers du bytecode et le faire tourner dans une vm, j'ai du mal a voir l'interet.
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Certes, ta la lib de base, mais c'est quoi l'interet de perdre la portabilite pour des perfs sensiblement equivalentes?
Tout dépend du point de vue. Il y a de très grandes quantités de code java disponible que tu n'as pas forcément envie de réécrire, mais en même temps tu en as peut-être rien à foutre de la portabilitée car tu es sur une plateforme figée : ton desktop par exemple.
Dans ce cas, avec gcj tu profites du code tout en ayant les avantages d'un code directement natif.
Il faut bien voir que la portabilité c'est un concept qui existe au moment de la difusion, mais beaucoup moins dans de nombreux cas d'utilisation. Quand on écrit du code on veut qu'il marche chez le plus de personnes possibles, quand on l'utilise on veut qu'il marche chez soit.
Une VM permet les deux mais un compilateur tel que gcj permet uniquement le deuxième. L'avantage c'est qu'il n'y a pas à attendre que la VM s charge ou que le JIT produise du code.
De meme pour du C, compiler un langage aussi aride que C vers du bytecode et le faire tourner dans une vm, j'ai du mal a voir l'interet.
Je pense que les créateurs de Ch ne soient pas d'accord avec toi, et leur bizness dure depuis un bout de temps donc leur clients ne doivent pas être d'accord non plus.
L'avantage de faire tourner du C sur une machine virtuelle c'est que tu éxectues le code dans un environement sécuriser et tu peut inclure l'interpreteur dans un autre programme.
Et comme pour au dessus, du dispose d'une quantité faramineuse de code déjà écrit.
Mais s'il est faisable d'ecrire un compilo lisaac qui target mono ou le bytecode de la jvm, personne ne le fera parce que ca n'a pas de sens.
Et pourtant si, ça aurait un sens. Le programme gagne les avantages de l'environement managé de .net ou de la jvm, et des facilitées de comunications inter langages. Cela permet aussi de cibler des plateformes ou seul ce genre de code est accepté.
Sur android par exemple tu ne peut éxectuer que du code java, ça pourrait être cool d'avoir autre chose. L'exemple est mal choisit puisque c'est une JVM modfié et qu'ils ont sortit un NDK, mais l'idée est là.
Il faut bien voir que natif ou VM c'est des techniques complémentaires qui ont chacune leurs avantages et inconvénients, et à part certaines construction particulière il est généralement possible de ciber l'un ou l'autre indiférament. Disposer des deux est même un avantage pour un langage.
[1] http://www.softintegration.com/products/
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
la seule et unique différence, c'est que le compilateur JIT travail "en live" quand le compilateur classique (AOT) travail en amont. Mais le travail effectué est absoluement identique !
D'ailleur la commande AOT de mono qui permet d'obtenir un binaire exécutable n'est rien d'autre que l'appel vers le moteur JIT en lui disant que tout doit être compilé là maintenant tout de suite.
Ce que tu appels un "énorme" bout de code pour transformer en code natif, tu le retrouves pareil dans GCC comme l'a très bien expliqué beafg.
GCC est basé sur un frontend et un backend avec au milieu un langage intermédiaire qui est tout comme un bytecode : une représentation qui fait abstraction des spécificités de la machine cible, le backend se chargeant de traduire dans le code machine cible.
Il n'y a donc fondamentalement pas de différence entre GCC et le compilateur C#+compilateur mono.
Je sais tres bien que mettre du code interprete en cache n'est pas du jit, mais s'il ya cache, c'est qu'il ya une forme de compilation, non?
Un interpréteur ne met rien en cache, il interprête !
Un interpréteur c'est ça :
while(true)
var instruction = analyse_instruction_suivante(input)
switch(instruction.type)
case "add" : locale[instruction.res] = intruction.left + instruction.right
case "mul" : locale[instrction.res] = instruction.left * instruction.right
etc.
Bref, une boucle infini qui analyse chaque instruction et exécute l'action correspondante, il n'est pas possible de mettre de code en cache, tout ce que tu peux mettre en cache c'est l'analyse. Tu seras toujours obligé de te taper en "live" le switch, bref le code qui s'exécute c'est celui de l'interpréteur.
Tout l'inverse d'un compilateur, qui lui joue plutôt comme ca :
foreach(instr in extractInstructions(source))
switch(instruction.type)
case "add" : exe.append(tranlateAddToX86(instr));
case "mul" : exe.append(translateMulToX86(instr));
Un compilateur JIT ne fait ni plus ni moins la même chose, sauf qu'au lieu d'écrire le résultat dans un binaire, il l'écrit dans un cache et l'exécute.
L'interpréteur a un seul intérêt : il est extrêment simple et ne nécessite pas de connaître le langage machine sur lequel il tourne (forcement il n'en produit pas), il suffit juste que l'interpréteur soit lui même écrit dans un langage portable pour que le langage interprété le soit également.
Le compilateur en revanche, cherche à éviter à tout prix la phase d'interprétation coûteuse (le switch voir l'analyse) en effectuant une traduction en code machine. C'est beaucoup plus complexe, et c'est ce que font .NET et GCC.
Les frontieres sont extremements floues dans ce domaine
Elles sont floues dans ta tête :) Ce sont 2 techniques totalement différentes sans rapport, si ce n'est leur but.
mais tu ne m'enleveras pas de l'idee est que chaque langage vient avec une philosophie
certes.
Et cette philosophie inclue la chaine de compilation, interprete, bytecode ou natif pur.
Pour moi non :
Python a d'abort été un langage interprété, puis est apparu un moteur JIT.
JavaScript a subit la même destinée. Java également.
.NET marche avec un compilateur AOT ou un compilateur JIT mais peut aussi être interprété.
Tu peux coller GCC en sortie de mono. Tu peux coller mono en sortie de GCC.
Pour moi la phylosophie d'un langage c'est d'autres caractéristiques : typage fort, dynamique, syntaxe, prototype, objet,etc.
Après ses caractéristiques peut le rendre plus ou moins facilement compilable, c'est un fait.
Et ca inclue aussi le runtime de base du langage, et le fait de savoir si on peut faire confiance a une couche en dessous, qui va verifier que tu ne dereference pas un pointeur null, que t'as acces a tel api d'ecriture sur le disque qui va verifier tes droits et tout ce genre de connerie, couche qui s'appelle une VM, verifie la signature du code, que la version de la lib est la bonne etc.
Là encore, tu confonds plusieurs choses : runtime et VM.
Une VM, ce n'est ni plus ni moins qu'un ensemble d'instruction "virtuelles", un processeur virtuel. C'est la représentation intermédiaire pour le frontend GCC, c'est le C89 pour Lisaac, c'est le bytecode pour le compilateur Java, etc.
Le runtime, c'est l'ensemble des services/code nécessaires à l'exécution pour rendre concrêtement la sémantique du langage pour lequel il est prévu.
Le C a un runtime minimaliste, le C++ en a déjà plus élaboré (pour les exceptions ainsi que pour la vérification de type, optionnel), Java en a un beaucoup plus gros parcqu'il offre de nombreux services.
Tu peux très bien compiler du code C# en code natif qui embarque le runtime (c'est ce que propose mono pour développer sur iPhone grâce à l'AOT), comme le fait le compilateur C++ qui est linké avec le runtime C++. C'est strictement identique, les étapes sont les mêmes, le service "validation" de l'AppleStore n'y voit que du feu : c'est du code natif et rien n'est généré dynamiquement.
De meme pour les "libs" d'aop qui fonctionnent en manipulant en temps reel le bytecode
Ce sont des libs, pas le langage. Les libs n'ont qu'à pas faire trop de supposition sur le code qui s'exécute. Le contrat, c'est la VM, rien n'indique que le bytecode est disponible sous la forme de donnée à l'exécution.
Lisaac qui est designe pour etre execute de facon native.
On est d'accord, Lisaac peut être conçu pour être utilisé d'une certaine façon. En l'occurrence Lisaac a été conçu pour être compilé en targetant la VM C89 de GCC.
Idem pour JSCript.NET, il a été conçu philosophiquement pour targeter la VM CLI de .NET en reprenant la syntaxe ECMAJavascript.
GCC comme .NET propose la compilation en code natif, c'est strictement identique, à la différence que .NET propose la souplesse de le faire en amont (comme GCC) ou en live.
[^] # Re: Surprise
Posté par kowalsky . Évalué à 2.
la seule et unique différence, c'est que le compilateur JIT travail "en live" quand le compilateur classique (AOT) travail en amont. Mais le travail effectué est absoluement identique !Avec quand même la grande difference que le JIT "connait" l'état du systeme au moment de l'execution. ça permet des avantages en termes d'optimisation JIT.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
http://www.codeproject.com/KB/dotnet/clr.aspx
"The IL code is compiled to native machine and is not interpreted at all."
[^] # Re: Surprise
Posté par kowalsky . Évalué à 2.
* You must declare all variables.* You cannot assign values to, or redefine, functions.
* You cannot assign to, or delete, predefined properties of the built-in JScript objects.
* You cannot add expando properties to the built-in objects.
* You must supply the correct number of arguments to function calls.
* The arguments property is not available within function calls.
En même temps c'est un peu ce qui devrait tout le temps être fait, à part la dernière peut être, et encore, non ?
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
Ou alors tu peux aussi admettre que Lisaac n'est pas le "seul" langage à prototype compilé.
[^] # Re: Surprise
Posté par Moonz . Évalué à 3.
> * You must declare all variables.
Oui
> * You cannot assign to, or delete, predefined properties of the built-in JScript objects.
Peut toujours être utile pour du logging
> * You cannot add expando properties to the built-in objects.
String.prototype.rot13 = function() { … }
Oui, on peut faire autrement, mais cette méthode ne me semble pas absurde
> * You must supply the correct number of arguments to function calls.
Non, parce que c’est le seul moyen en javascript de faire les arguments optionnels
> * The arguments property is not available within function calls.
Non, parce que c’est le seul moyen en javascript de faire un nombre variable d’arguments (le va_args du C, *args du python…)
[^] # Re: Surprise
Posté par kowalsky . Évalué à 2.
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 4.
Quelle définition est-ce que j'ai changée ? En regardant bien je ne voit qu'une chose que j'ai changer par rapport au debut : on est passer de "compiler" à "compiler en code natif". Donc le seul changement est a ton avantage, et si on revient à la formulation d'origine, il n'y a même plus a discuter.
Tu ne peux pas comparer la taille d'un runtime C avec celui de .NET.
Je ne compare pas et je m'en bas les couille de leur difference de taille. Ça ne change absolument rien au fait que le programme est compiler en code natif, que ce soit par NGen a partir de code .net, ou par GCJ a partir d'un code java intermediaire.
C'est pourtant pas compliqué, et le fait de ne pas etre le premier n'enleve rien a Lisaac. Plutot que de defendre un truc indéfendable et qui ne lui apporte rien, il serait beaucoup plus pertinent d'essayer de mettre en avant les vrai avantage du langage. Se serait bien plus efficace que du pseudo intégrissme a deux balles.
C'est facile pour n'importe quel jit de sauver les parties de binaires converti. Il reste tout de même une énorme part d'interprétation. C'est obligatoire par exemple pour garder fonctionnel tous les mécanismes de sécurité, si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut.
Tu n'a pas vraiment compris le modele de securite de .NET. Le principe c'est tu as un code que tu compile pour un machine virtuelle. Ton code est valide pour cette machine et ne peut pas faire de conneries. Ensuite tu as un compilateur auquel tu fait confiance qui traduit ce code en langage machine en respectant la semantique definie par la VM.
Donc tu garde ton modele de securite. En general tu difuse le code pour la VM, et l'utilisateur a un compilo auquel il fait confiance sur ca machine qui, al'instalation, va verifier le code et le compiler.
Tu as donc bien du code natif qui est aussi securiser que le code VM. Bien sur le compilo n'est pas infaible, mais une VM non plus.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Si tu lit plus haut tu verra que le truc avec gcj est une connerie. Et concernant Javascript, il ne s'agirait pas d'un vrai langage à prototype. C'est pas de moi, mais du créateur de Lisaac, qui s'y connait plus que moi en langage et plus que toi aussi je pense.
Alors, je n'ai pas l'argumentation concernant le fait que javascript n'est pas un langage à proto mais dés que je l'ai, je la poste.
Sinon, j'ai très bien compris le modèle de sécurité de .NET, ne me croit pas plus bête que je ne lui suis. Si tu distribue tes binaires ngen.exe, tu as la même (absence) sécurité qu'un code C.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
T'es rigolo, tu débarque avec un journal, et la première phrase vente le fait que Lisaac soit le "seul" langage à prototype compilé. Forcement ca fait tilte et ca prête à critique. Surtout que le reste des nouveautés est pas spécialement excitant et ne prête pas à grosse discussion...
C'est pas de moi, mais du créateur de Lisaac, qui s'y connait plus que moi en langage et plus que toi aussi je pense.
Alors s'il le dit...
C'est vrai quoi, y'a les vrais langages, les langages des hommes quoi, et les autres, les langages de tapette.
Si tu distribue tes binaires ngen.exe, tu as la même (absence) sécurité qu'un code C.
Toutafé. Mais personne ne déploie le code généré par ngen. D'ailleur ngen va mettre l'exécutable dans un cache du système que si tu vas pas sur google tu risques même pas de le trouver, donc bon...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
C'est vrai quoi, y'a les vrais langages, les langages des hommes quoi, et les autres, les langages de tapette.
Dans "1er langage à proto compilé", il y a proto. Si javascript n'est pas un langage à proto, ce que tu étales depuis le début n'a aucun intérêt.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
On attend avec impatience de voir l'étendu des mise à jour que vous allez faire dans Wikipedia sur les articles concernant Javascript et les langages à prototypes.
Surtout dans la version anglaise rédigée dans la langue des américains et de ces atlantistes d'anglais.
[^] # Re: Surprise
Posté par allcolor (site web personnel) . Évalué à 3.
JavaScript est un langage de programmation de scripts principalement utilisé dans les pages web interactives. C'est un langage orienté objets à prototypeMaintenant pour la compilation native de celui-ci... oui c'est possible et oui ça doit trimballer un runtime et oui tout n'est pas compilé AOT (et ne peut l'être) à moins d'interdire eval.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je n'a pas trouvé d'argument fort sur le fait que JS n'est pas vraiment un langage à prototype à part le fait qu'il ne parle pas de slot mais de variable et de fonction modifiable à la volé (or il me semble que jscript l'interdit).Là j'ai une fonction de JS que l'on ne peut pas compiler complètement à cause d'eval().
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Je viens de dire (et j'ai vérifié) que dans le cas d'eval, le runtime JScript compile en bytecode qui est lui même compilé en code natif par le CLR (JIT). La dernière étape est l'exécution du code machine associé.
Même eval est donc bien compilable. C'est juste pas possible de le faire de manière statique avant de lancer ton programme. Mais c'est la nature même de la fonction qui veut ça.
En Lisaac t'auras exactement le même problème si tu veux fournir l'équivalent.
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 6.
J'étais revenu sur le journal histoire de voir ou vous en etiez, et voir si des sujets intéressants était apparus, et je m'apperçoit que tu cherches encore des branches ou te rattraper comme tu peux...
C'est quand même pas la mort d'admetre qu'on c'est trompé surtout sur un truc aussi insignifiant. Le problème de Lisaac, ce n'est pas le langage en lui-même qui, bien qu'ayant des défault, reste un truc sympa. Le problème, sur linuxfr en tout cas, c'est que les gens qui le défende donne vraiment l'impression que le langage ne vaut rien.
Quand je lis un journal comme celui là, tu commence par m'annoncer des trucs sympas sur les nouveautées et autres. Le ton fait «vendeur d'aspirateur» mais c'est le jeu, et il faut savoir lire entre les lignes. L'objectif étant quand même de vendre le langage. Mais quand je lit les commentaires et tes réponses, et sans vouloir généraliser, c'est souvent le cas dans les journaux sur lisaac ; à la moindre critique, un gros mur ce dresse, impossible de discuter.
Il y a une mauvaise fois flagrante quand on lit le thread qui fait que au final je ne retient qu'une seule chose de ce journal : «la comunauté autour de lisaac à toujours pas changé, pas la peine de retourner voir ce que donne le langage, j'ai mieux à foutre»
Si tu avais rapidement admis que en effet la formulation que tu as utilisée n'était pas bonne mais plus vendeuse. Et si à la place de troller tu avais expliquer ce que la manière de faire de lisaac de mieux. Peut-être donné quelques chiffres de perfs ou explqué pourquoi vous penser qu'une compilation native telle que vous la faite est mieux que celle de .net ou qu'un jit ; je serais partis en me disant : «c'est cool, ça bouge lisaac, faudrais peut-être que je retourne voir ce que ça donne»
Tu peut trouver le fait de considérer un langage en fonction de sa communautée débile mais c'est un fait : ça marche comme ça. Et pour deux raisons :
- tester un langage ça implique de prendre du temps pour regarder sa syntaxe, pour apprendre les base, passer un peu de temps pour porter un code à soit pas trop compliquer mais qui vaut le coup, pour voir réellement les perfs et si on se sent à l'aise avec le langage. Tout ça demande du temps, donc il faut donner envie au gens de prendre ce temps, et c'est à la communautée de le faire.
- un nouveau langage ne s'apprend pas du jour au lendemain, on a souvent des galère, besoins de conseil sur comment coder tel ou tel truc, bref toutes les petites choses au jour le jour avant de vraiment maitriser le langage, et pour tout ça il y a souvent besoin de l'aide de la communautée. Donc si des le début tu donnes l'impression que ça va mal ce passer, tu fait fuir tout le monde.
Si je prend mon cas, je programme principalement en C pour tout ce qui est code critique, mais le C n'est pas adapté pour une grosse partie du programme, donc il y a quelques années j'ai cherché un langage de script pour coder tout ce qui n'est pas critique et appeller mon code critique en C.
J'ai choisit Lua alors que je le connaissait quasiment pas et que je n'était pas super fan de la syntaxe, mais derrière il y avait une communauté très ouverte et très réactive. La mailing liste est très active avec un rapport sigal/bruit presque parfait. Les gens sont parfaitement conscient des limitations du langage et ne cherchent pas à les présenter comme une feature ou donner des arguments plein de mauvaise fois, il se contente d'expliquer pourquoi ces comme ça et d'expliquer si ça va changer à l'avenir ou quand passer outre.
Don pour conclure, bon courrage à votre petite communauté autour de lisaac, mais si vous voulez la faire grossir il va falloir faire des éfforts, et si vous préférez rester entre vous, ça sert à rien de poster des journaux à part le vendredi.
[^] # Re: Surprise
Posté par kowalsky . Évalué à 2.
Surtout que sur la phrase qui fait débat, tout le monde à raison. Se prendre la tête pour une phrase bidon et conclure de la qualité d'un projet sur ça, c'est un peu rude !
Aller, je vais faire un hello world pour la peine, en plus, lisaac est dans pkgsrc/wip/lisaac .
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 1.
Sur la phrase qui fait débat, tout le monde ne peut pas avoir raison. Soit Lisaac est le premier, soit il ne l'est pas, et de mon point de vue, on a amené uffisament d'éléments indiquant qu'il ne l'est pas.
Ce que je lui reproche n'est pas d'avoir eu tord au début, mais de ne pas l'admettre et justement d'avoir poluer son journal avec cette discution pas plus intéressante que ça et montrer ça mauvaise foi. C'est très typique des membres de la comunauté Lisaac qui s'expriment sur LinuxFR.
Je ne conclu pas que Lisaac est mauvais, ce que je conclus c'est que je ne retournerais pas voir ce langage vu la comunauté qu'il y a autour. Une comunauté est indispensable pour qu'un langage ce dévelope. Et vu que je n'ai pas trop de temps à perdre, je mefais une idée de la comunauté autour de Lisaac en regardant le comportement de l'échantillon que l'on à sur LinuxFR.
C'est très approximatif comme méthode, mais c'est réaliste. Des langages intéressants il y en a un paquet. Je n'aurais jamais le temps de tous les regarder en détail, donc tout ce qui me permet de faire un tri est bon à prendre.
C'est comme un DRH devant une pile de 500 CVs. Il ne peut pas tous les étudier en détails et convoquer toutes les personnes pour un entretien. Donc il fait le tri, un premier passage sur la pile et tous les CVs qui ont été fait à la rache avec de grosses fautes dans les titres, ça donne pas l'impréssion que le mec est serieux, donc direct à la poubelle. (on va pas entrer dans le débat des autres critères très discutables)
[^] # Re: Surprise
Posté par Littleboy . Évalué à 4.
[1] http://lists.alioth.debian.org/pipermail/lisaac-devel/2009-D(...)
[2] http://lists.alioth.debian.org/pipermail/lisaac-devel/2009-D(...)
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
- il confirme l'impression que donne Nicolas Boulay de la communauté Lisaac. Ce genre de ton dédaigneux et compatissant j'ai du mal ;
- il prouve que l'on a donné a Nicolas Boulay avant hier soir un debut d'argument (pas trés convaincant mais bon...) et qu'il n'a pas daigné le recopier ici.
[^] # Re: Surprise
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
"En javascript, tu fais la distinction entre variable et fonction"
Donc c'est pas un langage à prototype.
Où est le rapport avec la définition communément admise de langage à prototype ?
http://en.wikipedia.org/wiki/Prototype-based_programming
Aucun. Donc il défini lui même ce que lui considère comme étant un langage à prototype. Changer le sens commun d'un mot, c'est encore la meilleure façon de se donner raison.
En tout cas il a l'esprit aussi large que sa définition.
On va voir s'il a les couilles de modifier wikipedia ou s'il préfère garder sa science infuse pour lui.
[^] # Re: Surprise
Posté par kowalsky . Évalué à 5.
la preuve :
var minou=function (param) {alert(param)}
minou("miaou") ;
//ça affiche miaou
alert(minou) ;
//ça affiche
//function (param) {
// alert(param) ;
//}
//Aller, voici comment savoir si minou est une fonction
alert(typeof(minou) ;
//ça affiche function
Mais comme tu le dis, ça rien à voir avec ce qu'est le prototypage. Et de plus, c'est une méconnaissance de JavaScript cet argument, parce que la difference n'est pas si grande...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je n'ai pas l'argument qui tue concernant le fait que JS ne serrait pas un langage à prototype. J'ai bêtement cru et répété les dire d'un chercheur et docteur en informatique dont le sujet de thèse et de recherche est la compilation de langage à prototype qui a un certain nombre de publication sur le sujet.
Après si tu préfère croire la page wikipedia sur le sujet, elle même un peu contredite par la page qui décrit les langage à prototype, c'est ton problème.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Jb Evain (site web personnel) . Évalué à 1.
C'est évident que des langages comme Lisaac, Self ou io sont plus jusqu'au-boutiste que JavaScript. Ne serait-ce que parce que ce dernier ne prend pas avantage de son mécanisme de prototype pour les structures de contrôle.
Mais du coup il a le bon goût de rester facilement abordable et agréable à l'œil pour la masse de développeurs qui ont programmé dans un langage de la famille du C, contrairement à Lisaac qui me donne envie de me rentrer des fourchettes dans les yeux, outre ses qualités intrinsèques.
Par contre, le type system de JavaScript est basé sur les prototypes, que ça te défrise ou pas.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
contrairement à Lisaac qui me donne envie de me rentrer des fourchettes dans les yeux, outre ses qualités intrinsèques.
Tu trouve de l'ocaml ou du smalltalk plus lisible ?
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Jb Evain (site web personnel) . Évalué à 1.
Donc non je n'aime pas lire du smalltalk non plus (encore une fois, outre toutes ses qualités), mais je suis assez habitué à la syntaxe à la OCaml parce que je fais pas mal de F#.
Et pour en revenir à Lisaac, j'ai horreur de ses Section, et j'ai horreur que les types soit TOUT EN MAJUSCULE.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
On s'habitue à tout. C'est moche mais c'est super rapide pour trouver un type. Cela permet d'avoir une grammaire qui tient en 30 lignes, cela permet d'avoir zéro surprise.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Jb Evain (site web personnel) . Évalué à 0.
Mais va dire ça à ta copine quoi.
Moi perso, vu le temps que je passe devant des lignes de code, je préfère me trouver devant un truc que je trouve élégant aussi bien dans le concept que dans la forme.
[^] # Re: Surprise
Posté par Jb Evain (site web personnel) . Évalué à 2.
C'est aussi parce qu'ils l'ont sacrifié leur pureté pour pouvoir toucher le plus grand nombre de développeurs. Mais c'est une histoire de compromis, et quand c'est fait intelligemment, c'est bien, parce que ça permet d'exposer des concepts à des gens qui n'y auraient pas forcément été exposé forcément.
Je prends deux exemples que je connais bien, que je trouve intelligents et pourtant qui sont opposés, tout en ayant une chance de toucher du monde :
* C#, qui est parti d'un langage complètement Java-like, et qui maintenant a des possibilités de meta-programmation (avec les expression tree) et des possibilités fonctionnelles (delegates, extension methods et LINQ). Donc on part d'un langage bateau a quelque chose de finalement assez couillu.
* F#, en gros OCaml pour .net, mais qui a été adapté pour pouvoir faire de l'impératif. Et donc on a un excellent langage fonctionnel, qui a accès à tout un framework connu par plein de gens, qui vont avoir des facilités pour s'y mettre.
Alors que Lisaac débarque comme une fleur en ne ressemblant à rien de vraiment connu et en criant «ON DÉBOITE DES CACAHOUÈTES». Je dis pas, y a des excellentes idées dans Lisaac. Mais avant que ça se popularise...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Par exemple dans lisaac, une fois la syntaxe vérifié, tout appel de slot est un point de liaison dynamique, que cela soit un appel de méthode, une boucle, un if, tout. Résultat toutes optim portant sur les appels ou les boucles s'appliquent partout (traitement de la récursivité, inlining, etc...)
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Jb Evain (site web personnel) . Évalué à 1.
On est bien d'accord, vous avez un joli compilateur, pour un langage intéressant sur le fond. Ok ? Bon.
Et maintenant ?
Moi je dis juste, «je pense que ça ne risque pas de percer tel quel».
Et te voir courir après chaque critique en disant «si si si c'est génial», ça aide vraiment pas :)
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est le fait qu'il soit plus utilisé, qu'il est une lib plus grosse, que le code soit plus plus stable.
Je ne sais pas tes critères précis, mais c'est un langage de haut niveau qui a les perfs du C. Ce n'est quand même pas rien comme marché.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Ce que je te reproche, ce n'est pas de t'être trompé au départ, mais ton attitude gamine après qui à été de ne pas vouloire reconnaître qu'un truc clochait.
C'est simple, quand on te dit «si, si, il y a plein de gens fiable qui pensent que javascript est un langage a prototype et qui le disent sur internet» tu as trois choix valables :
- Tu va voir ta source et tu lui demande de bon arguments histoire de défendre son point de vue ;
- Tu va faire un tour sur le net (et pas que wikipedia) et tu vois que en effet plein de gens tout à fait respectables pensent le contraire, et tu admet ton erreur ;
- Tu refuse d'admettre que tu ais pus avoir tord mais tu as la flemme de demander au gourou des arguments, et dans ce cas la, vu qu'on est pas vendredi, tu fait le mort.
Depuis le debut tu ne fais qu'affirmer sans argumenter au contraire des commentaires qui te répondent, donc permet moi d'avoir des doutes sur ce que tu dis.
Ici encore : la page wikipedia sur le sujet, elle même un peu contredite par la page qui décrit les langage à prototype de quelle contradiction parle tu ? J'ai pas lu en détails, mais je ne vois pas vraiment de contradictions entre les deux.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
- Tu va voir ta source et tu lui demande de bon arguments histoire de défendre son point de vue ;
- Tu va faire un tour sur le net (et pas que wikipedia) et tu vois que en effet plein de gens tout à fait respectables pensent le contraire, et tu admet ton erreur ;
- Tu refuse d'admettre que tu ais pus avoir tord mais tu as la flemme de demander au gourou des arguments, et dans ce cas la, vu qu'on est pas vendredi, tu fait le mort.
J'ai répondu un peu coté, j'attendais les vrais arguments mais la personne en question répond peu au mail. Et c'est argument était faible (en gros, c'est que javascript n'est pas été conçu pour être compilé). Ensuite concernant faire un tour sur le web, tu tombes sur la page wikipedia. Et souvent sur des très trucs pointus, c'est pas la joie.
Et j'ai fait un peu le mort dégouté par ce qui intéresse les gens : polémiquer. Peut être que tu as rater d'autres news/journal mais c'est assez systématique, typiquement de la part de Timaniac qui essaye de démontrer par A+B que Lisaac ne sert à rien. Il essaye de le démontrer par tout les moyens, ils insistent sur la syntaxe ou des choix téchnique qui ne sont que des choix. Ils ne sont pas moins bon, ils sont autres : à quoi sert de faire comme tout le monde ?
Alors oui, on essaye de faire de la pub. Un nouveau langage, c'est dur à lancer, à avoir une taille critique. Alors quand on a un beau truc, qui se fait critiquer systématiquement sur la tronche du "if", c'est gavant. D'où mes réactions.
Le "gourou" communique peu. C'est pas son truc. Alors on le fait à sa place mais on est pas chercheur en labo. On a des boulots. Moi, je suis dans l'informatique bas niveau avec un back ground en microelec. Je suis loin des langages (même si ma boite en produit un).
Ici encore : la page wikipedia sur le sujet, elle même un peu contredite par la page qui décrit les langage à prototype de quelle contradiction parle tu ? J'ai pas lu en détails, mais je ne vois pas vraiment de contradictions entre les deux.
Cela a pourtant été pointer par d'autre, je pensais au message de mathieu ici :
http://linuxfr.org/comments/1087357.html#1087357
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
J'ai bien préciser, à la faois dans le message auquel tu répond et dans plusieurs autres sur cette page que je parlais bien d'aller voir ailleur que sur wikipedia : Tu va faire un tour sur le net (et pas que wikipedia)
Il y a beaucoup de gens tout aussi respectable que ta source qui pense que javascript est un langage à prototype.
Et j'ai fait un peu le mort dégouté par ce qui intéresse les gens : polémiquer. Peut être que tu as rater d'autres news/journal mais c'est assez systématique, typiquement de la part de Timaniac qui essaye de démontrer par A+B que Lisaac ne sert à rien. Il essaye de le démontrer par tout les moyens, ils insistent sur la syntaxe ou des choix téchnique qui ne sont que des choix. Ils ne sont pas moins bon, ils sont autres : à quoi sert de faire comme tout le monde ?
Les news et journaux sur Lisaac, j'ai du à peu près tous les voir et même participé à plusieurs d'entre eux, et c'est pour ça que je me suis permit de te donner mon avis sur ton comportement. Et je le maintient.
Tu dira ce que tu veux, mais sur ce journal, le plus obtus et trolleur, ça reste toi. La personne qui semble le plus vouloir dénigrer les autres langage, c'est toi. Ce n'est peut-être pas ton intention, mais c'est comme ça que moi je le perçoit, et ce qui est important c'est que c'est toi qui veut nous vendre quelque chose, donc c'est à toi de nous convaincre.
Alors oui, on essaye de faire de la pub. Un nouveau langage, c'est dur à lancer, à avoir une taille critique. Alors quand on a un beau truc, qui se fait critiquer systématiquement sur la tronche du "if", c'est gavant. D'où mes réactions.
Pour avoir une taille critique il faut attirer les gens, et pour cela il faut leur donner envie de tester le langage, et de rejoindre une comunautée. Donc tu commence par essayer de donner une bonne image des deux, pour cela on commence par ne pas dénigrer les autres langages. Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Le "gourou" communique peu. C'est pas son truc. Alors on le fait à sa place mais on est pas chercheur en labo. On a des boulots. Moi, je suis dans l'informatique bas niveau avec un back ground en microelec. Je suis loin des langages (même si ma boite en produit un).
Je passerai sur l'aspect gourou puisque ça plait à certains, mais le fait d'avoir un boulot ou de bosser d'en une autre branche n'empêche pas d'assumer ses conneries.
Être du domaine n'apporte qu'une chose, réduire les risque de dire des conneries, mais une fois qu'elles sont dite, quel que soit le context, c'est pas dur de les assumer.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je crois surtout que je vais arrêter de me stresser dans des querelles stériles, cela n'apporte rien du tout, et cela ne sert à rien. A te lire, cela desserre aussi le projet. Donc, je vais oublier linuxfr pour la suite de Lisaac, inutile de perdre le temps de tout le monde.
Je suis toujours intéresser pour comprendre les vrai besoins des utilisateurs de langage, cela m'a toujours passionner. J'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile). Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Tu critique Timaniac qui critique Lisaac, mais tu est le premier à en balancer des conneries sur tout ce qui n'est pas Lisaac...
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 3.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
'imagine que tu peux comprendre la différence entre "je ne peux pas avoir un temps de compilation de 10 minutes, vu que je passe mon temps à faire des build pour avoir des résultats intermédiaires à coup de printf() à l'ancienne", et "ton produit à compile global forcément lente est bon à jeter, je ne peux pas débugguer dessus". (je fais aussi du debug à coup de printf(), mais avoue qu'un outil plus costaux serait mieux, d'ailleurs souvent gdb rend la recompile inutile).
Le problème c'est qu'un debuggeur est très pratique pour certains type de bug, mais pas tous. Si je prend un cas que j'ai eu jeudi dernier. Je code un algo en C car la quantité de calcul est monstrueuse et j'ai besoin que ce soit relativement rapide.
Avant de faire l'implémentation en C, j'en ai fait une sous Octave qui m'a permis de le coder de manière très rapide et bien plus sure. La version sous Octave à été beaucoup plus simple à debugger, et je sais maintenant que le résultat qu'elle me sort est correcte même si elle y passe des heures sur de petites données d'entrée.
La version en C me sortait un résultat différent, donc il y a un bug. Pour débugger, j'ai sortit plusieur logs des différents calculs intermédiaires fait par la version en Octave. Dans ces log j'ai des matrices gigantesques, donc impossible de faire un gdb et de lui demander de m'afficher les matrice et de comparer à la main.
J'ai recompiler plusieurs version du programme en C, dans lequel je sort aussi des logs, pour trouver ou ce situe le problème et voir à quel endroit il y a une différence.
GDB est très utile quand tu as un bug bien localisé, c'est-à-dire, un bug ou tu peut mettre un point d'arret très près de l'enroit ou ce produit le bug, ou une surveillance sur une donnée quand tu sait qu'elle va prendre une valeur interdite. Mais dans mon cas, et je suis souvent confronter à ce genre de problème, ce n'est pas un segfault ou autre, le programme est parfaitement correct, c'est juste qu'il traite de grosse quantitées de donnée et ne fait pas le bon calcul sur certaines d'entre elles.
Il faut bien comprendre qu'il n'y a pas une seule bonne manière de debugger.
Je devrais utiliser la réponse classique en open source : "send me the patch !". :)
Et comme d'habitude, la réponse classique est à côté de la plaque ;-) Si tu veux nous vendre Lisaac avec comme argument «il ne fait que de la compilation globale parce que c'est meilleur pour les optims» il faut bien t'attendre à avoir des remarques sur le «que»...
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant... Et pour prouver que je suis de bonne foi, il y a eu une news qui m'avait même fait tester Lisaac. Je l'avais installer, porter si je me souvien bien, deux codes de calculs et donner les résultats en commentaire de mes petits benchs.
Je sais plus exactement les raisons qui m'avais poussées à ne pas continuer l'expérimentation (en dehors des nom de types en majuscules que je trouve imondes...) Mais à chaque fois que je vois une news sur Lisaac, je lit pour voir ce qu'il y a de neuf, et voir si ça vaut le coup de rééssayer, comme pour chaque nouveau langage, ou nouvelle version d'un langage.
Tu parles encore de Javascript ? Ou de lisp ? (pour info, lisp, c'était de l'humour)
Pour ce qui est de ce journal, je parlais de javascript, mais j'avais surtout en tête, l'impression qui ressort de l'ensemble des journaux et news sur Lisaac. Quasiment à chaque fois on à vraiment l'impression que seul Lisaac est un bon langage et que le reste est de la merde à vous lire.
C'est ça que je n'apprécie pas...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La première phrase est déjà un bon point ;-) Ce qui fait du mal au projet ce n'est pas d'en parler, mais de donner l'impression que tout ceux qui y participent sont des trolleur et de mauvaise foi. N'arrête pas d'en parler, mais soit juste un peu plus ouvert et moins trolleur.
Tu as l'air de dire que je suis l'origine des trolls, c'est tout de même rarement le cas. Je me contenterais du minimum.
Le jour ou l'on me prouvera que Lisaac est adapté à mes besoin, je changerais, en attendant...
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ? Il y a quelques temps j'avais poser des questions dans des journaux sur comment développer différentes applications, quel outils manquait, etc... A quelques exceptions prêt, les résultats n'allaient pas bien loin. C'est un peu le syndrome décrit par Ford: "si j'avais écouté mes clients, j'aurais fait des chevaux plus rapide".
C'est très difficile de connaitre les vrais besoins. Ton besoin n'est pas d'avoir un temps de compilation faible, par exemple. Ton besoin est de pouvoir être efficace dans la recherche d'erreur dans des équations. Cela peut se résoudre avec un temps de compilation rapide, ou cela peut se résoudre avec un système de trace, que j'ai toujours trouvé génial pour les applications écrite en VHDL ou Verilog: les systèmes de waveform. Ou encore avec un système de dimension sur les données, avec les assertions, etc... Il y a d'autres solutions, donc.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 1.
Toutafé. C'est bien pour ça qu'en général il est difficile de se contenter de demander aux utilisateurs ce qu'ils veulent. Ils faut le deviner, anticiper, proposer, attirer et parfois créer le besoin.
Le minimum, c'est de regarder l'état de l'art de ce qui se fait.
La plupart des environnements modernes proposent un feedback instantané au développeur : ca se traduit par des IDE qui propose coloration contextuelle, completion, compilation en arrière plan, deboggage avec modification du code en live, ca se traduit également par des langages s'utilisant principalement avec un interpréteur (je test en direct le code auquel je pense), etc.
Maintenant les utilisateurs sont habitués à ça, et ca va être difficile pour eux de revenir en arrière, même si vous proposez d'autres atouts.
Comme déjà dit, les assertions c'est gentil, mais encore faut-il savoir les écrire. Encore faut-il savoir quoi mettre dedans. Encore faut-il ne pas se tromper lors que l'on écrit ce que l'on met dedans. Encore faut-il que les specs que l'on implémente soient correct. Encore faut-il qu'on les est bien comprises.
Les environnements actuels sont pragmatiques : rien ne vaut une exécution pour s'assurer que ce que fait le programme semble correspondre au besoin de son (futur) utilisateur.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
C'est pour ça que dans tous les cas il ne faut pas ignorer le temps de compilation, les outils de déboggage, les outils de vérifications de code, les outils de test, les IDE, bref toute la chaîne de production. Et oui : la plateforme (langage+runtime+lib) doit être conçu dès le départ pour prendre en compte ces différents aspects, sinon c'est l'assurance d'avoir un joli truc bon pour le placard.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
M'enfin, c'est un peu de la déformation professionnel, les avions, c'est pas censé planter.
Alors évidemment, les assertions ne doivent pas être ignorer, elles sont complémentaires, mais elles ne remplacent en aucun cas le feedback de l'exécution.
Dis moi les projets sur lequel tu bosses, que je ne les utilise pas. Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
M'enfin, c'est un peu de la déformation professionnel, les avions, c'est pas censé planter.
T'es toujours aussi doué dans ton argumentaire : simple, efficace, une démonstration parfaite en quelque sorte.
Parce que se contenter de test exploratoire pour faire de la validation, c'est franchement léger.
T'es vraiment un mec hallucinant. Tout ce qui t'intéresse, c'est d'être en désaccord. Pour celà, ton cerveau ignore la moitié des mots que tu lis. Je te parle de "complémentarité" et tu réponds par "se contenter ". Où est-ce que j'ai dit qu'il fallait se contenter de tests exploratoire ???
Moi je suis un pro langage avec typage fort et statique, je suis un pro assertion, un pro tests unitaires, un pro tests tout-ce-que-tu-veux-pourvu-que-ca-pète-pas-a-lexecution, donc me fait pas dire ce que j'ai pas dit.
L'impression que tu donnes, c'est que la plupart des bugs sont vérifiables à l'aide du compilateur. Moi je te réponds en disant juste que la plupart des bugs se situe généralement entre la chaise et le clavier, et que le compilateur peut juste s'assurer que syntaxiquement et sémantiquement ce qu'a écrit le développeur est correct.
Le compilateur ne peut pas deviner ce que doit faire le programme. Les assertions peuvent l'aider à vérifier certains points, mais elles ne sont pas exhaustives et rien ne garantie qu'elles soient correctement écrites.
Et puis tout est une question de compromis : dans l'idéal on coderait tout avec une méthode de type langage B. Mais le coût de développement est "monstre" et à part faire rouler des rames de métro automatique ou piloter des centrales nucléaires, on n'utilise pas. Pourtant c'est génial niveau "validation" (bien que cette méthode ne résoud pas les problème d'interface chaise/clavier et les specs incorrectes, obsolètes, ou ne répondant pas au besoin). Parcque ca a un coût. Pareil pour les assertions, pareils pour les tests U, etc. Bref une plateforme de dev doit éviter de contraindre l'utilisateur dans un modèle prévis de développement : il doit avoir un minimum de liberté sur le coût qu'il souhaite mettre dans la validation et les tests.
Et puis avant la validation, y'a la phase de développement "pur", où l'on souhaite tester rapidement un algorithme ou tester un pattern particulier. Compile & Debug, 2sec après je vois le résultat de mon expérimentation.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Donc renseignes toi sur des logiciels comme "Prover", les générateurs automatique de pattern de test (ATPG), les techniques de back propagation que l'on retrouve dans les "Static Timing Analyzer" pour comprendre ce qui peut se faire statiquement.
Renseignes toi aussi les process induit pour les logiciels critiques comme la DO-178, IEC 61508 et la EN 50128, pour comprendre comment est censé se faire une spec.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Je ne connaissais pas les ref que tu pointes pour les specs, mais il faut se faire une raison : tu ne peux pas contraindre le développeur à porter tout l'effort de validation sur les assertions et autres techniques déclaratives.
Je comprends bien la pertinence que cela a pour le compilateur et les garanties qui peuvent en découler, mais celà a un coup qui est loin loin d'être négligeable.
Regarde un truc comme le kernel Linux : il ne suit absolument pas ces process de dev. On est d'accord, ca conduit à un soft probablement buggué de partout avec des failles dans tous les sens (suffit de voir les journaux récents sur le sujet), mais le logiciel rempli tout de même une bonne partie du rôle que ses développeurs ont décidé de lui accorder, et le succès est là.
Donc oui, tout déporter le travail de validation en amont, de manière formelle, avec vérification statique par le compilateur est pertinent, mais dans un cadre vraiment limité : contexte industriel avec de fortes contraintes de fiabilité/sécurité. Lisaac pourrait donc être pertinent dans ces contextes... quoique du coup tu auras du mal à convaincre également ces industriels pour qui les perfs (principal atout de Lisaac), c'est secondaire : faut d'abord que ca marche (TM).
Hors de ce contexte, y'a d'autres méthodes de dev largement moins coûteuses, qui n'offre pas la même "qualité" en terme de fiabilité/sécurité on est d'accord.
Voilà tout ca pour dire que ton évangélisme sur LinuxFR est voué à l'échec, tout simplement parcqu'on est pas le public d'utilisateurs cible, donc c'est assez logique que l'on trouve finalement plus d'inconvénients dans ce langage que d'atouts.
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 2.
L'info de gestion étant mon métier depuis pas mal de temps, je suis assez d'accord avec ce que tu dis, qui est pertinent pour l'info de gestion.
Mais, regardes un peu comment on développe des algos pour les moteurs d'avions (Nicolas nous a fait une pres sur le sujet, on peut te la passer s tu veux), ça n'a rien à voir.
Programmer pour de l'embarqué petit (genre des ARM à 16mhz et moins de 256 ko de mémoire), idem.
Ce sont de environnement, ou tu ne peux même pas mettre de code de debug dans ta cible, et où tu n'as pas forcément d'émulateur (sur ARM ça se trouve, mais sur d'autres archi...).
Donc, sur ce genre de cible, il vaut mieux que tout soit nickel à la compil.
Or, un des buts de lisaac, voire même sa cible principale, c'est la programmation système et embarqué. Donc les besoins ne sont pas les mêmes.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Ca doit être petit comme marché :)
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 2.
Regarde autour de toi tout ce qui peut comporter un micro-controleur.. Tiens je fais l'exercice là maintenant :
- Chaine Hifi (pour gérer les programmation, l'interface, les fonctions réveils, etc...)
- Télé
- Four, lave-vaisselle, lave-linge
- décodeur tnt, dvd, etc...
- Clim, chaudière
- Etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 1.
On parle bien de micro-contrôleurs et autre processeurs qui sont "ciblables" avec GCC hein...
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Tu ne les lance pa stous mais tu est très doué pour les entretenir.
Faudrait encore les connaître tes besoins :) De plus, es-tu sûr de vraiment savoir ce que tu cherches ?
Oui je sais ce que je cherche, mais le probleme c'est que tu as l'air de mieux le savoir que moi :
C'est très difficile de connaitre les vrais besoins. Ton besoin n'est pas d'avoir un temps de compilation faible, par exemple. Ton besoin est de pouvoir être efficace dans la recherche d'erreur dans des équations. Cela peut se résoudre avec un temps de compilation rapide, ou cela peut se résoudre avec un système de trace, que j'ai toujours trouvé génial pour les applications écrite en VHDL ou Verilog: les systèmes de waveform. Ou encore avec un système de dimension sur les données, avec les assertions, etc... Il y a d'autres solutions, donc.
Sauf que si j'ai eu besoin de faire plusieurs compilation avec des log différents c'est justement parce que le volume de log est monstrueux. Donc je devais sélectionner quoi logger et le comparer aux logs valides. Donc ta trace elle peut faire ce quelle veut elle pourra pas deviner toute seule quoi logger.
Pour ce qui de ton système de dimension sur les données, avec les assertions, etc... va falloir que tu développe parce que dans le cas précisdont je parle, je ne vois absolument pas a quoi ça peut servir.
Donc... De plus, es-tu sûr de vraiment savoir ce que tu cherches ?</Ii ...oui moi je sais ce que je cherche et tu me propose des choses qui ne me conviennent pas et qui en plus ne sont pas présentes dans Lisaac. Donc en gros tu me dit : « tu veut ça, donc je te propose ceci qui ne résoud pas ton problème et que je ne sais même pas faire, donc j'ai raison » et après tu veut me faire croire que tu ne troll pas ?
Sachant qu'en plus ce n'est qu'un exemple de cas ou une compilation séparée et utile. Il en existe plein d'autre. Est-ce que pour chacune d'entre elle tu vas me dire, que l'on pourrait implemeter tel truc qui ne résoud pas le problème mais c'est pas grave ?
Par exemple, un code plein d'assertion ou de contrat dans une boucle critique peu se trouver devnir extrèmement lent, donc une foi ce module debuggé, j'aime désactiver les assertions dans ce module. Est-ce que lisaac peut gérer des options de compilation différentes en fonction du module ?
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En fait, en VHDL, les simu sont longues donc on préfère loger un max pour relire ensuite. Mais si l'execution est pas trop lente, le choix de quoi loguer peut être fait au runtime.
Concernant la suite, je te donne l'état des réflexions et les pistes que l'on peut suivre. Je ne te dis pas que c'est la meilleur solution, je ne te dis pas qu'il n'y a que ça à faire, je ne te dis pas non plus tout ce qui est envisageable de faire sans casser le modèle de programmation de Lisaac.
Je trouve hallucinant que tu me reproches de te donner les pistes que l'on explore. Je te donnes les pistes, pour toi, c'est que je troll en sous entendant je ne sais quoi. Je parle du présent, tu me dis, je m'en fout il manque telle truc. Tu me dis je me tiendrait au courant des nouveautés, je te donne des pistes pour le future, tu me dis que je troll.
Un système de trace pourrait éviter tout recompilation, certe, c'est du futur, certe, cela n'existe pas encore. Moi pourquoi forcément, me le renvoyer dans la figure, sans éventuellement accepter que le boulot pourrait être fait de cette façon. Ou encore, j'avais parlé dans un autre commentaire de séparation du proto en test des autres proto, mais on dirait que tu l'as oublier, ou alors, il fallait encore que je me répète ?
J'arrêtes là la conversation. Il n'y en a pas. Quoi que je dis ou propose, je troll ou je dénigre. J'ai l'impression qu'il est impossible de proposer un truc un minimum différent sans se faire défoncer.
D'ailleurs, tu n'as pas répondu sur Octave vs C.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 3.
Si je me souviens bien, la version lisaac prenait pas mal de mémoire de plus que la version C, ce qui nécessitait l'utilisation du swap, et donc ralentissait pas mal le calcul.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Le principal soucis était bien la gestion de la mémoire qui faisait que Lisaac ne pouvait pas traiter autant de donnée que la version en C. Apparement sur des jeux de données plus petit les perfs se raprochait un peu mais encore à l'avantage du C, sachant que ma version en Lisaac était loin d'être aussi optimisée que celle en C car je connais pas super bien lisaac par rapport au C.
J'avais noté que la syntaxe était globalement agréable à lire en dehors du coup des majuscules qui pour moi son un truc immonde, mais question de gouts.
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
i<>
Le gros point noir que j'avais noté c'était surtout la procédure d'instalation qui était merdique à soit, buggais pas mal et très invasive. Apparament un problèmes avec plein de variable d'environement ou autre, mes notes sont pas claires. Est-ce que ça à progresser de ce côter la depuis ?
C'est un peu mieux. C'est moins invasif. Cela marche bien sous Linux, mais c'est plus galère sous windows.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Hélas non, à l'époque ce n'était pas trop distribuable (toujours maintenant d'ailleurs) et je dois avouer que je n'ai pas garder les version Lisaac. C'était juste un essais pour tester le langage, pas vraiment comparer les perfs.
[^] # Re: Surprise
Posté par allcolor (site web personnel) . Évalué à 1.
à part le fait qu'il ne parle pas de slot mais de variable et de fonction modifiable à la voléNawak :
http://fr.wikipedia.org/wiki/Programmation_orient%C3%A9e_pro(...)
En programmation orientée prototype, les membres d'un objet, attributs et méthodes, sont appelés slots ; il n'y a pas la distinction entre les slots de données et les slots de code qu'on a avec les classes.
Self fut le premier langage à prototypes. Il a été conçu dans les laboratoires de Sun dans les années 1990. Le plus connu actuellement est Javascript.
http://fr.wikipedia.org/wiki/Syntaxe_JavaScript#Objets
Par commodité, on sépare habituellement les types de données en primitives (ou types de données de base) et objets. Les objets sont des entités qui ont une identité (il ne sont égaux qu'à eux-mêmes) et qui associent des noms de propriété à des valeurs. Les propriétés sont appelées slots dans le vocabulaire de la programmation orientée prototype.
http://fr.wikipedia.org/wiki/Syntaxe_JavaScript#Constructeur
Les constructeurs assignent simplement des valeurs aux slots de l'objet nouvellement créé.
Ça te suffit où tu en veux encore ?
[^] # Re: Surprise
Posté par allcolor (site web personnel) . Évalué à 0.
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 4.
Et bien regarde justement la page en question et imagine ce que ça pourrait être si tu était moins borné. On un message qui rétabli une erreur dans un journal, chose très courrante et justifiée. Et derrière il y a toi qui ne veut pas admetre que ta phrase était trop ambitieuse.
J'irais même jusqu'a dire que la remarque de base est très importante. Depuis que les ordinateurs permette d'avoir de bonne perf avec les VM, la notion de code compilé est devenue très ambigue et il faut apprendre a bien différencier la compilation en code natif et pour une VM qui sont très différent de l'interpretation.
Et concernant Javascript, il ne s'agirait pas d'un vrai langage à prototype. C'est pas de moi, mais du créateur de Lisaac, qui s'y connait plus que moi en langage et plus que toi aussi je pense.
Justement, tant que tu n'aura pas une bonne argumentation, cet argument ne vaut rien. Je viens de faire un peu de recherche sur le net et il semble que tout le monde soit d'accord sur le fait que javascript est un langage a prototypes. Donc la il va falloir que tu explique pourquoi tout le monde ce trompe.
Si tu distribue tes binaires ngen.exe, tu as la même (absence) sécurité qu'un code C.
C'est bien pour cela que lon ne distribue pas les binnaires natifs mais les binnaires pour la VM, comme je l'ai bien précisé dans mon message. Le code est transformé en code machine au moment de l'instalation du logiciel sur la machine de l'utilisateur. Ce qui permet de valider le code avant la compilation, et en plus de le compiler de maniere particulierement optimisée pour la config de l'utilisateur (du moins en théorie). C'est transparent.
Et ne me sort pas un argument du style oui mais on ne distribue pas du natif donc c'est moins bien que lisaac car :
- On peut le faire mais on perd alors le modele de securitee, et on se retrouve avec un modele equivalent a celui de lisaac ;
- Quelle soit faite sur la machine du developpeur ou de l'utilisateur, il y a bien compilation vers du code machine.
Donc pour moi la discution s'arrete ici, mais je trouve domage que tu t'entete sur ce genre de conneries plustot que de defendre de maniere intelligente ce langage. On en pas grand chose a battre de savoir qui est le premier, par contre tu aurrais mit en avant de vrais avantage du langage tu m'aurais peut etre donner envie de rééssayer.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela doit être trop dur d'aller regarder les vidéos pointés ou les slides associés sans doute.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Une lib est un runtime maintenant, il te reste encore d'autre argument avec autant de mauvaise fois ? (En plus à terme, Lisaac pourra se passer de la lib C.)
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le runtime va gérer la mécanique des exception pour gérer la pile correctement, il va gérer les droits sur les ios du programme pour gérer les protections type sandboxe., il va gérer les threads si il n'y a pas un mapping un pour un avec les threads noyau (runtime ada), et je dois en oublier.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'avais oublié le garbage collector qui est souvent dans le runtime. En Lisaac, il est en lib.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
pour moi le runtime, c'est le support technique à l'exécution des services offerts par le langage (modèle de sécurité, introspection, garbage collector, gestion des exceptions, etc).
Que ce soit sous forme de lib ou pas. D'ailleur cette différence n'a pas de sens puisque la plupart des "runtimes" joue sur les 2 tableaux en offrant également leurs services ou le contrôle de ces services sous la forme de libs.
Le "service" garbage collector peut être vu comme faisant parti du runtime si le service est indispensable pour remplir le contrat de la VM (c'est le cas de Java ou .NET, ce service fait parti de la définition de la VM).
En revanche si le service garbage collector est un "outil" optionnel qui n'a aucun impact sur la sémantique du langage, alors il peut être vu comme une lib normale.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
"run time in this context means the run-time support package associated with a compiler which is understood to make a language complete."
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TortuXm . Évalué à 2.
Par exemple en C, rien ne t'oblige à importer la stdlib, je l'ai déjà fait sur des architectures exotiques. C'est bas niveau et tu peux réécrire une librairie à partir de "rien". Ou même écrire du C sans la stdlib mais avec une autre librairie qui a plus ou moins les mêmes fonctions.
Au contraire si tu ne peux pas te passer de la lib, si le langage lui-même dépend de la lib pour gérer ses propres fonctionnalités, alors c'est un runtime.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Si ton modèle de sécurité est sous la forme d'une lib optionnel, pour faire un programme "dangereux" (volontairement ou non), rien de plus simple... en gros tu casses tout le modèle de sécurité.
Idem pour la gestion mémoire : si le gestionnaire est optionnel, tu tu ne peux plus offrir de garanti du type "cloisonnement" autre que le modèle de l'OS. C'est pourtant bien pratique d'avoir un modèle de cloisonnement pour gérer les plugins par exemple (tu veux les charger dans ton process mais pas qu'ils aillent taper n'importe où dans l'espace mémoire de ton process).
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La sécurité ce n'est pas un exemple. C'est le seul qui s'applique. Et encore, cela concerne la sécurité concernant un code en qui tu n'as pas confiance. Cela ne concerne pas grand chose comme code. Il suffit de regarder ce qui tourne sur une workstation.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 4.
ben regardes tout ce qui tourne dans un navigateur web et dis moi si t'es pas content que le javascript ou Flash s'exécute dans une machine virtuelle :)
Avec la mode des OS "web", ca va devenir le standard ce genre d'appli.
Cela ne concerne pas grand chose comme code
Pour moi ca concerne "tous" les codes : j'ai déjà pas confiance dans mon propre code alors :) Y'a pas que le code malicieux, y'a aussi les "bugs" des logiciels en local. Franchement je suis bien content que dans mes applications une division par 0 ou une référence nulle se solde par une exception qui peut être rattrapée à tous les coups plutôt que de bouffer une erreur de l'OS qui tue illico mon application.
Et puis non, y'a pas que la sécurité comme exemple, je peux prendre par exemple l'introspection : ce service me garantie que je peux dynamiquement charger des plugins en "regardant" ce qu'il y a dedans. Si ce service était optionnel et qu'un plugin n'était pas compilé avec, pouf plus de meta pour l'introspection, pouf chargement foiré.
Autre service utile : le bytecode. Il me permet de déployer sur un serveur des plugins sans me soucier de l'architecture cible. Côté client, je peux checker les plugins sur le serveur, les télécharger et les exécuter en local : ca marche, sous x86, ARM ou je sais pas quoi.
Si le bytecode était un target optionnel, je ne pourrais pas garantir la portabilité de ce que sort le compilateur.
[^] # Re: Surprise
Posté par kowalsky . Évalué à 2.
Côté client, je peux checker les plugins sur le serveur, les télécharger et les exécuter en local : ca marche, sous x86, ARM ou je sais pas quoi.Sous réserve, même si ça parait évident, qu'une VM existe pour ton OS/archi.C'est pas toujours aussi évident que ça peut le paraitre :)
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
Et puis faut arrêter avec les architectures esotériques : les implémentations de VM s'adaptent à la popularité des plateformes. Du moment que la VM est sous licence libre, on pourra toujours l'adapter à une nouvelle cible :)
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 2.
Dans quel genre de contexte rencontre t-on ce genre de besoin ?
Parce que j'ai vu pas mal de gros logiciels en Java, mais jamais de use case où c'était nécessaires.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Pour les client "lourds" t'as des miliers d'exemples : firefox, visual studio, Eclipse, etc.
Même le kernel propose le chargement dynamique de module "à chaud", c'est un mécanisme de plugin.
Perso j'utilise souvent ce pattern même pour des applications purement métier/serveur : support de nouveaux formats, de nouveaux workflows, etc.
Exemple : plateforme d'indexation de contenus vidéo : nous avions un serveur d'indexation qui chargeait dynamiquement des "moteurs" d'indexation développés par des développeurs/chercheurs dans des labos séparés. Bah les moteurs constituaient des plugins pour étendre les possibilités d'indexation de la plateforme.
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Des fonction telle que setjmp et longjmp, les fonctions de gestion des signaux, la gestion des arguments variables sont du runtime. Dans une certaines meure la gestion bas niveau des fichier fait aussi pour moi partit du runtime, mais je vais pas pinailler.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Dans une certaines meure la gestion bas niveau des fichier fait aussi pour moi partit du runtime, mais je vais pas pinailler.
Là, je suis moins d'accord car il s'agit clairement de lib qui font des appels systèmes.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 9.
1) Compiler, qu'est-ce que ça veut dire ?
Wikipedia (en) l'explique très bien :
A compiler is a computer program (or set of programs) that transforms source code written in a computer language (the source language) into another computer language (the target language, often having a binary form known as object code).
et se schéma explique le reste http://en.wikipedia.org/wiki/File:Compiler.svg
http://en.wikipedia.org/wiki/Compiler
Donc js Et Lisaac ont leur compilateur.
Mais il ne font pas la même chose.
2)Un compilateur qui fait de la JIT, se contente de compiler le code tel qu'il est. Pour vous donner une idée à quel point cet idiome est respecté, ya même la notion de classe et d'instance de classe dans le langage de la JVM.
Trace Tree et tout ces trucs sont pareils http://en.wikipedia.org/wiki/Trace_tree
ils prennent du code compilé avec très très peu d'optimisation, et regardent en temps réel ce qui peut être optimisé.
C'est le concept de la JIT, qui a été inventé par les créateur de Self.
Lisaac lui, crache certes du C. Mais ce C sera compilé tel quel par GCC, et sera transformé tel quel modulo les optimisations standard que propose GCC à tout code C et sur lequel le compilateur Lisaac compte en essayant de llui écrire (à GCC) le code au mieux afin qu'il détecte facilement ses cas d'optimisations.
Le binaire ne bougera jamais, il n'y a jamais d'analyse à la volée du code ou autres choses de ce genre.
Lisaac effectue une analyse de flot complète du code, en éliminant le code mort du programme (c'est à dire le code mort pour ce programme, en prenant son point d'entré), une détection de type draconienne (et donc les appels sur NULL), plein de patterns d'optimisation que Nicolas vous expliquerai mieux.
Bref, les deux se compile, mais compiler du Lisaac de cette façon, c'est à dire avec de l'analyse de flot, c'est la première fois qu'on le fait.
Il n'y a pas de VM, et donc le code peut être exécuté sur une machine sans OS.C'est pour ça qu'il a été conçu à la base
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 0.
Euh là tu montresuniquement que le bytecode est toujours de haut niveau, et que donc le boulot du JIT revient à compiler un code de haut niveau en code natif... comme le compilo Lisaac.
Tu montres tout l'inverse de ce que cherches à démontrer :)
Après on est d'accord, ce ne sont pas les mêmes techniques d'optimisation, etc.
M'enfin ils font quand même la même chose : traduction en code machine d'un code de relativement haut niveau pour l'exécuter ensuite.
Et puis on parle pas que de JIT, on parle également de AOT, où le temps de compilation n'est plus un frein aux optimisations : la phase d'optimisation peut devenir plus proche de celle d'un compilateur ala GCC. C'est tellement vrai avec GCJ...
Il n'y a pas de VM, et donc le code peut être exécuté sur une machine sans OS.C'est pour ça qu'il a été conçu à la base
Ca n'a aucun rapport. Il y a des projets d'OS en Java ou en C# (et dérivés) : tu peux très bien embarqué tout le bootstrap nécessaire pour lancer ton JIT avec ton OS en bytecode, bref embarqué le runtime comme ca se fait souvent.
Lisaac lui, crache certes du C.
Vi d'ailleur j'ai jamais bien compris : c'est par flemme que Lisaac utilise le C comme VM ? Non parcque dans mes souvenirs de cours d'optimisation à la fac, il me semble qu'un code écrit en fortran peut par exemple être plus rapide qu'un code écrit en C dans certaines situations : la sémantique fortran permet au compilateur de faire plus d'hypothèses (et donc d'optimisation) alors que le compilo C reste limité, tant la sémantique est permissive...
Je cherches pas à dire que Fortran est plus rapide que le C, mais qu'il paraît bizzare qu'un langage qui cherche les performances comme Lisaac n'est pas un compilateur qui profite de sa connaissance de "haut niveau" de la sémantique du code du développeur pour générer un binaire encore plus optimisé...
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 3.
Tu montres tout l'inverse de ce que cherches à démontrer :)
Après on est d'accord, ce ne sont pas les mêmes techniques d'optimisation, etc.
M'enfin ils font quand même la même chose : traduction en code machine d'un code de relativement haut niveau pour l'exécuter ensuite.
Et puis on parle pas que de JIT, on parle également de AOT, où le temps de compilation n'est plus un frein aux optimisations : la phase d'optimisation peut devenir plus proche de celle d'un compilateur ala GCC. C'est tellement vrai avec GCJ...
Oui mais la différence, c'est qu'en JIT, le "compilateur" connais pas mal d'infos car les données sont disponibles, il est en situation, il les as.
Mais comme il ne fait pas d'analyse globale. Ton call on null pète au runtime, pas à la compilation, parce que la compilation te l'empêche intrinsèquement.
En AOT ( http://www.mono-project.com/AOT#Full_AOT ) il fait une optimisation à la SmartEiffel : il regarde les possibilités au niveau statique, e va compiler tous les cas, même si l'arbre d'exécution réel impliquerai que tel ou tel cas n'existerait jamais. C'est la différence entre le compilateur SmartEiffel et Lisaac, qui a été développé dans le même labo que SmartEiffel.
Regarde les limitations : http://www.mono-project.com/AOT#Limitation:_Generic_Interfac(...)
C'est cela qu'on essaye d'éviter avec Lisaac, mais ça a été aussi une stratégie pour des langages comme OCaml.
C'est une philosophie qui consiste à déterminer le maximum d'erreurs potentielles à la compilations. De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
La compilation séparée à ses avantages et ses défauts, tout comme la compilation globale. Néanmoins, modulo le temps de compilation, je pense que tu peux faire en compilation globale ce que tu peux faire en séparé, par exemple en stockant quelques part des infos sur le bout de code compilé en globale, qui serviront lorsqu'on compilera le plugin.
De toutes façons, la compilation globale permet déjà un truc intéressant par rapport à son pendant séparé : tu n'embarques que le code dont tu te sers dans la lib, et question de taille, sur des machines à moins de 256ko, ça a son importance.
Ca n'a aucun rapport. Il y a des projets d'OS en Java ou en C# (et dérivés) : tu peux très bien embarqué tout le bootstrap nécessaire pour lancer ton JIT avec ton OS en bytecode, bref embarqué le runtime comme ca se fait souvent.
Si ça a voir, parce que ta VM doit embarquer un mini OS, c'est elle qui doit gérer les interruptions, la gestion de la mémoire, etc..
Et question taille, mais surtout perf, on a pas le temps de faire du JIT en live.
Vi d'ailleur j'ai jamais bien compris : c'est par flemme que Lisaac utilise le C comme VM ? Non parcque dans mes souvenirs de cours d'optimisation à la fac, il me semble qu'un code écrit en fortran peut par exemple être plus rapide qu'un code écrit en C dans certaines situations : la sémantique fortran permet au compilateur de faire plus d'hypothèses (et donc d'optimisation) alors que le compilo C reste limité, tant la sémantique est permissive...
Je cherches pas à dire que Fortran est plus rapide que le C, mais qu'il paraît bizzare qu'un langage qui cherche les performances comme Lisaac n'est pas un compilateur qui profite de sa connaissance de "haut niveau" de la sémantique du code du développeur pour générer un binaire encore plus optimisé...
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Re..
1) Pourquoi utiliser C (et ce n'est pas une VM : une VM est un programme qui tourne et exécute du code, le C est lui compilé et le code machine ne bouge plus) ?
Au vu du nombre d'architecture différentes existantes, et du nombre de règle d'optimisations très complexes des processeurs modernes, il aurait été stupide et surtout titanesque, de générer de l'assembleur. C'est pour cela que Dominique Colnet, lorsqu'il a commencé SmartEiffel (car ça vient de lui), a décidé d'utiliser un assembleur portable : le langage C.
L'idée consiste à générer un C très bas niveau, gérant une arithmétique de pointeurs très proche de la machine.
2) On en vient donc à pourquoi C et par Fortran ?
C est un langage doté de compilateur performant, disponible sur énormément de machine, et c'est sur ces compilateurs que tous les efforts sont effectués pour générer un assembleur le plus optimisé possible.
GCC connait les règles spécifiques à chaque processeurs : Athlon Thunderbird, Core Duo 1 et 2, AMD64, Arm thumb, etc...
La machine virtuelle java le fait aussi d'ailleurs.
On peut tout à fait être aussi voire plus performant qu'un code fortran si l'on écrit son code C d'une certaine façon (en faisant un code C qui ressemble.. à du fortran : pas trop de pointeurs, etc...).
Le projet GCC l'explique sur cette page :
http://gcc.gnu.org/projects/tree-ssa/vectorization.html
Pas vectorisable :
while (*p != NULL) {
*q++ = *p++;
}
Vectorisable :
for (k = 0; k < K; k++) {
sum = 0;
for (j = 0; j < M; j++)
for (i = 0; i < N; i++)
sum += in[i+k][j] * coeff[i][j];
out[k] = sum;
}
Il y est décrit comment écrire son code C, mais aussi quelle forme de code sont à éviter pour que le compilateur puisse optimiser au mieux et utiliser MMX, SSE, et dans le futur Larabee.
On a juste à faire attention à ce que le compilateur génère du code parfaitement conforme à ces normes, et on a ainsi un code parfaitement optimisé.
Il y a d'autres techniques comme utiliser automatiquement la lib oil, et autres système.
Surtout que GCC c'est loin d'être le compilateur réputé pour être le plus rapide, que ce soit à la compilation ou à l'exécution du binaire produit...
Même sur processeur Intel, j'en mettrais pas ma main à couper. GCC est travaillé au corps par pas mal d'universitaires, et ICC est souvent au coude à coude avec GCC.
De toutes façon on s'en fiche, le code peut être compilé par ICC aussi...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 1.
Euh, le call on null ca serait pas fait par le JIT dans ce cas, mais par le compilateur en amont. De la même manière que c'est le compilateur Lisaac et pas GCC qui s'en occupe...
Regarde les limitations : http://www.mono-project.com/AOT#Limitation:_Generic_Interfac(...)
C'est cela qu'on essaye d'éviter avec Lisaac, mais ça a été aussi une stratégie pour des langages comme OCaml.
Cette limitation vient de l'implémentation de Mono, pas du modèle sous-jacent, le compilateur AOT de .NET n'a pas cette limitation.
Ensuite je vois pas pourquoi tu parles de ça...
De sorte que si le compilateur te dit OK, tu n'auras jamais de Call On Null, de Cast exception, etc...
Garantie possible... uniquement si tu ne fait pas appel à des modules externes.
C'est impossible à faire sans analyse de flot, donc sans compilation globale.
Toutafé, on est d'accord. Les avantages sont indéniables, la question est de savoir si le jeu en vaut la chandelle au regard des inconvénients. Cela est d'autant plus bizzare vu la cible : embarqué, OS : jamais de code assembleur ? jamais de code externe ? jamais de drivers binaires ? Bref, combien de projet où le compilateur pourra vraiment offrir une garantie (ce qui suppose que tout soit codé en Lisaac et que toutes les sources soient compilées en même temps) ?
Si ça a voir, parce que ta VM doit embarquer un mini OS, c'est elle qui doit gérer les interruptions, la gestion de la mémoire, etc..Et question taille, mais surtout perf, on a pas le temps de faire du JIT en live.
Bref, c'est donc bien possible. Comme déjà expliqué, la présence d'une VM n'implique pas JIT : on peut faire de l'AOT. Mais oui, niveau perf les services apportés par ces VM a souvent un impact négatif c'est clair.
Mais dans tout les cas ca reste tout à fait possible, CQFD.
ce n'est pas une VM : une VM est un programme qui tourne et exécute du code, le C est lui compilé et le code machine ne bouge plus
Non non non et non. Une VM n'est pas un programme. Une VM c'est une machine virtuelle, une représentation abstraite sous la forme d'un jeu d'instruction d'une machine qui n'existe pas. C'est une confusion classique : on assimile une VM au runtime et son moteur JIT. Pourtant la technique AOT montre clairement que le bytecode est "lui compilé et le code machine ne bouge plus". C'est exactement pareil.
et surtout titanesque, de générer de l'assembleur.
Ok c'est bien un problème de moyen.
Maintenant moi j'ai une question : comment offrez-vous l'accès aux instructions spécifiques des processeurs modernes ? SSE & co ? Les unités de calculs vectorielles toussa ? En dehors des optimisations de base offertes par GCC, il est souvent très utile d'aller directement utiliser les instructions processeurs quand c'est vraiment les perfs que l'on recherche...
En résumé je trouve ce paradoxe assez étonnant : un des atouts de Lisaac, ce sont les perfs, et en même temps, vous limitez intrinséquement les perfs de Lisaac à la VM exposée par le langage C, autrement dit pas d'optimisation possible en dehors de cette VM... Lisaac est condamné à être aussi "lent" que le langage C "standard".
[^] # Re: Surprise
Posté par Philip Marlowe . Évalué à 3.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Pour moi un langage s'assembleur représente les instructions machines sous une forme lisible.
Si le C est un assembleur pour Lisaac, cet assembleur représente des instructions machines... cette machine est une machine virtuelle, ce qui lui permet d'être portable.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Où comment faire du JIT avec Lisaac ;)
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 4.
Cette dualité permet d'ailleur toutes les fantaisies : Je target Lisaac qui target le C qui target LLVM (qui a son langage d'assembleur qui défini son jeu d'instruction) qui target la JVM (qui a son langage de bytecode qui le défini) qui peut avoir pour target Mono (dans la VM est défini par le code IL) qui peut avoir pour target LLVM qui etc.
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Surprise
Posté par Philip Marlowe . Évalué à 2.
[^] # Re: Surprise
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
Le truc qui me semble occulté ici, c'est que dans la notion de machine virtuelle, il y a quand même notion d'une machine dynamique en quelque sorte, dans le sens ou elle "tourne" au dessus d'une machine réelle.
Dans le cas d'un langage compilé, on abstrait la machine en quelque sorte grâce à l'aspect "haut niveau" du langage, par contre quand tu fais tourner un compilateur, le compilateur ne tourne qu'une seule fois. Pas besoin d'en rajouter, ton programme n'a plus besoin du compilateur.
Sinon, à chaque fois qu'il y a abstraction on peut parler de machine, ce qui n'est pas le cas.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu confonds VM et implémentation à l'aide d'un runtime+JIT (pour le côté dynamique).
GCJ (pour Java) ou NGEN (pour .NET) montre clairement que ca n'a aucun rapport : ces 2 compilateurs proposent de compiler en langage natif avant exécution des programmes écrits en Java et .NET : le compilo tourne une seule fois, plus besoin d'en rajouter, c'est que du code natif qui s'exécute derrière. LLVM propose l'exercice inverse : un compilateur JIT pour le C. Comme quoi fondamentalement il n'y a pas de différence, tous les langages exposent une machine virtuelle, sauf les langages machines bien sûr, dont le rôle est justement d'exposer les instructions de la machine réelle.
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
Un autre exemple : .NET propose d'implémenter plusieurs langages grâce à sa VM. Est ce que tous ces langages définissent la même VM ? D'après ta définition, c'est le langage qui définit la VM, donc non. Dans les fait, il n'y a qu'une seule VM.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu confonds définition et implémentation. Quelque soit la technique que tu utilises dans l'implémentation de ta VM (compilation JIT, compilation AOT, interpreter), la VM est toujours présente : c'est une machine par définition qui n'a pas de réalité physique, elle n'est défini que par des instructions et ressources virtuelles.
Dans les fait, il n'y a qu'une seule VM.
Pas de bol : y'a des implémentation de JVM au dessus de .NET inversement, comme quoi tu peux bien en avoir plusieurs :-p
Dans les faits il y a autant de VM que t'as d'abstraction.
Si tu utilises un langage au dessus de .NET ou Java qui expose son propre jeu d'instruction avec ses propres caractéristiques de gestion de ressource, t'as une autre VM.
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
Évidemment tu peux empiler les VM logicielles, après il me semble qu'habituellement quand on parle de VM on parle de machine logicielle, plutôt.
Peut être qu'un terme qui me conviendrait mieux et qui se prendrait pas dans les pates avec la definition de VM serait plutôt "machine abstraite". Un peu comme la machine de Turing.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
Pour toi une VM reste un truc concrêt qui "tourne" alors que pour moi c'est essentiellement une cible. Pour moi ce qui tourne c'est le programme, soit le code source compilé/interprété + runtime.
après il me semble qu'habituellement quand on parle de VM on parle de machine logicielle, plutôt.
Après oui c'est aussi une partie de mon discours : casser cette idée qu'il y a une "machine" qui tourne. On entend du coup tout et n'importe quoi : "pourquoi utiliser la lourdeur d'une VM ?" "La VM ralenti tout", "le code natif ca va plus vite", etc.
Alors que dans les faits, les VM modernes sont implémentés à l'aide de compilateur qui traduisent en code natif, bref au final il n'y a que du code natif qui s'exécute.
J'ai bien la phrase sur wikipedia concernant la JVM :
"The JVM runtime executes .class or .jar files, emulating the JVM instruction set by interpreting it, or using a just-in-time compiler (JIT) such as Sun's HotSpot."
Ils font clairement la différence entre le runtime et le modèle : l'un est une implémentation de l'autre, et il peut y avoir différentes techniques d'implémentation.
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 3.
Tu peux y arriver sans ça.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Et cette définition a l'avantage d'être cohérente : d'un côté la notion de "machine virtuelle" qui se raccroche bien à quelque chose qui n'existe pas, et de l'autre différentes technique d'implémentation qui montre qu'une VM n'est pas forcement synonyme de la présence d'un "lourd interpréteur lent comme une loutre".
Beaucoup de gens confonde peut-être runtime/interpréteur/compilateurJIT et VM, mais c'est pour moi un héritage du passé où effectivement les VM étaient implémentées comme de bêtes interpréteurs : l'utilisateur identifie alors la VM à l'exécutable chargé d'interpréter le bytecode.
Depuis les VM n'ont jamais été aussi présentes mais les techniques d'exécution ont largement évoluées, et oublier la définition qui fait abstraction de toute implémentation, c'est ignorer ces évolutions.
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
Tu te contredis. Si on prends ta définition, n'importe quel langage est une VM, donc les VM sont présentes depuis le début.
Par ailleurs, la phrase sur java parle bien d'une JVM qui comporte un runtime, ce qui n'implique absolument pas qu'il existe des VM sans runtime, ta phrase ne montre selon moi pas grand chose.
Pour le reste, tu défend ta définition certe, mais si d'autre la reprennent tu devrai pouvoir sourcer tes propos un peu sérieusement ;)
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Attention on va rentrer dans la définition de runtime, et j'ai jamais dis que y'avait des implémentations de JVM sans runtime, bien au contraire :)
Pour moi le runtime c'est le code non écrit par l'utilisateur qui permet à l'exécution de rendre l'ensemble des services/comportement attendus de la VM définie par le langage : initiatilisation, allocation, GC, reflection, etc. A moins d'utiliser un langage d'assembleur, il y a toujours un runtime, quelque soit le langage.
ta phrase ne montre selon moi pas grand chose.
La phrase montre clairement qu'il font la distinction entre le runtime de la JVM et le jeu d'instruction de la JVM. Pour eux la JVM existe bien et ne représente pas le runtime : le runtime est une composante permettant d'implémenter la JVM.
Cette page http://en.wikipedia.org/wiki/Comparison_of_application_virtu(...) montre également que pour eux la notion de VM existe indépendamment de la technique d'implémentation, il font même un tableau comparatif qui montre qu'il y a différente techniques d'implémentation, comme quoi la notion de VM ne se limite pas à la notion de runtime avec interpréteur/JITeur. Pour eux quand il y a pré-compilation n'enlève en rien la définition de VM (alors que pour toi quand y'a AOT y'a plus de VM).
Sinon tu l'as proposé, il y a la notionde machine abstraite, et là encore wikipedia me rejoint : http://en.wikipedia.org/wiki/Abstract_machine
"An abstract machine implemented as a software simulation, or for which an interpreter exists, is called a virtual machine."
Une machine virtuelle EST une machine abstraite dont la particularité est qu'il en existe une implémentation technique (la notion de machine abstraite étant à la base une notion théorique).
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
Sinon dans ton tableau ils recencent pas gcj comme implémentation de la JVM, par exemple. Le langage C n'est pas du tout cité comme VM (et pour cause, c'est un langage).
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Bah rajoute une ligne si tu veux. Ce qui est sûr, c'est qu'ils ont mis la colonne "Precompilation" qui décrit exactement ce que fait GCJ.
Le langage C n'est pas du tout cité comme VM
bien sûr que non, parcque le langage C est avant tout destiné à être un langage de programmation pour le développeur, bref on parle avant tout d'un langage. En revanche depuis, des langages de plus haut niveau s'appui sur la VM exposé par le C afin d'avoir une portabilité offerte out-of-the-box : Lisaac en est un exemple, le C n'est alors plus utilisé pour représenter du code sous une forme lisible par un être humain mais comme un environnement définissant une VM portable.
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
Donc pourquoi "précompilation" ? c'est un mystère pour moi, puisqu'il n'y a pas besoin de "postcompilation" dans ce cas de figure.
A virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. Dans ce cas la plate forme est assimilable à un compilateur. Ou alors tu considères que gcc est une VM. Note d'ailleurs qu'ils citent LLVM comme VM, mais pas gcc, alors que la seule différence fondamentale entre les deux à ma connaissance est la capacité de faire du jit.
Toujours dans le cas de la "precompilation", la machine n'a plus vraiment de sens en elle même, puisqu'elle est déja préimplémentée voire transformée dans une autre machine, avec un autre assembleur et d'autres fonctionalités. La VM n'exécute plus rien, c'est la machine réelle qui le fait. Donc à mon avis on sort du cadre de cette définition. Faudrait lire les références pour voir si c'est cohérent avec les publis académiques.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Vi c'est clairement un abus de langage, c'est pour exprimer le fait de compiler entièrement et de manière statique avant de demander l'exécution du programme. Bref c'est de la compilation classique, par opposition à la compilation JIT qui a des particularités du fait des contraintes dynamiques qu'elle implique (même si la définition de compilation reste valable).
Note d'ailleurs qu'ils citent LLVM comme VM, mais pas gcc, alors que la seule différence fondamentale entre les deux à ma connaissance est la capacité de faire du jit.
LLVM ne fait que s'appuyer sur la VM interne de GCC. GCC n'est pas cité car son objectif premier n'est pas d'exposer sa VM mais de proposer des outils de compilation au développeur.
LLVM tire parti de la VM interne de GCC et de proposer son propre backend qui a beaucoup plus de possibilités.
La VM n'exécute plus rien, c'est la machine réelle qui le fait. Donc à mon avis on sort du cadre de cette définition.
C'est pour ça que ma définition marche très bien : la VM n'exécute rien, c'est un modèle virtuel pour les outils du développeurs. Après quelque soit la technique d'exécution derrière, ma définition marche toujours. Avec ta définition, un coup la VM existe, un coup elle existe plus, tout celà à cause d'une technique particulière d'exécution.
D'ailleur si on suit ton raisonnement, même sans "pré-compilation statique", un moteur JIT traduit toujours en code natif avant d'exécuter, la VM n'existe donc toujours jamais avec toi :)
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
Alors que dans le cas de la compilation native, la VM disparait, la machine abstraite disparait aussi puisqu'on ne retrouve plus du tout ses instructions à elle, mais l'équivalent sous une autre forme. On n'en a plus du tout besoin, on l'a transformé à priori en quelque chose de computationnellement équivalent.
la VM n'existe donc toujours jamais avec toi :)
Ben si, elle existe, elle se débrouille en temps réel pour exécuter, comme elle le peut, les instructions de la machine abstraite. La ou je te rejoint c'est que de ce point de vue comment elle le fait, on s'en balance.
Avec ta définition, un coup la VM existe, un coup elle existe plus, tout celà à cause d'une technique particulière d'exécution.
Ça c'est parce que tu veux présenter tout de manière équivalente en masquant les subtilités, donc tu trifouilles les définitions pour que ce soit effectivement le cas :) Ça marche pas parce que ça ne correspond pas à la définition communément admise de VM ...
Si tu veux dire qu'au final quelque soit l'implémentation tu obtiens les même résultats, c'est le but du truc.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Pas distincte, c'est la même puisque définissant la même machine. La phrase de wikipedia est pourtant claire : " An abstract machine implemented as a software simulation, or for which an interpreter exists, is called a virtual machine." : quelque soit le nombre d'implémentation, tu défini toujours la même machine abstraite, et on l'appelle pour l'occaz machine virtuelle (toujours qu'une seule, c'est bien la même).
Alors que dans le cas de la compilation native, la VM disparait, la machine abstraite disparait
La ou je te rejoint c'est que de ce point de vue comment elle le fait, on s'en balance.
Bah faut savoir, si y'a compilation native en s'en balance, alors que ce n'est rien d'autre qu'une technique d'exécution...
Donc pour toi la VM existe jusqu'à quel point ?
Je reste persuadé que pour toi la VM correspond à l'outil qui exécute un code ciblant la machine abstraite, c'est la seule façon d'expliquer la façon dont tu différencies la phase de traduction en code natif et d'exécution en code natif. Pour moi ça c'est la tambouille du runtime.
Ça marche pas parce que ça ne correspond pas à la définition communément admise de VM ...
Ben wikipedia c'est réputé pour être populaire et donc exprimer la définition communément admise : c'est une machine abstraite dont il existe une implémentation. On s'en fou de ce que fait l'implémentation, qu'elle fasse de l'AOT, du JIT, de l'interprétation, duchezpasquoi, la VM existe et est définie par une documentation (grammaire, jeu d'instruction, description du comportement, etc.) et rien d'autre. Pas la peine de chercher à la rendre réelle :)
(100 balles qu'on va rester sur nos positions)
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
Rien de mystérieux, c'est ce que j'essaye de dire depuis bien longtemps. Une machine abstraite c'est une définition de plate forme, une VM c'est un soft qui implémente cette plate forme.
en:Virtual_machine cite cet article, qui a l'air d'être pile dans le sujet : http://www.fdi.ucm.es/profesor/manu.ortega/Tema%201/M%C3%A1q(...)
A process VM is a virtual platform that executes an individual process. This type of VM exists solely to support the process; it is created when the process is created and terminates when the process terminates.
Published by the IEEE Computer Society
Je crois que j'irai pas plus loin, parce que c'est exactement ma position. Sauf si tu me trouve un article de qualité qui vient donner une autre définition :)
( http://scholar.google.com/scholar?hl=fr&lr=&q=relate(...) )
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Mais bon ca se tient comme définition mais je préfères quand même ma définition qui se rapproche de machine abstraite, je trouve ca beaucoup plus joli que de considérer uniquement le process de traduction/exécution, mais bon c'est une définition.
J'essairai de parler de machine abstraite la prochaine fois pour éviter toute confusion :)
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
C'est cette machine virtuelle qui lui permet d'être un minimum portable en faisant abstraction de la machine réelle (et de ses instructions spécifiques).
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Ca fait parti des modes qui existent : j'interprête, et quand j'exécute souvent ce code, je le compile en natif pour les prochaines fois. C'est une des stratégies de l'environnement d'exécution HotSpot de Java.
Mais en .NET par exemple, ce n'est pas du tout le cas : tout est systématiquement compilé avant exécution.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Source ?
Cela parait totalement aberrant pour des raisons de trop grande lenteur de démarrage ou de performance ensuite.
L'avantage du jit est justement de pouvoir faire de la constante propagation en connaissant les données du programme, c'est comme ça que Sun arrive à faire des benchmark ou java est plus rapide que le C. En gros, le code est spécialisé en fonction des données, cela simplifie encore plus le cœur des boucles. En plus, si le langage d'origine n'est pas fortement typé, il y a un dispatch a faire très couteux à l'exécution en fonction des données, Dispatch qui disparait dans le cas d'un jit.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Sinon regarde les specs de la norme ISO correspondante au Common language runtime.
Faut bien voir que le bytecode Java a été conçu pour être interprété, depuis la VM a évolué pour introduire des techniques de JIT, mais c'était pas le but initial.
Le bytecode .NET a été conçu pour se passer intégralement d'interpréteur.
Après le JIT peut avoir des avantages par rapport à la compilation AOT (parcqu'effectivement en Live il y a des infos non dispo par rapport à une pré-compilation).
Mais dans tous les cas le JIT est une techniquement de compilation, pas d'interprétation.
Sun utilise toujours les 2 pour sa machine HotSpot (JIT et interprétation), .NET utilise JIT ou AOT (sans interpréation dans les 2 cas).
[^] # Re: Surprise
Posté par kowalsky . Évalué à 3.
Lissac -> C -> gcc
C'est clair que ça n'a rien à voir parce que c'est diffèrent et qu'en plus, c'est pas pareil ! :)
Mais bon, je ne compare pas les deux langages, ils sont incomparable !
Parce que par exemple, il y a énormément de projet en JS alors qu'en Lissac... :)
Comme quoi, ça ne sert à rien d'être parfait, il vaut mieux être fonctionnel (et prototype, mais fonctionnel, 'fin, tu m'a compris :)) !
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
The JavaScript engine in Phobos is based on the one in the Java Platform, Standard Edition 6 (Java SE 6), code-named Mustang, and it uses Mozilla Rhino for its operations. Compared to the JavaScript engine in Mustang, the one in Phobos has these additional capabilities:
* Support for the JavaScript language extensions for XML (E4X)
* Compilation to bytecode
* Ability to subclass Java classes (subject to any security limitations specific to a platform)
* Extensible top-level functionality
https://phobos.dev.java.net/overview.html
Rhino is an open-source implementation of JavaScript written entirely in Java. It is typically embedded into Java applications to provide scripting to end users. http://www.mozilla.org/rhino/
Parce que par exemple, il y a énormément de projet en JS alors qu'en Lissac... :)
Linux doit être de la merde alors devant le nombre de projet windows.
En tout cas j'adore voir autant de gens essayer de prouver qu'un projet open source n'est pas innovant quand il l'est. Cela doit être très français de vouloir tout dénigrer.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par kowalsky . Évalué à 3.
Je ne dénigre pas (j'espère que je ne le ferais jamais) un projet de l'ampleur et de la complexité de Lisaac !
[^] # Re: Surprise
Posté par Antoine . Évalué à 3.
Si tu arrêtais de faire la vierge effarouchée à chaque fois qu'on émet une critique ça aiderait aussi...
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 2.
Oui.
Lire le très intéressant "Français et Américains, l'autre rive" de Pascal Baudry, qui explique pourquoi on est, en France, rétif à toute innovation et critiques de tout ce qui est nouveau.
http://pbaudry.com/
Ce bouquin est absolument passionnant, je vous le conseille !
(li livre est lisible gratuitement en PDF)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par ɹǝıʌıʃO . Évalué à 3.
Sans compter que la chaîne JS → Java → code natif est, à ma connaissance, une possibilité théorique pas vraiment testée, alors que tu peux télécharger le compilateur Lisaac. Donc non, ce n'est pas pareil.
[^] # Re: Surprise
Posté par Yusei (Mastodon) . Évalué à 2.
(Il y a d'autres langages qui peuvent être traduits en bytecode pour une JVM, mais à ma connaissance pas le C)
[^] # Re: Surprise
Posté par ɹǝıʌıʃO . Évalué à 3.
Dans ce cas, je te suggère de wikipédifier ta connaissance : http://en.wikipedia.org/wiki/Java_Virtual_Machine#C_to_bytec(...)
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Cf java web-start vs ActiveX.
Tu peux toujours sandboxer ton bytecode puisqu'il s'appui sur une machine virtuelle... sandboxer ton code natif dont tu ne connais pas la provenance, c'est beaucoup plus chaud.
En fait faudrait vous poser la question : pourquoi Java a été conçu comme ça ?
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
http://en.wikipedia.org/wiki/Duck_typing#In_C.23
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 5.
C'est pourtant ce dernier point qui est essentiel : votre objectif est-il de vanter les mérites de Lisaac ou de répondre aux besoins des codeurs ?
Qu'est ce qui est le plus important pour un développeur ? que la grammaire soit simple ou de faire en sorte que la syntaxe ne lui paraisse pas étrange ?
Pourquoi Java C# & Co se sont inspirés de la syntaxe du langage C ?
[^] # Re: Surprise
Posté par Yusei (Mastodon) . Évalué à 6.
Au niveau de la com, c'est pas toujours très au point, mais ce n'est pas non plus leur boulot, et ce ne sont pas les premiers à avoir du mal à faire accepter leur langage bizarre aux développeurs (cf. Eiffel, OCaml...). Au final, je pense qu'il est plus probable que les idées utilisées dans Lisaac soient intégrées dans les langages mainstream plutôt que de voir soudainement Lisaac être adopté par tout le monde, mais on verra bien. Il suffirait du soutien d'une grosse boîte pour que ça change.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à -1.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Java est à peine plus évolué que simula (1967) + les coroutines.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Victor . Évalué à 1.
[^] # Re: Surprise
Posté par Antoine . Évalué à 1.
Je suis bien d'accord que Java & co c'est pas très excitant mais, franchement, Lisaac non plus...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Rien à voir avec la philosophie d'un langage pensé pour être utilisé par des développeurs au quotidien.
Ce sont 2 objectifs différents, les 2 sont utiles, mais il est totalement idiot de dénigrer l'un plus que l'autre : Lisaac est à la ramasse totale en ce qui concerne le côté industriel. Les langages "modernes" sont conçus avec en tête leur utilisation dans un IDE (autocomplétion intelligente, refactoring), leur déploiement avec toutes les contraintes qui vont avec (composant, sécurité, portabilité, signature, sandboxing, etc.), la familiarité de la syntaxe, la bibliothèque standard (énorme), etc.
Donc arrête avec tes attaques à 2 balles sur la prétendu supériorité de Lisaac sur les autres langages.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Et si les qualités que tu cites étaient aussi importantes, expliques moi pourquoi C, C++, Fortran n'ont pas encore disparu dans les nouveaux designs.
Parfois les performances brutes comptent, l'empreinte mémoire compte.
Et je ne voix pas ce que vient faire la taille de la bibliothèque sur l'expressivité d'un langage.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Absolument pas.
Et si les qualités que tu cites étaient aussi importantes, expliques moi pourquoi C, C++, Fortran n'ont pas encore disparu dans les nouveaux designs.
Parcque ce sont des langages industriels qui ont de nombreux avantages, à commencer par une très grande maturité, des outils adaptés, des bibliothèques nombreuses, une certaine universalité, des performances adaptées à certains contextes, etc. Bref Lisaac est très très loin de pouvoir prétendre à remplacer ces langages, comme tu le fais si bien remarqués, ils sont vieux mais sont encore vivants et utilisés alors qu'il existe pourtant des langages plus modernes mais sans les mêmes atouts (D par exemple).
Parfois les performances brutes comptent, l'empreinte mémoire compte.
J'ai jamais dit le contraire.
Et je ne voix pas ce que vient faire la taille de la bibliothèque sur l'expressivité d'un langage.
Juste que ca forme un tout. Un langage sans une bonne bibliothèque n'est rien.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Et Lisaac peut dés à présent les remplacer tout en ayant une marge de manœuvre sur l'augmentation des performances, et l'amélioration de sa lib.
à commencer par une très grande maturité,
Forcément.
des outils adaptés
Une grosse part des outils en question, fonctionnent avec n'importe quel binaire ou n'importe quel fichier texte.
, des bibliothèques nombreuses
C'est la limite pour un nouveau langage, c'est sûr.
une certaine universalité, des performances adaptées à certains contextes, etc.
C'est exactement le cas de Lisaac qui s'appuie sur les compilo C pour le coté universel et performant "partout".
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Les IDE c'est pas de simple vim, faut pas déconner. Utilise Visual un jour, son éditeur, utilise le debuggueur, utilise les profilers, tout ça.
C'est exactement le cas de Lisaac qui s'appuie sur les compilo C pour le coté universel et performant "partout".
Quand je parle d'universalité, c'est au sens "répendu" dans la tête des gens et dans les compétences des développeurs.
Lisaac a une syntaxe imbittable pour le commun des mortels, et vu que personne n'apprend se langage, ben il est pas prêt d'être universel.
Les langages qui tentent ou réussissent à s'imposer sont beaucoup plus pragmatique et cherche à rendre leur syntaxe "familière" aux développeurs justement habitués à l'universalité du langage C.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Ceux qui disent cela ne connaisse que java ou le C. Lit du ocaml ou du smalltalk voir du perl, tu va sauter en l'air. La syntaxe lisaac est une version strict des règles de génies logiciel : avoir un maximum de clareté (MAJUSCULE pour les type, minuscule pour les slots, Une seul majucule pour les mots clef)
Les langages qui tentent ou réussissent à s'imposer sont beaucoup plus pragmatique et cherche à rendre leur syntaxe "familière" aux développeurs justement habitués à l'universalité du langage C.
Cela a un coup énorme sur l'ambiguïté de la syntaxe, sa difficulté à lire, la difficulté à compiler et rendre performant une grammaire large.
Les nouveaux langages cherchent aussi à être productif. Cela veut dire facile à relire (ce qui est complexifié par la taille de la grammaire, cf perl), facile à détecter des bugs tôt (lisaac détecte les "call sur null" à la compilation et non au runtime comme java), la programmation par contrat facilite aussi la vérification.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Yusei (Mastodon) . Évalué à 4.
Vu la rareté des mots clefs en Lisaac, j'aurais préféré que ce soient eux qui soient en MAJUSCULES, et les types en CamelCase.
En fait, j'ai un peu l'impression que Lisaac a repris les rares choses qui me gênaient en Eiffel: la section d'en-tête et les types pas beaux :)
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 1.
C'était justement volontaire : c'est imbittable pour la plupart des gens.
C'est pour les mêmes raisons que des langages comme smalltalk ou ocaml restent confidentiels.
Perl n'en parlons pas, c'est un truc de barbu.
La syntaxe lisaac est une version strict des règles de génies logiciel : avoir un maximum de clareté (MAJUSCULE pour les type, minuscule pour les slots, Une seul majucule pour les mots clef)
Un langage moderne part du principe que y'a un éditeur spécialisé avec coloration syntaxique... La règle des majuscule montre clairement que le langage n'a pas été conçu pour être utilisé dans un environnement moderne.
Cela a un coup énorme sur l'ambiguïté de la syntaxe, sa difficulté à lire, la difficulté à compiler et rendre performant une grammaire large.
D'accord sauf pour la difficulté à lire, puisque c'est justement l'objectif : simplifier la lecture par un noobs avec une syntaxe familière. Vous vous sacrifiez justement la familiarité et donc la simplicité de lecture pour répondre à d'autre besoins. C'est un choix, mais vous prenez l'énorme risque de vous retrouver avec un langage confidentiel comme Smalltalk.
Faudra pas venir pleurer.
la programmation par contrat facilite aussi la vérification.
On est d'accord, mais tant que vous aurez pas compris que le principal truc qui rebute, c'est la syntaxe.
C'est comme dans la vraie vie : c'est quoi le plus facile à apprendre : l'anglais qui utilise le même alphabet que nous ou ne chinois ?
Si tu dois créer une nouvelle langue, tu crois que c'est pertinent de créer un nouvel alphabet qui ne se rapproche d'aucun alphabet existant, si ton objectif est qu'il soit parler par le plus grand nombre ?
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu m'expliquera comment une coloration syntaxique corrige une faute de syntaxe.
D'accord sauf pour la difficulté à lire, puisque c'est justement l'objectif : simplifier la lecture par un noobs avec une syntaxe familière.
Perl et Ocaml propose beaucoup de "simplification" par sucre syntaxique. C'est cool pour écrire mais dingue pour relire si tu connais pas l'astuce en question.
Concernant la syntaxe, c'est tellement un avantage pour le compilo, qu'il y a peu de chance qu'elle bouge.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 1.
Y dit qui voit pas le rapport. Votre langage part du principe que les types sont en majuscule par soucis de "clareté". Bah pour la clareté on a inventé la coloration syntaxique. Nettement plus élégant que les majuscules.
Perl et Ocaml propose beaucoup de "simplification" par sucre syntaxique.
Perl est utilisé par les barbus justement parcqu'innaccessible pour ces connards de noobs.
Ocaml, c'est une des raisons qui fait qu'il est peu utilisé.
Concernant la syntaxe, c'est tellement un avantage pour le compilo, qu'il y a peu de chance qu'elle bouge.
Je comprends, pour un langage de labo, qu'on privilégie les concepts et en l'occurence tu fais plaisir au compilo.
Ce que vous comprenez pas, c'est que pour un langage de "tous les jours", il faut faire des compromis entre faire plaisir/attirer le développeur et faire plaisir aux chercheurs.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il faut vraiment tout t'expliquer ? Combien d'erreur pour simplement un mix minuscule/majuscule?
Sinon, le fait de faire plaisir au compilo permet plein de chose que veut l'utilisateur : avoir un code juste le plus rapidement possible et le binaire le plus performant possible.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Le but c'est quoi : faire ressortir les types au développeur pourqu'il s'aperçoive du premier coup qu'il y a un problème, avant de compiler. Les IDE modernes propose une couleur particulière pour les types, sans parler de la compilation en arrière plan et le soulignage en rouge pour ce type de faute.
Lisaac ignore totalement ces "avancées" et propose une alternative digne des années 70 : tout mettre en majuscule, comme ca le développeur repère plus facilement s'il a mis une minuscule quelque part par erreur.
Au passage Lisaac sacrifie une part de la lecture du type : la coloration syntaxique permet d'utiliser les minuscules/majuscules pour autre chose : distinguerLesMotsDansUnNomLong. NETTEMENTMIEUXQUENLISAACSANSPARLERQUECAFAITMALAUXYEUX.
Sinon, le fait de faire plaisir au compilo permet plein de chose que veut l'utilisateur
Ben oui mais bon vous oubliez d'attirer les développeurs débutants... le truc pourtant primordial pour un nouveau langage... le ticket d'entrée de la syntaxe vous le mettez de côté.
[^] # Re: Surprise
Posté par Antoine . Évalué à 2.
Lisaac est /peut-être innovant/, mais tu fais un travail de promotion absolument déplorable (destructeur, je dirais : ça donne vraiment l'impression que les gens qui bossent sur ce langage sont des guignols).
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Sur le coté innovant, il y a l'analyse de flot qui enlève 99.3% des VFT du code du compilateur sur 410 000 appels, tu as la detection des call sur null en statique. Tu as la gestion de l'héritage dynamique (changement du ou des pères au runtime). etc...
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Analyse qui pert une grande partie de son score dès qu'on modularise le code avec compilation séparée. Du bon boulot mais qui encourage à des pratiques inverses des pratiques conseillées traditionnellement en génie logiciel.
tu as la detection des call sur null en statique.
Idem : comment le garanties-tu en cas de compilation séparée ?
Tu as la gestion de l'héritage dynamique
Tu peux montrer un exemple de code où c'est pertinent ?
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Analyse qui pert une grande partie de son score dès qu'on modularise le code avec compilation séparée. Du bon boulot mais qui encourage à des pratiques inverses des pratiques conseillées traditionnellement en génie logiciel.
Tu confonds modularisation du code et compilation séparé. L'un n'entraine pas forcément l'autre.
Idem : comment le garanties-tu en cas de compilation séparée ?
On ne fait pas de compilation séparé pour l'instant. J'imagine que cela fonctionnera avec des tests aux interfaces... comme pour la compilation global...
Mais j'imagine que tu préfères gérer une exception au runtime.
Tu peux montrer un exemple de code où c'est pertinent ?
Un port USB qui devient une imprimante ou une clef usb, un bitmap qui change selon l'afficheur (8 16 24 bits).
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Je confonds absolument pas : je dis clairement quand "on modularise le code avec complétion séparée". Oui tu peux prendre que la première partie de la phrase mais moi je te parle de ma phrase entière.
Tu confonds modularisation du code et compilation séparé. L'un n'entraine pas forcément l'autre.
J'attend de voir ce que ca va donner quand vous aurez la compilation séparée...
Mais j'imagine que tu préfères gérer une exception au runtime.
Bien sûr que non. Avec un langage qui propose des assertions par contrat on peut éviter la plupart de ces "call sur null".
Un port USB qui devient une imprimante ou une clef usb
Pourquoi pas, je suppose donc que changer de parent nécessite tout de même de conserver un certain héritage en commun sinon c'est dangereux non ? (en l'occurence la clef USB reste un port USB)
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu es sûr que tu as compris de quoi tu parlais ?
Pourquoi pas, je suppose donc que changer de parent nécessite tout de même de conserver un certain héritage en commun sinon c'est dangereux non ? (en l'occurence la clef USB reste un port USB)
Non, ce n'est jamais dangereux. Si tu fais n'importe quoi, cela ne compile pas. Lisaac est strictement typé.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Thomas Douillard . Évalué à 2.
T'es sûr d'avoir essayé de l'expliquer ?
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le compilo attrape les "call sur nul" statiquement, sans utiliser de contrat.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
On ne le fera jamais. Cela ne sert à rien. On rend possible de faire un .o mais le but n'est pas d'en lier plusieurs mais sois de faire des plugin soit de se lier à du code autre.
On aura sans doute une découpe vertical, et non horizontal comme le C. Il faut juste être sûr de passer à l'échelle, le problème sera sans doute GCC. Et ensuite, l'interface entre module sera traité comme les IO d'un programme complet, donc toutes les détections fonctionnent pareil.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Donc là t'es en train de dire à tous les utilisateurs :
- les gars, vous compiler toujours tout.
- si vous devez compiler pour tester, vous compilerez tout.
- si vous devez compiler pour débugguer, vous compilerez tout.
- si vous devez proposer des modules interchangeable d'un point de vue déploiement, vous n'allez jamais le faire.
- si vous voulez distribuer des bibliothèques sous forme binaires, vous n'allez jamais le faire.
C'est sûr, c'est une gaçon de résoudre le problème.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.
- les gars, vous compiler toujours tout.
Oui, et c'est pas si lent.
- si vous devez compiler pour tester, vous compilerez tout.
Oui mais les bugs sont attrapé par le compilo en majorité. Une grosse parti de la compile pour être mis en cache.
L'avenir c'est le test statique par le compilo, pas le test. Cela ne passe pas à l'échelle.
- si vous devez compiler pour débugguer, vous compilerez tout.
Oui, c'est sans doute le plus chiant. Le débug, en ligne, est aussi le degré zéro de la validation, même si on n'a pas encore le choix.
- si vous devez proposer des modules interchangeable d'un point de vue déploiement, vous n'allez jamais le faire.
Si en plugin. Ensuite, j'imagine que niveau performance, cela sera beaucoup plus intéressant de distribuer des binaires complets différents. Et plus l'appli est grosse et plus cela sera intéressant par la magie de la compilation global.
- si vous voulez distribuer des bibliothèques sous forme binaires, vous n'allez jamais le faire.
Oui, sauf sous forme de plugin. J'imagine que l'on pourrait faire une sorte de paquet prédigéré pour accélérer la compilation et la distribution, faire cela juste pour l'obfuscation, c'est un peu naze surtout si il y a beaucoup d'introspection dans le langage.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
Ce qui est totalement insupportable quand on parle de phase de dev.
Oui mais les bugs sont attrapé par le compilo en majorité.
Tu vas rire, mais y'a beaucoup de bug qui sont ailleur : le compilo vérifie que le code est correct mais il vérifie pas qu'il fait ce que le développeur voudrait.
Une grosse parti de la compile pour être mis en cache.
Tu m'expliques comment tu mets en cache ce que compile GCC, la compil globale peut avoir un impact n'importe où dans le .c généré pour GCC... donc sans compilation séparée... point de salut.
Si en plugin.
Vi mais comme tu le précises, ca sera plus intéressant de faire des build différentes, bah oui car dans ce cas précis tu devras faire un choix entre perf et facilité de déploiement. Paradoxe insoluble avec la solution de la compilation globale.
Oui, sauf sous forme de plugin.
Donc pas le choix : faudra diffuser les libs sous forme de source. Point de proprio, que de l'open-source. On est sur LinuxFR, on va dire que c'est un point positif ;)
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
L'avenir c'est le test statique par le compilo, pas le test. Cela ne passe pas à l'échelle.
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur. Si dans ton programme tu remplace une addition par une soustraction, ton compilo n'a aucun moyen de savoir qu'il y a un bug.
Et ce genre de bug me demande souvent des faire de tres nombreuses compilations pour obtenir des sorties intermédiaires, faire des vérifications et autres.
Quand tu vois le temps de compilation d'un gros projet avec la compilation séparée, tu comprend que l'on soit septique quand on nous dit que lisaac ne sait pas gérer autre chose qu'une compilation globale.
Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
De manière générale, les bug qui me prennent le plus de temps sont des bugs impossible à trouver par un compilateur.
Et sur la masse total d'erreur ?
Autant pour une version finale, pas de problèmes pour un build d'une demie heure, autant pour une compilation de debugage, c'est poubelle direct.
C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Le problème c'est les «il y a des», «cela permetrait», «on pense aussi». Cela ne couvre qu'une partie des erreurs. Il va toujours en rester et il faut bien pouvoir les debugger celles la.
Et sur la masse total d'erreur ?
Ce n'est pas vraiment imprtant. On doit surement pas être loin de la regle des 80/20 ici ausssi. C'est-à-dire 20% des bugs représentent 80% du temps de débuggage. Dans mon code, j'ai des assertion pour vérifier l'indicage des tableaux et autre conneries du même style, donc généralement tous ces bigs sont résolus très rapidement.
Par contre, les bugs de logique me demandent souvent beaucoup de temps. Là ou en Lisaac je purais mettre un contrat, en C je peut mettre une assertion, donc la manière de faire est différente mais le résultat est proche.
Mais quand il n'y a pas de contrat c'est beaucoup plus dur...
Même si c'est cas ne représentent au final que 1% du nombre d'erreur, à eux seul ils peuvent représenter l'essentiel du temps de debuggage.
C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.
Sur mes programmes, je monte rarement à plus de deux ou trois minutes de compilation, donc pour moi ce n'est pas vraiment un problème, mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Si tu compile LLVM et CLang par exemple (non ce n'est pas de la provoc de compiler une aure compilo que lisaac....) La première compile prend pas loin d'une heure. Par contre, une fois que c'est fait, juste modifier une fichier source, implique de ne recompiler que ce fichier et de refaire l'édition de liens, c'est pas instantané bien sûr, mais c'est très rapide.
Tu ne refait une compilation globale avec optimisation inter-modules que pour une compilation finale.
À mon avis, c'est le genre de truc indispensable si vous voulez que Lisaac perce pour de gros projets.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En lisaac, les tableaux sont dynamiques donc, il n'y a pas d'erreur possible la dessus.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
mais il faut comprendre que des gens écrivent de très gros projets et là ça peut devenir très génant.
Je sais, c'est mon boulot "professionnel" avec des compiles qui peuvent prendre une nuit, avec des équipes de test, de validation, d'intégration, des étapes de relecture, et franchement les temps de compile qui se chiffrent en dizaine de minute, cela n'est rien du tout :)
Si tu compile LLVM et CLang par exemple (non ce n'est pas de la provoc de compiler une aure compilo que lisaac....) La première compile prend pas loin d'une heure. Par contre, une fois que c'est fait, juste modifier une fichier source, implique de ne recompiler que ce fichier et de refaire l'édition de liens, c'est pas instantané bien sûr, mais c'est très rapide.
Tu ne refait une compilation globale avec optimisation inter-modules que pour une compilation finale.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
A plus court terme, il y a à faire une sortie propre de la 0.39 sans bug et avec une doc potable, et surtout une syntaxe stabilisée. Ensuite, il faut de la réflexivité. Il y a à corriger les derniers problèmes sur COP, le modèle multitache. Il y a à trouver un moyen de tester les assertions automatiquement (par génération de vecteur d'entrée, par montecarlo, par propagation arrière,etc...).
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Un environnement de dev (langage+compilo+IDE) moderne, il te fait de la compilation en arrière plan pendant que tu codes et te surligne les fautes en live. Sans parler de la completion intelligente qui t'évite de toute façon de taper la plupart des identifiants.
Et ces environnement sont conçus pour apporter ce retour à l'utilisateur : c'est un confort et un gain de productivité énorme. Ignorer ces aspects, c'est prendre le risque de freiner la plupart des curieux qui approche le langage : ce sentiment de retour dans les années 70 va leur faire mal au c...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Donc je le répète : langage + libs + outils forment un tout, ils doivent être conçus ensemble et pour répondre aux différents cas d'utilisation des développeurs.
Le tout n'est pas d'avoir un bon langage ou un bon compilateur ou une bonne bibliothèque, il faut une plateforme complète qui soit cohérente, avec des compromis, et qui soit utilisable.
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
J'en ai rien a battre puisque comme je te le dit ce genre d'erreur est détecter rapidos par les assertion et ne représente qu'une fraction minime du temps de debuggage.
D'ailleurs, qu'est-ce qui fait que le code est plus propre et sans bug dans Octave mais pas en C ?
Principalement la notion vectorielle et les fonction de manipulation des matrice de haut niveau. Mais on s'en fout ici. Le truc c'est que j'ai une version de référence et que je veut comparer mon programe à cette référence et que vu les volumes de données, la seule solution raisonable ici, est de sortir des logs ce qui impose des recompilations.
Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure.
Encore completement à côtè de la plaque, je t'explique qu'il y a des projet ou il faut 1h voir plus pour tout compiler et seulement une ou deux minutes quand on fait de la compilation modulaire. Et toi tu me répond que tu en as rien a battre de leur gueule car ton compilo ce compile en quelques minutes.
Tu crois vraiment que tu me donne envie d'écrire un gros projet en Lisaac : «oui, bonjour monsieur. en effet votre programe prend 2h a compiler pour une modif d'une ligne, mais ce n'est pas grave, le compilateur qui est aussi lent ce compile lui en moins de 2minutes sur le processeur de votre montre.»
A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.
Tu finis par avouer que c'est quand même pas mal d'avoir de la compilation modulaire... Le truc c'est que «un jour» c'est trop tard pour un projet qui démare maintenat, donc faut pas venir ce plaindre que personne veut utiliser votre langage.
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 3.
Mais quand il n'y a pas de contrat c'est beaucoup plus dur...
Sauf qu'en SmartEiffel (c'est là que ça a été inventé) et en Lisaac, tes contrats sont hérités. Et de l'aveur de Dominique Colnet, il lui arrive assez souvent que son code pète sur un contrat posé il y a longtemps et assez haut dans l'arbre d'héritage.
Le fait qu'ils s'accumulent, et que tu puissent les poser sur du bas niveau (vu que tout est objet, tu peux les poser sur toutes les opérations), c'est un peu mieux que les asserts de C.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Philip Marlowe . Évalué à 2.
Les contrats sont dans la spécification initiale du langage Eiffel (à une époque où il n'y avait encore aucune implémentation). SmartEiffel est une implémentation particulière de ce langage. De plus en plus particulière...
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 3.
Peut-être que les contrats hérités de Lisaac ou autre sont mieux que les assertions, mais ça ne change pas le fait qu'ils ne détecterons pas les bugs qui me prennent le plus de temps à corriger et qui parfois nécéssitent des techniques de debuggage particulière telles que de multiple compilations avec génération de logs.
Donc on en reviens au même point, dire que la compilation par module n'est pas utile et vive les optimisations globales, c'est réducteur. Et, à mon avis, Lisaac n'est pour l'instant pas un bon choix de ce point de vue pour un gros projet.
On a ici un bon exemple de ce que j'ai du mal à apprécier dans les journeaux et news sur Lisaac et que j'ai éssayer plusieur fois d'expliquer. Si on prend le message de NB http://linuxfr.org/comments/1087340.html#1087340 il dit à propos de la compilation séparée :
«On ne le fera jamais. Cela ne sert à rien. On rend possible de faire un .o mais le but n'est pas d'en lier plusieurs mais sois de faire des plugin soit de se lier à du code autre.»
C'est un point de vue relativement tranché, auquel TIM répond par :
«Donc là t'es en train de dire à tous les utilisateurs :
- si vous devez compiler pour tester, vous compilerez tout.
- si vous devez compiler pour débugguer, vous compilerez tout.»
C'est une réponse un peu provocante mais qui n'a rien de particulier dans ce journal, ils donne des cas ou l'on a envie de faire de la compilation séparée. Ce qu'on peut lui reprocher c'est de ne pas vraiment détailler pourquoi on veut une compilation séparée.
Mais NB montre qu'il a bien compris le problème quand on voit sa réponse, donc pas de problème de clartée :
«Cette découpe n'existait que pour des raisons des capacités d 'un compilo sur des machines des années 80. Depuis, on a un peu plus de patates sous le pieds.
Le compilo Lisaac se compile en quelques seconde sur un atom (50kloc ?). C'est gcc qui rame ensuite quelques minutes.»
C'est encore très tranché. Et surtout un détail qui m'avait échapé, il dit que lisaac se compile en quelques secondes mais que GCC fait ramer le tout. Donc en gros lisaac c'est plus que quelques secondes de compilation... C'est quelques minutes pour un «petit» programme de 50kloc. Sur un gros projets ça va devenir ingérable.
Et il ajoute : «les bugs sont attrapé par le compilo en majorité.» à quoi je lui répond que tout les bugs ne peuvent pas être attrapé de cette manière.
Et la ça dérape, avec quelques messages pour montrer que sur un gros projets une compilation globale c'est pas gérable dans tous les cas, et expliquer qu'il y a des bug que l'on ne peut pas débugger sans refaire plusieurs compilation, on obtient comme réponses à côté de la plaque.
NB admet quand même que «C'est quelques minutes pour le compilateur au total. C'est supportable. Mais je suis d'accord que la série test/erreur n'est pas jouable avec des trucs trop long.»
Sauf que quelques minute peu devenir une heure ou plus sur un gros projet, et on a l'impression qu'il admet plus qu'il ne faut pas faire du debuggage test/erreur même s'il n'y a que ça de possible.
Ensuite, après avoir détailler le cas d'exemple pour mieux faire comprendre, on se prend encore une réponse qui n'a rien à voir avec le shmilblic suivit de :
«Je suis d'accord sauf que compiler le compilateur Lisaac sur un atom doit prendre quelques minutes, on ne parle pas d'une heure. Il y a encore de la marge sur la manière de gérer la compilation "pour le debug" par rapport à la compilation "pour une release".»
La c'est de la mauvaise foi. On dit que pour un gros projet, avec une compilation longue c'est un problème, et on me répond que pour un autre projet, bien plus petit, la compilation est rapide !!!
Si je vais voir un vendeur en lui disant «les pommes que vous m'avez vendues sont pourries» il ne vas pas me répondre «oui mais mes poires que j'ai vendue à votre voisin ne le sont pas». On s'en fou que lisaac ce compile super vite, nous on va le compiler au pire une fois, alors que notre projet qu'on doit débugger et qui prend une heure à compiler, on va devoir le faire plusieur fois par jour peut-être.
Il y a une petite lueur d'espoir apres. Alors que le fil est partit d'une affirmation comme quoi la compilation séparée ne sert à rien et date de la préhistoire, on obtient un :
«A terme, il pourrait y avoir une solution intermédiaire avec une déclaration de prototype à compiler ensemble et donc qui serait recompiler dans leur coin, sans avoir besoin de compiler tout le projet pour le debug. Lisaac génèrerait 2 .c, et un seul bouge, le plus petit. Mais c'est le futur. Sur un horizon de 2 ans, je dirais.»
On se dit que peut-être sur ce cas, un jour ça marchera. Mais en même temps, on nous dit souvent qu'il est domage qu'il n'y ait pas plus de gens à dévelloper en lisaac... Moi, ça ne me donne pas envie.
Et la tu arrive pour me dire que «oui mais, au lieu de mettre des assertions, tu met des contrats hérité, c'est bien mieux»
Sauf que ça n'a aucun rapport... Les bugs que l'on peut détecter par contrat on peut aussi les détecter par assertion. Au pire je vais oublier de mettre une assertion et ton héritage la met automatiquement. Mais ça ne change rien au problème des bugs qui ne peuvent pas être détecter avec c'est méthodes.
C'est super les contrats pour vérifier les bornes ou les invariants ou autres, mais ça ne marche pas pour tout. Je me suis fait chiez à expliquer un exemple ou il n'y a pas vraiment l choix et ou un contrat qu'il soit hériter ou pas ne change rien.
Ça donne vraiment l'impression classique des discution autour de lisaac avec sa communauté. Quand on montre un problème lié à Lisaac, ça commence par une levée de bouclier dans le genre «Lisaac c'est génial, nous on fait les chose bien les autres le font mal» et ensuite si on réussit à montrer que vous avez tord, on arrive parfois à vous arrachez un petit «tu as peut-être vaguement raison dans un univers parallel» et le plus souvent on à le droit à un «mais nous on a ce truc qui n'a rien à voir et qui ne résoud pas ton problème mais qui est vachement cool».
Je suis désolé, mais moi ça ne me donne pas envie. C'est pourtant pas compliqué d'expliqué que «pour l'instant on ne fait que de la compilation globale car ça nous permet de faire plein de super optimisations, mais c'est vrai que ça pose des problèmes avec les gros projets».
Ensuite soit tu rajoute «on admet le problème mais notre cible actuelle est les projets de taille raisonable qui ne sont pas génés par cela» ou «on y réfléchit et ce sera implémenter dans le futur».
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
PS: Je ne prétend pas détenir la vérité absolue et j'admet que ce que je dis dans ce message est mon interprétation de ce qui c'est dit ici. Mais si j'ai mal interpreté vos propos, je ne suis peut-être pas le seul, et si Lisaac est autant un sujet à troll c'est peut-être que l'on est nombreux à pas vous comprendre correctement.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 1.
C'est trop mignon :)
Sinon t'as totalement raison.
J'ajouterai que le plus important dans tout ça, c'est qu'ils retiennent que si les autres langages ne sont pas conçus comme le leur, c'est pas parcqu'ils sont pourris mais parcqu'il cible un public bien différent.
La conclusion, c'est qu'ils arrêtent de prétendre que Lisaac c'est LE langage C-killer parcque de haut niveau et avec les même perfs.
Parcque des langages de haut niveau qui remplace le C, y'en a une palanquée. Non, vraiment la différence c'est que Lisaac n'adresse (et ne peut adresser de par ses défauts/avantages conceptuels) qu'un public bien précis de développeurs C : ceux qui font de l'embarqué, de préférence sur de petits projet, de préférence sur du matériel exotique sans émulateur et de préférence avec des contraintes de performances ET de fiabilité.
Pour le reste, passez votre chemin, c'est pas pour vous.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
L'étape d'après, qui n'est pas encore implémenté, serait d'avoir un système de waveforme comme pour le hardware. En hardware, avoir 10 Go de log ne pose de problèmes à personne. Et si c'est le cas, on peut encore passer avec une sorte de débogueur embarqué pour couper les sorties inutiles au runtime.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 4.
Tu peux aller beaucoup plus loin que les tests de bornes.
Alors certe, cela contrainte à en mettre partout, mais cela diminue beaucoup le travail pour des tests . Cela ne va pas te trouver le signe faux directement. Au mieux cela te pointe le bon slot.
Le truc c'est que ça ne change rien au schmilblic. Pour les vérifs dont tu parle, il faut qu'il y en ais des propriétés testables et c'est pas toujours le cas.
Dans mon cas, c'est un algo itératif qui converge vers un optimum, l'opération en question était destinée à corriger certains comportements très particulier de l'algo dans des cas rares qui produisent une instabilité.
L'algo va quand même converger, mais sur certaines dimension il va osciller pendant plusieurs itérations avant de réussir à sortir de la configuration particulière.
Donc, les assertions qui vérifie que globalement on converge ne sont pas levées puisque l'on continue de converger. On converge beaucoup plus lentement mais on ne peut pas savoir que ça devrait être plus rapide.
Et on ne peut pas mettre d'assertions sur l'instabilité car ces un comportement qui ne peut être vérifié que sur un grand nombre d'itérations. Une instabilité sur deux ou trois itération c'est normal, sur plus d'une dizaine ça doit être corrigé. Et garder en mémoire les valeurs des dix dernière itération c'est tout simplement impossible.
Je ne vais pas rentrer dans les détails du système mais la vérification des propriétés n'est absolument pas une solution miracle, tout comme le debuggage à coup de log.
Il faut bien voir qu'il y a plein de manière de debugger et quelle sont toutes complémentaires. Dans mon cas, le programme en question c'est parfois plusieurs jours de calculs avec des problèmes qui ne se manifestent que sur de gros volumes de données et très difficiles à cibler, donc le debuggeur interactif, c'est pas vraiment gérable.
C'est des morceaux de code ou des vérifications complexes reviendrais à rajouter 4 fois plus de code que l'existant et qui donc contiendrais surement 4 fois plus de bugs.
Le coeur de l'algo fait en gros 400 lignes de C. C'est pas beaucoup mais ça reste très complexe à debugger. Tu rajoute à un peu plus d'une centaine de lignes de commentaires, et un peu moins de 200 lignes d'assertions.
Si je le transforme en Lisaac, du peu d'experience que j'ai dans ce langage, j'ai pas l'impression que le nombre de lignes de code va changer. C'est vraiment des math brutal, il y a rien du style allocation memoire ou autre. C'est juste des boucles, des if et des calculs.
La seule différence qu'il y aura ce sont les assertion qui deviennent des contrats, donc rien de plus facile pour debugger.
C'est même pire avec les contrats... Actuellement j'ai 6 types d'assertions différentes qui ne sont pas tous activés en même temps. Certains test sont peu couteux et peuvent rester en permanence, mais d'autre sont très couteux et ne sont activé que quand il y en as besoin, générallement sur des jeux de données petits ou avant le week-end.
A ma connaissance, ce genre de vérification sélective n'est pas simple à faire avec des contrats. C'est plus du tout ou rien.
Concernant la compilation globale, mon propos était de dire que tu peux avoir des temps de compilation court sans devoir passer en compilation partiel. Et uniquement ça.
L'exemple que j'ai en tête c'est le mode de fonctionnement de synplify de simplicity (c'est un synthétiseur pour FPGA) qui fonctionne avec une grosse base de donnée et fonctionne avec un diff en interne du code VHDL quand il y a une nouvelle synthèse.
Pour Lisaac, le problème reste toujours la génération du .c et le temps de compilation associé avec gcc. C'est pour ça que j'avais parlé de système ou tu choisis les regroupements de prototypes pour la compilation. Cela permet de changer que le bout de programme qui t'intéresse. Ou encore, on passe dans un mode "un fichier par fonction" en espérant que la compilation global ne va pas tous les changer. Cela fait parti des améliorations pour "le mode compilation pour le debug".
C'est bien beau tout ça, mais quand ? Ça à quand même l'air d'être pour dans longtemps. Ce n'est pas une critique mais ça veut dire que pour un gros projet c'es pas pour tout de suite, donc pour un gros projet Lisaac n'est pas adapté.
Je prend un autre exemple ou une compilation rapide est presque indispensable : un projet colaboratif ou la compilation commence à être longue.
Dans ce genre de projet, quand tu soumet un fonctionalité, la politesse veut que tu découpe ton gros patch en plusieurs petits patch progressif qui peuvent être testé un par un, et approuvé un par un. Pour la libdispatch par exemple, il y a eu un patch il y a peu découpé en 17 petits-patchs. Cela veut dire pour celui qui soumet 17 compilation pour vérifier à chaque fois que le patch marche bien donc beaucoup de temps s'il faut tout recompiler. Et autant de compilation pour tout ceux qui testent les patchs.
Sachant que génarallement il y a des remarques et des petites modifs à faire, c'est beaucoup de temps au final.
Et pourtant la libdispatch n'est pas un si gros projets que ça au final et des patch de ce genre son pas des cas rares.
Donc Lisaac a, à mon avis, un manque à ce niveau là. Encore une fois, ce n'est pas une critique du langage en lui-même, mais quand tu en parles, il faut accepter cette limitation et dire que ça changera, mais surtout admettre que au moins pour l'instant il n'est pas adapté.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 5.
Tout ce que tu peut faire en Octave peut être fait en C bien sur, mais de manière bien plus complexe. L'avantage de Octave est que la notation est beaucoup plus proche des formules mathématiques que l'on écrit et est beaucoup plus concise. Elle donc bien plus facilement vérifiable.
Un exemple tout con, j'ai un décodage de Viterbi à un moment, une des opérations nécessaire consiste à prendre une matrice et pour chaque ligne, chercher la plus grande valeur. Il faut stocker pour chaque lignes, la valeur maximale et son indice.
En Octave, cela ce code
val, idx = max(M')M étant la matrice en question, que l'on transpose et sur laquelle on appelle la fonction max. Elle retourne le vecteur val qui contient les valeurs maximales, et le vecteur idx qui contient les indices.Maintenant en C, c'est beaucoup moins trivial. Bien sur, on peut utiliser des libs toutes faites, mais cela implique de stocker dde nombreuse valeurs intermédiaires, ce qui n'est pas possible dans notre cas vu la taille de tout ces éléments.
Il faut donc coder tout cela avec des boucles, en tenant compte du fait que les matrices sont stocker en column-major (car de manière globale pour les calculs que l'on fait, c'est l'ordre le plus pratique.
Donc pour éviter d'avoir des cache-miss en permanence il faut travail dans un ordre qui n'est pas spécialement logique, c'est-à-dire que l'on ne calcul pas le max d'une ligne puis le suivant, mais toutes les lignes en même temps. Ça permet d'avoir des patterns d'accès mémoire très prévisibles par le processeur et presque aucun cache-miss.
La version en Octave n'est absolument pas optimisée et construit explicitement en mémoire de nombreuses matrices intermédiaires et donc, est lente à mourir car, dès que les données deviennent un peu importantes, elle swap énormément.
Mais par contre, le code est très simple et parfaitement lisible car très proche de la description mathématique de l'algo et donc très facilement vérifiable.
La version en C est prévue pour stocker complètement aucune matrices intermédiaire, ce qui implique de travailler par blocs, donc des niveaux de boucles supplémentaire et du code pour gérer les limites entre blocs.
Donc cela donne très rapidement un code beaucoup plus dur à comprendre, mais plusieurs ordres de grandeurs plus rapide.
Pour donner une idée, la version octave ne peut gérer de manière réaliste des modèle de plus de 100000 éléments, là ou la version en C est encore loin de ses limites avec un modèle de 1.3 milliard d'éléments.
La version en Octave permet de valider l'algorithme et d'obtenir une implémentation de référence. Celle est C permet de travailler sur des données réelles dans des condition correcte avec des temps de calculs raisonnables.
Le code en C à été relu de nombreuse fois et possède de nombreuses vérifications, mais ce n'est pas suffisant pour être sur de sa validité. Ce genre de code est à peu près impossible à prouver, le meilleur outils que l'on a pour l'instant pour être à peu près sûr qu'il fait ce que l'on pense c'est de vérifier qu'il donne les même résultats qu'une autre implémentation indépendante qu'il elle est bien plus facilement vérifiable.
Bien sûr on est loin d'une preuve absolue, mais c'est le mieux que l'on puisse faire pour l'instant et c'est le prix à payer pour pouvoir travailler avec d'aussi gros modèles.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'ai tout bon ?
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Le problème est que ce n'est pas réalisable pas plus qu'un compilateur qui prend l'algo en Octave et qui me pond un programme aussi rapide et peu gourmand en mémoire que ma version en C.
Un bon compilateur pourrait éventuellement s'apercevoir que certains vecteurs et matrice intermédiaires n'on pas à être conservé et factoriser le code. Pour d'autre endroits, il pourrait voir que tous les traitement sont indépendants et donc paralleliser le code ou faire du striping.
Mais, il sera incapable de gérer tous les cas que j'ai eu à résoudre ici, notament les calculs qui permettent de gérer les valeurs au limites des blocs, ou il faut réellement inventer la manière de faire le calcul, elle n'est pas dans le code pour octave. Ou encore des réorganisation complètes de l'ordre dans lequel sont fait les calculs, pour obtenir un calcul théoriquement plus long mais qui en fait permet un meilleur traitement en flux avec moins de valeur intermédiaires à stocker.
Mais si tu invente un compilateur capable de faire ça, tu va faire fortune.
J'évite au maximum d'optimiser et je préfère que ce soit le compilateur qui le fasse à ma place, mais il faut pas oublier qu'il a des limites...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Mais avant de savoir ce qu'il est possible de faire ou de ne pas faire, il faut déjà avoir une idée assez précise de ce que l'on voudrait.
C'est vraiment dommage que ton code soit fermé. Cela aurait fait une bonne référence, pour un bench pour voir l'effet d'optimisation.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Je ne veut pas être méchant, mais avant de songer à ce genre d'optimisation, qui ont l'inconvénient d'être à la fois extrêmement complexe à implémenter sans faire de conneries et applicable dans très peu de cas, il faudrait peut-être trouver une solution pour des optimisations plus utiles.
La vectorisation du code est généralement beaucoup plus efficace que l'optimisation des caches car la majorité du code accède à la mémoire avec des motifs facilement identifiables par le processeur. À par sur des cas précis comme celui-là, j'ai rarement recours à ce genre de techniques. En plus le code est spécifique à un modèle de processeur car la taille des blocs doit être choisie en fonction de la taille des lignes de cache.
Par contre la vectorisation du code apporte généralement beaucoup plus et surtout s'applique dans bien plus de cas. Et coup de bol, il y a moyen de ce comparer à d'autre compilateurs et il y a même des benchs qui trainent sur le net.
Mais la on tombe sur une limitation de Lisaac, le fait de générer du C89 à l'avantage d'être portable mais empêche tout optimisation de ce côté, vous êtes obligé de croisé les doigts pour que le compilateur C en dessous réussisse à faire ce boulot.
C'est vraiment dommage que ton code soit fermé. Cela aurait fait une bonne référence, pour un bench pour voir l'effet d'optimisation.
On choisit pas toujours ce que l'on peut faire de son code... Mais si ça peut te faire plaisir une version plus simple du code devrait être disponible dans quelques temps, mais pas en Lisaac, juste en C.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je pense que si il produit autre chose, cela sera du "C99 gcc" avec les bonnes extensions.
Concernant la vectorisation automatique, gcc en fait déjà pas mal tout seul comme un grand. Je penche plutôt sur le fait de faire des boucles qui s'automatise facilement. Vu la quantité de matière grise mis sur ce genre de problématique, je ne pense pas que l'on puisse faire une grosse différence.
Donc, en gros, on pense s'appuyer sur GCC pour faire la vectorisation, et sur l'utilisation de lib qui manipulerait directement soit les types vectoriels de Gcc ("v4sf",etc...), soit de l'assembleur mais c'est encore moins portable.
Concernant la taille de blocs en fonction du cache, on peut faire 2 stratégies : l'une dynamique en utilisant une lib qui donne la taille des caches, l'autre qui prend une taille "catch all" : 32 Ko qui correspond à une taille très courante de cache L1.
Concernant les versions de ton code, la version octave serait aussi utile pour l'utiliser comme version "haut niveau" de référence pour coder en Lisaac.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Je pense que si il produit autre chose, cela sera du "C99 gcc" avec les bonnes extensions.
Je ne mélange pas tout, je dit juste que, à mon avis, si votre objectif est de produire du code rapide, il faut mettre des priorités sur les optimisation à implémenter, et si ce n'est pas votre objectif, ça ne sert à rien de continuer la discution.
Implémenter des optimisation extrêmement complexes de ce type c'est prendre le risque d'introduire des erreurs dans le code généré et de rendre le compilateur très complexe pour des cas relativement rare.
Par contre la vectorisation, bien que complexe, à fait l'objet de bien plus de recherche et va s'appliquer dans beaucoup plus de cas. Donc moin de risque pour un plus gros gain. Il me semble plus pertinent de commencer par la.
Et donc je soulevais le problème du fait que Lisaac pour l'instant produit du code c89 donc la vectorisation n'est pas directement possible.
Concernant la vectorisation automatique, gcc en fait déjà pas mal tout seul comme un grand. Je penche plutôt sur le fait de faire des boucles qui s'automatise facilement. Vu la quantité de matière grise mis sur ce genre de problématique, je ne pense pas que l'on puisse faire une grosse différence.
Lisaac à une vision plus haut niveau du code, à mon avis il doit y avoir plein de cas ou gcc ne peut pas vectoriser le code mais ou lissac possède lui les informations pour le faire.
Même si gcc est très bon pour ce genre de choses, les motifs qu'il est capable de paralléliser restent très limités, et bien souvent il suffit qu'il y ait un pointeur qui traine pour tout foutre en l'air. Dans la pratique, écrire du code que gcc peut paralléliser est souvent au moins aussi complexe que d'écrire directement le code parallèle avec les intrinsics. Et le plus embêtant c'est que la moindre petite modification anodine peut rendre le code non parallélisable, donc un patch par quelqu'un qui ne fait pas super gaffe peut-être catastrophique.
Concernant la taille de blocs en fonction du cache, on peut faire 2 stratégies : l'une dynamique en utilisant une lib qui donne la taille des caches, l'autre qui prend une taille "catch all" : 32 Ko qui correspond à une taille très courante de cache L1.
Le problème c'est qu'optimiser pour le cache est à double tranchant. Il y a trois cas à considérer :
- tu as la bonne taille pour remplir exactement le cache comme il faut et le code est très rapide ;
- tu as exactement la bonne taille pour que le cache soit pourit à mort, et la tu as un code affreusement lent ;
- le reste ou tu as une quantité classique de cache miss et un code de vitesse normale.
Et mon experience à ce niveau la me fait dire que quand tu ne fais rien de spécial, tu est à peu près toujours dans le cas 3, mais des que tu cherche à faire des trucs un peu intelligent tu tombe le plus souvent dans le cas 2 et il faut faire pas mal d'essais avec différentes tailles pour réussir à tomber dans le cas 1.
Donc si tu ne connais pas la taille du cache, il vaut mieux ne rien faire, et si tu connais la taille du cache, trouver la bonne taile pour tes blocs est souvent possible uniquement de manière empirique.
Je suis loin d'etre persuader qu'un compilateur puisse le faire automatquement avant un bon bout de temps, les éléments à prendre en compte sont tellement nombreux et différents dans chaque cas. Pour plus d'infos tu peut regarder les manuels d'optimisation d'agner qui décrit bien le problème.
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 2.
Je me réfère souvent à cette page du projet GCC ( http://gcc.gnu.org/projects/tree-ssa/vectorization.html ) qui décrit quelles type d'écriture sont éligible à l'autovectorisation (utilisation de MMX, SSE, etc...)
Parles-tu de ce genre de vectorisation ou d'autre choses ?
S'il s'agit de ce genre de vectorisation, en quoi le C89 a t-il a voir avec ce genre d'écriture ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 2.
Le compilateur Lisaac a accès à une sémantique très "bas niveau" des calculs à effectuer, car les nombres sont tous des objets, et les opérateurs sont tous des messages classiques d'objets, à part les quelques primitives ( - , / , * , << ).
Comme les boucles sont elles mêmes déroulées de manière complète dans le langage très minimaliste en interne du compilateur, détecter des patterns de calculs afin de les optimiser au poil pour que GCC autovectorise, n'est pas insurmontable.
De plus, comme les boucles sont très uniformes de par le fait qu'elles sont définies en librairie, il est facile de les détecter et de cracher du C autovectorisable.
En C, ecrire du code autovectorisable est très difficile, mais pour un langage où le modèle est uniforme et assez minimaliste (c'est donc valable pour quelques langages), la simplicité fait que les patterns reviennent toujours au même et que leur détection en est ainsi facilitée.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Je parlais de cela dans le sens ou Lisaac ne sera pas capable de produire d'autres forme de vectorisations que celle que gcc gère, et il est très contraint par les formes reconnues par gcc, don pas trop d'imbrication de ces boucles et de combinaison simples.
J'ai citer ce type d'optimisation car je pense que c'est bien plus profitable que d'essayer (et à mon avis de rater, vu la difficultée) de faire automatiquement les optimisation que j'ai fait à la main. Et je pensais plutôt à la possibilité d'utiliser les intrinsics pour les cas ou lisaac peut vectoriser mais ne peut pas transmettre l'optimisation à gcc. (désactivable bien sur)
Ce n'était pas une critique du fait que lisaac est limité au c89, plutôt une remarque sur cette limitation et le fait qu'optionellement lever cette restriction permettrait de faire des optimisations bien profitable que ce que nicolas proposait.
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Je disais juste qu'a mon avis certaines optimisation font bien plus de mal qu'autre chose, au moins pour l'instant. Pourquoi vouloir faire très compliqué, risqué et peu-utile en général, quand il y a moyen de faire compliqué, moins risqué et très utile ?
Contrairement à ce que tu dis, faire mieux que gcc en matière de vectorisation n'est pas si complexe (tout est relatif bien sur....)
Le langage C est tel qu'il est difficilement vectorisable automatiquement, à cause des pointeurs ou de la sémantique complexe de certaines constructions notamment. Les boucles vectorisable doivent avoir des formes simples et correspondre aux motif connus, ce qui rend l'écriture de ces boucles généralement difficiles.
En Lisaac par contre, il y a beaucoup moins d'ambigüité et bien plus de sémantique dans les constructions, donc la vectorisation est plus simple. Que ce soit juste réécrire les boucles pour que gcc puisse les optimiser ou utiliser les intrinsics ça reste quand même bien plus profitable.
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 2.
Tout-à-fait, désolé j'avais oublié le lien.
Le 1er guide est un must-read pour toute personne qui veut optimiser son code serieusement plutôt qu'avec les recette de sa grand-mère.
Le 3ème est aussi très intéressant pour les optimisations de haut niveau notament la partie sur la prédiction de branchement. Comprendre ce qui ce passe dans le processeur est un énorme atout pour l'optimisation plus hardcore.
Il y a bien longtemps que je n'ai pas écrit d'assembleur, par contre je lit très souvent le code produit par le compilateur pour voir ce qu'il produit et chercher ce que je pourrais faire pour l'aider à mieux comprendre ce que je veux et l'aider à écrire du meilleur code.
Le 5 est à feuilleter une fois juste pour bien voir ce que coute chaque paramètres lors d'un appel, mais ça reste négligeable. Globalement c'est pas vraiment là qu'il y a gagner. La plupart des optimisation la dessus rendent le code bien moins lisible et pas vraiment plus rapide.
Le 2 et le 4 sont, pour moi, intéressant uniquement pour l'utilisation des instruction SIMD via les intrinsics. Ils seront très utile à des personnes qui écrive des compilateurs mais ce n'est plus mon cas.
Ce qui me sert le plus ce sont les timing des instructions SIMD pour justement tous les cas ou GCC ne pourra rien faire.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pour te donner l'anecdote, lors des premiers test du code mpeg2, lisaac était à 15% de l'exemple en C en utilisant gcc 2.95. Quelques années plus tard et une bonne dose d'optimisation de lisaac, l'exemple C est toujours 15% plus rapide. Pourquoi ?car gcc 4.3 donne du code 30% plus rapide que gcc 2.95.
Il est inutile de vouloir courir en parallèle de gcc, il sera toujours plus rapide. L'idée est de réutiliser au maximum ses avancés. Si on reste haut niveau, toutes les optimisations restent valable avec d'autres compilateurs.
La vectorisation est à la limite. Par exemple, gcc vient d'introduire Graphite ( http://en.wikipedia.org/wiki/Polytope_model ) pour réduire les boucles. C'est un an de boulot minimum pour l'intégrer dans un compilateur. Et pourtant les perspectives sont énormes en optimisation haut niveau (et avec des maths complexes). D'un autre coté, on utilise gcc et gcc utilise déjà cette optimisation. Pour lisaac, il "suffit" de produire du code gentil pour gcc (pas de pointeur, beaucoup de scalaire,...)
Il faut voir aussi que Ben fait de la recherche. Il ne peut pas "vendre" un papier sur une technologie avec autant de papier que l'auto-vectorisation.
Le projet a plus d'intérêt à partir sur des optimisations hors de porté de gcc. Par exemple, on pourrait faire la chasse au copie inutile ou au tableau temporaire.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Beaucoup de lecture en perspective !
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
http://chl.be/glmf/articles.linuxmag-france.org/lm32/hackC.h(...)
Concernant le timing des instructions, il faut voir qu'il s'agit de minimal donc, sans cache miss, sans page miss, sans erreur de prédiction de branchement. Cela peut rajouter des dizaine à des centaines de cycles au timing indiqué..
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Ontologia (site web personnel) . Évalué à 2.
C'est ce que je pense, et je crois savoir que c'est ce que pense l'auteur du Lisaac.
On priorise comme on peut, tellement le roadmap est chargé.
La compilation séparée est un objectif depuis longtemps, mais ça pose pas mal de problèmes, car comme c'est quand même un projet de recherche, il y a pas mal de choses à inventer pour combiner le meilleur des deux techniques.
Ce n'est pas une honte d'avoir des limitations dans le langage, mais il faut être capable de l'admettre et éviter de mentir ou de répondre à côté de la plaque aux utilisateurs, sinon ils fuient.
Où as-tu lu dans ce journal que je n'admettais pas qu'il y avait de limitations dans le langage ?
J'ai juste parlé des contrats hérités.. Ne me fait pas de procès d'intentions s'il te plait.
Évidemment que je l'admet, évidemment que le chemin est encore long et que le produit a beaucoup de limites.
Où ais-je dis le contraire sur ce journal ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Surprise
Posté par beagf (site web personnel) . Évalué à 1.
Il suffit de regarder ce journal pour comprendre ce dont je parle.
[^] # Re: Surprise
Posté par Philip Marlowe . Évalué à 2.
Chez Eiffel Software, qui propose un compilateur Eiffel, donc avec la programmation par contrat (qu'on utilise en produisant des assertions), ils ont dû trouver, mais ils ne doivent pas avoir ton niveau, que celle-ci ne permet pas totalement d'éviter les void calls. C'est pourquoi, avec la dernière mouture du compilateur/environnement de développement, il y a un mécanisme spécifique pour résoudre le problème avant la compilation.
Un peu de lecture :
http://qconlondon.com/london-2009/presentation/Null+Referenc(...)
http://www.ddj.com/architect/219500827?cid=RSSfeed_DDJ_All
Alors, oui, éviter les void calls avant l'exécution, ça vaut le coup. Merci à l'équipe de Lisaac pour ça. Et non, le recours aux contrats et autres assertions ne peut pas les éviter totalement. C'est le totalement qui est important.
Incidemment, mettre les noms de classes et de types en majuscules ne me dérange pas, c'est déjà ce que je fais :) Je sais, je suis minoritaire...
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Philip Marlowe . Évalué à 2.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 0.
Désolé pour la pique, mais bon vous semblez pas vraiment au fait de ce qui se fait depuis un bon moment déjà...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Comment tu peux te croire tellement supérieur aux autres pour croire que l'on ne connait pas comment fonctionne un JIT ?
Continues de défendre tes dieux américains et fichent nous la paix.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 1.
Attend, je te recites pour voir :
"C'est facile pour n'importe quel jit de sauver les parties de binaires converti. Il reste tout de même une énorme part d'interprétation. C'est obligatoire par exemple pour garder fonctionnel tous les mécanismes de sécurité, si le code est "purement natif" comme un code compilé, il peut faire ce qu'il veut. "
T'affirmes des trucs alors que ca fait 10 ans que la réalité te donne tord. Pas de ma faute à moi.
Continues de défendre tes dieux américains et fichent nous la paix.
Pauvre choupinet, faut pas venir sur trollFr avec un journal pour venter les mérites d'un langage (c'est pas une version révolutionnaire, donc à quoi bon ce journal ci ce n'est faire de la pub pour le langage ?) en commencant l'intro par "Lisaac est le seul langage à prototype compilé."
Et puis bon le côté bon français moi je supporte pas les technos des ricains, c'est du joli.
On parle de techno, rien à foutre de l'origine. En tout cas ca explique que vous soyez pas au fait de l'état de l'art, qui s'établi de part et d'autre de l'atlantique...
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
J'admire le bon trolleur de base qui s'arrête à la première phrase du journal.
Et les mécanisme de VM n'ont rien de supérieur au mécanisme natif, c'est juste un choix différent mais tu dois être trop limité (aveuglé ?) pour t'en rendre compte.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
Désolé de comparer avec ce que je connais. Je suis pas spécialement "pro-Java" et pourtant j'ai pris soin d'en parler également. J'ai également parlé de JavaScript, pourtant je supporte pas ce langage.
Et les mécanisme de VM n'ont rien de supérieur au mécanisme natif,
Disons qu'ils répondent pas aux mêmes besoins, n'offrent pas les mêmes services.
Après oui je suis à titre personnel plus intéressé par les technos qui offrent des modèles de sécurités fiable pour faire des applis et dans le futur des OS que les technos qui visent les perfs. Après il en faut pour tous les goûts.
Mais effectivement, je suis souvent agressif sur les journaux Lisaac, parcque quand c'est pas toi, c'est Ontologia, et votre verbiage sur le soit disant meilleur langage que-vous-savez même-pas-argumenter-faut-systématiquement-demander-au gourou c'est assez pénible.
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: Surprise
Posté par Philip Marlowe . Évalué à 3.
C'est que tu ne vois pas l'intérêt de pouvoir utiliser un langage de haut niveau qui permet de faire de la programmation système, proche du matériel, et qui permet d'adresser des cibles en 16, 32 et 64 bits. Si tu n'en as pas besoin, on ne t'en veut pas, c'est juste que ce n'est pas ton problème.
Ceux qui font de la programmation pour l'embarqué peuvent être autrement intéressés.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Surprise
Posté par Philip Marlowe . Évalué à 3.
Je ne vois dans cette phrase rien qui revendique un quelconque caractère révolutionnaire ou avant-gardiste. Nulle part il n'est demandé au lecteur de s'extasier devant la caractéristique annoncée. C'est tout bonnement de l'information, il n'y a pas de quoi péter un câble, ou le trollomètre.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Surprise
Posté par Philip Marlowe . Évalué à 3.
[^] # Re: Surprise
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Surprise
Posté par Antoine . Évalué à 2.
[^] # Re: Surprise
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Ah ?
Change d'éditeur de texte, ou apprend à l'utiliser, car n'importe quel programmeur Lisp (et dérivés) te dira qu'il n'a jamais à gérer la moindre parenthèse lui même…
Je me fais bien plus ch/er à gérer des guillemets avec des chaînes de caractères en Perl ou même en C…
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Soit des compétences de bases avec mon éditeur favori et ma classe de langages favoris ?
Faut être soit idiot soit ignorant pour coder en Lisp et gérer les parenthèses à la main, c'est tout. Pas de troll ni de mauvaise foi, juste que, contrairement à toi ici, je sais de quoi je parle.
C''est comme si tu disais « c'est nul le Français, on peut pas facilement écrire des accents, des cédilles ou des guillemets, voire des espaces insécables, » ce à quoi je répondrait « apprend le bépo. »
Là, tu parles de Lisp, et je te dis « apprend ton éditeur de texte. »
C'est comme quand je tape du HTML… J'ai arrêté de taper les balises fermantes il y a des années, et mon éditeur me propose aussi tout seul tous les paramètres optionnels de chaque tag…
[^] # Re: Surprise
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Surprise
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 1.
Euh, « Turing complete, » c'est un moyen de comparaison d'expressivité, et beaucoup de gens s'y amusent.
Tu as aussi « full abstraction » et « adequation theorem » qui sont des mots clefs de sémanticiens, un branche de l'informatique qui s'amuse à comparer l'expressivité des langages…
Cela dit, je ne parlais pas de l'expressivité du langage (très bonne, au demeurant), mais juste du fait que les principaux éditeurs de texte (notamment vim et emacs) ont depuis fort longtemps des modes/plugins qui rendent la vie des programmeurs Lisp vraiment aisée, à commencer par gestion automatique des parenthèse (par exemple, paredit.el), et le déplacement dans les S-expressions.
Petit exemple : http://img8.imageshack.us/img8/9479/openparen.gif
Et sache que tu ne peux pas effacer une parenthèse par erreur, ouvrante ou fermante.
Sinon : http://mikael.jansson.be/hacking/limp/docs/screenshots/highl(...)
Note la couleur des parenthèse qui encadrent le curseur, et la couleur des autres (ainsi que la couleur du fond de la S-Exp qui contient le curseur).
Après, tu rajoutes un colorscheme dynamique qui rend uniquement la parenthèse active en noir, et les autres en gris clair, et ça fait resortir l'expression courante, tout en cachant les autres parenthèse (qui, comme elles sont là, permettent d'avoir une indentation *toujours* correcte, et donc un feedback visuel encore plus fort, bien que les parenthèses soient cachées.)
Ce sont là des aides visuelles pratiques, une gestion SYNTAXIQUE du langage, alors que la plupart des autres langages ne permettent qu'une gestion lexicale.
Alors, je réitère : si tu codes en Lisp sans ces outils, soit t'es un blaireau fini, soit tu ne sais pas utiliser ton éditeur de texte. Dire que les parenthèses ici sont un fardeau, c'est comme dire que la roue c'est nul parce qu'elle est ronde/circulaire !
[^] # Re: Surprise
Posté par claudex . Évalué à 5.
Change d'éditeur de texte, ou apprend à l'utiliser, car n'importe quel programmeur Lisp C/Perl (et dérivés) te dira qu'il n'a jamais à gérer la moindre parenthèse guillemet lui même…
:-)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Ortografe
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
> Celle-ci tient sur 30 lignes
Je suis personnellement mauvais en Français mais il ne faudrait pas non plus réduire la grammaire Française à 30 règles ;-)
# langage à prototype compilé
Posté par claudex . Évalué à 6.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: langage à prototype compilé
Posté par Dr BG (site web personnel) . Évalué à 2.
[^] # Re: langage à prototype compilé
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: langage à prototype compilé
Posté par Dr BG (site web personnel) . Évalué à 2.
[^] # Re: langage à prototype compilé
Posté par ɹǝıʌıʃO . Évalué à 5.
¹ http://en.wikipedia.org/wiki/Self_%28programming_language%29
² http://selflanguage.org/
[^] # Re: langage à prototype compilé
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
# Ah que merci
Posté par fleny68 . Évalué à 3.
Une erreur, comme une impression de déjà vu entre 4.33 et 5.02.
Sinon je ne sais pas mais j'aurai bien aimé une comparaison dans les tableaux avec lisp aussi. Puisqu'on parle d'expressivité...
[^] # Re: Ah que merci
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
disons qu' un tel montage c'est du gros boulot :)
"La première sécurité est la liberté"
[^] # Re: Ah que merci
Posté par Ontologia (site web personnel) . Évalué à 3.
J'ai pour objectif de mettre les vrais slides dessus, mais c'est beaucoup de boulot :-)
Donc j'y travailles.
Pour les bruits de ventilateur, la lumière, etc.. on a fait ce qu'on a pu avec la webcam de mon mac....
La prochaine fois, on aura ptetre une cam
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# De l'inconvénient de ne pas utiliser les méthodes standard...
Posté par fleny68 . Évalué à 3.
Un reste de grippe me tenant loin du boulot je teste.
Et là... ben non. ça ne marche pas du tout. Une installation générée en lisaac (sur une autre machine) dont le .c intermédiaire compile mais plante, que peut-on faire? Un script, un Makefile on peut jeter un oeil, essayer d'afficher des messages, débuguer. Avec une telle méthode d'installation il n'ya qu'à regretter un tel choix, et attendre un correctif.
Voici le détail:
Le Makefile compile un .c qui s'appelle install_lisaac, et il lance l'exécutable, lequel propose en ligne de commande des choix d'installation. Je choisis
1- User installation.
puis
1- Compiler & Shorter Installation.
Et là... il faut penser à remonter pour visualiser qu'il y a des erreurs:
Step 4/5 : Compilation of Lisaac compiler.
==========================================
Execute command `gcc -O2 bin/lisaac.c -o bin/lisaac' (please wait ...)
Auto-install fail !
You want to compile a `bin/lisaac.c' file.
Step 5/5 : Compilation of Shorter tool.
=======================================
Compile `shorter' tools for your system (please wait ...)
Sorry, `shorter' not ready...
Welcome to the Lisaac World !
=============================
Installation successfull.
Run `lisaac' to compile.
Le 'gcc -O2 bin/lisaac.c -o bin/lisaac' lancé la main fonctionne. Mais pas l'exécutable:
$bin/lisaac
Warning: Slot `lisaac' not found.
Slot `front_end' not found in *.lip file.
[^] # Re: De l'inconvénient de ne pas utiliser les méthodes standard...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
En fait, le binaire lisaac cherche un make.lip qui définit la manière de construire tes binaires. Je pense qu'il ne doit pas le trouver. Essayes de lancer le compilo dans le répertoire du make.lip.
Cela me rappelle un bug du style que l'install lisaac ne fonctionne pas en mode root mais seulement utilisateur. C'est peut-être ça.
"La première sécurité est la liberté"
[^] # Re: De l'inconvénient de ne pas utiliser les méthodes standard...
Posté par fleny68 . Évalué à 3.
$ lisaac hello_world
Depending pass: .......... (10)
Executing pass: *........*.. (12)
=> 0 second(s).
run `gcc ./hello_world.c -o ./hello_world -lm '
FAILURE!
$ gcc ./hello_world.c -o ./hello_world -lm
$ ./hello_world
Hello world !
$
Il semble y avoir plusieurs problèmes:
- le programme lisaac plante lorsqu'il y a un appel externe,
- le make.lip de la racine ne contient qu'une ligne '+target.STRING := "unix" '.
=> J'ai remis le make.lip.sample, et en lançant les parties qui plantent à la main on finit par avoir quelque chose qui a presque l'air de marcher.
C'est quand même un peu dommage, je ne suis pas sur un matériel très exotique (debian 5.0.3 x64), il n'y a pas de raison pour que ça ce passe mal. Ça donne une mauvaise impression pour un premier contact.
(Je remplirais un rapport de bug ce soir).
[^] # Re: De l'inconvénient de ne pas utiliser les méthodes standard...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: De l'inconvénient de ne pas utiliser les méthodes standard...
Posté par fleny68 . Évalué à 2.
Et debian me propose généreusement une 0.13
http://packages.debian.org/search?keywords=lisaac&search(...)
# 2 mots clefs... ou pas
Posté par rewind (Mastodon) . Évalué à 2.
[^] # Re: 2 mots clefs... ou pas
Posté par Gilles G. . Évalué à 1.
Self, Left, Right, Old, Section
[^] # Re: 2 mots clefs... ou pas
Posté par Ontologia (site web personnel) . Évalué à 2.
Il dois en rester
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: 2 mots clefs... ou pas
Posté par outs . Évalué à 3.
PS: finalement le code source *lisaac* du compilateur est sous licence libre maintenant ?
[^] # Re: 2 mots clefs... ou pas
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: 2 mots clefs... ou pas
Posté par rewind (Mastodon) . Évalué à 1.
[^] # Re: 2 mots clefs... ou pas
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 mots clefs... ou pas
Posté par rewind (Mastodon) . Évalué à 1.
[^] # Re: 2 mots clefs... ou pas
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je ne vois pas de licence là-bas. Cela serait à ajouter qq part, d'ailleurs.
"La première sécurité est la liberté"
[^] # Re: 2 mots clefs... ou pas
Posté par outs . Évalué à 3.
Non c'est faux : le code en *lisaac* du compilo n'était pas disponible, seulement le résultat de la compilation vers le C. Je me souvient très bien de ce point lors d'un tutoriel sur Lisaac que j'ai suivit au Loria à nancy. Il y avait une histoire comme quoi l'INRIA ne voulait pas divulguer le source.
D'ou ma question
[^] # Re: 2 mots clefs... ou pas
Posté par Ontologia (site web personnel) . Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: 2 mots clefs... ou pas
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: 2 mots clefs... ou pas
Posté par Yusei (Mastodon) . Évalué à 3.
[^] # Re: 2 mots clefs... ou pas
Posté par allcolor (site web personnel) . Évalué à 1.
http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.h(...)
Io has no keywords or statements. Everything is an expression composed entirely of messages, each of which is a runtime accessible object. The informal BNF description:
exp ::= { message | terminator }
message ::= symbol [arguments]
arguments ::= "(" [exp [ { "," exp } ]] ")"
symbol ::= identifier | number | string
terminator ::= "\n" | ";"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.