35 votes

La connaissance du C peut-elle réellement nuire au code que vous écrivez dans des langages de plus haut niveau ?

La question semble réglée, voire battue en brèche. Les gens intelligents ont dit les choses intelligentes sur le sujet. Pour être un très bon programmeur, vous devez savoir que C .

Ou le faites-vous ?

J'ai été éclairé deux fois cette semaine. Le premier m'a fait réaliser que mes hypothèses ne vont pas plus loin que les connaissances qui les sous-tendent, et étant donné la complexité des logiciels qui tournent sur ma machine, ces connaissances sont presque inexistantes. Mais ce qui m'a vraiment fait comprendre ce commentaire de Slashdot :

Le résultat final est que je remarque les nombreuses façons naïves dont les programmeurs C traditionnels "bare metal" supposent que les langages de plus haut niveau sont mis en œuvre. Ils prennent de mauvaises décisions d'"optimisation" dans les projets qu'ils influencent, car ils n'ont aucune idée du fonctionnement d'un compilateur ou de la différence entre un bon système d'exécution et le modèle naïf de macro-assembleur qu'ils comprennent.

Puis ça m'a frappé : C est juste une abstraction de plus comme tous les autres. Même le CPU lui-même n'est qu'une abstraction ! Je ne l'ai juste jamais vu se briser, parce que je n'ai pas les outils pour le mesurer.

Je suis confus. Mon esprit a-t-il été mutilé au-delà de toute récupération, comme Dijkstra l'a dit à propos de BASIC ? Est-ce que je vis dans un état constant d'optimisation prématurée ? Y a-t-il de l'espoir pour moi, maintenant que j'ai réalisé que je ne connais rien à rien ? Y a-t-il quelque chose à savoir, même ? Et pourquoi est-ce si fascinant que tout ce que j'ai écrit au cours des cinq dernières années ait pu être fondamentalement faux ?

En résumé, est-il utile d'en savoir plus que ce que la documentation de l'API me dit ?

EDIT : Made CW. Bien sûr, cela signifie aussi que vous devez maintenant poster des exemples de l'interpréteur/exécution optimisant mieux que nous :)

38voto

Jerry Coffin Points 237758

Ni la connaissance de C ni celle des détails de mise en œuvre de niveau inférieur ne vous font du tort - en soi. Ce qui peut vous nuire et vous nuira, c'est si vous pensez et travaillez constamment en termes de détails de bas niveau, même lorsque c'est inapproprié.

Le vieux dicton disait que "les vrais programmeurs peuvent écrire en FORTRAN en cualquier langage". Si vous faites la même chose en utilisant C, ce n'est pas une amélioration. Si vous écrivez Lisp, écrivez Lisp. Si vous écrivez Python, écrivez Python. Ce qui est approprié et raisonnable pour C ne l'est pas pour l'un ou l'autre de ces langages (ni pour aucun des nombreux autres).

Un grand programmeur doit être capable de penser à de nombreux niveaux d'abstraction différents et (surtout) de reconnaître et d'appliquer le niveau d'abstraction qui convient à la tâche à accomplir.

La connaissance du niveau d'abstraction du C ne fait pas de mal. L'ignorance des alternatives le peut (et le fera).

20voto

Arkaitz Jimenez Points 10651

La connaissance ne fait pas de mal. Jamais. Ceux qui ont écrit du mauvais code dans un langage de plus haut niveau, c'est parce qu'ils n'ont pas maîtrisé correctement le langage de plus haut niveau, de mauvais développeurs.

12voto

RHSeeger Points 9217

Pour un mauvais développeur, tout type de connaissance peut être dangereux.

Pour un bon développeur, tout type de connaissance est un atout.

7voto

L'utilisation des langues - naturelles (parlées) ou artificielles (programmation) - exige que l'esprit s'adapte d'une certaine manière. Chaque langage possède sa propre grammaire, son propre vocabulaire (API), etc. Si vous êtes principalement un programmeur Java et que vous passez à Ruby, vous allez au moins suivre les schémas de pensée d'un programmeur Java, si ce n'est écrire ce qui est fondamentalement du code Java en Ruby. Il faut un peu d'effort et de pratique pour commencer à se sentir à l'aise dans le nouvel environnement (grammaire Ruby, API Ruby) et commencer à écrire Ruby code.

Le processus est donc parfaitement normal et tout effet négatif des modèles précédents est de très courte durée. Plus important encore, chaque langue que vous apprenez élargit vos horizons et facilite l'apprentissage de la suivante. Profitez du voyage :]

6voto

Secure Points 2838

La programmation ne concerne pas les langages de programmation. Il s'agit de résoudre des problèmes. Le site outils utilisé pour résoudre les problèmes se trouve être les langages de programmation. On n'écrit pas du code pour écrire du code, on écrit du code pour l'exécuter et résoudre le problème.

Mieux vous connaissez vos outils, mieux et plus vite vous pourrez résoudre les problèmes. Alors que vous aurez de sérieux problèmes si vous essayez physiquement d'enfoncer une vis dans du bois à l'aide d'un marteau, les logiciels ont une propriété intéressante : Il existe un milliard de solutions différentes à un problème donné.

Il est donc parfaitement possible d'écrire un marteau qui frappe une vis dans un angle tel que la vis demandera au bois de faire un trou en lui-même pour que la vis s'y insère. Vous pouvez ensuite le cacher derrière un bouton, l'utilisateur n'a même pas besoin de savoir ce qu'est réellement un marteau.

Bien que ce ne soit pas la solution la plus efficace, elle reste une solution valable et fonctionnelle. Lorsque vous vous serez familiarisé avec l'outil que vous avez utilisé, vous découvrirez enfin comment écrire un tournevis lorsque l'API n'en fournit pas.

Plus vous connaissez d'outils et plus vous savez comment résoudre un problème, plus vous avez de choix et meilleures sont vos décisions quant à la solution à utiliser. Choisissez le bon outil pour le travail. Mais comment le pourriez-vous si vous ne connaissez pas les outils et les solutions possibles ?

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X