Re: Nouveau langage

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?

Combien de décennies faut-il pour savoir correctement concevoir? Je ne parle même pas de programmer, mais d'assimiler l'OO avec ses bonnes pratiques, le génie logiciel, la gestion des ressources, etc. Tout demande un investissement dans nos métiers—je sais que ce n'est pas ce que nos employeurs voudraient entendre.

Et pour savoir quoi choisir, la question, mes collègues savent toujours y répondre: est-ce un choix qui se fait à la compilation ? A l'exécution ? Au lancement ?

Après, j’admets volontiers que les choses deviennent compliquées quand on veut le beurre et l'argent du beurre. Exemple typique : un calcul sera appliqué sur des pixels d'images du spatial (en 10000x10000), mais la nature du calcul on ne la connait pas avant que l'utilisateur ne lance l'application. Là on veut un point de variation dynamique, et éviter de payer pour ce choix à l'exécution.

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

En termes de paradigmes, certains distinguent la programmation générique où l'on va utiliser, voire écrire des types génériques (comme on faisait en Ada sans que cela ne choque personne), et la métaprogrammation template où l'on va commencer à adapter automatiquement l'algorithme générique choisi en fonction des types que l'on manipule (p.ex. un tri sur une collection qui offre un accès direct et celui sur une collection qui n'offre qu'un accès séquentiel ne sera pas le même ; std::copy sur des POD pourra utiliser memcpy, etc).

Les trucs les plus avancés que j'ai fait dans du code métier, c'est définir des listes de types décrivant des informations pouvant être extraites d'une trame binaire (ordre, nb bits dans la trame, type C++ associé après décodage). J'ai fait ça par métaprog. D'autres décrivent les trames en XML et font des parseurs compliqués, ou des générateurs de code. Dans tous les cas, un investissement est requis pour la technique employée.

Pour le fenouil braisé, on a des mécanismes similaires : l'envie de creuser, le temps, l’honnêteté d'admettre que c'est adapté (ou non!!) à une situation. Il y a beaucoup de critères. L'essentiel de ces critères est humains. Je renvoie à la première partie de la dernière présentation de Dan Saks au CppCon2016. Çà fait bien 20ans (plus?) qu'il essaie de vendre le typage supérieur à 0 surcoût du C++ avec template à la communauté C embarqué. Dans la première partie de la vidéo, il revient sur ce qui s'est passé et les raisons (humaines) de son échec.

Si ceux qui connaissent le C++ sont convaincus que la généricité peut s'importer facilement, voire plus facilement qu'un conception OO de qualité (combien ont compris SOLID et en particulier le LSP, et ce qu'est véritablement l'encapsulation? Trop peu.), pourtant ça bloque.

Tu me dis que ce n'est pas parce que ça (te) fait peur. Pourquoi alors ?

PS: Truc<T> 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.