Codeurs gérés vs codeurs natifs

Je suis codeur et j'ai de l'expérience avec du code natif et géré. J'ai commencé avec Pascal et C, puis je suis passé en C ++ et finalement en C #.

Au cours de la dernière année, j'ai codé presque exclusivement en C # et j'ai perdu beaucoup de ce qui se produisait naturellement lorsque j'étais codeur C ++.

Il y a quelques semaines, lorsque je me suis assis pour écrire du code C ++ natif, je me suis retrouvé à tâtonner pendant que je reprenais lentement connaissance de la complexité, des bizarreries et des particularités de tout cela. Je suis presque gêné de dire que j'avais complètement oublié que le passage d'un tableau alloué dynamiquement à une fonction sans également transmettre sa taille signifierait que la fonction de réception n'aurait aucun moyen de connaître la longueur du tableau.

Il existe d'innombrables articles et documents qui comparent et contrastent le code géré par rapport au code non géré. Nous savons tous que le code natif, s'il est bien optimisé, peut fonctionner beaucoup plus rapidement et plus léger que le code géré. D'autre part, le code managé a des récupérateurs de place et une optimisation spécifique au processeur et au système d'exploitation au moment de l'exécution, ce qui peut donner au code natif une course pour son argent.

D'un point de vue purement technique, il n'y a pas de vainqueur clair.

Il ne fait aucun doute que le code managé est des ordres de grandeur plus simples à coder et à comprendre. Regardez simplement la différence dans le nombre de lignes nécessaires pour construire une interface graphique simple dans Win32 C ++ vs C #.

À l'époque de mon codage natif, j'ai principalement écrit des simulations mathématiques fonctionnant sur des superordinateurs. Ils avaient des CLI laides et étaient principalement axés sur des algorithmes. Aujourd'hui, j'écris en C # et je produis de belles applications GUI, mais je serais perdu si je devais faire quelque chose d'un calibre similaire sur une langue native. Même avec un framework tel que QT, il faudrait encore deux fois plus de temps pour produire quelque chose en C ++ / QT qu'en C #.

Chaque fois que je vois quelqu'un qui a écrit une application graphique à grande échelle et complète en C / C ++, je ne peux pas m'empêcher de ressentir un sentiment de crainte et un soupçon de jalousie.

Je suis curieux de voir comment d'autres codeurs expérimentés voient les langages gérés et non gérés. Voyez-vous le code managé comme amateur-ish ? Pensez-vous que les codeurs natifs sont plus hardcore ?

Mon travail de jour est actuellement en C ++, mais j'ai programmé en plusieurs langues assez longtemps pour que je remarque à peine une différence. Voici mes observations:

• Beaucoup de prétendues inefficacités avec d'autres langages sont fréquemment réimplémentées par les programmeurs C ++ comme meilleures pratiques. Nous ajoutons suffisamment de vérifications nulles, de vérification des limites de tableau, de vérification de type, de validation d'entrée, etc. pour annuler en grande partie tout avantage de vitesse d'exécution gagné par le langage qui ne fait pas automatiquement ces choses, du moins pour le code qui ne demande pas beaucoup de traitement de données.
• Ce passe-partout supplémentaire devient une habitude enracinée après un certain temps, de sorte qu'il ne ressemble pas vraiment à un travail supplémentaire et qu'il dépasse comme un pouce endolori lorsqu'il manque.
• Lorsque je programme dans un langage "managé", je pense toujours à l'allocation de mémoire, afin de ne pas créer de fuite mémoire. Je ne mets peut-être pas un explicite delete, mais je suis toujours conscient dans mon esprit du point auquel le garbage collector considère qu'il peut être supprimé. J'ai eu plus de difficulté à résoudre les problèmes de mémoire faible à partir de Java que jamais en C ++, probablement parce qu'en C ++, ils sont beaucoup plus difficiles à ignorer pendant très longtemps.
• Il en va de même pour la frappe dynamique. Je dois encore garder une trace dans ma tête de savoir si un paramètre de fonction est un tableau, ou un int, ou une chaîne. En fait, cela nécessite plus d'effort mental, car le type n'est pas clairement indiqué pour moi.
• Le style C ++ moderne est très différent de l'ère pré-C #. Plutôt que de changer le langage, les gens ont "découvert" comment utiliser les fonctionnalités C ++ existantes de manière unique pour éviter une grande partie de la gestion de la mémoire subalterne du passé. Les modèles de conception qui libèrent automatiquement la mémoire sont désormais très courants.
• Pour autant que je sache, même s'il est possible de créer des applications GUI en n'écrivant que du code, les concepteurs graphiques comme le concepteur QT sont la méthode largement préférée, le code étant principalement utilisé uniquement pour les gestionnaires d'événements ou la personnalisation d'exécution.
• Les langues que vous n'avez pas beaucoup utilisées depuis longtemps sont toujours un peu maladroites, même si vous vous souvenez surtout de la syntaxe. Si je n'écris pas python pendant un an, il y a beaucoup d'idiosyncrasies que j'ai oubliées, et cela semble plus gênant que C ++ pendant un certain temps, même si objectivement la plupart des gens considèrent python comme le langage "le plus facile".

Avec la combinaison de tous ces facteurs, mon modèle mental reste assez cohérent entre le moment où je programme en C ++ et d'autres langages, et les différences semblent principalement syntaxiques. Certes, cela est en grande partie le résultat de la formation, des habitudes, des normes de codage et des modèles de conception modernes plutôt que des caractéristiques intrinsèques au langage C ++ lui-même, mais la comparaison est toujours valable.

Je suppose que ce que j'essaie de dire, c'est que d'après mon expérience, la formation du programmeur fait beaucoup plus de différence que le langage qu'il utilise.

Voyez-vous le code managé comme amateur-ish? Pensez-vous que les codeurs natifs sont plus hardcore?

Non.

Je vois les différences entre un ingénieur et un programmeur. L' ingénieur hardcore choisira toujours la pile de langue / technologie appropriée pour effectuer le travail en un minimum de temps avec un niveau d'exécution acceptable.

Avec la puissance du processeur ces jours-ci, la fréquence d' avoir réellement besoin de tirer le meilleur parti d'une machine en utilisant un niveau inférieur, les langues natives deviennent de moins en moins. Il n'y a généralement pas vraiment de rentabilité pour cela. La productivité l' emportera toujours sur une différence de quelques millisecondes dans le temps d'exécution.

Malheureusement, Microsoft nous a amenés à confondre le "code managé" avec les bibliothèques de classes C # /. Net.

Il y a deux choses distinctes et presque indépendantes en jeu ici.

1. Bibliothèques .Net sympas.

2. Code managé.

C # offre les deux dans un package bien rangé, pris en charge et facile à utiliser pour un prix.

C ++ a de nombreuses bibliothèques sympas qui font presque tout ce que fait .Net. Plutôt que de blâmer le code "C ++ natif" comme ayant plus de "complexités, bizarreries et idiosyncrasies" que le code C # /. Net, vous pourriez chercher de meilleures bibliothèques C ++.

De meilleures bibliothèques vous permettent également d'écrire du bon code C ++.

Chaque fois que je vois quelqu'un qui a écrit une application graphique à grande échelle et complète en C / C ++, je ne peux pas m'empêcher de ressentir un sentiment d'admiration et un soupçon de jalousie

Mauvaise politique. Au lieu de cela, vous devriez découvrir quelles bibliothèques de définitions de classe ils ont utilisées. Vous aussi, vous pourriez utiliser ces bibliothèques.

Tout tourne autour des outils. Sans outils, nous ne sommes que des animaux en pantalon.

"Native C ++" ne signifie pas que vous devez jeter tous vos outils. Cela signifie que vous devez trouver de bons outils. Microsoft ne vous aide plus, vous devez donc passer du temps à trouver la bonne combinaison d'outils.

Le problème ici n'est pas la programmation hardcore ou quelque chose comme ça, c'est le contrôle. Le fait est que C # offre une productivité à un coût de contrôle. Si vous écrivez un programme qui nécessite une grande quantité de contrôle (cette mémoire est désallouée exactement maintenant), alors vous n'avez pas d'autre choix que d'utiliser C ++. Si vous devez le faire rapidement, vous devrez peut-être utiliser C #. Le problème est que les bibliothèques de support pour C # sont bien meilleures et plus récentes que celles fournies pour C ++. Par exemple, le MFC est très, très ancien et ses pratiques sont connues pour être terribles, il a été principalement écrit bien avant la normalisation. Si Microsoft s'efforce de fournir de nouvelles bibliothèques C ++, par exemple, consultez le nouveau PPL dans Visual Studio 2010, puis assez étrangement, cette tâche devient facile en C ++. Et je pense qu'ils migrent de cette façon,

D'autre part, le code managé a des récupérateurs de place et une optimisation spécifique au processeur et au système d'exploitation au moment de l'exécution, ce qui peut donner au code natif une course pour son argent.

J'ai entendu de nombreux partisans du langage géré dire cela, mais je n'ai pratiquement jamais vu que c'était vrai. Le fait est que les nouvelles instructions CPU disponibles dans les CPU plus récents n'offrent tout simplement pas autant d'avantages à moins que vous ne fassiez des mathématiques très hardcore, auquel cas vous ne pouvez pas vous permettre de devoir le compiler ou l'interpréter lors de l'exécution -temps et vous pourriez simplement utiliser le compilateur C ++ d'Intel pour utiliser le dernier et le meilleur de SSE de toute façon. La portée des optimisations du compilateur C ++ est énorme par rapport à ce que le JIT peut faire, car le JIT doit s'exécuter en une fraction du temps pendant l'exécution du programme, tandis que les compilateurs C ++ sont assez légendaires pour prendre leur temps doux pour compiler.

La collecte des ordures n'est pas une sorte de grande chose magique ou quelque chose comme ça - c'est un choix d'algorithme. Convient-il à toutes les situations? Pas de loin - regardez le désordre IDisposable en C # et comment Java n'a même pas pris la peine d'essayer avec ce problème, alors que les destructeurs de C ++ fermeront vos fichiers et libéreront votre mémoire et fermer vos sockets, etc. etc. GC est idéal pour certains programmes , et pas pour certains autres.

À mon avis, le C / C ++ natif, comparé au C #, ressemble à l'assembleur du C / C ++ lui-même. Une autre couche d'abstraction complexe (pas vraiment vraie, mais disons-le), comme toujours, vous donne un développement plus facile, mais une certaine réduction de la vitesse et une utilisation excessive de la mémoire. Donc, comme je le vois, c'est juste divisé en différentes catégories, créant ainsi de nouveaux sous-types de programmeurs.

Btw pour son niveau d'abstraction C # est incroyablement rapide, Microsoft a fait un excellent travail.

Il y a des programmeurs amateurs, pas des langues amateurs. Les langues qu'ils ont toutes (enfin, la plupart au moins) leur but.

Je travaille actuellement sur un moteur de calcul d'assurance utilisé pour tester le système de production. Le système de production a été fait en C, notre moteur est fait en Java et depuis plus longtemps nous surpassons le moteur C, étant en même temps beaucoup plus productif. Non pas parce que Java en soi est plus rapide que C, il est juste assez rapide et nos algorithmes sont meilleurs, nous les avons mis en œuvre plus facilement, nous pourrions tester plus rapidement et mieux et refactoriser notre code.

J'ai également écrit du code de test pour comparer les résultats des calculs avec le contenu de la base de données de production: pas en C, pas en Java mais en Ruby. Encore une fois, il est assez rapide et nécessite beaucoup moins de code, il est donc plus facile à implémenter, à tester et à développer.

Et je ne me sens pas amateur, peu importe la langue que j'utilise, je ne le ressens que si je crée un bug stupide qui n'aurait pas dû se produire.

L'année dernière, l'entreprise dans laquelle je travaillais était en train de procéder à une ingénierie inverse d'un code CRC de communication par force brute (nous l'avons finalement obtenu). 3 développeurs ont chacun leur propre version, Borland C, C # .Net 2008, VB6. Le VB6 était évidemment lent, Borland C était rapide mais le C # .net l'a juste fouetté de 12 fois la vitesse. Ce n'était pas du tout ce que nous attendions.

Cela dépend d'un mélange de choses, mais fondamentalement, toutes choses étant égales par ailleurs, oui, le code natif est plus "hardcore" que le code managé.

Je suppose que c'est généralement une mauvaise chose, cependant, pour une application commerciale normale, car cela signifie que le développeur moyen doit mettre plus d'énergie mentale dans les aspects non commerciaux de son code.

Mon programme est ce qui pourrait être décrit comme C ++ comme Java. À mon avis, vous pouvez obtenir la même programmation de bas niveau en Java, mais c'est beaucoup plus difficile que la programmation de bas niveau en C ++. Cependant, vous avez généralement besoin de cette programmation de bas niveau dans une petite fraction de votre code et là où elle n'est pas requise, un langage géré est plus productif.

Les développeurs natifs ont généralement la réputation d'être plus hardcore parce qu'ils se sentent plus hardcore et agissent de cette façon. Les développeurs natifs sont formés dans un système qui ne tolère aucune erreur car ils entraînent inévitablement des plantages ou des fuites de mémoire illimitées. En particulier, .NET permet des hacks paresseux comme mettre try / catch autour de tout, évitant au développeur de penser qu'il doit comprendre le problème de base (" parfois, il lève juste InvalidOperationException. Je ne peux pas l'expliquer, je vais juste attraper tout. le code est critique! "). Ce n'est pas du tout noir et blanc, mais mes observations ont grandi dans le monde non managé et travaillent maintenant à plein temps en code managé.

De plus, les développeurs managés ont également tendance à avoir accès à des BCL beaucoup plus propres et mieux organisés. Cela les encourage souvent à explorer ce qui se passe réellement sous les couvertures. Certes, la même chose peut être dite pour, disons, STL ou Boost, mais la bibliothèque de classes .NET est souvent assez bonne pour nous rendre parfois paresseux intellectuellement.

Cela dit, la rédaction d'un bon programme géré livrable demande beaucoup de travail. Cela signifie faire du profilage de la mémoire et du processeur, des tests unitaires et une analyse de code de la même manière que les développeurs non gérés le font. Les développeurs non gérés ont tendance à comprendre cela, et les développeurs gérés ont tendance à inclure plus de ceux qui ne le font pas.

Encore une fois, pas en noir et blanc. Il existe de nombreux développeurs non managés intellectuellement paresseux et des développeurs managés hardcore. Ni l'un ni l'autre n'est par définition plus élite que l'autre.

Voyez-vous le code managé comme amateur-ish? Pensez-vous que les codeurs natifs sont plus hardcore?

Il y a un fossé entre les deux mondes, et je ne vois pas pourquoi: les systèmes gérés sont quelque part écrits en code natif (comme final, tout fonctionne "en assembleur"). Ce que je veux voir (encore dans ma vie) est un système de construction d'application, où toutes les sous-tâches de l'application seront écrites dans le bon type de langage.

Le code natif est devenu plus facile depuis la sortie de Go . Je trouve plus facile à lire et à écrire que Java et C #. Bien que la programmation GUI avec Go, pour l'instant, ne soit pas très agréable (j'ai jeté un coup d'œil aux options).
Essayez de ne pas le juger pour son manque de grande communauté et de variété de bibliothèques par rapport à C # (par exemple), car il est toujours considéré comme nouveau.