Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Gerry Sussman explique que les ingénieurs modernes ne sont pas de vrais programmeurs
La plupart se contentant d'assembler des bibliothèques tierces

Le , par Victor Vincent

20PARTAGES

18  4 
Un ingénieur moderne a-t-il besoin d'apprendre les notions enseignées dans SCIP pour développer ?
À l’occasion de la tenue de la conférence sur le langage LISP, organisée à New York City, un participant avait demandé à Gerry Sussman, coauteur du célèbre livre intitulé « Structure and Interpretation of Computer Programs (SICP) », pourquoi le MIT avait décidé d’arrêter l’enseignement de son cours 6.001 qui était basé sur leur livre. Sussman a répondu qu’il estimait qu’il était temps pour lui et Hal Abelson de se reposer un peu, car ayant enseigné ce cours depuis les années 80.

Cependant, la raison principale de l’arrêt de l’enseignement de ce cours qui apprenait les bases de la programmation telles que les notions d’abstraction, de récursivité et de programmation modulaire était tout à fait ailleurs. En effet, Sussman pense que le contenu du SICP ne correspond plus aux aspirations des ingénieurs de nos jours et des attentes qu’ont les entreprises. Il ajoute que, contrairement aux ingénieurs des années 80, voire les années 90, qui réalisaient des systèmes complexes en partant de zéro en combinant de simples bouts de codes qui étaient bien compris, car les ayant codées eux-mêmes, les ingénieurs contemporains se contentent de mettre ensemble des codes déjà existants pour réaliser des programmes compliqués dont ils ne maitrisent même pas le code la plupart du temps.

Le but de SICP était, selon Sussman, de fournir un niveau d’abstraction pour raisonner sur des systèmes tels qu’il en était construit dans les années 80 et n’est donc plus adapté aux réalités auxquelles sont confrontés les ingénieurs actuellement. Le constat fait par le coauteur de SICP est que l’environnement de programmation des ingénieurs de nos jours se résume en de gigantesques bibliothèques pour produire des logiciels destinés à des matériels compliqués dont ils n’ont aucune idée du fonctionnement interne. C’est ce qui fait, d’après lui, qu’ils n’ont plus besoin de ce niveau d’abstraction enseigné dans le livre et qui était nécessaire pour les ingénieurs de l’époque. Sussman confie que ses étudiants passent maintenant le plus clair de leur temps à lire les manuels de ces bibliothèques essayant de comprendre comment les faire fonctionner ensemble dans le but de réaliser une tâche bien définie.

Sussman déclare que la programmation de nos jours est comme la science en ce sens que le développeur met des bibliothèques ensemble et, sans partir de zéro, écrit le code qui va permettre de les intégrer pour ensuite constater le résultat. Dès lors, l’approche d’analyse par synthèse enseignée par SICP devient inappropriée pour les programmeurs modernes. Ce point de vue de Sussman est aussi partagé par un développeur iOS dont le pseudonyme est Jdmoreira qui affirme qu’il a appris la programmation en suivant les cours basés sur SICP, mais qu’il se trouve réduit aujourd’hui à intégrer des bibliothèques dans un framework propriétaire sans aucune possibilité d’accéder aux sources et naturellement dont il ne comprend pas grand-chose du fonctionnement interne.

Source : Posterioscience

Et vous ?

Pensez-vous que la programmation de nos jours se résume à l'intégration de bibliothèques ?

Voir aussi

le forum Débats sur le développement

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 09/05/2016 à 14:03
Citation Envoyé par Victor Vincent Voir le message
Gerry Sussman explique que les ingénieurs modernes ne sont pas de « vrais » programmeurs,
Il n'a jamais dit ça. Les propos sont complètement déformés et surinterprétés. Même si on sent une pointe de nostalgie chez lui, il ne porte aucun jugement de valeur sur les ingénieurs actuels, il constate juste que le job est devenu différent.

C'est quoi ces titres clickbaits qui créent des trolls là où il n'y en a pas ?
18  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 09/05/2016 à 3:08
Citation Envoyé par FoinFoin Voir le message
Le principal avantage est que je suis en contrôle du code que je fais et quand on me mentionne un problème, je sais exactement où chercher et comment corriger le problème.
Le hic est que cela ne fonctionne que lorsque l'on travaille tout seul.
En équipe, tu intègres forcément du code que tu ne maîtrises pas car développer par un autre, même si c'est ton voisin de table.

Je pense surtout qu'il faut bien savoir choisir les librairies que l'on intègre à un projet et avoir un bon suivi dans le temps pour les maj de ces dernières.
Rien que ça, c'est déjà pas mal de taf.
16  0 
Avatar de Golgotha
Membre expert https://www.developpez.com
Le 09/05/2016 à 10:38
Je suis complètement à l'opposé de Gerry Sussman, et je vais expliquer pourquoi.

Gerry Sussman prends là une position purement conservatrice et complètement idéologique. Dans un premier temps, si j'avais ce monsieur en face de moi, je me ferais un plaisir de lui expliquer que lui non plus n'est surement pas un "vrai" programmeur, car d'après ça définition, le "vrai" c'est celui qui connait les bases et utilise les bases pour programmer, mais qu'est ce que les bases ? le langage C ? l'assembleur ? Dites moi Gerry, coder vous vos programmes en assembleur, avez vous coder votre propre compilateur de C ? Le seul et à jamais unique "vrai" programmeur il s'appel Alan Turing, et nous ne somme que des "ré-utilisateur" de ce qu'il a crée, et vous aussi.

Ensuite, Ou en serions nous si l'homme ne ré-utilisai jamais ces inventions pour avancer ? Imaginez l'ingénieur en bâtiment sans grue, imaginez le boulanger moudre ces grains à la main, l'agriculteur sans tracteur ? Alors quoi ? On renonce à utiliser les avancés techniques pour rester dans le "vrai", Je vois les bibliothèques jQuery (js) ou stdio (c) exactement comme le tracteur de l'agriculteur, c'est une avancé technique qui me permet d'être plus productif, et ça n'a absolument rien à voir avec le fait d'être bon ou mauvais, au contraire, inintelligence c'est de prendre les bons outils et de faire du bon travail avec.

Enfin, le développement avance très vite, et il deviens clairement impossible d'être spécialisé dans tout les domaines. Vouloir écrire soi même tout le code pour une application deviens alors non seulement contre-productif mais aussi dangereux, pour la raison que d'autre personnes ont déjà écris le code que vous voulez écrire mais beaucoup mieux que vous. Accepter que vous ne maîtriser pas tout les domaines n'est pas une faiblesse, au contraire, c'est être lucide et responsable. Non, vous ne pouvez pas tout connaitre, et c'est normal.

Voilà pourquoi je suis d'un avis radicalement opposé à Gerry Sussman.
14  5 
Avatar de TheLastShot
Membre extrêmement actif https://www.developpez.com
Le 09/05/2016 à 15:16
Citation Envoyé par el_slapper Voir le message
C'est essentiellement la différence entre un travail utilisable fait rapidement et un travail de très faible valeur ajoutée qui demande un temps fou.
Ce qui est "marrant" c'est que pendant un de mes stages dans une grande entreprise international spécialisé dans le développement de logiciel de simulation, 3D, etc. dont je tairais le nom j'ai entendu le même discours. C'est toujours la même chose, faire les choses le plus vite possible, parce que sinon on perd de l'argent...
Ce qui est moins drôle c'est qu'aujourd'hui c'est un peu l'hécatombe pour eux... Forcément, avec des concepts tels que "les erreurs documentées" (en gros, plutôt que de résoudre les problèmes, on dit "ouais on connait, on sait plus ou moins, ce qui la provoque" on ce retrouve avec tout un logiciel (voire une gamme de logiciel) qui risque de planter à tout moment étant donné que le code en question se trouve au fin fond des entrailles des codes sources.
En revanche, dans les quelques boites que je connais où les mecs n'ont pas peur de se sortir les doigts de leur fondement respectif afin de les utiliser sur leur clavier (toujours respectif, faut un minimum d'hygiène), il y a "étrangement" beaucoup moins de problèmes.

Soit dit en passant, ce n'est peut-être qu'un extrapolation de ma part, mais pour quelqu'un qui semble défendre l'utilisation de bibliothèques, je trouve cela un peu irrespectueux envers ceux qui développent ces bibliothèques de parler de "travail de très faible valeur ajoutée".

Et enfin, parce que cette immonde expression me hérisse toujours le poil :
mais il ne faut pas ré-inventer la roue en permanence
(Pour la défense de l'auteur du message, le "en permanence" ajoute une petite nuance qui justifie un peu plus ses propos... mais quand même...)
Il ne faut pas ré-inventer la roue. En voilà une, banalité (pour le coup c'est un peu le cas de toutes les expressions toute faites de ce genre), parmi les plus énervantes que je connaisse.
A tous ceux qui prennent cette expression un peu trop au pied de la lettre, je leur demanderais d'aller faire un petit tour sur l'historique de la roue en question !
En effet, il me semble qu'il y a une nette différence entre la roue telle qu'elle a été inventée (une roue pleine en pierre) et les roues que l'on retrouve aujourd'hui sur nos voitures (et heureusement, sinon je vous raconte pas l'état des routes...). En effet, la roue a subit bon nombre de modifications qui fait que, mis à part sa forme grossière, la roue d'aujourd'hui n'a pas grand chose à voir avec la roue d'origine... Cette dernière a donc bien été réinventée, et ce à maintes reprises. Ce qui n'a pas été réinventé en revanche, c'est le concept de la roue, mais la manière dont on "implémente" ce concept a bien changée.
Ensuite, cette expression donne l'impression que la roue symbolise l'invention ultime, le saint graal de la technologie et que jamais on ne pourra faire mieux... A cela je répond: essayez de grimper un escalier avec une chaise roulante (ceci est évidemment rhétorique, et si vous le faites réellement, je ne saurais être tenu responsable en cas de blessures). La roue est une réponse à un problème (permettre le déplacement d'un objet d'un point A à un point B) dans une contexte donnée (un sol dur, relativement plat, avec une pente pas trop élevée). Mais en dehors de ce contexte la roue n'est clairement pas la bonne solution (ce n'est pas pour rien que les bateaux n'ont pas de roues...).

Et bien en ce qui concerne l'informatique, c'est la même chose... Au lieu d'utiliser cette expression, remplacer le mot "roue" par n'importe quoi et vous verrez que ça parait déjà moins évident... Petit essaie : "Il ne sert à rien de réinventer l'ordinateur" => Si je vous dis ordinateur quantique, supercalculateur, smartphone, tablettes, etc. ça vous parle ? J'ai besoin d'être plus explicite ?

Alors par pitié, arrêter de sortir cette phrase à tord et à travers. Je comprends que tout le monde n'ai pas l'envie, ni même la capacité, de se lancer dans des projets aussi complexe, mais ce n'est pas une raison pour décrédibiliser de la sorte ceux qui ont le courage de le faire et qui nous permettent aujourd'hui d'avoir les bibliothèques/frameworks que l'on a, et qui nous permettront demain d'en avoir de meilleurs.
8  0 
Avatar de ScriptorTux
Membre régulier https://www.developpez.com
Le 09/05/2016 à 9:09
Je suis tout à fait d'accord qu'il important de connaître les bases de la programmation et tout ce que cela signifie. Cependant, ne pas utiliser de bibliothèques me semble un "prétentieux" (en exagérant évidemment un peu). En effet, si des bibliothèques reconnues et solides, et utiles à notre projet, sont déjà sur le marché pourquoi ne pas s'en servir ? Qu'est-ce qui nous prouve que des bibliothèques "maison" seront plus stables et optimisées que certaines bibliothèques sur le marché ou open-source ?

Après je suis aussi d'accord qu'il est aussi intéressant de créer ses propres bibliothèques quand on a le temps ou que c'est pour notre propre loisir, ce qui permet d'élargir nos connaissances et en plus comme l'a dit FoinFoin, on a l'avantage d'avoir plus de contrôle sur ce que l'on écrit.

Mais tout ceci ne reste que mon point de vue.
7  0 
Avatar de sinople
Membre chevronné https://www.developpez.com
Le 09/05/2016 à 11:17
Qu'est-ce qui nous prouve que des bibliothèques "maison" seront plus stables et optimisées que certaines bibliothèques sur le marché ou open-source ?
Rien du tout, c'est même probablement certains que les bibliothèques "maison" ne seront de moins bonne qualité. Et c'est à mon avis contre-productif de vouloir réinventer la roue.

Néanmoins savoir qualifier la qualité des bibliothèques, et comprendre son fonctionnement si besoin, est quand même une qualité importante.
7  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 09/05/2016 à 11:22
Mis à part l'exercice et le trip pour ceux qui ont le temps (ça m'arrive), quelle est la "valeur" d'une telle démarche ? Un programme, c'est fait pour être utilisé. Les utilisateurs je sais pas si ça les intéresse de savoir que tout à été fait de zero par un "vrai programmeur".
De plus un programme dois répondre à un besoin à un moment précis.

Je préfère livrer un programme moins optimisé en python dans 2 mois avec 50 bibliothèques, que de faire un programme en assembleur from scratch livré dans 3ans et qui ne servira plus à rien.
6  2 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 09/05/2016 à 14:20
C'est essentiellement la différence entre un travail utilisable fait rapidement et un travail de très faible valeur ajoutée qui demande un temps fou.
5  1 
Avatar de TheLastShot
Membre extrêmement actif https://www.developpez.com
Le 09/05/2016 à 22:13
@Lfc.vs: J'ajouterais que non seulement on fini par avoir sa propre bibliothèque (que du coup on maitrise mieux que n'importe quelle bibliothèque trouvée sur internet (ou alors il y a un problème quelque part)), mais aussi qu'à force on sait ce qu'on a à faire, et le gain de temps peu se révéler considérable.
Je prends pour exemple quelque chose qui m'est arrivé il y a quelques jours. Un de mes associés travaillait depuis plusieurs semaines à l'intégration d'une bibliothèque pour faire des chart en javascript avec angularjs (donc angular-nvd3, qui lui-même nécessite nvd3, qui se base du d3... rien que ça, quand je vois autant de surcouche ça me fait un peu peur (surtout que derrière on doit quand même coder une petite couche supplémentaire pour traiter nos données avant de les envoyer à la lib'...). Bref, il a perdu un temps fou dessus pour arriver à faire ce qu'il voulait (un simple pie chart... c'est quand même parmi ce qu'il y a de plus basique dans le domaine) sans y arriver (parce que oui, contrairement à ce que laissent penser certains, toutes les bibliothèques ne sont pas miraculeuses, bien au contraire (et notamment en web...)).
Sur ce j'arrive avec ma petite bibliothèque perso pour gérer du SVG (que j'avais codé en 2 jours pour un autre projet). Résultat ? En une après-midi de boulot, on a réussi à obtenir un pie-chart.

Bref! C'est avant tout un habitude à prendre, et une rigueur à apprendre. Mais au final, quand on sait faire les choses par soi-même, on a souvent plus vite fait de le faire que de chercher parmi les centaines de bibliothèques (mal voire pas documentées) qui pullulent sur internet, pour se rendre compte qu'en plus il faudra retravailler derrière.
4  0 
Avatar de CaptainDangeax
Membre éclairé https://www.developpez.com
Le 11/05/2016 à 9:50
Bonjour à tous

Je ne me considère pas comme un programmeur, mais bien sûr je code. Dans le cadre de mon travail, j'utilise bash et python. Bien évidemment, je ne fais que coller ensemble des fonctions que je n'ai pas écrite et que je ne maîtrise pas. Dans mes loisirs, je bricole avec des microcontrôleurs. Mes 2 derniers projets, la conversion en USB d'une vieille radiocommande, et un module de commande de feux de jour pour ma moto.
Concernant la manette USB, j'ai utilisé un microchip Pic18F et j'ai utilisé la librairie en langage C qui contient déjà quasiment tout ; je n'ai eu qu'à écrire le descripteur USB HID (chiant), la gestion des 4 boutons, la gestion des 4 axes avec le mini-max et la mise à l'échelle. Comme c'est du C, je n'ai aucune idée de la tête du langage machine derrière, même si je connais les restrictions de ce type d'architecture (l'usage de la pile et de l'adressage indirect ne sont pas optimaux sur PIC18F, donc à éviter en C)
D'un autre coté, pour le module de commande des feux de jour, j'utilise un Atmel AT89C2051 que je programme directement en assembleur. Il faut dire que l'asm8051 est pour moi BEAUCOUP plus facile que le l'asm des PIC16 et PIC18 des Microchips.
J'ai acheté un pickit3 pour les microchip (approche industrielle) et j'ai fabriqué mon propre programmateur et écrit mon propre programme pour les AT89 (approche artisanale)
Il faudra toujours des programmeurs capables de créer les bibliothèques, que d'autres utiliseront. On passe dans l'informatique à une industrialisation, comme ce fut le cas dans l'artisanat. Mon grand'père était artisan, compagnon du devoir, il a fabriqué ses propres outils de charron à la forge. Un menuisier d'aujourd'hui achète ses outils au magasin. En est-il un meilleur ou plus mauvais travailleur que mon grand'père ? La provenance des outils n'est pas un critère, il y a juste une spécialisation et un menuisier d'aujourd'hui ne maîtrise plus la forge, ce qui laisse de la place à des métallos...
4  0