L'assembleur est-il essentiel pour coder ?

C’est amusant de voir la constance du "mec dur" qui lui a connu le temps glorieux où "on était des hommes, on faisait ça à la main, contrairement aux lavettes d’aujourd’hui". Ça va être quoi dans 20 ans ? On est pas un vrai développeur si on sait pas déployer une application multi-conteneur à la main ?

J’ai l’impression que vous avez beaucoup de mal -tous- à admettre que le développement d’aujourd’hui est bien plus simple qu’avant et qu’une petite connaissance de l’assembleur est toujours bonne à prendre…

Je n’ai pas connu l’époque "glorieuse" mais il est évident que les "anciens" étaient plus compétents que les dev d’aujourd’hui qui ont tout à disposition et surtout Internet

Le dev aujourd’hui, il passe plus de temps à chercher sur internet les bouts de code pour son projet qu’à coder.

Le dev aujourd’hui, il passe plus de temps à comprendre comment fonctionne Visual Studio, Rad Studio and Co qu’à coder.

Le dev aujourd’hui, il passe moins de temps à coder parce-que son chef de projet lui demande de finir son projet pour hier…

Le dev aujourd’hui code de moins en moins, il se contente de coller des morceaux de code et ça arrange tout le mode…

Les dev aujourd’hui ont besoin de la vache, la laitière, l’herbe, le pré, … Enlever un seul élément et le dev est perdu…

J’ai l’impression que tu ne sais pas de quoi tu parles.

Merci fatov pour ses explications. La prochaine fois que j’aurai un refactoring d’une semaine à faire, plutôt que de me casser la tête à réfléchir, je chercherai sur Internet si y’a pas le code tout fait. Comme ça je gagnerai du temps que j’irai dépenser sur 9gag plutôt que me former à l’assembleur et devenir un vrai dev.

Ce qui serait bien, c’est que la suite du débat – et je me permet de dire ça avec mon étiquette verte – ne se contentent plus d’affirmations péremptoires, mais soient étayées par des sources externes, ou au mieux des raisonnements construits.

La prochaine intervention qui se contente de lister des préjugés sera considérée comme du troll et sanctionnée comme telle.

Présenter l’assembleur comme une étape vitale de la formation d’un développeur pose problème pour pas mal de raisons, mais si il faut en retenir une seule, c’est peut-être que l’assembleur aussi, c’est un truc d’amateur, et que les vrais écrivent directement le code machine en binaire sur une carte perforée, "comme avant".

Le principe de la programmation, en général, c’est qu’on a des API, et qu’on travaille avec une API quelconque. C’est HTML, c’est le standard C++, c’est l’assembleur X86, c’est un bus I2C… On a tous une frontière "basse" dans notre métier, au delà de laquelle on ne cherche pas trop à comprendre. Peu importe à quel niveau dans la couche d’abstraction se trouve cette frontière, on en a tous une.

Les processeurs modernes ont tellement intégré ce concept d’API que X86 est aujourd’hui une couche de compatibilité, une interface, un wrapper au dessus d’un cœur de processeur moderne qui utilise des mécanismes un peu différents. On parle d’Instruction Set Architecture pour cette interface et de microarchitecture pour le véritable design en dessous. L’assembleur est devenu une API comme les autres et ce n’est même pas la plus basse qui soit.

(D’ailleurs, le saviez-vous ? Votre processeur est défini par du code aussi. )

J’ai l’impression que vous avez beaucoup de mal -tous- à admettre que le développement d’aujourd’hui est bien plus simple qu’avant et qu’une petite connaissance de l’assembleur est toujours bonne à prendre…

Je pense que personne ne nie qu’il est plus facile d’écrire un programme complexe aujourd’hui qu’hier. Est-ce un problème ? Non, car plutôt que de se préoccuper de la taille des entiers ou de la gestion fine de la mémoire, on se préoccupe de tester le programme ou de réaliser des fonctionnalités.

Or un logiciel doit avant tout être fiable et apporter des fonctionnalités pour répondre à des besoins. Ce qui est dingue c’est qu’aujourd’hui on peut réaliser des fonctionnalités très complexes dont on ne rêvait même pas il y a 10 ans, avec une fiabilité déconcertante. Et ce n’est pas grâce à une maitrise de l’assembleur qu’on arrive à ce résultat mais justement par l’utilisation de technologies éprouvées qui font de l’abstraction et simplifient le travail pour construire de nouvelles choses. Ces briques élémentaires permettent cela et c’est très bien.

Je n’ai pas connu l’époque "glorieuse" mais il est évident que les "anciens" étaient plus compétents que les dev d’aujourd’hui qui ont tout à disposition et surtout Internet

Je ne suis pas convaincu par cette assertion. Oui il y avait des génies par le passé mais les gens compétents existent toujours en nombre. Sinon on pourrait se demander qui écrit les programmes fiables et riches d’aujourd’hui (un site Web comme Facebook ce n’est pas 3 lignes de HTML copié / collé depuis un autre site).

De même qu’il y avait des mauvais par le passé qui sont toujours là aujourd’hui.

D’ailleurs, je vais te raconter deux choses. Je pense que tu es un peu trop formaté par ton métier, ta spécialisation. Le seul domaine informatique où la connaissance de l’assembleur peut être requis c’est dans les systèmes embarqués et la conception de systèmes d’exploitation / compilateurs / débogueur. Et encore pas toujours.

Forcément dans ce domaine, ceux qui connaissent l’assembleur sont en général (mais pas toujours) plus compétents car cela signifie très souvent qu’ils font cela par passion et qu’ils apprennent par eux mêmes. En aucun cas cela signifie que l’assembleur les rendra meilleur, mais que c’est un indice que cet individu est bon à l’origine car il a prit le temps de l’apprendre et d’élargir ses compétences. Les mauvais informaticiens sont en général ceux qui ne cherchent pas à apprendre d’autres choses ou de se maintenir à niveau.

Mais notre métier d’informaticien embarqués ne doit pas caché que l’informatique est vaste et que l’immense majorité de nos confrère n’en ont pas besoin de l’assembleur. Pour un développeur Web il sera plus pertinent d’apprendre les rouages internes de PHP ou Django pour maitriser leur développement que de l’assembleur qui n’aura que valeur de culture générale. On a hélas pas le temps de tout apprendre et chacun doit apprendre ce qui est utile à sa zone de travail, soit en général la couche d’au dessus et d’en dessous direct (donc pour un pythonneux, comment fonctionne Python, mais pas l’assembleur !).

Ensuite l’informatique a évolué, ses contraintes et exigences aussi. Dans notre monde, le socle commun à tout informaticien le plus essentiel n’est plus la prog système ou l’assembleur, c’est plutôt la sécurité et le réseaux qui sont des sujets très très vastes et très compliqués pour faire les choses bien. J’espère que tu maitrises les notions de base de cryptographie, les fonctions de hashages, et comment architecturer proprement un programme pour éviter les failles de sécurité évidentes.

Sinon, mon second point est plutôt une anecdote mais qui est je pense révélateur. Je bosse actuellement chez un concepteur de contrôleurs de compresseurs. Ils ont l’habitude d’utiliser un système temps réel pour leur système à savoir FreeRTOS. Mais si FreeRTOS c’est sympa, cela reste grandement limité. Il faut réinventer beaucoup de choses manuellement. Pour aller plus vite, ils utilisent du Linux maintenant. Car oui, il y a encore quelques mois, ils devaient sur leur FreeRTOS écrire un système de fichier par eux mêmes. Qui ne sera jamais aussi bien optimisé et fiable que ce que Linux propose. Avec Linux on n’a qu’à choisir et hop. On gagne un temps fou, temps qui est indispensable pour réaliser des tests et créer des fonctionnalités ayant une valeur ajoutée.

Bah ici, c’est pareil, pour nombre de développeurs plutôt que de recréer une gestion fine de la mémoire à la main, on laisse Python / Java ou autres le faire. Ça a ses inconvénients c’est sûr, mais cela permet de gagner du temps et de l’allouer à des choses utiles. En tout cas l’assembleur n’apporte plus rien de pertinent d’un point de vue logique et performances. Cela ne vaut plus le coup et seuls ceux qui en ont encore besoin devraient l’apprendre (ou par plaisir).

J’ai l’impression que vous avez beaucoup de mal -tous- à admettre que le développement d’aujourd’hui est bien plus simple qu’avant

Que ce soit différent aujourd’hui qu’avant, c’est indiscutable. Que ce soit plus simple, ou plus facile, en revanche, est extrêmement discutable, voire carrément faux.

Par rapport à il y a 10 ans (où le dévelopemment était soit-disant plus compliqué) :

• Les services en-ligne ont explosé sur le réseau (en particulier sur le web… tu sais, là où les gens font des copier-coller). Au point de voir naître l’axiome central du cloud, à savoir que même si une météorite s’écrase sur un datacenter et crame la moitié de tes serveurs ton application n’a pas le droit de s’arrêter de fonctionner. À partir du moment où ton application sera au minimum virtualisée, le plus souvent containerisée, faire de l’assembleur n’a juste aucun intérêt : tu ne sais même pas quel type de processeur va la faire tourner. Par contre rendre ton application résiliente, choisir une stratégie correcte de réplication ou de géo-répartition des données, rendre trivial le déploiement à chaud de nouveaux noeuds, sont des vraies problématiques, qui touchent même les plus petites startups, et plus simplement des problématiques d’un autre monde réservées à des géants comme Google ou Microsoft.

• Ces services en-ligne se sont fédérés et opèrent entre eux : non seulement ils peuvent être accessibles par des quidams (utilisateurs humains), mais la majorité d’entre eux servent également d’autres services, ce qui signifie que tu n’as pas le droit à l’erreur pendant le design de ton API, si tu ne veux pas risquer de devoir casser sa compatibilité avec tes utilisateurs. Dans de telles conditions, gagner ou perdre une dizaine micro-seconde par appel est beaucoup moins impactant que de mal anticiper l’évolution de ton modèle. Un tel design ne se fait pas par copier coller, c’est purement et simplement du jus de cerveau, et une API mal fagotée handicape des milliers de gens.

• Les méthodes de travail et de collaboration ont été révolutionées. Sur un projet moderne, chaque commit que tu réalises sur ton code est susceptible d’être automatiquement construit, testé, releasé, et déployé en production sur des dizaines ou des centaines de serveurs en parallèle pour être utilisé par des centaines de milliers d’utilisateurs dans l’heure qui suit. Dans ce style de rythme, effectivement, c’est pas tellement rentable de passer deux semaines sur l’optimisation d’une fonctionnalité.

Alors certes, depuis 10 ans où le développement était "plus compliqué", on a juste explosé la complexité de la plus petite application en prod, tout autant que sa fiabilité (et bien sûr il s’agit là de la complexité et de la fiabilité exigées par les clients). On a également compris que la durée de vie d’un logiciel était tellement courte qu’il n’était bien souvent pas rentable de l’optimiser au poil de cul.

Au passage, je suis un dev d’aujourd’hui, mais j’utilise Vim et je n’ai pas de chef de projet. Par contre, comme la totalité des développeurs d’aujourd’hui, j’ai le soucis de produire du code réutilisable, non pas par copier-coller, mais simplement en important mes bibliothèques et en appelant ses fonctions pour éviter d’avoir à réinventer la roue.

Pour résumer : ce n’est pas parce que le développeur d’aujourd’hui ne réinvente pas la roue qu’il ne code plus ou que son code est moins compliqué. Simplement ça lui permet de rendre son code plus utile, plus facile à maintenir et plus fiable. En passant moins de temps à réinventer la roue, cela lui laisse plus de temps pour coder le reste du train. Et toi, tu es pile poil en train de dire que ça demande moins de compétences de construire un train que de construire une seule de ses roues…

Moi je suis d’accord avec fatov. Je constate ça tous les jours au boulot. Je suis développeur web et tous les jours, y’en a un qui vient me voir parce qu’il comprend pas, son code il fonctionne pas, et ça fait une heure qu’il galère. Évidemment, c’est toujours ceux qui n’ont appris que les langages de haut niveau qui font ça. Les autres ont appris à fouiller dans les entrailles de la machine, à aller au fond des choses. Ceux qui se contentent de PHP et autres Pythons ne sont que des êtres superficiels, c’est tout.

Ça fera donc 3 jours de LS pour blo yhg. D’autres amateurs ?

Que signifie LS ?

Lecture seule, ou incapacité à poster sur le site.

Lecture-seule. Il peut donc toujours se connecter, mais ne peut plus poster.

Un renard ça aboie comme un chien ! #provocation

Effectivement, cette affirmation est totalement fausse, le développement est très vaste et à moins d’avoir en tête la conception d’un compilateur, du reverse, du système, … L’utilité de connaitre l’assembleur est proche de zéro…

Mais rien n’interdit de l’apprendre un peu pour sa propre culture générale.
Et je pense que connaitre les bases de l’informatique peut apporter ce petit plus au développeur…
Même si pour la création d’une app web ou d’un logiciels X, ça ne sert plus à rien… On est bien d’accord la dessus

J’ai fait une petite vidéo sur YT ou j’ai codé Hello World dans tous les langages connus avec tous les compilateurs du marché et le Hello en assembleur est toujours très apprécié même par les développeur web

L’idée est la notion de relation de cause à effet. Le débat part en troll, je pose cet avertissement à 13h17 :

Les trois messages suivants sont constructifs, mais pas la fin du quatrième :

C’est dommage d’ailleurs, parce qu’il y avait un début d’argument dans la première partie du message.

Enfin, quoiqu’il en soit : cause (la règle donnée explicitement a été violée après l’avertissement) → conséquence (3 jours de lecture seule). C’est pas faute d’avoir prévenu.

Si on commence à faire du pinaillage en fonction des intentions supposées et non-vérifiables portées par les messages, ça va être compliqué (et ça a déjà été tenté, et ça a apporté pas mal d’emmerdes puisque certains sont très doués pour jouer avec ça). Je note d’ailleurs que la technique semble avoir porté ses fruits, puisque la seule intervention de fatov depuis l’avertissement est beaucoup plus nuancée.

La vache, tu fais quoi aux gens après les avoir mis en LS @SpaceFox ?

On n’a pas besoin de jugement sur les personnes à partir des technologies qu’ils utilisent. Ce n’est pas le genre de discussion que j’attends sur un site comme ZdS, et les guerres de chapelle sur les langages perdent le peu d’intérêt qu’elles ont encore à l’instant où on part dans les attaques personnelles.