Rien ne montre effectivement qu'il n'est pas possible de cibler une machine virtuelle en Lisaac.
SmartEiffel propose de produire du bytecode pour la JVM.
Il en a de même été question dans nos discussions de faire de même avec le compilateur lisaac. Il y a à ce titre plusieur approche :
- Une qui fonctionne déjà, mais vraiment tordu : il 'sagit de compiler le .c produit par lisaac pour produire du binaire mips, qui est transformé en LLVM, puis en bytecode JVM. Ca marche à peu près, mais c'est trop tordu.
- Produire du bytecode JVM. C'est quelques semaines de travail, faut voir avec les autres priorités
- Produire du java, en mettant tout le code dans une grosse classe Main. Ca aurait en plus l'avantage de pouvoir s'interfacer avec d'autres libs en java. Le truc qui dérange Benoit, c'est l'absence d'entier signé en Java, ça lui pose des problème, mais à part ça, c'est pas très difficile à faire, surtout que la gestion de la mémoire serait beaucoup plus facile
La 2ème question à se poser c'est la pertinence de certains choix fait dans Lisaac, notamment le côté "simple" de la grammaire permettant d'augmenter facilement les constructions syntaxique (simuler une boucle for while ou un autre truc innovant). C'est joli, bandant... oui mais pourquoi Java ou C# ne propose pas ce genre de chose ? (c'est pas une nouveauté en soit)
Java et C# ne le proposent pas, parce que c'est très dur à compiler, même quand tu fait du JIT.
S'il le faisaient, les performances s'écrouleraient.
De plus, par suivisme, et pour ne pas choquer les programmeur et ainsi faciliter (à l'époque) la transition C/C++ -> Java, le parti pris a été de proposer une syntaxe très proche du C.
Ces deux facteurs ont impliqué que ce genre de possibilités n'existent pas, et qu'on est donc obligé de grossir la grammaire pour en proposer certaines.
En limitant à l'aide de mots clés (for while foreach, etc.) les constructions les plus courantes, on limite certes la concision et l'expressivité, mais on améliore aussi la compréhension du code par une autre personne. C'est probablement ce qui a fait une partie du succès de Java. Beaucoup d'autres simplifications également. Ce qui apparaît comme des contraintes pour un "universitaire" est en fait un atout dans la vraie vie. Lever ces contraintes comme le propose Lisaac élimine une qualité essentielle d'un code source. Et dans le mondre du libre on devrait être attaché à cet aspect.
Il est vrai que cela peut être à double tranchant.
Cela dit, en ce qui nous concerne, on y réfléchit très murement avant de mettre une construction nouvelle dans la librairie standard.
Il est même question de les normaliser, afin de les rendre prévisible (genre quand une fonction rend une collection, on aura toujours une fonction proposant de boucler sur cette liste, avec un nom de fonction prévisible de par la première)
de plus, on essaye d'avoir des noms de fonction claires, et la syntaxe à mot clé y aide.
macollection.foreach { // code }; until { //condition}; se comprend très vite
Et on ne modifie pas impunément une librairie standard, je connais peu de gens qui prennent ce genre de risque, même quand c'est "pas grave" et qu'ils peuvent se le permettre.
Une machine virtuelle c'est pareil. En apparance c'est une érésie, les perfs s'en ressentent largement. Seulement les avantages sont aujourd'hui beaucoup plus important que les inconvénients (sécurité, portabilité, productivité, etc.) dans beaucoup de scénarios d'utilisation.
Voir plus haut. Et j'aimerai que tu me cites les constructions de Java, qui utilisent ces fameuses plus value de la VM...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: C'est trop compliqué !
Posté par Ontologia (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 2.
SmartEiffel propose de produire du bytecode pour la JVM.
Il en a de même été question dans nos discussions de faire de même avec le compilateur lisaac. Il y a à ce titre plusieur approche :
- Une qui fonctionne déjà, mais vraiment tordu : il 'sagit de compiler le .c produit par lisaac pour produire du binaire mips, qui est transformé en LLVM, puis en bytecode JVM. Ca marche à peu près, mais c'est trop tordu.
- Produire du bytecode JVM. C'est quelques semaines de travail, faut voir avec les autres priorités
- Produire du java, en mettant tout le code dans une grosse classe Main. Ca aurait en plus l'avantage de pouvoir s'interfacer avec d'autres libs en java. Le truc qui dérange Benoit, c'est l'absence d'entier signé en Java, ça lui pose des problème, mais à part ça, c'est pas très difficile à faire, surtout que la gestion de la mémoire serait beaucoup plus facile
La 2ème question à se poser c'est la pertinence de certains choix fait dans Lisaac, notamment le côté "simple" de la grammaire permettant d'augmenter facilement les constructions syntaxique (simuler une boucle for while ou un autre truc innovant). C'est joli, bandant... oui mais pourquoi Java ou C# ne propose pas ce genre de chose ? (c'est pas une nouveauté en soit)
Java et C# ne le proposent pas, parce que c'est très dur à compiler, même quand tu fait du JIT.
S'il le faisaient, les performances s'écrouleraient.
De plus, par suivisme, et pour ne pas choquer les programmeur et ainsi faciliter (à l'époque) la transition C/C++ -> Java, le parti pris a été de proposer une syntaxe très proche du C.
Ces deux facteurs ont impliqué que ce genre de possibilités n'existent pas, et qu'on est donc obligé de grossir la grammaire pour en proposer certaines.
En limitant à l'aide de mots clés (for while foreach, etc.) les constructions les plus courantes, on limite certes la concision et l'expressivité, mais on améliore aussi la compréhension du code par une autre personne. C'est probablement ce qui a fait une partie du succès de Java. Beaucoup d'autres simplifications également. Ce qui apparaît comme des contraintes pour un "universitaire" est en fait un atout dans la vraie vie. Lever ces contraintes comme le propose Lisaac élimine une qualité essentielle d'un code source. Et dans le mondre du libre on devrait être attaché à cet aspect.
Il est vrai que cela peut être à double tranchant.
Cela dit, en ce qui nous concerne, on y réfléchit très murement avant de mettre une construction nouvelle dans la librairie standard.
Il est même question de les normaliser, afin de les rendre prévisible (genre quand une fonction rend une collection, on aura toujours une fonction proposant de boucler sur cette liste, avec un nom de fonction prévisible de par la première)
de plus, on essaye d'avoir des noms de fonction claires, et la syntaxe à mot clé y aide.
macollection.foreach { // code }; until { //condition}; se comprend très vite
Et on ne modifie pas impunément une librairie standard, je connais peu de gens qui prennent ce genre de risque, même quand c'est "pas grave" et qu'ils peuvent se le permettre.
Une machine virtuelle c'est pareil. En apparance c'est une érésie, les perfs s'en ressentent largement. Seulement les avantages sont aujourd'hui beaucoup plus important que les inconvénients (sécurité, portabilité, productivité, etc.) dans beaucoup de scénarios d'utilisation.
Voir plus haut. Et j'aimerai que tu me cites les constructions de Java, qui utilisent ces fameuses plus value de la VM...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker