Oui, ça c'est ce que les architectes disent pour se défendre quand le marketing vient leur dire "ça rame" : "c'est pas not' faute, c'est les ingé qu'on mal implémenté notre beau design". Non, j'ai trop vécu ce cas pour avaler ce genre d'excuse : un design peut être intrinsèquement lent, quelque soit l'implémentation. C'est pas pour rien que toutes les methodologies de prog actuelles (extreme programming en tete) sont sous forme de cycle ou le design est revu avec l'expérience de l'implementation.
Ok, nous sommes d'accord sur le principe, j'aurais donc du ajouter des exemples pour illustrer mon propos. Le cas de Java qui est emblématique. Les premières JVM étaient d'une lenteur délirante, à tel point que pour certains Java est intrinsèquement lent, seulement interprété, etc. En fait, le design de Java contient des erreurs, en particulier l'absence de struct qui fait qu'on se retrouve avec une énorme consommation mémoire. Mais les JVM modernes sont très rapides et dans certaines situations on peut même faire mieux que du C ou du C++ en Java. Il n'y a rien intrinsèquement en Java qui rend le langage lent. C'est la même chose pour Eiffel par exemple dont les premiers compilateurs étaient tellement lents que le langage était presque inutilisable (idem pour Ada, d'ailleurs). Des progrès énormes ont été réalisés et on constate maintenant que le design d'Eiffel ou d'Ada est bien meilleur que celui de C++.
Tiens, je termine pas un exemple concret. Il a une grosse couille de conception dans Java, c'est le lock par objet qui est soit disant plus objet que l'utilisation de mutex. Enfin, disons plutôt que je pensais qu'il y avait une couille de conception. Bon, je n'aime pas, mais surtout j'étais persuadé qu'on était obligé d'avoir un mot par objet au minimum pour gérer ce lock, soit une perte de 4 octets sur nos architectures 32 bits. Encore de la mémoire gâchée... Sauf que les concepteurs de SableVM ont trouvé un moyen de virer ce mot et d'éviter la perte mémoire.
Il a un phénomène du même genre en Eiffel, avec un truc ultra-puissant découvert par les chercheurs qui implémentent smalleiffel. Je ne me rappelle plus des détails, mais en gros ça permet de garder un modèle objet cohérent tout en se débarassant de la "table des méthodes virtuelles".
Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout.
Terrain glissant ! VHS contre Betacam, USB 1 contre Firewire, Unix contre Windows, etc. L'industrie ne fait que des erreurs ou presque, mais heureusement, ça change car l'information circule bien mieux. J'en veux pour preuve l'adoption de ogg dans de plus en plus de players.
Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
D'un côté je suis d'accord (interface triviale avec le C) et j'ajouterais même courbe d'apprentissage rapide pour un développeur C. Mais d'un autre, tout ça n'est vrai que pour les vieilles versions du C++. Parce qu'avec l'arrivée des templates, ça a été le délire. Il a fallu littéralement une décénie pour avoir des compilateurs décents...
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Salaud, tu m'as coincé et tu en profites ;-) Je n'irais pas jusqu'à dire qu'on obtient plus gros que du C++, mais bon tu as raisons. Excepté une spec modulaire, j'avoue que je ne vois pas trop comment faire.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
Ouaip. Le pire, c'est que la solution retenue pour les generics de Java existe depuis au moins 5 ou 6 ans, avec des prototypes qui marchent, etc. Alors attendre tout ce temps pour une solution moyenne, c'est vraiment nul.
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
Ba oui, je crois qu'on est obligé. Mais Eiffel et Sather le savent depuis plus de dix ans...
[^] # Re: C'est un troll.
Posté par boubou . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Ok, nous sommes d'accord sur le principe, j'aurais donc du ajouter des exemples pour illustrer mon propos. Le cas de Java qui est emblématique. Les premières JVM étaient d'une lenteur délirante, à tel point que pour certains Java est intrinsèquement lent, seulement interprété, etc. En fait, le design de Java contient des erreurs, en particulier l'absence de struct qui fait qu'on se retrouve avec une énorme consommation mémoire. Mais les JVM modernes sont très rapides et dans certaines situations on peut même faire mieux que du C ou du C++ en Java. Il n'y a rien intrinsèquement en Java qui rend le langage lent. C'est la même chose pour Eiffel par exemple dont les premiers compilateurs étaient tellement lents que le langage était presque inutilisable (idem pour Ada, d'ailleurs). Des progrès énormes ont été réalisés et on constate maintenant que le design d'Eiffel ou d'Ada est bien meilleur que celui de C++.
Tiens, je termine pas un exemple concret. Il a une grosse couille de conception dans Java, c'est le lock par objet qui est soit disant plus objet que l'utilisation de mutex. Enfin, disons plutôt que je pensais qu'il y avait une couille de conception. Bon, je n'aime pas, mais surtout j'étais persuadé qu'on était obligé d'avoir un mot par objet au minimum pour gérer ce lock, soit une perte de 4 octets sur nos architectures 32 bits. Encore de la mémoire gâchée... Sauf que les concepteurs de SableVM ont trouvé un moyen de virer ce mot et d'éviter la perte mémoire.
Il a un phénomène du même genre en Eiffel, avec un truc ultra-puissant découvert par les chercheurs qui implémentent smalleiffel. Je ne me rappelle plus des détails, mais en gros ça permet de garder un modèle objet cohérent tout en se débarassant de la "table des méthodes virtuelles".
Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout.
Terrain glissant ! VHS contre Betacam, USB 1 contre Firewire, Unix contre Windows, etc. L'industrie ne fait que des erreurs ou presque, mais heureusement, ça change car l'information circule bien mieux. J'en veux pour preuve l'adoption de ogg dans de plus en plus de players.
Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
D'un côté je suis d'accord (interface triviale avec le C) et j'ajouterais même courbe d'apprentissage rapide pour un développeur C. Mais d'un autre, tout ça n'est vrai que pour les vieilles versions du C++. Parce qu'avec l'arrivée des templates, ça a été le délire. Il a fallu littéralement une décénie pour avoir des compilateurs décents...
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Salaud, tu m'as coincé et tu en profites ;-) Je n'irais pas jusqu'à dire qu'on obtient plus gros que du C++, mais bon tu as raisons. Excepté une spec modulaire, j'avoue que je ne vois pas trop comment faire.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
Ouaip. Le pire, c'est que la solution retenue pour les generics de Java existe depuis au moins 5 ou 6 ans, avec des prototypes qui marchent, etc. Alors attendre tout ce temps pour une solution moyenne, c'est vraiment nul.
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
Ba oui, je crois qu'on est obligé. Mais Eiffel et Sather le savent depuis plus de dix ans...