Les ingénieurs logiciels ont-ils vraiment besoin de connaître les choses de bas niveau? [fermé]

Alors que des langages de programmation de haut niveau tels que C #, Java, etc. se développent, de nombreuses personnes affirment qu'elles seront une alternative aux langages tels que le langage d'assemblage et C / C ++, qui vous donne accès et contrôle au matériel informatique, car les programmeurs devraient se concentrer sur la création du programme et la résolution du problème, sans perdre de temps avec l'ordinateur pour le faire fonctionner. Au fur et à mesure que le matériel s'améliore, la différence de performances entre C / C ++ et Java ne sera pas significative, et les gros jeux pourraient être programmés dans un langage tel que Java.

C'est l'idée générale que je résume brièvement après avoir examiné ce sujet sur Internet. Pensez-vous que cela deviendra réel dans un avenir proche? Cela signifie-t-il que tout ce que nous apprenons sur les choses de bas niveau n'est plus pratique pour l'industrie du logiciel? Cela signifie-t-il que le langage d'assemblage et le C / C ++ ne deviendront pertinents que pour les ingénieurs électriciens, car ils seraient les seuls à avoir besoin de programmer leurs composants électriques?

---

Combien d'apprentissage est suffisant? Si nous apprenons trop de choses de bas niveau, nous finirions par devenir plus orientés en génie électrique ou si nous apprenons trop de mathématiques, nous pourrions apprendre à devenir des mathématiciens, pas des programmeurs. Je veux juste savoir si les matières mathématiques que j'ai apprises (j'ai suivi un cours de mathématiques qui couvre le matériel similaire à ce livre (ils ont utilisé différents manuels): les mathématiques discrètes et son application) sont en fait aussi utiles que notre ensemble de compétences en programmation. De nombreux exercices de mathématiques peuvent prendre la plupart d'entre nous des heures pour le faire, et si vous êtes sérieux avec cela, vous aurez moins de temps pour étudier la programmation. Dans notre forum gamedev, même les mathématiques et la physique n'ont qu'une section à comparer avec celles de programmation.

En ce moment, je viens de commencer à lire "L'art de la programmation informatique". Les mathématiques ne sont couvertes que dans environ le quart du livre, mais l'exercice est difficile pour nous, non-mathématiciens. Même ces mathématiques "élémentaires", l'avons-nous utilisé autant dans notre carrière? Certaines personnes me diraient probablement que lire le livre TACOP est une perte de temps et devrait probablement consacrer du temps à autre chose de plus pratique, même si le livre est entièrement consacré à la programmation (un peu plus académique comparé au livre expliquant des choses similaires). Mais je pense que l'auteur a mis beaucoup de temps et d'efforts pour le produire. Il peut même écrire l'ensemble complet de 5 livres, alors que nous - le public - n'avons que la mission de le lire. Pourquoi pas?

Question interessante. Je suis un programmeur C ++ de longue date qui travaille maintenant en C # (avec un peu de C ++ non géré pour un travail critique en termes de performances), et j'ai toujours dû ajouter le bit occasionnel de code assembleur, généralement pour des raisons de performances.

Quelques points pour préparer une réponse à la question:

• Pour votre comparaison, je suggère que la principale distinction entre les langages que vous mentionnez, C # et Java, de l'autre ensemble, Assembly, C / C ++, est que les premiers utilisent un runtime géré pour fournir la collecte des ordures. Il existe d'autres différences (par exemple, la portabilité binaire, la taille du framework et la portabilité), mais comme vous cherchez à comparer les différences de performances, c'est un (le?) Contributeur majeur.

• Assembly, C et C ++ sont loin d'être également "de bas niveau". Je pense que vous avez raison d'associer les langages Assembly et C aux développeurs de matériel / micrologiciel / pilote, mais C ++ est généralement utilisé à un niveau supérieur et est toujours très utilisé - bien que C # / Java le fasse clairement selon TIOBE indice.

• Dans le niveau C ++, j'ajouterais Objective-C, car il s'apparente plus à C ++ qu'à C # / Java. Enfin, je noterais qu'avec l'ajout de shared_ptr <> et d'autres fonctionnalités de gestion automatique des ressources, ces langages prennent en charge quelque chose de proche de la récupération de place.

OK - passons à votre question principale: les ingénieurs logiciels ont-ils vraiment besoin de connaître les choses de bas niveau?

Ma réponse: oui

Les raisons:

• Même lorsque vous utilisez C # / Java, vous rencontrerez probablement des entités de framework qui nécessitent une gestion explicite des ressources et / ou rencontrerez des problèmes de graphiques de mémoire "épinglés" sur toutes les applications non triviales. Vous devez comprendre comment ces systèmes fonctionnent pour éviter et déboguer efficacement ces problèmes.
• Les plates-formes mobiles ont des ressources plus limitées et, bien que certaines versions de Java et .NET soient prises en charge sur certains, la domination actuelle d'iOS et d'Objective-C suggère une longue vie renouvelée.
• Performances: chaque fois que vous atteignez un mur de performances, vous devrez probablement passer dans un bloc de code compilé en mode natif pour le contourner.
• Prise en charge héritée: chaque fois que vous devez interagir pour accéder à une fonctionnalité non (encore) exposée dans le code managé, vous devrez faire de même.

Bonne question - mais je ne vois pas de langues non gérées disparaître à court terme.

• Que quelqu'un n'ait légitimement pas connaissance et ne comprenne pas les fonctionnalités de niveau inférieur, tout en étant un développeur très productif et précieux, c'est déjà le cas.
• Que personne n'ait besoin d'apprendre ou de comprendre des fonctionnalités de niveau inférieur, que ce serait toujours une perte de temps, ce ne sera jamais le cas.

Comme dans toute discipline d'ingénierie, le produit final comporte de nombreuses étapes, toutes importantes, exigeant une expertise et précieuses. En génie logiciel en particulier, nous avons de nombreuses couches d'abstraction. Tout est nécessaire, et personne ne peut être un expert dans chacun d'eux.

Cela étant dit, nous avons besoin de plus de développeurs C # / Java / Ruby que de développeurs Assemby / C. Pour nous, les développeurs de "niveau supérieur", il est utile de mieux comprendre ce qui se passe "sous le capot" et cela fera de nous de meilleurs développeurs. Mais il en va de même pour beaucoup d'autres choses . En tant que développeur .NET, par exemple, il y a tellement de choses que je peux apprendre qui me rendront plus productif, que l'étude de notre langage intermédiaire (beaucoup moins C ++ / C / Assmebly), bien que très utile, doit souvent prendre du recul.

Vous pouvez gagner votre vie aujourd'hui en tant que programmeur sans connaître les trucs de bas niveau. Je pense que cela fait de vous un meilleur programmeur pour le savoir.

Le maintien d'un haut niveau de compétence avec le bas niveau, cependant, devient de moins en moins important. Je veux dire, je n'ai rien fait dans l'assemblage depuis 20 ans et j'aurais probablement besoin d'un sérieux recyclage avant de pouvoir y être à nouveau productif, mais les concepts généraux de la façon dont les choses fonctionnent à ce niveau font toujours partie de ma conscience et je trouve il est utile de temps en temps même lorsque vous travaillez dans des langues de niveau supérieur.

Je ne pense pas, les développeurs du noyau auront toujours besoin de choses de bas niveau. Cela ne fait pas de mal non plus de comprendre comment tout fonctionne, si vous comprenez fondamentalement ce que fait réellement le code que vous écrivez, vous apprendrez à écrire un meilleur code. Je pense que supprimer les éléments de bas niveau est une idée horrible car cette pensée abstraite est parfois utile, mais peut en fait être un obstacle si vous voulez que le problème soit résolu de la meilleure façon. Par exemple, il est important de comprendre que lorsque vous concaténez des chaînes, vous créez réellement de nouvelles chaînes, mais si vous ne comprenez pas comment les chaînes ont été implémentées, vous pouvez simplement concaténer et attendre les 5 minutes nécessaires à l'exécution de votre programme. Ceci est un excellent article sur des choses comme celle-ci: http://www.joelonsoftware.com/articles/fog0000000319.html

Cela dépend de ce sur quoi l'ingénieur logiciel travaille réellement. Il est possible d'avoir une carrière productive, heureuse et rentable sans jamais toucher à quoi que ce soit de bas niveau maintenant, mais ce ne sont pas tous les emplois de programmation. Pour qu'il y ait des systèmes d'exploitation et des compilateurs, il doit y avoir des ingénieurs travaillant sur les systèmes d'exploitation et les compilateurs, et ils devront connaître le C, C ++ et le langage d'assemblage de leur machine.

Les performances peuvent également être importantes. Mon ordinateur portable actuel est à peu près un million de fois plus puissant que mon premier ordinateur personnel, et l'exécution de logiciels peut encore prendre du temps. Je peux encore avoir du retard dans les jeux vidéo. Bien sûr, les jeux vidéo ont une meilleure apparence, car chacun des millions de pixels sur l'écran peut recevoir l'une des millions de couleurs (par opposition à mille positions de caractères en noir et blanc, certains des caractères étant utilisés pour les graphiques). ). Je doute que nous obtenions une autre augmentation de mille fois la puissance informatique dans un proche avenir, et si nous le faisons, je m'attends à ce qu'elle soit utilisée par des logiciels de plus en plus complexes.

Alors que la majeure partie des logiciels d'entreprise continuera à être écrite dans ce qui est le plus rapide à produire et à sortir, ce qui n'est généralement pas C, il y aura toujours beaucoup de place pour les experts C et C ++.

"Avec le matériel qui continue de s'améliorer, les performances entre C / C ++ et Java ne seront pas significatives, et le gros gibier pourrait être programmé dans un langage tel que Java."

Je ne pense pas que cette déclaration sera correcte de sitôt. Il y a toujours un hit dans le code managé à cause des vérifications effectuées en arrière-plan. Ce n'est pas non plus une question de matériel, car le matériel s'améliore, tout comme les applications qui devraient fonctionner sur eux. Un système écrit en code natif doit avoir une interface avec le code managé. Il y a un coup de performance qui se produit lors du basculement entre les deux.

Cependant, seul un pourcentage généralement faible des applications a réellement besoin de ce code optimisé. La plupart des applications métier conviennent parfaitement à tout code managé, .net, java, etc. Cependant, l'assemblage écrit à la main est beaucoup moins utilisé maintenant, les compilateurs d'optimisation C / C ++ étant si bons. Il y a eu récemment un OS écrit entièrement en assemblage, donc certains y ont encore du mal. C'est également très important dans le domaine de la sécurité.

Je dirais cependant que pour être un très bon développeur, il faut comprendre ce qui se passe à un bas niveau. Il aide à résoudre certains problèmes difficiles, en particulier lors de l'appel en code natif.

Je pense que la connaissance de certaines choses de bas niveau est très utile pour le débogage, comme par exemple avec la programmation intégrée, la plupart se fait avec C, mais lors du débogage, l'assemblage de ce contrôleur Micro particulier est extrêmement utile.

Lorsque les ordinateurs ont été inventés pour la première fois, seules quelques personnes savaient comment les utiliser. Maintenant, la plupart des maisons d'un pays riche ont au moins un ordinateur utilisable par la personne moyenne. Beaucoup de gens ordinaires travaillent quotidiennement sur des ordinateurs. La personne moyenne a la possibilité d'utiliser un ordinateur, mais nous avons encore besoin de programmeurs.

De même, le programmeur moyen n'a pas besoin de connaître ou de programmer régulièrement en langage assembleur. Il s'agit tout autant d'une condition de compétences commercialisables que d'un hommage à notre progrès dans le monde de la technologie. Les entreprises ont besoin d'ordinateurs pour automatiser les tâches. Par conséquent, les programmeurs qui peuvent programmer en .NET / Java sont très demandés.

Les tâches qui peuvent être automatisées, seront automatisées. Toutes les tâches ne peuvent pas être automatisées. Toute automatisation n'est pas parfaite. Alors, l'assemblage est-il important? Bien sûr. Faut-il être "programmeur"? Bien sûr que non.

Hmmm, j'aime vraiment apprendre des trucs de bas niveau.

Ce n'est peut-être pas la comparaison la plus précise, mais pour moi, c'est comme apprendre les machinations à l'intérieur d'une voiture. Je ne sais peut-être pas comment toutes les pièces fonctionnent les unes contre les autres, mais c'est amusant de savoir qu'il y a un moteur, un vilebrequin, des cylindres, des différentiels, des grues, des freins, de l'huile, la combustion, la réfrigération, puis la friction, le stress, la chaleur, les forces, science - thermodynamique, physique, mécanique des fluides ...

Peut-être pas très utile (je ne pourrai pas réparer une voiture en sachant tout cela), certainement pas pratique professionnellement, mais, bien, amusant. L'art pour l'art: la connaissance pour la connaissance.

Je pense qu'une règle d'or utile est la suivante: plus elle doit être rapide, plus le niveau bas que vous devez obtenir.

Donc, votre jeu de tir à la première personne intensif en graphisme ou votre système de trading FX algorithmique, ils sont encore assez bas (C ++, etc.) car la vitesse est la clé. Mais l'application web qui crache un rapport de vente à temps? Bon sang, vous pourriez écrire cela dans Sinclair BASIC, et ce serait toujours acceptable.

Tous les emplois en génie logiciel ne sont pas identiques . Les gens qui travaillent sur les systèmes d'exploitation, les compilateurs, les frameworks, les pilotes de périphériques, les systèmes embarqués et l'informatique scientifique à hautes performances doivent bien connaître les «choses de bas niveau». Les gens qui écrivent des formulaires Access CRUD, ou des paniers d'achat PHP pour les magasins Mom and Pop, ne sont peut-être pas tellement. Quel type de génie logiciel voulez-vous faire et voulez-vous le faire le reste de votre vie?

Mon opinion est que vous devez apprendre au moins un niveau d'abstraction en dessous de celui dans lequel vous travaillez habituellement. Si vous travaillez en C / C ++, vous devez choisir une architecture et un assemblage de machine. Si vous travaillez en PHP, vous devez comprendre HTTP et un peu de C / C ++ ou Perl. Si Access est votre pain et beurre, vous feriez mieux de connaître une théorie RDB, et peut-être un peu sur COM ou .Net. À un moment donné de votre carrière, vous finirez par vous arrêter sur vos traces par un problème à un niveau d'abstraction inférieur, et vous devrez être en mesure de communiquer au moins un peu avec quelqu'un qui est un expert dans ce domaine. Pouvez-vous vous débrouiller sans ces trucs? Bien sûr, mais il est dangereux de prévoir de simplement «se débrouiller» sur un marché du travail concurrentiel.

Je travaille moi-même beaucoup en C # .NET et je me suis toujours éloigné du C, C ++. Récemment, j'ai commencé à chercher du travail et j'ai été surpris de voir combien d'emplois sont disponibles et nécessitent de l'expérience en C, C ++. Au début, je pensais que le C, C ++ devenait obsolète, mais en regardant les emplois disponibles, il ne semble pas que ce soit le cas.

Tous les langages gérés que vous avez répertoriés ont des interprètes ou des machines virtuelles écrits en C / C ++. Sans ces deux, la plupart des langages gérés ou interprétés n'existeraient même pas. Je dirais que vous sous-estimez leur valeur.

Je déteste vraiment la notion même de connaissance "pratique" . Tout ce que vous apprenez est également pratique. Peu importe que vous n'opériez pas à un niveau d'abstraction proche du matériel, le simple fait de connaître les concepts de ce domaine est toujours bénéfique pour construire de nouvelles connaissances à un autre niveau d'abstraction. Plus vous connaissez de concepts liés, mieux c'est.

Pour ce que je fais normalement, C # est un langage de très bas niveau, et je le considère comme quelque chose de très proche d'un matériel. Mais je crois toujours que même ma connaissance rudimentaire et rouillée de l'électronique numérique, de la conception du processeur, etc., est très utile pour tout ce que je fais.

Non, la majorité n'en a pas besoin. Bien que la pratique de techniques de bas niveau donne au développeur une meilleure connaissance de ce qui pourrait affecter le cycle dans son ensemble, de nos jours, le développeur pourrait utiliser ce temps pour étudier de nouvelles technologies, ce qui nécessitait à son tour la connaissance de choses de bas niveau pour être développées mais non fiables. sur.

À mon avis, lorsque vous utilisez un mot «ingénieur», vous voulez dire que l'homme / la femme est celui qui conçoit et construit les choses à partir de zéro. Le vrai problème d'un ingénieur logiciel est de résoudre un problème, mais quel problème? C'est une grande question.

Un développeur est différent d'un ingénieur à bien des égards. Un "développeur" est une personne qui construit généralement des choses sur des plateformes déjà existantes. Il développe les plates-formes existantes ou construit de nouvelles plates-formes héritées des anciennes en utilisant certainement le composant de son système parent.

Un développeur pense généralement d'un point de vue commercial, il n'est pas un scientifique. :) Le développeur est plus proche de l'utilisateur du système, ils pensent les choses du point de vue de l'utilisateur et finissent donc par résoudre les problèmes des utilisateurs en utilisant la technologie.

Un ingénieur intelligent. C'est un scientifique, il résout un problème très authentique. La plupart des problèmes, quel ordinateur lui-même a comme fonctionnalité .. Nous, utilisateur, ne nous approchons jamais de ce problème, il est encapsulé. Les ingénieurs sont ceux qui abandonnent leurs études après avoir fait beaucoup de recherches sur le système existant et trouver quelque chose de nouveau pour résoudre le problème, si la solution l'exige, si leur système avait besoin d'une nouvelle langue, ils inventent une nouvelle langue parce que le système existant n'est pas capable de résoudre ce problème .. Les ingénieurs ont fini par construire un système sur lequel les développeurs construisent leur système.

En effet, un ingénieur logiciel doit apprendre et bien connaître les trucs de bas niveau ... :)

Alors qu'un développeur, cela dépend complètement de son intérêt. :)