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 beagf . En réponse au journal Lisaac: sorti de la 0.39beta. É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.