arnaudus a écrit 5258 commentaires

cette pratiques consistant à bloquer les comptes pour se servir ensuite est très courante.

Franchement, quel intérêt? Avec les frais de recouvrement et le fait que les créanciers sont les derniers servis lors d'une liquidation, la banque pop n'a pu récupérer qu'une partie de l'argent qu'elle a prêté. Si l'entreprise avait été viable, elle aurait récupéré le capital et les intérêts, c'est un mouvement complètement perdant pour elle.

Ton histoire ressemble plus à une magouille ratée de la part d'une filiale dans un pays où le contrôle bancaire est peut-être lacunaire (voire une simple erreur), qui a entraîné des problèmes de trésorerie. Je ne connais pas les procédures en termes de transferts internationaux, mais je ne crois pas vraiment à la possibilité de faire disparaitre des fonds lors d'un transfert (par contre, il est peut-être possible que le transfert ait été bloqué du fait de règles strictes sur les transferts de fonds hors de Tunisie, il est par exemple interdit de faire sortir du liquide des frontières Tunisiennes, et il n'est peut-être pas possible de faire ce qu'on veut avec les transferts internationaux).

Le fait que la banque ait été blanchie en appel montre qu'ils avaient au moins des explications crédibles sur ce qui s'est passé. Si par ton histoire tu veux dire que les banques ne sont pas tes amies, et qu'elles sont encore moins tes amies dès que tu as un problème de trésorerie, alors je pense que tout le monde est d'accord. Que les banques fassent des erreurs et qu'elles soit particulièrement non-professionnelles dans certains cas, on est d'accord aussi. Par contre, qu'elles coulent volontairement des entreprises pour récupérer du cash, je n'y crois pas une seconde ; si elles bloquent sciemment des comptes, ça ne peut être que parce qu'elles sont convaincues de ne jamais récupérer leurs billes autrement.

Portnawak. L'ordre est très strict et très bien défini pour une liquidation.

1) les salariés
2) le mandataire
3) le fisc
4) l'URSAFF et autres caisses/machins sociaux
5) les fournisseurs sans privilèges particuliers.

Présenté ainsi, on pourrait penser à des personnes qui se réjouissent du malheur d'autrui; ce qui, assurément, est difficile à cautionner.

Ouais, ou alors des personnes qui sont bien contentes de voir disparaitre un concurrent sans business model viable qui leur prenait des parts de marché. Il y a une différence majeure entre se réjouir du malheur des autres et se satisfaire d'une situation qui revient à son état normal.

Je crois que tu t'es simplement trompé sur l'idée qu'on pouvait bénéficier d'une faillite… J'imagine qu'il y a toujours des cas tordus où c'est marginalement possible, mais d'une manière générale, la faillite permet de limiter ses pertes à la hauteur de son investissement initial, mais pas de gagner de l'argent… Au pire du pire, on a bénéficié «gratuitement» de prestations qu'on ne payera pas, mais ça n'est pas au bénéfice des actionnaires.

Si tu voulais parler de "redressement", je ne vois toujours pas en quoi ça peut être intéressant pour l'actionnaire à part pour ne pas aller jusqu'à la faillite.

Ce n'est pas très convaincant quand on compare son témoignage à la réalité.

Bah si, c'est de manière très convaincante le discours typique des mecs qui sont en train de noyer le poisson tout en achetant un aller simple vers un pays où l'extradition est compliquée. «Tout va bien, on sait ce qu'on fait, les autres sont jaloux, le pognon est toujours là et si on ne peut pas vous le rendre tout de suite c'est de la faute de X ou de Y».

Euh, je n'y connais pas grand chose dans le domaine, mais j'ai l'impression que l'actionnaire récupère sa mise en dernier, au contraire (c'est à dire, dans les faits, rien du tout). Il faudrait que les actifs soient énormes pour éponger les dettes et laisser quelque chose en plus, et si c'était le cas, l'entreprise aurait pu trouver des créanciers pour leur avancer de la trésorerie, non? (puisque les créanciers auraient eu des garanties).

Ils n'ont pas pu trouver en France de fonds suffisants pour rester indépendants

C'est une ligne de défense un peu étrange qu'on lit souvent de la part des entreprises qui sont en train de mourir. Pour moi, c'est le même argument que le mec qui veut qu'on lui prête encore 1000€ pour qu'il se refasse au casino, et qui attribue sa perte de 100000€ à l'enfoiré qui n'a pas voulu lui prêter les 1000€.

C'est super facile d'investir avec le pognon des autres. C'est aussi facile d'accuser les autres quand on ne sait pas ramener du cash.

Sur un plan purement rationnel, un investisseur n'a en général aucun intérêt à laisser couler une boite dont il est actionnaire. S'il ne veut plus remettre du pognon, c'est qu'il considère que la situation est foutue et qu'il ne reverra jamais son investissement initial. Bien sûr, il peut se tromper, mais il n'a aucune raison de le faire volontairement.

Ces application évoluent rapidement et doivent être très fréquemment mises à jour pour corriger des failles de sécurité.

Là je suis un peu paumé. N'est-ce pas l'intérêt majeur d'un système de paquets que de faire reposer la veille technologique et l'intégration des patches au mainteneur du paquet?

Mouais, je trouve quand même ça déplacé de faire ça devant tout le monde. Il peut très bien lui dire ce qu'il pense en mail privé, et officiellement dire qu'il s'est expliqué avec Andrew et qu'ils s'étaient assurés que ce genre de choses n'arriveraient plus.

Honnêtement, je ne trouve pas ça digne d'un chef, de dénoncer nommément les responsables de conneries. C'est des méthodes de management à la Cyril Hanouna, c'est ça? Si une telle chose a pu arriver, c'est à cause d'un problème d'organisation, puisque le système est censé être fait pour que ça n'arrive pas. Peut-être qu'Andrew a fait comme Linus, qu'il a laissé passé un truc dans l'urgence sans le voir.

j'avais des attentes bien plus grandes de choses pouvant venir de la part d'Andrew.

Dites donc, l'ambiance est toujours autant au beau fixe…

Non, je crois que ça ne marche pas du tout. En termes de droit d'auteur, tu ne transmets absolument rien au destinataire, ça reste ta lettre, tu lui donnes le droit de la lire, et c'est tout. Quand tu reçois un CD d'installation d'Ubuntu par la Poste, tu crois que tu récupères les droits d'auteur dessus? C'est absurde.

Si j'ai bien compris le texte de Maitre Eolas, le problème est que beaucoup de gens ne comprennent pas ce qu'est le secret de la correspondance. Le secret de la correspondance, ça protège l'auteur et le destinaire d'un courrier dans le sens où les intermédiaires n'ont pas le droit de l'ouvrir pour le lire. Ça n'empêche absolument pas le destinataire de le lire (ce qui est quand même implicite quand tu envoies un courrier) ni d'en faire usage comme il le souhaite (par exemple, en dévoiler le contenu ou en parler à qui on veut). Bref, c'est exactement la même chose que pour une conversation privée : si quelqu'un te confie un secret, tu as le droit d'en parler à tout le monde ou de le dévoiler dans les journaux (tant qu'il n'y a pas de diffammation) ; c'est impoli mais ça n'est pas illégal. La seule limite, c'est le respect du droit d'auteur, puisque tu n'as pas les droits pour diffuser une œuvre de l'esprit (mais c'est pareil que si on te récite un poëme ou qu'on te chante une chanson originale par téléphone). Ceci étant dit, s'il s'agit d'un SMS ou d'une info succinte, difficile de faire valoir son statut d'œuvre de l'esprit…

Bref, quand tu envoies une lettre à quelqu'un, c'est exactement comme quand tu racontes quelque chose à quelqu'un : il est libre de le raconter à qui il veut, la seule manière de protéger une information est de ne pas la dévoiler à n'importe qui. Après, ça peut être malvenu, impoli, mal élevé, ou relever de la goujaterie de dévoiler le contenu d'une correspondance privée, mais il n'est pas illégal d'être un goujat…

La théorie veut que le sérif trace une ligne de base qui facilite la lecture sur papier. De fait, c'est un peu dur à dire si ça fait une différence, parce qu'il y a très peu de bouquins en sans serif. Par contre, du fait de la résolution limitée des écrans, le sans serif est censé moins baver et ne pas mettre l'anti-aliasing à l'agonie.

Mais bon, si la seule critique typographique qu'on pouvait faire aux gens qui produisent des documents sous traitement de texte étaient le choix des polices serif/sans, ça serait miraculeux.

Pas style de titre souligné?

Encore heureux, c'est typographiquement hideux. D'une manière générale, le souligné n'existe pas en typographie. Tu ouvres n'importe quel livre composé par un professionnel, et tu n'as jamais de style souligné.

Le corps de texte en serif et les titres en sans serif

C'est pourtant une mise en forme assez standard. Je viens de vérifier sur ma pile de livres sur mon bureau (bouquins scientifiques), et sur 7 livres, j'en ai 3 en serif/serif, 3 en sans serif pour les headers /serif pour le texte, et un tout mélangé (texte en serif, titres de sections en sans serif, titres de chapitres en serif, et hauts/pieds de pages en sans serif). Pourtant ce dernier date de 1970 et sort de chez Harper & Row, donc a priori des gens qui savaient composer un bouquin.

Du coup, j'aurais tendance à penser que les titres en sans serif gras et le corps du texte en serif, pour un choix par défaut, ça n'est pas délirant.

N'importe qui peut utiliser le logiciel, mais n'importe qui ne peut pas le développer

Ça a toujours été comme ça. Personne n'est obligé d'accepter tes patchs, ni même d'argumenter pour expliquer pourquoi tes patchs ou tes rapports de bugs sont ignorés. En fait j'ai l'impression que tu ne sais pas trop comment fonctionnent les différentes communautés, certaines sont très ouvertes, certaines sont très fermées, et pour certains logiciels il n'y a même pas de communauté.

Dans tous les cas, tu es libre de développer, et si tu n'es pas content, tu forkes. Et si tu ne veux pas forker, tu n'envoies plus tes correctifs si tu n'es pas content.

C'est pas trop ma vision du libre.

Ta vision du libre, tu peux l'imposer dans le fonctionnement de la communauté qui s'est formée autour du logiciel que tu développes, et c'est déja bien. Avec une telle vision, tu devrais attirer des milliers de contributeurs dégoûtés de l'ambiance pourrie des autres communautés. Y'a plus qu'à.

Et au final, ça fait partie des petits trucs qui donnent l’impression que le noyau Linux est club de mecs et aide pas à se sentir à l’aise là-bas.

Tu sembles partir du principe que tous les mecs se sentiraient à l'aise là-bas, et ça n'est pas du tout le cas. Le kernel est un endroit où ça fritte, c'est une sorte de vestiaire de rugby, les mecs se mettent des grands coups de serviette mouillées et vont dans des bars à putes après les matchs. C'est tolérable parce que ça n'est pas une obligation d'aimer cette ambiance, on peut même apprécier le rugby en tant que spectateur sans pour autant imaginer aimer l'ambiance des vestiaires. S'il leur faut ça pour gagner, alors je ne vois pas vraiment le problème. Bien sûr, tu pourrais dire par exemple qu'il pourrait y avoir de bons joueurs de rugby qui ne boivent pas ou qui sont homos, et qu'ils se détournent de ce sport parce qu'ils ne supportent pas l'ambiance. C'est très certainement vrai, mais est-ce qu'un monde complètement lisse est aseptisé est réellement souhaitable? Les machos vulgaires, ça existe, et c'est très dur de les changer ; s'ils jouent bien au rugby ou contribuent au meilleur OS du marché, est-ce que ça ne revient pas à leur donner un rôle social où ils sont utiles?

Après tout, le logiciel libre c'est surtout une histoire d'initiative, et ceux qui ont le pouvoir, c'est ceux qui se sortent les doigts du cul. Torvald a créé autour de lui une communauté à son image, il a tout monté tout seul, grâce à son énergie et sa compétence indiscutée, à la fois (ce qui est très rare) sur le plan technique et sur le plan humain (oui, parce qu'étrangement, il y a des gens qui sont particulièrement motivés par les ambiances de compétition). Si j'étais big boss du noyau, ça n'est pas du tout comme ça que ça fonctionnerait. Mais le big boss du noyau, c'est Linus, et moi je suis le boss de mes propres fesses (et c'est déja pas mal).

Si tu trouves que certains débiles essayent de reproduire cette ambiance dans leur petits projets où deux contributeurs se battent en duel, c'est probablement vrai, et c'est un peu pathétique. Mais on s'en fout, des minables, il y en a partout, et ça n'a jamais empêché le monde de tourner.

Je suis certain qu'il est possible de monter des communautés de développeurs autour de grands projets libres en imposant une culture différente. Il suffit que les gens qui montent le projet aient la volonté d'imposer une ambiance de travail différente, et surtout qu'ils fassent en sorte que ça soit efficace et que les contributeurs soient compétents. On ne peut pas dire que le libre manque de grands chantiers : client email moderne, traitement de données multimédia, plateformes de développement, traitements de texte de nouvelle génération, jeux, IA… tant de choses à faire. Y'a plus qu'à faire ce qu'on veut de la manière dont on voudrait qu'elles soient faites.

Au passage, ça pourrait être intéressant d'avoir le point de vue de développeuses qui apprécient l'ambiance "kernel". Je trouve ça assez caricatural finalement d'imaginer que tous les mecs aiment se faire rabrouer et que toutes les filles sont des choses fragiles à qui il faut parler en douceur.

Beaucoup de gens sont rétribués pour des tâches communes. Les élus, par exemple. Les enseignants, les chercheurs aussi. Bref, l'État finance pas mal d'activités non-lucratives et paye des gens pour ça.

Même les boîtes privées financent des tâches communes (syndicats interprofessionnels, comités de normalisation, organisations diverses et variées, plus ou moins éthiques ou morales). Dans une certaine mesure, beaucoup de contributeurs aux logiciels libres sont payés pour ça (il n'y a qu'à voir le poids des professionnels dans les contributeurs du kernel…).

Ça peut prendre du temps et beaucoup d'énergie pour convaincre un État de financer une tâche collective, mais ça n'est pas impossible. Par contre, il faut un minimum d'organisation, et de bonnes raisons. Parce qu'il ne faut pas non plus imaginer qu'on va toucher son chèque parce qu'on bricole du code libre dans son garage…

en droit français du moins — ce n’est pas obligatoire.

Pour le réutiliser dans le cadre d'une correspondance privée, peut-être pas, mais pour le publier, on tombe sous le coup du code de la propriété intellectuelle avec tout ce qui va avec (après, tout dépend du contenu de la correspondance. Il faut que ça soit une œuvre de l'esprit).

Ah oui, mais on parle du moteur de recherche, là, pas de l'email. Ça n'est pas tout à fait pareil, parce que le moteur de recherche, on lui donne les infos volontairement. On peut aussi aller trifouiller dans les options de confidentialité de Google pour lui demander de ne pas garder l'historique, je crois (après, je ne sais pas s'il le fait vraiment). La différence avec Gmail, c'est qu'on ne transmet pas volontairement un email à Google, on le transmet à un correspondant.

Mais sur le fond, je suis d'accord, les requêtes dans un moteur de recherche peuvent être beaucoup plus informatives et beaucoup plus intimes que les emails. Google sait avant tout le monde (et parfois même avant toi!) si tu es malade, si tu es enceinte, si tu t'es fait virer, si tu cherches à mettre ton fric aux Caïman, si tu aimes les photos de nains nus, si tu montes une entreprise ou si tu cherches un avocat spécialisé dans le divorce. D'un autre côté, c'est quand même plus facile de rendre ces requêtes non-nominatives si on le souhaite ; je ne suis pas certain que l'historique soit conservé si longtemps que ça (ne serait-ce que pour des raisons de stockage --- 1000 milliards de requêtes par an, ça ne fait pas tant que ça, remarque, quelques Po par an peut-être).

Après, c'est la même chose pour tout tiers de "confiance" : ta banque, ton FAI, la sécu, ton employeur, ou la RATP on des données très personnelles sur toi et les membres de ta famille. J'imagine (peut-être naïvement) qu'elles sont relativement bien protégées des intrusions extérieures chez Google comparé à ces derniers.

En fait, le problème est que personne ne semble souhaiter identifier le problème précisément. On parle de problème de vie privée ou de libertés individuelles, mais sans plus de précisions, on ne peut pas parler de solutions. Qu'est-ce qui pose problème avant tout?

1) que les emails passent par un état déchiffré avant d'être affichés sur l'écran? Mais dans ce cas, est-ce qu'on met les filtres anti-spam dans le problème? Est-ce qu'on n'autorise que le client mail à filtrer les spams, tagguer les pubs, avertir en cas de tentative de hameçonnage?

2) que les emails puissent être analysés par des algorithmes. Ceci dit, ça pose le même problème que les filtres anti-spam, et avec le développement inévitable de l'IA, les algorithmes vont de mieux en mieux comprendre ce qu'on raconte. Est-ce que des tags "personnel", "urgent", "interne", "nouveau client" ajoutés par un algo poseraient des problèmes de confidentialité?

3) que les emails puissent être interceptés par autre chose que le serveur de destination. C'est un problème, mais ça ne résoud pas le cas des webmails populaires.

4) que les emails puissent être analysés à des fins commerciales. Autrement dit, si Google veut faire des études scientifiques sur les évolutions du vocabulaire ou la longueur des phrases, OK, mais si c'est pour afficher de la pub, pas d'accord.

5) que les emails puissent être accessibles à des prestataires privés

6) que les emails puissent être accessibles à des services gouvernementaux

7) que les emails puissent être lus par des êtres humains.

8) que les emails puissent être lus par des êtres humains à des fins illégitimes, illégales, ou non-éthiques.

On peut ajouter autant de niveaux supplémentaires qu'on souhaite. Et en fonction de ce qu'on souhaite, on peut discuter des solutions, et on peut même discuter de l'existence du problème—et du niveau de fantasmes qu'il y a dans la présentation d'un grand problème qui n'est jamais réellement explicité.

Au final, on parle aussi beaucoup de problèmes potentiels, mais pas de problèmes réels. Si on désactive adBlock, on peut voir les publicités proposées par gmail. C'est une bonne expérience, parce qu'on peut réellement s'apercevoir à quel point les algorithmes ne comprennent rien. "J'ai changé le bébé, il n'y a plus qu'une couche, il faut en racheter" -> Dulux Valentine; "Le frigo est vide" -> Darty, etc. Imaginer que Google connait tout de votre vie est réellement de l'ordre du fantasme, Google a en effet les données qui permettrait de vous connaitre si un être humain passait suffisamment de temps à lire et analyser vos mails, mais les algos n'attrappent que quelques mot-clés, ne semblent avoir aucune mémoire ni aucunes capacités analytiques. Ou s'ils les ont, ils ne les utilisent pas pour cibler les pubs. Ou bien s'ils détectent un esprit critique ils font exprès de vous mettre des pubs idiotes pour vous faire croire qu'ils sont incapables de tout savoir sur vous. Ou alors ils s'en foutent réellement de votre vie.

Concernant sort, là tu bloques sur l'écriture OO mainstream on dirait.

Bah non, ma compréhension du problème est que la généricité de la fonction sort() impose l'utilisation d'itérateurs uniquement parce que les containers de la STL n'héritent pas d'une interface commune.

L'écriture qui est sympa c'est sort(v) pourquoi est-ce que cela devrait être v.sort()?

L'intuition est peut-être la chose au monde la moins partagée, mais pour moi les signatures "intuitives" de ces deux fonctions devraient être

std::vector<T> sort(const std::vector<T> &);
void vector<t>::sort();

Je trouve très surprenant en général que y = f(x) puisse modifier x, et les compilos récents n'ont aucun mal à optimiser v = sort(v) correctement. Ceci dit, j'ai peut-être tendance à tenter de retrouver en C++ des concepts qui viennent des langages de plus haut niveau.

elle va supporter l'écriture vi |= action::sort | action::unique;

On peut voter quelque part pour le support du Brainfuck dans C++19?

Je veux un tableau dans une classe concrète? std::vector<>. C'est générique et je m'en sers.

J'ai l'impression qu'on ne se comprend pas, et au bout d'un moment ça tourne en rond. Je pense que personne ici ne parle de ne pas utiliser les conteneurs de la STL ; utiliser la STL n'a pas grand chose à voir avec la programmation générique.

La question (telle que je la comprend), c'est de choisir entre

struct EtatCivil {
   string nom;
   string prenom;
};

et

template<typename n, typename p>
struct EtatCivil {
    n nom;
    p prenom;
};

comme paradigme de base. Sans aller jusqu'à prétendre qu'il faut 100% de l'un ou de l'autre, mon argument c'est que la plupart des problèmes ont une solution avec l'un ou l'autre, et que comme les deux sont très difficilement fongibles, on va orienter l'ensemble de l'architecture du programme dans un sens.

Je veux trier un tableau ? std::sort()

Je pense que c'est un excellent exemple. C'est générique? OK. Mais l'ergonomie est dégueulasse, parce que tu as oublié que ça s'utilisait comme ça : std::sort(v.begin(), v.end());. Évidemment, à force de voir ça, on est habitué, mais tu ne trouves pas que v.sort() serait bien plus élégant? Il permettrait aussi le polymorphisme si tous les containers dérivaient d'une interface STL_cont. Bref, la programmation générique pour la bibliothèque standard, c'est un choix technique, mais ça me semble assez excessif de prétendre que c'est pratique et ergonomique ; d'une manière générale, la STL est relativement imbittable, les syntaxes sont contre-intuitives, et le code est assez illisible.

je sais ne pas pouvoir vouloir d'un T ITruc::operator non plus—oui, de connaitre la limitation, ça oriente fortement ce que je m'autorise à vouloir faire.

Oui, donc dans les faits si tu ne veux pas utiliser le polymorphisme, bah la programmation à base de templates ne te pose pas de problème :-) Encore une fois, mon point de vue n'est pas de dire que la programmation générique c'est pourri, c'est de dire que le C++ OO et le C++ générique (au sens de templates non triviaux sur des objets complexes) sont philosophiquement et techniquement incompatibles. On peut concevoir tout un projet en C++ OO ou en C++ générique, mais ça va fortement conditionner le sous-ensemble du C++ et les designs qu'on va utiliser.

Bien sûr, on peut écrire des trucs hybrides, ça va compiler, et ça va faire d'excellents exercices pour les gens qui aiment se prendre la tête. La question, c'est plutôt "est-ce que des projets réels vont utiliser ça"?

PS: Truc peut tout à fait hériter de ITruc ou de TrucImpl. C'est même assez classique quand on veut combiner une variabilité dynamique avec une statique.

C'est super bancal comme solution, parce que ça demande une surcouche, et que l'interface n'est pas templatée. Prenins un exemple trivial : je veux faire un vecteur de vecteurs de différents types. On peut bien créer quelque chose comme vector<MyVec*> avec des MyvecT<T> qui dérivent d'une classe MyVec, mais à ma connaissance on ne peut pas avoir une méthode MyVec::at(size_t i) const qui retourne le bon type (*).

Si la programmation générique était fongible avec la POO, alors le langage devrait assimiler un template à une interface, et autoriser des choses comme vector * v; qui se comporteraient comme des pointeurs vers des classes virtuelles pures. Je ne sais pas si c'est pour des raisons techniques ou philosophiques que le C++ a choisi des syntaxes incompatibles, mais je ne vois pas comment on peut l'interpréter autrement que par la volonté de définir deux dialectes qui ne sont pas destinés à cohabiter dans le même code.

(*) Enfin si, je crois qu'on peut si la méthode retourne un void* qu'on peut caster avec un typename qu'on aurait défini dans Myvec<T>. Je ne sais pas s'il existe une personne sur terre qui pourrait croire que c'est une bonne idée.

Ces paradigmes ne doivent pas être opposés. Ils offrent des choses complémentaires.

Et du coup, il faut combien de décennies d'apprentissage avant de savoir choisir le bon paradigme?

pour gérer la mémoire, par défaut je vais utiliser des unique_ptr<> qui sont génériques.

Je pense que personne ne considère qu'utiliser les conteneurs de la STL revient à faire de la programmation générique.

Je comprends que devoir écrire ce genre de classe from scratch fasse peur à quelqu'un qui n'est pas habitué

Je n'aime pas le fenouil braisé. Est-ce que ça veut dire que j'ai peur du fenouil braisé? Est-ce légitime de m'expliquer que la seule raison pour laquelle je n'aime pas le fenouil braisé est que je n'y suis pas habitué? Au bout d'un moment, c'est agaçant.

Reste que ce ne sont pas des paradigmes opposés.

Si, parce qu'ils sont incompatibles, et qu'ils répondent tous les deux au même besoin de base (utiliser le même code pour appliquer les mêmes opérations à des objets différents qui partagent un certain nombre de propriétés). Si on va au-delà des simples conteneurs style STL, on se retrouve avec des possibilités d'architectures parallèles (d'un côté, Truc<A> et Truc<B>, d'un autre côté TrucA et TrucB qui dérivent de Truc), avec chacun leurs paradigmes, leur syntaxe, leurs contraintes et leurs avantages. Mélanger les deux dans un projet un peu complexe me semble assez incongru, au moins autant que de mélanger des paradigmes C et C++, par exemple.

Je pense qu'en 2017 nous publierons de petites dépêches pour expliquer les aspects de la programmation générique et surtout la méta-programmation (et un peu de programmation fonctionnelle) car c'est l'intérêt de coder en C++.

Bah, je n'ai rien personnellement contre la programmation générique. C'est juste que le C++ OO et le C++ générique ressemblent de plus en plus à deux dialectes distincts, au moins autant que le C et le C++98. Et s'il est techniquement possible de mélanger les deux (le compilateur le comprend), c'est de plus en plus compliqué de les faire cohabiter dans le même projet. Mon impression est que de toutes manières les programmeurs ne vont plus pouvoir s'en sortir avec les deux paradigmes à la fois; d'un côté on aura le monde des design patterns et du typage dynamique, et de l'autre côté on aura les templates de templates et le typage statique.

Par contre, du coup, appeler tout ça "C++" et continuer à prétendre que c'est le même langage, ça n'est pas très sain. Pour recruter quelqu'un dans une boîte ou dans un projet, il va falloir préciser quels aspects du C++ on souhaite privilégier. De même, il pourrait être sympa de commencer à définir des sous-ensembles plus ou moins officiels qu'on pourrait passer aux compilateurs, pour vérifier qu'on respecte bien le cadre imposé. J'ai appris il y a peu de temps que pour émuler ce comportement, certains n'acceptaient que d'anciennes versions des compilateurs, ce qui me semble profondément stupide (on peut ne pas vouloir autre chose que du C++98 tout en voulant profiter des corrections de bugs et des optimisations des compilos récents).

Le mot-clé template fait peur, démystifions-le ;-)

Je ne pense pas que ça soit les templates qui fassent peur, c'est l'ensemble pas très intuitif des syntaxes associées.