Pour moi, le C est effectivement trop utilisé, et dans la plupart des cas les développeurs y gagneraient à utiliser C++ qui, jusqu'à ce que j'aie la preuve du contraire, peut faire les mêmes choses à bas niveau, mais en plus permets de les encapsuler de façon à ne pas risquer d'oublier un (削除) delete (削除ここまで) free.
L'excuse de la gestion manuelle de la mémoire est un faux problème, en C++ il est rare d'avoir réellement besoin de le faire: les smart pointers et la RAII sont là pour ça. En plus, contrairement à des langages utilisant un GC, c'est bien plus simple de savoir quand un objet va être libéré, et donc quand il finira par libérer les ressources dont il à besoin: accès fichier, connexion à une base de données et connexion à un port sont les premières choses qui me viennent à l'esprit, et je ne connaît pas des masses de programmes qui ne manipulent rien de tout ça.
Les garbages collectors devraient commencer par se collecter eux-mêmes franchement.
Pour le C++, je peux aussi citer les templates qui sont extrêmement puissants. La dernière fois que j'ai eu à toucher du Java ou du C#, il n'était pas possible de faire de la spécialisation partielle, entres autres (je parle d'avant 2011). Pourtant, ça simplifie la vie des devs.
L'un des problèmes par contre du C++, c'est que dès lors que l'on doit exposer des classes et des méthodes l'ABI n'est plus garantie, donc on s'expose à des emmerdes si on à pas le même compilo dans la même version (du coup la méthode habituelle est d'utiliser le sous-ensemble C: des structs qui n'intègrent aucune méthode qui sont gérées par des fonctions. Du C quoi.).
Donc, le C à bel et bien un avantage sur certains langages de plus niveau.
Ce même avantage reviens quand on doit faire interagir des applications écrites dans des langages différents: le Java, le C++, le C#, et probablement d'autres plus obscurs savent tous charger des bibliothèques codées en C.
Je vais continuer sur python (histoire de me faire encore plus moinsser), et dire que je trouve néfaste le fait qu'un langage soit si dépendant de sa version. Sur la machine de laquelle j'écris, j'ai 2 versions de python. Par contre, une seule version de libc. Et manifestement, j'ai pas loin d'une centaine de Mo de dépendance pythonique. Oui, je sais, l'espace mémoire c'est pas cher, mais moi, je me dit que 100Mo * 9, c'est déjà près d'un Go. Pourquoi par 9? Parce qu'il y à 9 PC de bureau à mon taf. 1 Go, c'est vrai, ce n'est rien... mais je suis encore à l'échelle d'une petite entreprise.
Dans le cas de perl, c'est moins pire, seulement 50Mo, mais il faut dire que perl semble beaucoup moins dépendant de la version du langage. Moins utilisé aussi. On peut supposer que ce serait dans les 100Mo aussi s'il y avait 2 versions...
Si l'ensemble des gens de ma boîte tournaient sur Debian, configuré pour être minimaliste (oui, parce que les 150Mo, c'est sur une config que j'essaie de garder minimaliste, je pense que si j'avais un DE monolithique type KDE ou gnome, ce serait très probablement plus gros...) on parlerait alors de 1.5Go, à la louche.
À l'heure ou l'on parle d'économie d'énergie, c'est tout de même dommage, non? Parce que les libs et interpréteurs, il faut les charger en RAM, pour que ça serve. Et quand on charge un programme interprété, il faut stocker la forme binaire optimisée, en RAM également. Hors, la RAM, ça consomme de l'énergie.
J'ai vu une étude qui montrait que le coût en énergie des machine est de moins en moins négligeable face à leur coût d'achat. Certes, c'est dû au matos de plus en plus performant, mais pourquoi as-t-on besoin de matos de plus en plus performant?
Alors, ok, je te rejoins sur le fait que 90% des applications incluant une interface graphique n'ont aucun intérêt particulier à être codées en C. Par contre, je ne vois pas ce qui leur interdirait d'être écrites en C.
Quant à l'argument "oui mais les débutants savent pas faire proprement".
Désolé, cet argument est juste l'un des pires qui existe: si on commence à jauger les langages à l'aune des cochonneries que font les débutants, alors je doute qu'il existe un seul langage correct: je défie quiconque de me prouver que pour un langage donné il est impossible de faire du code de plus de 1000 lignes qui soit crade (je dirait même que moins un langage est typé, plus il est facile d'écrire de la merde, le code php que j'ai devant les yeux au taf le montre bien).
[^] # Re: suckless !! More is less !
Posté par freem . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
Si je dois dire exactement ce que je pense, ok.
Pour moi, le C est effectivement trop utilisé, et dans la plupart des cas les développeurs y gagneraient à utiliser C++ qui, jusqu'à ce que j'aie la preuve du contraire, peut faire les mêmes choses à bas niveau, mais en plus permets de les encapsuler de façon à ne pas risquer d'oublier un
(削除) delete (削除ここまで)free.L'excuse de la gestion manuelle de la mémoire est un faux problème, en C++ il est rare d'avoir réellement besoin de le faire: les smart pointers et la RAII sont là pour ça. En plus, contrairement à des langages utilisant un GC, c'est bien plus simple de savoir quand un objet va être libéré, et donc quand il finira par libérer les ressources dont il à besoin: accès fichier, connexion à une base de données et connexion à un port sont les premières choses qui me viennent à l'esprit, et je ne connaît pas des masses de programmes qui ne manipulent rien de tout ça.
Les garbages collectors devraient commencer par se collecter eux-mêmes franchement.
Pour le C++, je peux aussi citer les templates qui sont extrêmement puissants. La dernière fois que j'ai eu à toucher du Java ou du C#, il n'était pas possible de faire de la spécialisation partielle, entres autres (je parle d'avant 2011). Pourtant, ça simplifie la vie des devs.
L'un des problèmes par contre du C++, c'est que dès lors que l'on doit exposer des classes et des méthodes l'ABI n'est plus garantie, donc on s'expose à des emmerdes si on à pas le même compilo dans la même version (du coup la méthode habituelle est d'utiliser le sous-ensemble C: des structs qui n'intègrent aucune méthode qui sont gérées par des fonctions. Du C quoi.).
Donc, le C à bel et bien un avantage sur certains langages de plus niveau.
Ce même avantage reviens quand on doit faire interagir des applications écrites dans des langages différents: le Java, le C++, le C#, et probablement d'autres plus obscurs savent tous charger des bibliothèques codées en C.
Je vais continuer sur python (histoire de me faire encore plus moinsser), et dire que je trouve néfaste le fait qu'un langage soit si dépendant de sa version. Sur la machine de laquelle j'écris, j'ai 2 versions de python. Par contre, une seule version de libc. Et manifestement, j'ai pas loin d'une centaine de Mo de dépendance pythonique. Oui, je sais, l'espace mémoire c'est pas cher, mais moi, je me dit que 100Mo * 9, c'est déjà près d'un Go. Pourquoi par 9? Parce qu'il y à 9 PC de bureau à mon taf. 1 Go, c'est vrai, ce n'est rien... mais je suis encore à l'échelle d'une petite entreprise.
Dans le cas de perl, c'est moins pire, seulement 50Mo, mais il faut dire que perl semble beaucoup moins dépendant de la version du langage. Moins utilisé aussi. On peut supposer que ce serait dans les 100Mo aussi s'il y avait 2 versions...
Si l'ensemble des gens de ma boîte tournaient sur Debian, configuré pour être minimaliste (oui, parce que les 150Mo, c'est sur une config que j'essaie de garder minimaliste, je pense que si j'avais un DE monolithique type KDE ou gnome, ce serait très probablement plus gros...) on parlerait alors de 1.5Go, à la louche.
À l'heure ou l'on parle d'économie d'énergie, c'est tout de même dommage, non? Parce que les libs et interpréteurs, il faut les charger en RAM, pour que ça serve. Et quand on charge un programme interprété, il faut stocker la forme binaire optimisée, en RAM également. Hors, la RAM, ça consomme de l'énergie.
J'ai vu une étude qui montrait que le coût en énergie des machine est de moins en moins négligeable face à leur coût d'achat. Certes, c'est dû au matos de plus en plus performant, mais pourquoi as-t-on besoin de matos de plus en plus performant?
Alors, ok, je te rejoins sur le fait que 90% des applications incluant une interface graphique n'ont aucun intérêt particulier à être codées en C. Par contre, je ne vois pas ce qui leur interdirait d'être écrites en C.
Quant à l'argument "oui mais les débutants savent pas faire proprement".
Désolé, cet argument est juste l'un des pires qui existe: si on commence à jauger les langages à l'aune des cochonneries que font les débutants, alors je doute qu'il existe un seul langage correct: je défie quiconque de me prouver que pour un langage donné il est impossible de faire du code de plus de 1000 lignes qui soit crade (je dirait même que moins un langage est typé, plus il est facile d'écrire de la merde, le code php que j'ai devant les yeux au taf le montre bien).