Les mages parlent aux mages, molducs prière de vous abstenir de lire ce grimoire de magie noire.
J'étais un universitaire. J'ai appris à coder pour des endroits où les étudiants partent et viennent, et où rien n'est changé tant que ça n'a pas prouvé apporter un bénéfice.
Les malloc m'étaient interdits. J'avais le droit à de parcimonieuses variables globales mais j'avais le droit à l'artillerie lourde des fork/pipe/dup/open. Et je forkais mon process C dans un interpréteur Tk/Tcl pour permettre de visualiser des résultats de simulations.
Par curiosité j'ai recompilé ce code des années 1996: il marche toujours...
Quand je suis retourné à l'ENS physique en 2009 pour une visite de courtoisie j'ai demandé à Gérard W. mon mentor de l'époque: pourquoi vous êtes pas passé à python/LAMP/ruby/Perl?
Il m'a répondu: ça sert à rien. Les performances surtout en analyse numérique sont mauvaises.
Et il a détaillé que d'un coté les modèles à GC introduisait des pertes de performances notamment dû à la perte de localité des variables qui n'avait pas de bon sens, mais que surtout, on ne retrouvait plus la qualité des bibliothèques d'analyses numériques des années 80 tant en vitesse qu'en correction.
Donc, le FORTRAN/le C était toujours utilisés parce qu'on avait pas de code "correct" à la place, et que les "incorrections" coûtaient chères à corriger. (QA style quoi).
Pendant ce temps, au royaume du big DATA on utilise du javascript pour faire des filtres ARMA pourris implémentés naïvement qui le serait bien plus efficiemment en passant par des FFTs.
M'enfin, je m'égare.
Que ce soit le code fortran appelé par python dans matplotlib, ou que ce soit l'équivalent des numerical recipies en C il y a toujours du code qui doit être garanti de compiler à l'identique car il est critique.
Je renverrais les béotiens à google pour lire un cours d'introduction à l'informatique pour comprendre ce qui ne va pas en C:
quand + - * / sont utilisés ils n'ont pas du tout les mêmes proriétés que les vrais opérateurs.
ttc = ( 1.0 + tva * 100 ) * prix
ne donne pas toujours le même résultat que
ttc = prix + ( prix*tva/100)
Yes, on fait du commerce électronique avec ça. On a beau répété qu'il faut prendre des virgules fixes pour le commerce, rien n'y fait. Les développeurs continuent majoritairement à utiliser des floats.
Donc quand on me demande pourquoi on a besoin de bibliothèque numérique avec contrôle d'erreur ou encore de FORTRAN, je répond parce qu'il y a du code qui a été très bien écrit qui n'est pas remplaçable et qui permet de dire qu'un nombre est pas trop faux.
Excusez moi, mais la correction dans les ordinateurs pour afficher une page web et celle pour calculer un truc donc dépend ma vie (aviation, nucléaire, médicale) ne sont pas les mêmes.
Et, les algorithmes n'ont pas changés.
Par contre .... Les codes produits par les compilateurs eux changent... sur une même plateforme matérielle en fonction des versions des compilateurs.
Pourquoi ?
Non la question est comment:
- La jungle des Ox et de leurs effets et des optimisations acceptables par défaut;
- introduction de nouveaux comportements face aux indéterminations (ex valeur de variable non settées en C);
- la jungle des jeux d'optimisations matérielles et des différents modéles mémoires;
- les pragmas à la con et autres GNUeris
Tout cela fait que les codes produits sont différents, entraînant du fait des nombres de combinatoires engendrées des conflits sur les valeurs trouvées. Les #ifdefs de l'enfer. Obligeant le développeur à gérer à la mimine l'enfer des résolutions de dépendances matérielles, d'optimisation ET de types ET version de compilateurs
Et en plus, cela complexifie le déboguage. Quand un bug apparaît il faut pouvoir régénérer l'exact version du code afin de déterminer si c'est un bug de logiciel, de compilateur, ou de version de compilateur, ou d'option spécifique de compilation....
Ce qui m'épate, c'est que dans les années 2000 avec plus de plate-formes matérielles, et d'OS qu'aujourd'hui, on y arrivait plutôt pas mal à garantir tout ça.
Ce que ne réalisent pas moult développeurs, c'est que les cycles de vies des entreprises ne sont pas de 2 ans maximums...
Comprenez bien... J'ai rien contre node qui sait pas multiplier mieux que python, ruby, Perl, java.
Non.
Je dis juste qu'une centrale nucléaire doit pouvoir être maintenue pendant 70 ans, un réseau de gaz ou d'eau pendant des décades, un avion des décennies, un satellite des décennies, mes archives de travailleur/citoyens/médicale tout au long de ma vie.
Je dis qu'appeler 2 ans du support de long terme dans l'informatique actuelle, ça craint du boudin.
Je dis à mes camarades informaticiens et du logiciels libre c'est que si vous voulez vraiment un avenir à l'informatique, on a pas besoin d'un brouteur web qui souffre d'une cancer des extensions, on a besoin d'un compilateur C stable de support à vrai long terme.... genre aussi long que l'on veut que l'informatique puisse durer sans devenir une gêne.
Sérieux, vos grands parents gardaient précieusement photos et lettres dans une boîte en carton dans le grenier et c'est comme ça que se passaient les souvenirs.
Vous, quand vous pourrez plus payer votre compte sur le clown car vous aurez passé l'arme à gauche comment allez vous transmettre votre mémoire?
C'est ça une logique de support de long terme... penser au futur et non à demain.
Notre vision de la durée de vie et des garanties de correction en informatique sont aujourd'hui une insulte au reste de l'industrie et des citoyens autant que des consommateurs.
Et ça va nous péter à la gueule tôt ou tard.
Donc moi je dis peanuts à mozilla pour les dons, peanuts à la FSF, peanuts à tout le monde tant qu'on sait pas comment construire une informatique avec un support à long terme qui soit conforme aux attentes.
Si on met des livres dans des ordis et qu'on détruit les livres, alors j'aimerais avoir une garantie que la mémoire sera transmise aux générations futures, sinon ça sert à quoi de bâtir du savoir?
No comments:
Post a Comment