Sommaire
Le boulot des développeurs change constamment et pourtant l'histoire me semble se répéter. Dis-moi si toi aussi tu vois une constante émerger des outils qui suivent.
Assembleur
Connais-tu ce merveilleux langage qu'est l'assembleur ? C'est le premier langage de programmation. En assembleur il n'y a pas de type de donnée, ni même de code en fait. Tout n'est qu'octet, et encore si l'architecture utilise des octets.
L'assembleur c'est pénible. On ne comprend rien, toute l'information est dupliquée dans des commentaires et le pauvre qui doit déboguer tout ça se retrouve avec deux tâches : comprendre ce qu'expliquent les commentaires et voir si le code correspond. De quoi s'arracher les cheveux.
Bien sûr le fait qu'il soit spécifique à une architecture ainsi qu'infernal à écrire et à lire n'empêche pas de faire de grandes choses en assembleur. Après tout c'est le langage à l'origine de tous les logiciels, et même aujourd'hui on l'utilise encore pour tirer de meilleures performances du matériel, comparé à ce que le compilateur aurait généré. Cependant les développeurs expérimentés lui préféreront un langage de plus haut niveau.
BASIC
Connais-tu les options Strict et Explicit de ce merveilleux langage qu'est Visual Basic ?
Le BASIC est un langage de programmation pour débutant. Il abstrait beaucoup de choses de la machine et permet à n'importe quel ignorant d'écrire un programme, ce qui est une bonne chose. Comme il se veut facile d'accès il est très laxe sur les déclarations de variables et le typage. Si un identifiant inconnu est utilisé dans une expression, pouf ! ça devient une variable et le compilateur devine son type.
Bien sûr le fait qu'il soit destiné à des débutants n'empêche pas la création de grands programmes dans ce langage. Des programmes écrits dans un cadre PROfessionnel (insister sur le « pro ») par des vrais PROs (idem) qui font du business (à nouveau), pas de misérables amateurs (prendre un ton dégradant). Malheureusement ce laxisme n'est pas gratuit et à force d'empiler des trucs approximatifs qui ont l'air de marcher on fini avec un tout qui s'écroule.
C'est à ce moment que le dev perd ses cheveux à essayer de comprendre ce qu'il se passe dans ce programme, traquant les variables et les types comme s'il était le compilateur. Mais on ne pourrait déclarer ça une bonne fois pour toute et demander au compilateur de valider ça ? Se demande-t-il. Oui on le peut en Visual Basic, grâce aux options Strict et Explicit. Deux options qui vont demander un peu plus de rigueur au dev et permettre d'économiser des heures de problèmes en maintenance.
Perl
Connais-tu les options use strict et use warnings de ce merveilleux langage qu'est Perl ?
Perl est un langage de script qui, comme beaucoup d'autres dans son genre, est très laxiste. Contrairement au BASIC il n'est pas facile d'accès. Il se réclame d'une syntaxe concise, donc cryptique, et ne voit pas d'inconvénient à laisser des pièges béants pour le développeur :
It looks like a function, therefore it is a function, and precedence doesn't matter. Otherwise it's a list operator or unary operator, and precedence does matter.
There is no rule that relates the behavior of an expression in list context to its behavior in scalar context, or vice versa. It might do two totally different things.
Tu ne vas sans doute pas me croire mais même un langage aussi approximatif a ses adeptes.
Comme pour le BASIC et nombre de langages de script, Perl va vous laisser utiliser des variables sorties de nulle part et additionner des pommes avec des bananes. Comme pour le BASIC celui qui devra déboguer cela est bon pour une calvitie précoce. C'est pourquoi un développeur Perl expérimenté n'hésitera pas à commencer ses scripts avec use strict et use warnings pour se libérer des problèmes les plus élémentaires tels qu'une typo dans l'utilisation d'une variable causant la création silencieuse d'une nouvelle variable.
Bash
Connais-tu les options -e -u -o pipefail de ce merveilleux langage qu'est Bash ?
Bash est un interpréteur de lignes de commande de type script. C'est un langage de programmation qui fait très bien ce qu'il doit faire même si on se demande si on a bien fait de lui demander.
Comme nombre d'outils dans son genre Bash est terriblement laxiste et va volontiers exécuter n'importe quoi, remplacer des variables inconnues par rien, et continuer à s'exécuter alors même que tout finit en erreur tandis que l'utilisateur bourrine ctrl+C dans une tentative désespérée de réduire la casse.
Le développeur Bash expérimenté (existe-t-il quelqu'un qui se revendique « développeur Bash » ?) tentera de contrôler ces problèmes en commençant ses scripts par un set -euo pipefail, trois options signifiant respectivement qu'il faut s'arrêter à la première erreur (-e), interdire le remplacement de variables sans valeur (-u) et considérer une erreur dans un pipe comme une erreur (-o pipefail).
Sans doute penses-tu que ce mode strict de Bash reste bien fragile, et tu as bien raison. Programmer en Bash est aussi rassurant que de jongler avec des tronçonneuses enflammées en marche. Cela n'empêche pas de construire de gros programmes dans ce langage, ni même de l'utiliser comme méthode d'installation d'un programme à coup de curl -s https://random-script-from-the-web.sh | sh.
JavaScript
Connais-tu l'instruction "use strict" (avec les guillemets) de ce merveilleux langage qu'est JavaScript ?
JavaScript est un langage de script destiné à être utilisé dans les navigateurs web. On peut par exemple s'en servir pour afficher une traînée d'étincelles qui suivent le curseur. C'est un langage extrêmement laxiste et proposant un très faible coût d'entrée. Si tu as un navigateur web tu as un environnement de développement JavaScript.
Sa facilité d'accès a permis à bon nombre d'entre nous d'accéder au monde de la programmation peut-être même sans le savoir. Comme Bash, Perl et BASIC avant lui, JavaScript a opté pour la facilité d'accès en permettant la création de variables silencieusement à la volée dès lors qu'un nouvel identifiant apparaît. Comme pour Bash, Perl et BASIC, les développeurs en ont eu ras-le-bol de chercher des bugs liés à des typos dans les noms de variables. C'est pourquoi ECMAScript 5 a introduit le mode strict, optionnel bien sûr.
On retiendra cette description sur le site w3schools :
Strict mode changes previously accepted "bad syntax" into real errors.
J'apprécie l'utilisation de guillemets autour de « bad syntax », comme si c'était subjectif. Qui t'es pour dire que la syntaxe est mauvaise ? C'est juste, genre, ton opinion mec.
Bien sûr le laxisme du langage n'empêche pas de construire de grandes choses. Longtemps réputé pour sa lenteur, la situation s'est grandement amélioré dans les années 2010 quand l'industrie s'est mise à tout faire en JavaScript. De gros efforts ont ainsi été faits sur les machines virtuelles JavaScript pour passer de performances terriblement mauvaises à des performances sacrément décevantes.
Qu'à cela ne tienne, ce n'est pas parce que le langage est bancal et inefficace qu'il ne faut pas l'utiliser ! Tel l'élève médiocre pointant le cancre du doigt, l'industrie s'est dit que ça va, ça pourrait être pire, et a continué d'investir le gros de ses ressources dans cette voix. C'est pourquoi nous sommes passés d'étincelles derrière le curseur à des applications web puis à des applications desktop qui embarquent un navigateur entier, ainsi qu'à des applications serveur. Ce langage adresse tous les systèmes de manière égale. À moins que ce soit égal-égal ? Ou égal-égal-égal ?
Python
Savais-tu qu'il n'y avait pas de mode strict dans ce merveilleux langage qu'est Python ?
Python est un langage de programmation interprété initialement développé pour l'enseignement de la programmation aux débutants. Il se veut facile d'accès et a le bon goût d'insister sur la lisibilité du code notamment en revendiquant une seule façon de faire chaque chose.
Python est beaucoup plus strict que les langages cités précédemment, pas d'addition de pommes avec des bananes ici. Cependant, bien qu'il applique un typage fort, il pratique aussi le typage dynamique, c'est à dire qu'il déduit le type des données lorsqu'elles sont utilisées ce qui procure une certaine souplesse. En particulier, Python est certainement le plus populaire des langages pratiquant le Duck typing.
Bien sûr cette souplesse n'empêche pas de construire de grandes choses, et à force d'empiler des trucs qui ont l'air de marcher on se retrouve à déboguer des exceptions et d'autres trucs obscurs parce que quelque part quelque chose a été appelé avec une donnée d'un mauvais type. Par exemple, savais-tu que Python te laissera écrire un appel à une fonction en lui passant un nombre incorrect de paramètres ? Tant que l'exécution ne passe pas par cet appel, tout va bien, mais dès lors qu'on passe par cet appel, paf ! C'est la fin.
J'ai longtemps trouvé que l'ambiance au sein de la communauté Python s'apparentait à une secte, une sorte un culte qui se veut au-dessus du reste et qui peine à envisager d'être dans l'erreur malgré les critiques. Par exemple, il était pendant longtemps hors de question de typer les données. Trop restrictif. Heureusement la situation semble s'être améliorée et on a vu apparaître des choses comme PEP 484 pour introduire un peu de rigueur de typage.
C++
Connais-tu le C++ ? C'est un langage compilé, fortement et statiquement typé. Ça sent la rigueur non ?
Le langage C++ a été créé il y a plus de 40 ans par un chercheur en informatique qui s'est dit un jour que ça serait cool d'avoir une sorte de langage C mais orienté objet. Il a posé une syntaxe ambiguë et pour une raison que j'ignore l'industrie a adopté son langage. Bien sûr le langage a évolué et s'est adapté aux époques tant et si bien qu'il est aujourd'hui connu pour permettre de faire chaque chose de dix façons différentes, toutes mauvaises.
Le langage est connu pour faciliter les problèmes de mémoire : fuites, accès hors bornes, il est très facile de créer ce genre de problème. Et comme il s'agit d'un langage pour créer des binaires natifs, ces problèmes de mémoire deviennent des problèmes de sécurité.
Pendant la conception de la version C++11 du langage, le commité définissant ses règles rencontre un problème pour typer les closures et introduit le type auto pour laisser le compilateur déduire le type. Dès lors, les programmeurs frustrés depuis toujours de devoir expliciter leurs intentions au compilateur s'engouffrent dans la brèche et décident de mettre auto partout, avec des raisonnements tels que : si on dit que auto veut dire let ou var alors ça ressemble à un langage moderne, hein ? Bah répondez, quoi !
Dans la foulée, des pontes du langage reconnus pour leur niveau technique poussent à leur tour pour mettre auto partout, avec des arguments en béton tels que : si je déclare toutes mes variables avec auto elles sont bien alignées dans mon éditeur. C'est joli hein ? Bah répondez, quoi !
Les versions suivantes du langage suivent la même tendance. On veut que le langage soit différent. Pas mieux. Différent. Si possible semblable à des langages plus récents mais pas trop pareil non plus. On introduit des concepts tels que les ranges parce que ça a l'air cool et ça permet d'alimenter les conférences de consultants expliquant à quel point rien ne marche comme on veut avec cet outil.
Plus récemment il est question de traiter les problèmes de sécurité liés au laxisme sur les accès mémoire. Il faut dire que l'aura de Rust, quelque part successeur du C++ et qui gère magistralement le problème, pèse sur ce vieux langage. Mais comme la tendance est à ne pas casser l'existant on est bien parti pour avoir une version safe du C++ qui ne fonctionne pas vraiment. Le C++ est malheureusement un langage qui souhaite évoluer dans un espace où il ne peut plus grandir.
Cela dit ce n'est pas parce que le langage est mal fichu, bancal, plein d'ambiguïtés, et spécifié par des gens qui codent à peine, qu'on ne peut pas créer de grandes choses avec. C'est pourquoi les développeurs C++ se retrouvent aujourd'hui à perdre leurs cheveux en déboguant du code où l'auteur initial a refusé de dire quels types de donnée sont manipulés. C'est générique man, ça peut être tout et n'importe quoi du moment que ça respecte les contraintes implicites de l'implémentation, c'est cool non ? Bon ça ne marche que pour des int mais c'est cool hein ? Bah répondez, quoi !
Rust
Connais-tu le langage Rust ? C'est un langage ciblant le même domaine que le C++, sans les problèmes.
Le langage Rust corrige quasiment tous les problèmes mémoire du C++. Vraiment, si on vient du C++ on voit dès les premières lignes que les créateurs de Rust ont bien compris le problème, et le borrow checker devient une bénédiction.
Cependant on sait à quel point les développeurs ne veulent pas s'engager sur le type des données. Tous les langages modernes laissent le compilateur déduire les types à partir des expressions. C'est tellement beau sur le plan conceptuel. Quand on dit qu'on laisse le compilateur déduire les types, ça veut aussi dire qu'on laisse le relecteur déduire les types. Le relecteur est-il aussi à l'aise que le compilo pour cela ? Ha ! Ha ! Certainement pas ! Tant pis pour lui !
Pendant trop longtemps la culture autour de ce langage était polluée par des adeptes dignes des plus grandes sectes de l'histoire, toujours prêts à partir en croisade et faire du zèle pour éclairer, éduquer, l'ignorant. Il me semble que la situation s'est grandement améliorée.
Rust n'a que 15 ans, c'est un ado. Et encore, la version 1.0 du langage n'en a que 10. On est très loin d'avoir du recul sur ce langage mais c'est de loin le plus prometteur de ces dernières années. Cela signifie en particulier qu'il n'y a pas de développeur expérimenté en Rust ! On peut donc s'attendre à ce que tous les devs de ce langage aient encore leurs cheveux (enfin ceux qu'ils n'ont pas perdus avec les langages précédents). Cependant, mon petit doigt me dit qu'ils ne vont pas rigoler longtemps quand il faudra déboguer du code où une variable est déclarée sans type et que celui-ci est déduit des dizaines de lignes plus bas via une expression obscure :) Bientôt un mode strict en Rust ?
L'IA agentique
Connais-tu l'IA agentique ? C'est une mode de développement consistant à concevoir des programmes en donnant des instructions à des IAs, puis à les laisser se débrouiller pour pondre un truc.
Un des gros soucis de tout éditeur logiciel est que le dev est lent (ça prend plus que zéro secondes) et cher (ça coûte plus que zéro euro). Comprends bien que pour faire des dollars aujourd'hui il faut être le premier sur le marché, et une fois que tu as le marché il faut réduire les coûts pour faire du bénef'. Encore récemment un des moyens d'adresser ces problèmes était de délocaliser. On prend quelques manageurs de nos pays riches et on leur fait superviser des devs d'un pays pauvre qui vont nous sortir du code pour pas cher.
Depuis peu on peut faire la même chose sans avoir à s'embêter à délocaliser ! Les outils d'IA sont excellents pour produire des choses. Pose une question à un chatbot, hop tu as une réponse exposée avec l'assurance d'un expert. Parfois même, la réponse est bonne. Ça fait quinze ans que tu t'éduques à coup de TL;DR et te voilà face à un document est un peu long ? Donne ça à une IA et elle te fera un résumé. Parfois même, il sera pertinent.
J'écris tout ça sur un ton sarcastique mais clairement les outils d'IA ont de très bons côtés, abstraction faite des aspects éthiques et écologiques. Cela m'a aidé à plusieurs reprises pour trouver des informations sourcées que j'étais bien incapable de trouver sur le web. De là à leur laisser les tâches cognitives cependant, faut pas exagérer non plus.
Comme tu l'auras déduit au long de ce post, nous les devs somes de gros fainéants. Nous ne voulons pas coder, nous ne voulons pas documenter, nous ne voulons pas expliciter nos intentions, et nous ne voulons pas déboguer. C'est pourquoi je ne suis pas surpris de voir des devs s'enjouer d'avoir leur délocalisation à eux. On donne les specs et les agents se débrouillent pour pondre un truc. Et là où c'est génial en termes de business c'est que c'est encore moins cher que le tiers monde. Auparavant il fallait superviser les devs à l'étranger avec un manageur en local, et payer tout le monde. Maintenant on paye pas cher pour avoir des agents IA, et le manageur est un dev, payé au prix d'un dev. Manageurs d'une armée de stagiaires, quel devs n'a pas rêvé de ça ?
Au final le développeur consciencieux n'a plus qu'à faire la revue de code et valider. Quiconque a pratiqué la revue de code sait que c'est loin d'être suffisant pour comprendre ce qu'il se passe, et quiconque a déjà programmé sait qu'il est deux fois plus difficile de déboguer du code que de l'écrire ; alors quand tu ne l'as même pas écrit… Et puis OSEF après tout, S'il y a besoin de comprendre ce qu'il se passe il suffira de demander à l'IA. Soyons positifs, il n'y a pas de raison que ça pose des problèmes. Toute technologie révolutionnaire a eu ses détracteurs après tout.
Cette méthode de développement est encore très jeune et on n'a pas de recul sur la qualité de la production, et vu la vitesse à laquelle celle-ci croît on ne peut qu'espérer qu'elle soit de qualité. Heureusement on peut s'inspirer de l'histoire de la programmation et constater que lorsqu'un outil a été fait pour accueillir des devs qui ne veulent rien avoir à faire avec le sujet, le résultat a plutôt été mauvais, au point que des contraintes ont dû être ajoutée a posteriori pour les empêcher de causer des problèmes. Et on peut se demander si l'industrie ne serait pas un peu con-con à recréer les mêmes problèmes encore et encore.
Et toi cher lecteur, as-tu connaissance d'un autre outil qui se voulait facile d'accès avant de rétropédaler en mettant des garde-fous avec une sorte de mode strict ? Ou au contraire d'outils très stricts qui se sont dégradés en voulant être plus accessibles ?
# La suite , la suite ...
Posté par chilinhualong . Évalué à 10 (+20/-0). Dernière modification le 05 février 2026 à 21:42.
Scheme / Lisp
Les langages qui te regardent droit dans l’âme en disant : « tout est une liste, fais-en quelque chose de beau ». Minimalistes, élégants… et capables de retourner ton cerveau avec trois parenthèses bien placées.
Fortran
Le vétéran increvable. Pas là pour faire joli, mais pour calculer plus vite que la lumière. Si ton code fait décoller une fusée ou simule un trou noir, il y a de grandes chances que Fortran soit dans le coin.
COBOL
Le dinosaure qui refuse de mourir. Verbeux, sérieux, mais toujours en train de faire tourner banques et administrations pendant que les autres langages vont et viennent. Respect éternel.
Pascal
Le prof sympa mais strict. Il t’apprend à bien penser avant de coder, à structurer proprement, à respecter les règles. Pas le plus fun du groupe, mais clairement celui qui t’a donné de bonnes manières… et dont l’ombre plane encore sur pas mal de langages modernes.
[^] # Re: La suite , la suite ...
Posté par Julien Jorge (site web personnel) . Évalué à 5 (+3/-0).
Nobles langages que tu listes ici :) Pas sûr que l'un d'eux ait subit le syndrome du mode strict ajouté tardivement, si ?
[^] # Re: La suite , la suite ...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 9 (+6/-0).
Il y avait d'autres problèmes à l'époque. Pour Pascal, en particulier, il n'y avait au départ ps de linker, tout le programme devait donc tenir dans un seul fichier. Cela a été corrigé par Modula et Modula 2, mais comme les développeurs n'aiment pas apprendre un nouveau langage, la notion d'unités de compilation (des modules, mais pas vraiment) a été ajoutée par exemple dans Turbo Pascal.
Sinon, si on veut du strict, on peut programmer en Ada. C'est un peu comme Rust: il y a un mode unsafe, et quand on s'en sert, on peut faire exploser une fusée de façon spectaculaire sous les yeux du président de la république.
[^] # Re: La suite , la suite ...
Posté par shuihuzhuan . Évalué à 4 (+3/-0).
Pour du strict, je mettrais encore plus Spark (un sous-ensemble d'Ada qui peut être prouvé, avec différents niveaux de preuve) qu'Ada 😀
[^] # Re: La suite , la suite ...
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 4 (+3/-0).
Historiquement, les modules (units) ont été introduits dans Pascal UCSD, donc bien avant Modula 2, et c'est ce qui a été repris dans Turbo Pascal 4.0 quelques années plus tard.
(Je me suis pas mal documenté sur Pascal et ses successeurs pour faire mon interpréteur PascalScript même si je bloque sur l'interprétation des appels de fonctions en ne sachant pas si c'est moi qui rate quelque chose ou si c'est ma structure de données qui est foireuse (et oui je veux bien un coup de main si ça intéresse une bonne âme ;-)))
[^] # Re: La suite , la suite ...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
La chronologie semble être:
Pascal (1970) -> Modula (1975) -> USCD Pascal (1977) -> Modula 2 (1978).
Et effectivement ce n'est arrivé dans Turbo Pascal que bien plus tard. J'imagine que cela contribue à la réputation de "jouet" du langage Pascal, qui pourtant a beaucoup évolué depuis ses toutes premières versions qui étaient effectivement assez limitées (le Pascal original par des fonctionalités manquantes, puis l'USCD Pascal par son approche avec un interpréteur p-Code, assez lent par rapport à l'exécution directe).
[^] # Re: La suite , la suite ...
Posté par Ant . Évalué à 3 (+2/-0). Dernière modification le 07 février 2026 à 00:37.
J'ai (un peu) développé avec MS Pascal entre 1985 et 1990 avec MS Pascal, qui était donc l'implémentation de Pascal ISO sur ms-dos.
Effectivement, il supportait les modules, et d'ailleurs tout état module si je puis dire. On compilait chacun des modules et le programme principal en ligne de commande dos, puis on lançait l'édition de liens, qui créait l'éxecutable final. C'était bien lent, plusieurs minutes même pour compiler un petit programme, car le compilateur se lançait depuis la disquette, puis accédait au code, sur la disquette également, et ainsi de suite. Et puis est arrivé Turbopascal, pas de modules mais des overlay, et une compilation en une seule passe en mémoire en quelques secondes, avec l'éditeur et compilateur intégré, ça a changé la vie.
Pascal est rigoureux et peut permissif dans la syntaxe : déclaration obligatoire des variables et pas de conversion de données implicite. Ce que j'aimais c'était les procédures imbriquées et le code était assez élégant à mon sens : une forme rigoureuse, pas d'expressions bizarre et pas des trucs qui tantôt traitaient des chiffres et tantôt des caractères. Le problème c'était surtout le peu de librairies disponibles, pas simples à utiliser, et le côté verbeux, long à coder.
[^] # Re: La suite , la suite ...
Posté par pamputt . Évalué à 7 (+5/-0).
En Fortran 77, on a quand même la possibilité de ne pas définir le type explicitement. Si la variable commence par un « i », un « j », un « k », un « m » ou un « n » alors c'est un entier, sinon c'est un flottant. Ca m'a fait perdre quelques cheveux en débogage…
[^] # Re: La suite , la suite ...
Posté par Nicolas (site web personnel) . Évalué à 8 (+8/-0).
Pour compléter, en Fortran moderne il est recommandé d’ajouter
Ou encore mieux :
Évidemment ce langage, avec Cobol, avait résolu les problèmes d’accès mémoire du C depuis très longtemps, mais la solution était trop simple (balle perdue destinée aux fanboys de Rust).
[^] # Re: La suite , la suite ...
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
à vrai dire les problèmes de mémoire du C étaient réglés avant même l'invention du C. C'est amusant (mais un peu déprimant) de lire les articles datant des années 60 et 70 où les développeurs LISP se plaignent déjà de l'attitude des programmeurs assembleur, et de voir qu'aujourd'hui, c'est Rust d'un côté et C de l'autre, mais qu'au fond, rien n'a changé.
[^] # Re: La suite , la suite ...
Posté par Christophe B. (site web personnel) . Évalué à 3 (+3/-2).
Après tout c'est Vendredi :
LISP : Désolé mais c'est pas facile à lire, peut être en s'aidant avec du LSD ou autre drogue psychédélique … c'est bien un truc d'étudiant
Fortan : calcule bien OK, c'est pas mal et pour le reste ?
COBOL : C'est surtout que les grosses institutions bancaires et autres ne veulent pas changer un truc qui fonctionnent car cela couterait trop cher a refaire. sinon il y a longtemps que ce langage verbeux et psycho rigide aurait disparu.
Pascal : OK cela donne de bonnes habitudes, c'est comme le vélo t'apprend les bases puis tu grandis et après tu utilises une moto ou une voiture :) pour aller plus loin
Assembleur : pendant quelques micro secondes tu as l'impression de dompter ton processeur comme tu le ferai avec un cheval … puis tu te fais éjecter et si remontes pas tout de suite sur la bête tu passes a autre chose
Basic : normalement fait pour apprendre, mais il y a tellement de basic avec tellement de syntaxes différentes que cela finit par perdre tout le monde
Perl : te donnes un grand pouvoir pour faire de grandes choses (si si …), six mois après tu essayes de te rappeler ce que tu as pu boire ou fumer pour écrire ces lignes
Bash : un langage pour sysadmin … pas pour les devs
Javascript : tout à fait d'accord "ce n'est pas parce que le langage est bancal et inefficace qu'il ne faut pas l'utiliser !" mais on a un arrière gout désagréable dans la bouche et c'est impression que l'on nous a forcé la main pour l'utiliser … Javascript c'est bien, ça lave plus blanc et ya de gros morceaux dedans.
Rust et Ada : OK certainement mieux que le C, et bien mieux que le C++ (trop facile :) ) mais tu passes quand même trop de temps à te battre contre le compilateur.
C : rien de plus qu'un assembleur amélioré, mais toute une époque :)
C++ : un bricolage par dessus le langage C, manque de simplicité.
Python : enfin un langage qui impose lisibilité et simplicité, qui considère le codeur comme une personne responsable tu veux déclarer tes types tu peux, tu veux pas les déclarer tu peux aussi
tu veux écrire comme un goret tu peu aussi.
bref c'est toi qui es au commande.
En plus il t'impose pas des caractères inutiles comme Begin End, point virgule et autres parenthèses ou accolade inutiles
Et il peu presque tout faire
Ce pas un hasard et ce n'est pas pour rien si c'est le langage No 1 depuis quelques années
Bon après ce texte, volontairement bête, méchant, et partisan je ne dirai qu'un chose n'apprenez pas un langage particulier, commencez par apprendre ce qu'est l'informatique.
Après vous choisirez le langage le plus adapté pour un problème donné.
Python, C, bash et tout les autres ne sont pas des frères ennemis mais des frères de sang.
[^] # Re: La suite , la suite ...
Posté par zurvan . Évalué à 3 (+1/-0).
il manque le FORTH : si tu n'arrives pas à relire ton code 3 jours après, c'est parce que tu n'as pas assez découpé ta procédure en plusieurs sous-programmes et a tout construit d'un bloc. En plus, si tu n'as pas développé ta propre version de FORTH en assembleur, tu manques probablement d'ambition.
C'est d'ailleurs ce qui s'est passé, avec des mot clés incompatibles d'une implémentation à l'autre, et pour rajouter un peu de rigueur, ils ont procédé à une normalisation par l'ANSI en 2012 (https://forth-standard.org/), mais bien entendu certains continuent encore de faire des trucs dans leur coin, dans l'esprit des origines (https://duskos.org)
Rappel important : vos amis qui se sont retournés contre vous parce que la TV leur a dit de le faire : ils le feront encore.
[^] # Re: La suite , la suite ...
Posté par Christophe B. (site web personnel) . Évalué à 2 (+2/-2).
Et je dirai même plus :
Le FORTH c'est un truc d'extra terrestre, ça marche OK, mais avec l'impression de faire les choses à l'envers.
Sincérement la notation polonaise inverse … c'est trop fort ce que vous fumez, faut changer. Sinon les renards vont venir et ont a les dents qui poussent.
[^] # Re: La suite , la suite ...
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Je te soupçonne de manquer d'objectivité en ce qui concerne Python. Je suis sûre que si tu avais écrit sur, je sais pas moi, Ada, Rust ou Fortran à la place ton commentaire aurait été différent.
Je n’ai aucun avis sur systemd
[^] # Re: La suite , la suite ...
Posté par Christophe B. (site web personnel) . Évalué à 2 (+0/-0).
ça se voit tant que ça ?
;)
[^] # Re: La suite , la suite ...
Posté par mahikeulbody . Évalué à 4 (+2/-0). Dernière modification le 06 février 2026 à 12:03.
C'est exactement ce que mes profs disaient au début des années 70 en nous renvoyant à des manuels pour apprendre un langage. Eux ils préféraient nous enseigner les grammaires formelles, ce qu'est un compilateur (et comment en faire un), un système de fichiers, faire des TP sur un Elbit pour étudier le fonctionnement d'un ordinateur, etc… On n'a jamais eu de cours sur un quelconque langage. Pendant ce temps-là, il y avait des publicités invitant à devenir pupitreur en quelques mois sur un matériel donné, c'est l'avenir elles disaient…
[^] # Re: La suite , la suite ...
Posté par Christophe B. (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 06 février 2026 à 16:25.
Comme les maths modernes quand j'étais petit …
En gros on t'apprenait la linguistique avant de parler en anglais
Tu savais que Alone = Allein car l'anglais et l'allemand avait la même racine mais tu savait parler ni l'un ni l'autre
Tout le monde n'avait pas vocation a continuer ses etudes des années apres le bac
La théorie sans exemple pratique … rien de plus penible
Et je peu te dire que trouver des exemples pratiques en fonction du niveau c'est pas toujours simple …
[^] # Re: La suite , la suite ...
Posté par martoni (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Ouch, voila un indicateur d'âge qui ne rajeuni pas ;)
J'ai plus qu'une balle
[^] # Re: La suite , la suite ...
Posté par Christophe B. (site web personnel) . Évalué à 6 (+4/-0).
Eh ouais …
et si je te dis que j'ai connu le jour sans école le jeudi au lieu du mercredi …
et que j'ai appris à écrire avec une plume sergent major un encrier et un buvard …
:)
[^] # Re: La suite , la suite ...
Posté par Ant . Évalué à 2 (+1/-0).
Hum, j'ai eu des profs comme ça. Je les soupçonne de ne jamais avoir appris un seul langage…
Un des miens en particulier nous a appris un langage machine de son invention de type assembleur, et ensuite bien sûr on devait coder un compilateur et un interpréteur de son pseudo-langage. Ensuite, en sortant de la fac, j'ai passé les 10 années suivantes à expliquer que oui j'avais développé en assembleur, mais que non ce n'était ni du 68000 ni du Z80 ni un autre assembleur connu.
Maintenant, tout le monde s'en fout, je pense que les étudiants de codent plus de compilateurs, ou alors pendant leur temps libre.
[^] # Re: La suite , la suite ...
Posté par PhRæD . Évalué à 5 (+4/-0).
À quoi bon refaire ce qui marche, à part pour suivre la hype ? Hype quo aurait changé dans 2 ans et il faudra — encore — tout réécrire…
Quant à la verbosité ? Source ?
Quant à la rigidité ? Si COBOL est toujours là, et qu’on continue d’en écrire — parce qu’il ne tourne pas que du COBOL datant des années 1960 —, c’est peut être surtout parce que COBOL et son écosystème ont su évoluer et s’adapter aux époques. Depuis le temps qu’on écrit que COBOL est dépassé, curieux qu’il subsiste. L’argument du coût de réécriture me semble biaisé. Celui du coût de maintenance me semble bien plus à propos.
C’est bien simple : dans le groupe bancaire dans lequel j’évolue, l’écosystème COBOL (le site central) coûte environ 10 % de la facture globale informatique (près d’un milliard d’euros par an), alors que ça fait tourner 95 % des applications du marché domestique (tous les postes de travail en agence n’ont qu’un front-end d’affichage : toutes les règles métiers sont côté site central).
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: La suite , la suite ...
Posté par Christophe B. (site web personnel) . Évalué à 3 (+1/-0).
C'est pas encore vendredi mais :
[hello.cbl]
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLO.
000300 AUTHOR. JOE PROGRAMMER.
000400 ENVIRONMENT DIVISION.
000500 DATA DIVISION.
000600 PROCEDURE DIVISION.
000700 MAINLINE.
000800 DISPLAY 'Hello World!'.
000900 STOP RUN.
On fait plus concis de nos jours … :)
Ok c'est petit, bête et méchant
Mais si cela fonctionne est que cela fait tourner le métier bancaire alors respect.
Question subsidiaire : vous arrivez a former des jeunes ? ou dans quelques années tout le monde sera à la retraite ?
[^] # Re: La suite , la suite ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Les jeunes utilisent maintenant lya donc plus de formation en rien et les vieux+vieilles peuvent sortir du popcorn
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: La suite , la suite ...
Posté par PhRæD . Évalué à 2 (+1/-0).
La ligne 300 est facultative -> gain de concision. (_ )
En 900, GOBACK est préférable à STOP RUN : s'il s'agissait d'un programme susceptible d'être appelé, il stopperait sinon l'appelant.
Pour ce qui est des jeunes, c'est très facile : lancez des appels à candidatures, sélectionnez les têtes vous paraissant bien faites, plongez les dans un eco-système COBOL pendant 3 mois, utilisez-les en sous-traitance pendant 1 an, embauchez ceux gui survivent… Dans notre groupe, on appelle ça une host-académie, la troisième promotion d'environ 10 personnes va bientôt entrer dans la phase prestation.
C'ess la reprise d'un mode recrutement courant dans les années 2000 dont j'ai bénéficié, quand on disait déjà que COBOL était has been et allait dispuraitre sous peu.
« Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »
[^] # Re: La suite , la suite ...
Posté par Christophe B. (site web personnel) . Évalué à 2 (+0/-0).
Comme le papier / crayon , les sysadmin, les codeurs etc … mais quand un outil est fiable, pratique et qu'il fait le job avec un prix correct il perdure
Mode Vendredi on
Par contre des techno comme
- le Wap (mouahaha mdr) pour ceux qui s'en souviennent (j'ai une anecdote la dessus ;) )
- Le port parallèle pour les imprimantes
- Internet Explorer 6 et la suite … (de nos jours c'est un mot comme "lapin" sur un bateau cela porte malheur :) )
- MS/DOS : j'oublierai jamais cette phrase mythique d'un grand visionnaire : "Mais qui a besoin de plus de 640K de ram ?"
- Les windows phone : même sur cette techno il fallait rebooter régulièrement … trop fort M$
Mode Vendredi Off
[^] # Re: La suite , la suite ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Peut-être que si on était resté aux « decks » il y aurait pas toutes les m-rd-s qu’on a aujourd’hui sur les transportables :/
Et sinon j’ai encore du Centronics (:
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: La suite , la suite ...
Posté par Christophe B. (site web personnel) . Évalué à 3 (+1/-0).
Peut être pas avec un imprimante derrière ?
L'imprimante en tant que tel certaines étaient inaltérables … mais après les rubans et autres consommables cela se trouvent encore ?
Sinon cela peut servir a plein de choses un port centronic c'est sur :)
[^] # Re: La suite , la suite ...
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Tu as tout à fait raison : je n’ai plus d’imprimante (aussi bien la parallèle que la scsi, toutes deux perdues dans un déménagement, ce qui est dommage car elles semblaient increvables) depuis presque onze ans (que le temps passe vite…)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: La suite , la suite ...
Posté par sjub . Évalué à 3 (+2/-0).
Fortran pour calculer vite… dans le domaine du HPC, Calcul Haute Performance, généralement ça ne va pas vite du tout !
Mais c'est vrai que c'est plus à cause du développeur qui est généralement matheux ou physicien et dont la préoccupation est déjà que le code tourne et n'a pas les connaissances en optimisation. Il faut voir tous les anti-patterns de perfs qu'on peut trouver dans ces codes : accès à la mémoire/aux caches non efficace, allocations dynamiques partout, boucles non fusionnées, … et je ne parle pas des communications avec MPI. Et c'est pareil pour les codes HPC en C ou C++.
[^] # Re: La suite , la suite ...
Posté par sjub . Évalué à 3 (+2/-0).
Un petit exemple qu'on retrouve souvent : la barrière de synchro dont on ne sait pas si elle est nécessaire ou non, mais bon, dans le doute l'ajouter ne peut pas faire de mal.
Ici dans un code High Performance Linpack en précision mixte, avec le commentaire qui va bien :
MPI_Barrier(MPI_COMM_WORLD); // for extra safety
# Facile l'assembleur !
Posté par pasBill pasGates . Évalué à 10 (+16/-2).
Moi j'ai résolu il y a longtemps les problèmes de duplication mentionnés pour l'assembleur en n'écrivant tout simplement aucun commentaire, en plus cela rend les fichiers plus légers !
[^] # Re: Facile l'assembleur !
Posté par Julien Jorge (site web personnel) . Évalué à 10 (+8/-0).
En plus ta technique marche avec tous les langages !
Cela dit je t'attendais plutôt sur une autre section de l'article ;)
[^] # Re: Facile l'assembleur !
Posté par fabricius . Évalué à 2 (+1/-0).
Et c'est même recommandé par l'oncle Bob (Robert C. Martin et son livre "Clean Code")
[^] # Re: Facile l'assembleur !
Posté par wilk . Évalué à 9 (+7/-0).
D'autant plus que contrairement à l'article l'assembleur c'est bien du code et pas des octets, d'où le terme. C'est bien typé, y a deux types, l'octet et le bit.
Ca n'est pas pénible et on comprend tout facilement vu le peu d'instructions et de types qu'il y a à connaitre.
Qu'est-ce que je me régalais avec le 6502 et le 68000 !
Il n'y a pas de meilleur apprentissage, mangez-en.
[^] # Re: Facile l'assembleur !
Posté par Bruno (Mastodon) . Évalué à 6 (+6/-1).
Je plussois ! j'ai commencé avec le Z80 en 1978 ;-) c'est le langage le plus près de la machine, on sent bien les octets.
Mais le mieux c'est de programmer directement en hexadécimal, c'est ce que j'ai fait car n'ayant pas de programme d'assemblage au début.
Les developpeurs-peuses expérimentés choisissent cette solution ;-)
[^] # Re: Facile l'assembleur !
Posté par mahikeulbody . Évalué à 7 (+5/-0).
Ah, je vois, un petit jeune ; moi c'est en 1972 avec le T1600 (Telemecanique), avec code source sur ruban perforé et debug directement au pupitre (y avait intérêt à connaître les instructions en hexadécimal).
Je l'ai d'ailleurs échappé belle, son prédécesseur était le T2000, sur 19 bits…
[^] # Re: Facile l'assembleur !
Posté par Christophe B. (site web personnel) . Évalué à 3 (+1/-0). Dernière modification le 06 février 2026 à 10:28.
Wouaouhh
Impressionnant, Assembleur en Z80, j'ai commencé avec un ZX81 on est des dinosaures
Mais toi tu es dans la catégories avant : Archosaures
Un jour, il faudra que tu nous racontes ce que c'était l'informatique à l'époque
[^] # Re: Facile l'assembleur !
Posté par Bruno (Mastodon) . Évalué à 2 (+1/-0).
Comme maintenant, des Ø et des 1.
[^] # Re: Facile l'assembleur !
Posté par Christophe B. (site web personnel) . Évalué à 2 (+0/-0).
Sauf que on est passé de
0101 0000 1100 0111
00000000 72 6f 6f 74 3a 78 3a 30 3a 30 3a 72 6f 6f 74 3a
00000010 2f 72 6f 6f 74 3a 2f 62 69 6e 2f 62 61 73 68 0a
00000020 64 61 65 6d 6f 6e 3a 78 3a 31 3a 31 3a 64 61 65
ensuite
LDA $1000 ;
STX #41 ;
main()
{
printf("Hello world \n")
}
Par contre en 1972 avec le T1600, comment tu faisais pour rentrer un programme dans la machine ?
pour le sauvegarder, pour imprimer ?
Toutes ces choses qui paraissent évidentes de nos jours, sans parler de la recherche d'informations.
Et la tu verra à quel point l'informatique a évoluée …
[^] # Re: Facile l'assembleur !
Posté par wilk . Évalué à 6 (+4/-0).
Ca n'a pas tant évolué que ça. Dans les années 80 je faisais des serveurs minitel, des sites quoi, pendant que mon père gérait des VM sur les gros IBM. Et ma foi le principe n'a pas changé, on se contente toujours de déplacer des bouts de données d'un endroit à l'autre.
La recherche d'information est plus étendue mais comme on a besoin de plus d'informations, à l'arrivée ça n'est pas plus efficace.
De ce que je me souviens de mon paternel, il écrivait sur un bout de papier le code du programme et un pupitreur (souvent une) créait la carte. La sauvegarde c'était le bout de papier, le cahier pour les plus organisés.
Le petit vieux va nous le confirmer.
[^] # Re: Facile l'assembleur !
Posté par mahikeulbody . Évalué à 4 (+2/-0).
c'est une vision réductrice de l'informatique : dans un de mes projets, c'est du lait qu'on déplaçait d'un endroit à l'autre :-)
[^] # Re: Facile l'assembleur !
Posté par Christophe "CHiPs" PETIT (site web personnel) . Évalué à 2 (+1/-0).
C'est un effet de bord du déplacement des données ;-)
[^] # Re: Facile l'assembleur !
Posté par Christophe B. (site web personnel) . Évalué à 2 (+0/-0).
Sauf que sans réseaux tu faisais comment ?
avec des Disquettes a capacité ridicule … et d'une fiabilité douteuse
Non 2 choses montrent l'évolution de l'info : le port USB / le RJ45
et la capacité de transférer facilement a des vitesses > 100Mo/s
Et ce sans se poser de question si c'est de l'IBM du HP du M$ du linux etc …
[^] # Re: Facile l'assembleur !
Posté par wilk . Évalué à 10 (+9/-0).
Le réseau c'était entre l'ordinateur et le minitel à travers un modem de minitel retourné. Une seule personne se connectait à la fois. On appelait ça des "micro-serveurs".
Pour dire à quel point c'était performant, l'ordinateur (un Apple ][+) était éteint pour ne pas chauffer. Lorsque quelqu'un appelait la sonnerie déclenchait un relais qui allumait l'ordinateur, juste le temps de la sonnerie qui envoyait un peu de jus. L'ordinateur démarrait en quelques secondes (on appelait ça fastboot, le code machine était lancé sans OS, directement du disque) et à son tour il gardait le relais allumé, envoyait la porteuse pour que le minitel de l'appelant puisse se connecter. Une fois connecté il avait accès à des forums et des pages d'infos sur les divers hack qu'on faisait, au niveau du volume une disquette était largement suffisante et sans soucis de fiabilité particulière. Lorsqu'il partait l'ordinateur s’éteignait en lâchant le relais.
[^] # Re: Facile l'assembleur !
Posté par Christophe B. (site web personnel) . Évalué à 3 (+1/-0).
Classe, Joli bricolage
Respect
[^] # Re: Facile l'assembleur !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0). Dernière modification le 07 février 2026 à 11:22.
Du « à la demande » qui n’a pas attendu Jeff et les autres.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Facile l'assembleur !
Posté par BAud (site web personnel) . Évalué à 6 (+4/-0).
ah le minitel 1B et son modem retournable pour faire du 75 / 1200 bauds au lieu de 1200 / 75 ;-) j'avais rapporté les 2 précédents à l'agence France Telecom, le premier bleu foncé mais avec clavier abcd :/ le deuxième un minitel 1 déjà couleur beige+marron et le clavier en azerty mais modem non retournable ; au moins avec le minitel 1B ils ont pensé à me fourguer la doc' qui encombrait leur armoire : deux docs, papier glacé, avec même les blueprints des circuits électroniques et surtout toutes les commandes envoyables par l'interface série pour piloter le minitel et gérer l'affichage (avec tous les codes de caractères semi-graphiques…).
je l'avais connecté à mon Apple IIe pour "automatiser" l'enregistrement des pages du 3611 pour mon père : les 3 min de consultation étaient "gratuites", ça permettait de récupérer les adresses des clients du magasin ;-)
Bon j'avais commencé le programme en Basic Applesoft, j'ai rapidement dû passer en assembleur pour économiser la RAM consommée et pouvoir exploiter les 64 ko de l'extension à 128 ko pour y stocker les pages, que l'on reconsultait à déconnexion en les renvoyant sur le minitel.
j'avais aussi fait un chat avec un pote, mais ça monopolisait la ligne téléphonique et on ne pouvait parler que par clavier interposé, pas au téléphone :/ (ouais, yavait qu'une ligne téléphonique chez moi /o\)
[^] # Re: Facile l'assembleur !
Posté par wilk . Évalué à 4 (+2/-0).
Un jour une copine d'école se connecte, par la suite je lui dit que je l'ai bien vue. Et là elle s'affole, tu as vue ma tête ???
Quelle prémonition !
[^] # Re: Facile l'assembleur !
Posté par Bruno (Mastodon) . Évalué à 4 (+3/-0).
Oui, ça s'appelait un(e) préparatrice, le pupitreur c'est celui qui lance les jobs.
[^] # Re: Facile l'assembleur !
Posté par wilk . Évalué à 3 (+1/-0).
On vient de me dire qu'elles s'appelaient des "perforatrices". Et ensuite ils imprimaient les résultats pour conservation.
[^] # Re: Facile l'assembleur !
Posté par Bruno (Mastodon) . Évalué à 2 (+1/-0).
Pour moi la perforatrice c'était la machine (pas une perforeuse non 😉)
Peut-être que dans certaines boîtes ils disaient ça aussi pour celles qui manipulaient mais ça m'étonne.
[^] # Re: Facile l'assembleur !
Posté par wilk . Évalué à 6 (+4/-0).
Ca m'étonnait aussi mais ils avaient l'air sûr d'eux. On trouve des traces du terme :
https://fr.wikipedia.org/wiki/Perforatrice
Ensuite s'en est suivi une discussion un peu hallucinante. Ma mère demande à mon père "mais qu'ont-t-elles fait ensuite quand il y a eu les écrans ?". Réponse : le ménage.
[^] # Re: Facile l'assembleur !
Posté par Bruno (Mastodon) . Évalué à 4 (+3/-0).
Oui c'est ce que je pense, le terme pouvait être employé pour la personne mais ce n'était pas généralisé et pour ma part dans les deux boites où à mes débuts il y avait encore des cartes perforées le terme était préparatrice.
Avec les écrans beaucoup sont devenues des "Opératrices de saisie"
C'est juste mon expérience.
[^] # Re: Facile l'assembleur !
Posté par Bruno (Mastodon) . Évalué à 3 (+2/-0). Dernière modification le 06 février 2026 à 18:17.
Je plaisantais, en fait j'ai vu l'évolution de l'informatique car après avoir joué sur mon trs-80 c'est devenu mon métier jusqu'à l'année dernière.
Je suis passé des cartes perforées au cloud en passant par toutes ou presque les technos.
L'année dernière je donnais des formations sur le Big Data et l'IA.
Ça a été sympa.
[^] # Re: Facile l'assembleur !
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Et pour patcher le code, on utilisait ce genre d'outil :
[^] # Re: Facile l'assembleur !
Posté par mahikeulbody . Évalué à 5 (+3/-0). Dernière modification le 07 février 2026 à 21:42.
On coupait au bon endroit et on insérait un morceau vierge qu'on pouvait perforer. Que de souvenirs ! Par contre plus aucun souvenir de comment on trouvait l'endroit (je me rappelle juste qu'on mettait le binaire exécutable sur le ruban).
[^] # L LM
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Là c’est pas de l’assembleur (pour résumer, des mnémoniques et constructions à assembler par un autre programme pour produire le binaire machine) mais directement Le Langage Machine (oui, oui, le binaire écrit directement à la main). Je dirai que là il y deux types de types : le bit et les mots mémoire (la taille de tes registres)
Je te rejoins : pour apprendre, parmi les processeurs humainement abordables, il y a les 6.5k, le 68k, le Z80, et quelques autres.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Facile l'assembleur !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 06 février 2026 à 11:48.
Moins malin, je persiste à en écrire épisodiquement, quoique l'expérience de reprendre mes propres codes retourne quasi invariablement le résultat : le code est plus clair que les commentaires…
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Connais-tu le PHP ? C'est un langage ...
Posté par rycks . Évalué à 10 (+11/-0).
La flemme d'écrire la suite :)
Merci c'est bel article très plaisant à lire !
eric.linuxfr@sud-ouest.org
[^] # Re: Connais-tu le PHP ? C'est un langage ...
Posté par Julien Jorge (site web personnel) . Évalué à 10 (+10/-0). Dernière modification le 06 février 2026 à 07:18.
Mais oui ! Comment ai-je pu passer à côté d'une cible aussi facile…
# C++
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Je m'attendais à lire ça dans l'article et je ne l'ai pas vu:
[^] # Re: C++
Posté par thoasm . Évalué à 6 (+3/-0). Dernière modification le 06 février 2026 à 10:37.
[^] # Re: C++
Posté par Julien Jorge (site web personnel) . Évalué à 4 (+2/-0).
J'ai longtemps hésité parce que ce sont des paramètres d'outils et non pas du langage. D'un autre côté le fait qu'il y ait besoin d'autant d'assistance pour faire des programmes vaguement corrects en dit long sur le langage :) On pourrait mettre -fsanitize=address & co. aussi.
# Rigueur ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 9 (+6/-0).
Est-ce que les codes sont mieux indentés ? J'entends de la même façon partout, l'absence de blancs finaux qui trainent, de mélange tabulations/espaces, de mélange sur les fins de ligne/fichier Unix/Windows. Les outils pour ça existent en général (ça arrive assez vite avec tout nouveau langage, il y a des IDE, etc.). Mais est-ce toujours configuré au final ? (Réponse: non)
Est-ce que les analyseurs statiques de code sont toujours utilisés ?
Est-ce qu'il y a des tests, de la doc, des dépendances bien décrites, etc. ?
Plus on élargit la quantité de personnes qui codent, plus on sort des psychorigides initialement spécialement formés pour ça qui font la différence entre espace et tab, crisent sur un double espace inutile, râlent sur un mélange camelcase/snakecase, n'aiment pas voir des warnings ; plus on va vers "le fonctionnel est plus important que le bon code, on verra plus tard ou jamais pour ça, tant pis pour le debug et la maintenance" ; le vibe coding vient amplifier nettement cela avec l'arrivée de la magie dans la production de code. Potentiellement on n'a jamais eu autant d'outils pour faire des tas de vérif/améliorations sur le code. Et pourtant l'écart entre meilleurs et pires codes ne fait que se creuser, parce qu'il faut massivement produire toujours plus de code.
Assembler/produire du code ce n'est pas juste visser deux ou trois boulons, c'est savoir si c'est deux ou trois qu'il faut, de quels types, dans quels matériaux, si on doit empêcher qu'ils se dévissent tous seuls. Et pourtant n'importe qui peut visser un boulon. Donc jusqu'à ce que tous les boulons se valent, il faudra savoir faire des choix, idéalement réfléchis plutôt qu'aléatoires ou par plagiat.
# Au moins avec le C...
Posté par gUI (Mastodon) . Évalué à 10 (+9/-0). Dernière modification le 06 février 2026 à 10:46.
Pas de surprises avec le C ! Personne n'a jamais vanté quoi que ce soit en matière de rigueur, donc pas de mauvaise surprise. Il y a carrément la liste des Undefined Behavior, soit en bon Français : pffff [hausse les épaules].
Allez si, par principe indiquons ce qui pourrait être un "mode strict" :
-Wall -Wextra -Wpedantic -Werror.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# Excellent !
Posté par Miguel Moquillon (site web personnel) . Évalué à 5 (+4/-0).
J'adore ton billet d'humeur et le ton utilisé. Ça m'a bien fait sourire. Et c'est tellement vrai ; le dev aime bien écrire du nouveau code, bien moins à maintenir et faire évoluer un code existant. D'ailleurs, la grande majorité des frameworks sont construits pour faciliter avant tout l'écriture de nouveaux projets.
J'ai l'impression, toutefois, que l'industrie ou les dév aiment peu les langages trop rigoureux ; en effet, Ada ou encore Haskell n'ont pas eu de succès.
Après, je pense qu'au delà des contraintes apportées par le langage dans l'écriture du code, ce qui manque et qui, à mes yeux, est requis dans tout projet logiciel, ce sont avant tout les conventions acceptées (voir imposées) par l'équipe. Ne s'appuyer que sur l'outillage (dont le langage) n'est en soit pas suffisant. Aussi, laisser un dév, et d'autant plus un débutant ou un junior, seul dans son coin sans le chapeauter, c'est quand même tendre le bâton pour se faire taper sur les doigts ensuite.
[^] # Re: Excellent !
Posté par mahikeulbody . Évalué à 4 (+2/-0).
C'est vrai mais avec quelques contre-exemples industriels significatifs quand même : par exemple plusieurs centrales nucléaires en France (mais aussi en Angleterre, en Chine, …) sont entièrement pilotées en Ada.
[^] # Re: Excellent !
Posté par Christophe B. (site web personnel) . Évalué à 5 (+3/-0).
Ce qui est cohérent :
un environnement complexe avec un risque très élevé Nécessite un langage à la hauteur du problème
Quand tu veux copier et modifier la taille des images sur ton disque perso, un script bash suffit amplement pas la peine de sortir un framework un compilateur des usines a gaz comme VScode
mais rassures moi … ya pas de centrales nucléaires pilotées avec du Javascript ?
Quand à confier une centrale nucléaire à une IA, à mon avis c'est pas pour tout de suite
Même si le début de l'IA c'est aussi un marqueur de plus de la décadence de notre civilisation :
pourquoi se casser la tête à coder alors qu'une machine peu le faire à notre place ?
Pourquoi travailler alors que je peu gagner plein de sous avec les crypto monnaies ou en devenant influenceurs ?
Pourquoi chercher un remède pour le cancer, l'IA finira bien par en trouver un …
Sauf que
Pour l'instant, quand le code est généré par l'IA, bon courage a ceux qui devront le maintenir, il doit bien y en avoir encore capable de le faire, mais dans quelques années …
Crypto et influenceurs : beaucoup sont volontaires mais très peu sont élus, un peu comme le loto ou la roulette au casino
L'IA trouvera un remède contre le cancer, une solution simple est de supprimer la race humaine comme ça il n'y aura plus de cancer :) c'est une solution comme une autre après tout
[^] # Re: Excellent !
Posté par mahikeulbody . Évalué à 3 (+1/-0).
Pas à ma connaissance mais ça date des années 90. Les IHM étaient codées en appelant directement X11 (avec un windows manager maison minimaliste). Mais depuis, j'imagine qu'on est quand même passé à des technos web pour les postes opérateur. Pour ce qui est des centrales plus récentes, je ne sais pas quel est le langage utilisé pour le pilotage lui-même.
NB. Les centrales pilotées en Ada sont toujours en fonction.
# Strict Python
Posté par serge_sans_paille (site web personnel) . Évalué à 6 (+4/-0).
Journal très agréable à lire, merci beaucoup !
Pour la partie Python, je ne pense pas que son évolution diffère tant que ça de ces prédécesseurs, on commence par la foire à la saucisse, puis on se rend compte que le langage pensé comme un langage de glue est utilisé pour faire des applications complexes, qu'on a besoin de structure, et on colle cette structure (la PEP 484 que tu cites par dessus). Ce n'est pas un hasard si mypy a été développé chez Dropbox.
Au final, la difficulté c'est l'optimisation multi-critère. Un langage est pensé pour un objectif, puis il devient gourmand et veut en remplir un autre. Même pour les Pokemon, c'est difficile d'évoluer !
# Langage pro
Posté par Wawet76 . Évalué à 10 (+8/-0).
Heureusement qu'il y a Java pour les vrais développements professionnels.
[^] # Re: Langage pro
Posté par Christophe B. (site web personnel) . Évalué à 3 (+2/-1).
C'est vrai on peu le dire
Mais quand une VM bouffe tout son CPU et sa RAM … il y a de grandes chances qu'il y ait du java dedans :)
[^] # Re: Langage pro
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+2/-2).
Java c'est aussi le langage qui tourne dans une VM pour pouvoir tourner sans compilation, c'est a dire facilement sur n'importe quelle architecture, mais qui au final est le plus complexe à déployer car il lui manque toujours une dépendance et qu'il faut trouver les libs. C'est aussi le code qui périme le plus. Impossible de faire tourner un code qui a 10 ans.
Une usine à gaz.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Langage pro
Posté par Christophe B. (site web personnel) . Évalué à 3 (+1/-0).
Le gros reproche que je ferais a ce langage c'est la multitude de machine virtuelle
à une époque chaque editeur installait la sienne et cela devenait un foutoir monstre sur certains poste client et/ou serveurs Windows
Plus facile a gérer sous unix, une application = un utilisateur basta.
Mais je connais mal l'environnement Java pourtant je sais qu'il a permis de faire de grandes choses
Nobody 's perfect …
[^] # Re: Langage pro
Posté par Julien Jorge (site web personnel) . Évalué à 2 (+0/-0).
Je pense que ça vaut le coup de comparer au C++ alors, où chaque nouvelle version s'obstine à maintenir la compatibilité avec les précédentes au point que ça empêche de corriger les problèmes. Au final vaut-il mieux une rétrocompatibilité ou s'autoriser à tout casser ?
[^] # Re: Langage pro
Posté par Dr BG . Évalué à 3 (+1/-0). Dernière modification le 07 février 2026 à 14:13.
Si tu veux, tu peux tout à fait faire un "fat jar" qui contient toutes les dépendances.
Quant à cette affirmation : "C'est aussi le code qui périme le plus. Impossible de faire tourner un code qui a 10 ans.", je me demande bien d'où ça sort car c'est carrément faux.
[^] # Re: Langage pro
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
T’as toi des trucs.jar de plus de dix ans que tu arrives à lancer sans t’arracher les cheveux ? (vraie question)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Langage pro
Posté par Dr BG . Évalué à 2 (+0/-0).
Je dirais plutôt que je n'en vois pas que je ne pourrais pas lancer en fait.
[^] # Re: Langage pro
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Alors nous sommes d’accord ;) Ce n’est pas que le code ne peut plus tourner (comme beaucoup pourraient le penser en lisant le commentaire initial) mais que souvent il faut un peu se retrousser les manches. Dans nombre de cas, il s’agit seulement de trouver la bonne version de JVM… (avec GNU/Linux ça le fait plus aisément) :)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Langage pro
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+0/-1).
En théorie, c'est vrai que le langage machine de la VM, n'a pas évolué et donc cela devrait être simple. Mais en pratique, quand tu veux faire tourner un programme dans un serveur Tomcat, si tu n'a pas la même version (et ce n'est pas possible puisque la version d'il y a 10 ans n'est plus maintenu) ça ne marchera jamais… et si tu pense qu'il n'y a pas grand chose a toucher, tu te trompe.
Bien sûr en entreprise, ça peut marcher, car l'environnement est très cadré et stable. En plus elles mettent le moyens qu'il faut pour paramétrer tout. Mais si ça marche, c'est un peu parce que c'est comme Oracle : de la bonne grosse com'. Certes Java est en théorie plus performant que d'autres interprétés (PHP et consorts) mais cela ne se justifie que rarement (surtout en contexte pro ou le cout serveur n'est pas très important) et s'il faut des perfs, aujourd'hui Go est 100 fois mieux a tout point de vue.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Langage pro
Posté par Dr BG . Évalué à 3 (+1/-0). Dernière modification le 07 février 2026 à 17:56.
C'est un problème de compatibilité de versions de bibliothèques car tu es lié dynamiquement à elles mais leurs API ont changées, ça n'a aucun rapport avec le language ou la JVM en fait. En Go tu lies tout en statique alors forcément t'auras pas le problème, mais rien ne t'empêche de faire un microservice en Java avec toutes ses dépendances packagées et t'auras pas de souci. Ça n'a rien à voir avec le langage ou la JVM en fait.
[^] # Re: Langage pro
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+0/-2).
Effectivement c'est pas le langage le problème, c'est tout l'écosystème qui est à jeter 🤣
Déjà Oracle, ensuite les technologies qui s'enchaînent sans continuité. Je veux dire par la, en C++, Qt a plus de 20 ans, en PHP pareil, en Java ce n'est pas le cas, trop de technologurs web notemment, sont poussé par Oracle et disparaissent moins de 10 ans plus tard, aucune rétro-compatibilité.
Toute application digne de ce nom se base sur des Framework…
Python a connu ce problème 1 seul fois au passage de Python 2 à 3. Java c'est récurent.
PS : cela fait un moment que je ne fais plus de Java, c'est peut être mieux, mais ça et les problèmes d'env et de config de la JVM…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Langage pro
Posté par barmic 🦦 . Évalué à 4 (+3/-1).
De toute évidence tu n’a aucune idée de ce dont tu parle que ce soit pour Java, C++, PHP,… Tu es vraiment approximatif surtout.
Ma question c’est pourquoi tu préfère balancer ta verve comme ça plutôt que simplement te renseigner sur ce dont tu parle et pourquoi pas les utiliser ? Ce serait plus enrichissant pour toi de jouer avec python, C++ ou ce que tu veut que de troller en te ridiculisant.
Ça n’est pas tant de travail que ça et tu aura un sentiment d’appartenance bien plus agréable qu’en ressortant des arguments mal digérer comme tu le fais.
Je veux pas trop te frustrer donc je te donne juste un apperçu
LE framework java c’est Spring depuis 2003. En PHP c’est Symfony depuis 2005. Qt c’est compatible GPL depuis 2000. Ils ont tous connus des cassures fortes Qt3 vers Qt4, Symfony peut être pas. Spring avec Java EE vers Jackarta (c’était pas non plus un enfer). Oracle ne pousse pas de framework java de ce que j’en sais depuis un certains temps. Ils ont quelques framework qui viennent de leurs rachats mais tout ceux que je connais suivent les spécifications de standards java comme JSF et sont donc toujours utilisables aujourd’hui. Note au passage que pour faire du web en java tu as servlet (1997), JSP (1998) et JSF (2001). Elles sont toutes toujours utisables aujourd’hui.
Oracle est une entreprise d’avocats qui font de l’argent avec du logiciel. Je n’oublie pas le procès qu’ils ont intenté à Google, mais depuis ils font un travail propre sur java (ce qui n’est pas le cas avec MySQL par exemple).
Mais pour pouvoir en parler, il faut savoir de quoi on parle et ne pas juste enchainer les phrases toutes faites.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Langage pro
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Les versions "mineures" de Python 3 cassent régulièrement des trucs. Ça se fait petit à petit mais en continu, ce qui facilite la migration en lissant la charge de travail.
En C++, selon le compilateur utilisé, l'utilisation de nouvelles versions du compilateur ne se fait pas non plus les yeux fermés, il y a de nouveaux warnings à corriger, des choses qui sont retirées du standard C++, des optimisations qui font que du code qui fonctionnait avant ne fonctionne plus, …
Rust est trop jeune pour avoir ce genre de problème mais je n'ai aucun doute qu'il y aura un jour un Rust 2.0 aussi.
Maintenir la compatibilité pwndant plusieurs dizaines d'années, ce n'est pas facile, et l'environnement évolue aussi (passage au 64 bit par exemple, mais aussi plus simplement des pratiques de développement). Tous les langages doivent s'adapter, chacun a sa façon.
[^] # Re: Langage pro
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Je suis globalement d'accord avec quelques cas particuliers. Déjà javawebstart c'est mort, les applets java aussi. Ensuite si ton logiciel aurait besoin d'un agent (au sens de la jvm) il est très probable que tu n'ai pas mis les options pour le déclarer explicitement donc ça pète en java 24 ou 25, tu as probablement des warnings qui sont apparu avec java 9, si tu fais des trucs vraiment tordu avec de la réflexion sur les enum ça va péter (si je comprends bien les enums sont sealed), si tu utilise des valeurs flottantes pas de la bonne manière ça va peut être casser aussi,…
En vrai la plupart sont plus des bugs qui se révèlent de mon point de vue et à part pour les agents ça a plutôt été bien géré.
Je trouve que l'objectif de fossiliser du code est une très mauvaise idée en soit, même dans l'IoT c'est un problème.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Langage pro
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+0/-2).
Oui pas fossiliser mais des évolutions douce et globalement rétro compatibles. Java désolé mais à chaque version ils reinventent la roue. Oracle y est pour beaucoup.
C'est plus facile de faire et maintenir un programme C++ ou Rust que Java… Alors que cela devrait être le contraire.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Langage pro
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Le java moderne est super simple à déployer. Tu embarques tout (jre, libs…) et dans un gros binaire exécutable.
C'est LOURD, mais simple.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Langage pro
Posté par Claude SIMON (site web personnel) . Évalué à 4 (+2/-0).
À propos, qui se souvient des applets (et en a développé) ?
Zelbinium: Your Devices, Your Rules!
[^] # Re: Langage pro
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
M’en souviens et ai fait :)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Langage pro
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
C'était le but premier de Java mais cela n'a jamais vraiment pris (trop lourd, complexe). La seule chose qui a fonctionné ce sont els applets "VPN d'entreprises". Aujourd'hui WebAssembly est un peu l'équivalent…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Langage pro
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Puisque on en parle, quelqu'un a des nouvelles de Pierre Tramo ?
# C++ et auto
Posté par 2PetitsVerres (Mastodon) . Évalué à 4 (+2/-0).
auto c'est bien, mais pour rendre le code lisible, le mieux c'est d'utiliser une vrai 🚗 !
Comme ça par exemple
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: C++ et auto
Posté par Julien Jorge (site web personnel) . Évalué à 2 (+0/-0).
C'est beaucoup plus clair comme ça, merci !
# Bash set -e
Posté par purplepsycho . Évalué à 4 (+2/-0). Dernière modification le 06 février 2026 à 16:22.
La suite là https://mywiki.wooledge.org/BashFAQ/105
# La rigueur et la finance
Posté par Andre Rodier (site web personnel) . Évalué à 4 (+3/-0).
Pour les actionnaires, la rigueur dans la programmation n'est pas financièrement intéressante. Pour ces derniers, il y a un taux acceptable de bugs et de dette technique, en deçà duquel on peut continuer à vendre des services et le produit.
Lorsque l'on dépasse ce taux et que les clients commencent à se plaindre, on intègre des nouveaux concepts, des nouvelles technologies, ou des nouveaux langages. Arrivent donc, l'intégration continue, le « code coverage / code quality analysis », les « blue-green deployment », les « xxx-driven-development », le « pair programming », la programmation orientée objet, etc. La liste est longue.
Avec toutes ces merveilles, on pourrait croire que l'industrie informatique ne puisse maintenant souffrir d'aucun bug ni faille de sécurité.
Et pourtant, en 2025, on a battu des records en termes de failles de sécurité, de bugs mondiaux (c.f. CloudFlare / AWS / etc).
Le seul maillon de la chaine que l'on n'avait pas changé était l'humain. C'était difficile, mais avec l'IA, on y vient. On va donc avoir des technologies qui permettent de produire du code en quantité, et aussi d'analyser la qualité de code, tout cela en très peu de temps, avec des développeurs débutants et un impact écologique désastreux.
L'analyse de qualité et l'écologie ne rapportant pas de retour sur investissement à court terme, on comprendra que les actionnaires pousseront pour l'utilisation de production de code. C'est-à-dire la production de nouveaux produits et services, dont les commerciaux assureront la vente, la publicité, et la « création du besoin ». En gros, l'IA va accélérer la « merdification » des services et les commerciaux vont gaver les clients comme des oies de Noël.
Prenons par exemple Spotify. L'entreprise ne cesse de pousser des services qu'une grosse partie des clients ne veulent pas, et refusent de les supprimer. Ou les sites de la SNCF, où réserver un train requiert un doctorat en informatique (dixit Aurélien Barrau).
Pourtant, un autre mode de consommation est possible, ou la qualité primerait sur la quantité, la tempérance sur la frénésie, la simplicité sur la complexité, l'austérité sur l'opulence, etc.
En attendant, que le spectacle commence 🍿
[^] # Re: La rigueur et la finance
Posté par Krunch (courriel, site web personnel) . Évalué à 4 (+2/-0). Dernière modification le 08 février 2026 à 10:47.
Pour l'ingénieur il y a un taux acceptable de bugs et de dette technique en deçà duquel on peut continuer à fournir des services et des produits qui répondent suffisamment bien au cahier des charges.
FTFY
Après, il y a effectivement un système économique qui influence le cahier des charges et donc les compromis techniques. Mais les compromis techniques en sois sont bel et bien du ressort de l'ingénieur (ou de la personne qui a son rôle quel que soit son titre nominal) en charge du projet.
Si c'était uniquement les actionnaires qui pousseraient à accepter les bugs, aucun projet gratuit n'aurait de bug.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Et Ruby ?
Posté par Philippe F (site web personnel) . Évalué à 6 (+4/-0).
Je suis surpris que Ruby ne figure pas dans ta merveilleuse lettre (ou est-ce un pamphlet) ? Il a pourtant eu son heure de gloire!
J'ai entendu dire qu'il existerait des langages extrêmement stricts sur leurs types de données. Genre un langage nommé en l'honneur d'Ada Lovelace. Et plus d'être fastidieux à écrire, ce genre de langage est terriblement ennuyeux car il n'a aucun mystère : tu connais tout de suite le type de tes données. C'est un pur spoiler à lui tout seul. Pas étonnant qu'il n'aie aucun succès chez les développeurs fainéants (pléonasme)!
[^] # normal
Posté par Krunch (courriel, site web personnel) . Évalué à 5 (+3/-0).
Tu remarquera que la liste ne contient que des langages utilisés par plus de 7 personnes.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: normal
Posté par shuihuzhuan . Évalué à 3 (+2/-0).
Nous sommes pourtant bien une petite dizaine sur le forum (pub).
# markdown pas assez strict
Posté par Krunch (courriel, site web personnel) . Évalué à 4 (+2/-0).
Le deuxième paragraphe de la section « JavaScript » commence par « [[JavaScript] » alors que l'intention de l'auteur était sans doute d'y mettre un lien vers la page Wikipedia JavaScript.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: markdown pas assez strict
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Corrigé, merci.
[^] # Re: markdown pas assez strict
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
C'est ce qui arrive quand on ne met pas son interpréteur Markdown en mode strict!
[^] # Re: markdown pas assez strict
Posté par Krunch (courriel, site web personnel) . Évalué à 4 (+2/-0).
Il fallait écrire du XHTML directement.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# LLM comme moteur de recherche
Posté par Krunch (courriel, site web personnel) . Évalué à 6 (+4/-0).
Moui mais est-ce que c'est parce que cette technologie est tellement performante ou parce que la qualité de ton moteur de recherche s'est dégradée ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: LLM comme moteur de recherche
Posté par Julien Jorge (site web personnel) . Évalué à 9 (+7/-0).
Non seulement la qualité du moteur de recherche s'est dégradée mais en plus la qualité du web s'est dégradée.
# Plus fort que l'IA : les langages de quatrième génération !
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0). Dernière modification le 11 février 2026 à 16:37.
Les L4G vont encore plus loin que les LLM : ils permettent d'écrire directement le code en langage naturel !
Par exemple si vous voulez mettre à jour votre commentaire sur linuxfr, vous pouvez écrire
update commentaire set content = 'plop' where login = 'devnewton'.Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par thoasm . Évalué à 3 (+0/-0).
plop
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par ted (site web personnel) . Évalué à 4 (+2/-0).
SEQUEL langage?
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
QBE 4ème génération
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
aussi appelé Query by Example qui était disponible dans Paradox (la base de données rachetée par Borland). Méthode fournie par IBM initialement ? (je ne l'avais pas cette partie)
J'avais aussi en tête un logiciel qui faisait de la recherche en langage naturel et non en langage structuré, mais je n'ai pas réussi à retrouver :/ (stait aussi un produit Borland de mémoire)
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Paradox que j’ai brièvement côtoyé <3 J’ai débuté les bases de données avec BASIC… puis suis passé rapidement à dBase, ça nous rajeuni pas tout ça.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par BAud (site web personnel) . Évalué à 2 (+0/-0).
bin Nantucket compiler — que j'avais utilisé — permettait d'avoir des programmes plus intégrés (et rapides) que dBase III+ et dBase IV était trop lourdingue :D
Ma prof' de bases de données en école d'ingé a un peu halluciné quand je lui ai proposé comme sujet de travail perso à rendre le modèle de base (MCD) que j'avais fait en 1ère S pour recenser mes CD et mes bouquins… avec l'appli opérationnelle (vu que je l'utilisais encore 6 ans après)
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par shuihuzhuan . Évalué à 1 (+0/-0).
Pas très langage naturel comme exemple 😉
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
C'est un extrait faishell, le shell de QuesOS, l'OS où tout est requête et fromage.
Préalablement, j'avais défini une table commentaire :
create table commentaire (
login text,
content text
) as api on server https://linuxfr.org/
on update POST /comments
(...)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Plus fort que l'IA : les langages de quatrième génération !
Posté par Krunch (courriel, site web personnel) . Évalué à 3 (+1/-0).
Pour mettre à jour mon commentaire sur linuxfr, il me suffit d'écrire « rectification : sur mon dernier commentaire il fallait lire […] ». Quelques minutes à quelques heures plus tard, le commentaire est modifié et un nouveau commentaire apparaît en dessous disant « corrigé ». J'arrive même à modifier les commentaires, journaux et dépêches des autres comme ça.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.