Donc, ça n'a pas été un objectif de design de concevoir un langage qui offre des features aux limites de ce qui est analysable.
En effet, je faisait référence au "zero-overhead principle". On ne paie pas pour les features qu'on utilise pas.
C'est moi qui suggère de concevoir un language en fonction de ce qui s'analyse bien. Pas nécessairement "aux limites" de ce qui est analysable. Il s'agirait plutôt de concevoir les règles de typage pour rendre la tâche d'analyse facile et efficace.
Par exemple:
- Si davantage d'opérations en JS lancaient des exceptions quand elles recoivent des types invalides, les valeurs undefined ne pourraient pas se propager partout.
- Les objets pourraient ne pas permettre de rajouter des champs après leur création, ou sinon, accèder à un champ non défini pourrait lancer une exception.
- Les opérations numériques sur des entier pourraient guarantir de ne produire que des entiers en permettant l'overflow, par design. Ceci élimine le problème de savoir si un nombre est un entier ou un float, ou s'il entre dans 30 ou 32 bits.
- Eval pourrait prendre un environnement en paramètre, voir être complètement éliminé en faveur de la génération de nouvelles fonctions dynamiquement
Anyways, ça ne vaut pas la peine de s'embarquer dans du "C++ bashing"
Ce n'est certainement pas moi qui déteste C++ ici. Le language, malgré ses failles, a connu un énorme succès, en grande partie parce qu'il a été conçu avec un esprit pragmatique (e.g.: réutiliser tout l'héritage de C).
- Maxime