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.
Je suis d'accord que l'important est de disposer de langage évolué disposant donc de primitives tout aussi évolué.
Je suis le premier à militer" pour la montée en niveau des langages. J'ai même fait une publi là dessus.
Le fait que, ces services soient pour le moment offerts sur des machines virtuelles prouvent que compiler la même chose est trop compliqué, qu'on ne sait pas le faire, mais personne n'a prouvé que c'est impossible !
Je suis totalement d'accord avec toi dans le refus catégorique d'obliger le programmeur à l'ancienne pour utiliser un code compîlé, pour le plaisir d'avoir du code compilé. En terme de rationalité économique c'est effectivement stupide.
Quand je parlai de "vrai" machine virtuelle, je parle d'un programme exécutant un pseudo assembleur. Ca prend du temps de le compiler, même si c'est beaucoup plus rapide que de compiler du C++ ou du C.
En admettant que ce soit compilé intelligement, et souvent une bonne fois pour toute, une fois le code compilé, il n'est plus adaptable, spécialisable au contexte. On retombe toujours dans le même problème.
Ce que je veux simplement dire, c'est qu'il y a des recherches à faire là dedans pour essayer de synthétiser les avantages des deux, d'imaginer du code automodifiant, de l'analyse de chemin d'exécution, de contexte de données, toussa. On en parle.
Les techniques d'analyse de flots le permettent. Comme je le disais c'est un beau sujet de thèse.
PS2 : J'ai déjà expliqué 5000 fois que je n'ai pas le pouvoir, et Benoit non plus quand à la libération du code source de Lisaac. Nous avons l'autorisation de libérer IsaacOS, ce que nous préparons dans les mois à venir (on travaille à faire une distrib pour développeur absolument impeccable, avec de la doc, des explications, le tout nouveau compilateur, etc...).
Mais pour Lisaac, nous n'avons pas le pouvoir de le libérer. J'aimairai beaucoup le voir en GPL crois moi.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Le passage Mono dans le document
Posté par Ontologia (site web personnel) . En réponse au journal Mono et Gnome. Évalué à 2.
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.
Je suis d'accord que l'important est de disposer de langage évolué disposant donc de primitives tout aussi évolué.
Je suis le premier à militer" pour la montée en niveau des langages. J'ai même fait une publi là dessus.
Le fait que, ces services soient pour le moment offerts sur des machines virtuelles prouvent que compiler la même chose est trop compliqué, qu'on ne sait pas le faire, mais personne n'a prouvé que c'est impossible !
Je suis totalement d'accord avec toi dans le refus catégorique d'obliger le programmeur à l'ancienne pour utiliser un code compîlé, pour le plaisir d'avoir du code compilé. En terme de rationalité économique c'est effectivement stupide.
Quand je parlai de "vrai" machine virtuelle, je parle d'un programme exécutant un pseudo assembleur. Ca prend du temps de le compiler, même si c'est beaucoup plus rapide que de compiler du C++ ou du C.
En admettant que ce soit compilé intelligement, et souvent une bonne fois pour toute, une fois le code compilé, il n'est plus adaptable, spécialisable au contexte. On retombe toujours dans le même problème.
Ce que je veux simplement dire, c'est qu'il y a des recherches à faire là dedans pour essayer de synthétiser les avantages des deux, d'imaginer du code automodifiant, de l'analyse de chemin d'exécution, de contexte de données, toussa. On en parle.
nicO a pas mal d'idée sur le sujet, qu'il a posé ici (avec d'autres) :
http://wiki.loria.fr/wiki/Lisaac/Optimisation_en_taille
http://wiki.loria.fr/wiki/Lisaac/Optimisation_en_performance
http://wiki.loria.fr/wiki/Lisaac/WishList
http://wiki.loria.fr/wiki/Lisaac/Fonctionnalit%C3%A9_du_lang(...)
Les techniques d'analyse de flots le permettent. Comme je le disais c'est un beau sujet de thèse.
PS2 : J'ai déjà expliqué 5000 fois que je n'ai pas le pouvoir, et Benoit non plus quand à la libération du code source de Lisaac. Nous avons l'autorisation de libérer IsaacOS, ce que nous préparons dans les mois à venir (on travaille à faire une distrib pour développeur absolument impeccable, avec de la doc, des explications, le tout nouveau compilateur, etc...).
Mais pour Lisaac, nous n'avons pas le pouvoir de le libérer. J'aimairai beaucoup le voir en GPL crois moi.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker