Comment l'augmentation de la complexité des systèmes a-t-elle affecté les générations successives de programmeurs?

En tant que "nouveau" programmeur (j'ai écrit une ligne de code pour la première fois en 2009), j'ai remarqué qu'il est relativement facile de créer un programme qui présente des éléments assez complexes aujourd'hui, avec des éléments tels que .NET Framework, par exemple. Créer une interface visuelle ou trier une liste peut être fait avec très peu de commandes maintenant.

Lorsque j'apprenais à programmer, j'apprenais aussi la théorie de l'informatique en parallèle. Des choses comme les algorithmes de tri, les principes de fonctionnement matériel, l'algèbre booléenne et les machines à états finis. Mais j’ai remarqué que si j’ai toujours voulu tester un principe de base que j’avais appris en théorie, c’était toujours beaucoup plus difficile à démarrer car beaucoup de technologies sont masquées par des éléments tels que les bibliothèques, les frameworks et le système d’exploitation.

Créer un programme économe en mémoire était nécessaire il y a 40/50 ans, car il manquait de mémoire et coûtait cher. La plupart des programmeurs ont donc porté une attention particulière aux types de données et à la manière dont le processeur traiterait les instructions. De nos jours, certains pourraient soutenir qu'en raison de la puissance de traitement accrue et de la mémoire disponible, ces préoccupations ne sont pas une priorité.

Ma question est de savoir si les anciens programmeurs voient des innovations comme celles-ci comme une aubaine ou une couche supplémentaire à travers laquelle faire abstraction, et pourquoi pourraient-ils le penser? Et les jeunes programmeurs bénéficient-ils davantage d’apprentissage de la programmation de bas niveau AVANT d’explorer les royaumes de bibliothèques volumineuses? Si oui, alors pourquoi?

cela n’est tout simplement pas nécessaire en raison de l’augmentation de la puissance de traitement et de la mémoire disponibles.

Avoir de la mémoire bon marché, des disques énormes et des processeurs rapides n'est pas la seule chose qui a libéré les utilisateurs de la nécessité de devenir obsédés par chaque octet et chaque cycle. Les compilateurs sont maintenant beaucoup, beaucoup mieux que les humains pour produire du code hautement optimisé quand il le faut.

De plus, n'oublions pas ce que nous essayons d'optimiser, à savoir la valeur produite pour un coût donné. Les programmeurs sont beaucoup plus chers que les machines. Tout ce que nous faisons pour que les programmeurs produisent des programmes opérationnels, corrects, robustes et complets, plus rapidement et à moindre coût, conduit à la création de plus de valeur dans le monde.

Ma question est cependant de savoir ce que les gens pensent de cette "dissimulation" d’éléments de niveau inférieur. Les anciens programmeurs le voyez-vous comme une aubaine ou une couche inutile à traverser?

Il est absolument nécessaire de faire tout travail. J'écris des analyseurs de code pour gagner ma vie; Si je devais me soucier de l'allocation de registre ou de la planification du processeur ou de l'un de ces millions d'autres détails, je ne passerais pas mon temps à corriger des bogues, à examiner des rapports de performances, à ajouter des fonctionnalités, etc.

Toute la programmation consiste à extraire la couche en dessous de vous pour en faire une couche plus précieuse. Si vous faites un "diagramme de gâteau de couches" montrant tous les sous-systèmes et la manière dont ils sont construits les uns sur les autres, vous constaterez qu'il existe littéralement des dizaines de couches entre le matériel et l'expérience utilisateur. Je pense que dans le diagramme de gâteau de la couche Windows, il existe environ 60 niveaux de sous-systèmes nécessaires entre le matériel brut et la capacité à exécuter "hello world" en C #.

Pensez-vous que les jeunes programmeurs bénéficieraient davantage d’apprentissage de la programmation de bas niveau AVANT d’explorer les royaumes de bibliothèques volumineuses?

Vous mettez l'accent sur AVANT, je dois donc répondre à votre question par la négative. J'aide un ami de 12 ans à apprendre à programmer dès maintenant et vous feriez mieux de croire que je les lance dans Processing.js et non dans l'assembleur x86. Si vous démarrez un jeune programmeur dans quelque chose comme cela, Processing.jsils écriront leurs propres jeux de shoot-em-up dans environ huit heures. Si vous les démarrez dans assembleur, ils multiplieront trois nombres en huit heures environ. Selon vous, lequel est le plus susceptible de susciter l’intérêt d’un jeune programmeur?

Maintenant, si la question est "les programmeurs qui comprennent la couche n du gâteau bénéficient-ils de la compréhension de la couche n-1?" la réponse est oui, mais cela est indépendant de l'âge ou de l'expérience; Dans tous les cas, vous pouvez améliorer votre programmation de niveau supérieur en comprenant mieux les abstractions sous-jacentes.

J'avais des idées à ce sujet et je les ai mises dans un livre il y a 20 ans . Cela fait longtemps que le texte n'est plus disponible, mais vous pouvez toujours en obtenir des copies sur Amazon .

Une réponse simple à votre question est aussi ancienne qu'Aristote: la nature a horreur du vide . Même si les machines sont devenues plus rapides et plus grandes, les logiciels sont devenus plus lents et plus longs.

Pour être plus constructif, je proposais que la théorie de l’information, et son intérêt direct pour les logiciels, fassent partie de la formation en informatique. Cela n'est enseigné que maintenant, voire pas du tout, de manière très tangentielle.

Par exemple, le comportement big-O des algorithmes peut être parfaitement compris de manière intuitive si vous considérez un programme comme un canal d’information de type Shannon, avec symboles de saisie, symboles de sortie, bruit, redondance et bande passante.

D'autre part, la productivité d'un programmeur peut être comprise dans des termes similaires en utilisant la théorie de l'information de Kolmogorov. L'entrée est une structure conceptuelle symbolique dans votre tête et la sortie est le texte du programme qui sort du bout des doigts. Le processus de programmation est le canal entre les deux. Lorsque le bruit entre dans le processus, il crée des programmes incohérents (bugs). Si le texte du programme en sortie présente une redondance suffisante, il peut permettre de détecter et de corriger les bogues (détection et correction d'erreur). Cependant, s'il est trop redondant, il est trop volumineux et sa taille même, combinée au taux d'erreur, provoque l'introduction de bogues. À la suite de ce raisonnement, j'ai passé une bonne partie du livre à montrer comment traiter la programmation comme un processus de conception de langage., dans le but de pouvoir définir les langues spécifiques à un domaine appropriées à un besoin. Nous ne prêtons pas beaucoup d'attention aux langues spécifiques à un domaine dans l'éducation CS, mais encore une fois, c'est tangentiel.

La construction des langues est facile. Chaque fois que vous définissez une fonction, une classe ou une variable, vous ajoutez du vocabulaire à la langue avec laquelle vous avez commencé, créant ainsi une nouvelle langue avec laquelle travailler. Ce que l’on n’apprécie généralement pas, c’est que l’objectif devrait être de faire en sorte que le nouveau langage corresponde davantage à la structure conceptuelle du problème. Si cela est fait, cela aura pour effet de raccourcir le code et de le rendre moins complexe, simplement parce que, idéalement, il existe une correspondance 1-1 entre les concepts et le code. Si le mappage est 1-1, vous pouvez commettre une erreur et coder un concept de manière incorrecte en tant que concept différent, mais le programme ne plantera jamais, ce qui se produit lorsqu'il ne code aucune exigence cohérente .

Nous n'obtenons pas cela. Pour toutes nos discussions courageuses sur la conception de systèmes logiciels, le rapport entre le code et les exigences devient de plus en plus grand.

C'est vrai, nous avons des bibliothèques très utiles. Cependant, je pense que nous devrions être très circonspects sur l'abstraction. Nous ne devrions pas supposer que si B s'appuie sur A et que c'est bien, que si C s'appuie sur B, c'est encore mieux. Je l'appelle le phénomène de la princesse et du pois. Empiler des couches sur quelque chose de gênant ne résout pas nécessairement le problème.

Pour terminer un long post, j’ai développé un style de programmation (qui me pose parfois des problèmes) où

• L'invention n'est pas une mauvaise chose. C'est une bonne chose, comme c'est le cas dans d'autres branches de l'ingénierie. Bien sûr, cela peut créer une courbe d'apprentissage pour les autres, mais si le résultat global est une meilleure productivité, cela en vaut la peine.
• Code minimaliste de style haïku. Cela vaut particulièrement pour la conception de la structure de données. D'après mon expérience, le plus gros problème de logiciel de nos jours est la structure volumineuse des données.

Une abstraction de haut niveau est essentielle pour réaliser des progrès constants en informatique.

Pourquoi? Parce que les humains ne peuvent pas garder autant de connaissances dans leur tête à tout moment. Les systèmes modernes à grande échelle ne sont possibles qu’aujourd’hui parce que vous pouvez exploiter de telles abstractions. Sans ces abstractions, les systèmes logiciels s'effondreraient simplement sous leur propre poids.

Chaque fois que vous écrivez une méthode, vous créez une abstraction. Vous créez une fonctionnalité cachée derrière un appel de méthode. Pourquoi les écris-tu? Parce que vous pouvez tester la méthode, prouver que cela fonctionne, puis appeler cette fonctionnalité à tout moment en appelant simplement la méthode, sans avoir à vous soucier du code contenu dans cette méthode.

Au début de l'informatique, nous utilisions le langage machine. Nous avons écrit de très petits programmes nus avec une connaissance intime du matériel pour lequel nous les écrivions. C'était un processus laborieux. Il n'y avait pas de débogueurs; votre programme a généralement soit fonctionné, soit bloqué. Il n'y avait pas d'interface graphique; tout était en ligne de commande ou en batch. Le code que vous avez écrit ne fonctionnerait que sur cette machine particulière; cela ne fonctionnerait pas sur une machine avec un processeur ou un système d'exploitation différent.

Nous avons donc écrit des langages de haut niveau pour résumer tous ces détails. Nous avons créé des machines virtuelles afin que nos programmes puissent être portables sur d'autres machines. Nous avons créé un ramasse-miettes pour que les programmeurs ne soient pas obligés de faire preuve de la plus grande diligence dans la gestion de la mémoire, ce qui élimine toute une classe de bogues difficiles. Nous avons ajouté une vérification des limites à nos langues afin que les pirates informatiques ne puissent pas les exploiter avec des dépassements de mémoire tampon. Nous avons inventé la programmation fonctionnelle afin de pouvoir raisonner autrement sur nos programmes et nous l'avons redécouvert récemment pour mieux tirer parti de la concurrence.

Est-ce que toute cette abstraction vous isole du matériel? Bien sûr que si. Vivre dans une maison au lieu de planter une tente vous isole-t-il de la nature? Absolument. Mais tout le monde sait pourquoi ils vivent dans une maison plutôt que dans une tente, et construire une maison est un jeu de balle complètement différent de celui de planter une tente.

Cependant, vous pouvez toujours monter une tente quand il le faut, et en programmation, vous pouvez (si vous le souhaitez) descendre encore à un niveau plus proche du matériel pour obtenir des avantages en termes de performances ou de mémoire que vous ne pourriez peut-être pas. sinon atteindre dans votre langue de haut niveau.

Pouvez-vous trop résumer? "Dépasser la plomberie", comme dirait Scotty ? Bien sûr vous pouvez. Écrire de bonnes API est difficile. Écrire de bonnes APIs qui intègrent correctement et intégralement le domaine du problème, de manière intuitive et découvrable, est encore plus difficile. S'empiler sur de nouvelles couches de logiciels n'est pas toujours la meilleure solution. Les modèles de conception logicielle ont, dans une certaine mesure, aggravé la situation, car des développeurs inexpérimentés les recherchent parfois lorsqu'un outil plus précis et plus allégé est plus approprié.

Une formation vraiment bonne implique les deux extrêmes, ainsi qu'un pont entre.

Côté bas niveau: comment un ordinateur exécute le code à partir de la base *, y compris la connaissance du langage d'assemblage et ce que fait un compilateur.

Du haut niveau: concepts généraux, par exemple utiliser des tableaux associatifs, des fermetures, etc. sans perdre de temps à se soucier de la façon dont cela fonctionne sous le capot.

À mon humble avis, tout le monde devrait avoir l'expérience des deux, y compris leurs inconvénients, et savoir comment passer des concepts de bas niveau aux concepts de haut niveau. Aimez les tableaux associatifs? Génial, essayez maintenant de les utiliser sur un processeur embarqué de 50 cent avec 1 Ko de RAM. Vous aimez écrire du code rapide en utilisant C? Parfait, vous avez maintenant trois semaines pour écrire une application Web; vous pouvez passer votre temps à gérer les structures de données et la gestion de la mémoire à l'aide de C, ou à consacrer votre temps à l'apprentissage d'un nouveau framework Web, puis à l'implémentation de l'application Web dans quelques jours.

Pour ce qui est de la complexité, je pense qu’il est trop facile de concevoir des systèmes complexes sans comprendre clairement le coût . En conséquence, notre société a accumulé une énorme dette technique qui nous pique de temps en temps. C'est comme les tremblements de terre (juste le coût de la vie près d'une faille géologique, n'est-ce pas?), Sauf que ça empire progressivement. Et je ne sais pas quoi faire à ce sujet. Idéalement, nous apprendrions et maîtriserions mieux la complexité, mais je ne pense pas que cela se produira. Une formation en ingénierie responsable doit inclure beaucoup plus de discussions sur les conséquences de la complexité que la plupart de nos universités ne proposent actuellement.

* et, de toute façon, où est le "sol" dans la façon dont un ordinateur exécute le code? Est-ce le langage d'assemblage? Ou architecture informatique? Ou la logique numérique? Ou des transistors? Ou physique de l'appareil?

Je pense que la programmation de haut niveau présente de nombreux avantages et constitue un élément essentiel d'un langage de programmation. L'une des raisons du succès de Java réside dans le fait qu'il dispose d'une bibliothèque complète. Vous réalisez plus avec moins de code - appelez simplement une fonction prédéfinie.

Nous pouvons maintenant distinguer les utilisateurs de langage de programmation des auteurs de langage de programmation (auteurs de compilateur). Nous laissons les optimisations aux auteurs du compilateur. Nous nous concentrons davantage sur la maintenabilité, la réutilisation, etc.

L'augmentation de la complexité des systèmes est implacable, oppressante et finalement paralysante. Pour moi, en tant que programmeur de génération plus âgée, cela est également extrêmement décevant.

Je programme depuis plus de 40 ans, ayant écrit du code dans 50 à 100 langues ou dialectes différents et devenu expert en 5 à 10. La raison pour laquelle je peux en dire autant, c'est que la plupart du temps, ils ne sont que le même langage, avec quelques ajustements. Les ajustements ajoutent de la complexité, rendant chaque langue un peu différente.

J'ai implémenté les mêmes algorithmes d'innombrables fois: collections, conversions, tri et recherche, encodage / décodage, format / analyse, mémoires tampons et chaînes, arithmétique, mémoire, E / S. Chaque nouvelle implémentation ajoute de la complexité, car chacune est un peu différente.

Je me pose des questions sur la magie des artistes du trapèze volant des frameworks Web et des applications mobiles, sur la façon dont ils peuvent produire quelque chose d'aussi beau en si peu de temps. Ensuite, je me rends compte à quel point ils ne savent pas, à quel point ils auront besoin d’être renseignés sur les données, les communications, les tests, les threads, etc.

J'ai appris mon métier à l'ère des langages de quatrième génération, où nous croyions sincèrement que nous produirions une succession de langages de plus en plus élevés pour capturer progressivement de plus en plus de parties répétitives de logiciels d'écriture. Alors, comment cela s'est-il avéré, exactement?

Microsoft et IBM ont éliminé cette idée en revenant au C pour écrire des applications pour Windows et OS / 2, tandis que dBase / Foxpro et même Delphi se morfondaient. Ensuite, le Web a recommencé avec son trio ultime de langages d'assemblage: HTML, CSS et JavaScript / DOM. Tout a été en descente à partir de là. Toujours plus de langues et plus de bibliothèques et plus de cadres et plus de complexité.

Nous savons que nous devrions le faire différemment. Nous connaissons CoffeeScript et Dart, Less et Sass, les modèles pour éviter d’écrire en HTML. Nous savons et nous le faisons quand même. Nous avons nos cadres, pleins d'abstractions qui fuient, et nous voyons les merveilles qui peuvent être faites par les quelques élus qui apprennent les incantations profanes, mais nous et nos programmes sommes pris au piège des décisions prises dans le passé. C'est trop compliqué de changer ou de recommencer.

Le résultat est que les choses qui devraient être faciles ne sont pas faciles, et les choses qui devraient être possibles sont presque impossibles à cause de leur complexité. Je peux estimer le coût des modifications nécessaires pour implémenter une nouvelle fonctionnalité dans une base de code établie et être confiant que tout ira bien. Je peux estimer, mais je ne peux pas le justifier ni l'expliquer. C'est trop compliqué.

En réponse à votre dernière question, je conseillerais vivement aux jeunes programmeurs de commencer aussi haut que possible, et de ne plonger que dans les couches inférieures, selon le besoin et le désir. Ma préférence va aux langues sans boucles, avec peu ou pas de branchement et avec un état explicite. Lisp et Haskell me viennent à l’esprit. En pratique, je finis toujours avec C # / Java, Ruby, Javascript, Python et SQL car c’est là que se trouvent les communautés.

Derniers mots: la complexité est l'ennemi ultime! Battez ça et la vie devient simple.

Ma question est cependant de savoir ce que les gens pensent de cette "dissimulation" d’éléments de niveau inférieur. Les anciens programmeurs le voyez-vous comme une aubaine ou une couche inutile à traverser?

Vraiment.

La superposition est nécessaire car sans cela, vous atteignez un point où votre système devient des spaghettis non maintenables. C'est également l'un des principes de la réutilisation: si le développeur d'une bibliothèque fait du bon travail, les utilisateurs ne devraient pas se soucier des détails de la mise en œuvre. La quantité de code en boîte que nous utilisons dans nos systèmes a augmenté par ordre de mangue par rapport à ce qu'elle était lorsque j'ai écrit mon premier programme il y a 35 ans. Cette croissance signifie que nous sommes capables de faire des choses plus puissantes avec le temps. C'est bon.

L'endroit où ça a été un problème pour moi est entièrement culturel. Ma moitié pragmatique comprend qu'il n'est plus possible de penser à chaque détail avant de pouvoir finir ce que je veux faire. (Le fait de vieillir n'aide pas non plus.) Ma moitié de barbare grisonnante a eu de la difficulté à abandonner de nombreuses années passées à avoir une compréhension aussi fine de tout ce sur quoi j'ai travaillé.

Pensez-vous que les jeunes programmeurs bénéficieraient davantage d’apprentissage de la programmation de bas niveau AVANT d’explorer les royaumes de bibliothèques volumineuses?

Comme cela a été souligné dans d'autres réponses, il convient de trouver un juste milieu pour attirer et retenir l'attention des néophytes et leur donner une éducation idéale, de bas en haut. Si vous ne pouvez pas faire le premier, le dernier ne peut pas arriver.

Je vois des choses dans notre industrie parallèles au reste de la société. Auparavant, presque tout le monde cultivait sa propre nourriture et y passait beaucoup de temps. Depuis lors, nous avons formé des spécialistes appelés agriculteurs qui exercent ce métier, ce qui a permis aux autres de faire d'autres choses qui contribuent à la société. J'achète ma nourriture dans une épicerie et je serais absolument incapable d'en produire moi-même la majeure partie si je devais le faire. Nous faisons la même chose, mais sur une échelle de temps beaucoup plus comprimée. Les programmeurs se spécialisent dans certains ensembles de couches et pas d’autres. Le gars moyen qui écrit des interfaces graphiques peut savoir qu’il existe un espace d’échange mais ne sait probablement pas ou se soucie peu de la façon dont le système d’exploitation le gère.

Le résultat de tout cela est qu'il ne s'agit plus uniquement de développement. La poursuite de la spécialisation signifie que les développeurs devront continuer à améliorer leurs compétences en communication et en intégration.

Comme pour tout, un peu vous fait du bien, mais trop mal. Le problème est que trop de systèmes ne savent pas quand s’arrêter - une seule abstraction supplémentaire pour vous aider à programmer plus rapidement ... mais vous finissez par coder dans le monde réel où les choses ne sont jamais aussi simples que vous le souhaitez, et vous passez plus de temps à travailler que si vous aviez une abstraction moins en vedette.

C'est habilement décrit ici

ou ici - "avec une seule ligne de code, vous pouvez ajouter 500 utilisateurs au domaine" ...

Vos abstractions essaient de vous cacher la complexité, mais elles ne font que masquer cette complexité. La complexité est toujours présente, mais vous avez beaucoup moins de contrôle sur elle, et c'est pourquoi vous vous retrouvez dans ce genre de situation.

Les jeunes programmeurs bénéficient-ils davantage de l'apprentissage de la programmation de bas niveau AVANT d'explorer les domaines de bibliothèques volumineuses? Si oui, alors pourquoi?

Je ne pense pas. Il y a encore beaucoup de situations dans lesquelles il est avantageux de savoir que le «calque inférieur» fonctionne, par exemple:

• Lors du débogage d'un problème sur une couche n, cela peut souvent être expliqué en considérant ce qui se passe sur la couche n-1(c'est-à-dire la couche en dessous). Je suppose que la couche 0 serait "des transistors" mais si vous voulez expliquer un problème avec les transistors, vous parlerez probablement de physique (par exemple de la chaleur), alors peut-être que la physique est vraiment au niveau 0.

• Lors de l'optimisation du code, il est malheureusement (parfois) utile d'abaisser le niveau d'abstraction, c'est-à-dire de mettre en œuvre un algorithme en termes de couche de niveau inférieur. Cependant, les compilateurs sont devenus très doués pour le faire pour vous s'ils voient en réalité tout le code impliqué. Cette raison est devenue plus populaire récemment avec l'essor des appareils mobiles et embarqués, qui ont tendance à avoir des processeurs plus faibles et où "la performance par Watt" est beaucoup plus pertinente que sur les systèmes de bureau, par exemple.

Cependant, en général, il est devenu beaucoup plus facile de faire fonctionner des ordinateurs (même de manière légèrement inefficace), ce qui signifie qu'il y a beaucoup plus de programmeurs qu'auparavant. Cela a à son tour rendu le facteur "humain" beaucoup plus important: la réponse de Robert Harvey mentionnait déjà que "les humains ne peuvent pas garder autant de connaissances dans leur tête à tout moment", et je pense que c'est un aspect très pertinent de nos jours.

Une des principales motivations de la conception des langages de programmation et des bibliothèques (API) est de faciliter les choses pour le cerveau humain. À ce jour, tout est encore compilé en code machine. Cependant, il n’ya pas que des erreurs, il est également difficile à comprendre. Donc, il est très souhaitable de

• Demandez à l'ordinateur de vous aider à trouver des erreurs logiques dans les programmes que vous écrivez. Des choses comme les systèmes de types statiques ou les analyseurs de code source ( Eric Lippert travaille sur un système assez populaire de nos jours) m'aident à résoudre ce problème.

• Ayez un langage qui puisse être traité efficacement par un compilateur et qui communique l' intention du programmeur à d'autres programmeurs pour faciliter le travail sur le programme. En tant qu’extrême absurde, imaginez que l’écriture de programmes en anglais simple soit possible. Les autres programmeurs auraient peut-être plus de facilité à imaginer ce qui se passait, mais il serait quand même difficile de compiler la description en instructeurs de machine, ce qui est notoirement ambigu. Vous avez donc besoin d'un langage qu'un compilateur peut comprendre mais qui soit également compréhensible.

Étant donné qu'un grand nombre de compilateurs (la plupart?) Sont encore très polyvalents, ils disposent d'un jeu d'instructions très générique. Il n'y a pas d'instruction "dessiner un bouton" ou "lire ce film". Par conséquent, en descendant dans la hiérarchie d'abstraction, vous vous retrouvez avec des programmes très difficiles à comprendre et à maintenir (bien que triviaux à compiler). La seule alternative est de monter dans la hiérarchie, ce qui conduit à un nombre croissant de langages et de bibliothèques abstraits.

"Si les programmeurs plus âgés voient des innovations comme celles-ci comme une aubaine ou une couche supplémentaire à travers laquelle faire abstraction, et pourquoi pourraient-ils le penser?"

Je programme depuis que je suis au lycée, environ 34 ans, en commençant par Basic et Z80 Assembler, puis en C, en différents langages 4GL, Scheme, SQL et maintenant en différents langages Web. La portée, l’ampleur et la profondeur des problèmes abordés par la profession ont connu une période inflationniste au cours de cette période, en particulier dans les années 90. Les constructions telles que les bibliothèques, les frameworks et les services de système d’exploitation sont toutes des agencements destinés à traiter la complexité qui accompagne l’élargissement de l’espace des problèmes. Ils ne représentent ni une aubaine ni un fardeau, mais une exploration continue d’un vaste espace de solutions.

Mais, à mon humble avis, l '"innovation" est mieux comprise en termes de formes novatrices et ne doit pas être confondue avec un mouvement latéral - réintroduisant des formes déjà introduites. D'une certaine manière, la fécondité d'un écosystème souffre du fait que les formes primitives ne se composent pas, lorsqu'elles fixent les décisions prises au début de l'évolution ou ne peuvent pas retraiter leurs propres détritus. Certains des concepts, sinon la plupart, sur lesquels nous restons concentrés ne donnent pas la priorité à la subsistance à long terme de la valeur en tant que préoccupation. Cela a commencé à changer - des approches telles que l'orientation par les services et la conception par domaine, sans parler des modèles hypertextes et graphiques, modifient par exemple le paysage. Comme tout écosystème, les formes dominantes finiront par céder la place à de nouvelles formes; nous sommes mieux servis en permettant la diversité,

"Et les jeunes programmeurs bénéficient-ils davantage de l'apprentissage de la programmation de bas niveau AVANT d'explorer les domaines de bibliothèques volumineuses? Si oui, pourquoi?"

Je dirais que la plupart des langages humains sont basés sur des métaphores depuis longtemps oubliées. Par conséquent, bien que je sois favorable à l’apprentissage de la programmation de bas niveau du point de vue de la littératie scientifique / numérique, il est plus important de rechercher des primitifs compatibles avec l’ampleur et la portée de la programmation. les problèmes que nous abordons d'une manière que nous pouvons ignorer en toute sécurité le niveau de détail inférieur. Un framework n'est pas une primitive, pas plus qu'un système d'exploitation ou une bibliothèque - ils sont assez pauvres pour faire le genre d'abstraction dont nous avons vraiment besoin. Les progrès réels nécessiteront des personnes qui (a) savent ce qui a été fait auparavant et (b) peuvent penser de manière suffisamment novatrice pour proposer quelque chose de suffisamment différent pour explorer un espace de solution jamais exploré auparavant ou ayant été exploré et oublié.

OTOH, même si votre objectif est de travailler en tant que technicien / mécanicien, une certaine exposition à la programmation de bas niveau restera utile pour développer vos compétences en résolution de problèmes.

Mon premier programme (adolescent âgé de 15 ans) était en 1974 en PL / 1 sur des cartes perforées pour un ordinateur central IBM 370/168. Mon père travaillait chez IBM et j'ai eu la chance de pouvoir aller au centre de données le dimanche.

A cette époque, un programme de plusieurs milliers de relevés (cartes perforées) était un programme important (et lourd également, car plusieurs milliers de cartes perforées pesaient plusieurs kilogrammes). Les interfaces visuelles n'existaient pas (un programme typique lu depuis son "entrée standard" en utilisant une commande de carte perforée commençant par //GO.SYSIN DD *IIRC, mais je ne maîtrisais pas JCL ). L'algorithmique était importante, et la bibliothèque standard du IIRC était assez petite par rapport au standard actuel.

Aujourd'hui, les programmes de plusieurs milliers de lignes sont généralement considérés comme petits. Par exemple, le compilateur GCC a plus de dix millions de lignes de code source et personne ne les comprend parfaitement.

Mon sentiment est que la programmation d'aujourd'hui est assez différente de celle des années 1970, car vous devez utiliser beaucoup plus de ressources (en particulier les bibliothèques existantes et les frameworks logiciels). Cependant, je suppose que les développeurs de logiciels de centre de données (tels que les moteurs de recherche de Google) ou de certains logiciels embarqués s'intéressent autant aux algorithmes et à l’efficacité que le programmeur moyen des années 70.

Je pense toujours que la compréhension de la programmation de bas niveau est importante même de nos jours (même si la plupart des programmeurs ne se codent pas eux-mêmes des algorithmes de conteneur de base tels que des arbres équilibrés, des tableaux triés accédés de manière dichotomique, etc.), car comprendre l’ensemble est toujours important.

Une différence majeure entre les années 1970 et aujourd’hui est le rapport entre le coût des efforts (humains) du développeur et la puissance de l’ordinateur.