Pour avoir feuilleté "The Design and Evolution of C++", il me semble que tu te trompes.
Il y a de la marge entre ce que dit Stroustrup et le résultat de sa reflexion. Pour avoir lu des articles théoriques sur Caml et ses dérivées, je comprends parfaitement que Stroustrup ait pu être rebuté par la théorie des langages de programmation et ait préfére faire l'ingénieur. Mais le résultat est ce qu'il est, mauvais sur de nombreux points. Il est vrai qu'Eiffel n'était pas un modèle d'efficacité, ni d'ailleurs smalltalk, par exemple, donc Stroustrup a pu être échaudé par ces expériences (commetant l'erreur habituelle qui est de confondre design et implémentation). Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C, Stroustrup casse le modèle objet expérimenté par toute la communauté de l'orienté objet. Pour qu'un objet fonctionne (c'est-à-dire que le polymorphisme marche), il faut maintenant déclarer ses méthodes "virtuel", sinon il s'agit d'une struct à laquelle on ajoute des méthodes. L'exemple même de l'optimisation à l'envers. Plutôt que d'étendre la sémantique de struct en permettant d'insérer des méthodes ou encore de choisir un mot clé particulier pour ces "objets" qui n'en sont pas, Stroustrup préfère casser le cas général tout ça pour soit disant faciliter la récupération du C (alors que cela aurait marché très bien avec les autres solutions). Je ne peux pas prouver qu'on savait faire ça à l'époque, mais c'est tellement trivial pour quelqu'un qui s'intéresse aux langages de programmation que ça me semble évident.
De même beaucoup plus tard pour les templates qui sont à la fois trop puissants (il a fallu attendre si longtemps avant d'avoir des compilateurs qui marchent) et pas assez (les contraintes sur les types sont implicites, ce qui retarde la vérification de la validité du code). Encore une fois, l'expérience des autres langages aurait permis d'éviter ça. Soit, on n'aurait pas eu les expressions templates, mais franchement, j'ai des doutes sur leur intérêt réel.
Et si tu prends le contre-exemple de Java, tu vois que très rapidement on a cherché à y ajouter des choses comme les templates ou même l'overloading d'operateur.
Ok pour les templates (le résultat est d'ailleurs pourri si tu veux mon avis), mais pas pour les opérateurs. Ils ne sont pas surchargeables en Java et ça risque de durer. Sur le fond, je fini par être d'accord. Oui, ça permet d'écrire du code numérique lisible et avec les expressions templates du C++, ça permet même de faire du code relativement efficace. Cependant, j'ai lu pas mal de papier de numériciens et je suis maintenant convaincu par leur argumentation : si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code. Ca veut dire qu'il doit pouvoir appeler des bibliothèques comme Atlas. On en est loin, mais j'avoue que je ne vois pas comment faire autrement. Et si on enlève le code numérique, la surcharge d'opérateurs ça ne sert franchement à rien.
Et même C#, qui a pourtant ajouté un certain nombre de choses à Java dès le départ, se retrouve contraint d'en ajouter encore.
Oui et non. Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus. Il s'agit d'équipe de chercheurs en théorie des langages et franchement, le résultat est vraiment impressionnant (j'ai honte d'admirer une production de MS, mais bon). Soit, on a du more is more ici, mais fait proprement. Sinon, oui C# a ajouté des choses à Java, peut être un peu trop comme les opérateurs, mais aussi dans la bonne direction comme les structs. Mais surtout, en s'appuyant sur des équipes de recherche pour certaines features...
[^] # Re: C'est un troll.
Posté par boubou . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 3.
Il y a de la marge entre ce que dit Stroustrup et le résultat de sa reflexion. Pour avoir lu des articles théoriques sur Caml et ses dérivées, je comprends parfaitement que Stroustrup ait pu être rebuté par la théorie des langages de programmation et ait préfére faire l'ingénieur. Mais le résultat est ce qu'il est, mauvais sur de nombreux points. Il est vrai qu'Eiffel n'était pas un modèle d'efficacité, ni d'ailleurs smalltalk, par exemple, donc Stroustrup a pu être échaudé par ces expériences (commetant l'erreur habituelle qui est de confondre design et implémentation). Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C, Stroustrup casse le modèle objet expérimenté par toute la communauté de l'orienté objet. Pour qu'un objet fonctionne (c'est-à-dire que le polymorphisme marche), il faut maintenant déclarer ses méthodes "virtuel", sinon il s'agit d'une struct à laquelle on ajoute des méthodes. L'exemple même de l'optimisation à l'envers. Plutôt que d'étendre la sémantique de struct en permettant d'insérer des méthodes ou encore de choisir un mot clé particulier pour ces "objets" qui n'en sont pas, Stroustrup préfère casser le cas général tout ça pour soit disant faciliter la récupération du C (alors que cela aurait marché très bien avec les autres solutions). Je ne peux pas prouver qu'on savait faire ça à l'époque, mais c'est tellement trivial pour quelqu'un qui s'intéresse aux langages de programmation que ça me semble évident.
De même beaucoup plus tard pour les templates qui sont à la fois trop puissants (il a fallu attendre si longtemps avant d'avoir des compilateurs qui marchent) et pas assez (les contraintes sur les types sont implicites, ce qui retarde la vérification de la validité du code). Encore une fois, l'expérience des autres langages aurait permis d'éviter ça. Soit, on n'aurait pas eu les expressions templates, mais franchement, j'ai des doutes sur leur intérêt réel.
Et si tu prends le contre-exemple de Java, tu vois que très rapidement on a cherché à y ajouter des choses comme les templates ou même l'overloading d'operateur.
Ok pour les templates (le résultat est d'ailleurs pourri si tu veux mon avis), mais pas pour les opérateurs. Ils ne sont pas surchargeables en Java et ça risque de durer. Sur le fond, je fini par être d'accord. Oui, ça permet d'écrire du code numérique lisible et avec les expressions templates du C++, ça permet même de faire du code relativement efficace. Cependant, j'ai lu pas mal de papier de numériciens et je suis maintenant convaincu par leur argumentation : si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code. Ca veut dire qu'il doit pouvoir appeler des bibliothèques comme Atlas. On en est loin, mais j'avoue que je ne vois pas comment faire autrement. Et si on enlève le code numérique, la surcharge d'opérateurs ça ne sert franchement à rien.
Et même C#, qui a pourtant ajouté un certain nombre de choses à Java dès le départ, se retrouve contraint d'en ajouter encore.
Oui et non. Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus. Il s'agit d'équipe de chercheurs en théorie des langages et franchement, le résultat est vraiment impressionnant (j'ai honte d'admirer une production de MS, mais bon). Soit, on a du more is more ici, mais fait proprement. Sinon, oui C# a ajouté des choses à Java, peut être un peu trop comme les opérateurs, mais aussi dans la bonne direction comme les structs. Mais surtout, en s'appuyant sur des équipes de recherche pour certaines features...