Pourquoi les programmeurs systèmes sont-ils trop attachés au C ?

**Wizard50** · 30/05/2012, 17h35

aucun langage parmi ceux proposés (BitC,Haskell,ATS,...) n'est plus performant que le C et tous sont plus difficiles à apprendre.

Permettez moi de douter très largement de cette assertion : je suis d'accord sur le premier point, aucun des langages proposée n'est plus performant que le C. Mais de là a dire que tous sont plus difficile à apprendre que le C, c'est vraiment une question de point de vue. Je reprend encore l'exemple de l'Ocaml mais des étudiants de niveau Licence apprennent bien plus facilement l'Ocaml que le C et la raison est simple : leur esprit est généralement "neuf" et vierge de préjugé, ils n'ont aucun appriori sur les langages et sont aptes à recevoir tous concept de programmation, Ocaml comme C. Une fois passé le chapitre sur la récursivité qui est omniprésente en Ocaml, tout va bien alors que le chapitre sur les pointeurs en C peut devenir un problème éternel chez certains étudiants. Pour une personne ayant des années d'expériences en C, l'apprentissage d'un langage fonctionnel est forcément plus lent : perdre certaines habitudes et en adopter de nouvelles, notamment des concepts qui changent tout, n'est pas chose aisée, surtout si on y va a reculons.

Invité · 27/05/2012, 20h05

Et si les concepts d'abstraction des langages modernes étaient carrément contre-productifs ?

J'adore l'objet pour un tas de raisons simples comme la prise en charge de l'allocation et la libération de mémoire. J'adore que le type string me permette les concaténations, les insertions, les tableaux dynamiques de strings dynamiques. Tout ça est génial mais c'est lent et impossible à optimiser

Pensez donc , en C je sauve l'image de toutes mes variables globales avec un memcpy() ; Comment faire en C++ ? En C#, il faut parcourir chaque élément du segment data dans une boucle pour aller chercher les variables une par une (Marshal).

En C pas de boucle, pas de piège , juste un pointeur et une longueur ..

Vous pensez vraiment que ça va changer ? Moi je doute .. La modernité , c'est justement ce que je veux éviter quand je compile de l'ARM 7 !

Un autre argument de l'objet selon moi est le partage du travail en équipe , le C n'aide pas dans ce cas mais on finit par se partager les tâches de façon informelle alors qu'en objet il y a moins de chances que les devs se marchent dessus si vous voyez ce que je veux dire...

**Freem** · 29/05/2012, 11h38

Envoyé par unBonGars

Et si les concepts d'abstraction des langages modernes étaient carrément contre-productifs ?

J'adore l'objet pour un tas de raisons simples comme la prise en charge de l'allocation et la libération de mémoire. J'adore que le type string me permette les concaténations, les insertions, les tableaux dynamiques de strings dynamiques. Tout ça est génial mais c'est lent et impossible à optimiser

Pensez donc , en C je sauve l'image de toutes mes variables globales avec un memcpy() ; Comment faire en C++ ? En C#, il faut parcourir chaque élément du segment data dans une boucle pour aller chercher les variables une par une (Marshal).

En C pas de boucle, pas de piège , juste un pointeur et une longueur ..

Vous pensez vraiment que ça va changer ? Moi je doute .. La modernité , c'est justement ce que je veux éviter quand je compile de l'ARM 7 !

Un autre argument de l'objet selon moi est le partage du travail en équipe , le C n'aide pas dans ce cas mais on finit par se partager les tâches de façon informelle alors qu'en objet il y a moins de chances que les devs se marchent dessus si vous voyez ce que je veux dire...

Bon... Déjà, en C, le travail en équipe est autant possible qu'en C++.
Après tout, le C est un langage modulaire, non?

Quand on me parle de l'objet pour travailler en équipe, ça me fait doucement sourire.
Découper une tâche implique de l'avoir au préalable bien définie.
L'orienté objet est une façon de découper comme les autres, que je qualifierais simplement de "descendant de la programmation modulaire". Le truc, c'est qu'en POO, chaque classe est un module. Ou du moins devrais parce que j'ai pu voir un ou deux codes sources qui ne respectaient pas ça. Résultat, dur à maintenir. Mais ça ne viens pas du paradigme, en C ça aurait été le même bordel. Et en brainfuck aussi

Ensuite, il est, comme il a déjà été dit, possible de faire de la programmation orientée objet en C, c'est juste que l'on a pas un compilateur aussi casse-pied sur les cast et que les accès aux données/fonctions ne peuvent être régulés. Et, naturellement, la syntaxe n'est pas vraiment adaptée.

Quant à ton histoire d'initialiser séparément de l'allocation, j'ai plusieurs solutions pour toi, et tu peux déjà en appliquer une (la première):
_ garder la même procédure qu'en C. Malloc & co marchent très bien en C++ malgré qu'il existe des alternatives tout aussi souples. Oui, marchent très bien, y compris avec des classes, c'est juste qu'après il faut appeler le constructeur à la main.
_ surcharger LES opérateurS new et new[]. Evite d'avoir une séquence un peu bizarroïde d'appels à malloc puis au constructeur. C'est à dire, lui dire de ne pas appeler le constructeur, je pense. Suis pas tout à fait sûr de comment on fait ni de ses effets... Je sais qu'on peut le faire car je connaît les capacités de C++, mais je n'ai pas encore eu d'intérêt à utiliser ce type de techniques.
_ utiliser les vector pour remplacer les tableaux. Enfin, si on a un truc dont la taille varie au cours du temps, ou n'est pas connue à la compilation naturellement (sinon, on peut simplement utiliser des tableaux. Ou des tableaux de pointeurs. Et il me semble même qu'il soit possible de faire des tableaux de références bien que je n'en sois pas sûr... J'ai encore de vieux réflexes pointeurs). Le memcpy reste utilisable sur un vector d'ailleurs, mais je te l'accorde, il doit y avoir une petite quinzaine d'octets supplémentaires. Mieux vaut utiliser l'opérateur d'affectation ou le constructeur par copie. Voir mieux, en terme de perfs si on veut juste bouger la bête, la fonction std::move.

Honnêtement, je suis plutôt d'accord avec stardeath par rapport aux arguments que l'on entend en défaveur du C++.
Au fait, vous connaissez tous, j'imagine, la philosophie gardée à l'esprit lors de l'ajout de choses au langage C++ : "you don't pay for what you don't need.
Ca veut simplement dire que si on utilise pas une fonctionnalité du langage, on ne paye pas les conséquences. C'est justement fait pour garder la vitesse du C. Le C++ utilisé en "mode C" devrait donc théoriquement avoir les mêmes performances. (J'ai précisé théoriquement uniquement parce que je n'ai pas vérifié par moi-même)
C'est pour ça que, contrairement à d'autres langages, il faut déclarer une fonction virtuelle pour qu'elle le soit, pour éviter de coller des vtable où il n'y en a pas besoin. Idem pour la RTTI, qui existe bel et bien, mais qui nécessite des utilisations explicite.
Le seul point, pour le moment, que j'aie vu et que je trouve assez vrai, c'est le fait qu'il existe du "code caché" ou plutôt mal contrôlable (du moins, c'est faisable, juste pas évident d'y penser toujours) a cause des héritages. Du coup il faut savoir si une fonction est virtuelle ou pas, surchargée ou pas... Si on a pas la documentation de ce que l'on utilise (ou qu'elle n'est pas exhaustive), ça peut devenir pénible (j'en ai un souvenir assez récent).

C++ est multi paradigme, il n'est pas limité à l'impératif classique comme le C, ni à la POO comme JAVA. Il peut faire soit l'un, soit l'autre, soit les deux à la fois. (sans parler de la programmation générique)

Pour en revenir au langage Ctruc, une chose parmi les avantages du C (à mon humble avis) n'a pas été dite:
_ que le langage soit compilé
_ pas de garbage collector, le dev est quand même censé savoir ce qu'il fait mieux que la machine (comment ça, j'aime pas les GC?)

Parce que bon... la mode actuelle, c'est quand même ces satanées VM, systématiquement dotées de GC. Quel langage récent n'en a pas d'ailleurs?

**Bktero** · 29/05/2012, 11h47

Envoyé par Lucie-58D1FCBD

Sinon, pourquoi ressortir un article datant de 2006, sur un concept abandonné en 2010, et qui possède des erreurs de conception ?

"Finally, in March 2012 he announced that he had permanently ceased work on BitC, saying that the language had fundamental design flaws and would not work in its current form." (source Wikipedia)

Tout est dit

Envoyé par OleoShark

Je vais répondre par une autre question : pourquoi remplacer la langue française par une autre langue ?

C'est pas faux.

J'ai du mal à comprendre le fondement du débat : "Comment attirer les programmeurs systèmes vers un langage moderne ?". Mais.... ont-ils besoin d'un langage moderne ? Le débat est parti du principe que "oui, le C has been" et qu'il lui faut le remplacer. Le passif en C de toute l'informatique actuelle est énorme et, comme dit ci-avant, le C s'impose comme le langage naturel pour communiquer avec tout cela (l'exemple des API des systèmes était bon).

Mon avis est que le C répond parfaitement aux besoins des gens qui l'utilisent. Il est fiable et stable. Si ces gens en avaient marre du C, il y aurait déjà eu tout plein de propositions pour remplacer ce langage et probablement qu'une de ces solutions aurait déjà réussi à s'imposer.

Quand à savoir si on peut l'améliorer et ajouter des nouvelles fonctionnalités, c'est possible en les ajoutant à la prochaine norme, non ?

**istace.emmanuel** · 26/05/2012, 19h04

Pourrait-on aussi se poser la question de savoir si rajouter de nouveaux concept à la manière dont le sysdev est fait actuellement aurait un intérêt ? Est-ce que l'apport de concepts objet apporte un bénéfice pour le dev d'un ordonnanceur ?

En plus il faut voir ce que l'on appel sysdev au final. Si on parle d'un gestionnaire de filesystem ou d'un switcher audio, d'une architecture monolithique ou µkernel, les besoins sont différents et donc les langages choisis peuvent aussi différer.

Pourquoi ne pas plutôt rester sur du "Core" en C et ensuite utiliser des langages plus haut niveau pour le reste ?

Et puis, ne pas oublier qu'on a un historique de C assez lourd, avec des skills actuel de sysdev en C principalement. Changer de langage signifierais un gros investissement en temps et en argent pour former ainsi qu'une période de stagnation au niveau des avancées sur le systèmes. (on reste avec 24h sur une journée, si on passe 8h à apprendre un nouveau langage, on ne le passe pas a faire évoluer le produit)

Bref, est-ce que le jeux en vaut la chandelle ? Ça marche très bien en C le sysdev il me semble, pourquoi vouloir le changer ?

Invité · 27/05/2012, 01h34

Pour moi, le C (et dans une moindre mesure) le C++ sont des langages :

- répandus : ils existent et sont utilisés depuis des années.
- éprouvés : ils ont démontrés leurs capacités à être utilisés dans de nombreuses applications.
- pérennes : pas ou peu de changements dans le langage en lui-même, au contraire d'autres langages qui évoluent plus vite.

Il n'y a pas que des nouveaux projets en informatique. Il y a tout l'existant qui est en grande partie codé en C. C'est un peu comme pour certaines grosses applications de gestion qui sont toujours en Cobol et où on demande sans cesse des programmeurs dans ce langage pour les maintenir (domaine bancaire par exemple, il y a des programmes écrits il y a 30 ans qui fonctionnent encore aujourd'hui et n'ont pas donné une erreur d'un centime...).

Le C est et restera inévitable un bon bout de temps car trop de choses dépendent encore de ce langage.

**tiloopz** · 27/05/2012, 02h38

Bonjour,

La langage C est très proche de l'électronique sur lequel il fonctionne. La notion de pointeurs est facilement assimilable à la notion de bus d'adresses et la notion de variables à la notion de bus de données. Pour des raisons de performances, j'ai déjà optimisé l'assembleur d'un code C, je vous déconseille d'essayer de faire pareil avec du C#, enfin après que le MSIL se soit compilé sur votre plateforme bien sur

Les types de bases répondent aux besoins de variables de taille différentes. Des types plus complexes sont superflus et diminuent les performances et prennent plus de place. On peux toujours créer des structures ou classes pour cela.

Pour revenir sur la notion de soi disante sécurité, il faut savoir que soit on fait de la sécurité, soit on fait de la performance. Et comme dirait Benjamin Franklin : "Ceux qui sont prêts à sacrifier une liberté essentielle pour acheter une sûreté passagère, ne méritent ni l’une ni l’autre." Par exemple, pourquoi interdire les pointeurs si leur incrémentation permet de réaliser des FFT plus rapide. Au programmeur de savoir ce qu'il fait. Sinon, c'est comme manger sans couteau par crainte du risque de se couper lol.

Pourquoi un autre langage, quel apport ? A mon avis, il faudrait que le support physique et les modes de fonctionnement changent pour éventuellement trouver un langage plus adapté.

Une large communauté, des librairies éprouvées, des millions de codes comme autant de preuves de son efficacité, sans conteste le langage C est le langage par excellence et ce n'est pas prêt de changer

**Lucie-58D1FCBD** · 27/05/2012, 13h47

Le titre ne sonne pas bien en français: "trop attachés" relève de l'affirmation, alors que titre est une question.
Sinon, pourquoi ressortir un article datant de 2006, sur un concept abandonné en 2010, et qui possède des erreurs de conception ?

"Finally, in March 2012 he announced that he had permanently ceased work on BitC, saying that the language had fundamental design flaws and would not work in its current form." (source Wikipedia)

Si on veut quelque chose qui a un goût de programmation fonctionnelle dans un descendant du C, on peut regarder les fonctions anonymes en C++11, Boost.Phoenix, ou les blocks en Objective-C (extension Apple).