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

23

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?

Adam Lear
la source
1
"les performances entre C / C ++ et Java ne seront pas significatives". Si cela se produit bientôt, envoyez-moi un PM pour réviser mes compétences Java. J'ai arrêté d'utiliser Java il y a quelques années pour ces raisons.
sakisk
3
La plupart du code C / C ++ n'accède pas au matériel. Cela facilite les choses, mais cela est généralement masqué par les pilotes de périphérique. J'irais même jusqu'à dire que 95% + du code C ou C ++ n'interagit jamais directement avec le matériel.
Pemdas
1
Je suggère un changement de titre pour les langues de bas niveau. Il y a beaucoup de choses de bas niveau (comment les threads fonctionnent .. comment fonctionne votre système d'exploitation ... etc.) qui ont encore de la valeur même si la connaissance de C ++ ou Assembly peut ne pas l'être.
ShaneC
2
@faif, Pour les applications en cours d'exécution de longue date, une application Java peut suivre le rythme d'une application C / C ++. Après que Java se soit réchauffé. Cela est dû à la technologie hot-spot recompilant le code Java en code natif au fil du temps. Cependant, pour les applications de courte durée, le temps de démarrage de Java est toujours horrible. À un moment donné, en particulier pour les applications serveur, les communications sont plus votre goulot d'étranglement que le traitement réel.
Berin Loritsch
1
@BerinLoritsch Java est relativement rapide, oui, mais la surcharge de mémoire, la surcharge de la bibliothèque d'exécution, l'accès au matériel de bas niveau et la préconfiguration de la VM avant de s'exécuter (afin d'atteindre différentes limites de tas, par exemple) sont terribles, par rapport à juste un programme de bas niveau, fonctionnant sur le système d'exploitation. Il ne s'agit pas uniquement d'exécuter des instructions dans le même ordre de grandeur.

Réponses:

18

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.

holtavolt
la source
Merci pour votre réponse. Je continuerai à étudier davantage les fondations informatiques (telles que le système d'exploitation, le réseau, plus de mathématiques ... également juste assez pour comprendre le principe de base et ne pas trop me concentrer sur l'amélioration de la programmation). J'espère que cela vous sera utile un jour.
Amumu
1
Une meilleure compréhension de ce qui se passe au niveau inférieur aidera également à éclairer vos décisions.
dietbuddha
1
Pour ajouter mon 0,02, savoir comment quelque chose est fait lorsque vous l'exigez est généralement une bonne chose. Peut aider à rendre vos demandes plus raisonnables et efficaces (s'applique à la programmation de haut niveau et peut-être aux patrons;)).
ssube
43
  • 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.

Patrick Karcher
la source
7

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.

JohnFx
la source
3

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

Jesus Ramos
la source
3

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 ++.

David Thornley
la source
2

"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.

Adam Tuliper - MSFT
la source
@Adam Tuliper "un OS écrit entièrement en assembleur" Intéressant. Pouvez-vous me donner le nom de l'OS? Vous avez fait un bon point sur le dépannage.
Amumu
@Adam: Un "OS" d'assemblage uniquement n'a probablement pas beaucoup de cloches et de sifflets (comme une interface graphique animée de fantaisie et un programme de peinture), mais il ne pourrait peut-être exécuter qu'un ou deux processus en mode utilisateur ...
Macke
@Macke: Tu plaisantes? Plus de systèmes d'exploitation multitâche ont été écrits en langage assembleur qu'en langage C. Le système d'exploitation à partir duquel NT (le noyau Windows) a été cloné a été écrit principalement en langage assembleur Macro-32.
bit-twiddler
1
@ bit-twiddler: Êtes-vous sûr? La plupart des sources que j'ai vues étaient dans BLISS ...
TMN
@TMN: BLISS n'était utilisé que pour les éléments de système d'exploitation de niveau supérieur. L'ensemble du noyau VMS a été écrit en Macro-32. J'ai gardé une liste du code de traitement au niveau des fourchettes pendant des années parce que je pensais que c'était une idée tellement cool. Le traitement au niveau de la fourche était un mécanisme par lequel un gestionnaire d'interruption pouvait planifier la partie non critique de son code pour s'exécuter à un niveau de priorité d'interruption inférieur. Le traitement au niveau de la fourchette a été renommé Appels de procédure différée dans le noyau NT.
bit-twiddler
2

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.

user6791
la source
Se mettre d'accord. Je fais de la programmation embarquée depuis environ 30 ans, et même si je ne me retrouve plus à écrire le code assembleur (tout est en C), je parcours souvent un programme instruction par instruction.
tcrosley
Heck, je débogue souvent le code C et C ++ en mode CPU sur Windows. La connaissance de l'architecture et du jeu d'instructions pour le processeur ainsi que l'organisation d'exécution du compilateur utilisé est un ensemble puissant de compétences à avoir dans son sac. Veuillez consulter la question suivante programmers.stackexchange.com où je détaille le code généré par GCC: programmers.stackexchange.com/questions/59880/…
bit-twiddler
2

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.

P.Brian.Mackey
la source
0

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.

Dynamo
la source
0

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.

Adrian Parker
la source
1
-1: 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. - Juste curieux, quel âge as-tu? De meilleurs algorithmes, une meilleure architecture et un meilleur matériel accéléreront la plupart des applications logicielles modernes. Les jeux informatiques et les systèmes embarqués sont des exceptions à cette règle.
Jim G.
Beaucoup trop vieux! :-) Vous mentionnez de meilleurs algorithmes, une meilleure architecture de machine, un meilleur matériel - mais à mon avis, ils ont un impact équivalent sur la vitesse d'exécution des processus. Augmentez la vitesse du processeur, puis chaque processus (devrait) s'exécuter plus rapidement quel que soit le langage dans lequel il a été développé. Utilisez un algorithme de tri lent et votre application s'exécute plus lentement que nécessaire, peu importe ce que vous avez écrit. Je pose le choix du bas niveau ou Le langage de programmation de haut niveau fait encore une différence relative par rapport à la vitesse d'exécution. Si les millisecondes sont importantes, descendez bas. Les systèmes de trading algorithmiques ne sont pas écrits en Java.
Adrian Parker
0

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.

Charles E. Grant
la source
-1

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.

user676938
la source
-1

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.

Pemdas
la source
-1

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.

SK-logic
la source
@Amumu a déclaré: Vous avez fait valoir un bon argument. Les gens associent généralement des connaissances qui rapportent beaucoup d’argent à des «connaissances pratiques». Cependant, ils ont un point. À tout le moins, nous nous attendons et nous attendons à ce que nous apportions quelque chose à la société si nous ne gagnons pas d'argent avec les choses que nous avons apprises, en particulier celles qui ne profitent pas à notre vie. Par exemple, nous pouvons vouloir apprendre la philosophie ou les façons de rendre notre vie plus significative. Mais si nous passons du temps à étudier les mathématiques, électriques mais à mi-chemin, nous ne pouvons rien faire et perdre votre temps.
Adam Lear
@Anna Lear, le problème est que l'on ne peut pas maîtriser une compétence "pratique", directement applicable sans une couverture très large de "non pratique". Tout simplement parce que toutes les connaissances de ce monde sont étroitement liées. Aucune connaissance ne peut être une "perte de temps", quelle que soit sa distance par rapport à toute pratique possible.
SK-logic
1
-1: Tout ce que vous apprenez est également pratique. - Sensationnel. Je devrais peut-être mémoriser les réponses à toutes mes cartes de questions «Trivial Pursuit»! ;)
Jim G.
@ Jim G., oui, tant que vous avez suffisamment de temps libre et que cela ne vous coûtera pas de ne pas apprendre quelque chose qui vous ferait avancer plus que cela. Mémoriser des choses «inutiles» est en fait un moyen très robuste d'améliorer votre mémoire.
SK-logic
-1

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.

doc_id
la source
-1

À 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. :)

Mohammad Abdurraafay
la source
1
-1: Umm ... Les titres d'emploi n'ont aucun sens, mec.
Jim G.