J'interviens juste pour faire quelques remarques :
Ne prenez pas le C/C++ pour les Dieux des langages.
Beaucoup de firmeware utilisent des langages adhoc, beaucoup de BIOS (celui des Mac notamment) utilisent du Forth, qui est bien plus adapté pour faire du code compact et performent que le C.
Le problème du Forth, c'est qu'il est spécialisé et donc avec très peu de fonctions.
A la fin, code natif ou code interprété, c’est du code machine, qui est un langage, qui est exécuté. Sans compter le microcode dans les CPU.
C/C++ sont des langages
polyvalents qui ont servi au début dans les OS, doit leur omniprésence dans ce domaine (plus le C que le C++). Mais les OS ont généralement besoin d'être polyvalents, mais rarement les applications. Le développeur, lui, aime être polyvalent donc un dédain/peur des langages spécialisés.
Il ne faut pas non plus se leurrer, un avantage indéniable pour l'acceptance du C++ était sa proximité supposé avec le C.
Maintenant, cela joue en sa défaveur mais on ne peut pas tous avoir.
Le fait de la multitude d'intervenant dans la norme C++ peut expliquer bien des choses que je voudrais souligner par un exemple.
Bon nombre de personnes n'aime pas le diptyque .H/.CPP. D'autres trouve cela indispensables pour une bonne organisation.
Les deux ont raison et le fait qu'il y ai un nombre très important d'intervenant dans C++, interdit de compenser des lourdeurs par de l'outillage.
Si l'on prend des langages comme C# ou Java, avec les IDE VS et Eclipse, les outils de refactoring influences directement le langage.
La qualité d'un langage tient, maintenant que la puissance CPU des stations des développeurs est "considérables", énormément dans son "écosystème".
Le C++, par son ouverture, ne dispose pas actuellement d'un écosystème aussi efficace au niveau productivité. Quantitativement, grâce à Intellisence par exemple, mais aussi qualitativement, par les outils de tests automatiques et d'analyse de code.
"lint" contre "Code Analysis" : au moins 20 ans d'écart.
Je pense que le fait que le C++ reste un langage "Notepade-aware" bride énormément son évolution.
Les fichiers d’en-tête ont été conçus pour accélérer la compilation. N’oubliez pas que C a été conçu au début des années 70, sur des PDP-11 je crois.
Avec un IDE, qu’il y est un fichier d’en-tête ou pas ne devrait être qu’un détail qui n’influence pas le langage.
Java qui début publiquement en 1995 sur Pentium Pro n’a pas les même contraintes.
Le fait de définir des interfaces avec les .h n’est qu’un effet de bord, vertueux je l’admets, mais ne remplace par la définition de vrais interfaces. Un IDE peut facilement faire l’extraire l’API d’une classe de manière automatique (facile aujourd’hui mais pas en 1971)
En résumé, le langage n’est pas le problème, c’est sont écosystème hétérogène qui bride son évolution aux besoins des années 2010 et non aux besoins de 1971 (C) ou de 1985 (C++).
3 |
0 |