Si j'ai évoqué les méthodes de compilation des langages "très dynamiques" (que ce soit par JIT ou profile-based compilation) c'est pour montrer qu'on peut avoir une sémantique qui semble impliquer des appels indirects, et quand même une implémentation performante derrière, de nature à satisfaire les personnes exigeantes.
Après, ça ne veut pas dire que l'implémentation effective du langage à un instant donné effectue ces efforts d'amélioration des performances. Dans ce sens ta question sur l'implémentation actuelle de Go est tout à fait pertinente. Mais je pense que sans invoquer le spectre du "sufficiently smart compiler" on peut juger que Go a une forte marge de manœuvre là-dessus et qu'il serait dommage de juger le langage (qui est avant tout une sémantique) sur des détails d'implémentation de ce type.
L'inconvénient dans tout ça, c'est la perte de la predictibilité de la copmilation. Plus le compilateur est malin, plus il est difficile pour le programmeur d'être certain de ce qui va se passer. Mais c'est aussi le coût à payer pour une expressivité plus forte (car dans le fond, si on ajoute une indirection ici, ce n'est pas pour le plaisir, c'est parce que ça permet de mieux écrire des programmes).
[^] # Re: Testez-le, ensuite vous pourrez critiquer
Posté par gasche . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 3.
Oui, nous sommes d'accord.
Si j'ai évoqué les méthodes de compilation des langages "très dynamiques" (que ce soit par JIT ou profile-based compilation) c'est pour montrer qu'on peut avoir une sémantique qui semble impliquer des appels indirects, et quand même une implémentation performante derrière, de nature à satisfaire les personnes exigeantes.
Après, ça ne veut pas dire que l'implémentation effective du langage à un instant donné effectue ces efforts d'amélioration des performances. Dans ce sens ta question sur l'implémentation actuelle de Go est tout à fait pertinente. Mais je pense que sans invoquer le spectre du "sufficiently smart compiler" on peut juger que Go a une forte marge de manœuvre là-dessus et qu'il serait dommage de juger le langage (qui est avant tout une sémantique) sur des détails d'implémentation de ce type.
L'inconvénient dans tout ça, c'est la perte de la predictibilité de la copmilation. Plus le compilateur est malin, plus il est difficile pour le programmeur d'être certain de ce qui va se passer. Mais c'est aussi le coût à payer pour une expressivité plus forte (car dans le fond, si on ajoute une indirection ici, ce n'est pas pour le plaisir, c'est parce que ça permet de mieux écrire des programmes).