Ontologia, ce n'est pas la première fois que je te surprends également à dire une connerie :)
Je persiste et je signe, la notion de machine virtuelle est une notion abstraite. Certes, avec certains environnement d'exécution, la dernière phase de compilation est effectuée "juste à temps", mais que ce soit pour Java ou à plus forte raison pour .NET, il est tout à fait possible de compiler dès le départ en natif, bref, au final ca prend pas plus de temps.
Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.
C'est pourquoi Mono implémente les spécifications d'une machine virtuelle qui a été conçue en vue de produire du code compilable à l'avance en code natif (que ce soit au dernier moment, 1h avant, ou 1 mois avant) Le résultat est identique : c'est de l'assembleur qui s'exécute, et il n'y a aucune phase de traduction/interprétation une fois la dernière phase de compilation effectuée.
il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
C'est rigolo de parler d'une "vraie" machine virtuelle... Une machine virtuelle est... virtuelle, elle n'existe pas. Une machine c'est quelque chose de physique. Le jour où t'auras une vraie machine qui existe pour .NET ou Java, ca sera un proc dédié pour exécuter les instructions du langage intermédiaire. Ce dont tu parles c'est l'environnement d'exécution et plus particulièrement de son compilateur JIT.
Pas la peine de réciter ton blabla théorique habituel, t'as beau affirmer des vérités générales, ca ne change strictement rien à ce que j'ai dis : le problème de la lourdeur vient des nombreux services offerts que n'offrent pas les langages "traditionnels" orientés machine physique sans limitations. C'est services ont un coup, c'est évident et n'importe quel bench peut le montrer, mais ils participent à la qualité du soft, tout est alors une question de juste équilibre.
Comme je l'ai déjà dis, même GCC propose une machine virtuelle, mais ne propose pas tous les services qu'offre Mono/Java, ce qui lui permet de produire du code machine plus rapide et plus optimisé.
Conclusion, la bataille entre compilateur et machine virtuelle fait rage depuis 20 ans, voire plus, avec les mêmes arguments.
Sauf que depuis 20 ans pleins de choses ont évoluées : les machines sont plus puissantes, offrant la possibilité de fournir des services supplémentaires à l'exécution sans vraiment pénaliser l'application qui s'exécute, les techniques de compilation JIT ont largement évoluées pour remplacer la traditionnelle phase d'interprétation du langage intermédiaire, qui elle était réellement lente, et surtout le plus important, les programmes ont changé de taille : on ne parle plus de quelques milliers de lignes mais plutôt de millions de lignes. Et là de nombreux programmeurs ont compris l'intérêt que pouvait apporter les environnements riches en services "ajoutés", ce qui leur permet globalement d'améliorer grandement la qualité de leur code, mais aussi de faciliter la programmation à plusieurs (composants, versionning, signature numérique, introspection et j'en passe).
Alors oué t'as raison, les pro langage natif "à l'ancienne" utilisent toujours les mêmes arguments, et pendant ce temps d'autres bossent, codent, et certains leurs offrent des outils/langages/bibliothèques/compilateurs qui leur rendent réellement services. Va coder une application d'entreprise devant facilement monter en charge en répartissant ses composants sur différentes machines dans un langage comme C/C++, bon courage.
PS : Je ne suis pas spécialement contre le code "superoptimisédelamortquitue" écrit en assembleur, ca a toujours son intérêt pour de nombeuses applications (couches bassent de l'OS, embarqué, etc.)
PS2 : tiens au fait, on attend toujours une release GPL de votre langage...
[^] # Re: Le passage Mono dans le document
Posté par TImaniac (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 3.
Je persiste et je signe, la notion de machine virtuelle est une notion abstraite. Certes, avec certains environnement d'exécution, la dernière phase de compilation est effectuée "juste à temps", mais que ce soit pour Java ou à plus forte raison pour .NET, il est tout à fait possible de compiler dès le départ en natif, bref, au final ca prend pas plus de temps.
Un programme compilé n'a pas ce problème, l'assembleur est là, prêt à être exécuté.
C'est pourquoi Mono implémente les spécifications d'une machine virtuelle qui a été conçue en vue de produire du code compilable à l'avance en code natif (que ce soit au dernier moment, 1h avant, ou 1 mois avant) Le résultat est identique : c'est de l'assembleur qui s'exécute, et il n'y a aucune phase de traduction/interprétation une fois la dernière phase de compilation effectuée.
il s'agit d'une "vraie" machine virtuelle. C'est à dire que nous avons un programme, qui lit un espèce d'assembleur (à pile... j'en entend certain rigoler) et dispose de quelques primitives.
C'est rigolo de parler d'une "vraie" machine virtuelle... Une machine virtuelle est... virtuelle, elle n'existe pas. Une machine c'est quelque chose de physique. Le jour où t'auras une vraie machine qui existe pour .NET ou Java, ca sera un proc dédié pour exécuter les instructions du langage intermédiaire. Ce dont tu parles c'est l'environnement d'exécution et plus particulièrement de son compilateur JIT.
Pas la peine de réciter ton blabla théorique habituel, t'as beau affirmer des vérités générales, ca ne change strictement rien à ce que j'ai dis : le problème de la lourdeur vient des nombreux services offerts que n'offrent pas les langages "traditionnels" orientés machine physique sans limitations. C'est services ont un coup, c'est évident et n'importe quel bench peut le montrer, mais ils participent à la qualité du soft, tout est alors une question de juste équilibre.
Comme je l'ai déjà dis, même GCC propose une machine virtuelle, mais ne propose pas tous les services qu'offre Mono/Java, ce qui lui permet de produire du code machine plus rapide et plus optimisé.
Conclusion, la bataille entre compilateur et machine virtuelle fait rage depuis 20 ans, voire plus, avec les mêmes arguments.
Sauf que depuis 20 ans pleins de choses ont évoluées : les machines sont plus puissantes, offrant la possibilité de fournir des services supplémentaires à l'exécution sans vraiment pénaliser l'application qui s'exécute, les techniques de compilation JIT ont largement évoluées pour remplacer la traditionnelle phase d'interprétation du langage intermédiaire, qui elle était réellement lente, et surtout le plus important, les programmes ont changé de taille : on ne parle plus de quelques milliers de lignes mais plutôt de millions de lignes. Et là de nombreux programmeurs ont compris l'intérêt que pouvait apporter les environnements riches en services "ajoutés", ce qui leur permet globalement d'améliorer grandement la qualité de leur code, mais aussi de faciliter la programmation à plusieurs (composants, versionning, signature numérique, introspection et j'en passe).
Alors oué t'as raison, les pro langage natif "à l'ancienne" utilisent toujours les mêmes arguments, et pendant ce temps d'autres bossent, codent, et certains leurs offrent des outils/langages/bibliothèques/compilateurs qui leur rendent réellement services. Va coder une application d'entreprise devant facilement monter en charge en répartissant ses composants sur différentes machines dans un langage comme C/C++, bon courage.
PS : Je ne suis pas spécialement contre le code "superoptimisédelamortquitue" écrit en assembleur, ca a toujours son intérêt pour de nombeuses applications (couches bassent de l'OS, embarqué, etc.)
PS2 : tiens au fait, on attend toujours une release GPL de votre langage...