Sun a finalement annoncé le passage prochain de son langage Java, en
Open Source.
L'hésitation porte à l'heure actuelle sur le type exact de licence, Sun
voulant garder la main sur le langage.
Quoiqu'il en soit le code de Java sera ouvert.
Cela va t-il sonner le glas pour les techno .NET ?
vous aurez du mal à m'enlever le préjugé que mettre du code à compiler et exécuter depuis un langage interprété est un peu tordu :-)
Perl n'est pas un langage interprété. Pär ailleurs la compilation du code Inline n'a lieu qu'à la première exécution. Et on utilise très couramment et depuis de longues années des librairies bindées en C en Perl (y compris Tk, GTK, SDL et tutti quanti), c'est parfaitement fiable et robuste, il n'y a pas de raison que ça ne marche pas avec Java :)
Connais pas. S'il s'agit de JNI, c'est une interface avec le code compilé, pas avec le code source, n'est-ce pas ?
Inline aussi c'est une interface avec le code compilé. L'intégration du source n'est qu'une commodité pour le développeur (il suffit d'avoir essayé de lire la doc XS pour comprendre sa douleur).
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Aït Ahmed.
Le Wed, 24 May 2006 14:22:49 +0200, SL a écrit :
vous aurez du mal à m'enlever le
préjugé que mettre du code à compiler et exécuter depuis un langage
interprété est un peu tordu :-)
Perl n'est pas un langage interprété. Pär ailleurs la compilation du
code Inline n'a lieu qu'à la première exécution. Et on utilise très
couramment et depuis de longues années des librairies bindées en C en
Perl (y compris Tk, GTK, SDL et tutti quanti), c'est parfaitement fiable
et robuste, il n'y a pas de raison que ça ne marche pas avec Java :)
Connais pas. S'il s'agit de JNI, c'est une interface avec le code
compilé, pas avec le code source, n'est-ce pas ?
Inline aussi c'est une interface avec le code compilé. L'intégration du
source n'est qu'une commodité pour le développeur (il suffit d'avoir
essayé de lire la doc XS pour comprendre sa douleur).
--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Aït Ahmed.
vous aurez du mal à m'enlever le préjugé que mettre du code à compiler et exécuter depuis un langage interprété est un peu tordu :-)
Perl n'est pas un langage interprété. Pär ailleurs la compilation du code Inline n'a lieu qu'à la première exécution. Et on utilise très couramment et depuis de longues années des librairies bindées en C en Perl (y compris Tk, GTK, SDL et tutti quanti), c'est parfaitement fiable et robuste, il n'y a pas de raison que ça ne marche pas avec Java :)
Connais pas. S'il s'agit de JNI, c'est une interface avec le code compilé, pas avec le code source, n'est-ce pas ?
Inline aussi c'est une interface avec le code compilé. L'intégration du source n'est qu'une commodité pour le développeur (il suffit d'avoir essayé de lire la doc XS pour comprendre sa douleur).
-- L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas en avant. Aït Ahmed.
SL
Le Wed, 24 May 2006 13:53:59 +0200, Stéphane Zuckerman a écrit :
Mais en C ou C++, le programme est compilé une fois pour toutes. En Java, le bytecode n'est pas totalement compilé en JIT, si ?
Inline cache le résultat des compilations, et il est possible dans le cas de programmes genre CGI ou mod_perl, d'utiliser toujours la même JVM.
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à chaque requête, donc il faudrait effectivement que Inline cache le code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il cachait la liste des méthodes publiques.
Le Wed, 24 May 2006 13:53:59 +0200, Stéphane Zuckerman a écrit :
Mais en C ou C++, le programme est compilé une fois pour toutes. En Java,
le bytecode n'est pas totalement compilé en JIT, si ?
Inline cache le résultat des compilations, et il est possible dans le cas
de programmes genre CGI ou mod_perl, d'utiliser toujours la même JVM.
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à
chaque requête, donc il faudrait effectivement que Inline cache le
code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il
cachait la liste des méthodes publiques.
Le Wed, 24 May 2006 13:53:59 +0200, Stéphane Zuckerman a écrit :
Mais en C ou C++, le programme est compilé une fois pour toutes. En Java, le bytecode n'est pas totalement compilé en JIT, si ?
Inline cache le résultat des compilations, et il est possible dans le cas de programmes genre CGI ou mod_perl, d'utiliser toujours la même JVM.
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à chaque requête, donc il faudrait effectivement que Inline cache le code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il cachait la liste des méthodes publiques.
SL
Le Wed, 24 May 2006 14:22:49 +0200, SL a écrit :
vous aurez du mal à m'enlever le préjugé que mettre du code à compiler et exécuter depuis un langage interprété est un peu tordu :-)
Perl n'est pas un langage interprété.
Ça s'appelle comment ?
Le Wed, 24 May 2006 14:22:49 +0200, SL a écrit :
vous aurez du mal à m'enlever le préjugé que mettre du code à
compiler et exécuter depuis un langage interprété est un peu tordu
:-)
vous aurez du mal à m'enlever le préjugé que mettre du code à compiler et exécuter depuis un langage interprété est un peu tordu :-)
Perl n'est pas un langage interprété.
Ça s'appelle comment ?
Emmanuel Florac
Le Wed, 24 May 2006 23:13:16 +0200, SL a écrit :
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à chaque requête, donc il faudrait effectivement que Inline cache le code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il cachait la liste des méthodes publiques.
Et il peut utiliser la même JVM résidente pour ne pas la relancer à chaque fois.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Le Wed, 24 May 2006 23:13:16 +0200, SL a écrit :
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à
chaque requête, donc il faudrait effectivement que Inline cache le
code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il
cachait la liste des méthodes publiques.
Et il peut utiliser la même JVM résidente pour ne pas la relancer à
chaque fois.
--
A thing of beauty is a joy forever.
J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert!
Marcel Bénabou.
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à chaque requête, donc il faudrait effectivement que Inline cache le code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il cachait la liste des méthodes publiques.
Et il peut utiliser la même JVM résidente pour ne pas la relancer à chaque fois.
-- A thing of beauty is a joy forever. J. Keats.
Ah! Singe débotté, hisse un jouet fort et vert! Marcel Bénabou.
Emmanuel Florac
Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit :
Ça s'appelle comment ?
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la Java (mais pas tout à fait, parce que la totalité du code n'est pas forcément compilée au démarrage).
-- Sutor ne ultra Crepidam.
Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit :
Ça s'appelle comment ?
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la
Java (mais pas tout à fait, parce que la totalité du code n'est pas
forcément compilée au démarrage).
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la Java (mais pas tout à fait, parce que la totalité du code n'est pas forcément compilée au démarrage).
-- Sutor ne ultra Crepidam.
talon
Emmanuel Florac wrote:
Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit :
Ça s'appelle comment ?
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la Java (mais pas tout à fait, parce que la totalité du code n'est pas forcément compilée au démarrage).
Non tu dis n'importe quoi, perl est bien un langage interprété, perl interprète du byte code. Certes il commence d'abord à compiler ton programme textuel en bytecode, il va compiler les expressions régulières, etc. mais ensuite il interprète pas à pas du bytecode, qui est trés loin du code machine. La machine virtuelle Java compile sans arrêt (particulièrement en mode "server") le bytecode en code machine, l'optimise en fonction de l'utilisation qui en est faite, et exécute pour l'essentiel du code machine. C'est pour ça qu'il y a un gros facteur entre les performances de Java, qui peuvent approcher celles du code natif, ou tout au moins ne pas être plus de 10 fois plus lent, et les performances des langages interprétés, perl, python, ruby qui sont au bas mot 10 fois plus lents que Java.
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit :
Ça s'appelle comment ?
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la
Java (mais pas tout à fait, parce que la totalité du code n'est pas
forcément compilée au démarrage).
Non tu dis n'importe quoi, perl est bien un langage interprété,
perl interprète du byte code. Certes il commence d'abord à compiler ton
programme textuel en bytecode, il va compiler les expressions régulières, etc.
mais ensuite il interprète pas à pas du bytecode, qui est trés loin du code
machine. La machine virtuelle Java compile sans arrêt (particulièrement en
mode "server") le bytecode en code machine, l'optimise en fonction de
l'utilisation qui en est faite, et exécute pour l'essentiel du code machine.
C'est pour ça qu'il y a un gros facteur entre les performances de Java,
qui peuvent approcher celles du code natif, ou tout au moins ne pas être
plus de 10 fois plus lent, et les performances des langages interprétés,
perl, python, ruby qui sont au bas mot 10 fois plus lents que Java.
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la Java (mais pas tout à fait, parce que la totalité du code n'est pas forcément compilée au démarrage).
Non tu dis n'importe quoi, perl est bien un langage interprété, perl interprète du byte code. Certes il commence d'abord à compiler ton programme textuel en bytecode, il va compiler les expressions régulières, etc. mais ensuite il interprète pas à pas du bytecode, qui est trés loin du code machine. La machine virtuelle Java compile sans arrêt (particulièrement en mode "server") le bytecode en code machine, l'optimise en fonction de l'utilisation qui en est faite, et exécute pour l'essentiel du code machine. C'est pour ça qu'il y a un gros facteur entre les performances de Java, qui peuvent approcher celles du code natif, ou tout au moins ne pas être plus de 10 fois plus lent, et les performances des langages interprétés, perl, python, ruby qui sont au bas mot 10 fois plus lents que Java.
--
Michel TALON
SL
Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit :
Ça s'appelle comment ?
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la Java (mais pas tout à fait, parce que la totalité du code n'est pas forcément compilée au démarrage).
Une machine virtuelle à la Java, c'est à-dire-qu'au lancement de l'interpréteur perl, il ne re-compile pas le fichier texte en bytecode, mais récupère un bytecode stocké quelque part ? Et qu'il compile le bytecode en code machine quand il peut avec une technologie JIT ?
Je n'ai toujours pas compris comment Inline::java pouvait ne pas recompiler le code java en bytecode à chaque lancement d'une l'instance de l'interpréteur. ça veut dire que Inline::java récupère le code java, le compare au code source à partir duquel il a byte-compilé quelque chose, et que si le code source est toujours le même il réutilise ce code bytecompilé sauvé quelque part ?
Le Wed, 24 May 2006 23:14:19 +0200, SL a écrit :
Ça s'appelle comment ?
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la
Java (mais pas tout à fait, parce que la totalité du code n'est pas
forcément compilée au démarrage).
Une machine virtuelle à la Java, c'est à-dire-qu'au lancement de
l'interpréteur perl, il ne re-compile pas le fichier texte en
bytecode, mais récupère un bytecode stocké quelque part ? Et qu'il
compile le bytecode en code machine quand il peut avec une technologie
JIT ?
Je n'ai toujours pas compris comment Inline::java pouvait ne pas
recompiler le code java en bytecode à chaque lancement d'une
l'instance de l'interpréteur. ça veut dire que Inline::java récupère
le code java, le compare au code source à partir duquel il a
byte-compilé quelque chose, et que si le code source est toujours le
même il réutilise ce code bytecompilé sauvé quelque part ?
Quoi donc ? C'est à peu près équivalent à une machine virtuelle à la Java (mais pas tout à fait, parce que la totalité du code n'est pas forcément compilée au démarrage).
Une machine virtuelle à la Java, c'est à-dire-qu'au lancement de l'interpréteur perl, il ne re-compile pas le fichier texte en bytecode, mais récupère un bytecode stocké quelque part ? Et qu'il compile le bytecode en code machine quand il peut avec une technologie JIT ?
Je n'ai toujours pas compris comment Inline::java pouvait ne pas recompiler le code java en bytecode à chaque lancement d'une l'instance de l'interpréteur. ça veut dire que Inline::java récupère le code java, le compare au code source à partir duquel il a byte-compilé quelque chose, et que si le code source est toujours le même il réutilise ce code bytecompilé sauvé quelque part ?
SL
Le Wed, 24 May 2006 23:13:16 +0200, SL a écrit :
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à chaque requête, donc il faudrait effectivement que Inline cache le code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il cachait la liste des méthodes publiques.
Et il peut utiliser la même JVM résidente pour ne pas la relancer à chaque fois.
Je ne sais pas ce que c'est qu'une JVM résidente, par contre je n'ai pas compris comment il pouvait ne pas avoir à appeller le compilateur code java->bytecode java à chaque compilation code-perl->bytecode perl.
Le Wed, 24 May 2006 23:13:16 +0200, SL a écrit :
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à
chaque requête, donc il faudrait effectivement que Inline cache le
code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il
cachait la liste des méthodes publiques.
Et il peut utiliser la même JVM résidente pour ne pas la relancer à
chaque fois.
Je ne sais pas ce que c'est qu'une JVM résidente, par contre je n'ai
pas compris comment il pouvait ne pas avoir à appeller le compilateur
code java->bytecode java à chaque compilation code-perl->bytecode
perl.
Avec CGI, si mes souvenir sont bons, il y un interpréteur lancé à chaque requête, donc il faudrait effectivement que Inline cache le code byte-compilé. J'avais pas vu ça dans la doc, il disait qu'il cachait la liste des méthodes publiques.
Et il peut utiliser la même JVM résidente pour ne pas la relancer à chaque fois.
Je ne sais pas ce que c'est qu'une JVM résidente, par contre je n'ai pas compris comment il pouvait ne pas avoir à appeller le compilateur code java->bytecode java à chaque compilation code-perl->bytecode perl.
seb666fr2
Emmanuel Florac wrote:
Il faudra m'expliquer l'intérêt de se limiter aux API standards de n'importe quel langage...
Parce que cela permet de juger des capacités du langage à permettre la résolution de problèmes directement, sans être contraint d'utiliser des APIs tierces où en minimisant le plus possible le recours à celles-ci, afin de réduire les dépendances vis à vis d'éditeurs tiers (libre ou non).
Emmanuel Florac wrote:
Il faudra m'expliquer l'intérêt de se limiter aux API standards de
n'importe quel langage...
Parce que cela permet de juger des capacités du langage à
permettre la résolution de problèmes directement, sans être
contraint d'utiliser des APIs tierces où en minimisant le plus
possible le recours à celles-ci, afin de réduire les dépendances
vis à vis d'éditeurs tiers (libre ou non).
Il faudra m'expliquer l'intérêt de se limiter aux API standards de n'importe quel langage...
Parce que cela permet de juger des capacités du langage à permettre la résolution de problèmes directement, sans être contraint d'utiliser des APIs tierces où en minimisant le plus possible le recours à celles-ci, afin de réduire les dépendances vis à vis d'éditeurs tiers (libre ou non).
Nicolas George
, dans le message , a écrit :
Parce que cela permet de juger des capacités du langage à permettre la résolution de problèmes directement,
Non, évidemment : pour ça, pour juger le _langage_, il faut se restreindre au langage, sans _aucune_ bibliothèque tierces sauf celles qui sont structurellement indispensables.
seb666fr2@yahoo.fr, dans le message
<1148555085.370075.186560@j73g2000cwa.googlegroups.com>, a écrit :
Parce que cela permet de juger des capacités du langage à
permettre la résolution de problèmes directement,
Non, évidemment : pour ça, pour juger le _langage_, il faut se restreindre
au langage, sans _aucune_ bibliothèque tierces sauf celles qui sont
structurellement indispensables.
Parce que cela permet de juger des capacités du langage à permettre la résolution de problèmes directement,
Non, évidemment : pour ça, pour juger le _langage_, il faut se restreindre au langage, sans _aucune_ bibliothèque tierces sauf celles qui sont structurellement indispensables.
