calme toi, dans le fond on est d'accord, j'essaye juste d'expliquer pourquoi un point de vue different est defendable.
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 thedude . En réponse au journal Lisaac: sorti de la 0.39beta. É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.