Guillaume Laurent a écrit 1148 commentaires

excuses moi, je savais pas que c'etait important, je penserais a t'envoyer mon cv la prochaine fois que je poste ici.

Je ne vois pas l'interêt de discuter avec quelqu'un qui parle d'un sujet sans en avoir la moindre expérience, ce que ta première réponse laissait supposer.

Bon, je suppose que je me suis trop emmerdé avec des '+' pour apprécier ton point de vue (certes, dans des cas triviaux ou le string est simple, c'est tout à fait lisible et je l'utilise aussi parfois, mais au dela ça devient vite lourd).

> Stroustrup n'a pas eu une interaction suffisante avec les universitaires et n'a donc pas utilisé l'expérience d'Eiffel et d'autres langages

Pour avoir feuilleté "The Design and Evolution of C++", il me semble que tu te trompes.

> Stroustrup est partisant du "more is more" et effectivement chaque feature du C++ est utilisée et c'est bien le problème.

Ben oui mais a un moment il faut bien que ton langage serve à quelque chose :-). 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. 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.

> Nous avons d'ailleurs déjà eu cette discussion un certain nombre de fois et nous ne serons jamais d'accord, je suppose.

Sans doute. :-)

> La grosse difference entre 1 et 2 est que dans 1 le toString est appelé "magiquement"..

Euh, en java aussi, quand tu concatènes à coup de '+' il appelle toString() tout seul comme un grand.

> Je ne vois pas pourquoi ce "syntactic sugar" bien agréable devrait être réservé aux languages "de script"..

Plus exactement, aux langages interpretés. Un langage compilé ne peut pas faire ce genre de choses, déjà parce que le nom d'une variable n'est pas une information que la compilation conserve (donc plus moyen d'interpoler "blah %{foo} blah").

Depuis quand on a besoin de montrer sa b^W^W son CV pour pouvoir dire qu'on préfère un style à un autre ?

Depuis que ce genre de question a une influence directe sur l'heure à laquelle tu rentres chez toi le soir. :-)

C'est facile de dire "je préfère ce style là" quand on a jamais vraiment codé. Mais quand c'est ton boulot, que tu as testé les deux, et qu'avec l'un tu te fais plus chier que l'autre, tu as de vrais arguments pour parler.

> ces 2 syntaxes sont à chier par rapport à l'interpolation directe de variables

C'est vrai, mais :

- un langage compilé ne sait pas faire ça, donc on est un peu hors sujet :-)

- tu n'as pas de controle sur la façon dont les variables sont effectivement affichée (par ex., afficher un entier en hexa, ou un float avec une certaine précision).

C'est pas pour rien que Ruby a sprintf() aussi :-) (et Perl aussi, mais j'aime pas Perl).

si par erreur, tu entends l'absence d'espace apres colonne, j'appelle pas vraiment ca une erreur, plus une faute de frappe.

Appelle-ça comme tu veux, en pratique le résultat est le même : un cycle edition/compilation/run en plus. Et non, ça n'est pas une faute de frappe parce qu'il n'est pas naturel d'ajouter un espace avant de fermer des quotes. C'est bien une erreur.

Je l'ai vu a la deuxieme lecture de la ligne.

Alors que "... colonne%3 ...", tu le vois tout de suite.

pour ecrire ta premiere ligne, tu as du ecrire le message d'erreur, puis donner le nom des variables en te demandant dans quel ordre tu dois les donner : 2 etapes au lieu d'une.

Parce que tu crois que découper ton string à coup de " et + c'est rapide ? :-)

tu devines ce que la ligne veut dire, pas ce qu'elle fera effectivement, ce qui me parait quand meme le plus important

Quand tu lis du code rapidement pour avoir une idée de ce qu'il fait, tu ne t'emmerde pas comprendre ce que fait exactement chaque ligne, ou alors tu n'avances plus, et avoir un string lisible te fait gagner du temps. Tu regardes le détail uniquement quand tu débugges, et dans ce cas compter les arguments n'est pas vraiment un pb. Ça reste même plus facile qu'assembler le string (surtout quand les arguments sont plus complexes que de simples noms de variables, mets des appels de méthodes à la place, pour voir :-).

quand a ce qui est d'entrelacer avec des " et des +, c'est pas pire que d'entrelacer avec des %i

Bon, si tu as envie d'y croire... Et ça fait combien de temps que tu développes, et avec quels langages, pour pouvoir affirmer ça ?

peut etre es tu rentre dans la matrice du C, ce qui fait que tu es parfaitement habitue a lire un printf.

On est beaucoup dans ce cas :-).

l'ecriture java-style me parait plus naturelle.

Même question : sur quelle expérience concrète te bases-tu pour dire ça ?

Bon, on est loin du C++ qui est à mon avis l'exemple même du langage construit de bric et de broc sans aucune interaction avec les "gens qui savent"

Ça dépend qui tu entends par "gens qui savent". Si tu parles des théoriciens des langages, c'est partiellement vrai (Stroustrup est avant tout un pragmatique). Si tu parles des gens qui utilisent les langages pour développer avec, c'est complètement faux (c'est même bien pour ça que C++ est devenu aussi complexe : chaque feature est là parce que quelqu'un l'utilise.

Pantois, vraiment... Bon puisqu'il faut te tenir la main pour verifier les choses, allons-y :

"Erreur numero %1 a la ligne %2, colonne %3 du fichier %4", errno, lineNb, colNb, fileName

"Erreur numero " + error + " a la ligne " + lineNb + ", colonne" + colNb + " du fichier " + fileName

Tu n'a pas besoin de "remplacer les %i", tu infères leur valeur par le contexte du string. Lequel contexte est beaucoup plus clair si le string n'est pas entrelardé de '"' et de '+'. Sans compter que c'est bien plus facile à écrire, par exemple j'ai volontairement fait une erreur dans le 2eme exemple, tu arrives à la voir facilement ?

> je vois pas l'interet d'avoir un equivalent de printf

Regarde mieux :

- c'est plus rapide (concatener des String en Java est assez couteux)
- c'est beaucoup plus lisible.
- il est impossible d'internationaliser une chaine construite à coup de "+".

> Le pb, c'est surtout que si tu fais un joli logiciel libre GPL sous linux, tu peux pas le distribuer aux mêmes conditions sous windows

Bien sur que tu peux, qu'est-ce qui t'en empèche ?

> Ca me derange de faire payer mon logiciel.

Ben ne le fait pas payer. Il n'y a absolument rien dans la licence Qt Windows qui t'y oblige. Les licenses Qt sont pour les developpeurs, pas les utilisateurs des logiciels fait avec Qt. Tu es libre d'acheter une license Qt pour Windows et de distribuer ton soft en GPL, et de mettre à disposition des binaires précompilés linkés statiquement.

Mais je ne veux pas changer affiche(), puisque le but de l'héritage est justement de réutiliser le code!

Oui mais là ce que tu veux c'est le polymorphisme, qui n'a rien à voir avec l'héritage, même si dans beaucoup de cas il s'obtient par héritage (mais pas dans tous, les langages plus faiblement typés comme Ruby sont des exceptions).

Bref, ton erreur est de confondre héritage et polymorphisme.

Par ailleurs, ce n'est pas le problème de la classe de base qui a gêné pour pwlib. C'est avec le nouveau code que les problèmes sont apparus: comme les classes de base n'avaient pas prévu d'être héritées, il a fallu flanquer des virtual dans tous les coins pour obtenir un truc qui marche correctement.

Ce qui est bien l'une des facettes du Fragile Base Class Problem, CQFD.

Tu aurais eu exactement le même pb en Java si, pour des raisons d'efficacité ou autre, l'auteur avait mis en 'final' certaines méthodes, et qu'après coup on découvre qu'on voudrait bien pouvoir les overrider quand même. Les deux sont des cas d'école, avec l'expérience tu apprends à te méfier, mais ça arrive toujours de se planter.

Apparemment il fallait connaître les futurs besoins avant de les avoir...

Bienvenue dans la dure réalité du design logiciel.

Ce que j'essaie d'expliquer depuis le début, c'est que la normalité quand on veut faire de l'héritage [...]

Ce que tu cherches à expliquer depuis le début manifestement sans bien comprendre les concepts derrière c'est qu'il est plus commode d'avoir des méthodes virtuelles par défaut. Et bien sur c'est vrai. Mais ça n'est pas sans inconvénients non plus (ça peut avoir un impact sur les perfs, mais moins grands qu'on le croit en général), et dans le cas de C++ ça n'était pas possible pour pouvoir garder la compatibilité avec C.

Ensuite, bien que ça aide pour faire des classes facilement réutilisables, ça ne résoud absolument pas tous les problèmes liés à l'héritage. Dès que tu dérives une classe tu crées un lien extrèmement fort entre ton code et la classe dérivée, et même en Java, il n'y a pas de miracles, tu te retrouves souvent à devoir hacker le code dont tu hérites (quand c'est possible).

Donc si tu crois vraiment qu'un langage n'est OO que si les méthodes y sont virtuelles par défaut, tu n'as rien compris et tu ne soupçonnes même pas à quel point le design OO peut être complexe, ni quels sont les outils dont on dispose en la matière. L'héritage n'étant que l'un d'entre eux, et certainement pas le plus important.

Enfin, concernant le fait que les créateurs de langage soient des clowns: ça ne me semble pas si impossible que ça.

Effectivement, ça n'est pas impossible, mais si à ce stade de la discussion tu es toujours persuadé d'avoir bien tout compris à la POO, et donc d'avoir assez de recul pour juger si les mecs qui ont fait C# sont des bozos ou pas, alors je crois qu'il est inutile de poursuivre.

Y a pas de messages en C++, ce sont des appels de fonctions avec eventuellement une indirection dans le cas des fonctions virtuelles.

> Bon, alors le C# est plus mauvais que je ne pensais

C'est vrai que quand tu lis une interview d'Anders Hejlsberg (par Bruce Eckel en plus)

http://www.artima.com/intv/csdes.h(...)

tu vois tout de suite que c'est un clown qui n'a rien compris à la POO et au design de langage. Et Eckel aussi puisqu'il ne lui fait même pas la remarque. Tu devrais leur mailer pour leur dire qu'ils n'ont rien compris.

> L'échantillon de programme C++ modifié en passant des pointeurs montre très bien le comportement que j'exècre

Oui, en passant des pointeurs, ou des références. Ça s'appelle le polymorphisme (ou plutôt le manque de, dans le cas présent, si on ne met pas 'virtual'). Note aussi que si tu changes affiche() pour qu'elle prenne un objet de type B, c'est bien la méthode B qui est appelée, qu'elle soit virtuelle ou non, ce qui démontre bien que 'virtual' n'a pas la fonction que tu lui prètes. Maintenant pour comprendre la nécéssité de l'existence de ce mot clé tu peux un peu te documenter sur le modèle objet de C++, savoir que la compatibilité avec C était un principe de base (et par conséquent qu'on ne pouvait pas ajouter systématiquement une table virtuelle à un objet), mais je te sens pas vraiment bien parti pour essayer d'aller au dela de ce que tu crois savoir.

> Si l'héritage n'est accessoire et "pour débutant" que pour les programmeurs C++, c'est justement parce qu'il est si problématique avec ce langage.

Alors faut prevenir les gens qui ont fait Java aussi, même dans la lib Java il n'y a quasiment jamais plus de 3 niveaux d'héritage (2 si on tient compte du fait que java.lang.Object est une base obligatoire). Pareil dans la lib de Ruby.

> la pwlib a un bel arbre généalogique de classes (qui merdouille dès qu'on veut y ajouter quelque chose, certes, mais ça c'est l'effet C++)

Non, c'est l'effet du Fragile Base Class Problem, qui existe dans n'importe quel langage OO et qui est la première conséquence de l'abus d'héritage. Tiens va voir là :

http://www.cas.mcmaster.ca/~emil/publications/fragile/(...)

In this paper we study the fragile base class problem. This problem occurs in open object-oriented systems employing code inheritance as an implementation reuse mechanism. System developers unaware of extensions to the system developed by its users may produce a seemingly acceptable revision of a base class which may damage its extensions. The fragile base class problem becomes apparent during maintenance of open object-oriented systems, but requires consideration during design.

Note bien qu'il dit "object-oriented systems", et pas "C++", et y a pas un poil de C++ dans le papier.

> On n'a pas besoin de la notion d'objet pour mettre des apis autour des données... par contre, pour faire l'héritage, c'est essentiel.

Tu n'as toujours pas compris : mettre des APIs autour des données, C'EST la notion objet. Regarde la série des fonctions fopen(), fclose(), fprintf(), etc... de la lib C. C'est une API objet, avec des méthodes sur une structure de donnée opaque (FILE*). Laisse tomber l'héritage, c'est presque accessoire et très souvent mal employé. Regarde Qt justement, la hierarchie des classes est simplissime, tu n'as presque jamais plus de 2 niveaux d'héritage (QObject->QWidget->QFoobar). A ce sujet je te conseille l'intro de Design Patterns, excellent texte qui remet l'héritage en perspective et parle d'autres méthodes pour réutiliser du code, comme l'agrégation (décidément y a pas une page de ce bouquin qui ne soit indispensable).

> Le C# n'a pas du tout le même genre de mécanisme que le C++

T'es sur ? Lis bien :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cs(...)

The virtual keyword is used to modify a method or property declaration, in which case the method or the property is called a virtual member. The implementation of a virtual member can be changed by an overriding member in a derived class.

When a virtual method is invoked, the run-time type of the object is checked for an overriding member.

C'est exactement la même chose qu'en C++.

> Enfin, je n'ai pas doublement faux, comme l'exemple suivant le montre

Ah, vraiment ? Essayons voir :

#include

class A
{
public:
void toto() { std::cout << "Hello World A\n"; }

};

class B : public A
{
public:
void toto() { std::cout << "Hello World B\n"; }
};

void affiche(A a)
{
a.toto();
}

int main()
{
B b;
affiche(b);
return 0;
}

Je compile et j'execute, ça m'affiche "Hello World A". Jusque là t'as tout bon. Maintenant, j'ajoute 'virtual' devant les 2 déclarations de toto(), et là surprise, ça m'affiche toujours "Hello World A". Ça alors. T'as une idée de pourquoi ?

> Je réaffirme donc mon propos

Et moi le mien : tu ne sais absolument pas de quoi tu parles. Ta conception de l'objet est celle d'un débutant qui croit que l'héritage est le seul outil dont on dispose en POO (erreur très courante, tout le monde passe par là), tu n'a pas compris à quoi sert le mot clé "virtual" en C++, et il te manque aussi la notion de polymorphisme.

> Il est de mauvaise foi et utilise des images choc pour dire ce qu'il a a dire, au lieu de faire un reportage detaille qui aurait un semblant d'objectivite

Comme le disait William Karel, auteur d'un autre excellent documentaire sur le même sujet ("Le Monde selon Bush"), "a propos de Bush être objectif serait obscène". Ce que Moore montre est essentiellement vrai. Il ne montre pas ce qui ne rentre pas dans son point de vue, mais ça n'empèche pas que ce qu'il montre est vrai, et pour l'essentiel, totalement ignoré des américains.

> Ceux qui ne haissent pas deja Bush n'iront pas voir le film, donc ca sert juste a s'autocongratuler entre personnes anti-Bush

Euh, t'as regardé les news dernièrement ? :-) C'est ce que tout le monde (même Moore) croyait, mais les chiffres du box-office US et les témoignages évoqués un peu partout montre que ça n'est clairement pas le cas. Le film a reçu des standing ovations même au Texas.

> Bien concevoir les interfaces ne suffit pas avec le C++, justement: si on n'a pas mis de 'virtual' partout, il va passer par l'interface de la classe parente et pas par celle de l'objet sur lequel on l'applique.

Qu'est-ce qu'il ne faut pas lire...

Ce que tu dis est vrai uniquement si tu manipules ton objet à travers une ref ou un pointeur du type parent.

> Pour moi l'idée centrale pour qualifier un langage d'orienté objets, c'est l'héritage

Je serais curieux de savoir d'où tu tires une idée pareille.

L'OO c'est pouvoir faires des APIs autour de tes types de données. L'héritage c'est juste un gadget pour pouvoir, effectivement, réutiliser du code sans trop se faire chier. Exemple : la STL, 100% OO, 0% d'héritage (ou presque).

> Le C++ n'entre pas dans cette définition, parce que pour faire de l'héritage, il faut le demander explicitement (mot-clef 'virtual')

Doublement faux. Tu n'as pas besoin de le "demander explicitement", et le mot clef "virtual" ne sert pas à ça.

Et pour info, C# a le meme genre de mécanisme, en pire. Non seulement les méthodes ne sont pas virtuelles par défaut, mais il faut expliciter qu'on en override une.

Bref, es-tu bien sur de savoir de quoi tu parles ? :-)

> Pourquoi toujours un mécanisme de signaux mal intégré et inhomogene avec le reste du langage ? L'argument des templates mal suportés ne tient plus la route

C'est une FAQ, est la réponse est que moc ne sert pas que pour les signaux mais aussi pour le modèle meta-objet de Qt (qui permet des choses sympas comme l'introspection).

<<Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin.>>

Là je serais curieux de connaitre tes arguments pour étayer ça.

Vu d'ici, c'est plutôt un cas classique de : "si mon langage à moi que j'aime a pas cette feature, ben c'est que cette feature c'est que d'la merdeuhhh".

Et sérieusement, as-tu seulement lu cette série d'interview de Hejlsberg ? Le gars est impressionnant par son pragmatisme et sa franchise.

En général, oui (C < C++ < Java < C#), ou sinon il offre un paradigme complètement différent (Lisp, OCaml...), mais dans ce cas il va "direct à la niche", si j'ose dire, et ne sort quasiment pas des Universités, labos de recherche, ou certains segments très précis de l'industrie.

Après tu as toujours des gars qui préfèrent l' "ancien" langage et trouvent le nouveau pleins de features inutiles|dangereuses|lourdes etc... Ça ne loupe jamais, et le fait que ça se répète pour chaque nouveau langage prouve bien que leur réaction est avant tout émotionelle ("c'est mon langage qu'est le mieux et je changerai pas, na d'abord"), et non rationelle.

(il y a aussi ceux qui veulent à tout prix utiliser le nouveau langage dans des situations ou il ne convient pas du tout, par ex. quand Java est arrivé, il y avait un thread récurrent sur comp.emacs à propos de l'opportunité de ré-écrire Emacs en Java :-).

En général chaque nouveau langage tire les leçons des précédents (typiquement : C, C++, Java, C#). On améliore l'outil de programmation, rien de plus.

Quand tu commences vraiment à avoir beaucoup de photos (disons quelques dizaines ou centaines de milliers, pas si rare avec les appareils numériques), pourquoi pas. Sinon, là encore un index texte tout con dans lequel tu vas dumper tes data exifs fera largement l'affaire. Note bien qu'on rentre très rarement des annotations manuelles, simplement parce que c'est trop lourd à faire. Longhorn a bien pigé ça en fournissant un mécanisme générique d'extraction des meta-datas en fonction du format du fichier.

Mais bon, en fait dès que tu explores la question des DBs dans des applis, tu en arrives toujours a la même conclusion : pour que ça marche bien faut foutre la DB dans le filesystem :-). Comme ça tu as le meilleur des deux mondes : recherche évoluée sans effort de dev, fiabilité, pas de dépendence avec une lib exotique... C'est pas pour rien que BeOS ou Longhorn mettent cette idée en pratique.

<<Enfin au final je pense que nous sommes d'accord, ca n'est pas une solution universelle mais ca peut servir.>>

Oui, les cas que tu cites sont des cas pour lesquels j'utiliserais probablement aussi une DB. Ceci dit si ca commence a vraiment prendre de l'ampleur, et que tu fais ca pour un client, il y a de bonnes chances pour qu'il ait déjà son install Oracle et qu'il te demande de t'y integrer :-).

<<si j'imagine un usage un peut intensif du client RSS, ca va me permettre de faire des corrélations entre sources mais aussi de proposer à l'utilisateur de chercher dedans de façon tres evoluée.>>

Quelles corrélations entre sources ? Peux-tu me citer un exemple, je ne vois pas ce que tu veux dire. Quant à faire des recherches dessus, y a déjà google... Et même, tu vas vraiment avoir besoin de plus qu'une simple recherche de mots clés ou de regexp, éventuellement triée sur la date ? Est-il vraiment utile d'ajouter une DB juste pour ça ?

<<Pour un client mail je vois tout de suite l'usage, j'ai personnellement plus de 2Gb de mail [...]>>

Tu n'es pas un cas typique, mais un de mes potes est exactement comme toi, sauf que lui c'est depuis le début des années 90 je crois (je ne sais plus quand exactement). Tout son mail est au format mh, et je crois me souvenir qu'il indexe avec glimpse. OK, à ce niveau là une DB est bienvenue. Mais sur les 20Mb de mail (sans compter les attachements, bien sur) qu'a l'utilisateur moyen, je maintiens que ça n'en vaut pas la peine. Si tu vises plus large, à ce moment là tu fais un outil de recherche généralisé pour tout tes fichiers tant qu'a faire, pas juste ton mail. Et tu ré-invente longhorn ou google-sur-pc :-).

<<Il n'y qu'a voir avec quelle régularité un bon nombre d'applis corrompent leurs données, ou deviennent incapable de relire leur formats de fichiers entre deux versions.>>

Ouais, comme les DBs par exemple. La corruption de données ça arrive forcément un jour ou l'autre, la seule question c'est comment limiter le niveau d'emmerdement. Et là une DB est une mauvaise réponse, alors qu'un bon gros format texte bien neuneu, c'est pas trop dur d'y retrouver ses petits. Quand à l'évolution d'un format d'une version à l'autre, ben c'est au dev de se dermerder pour être backward compatible si il ne veut pas trop faire chier ses utilisateurs. Là aussi une DB ne va pas t'aider, si c'est pas le format de la DB qui change, c'est le format de tes datas dans la DB...

Après oui, faire un format de données c'est pas si simple, mais il y en a tellement d'existants que c'est bien le diable si tu ne peux pas trouver ton bonheur quelque part.

<<Sans compter que moult programmeurs préferent réimplementer leur propres fonctions plutot que tenter d'utiliser les fonctions évoluées des bibliothèques>>

Y a des clowns partout. Mais je n'ai jamais travaillé pour une boite qui aurait accepté qu'un dev perde du temps à recoder quicksort, ni vu un dev assez bête pour le faire, quelque soit le langage.

<<jeter un oeil à SQLite parceque c'est bien fichu et vraiment à connaitre pour LA fois ou ce sera peut être la réponse au problème du jour.>>

Entièrement d'accord. Là ou j'objecte, c'est quand on me dit que c'est tout le temps la réponse, ou presque.