C’est surtout « IA » pris dans le sens tel qu’on le voit à toutes les sauces partout en ce moment, le sens sur lesquels il y a des milliards en investissements partout et n’importe où, le sens sur lequel des entreprises se mettent en danger pour sortir « de l’IA » sans savoir ce qu’elles vont pouvoir mettre exactement derrière ce terme et ce juste pour éviter d’être larguées par leurs concurrentes.
Vouloir relativiser le terme « IA » en l’élargissant à tous les sens potentiels qu’on a mis derrière ce terme au fil des années, c’est complètement passer à côté du propos de l’article.
Ce genre de structure est particulièrement présent en Corée du Sud, on les appelle Chaebol.
Il est donc tout à fait possible que Samsung (ou LG, Hyundai, Lotte…) soit réellement spécialiste à la fois en aspirateurs et en réfrigérateurs et en ordinateurs, etc. Parce qu’en réalité ce sont des produits d’entités différentes vendues avec le même logo, et pas une seule entité qui essaie de tout faire.
À titre personnel je trouve dommage de ne pas avoir vérifié avant de poster, c'est littéralement plus rapide que de rédiger le message plein de présupposés.
La vidéo d’Heu?Reka sur Black & Scholes, justement : https://www.youtube.com/watch?v=bsgEdQB05_U (doit aussi exister sur peertube, le titre de la vidéo est « La faillite du Hedge Fund LTCM (1/5) Arbitrage - Wall Street Stories #4 »).
Mais du coup, vraie question : quel est l’intérêt d’un outil qui tente de deviner le séparateur et le type des données ?
Ça doit fonctionner avec des données en entrée bien maitrisées, mais dans le cas général c’est la garantie d’avoir du n’importe quoi importé dans tes bases, à cause d’erreurs de détection.
La plupart des SGBD sont capables d’importer des CSV de façon native, avec une commande comme load data (Oracle, MySQL), copy (PostgreSQL), bulk insert (MSSQL), CSVREAD (H2), .import (SQlite), import (DB2)…
Jolie utilisation du stratagème XXIX (ou peut-être du XVIII, ils se ressemblent beaucoup). Dans tous les cas, c’est toujours dommage de piocher dans les techniques de la dialectique éristique.
Je n'ai jamais pensé ni écrit cela ici ou ailleurs
Tu as pourtant écrit (le gras est de moi) :
Ce n'est pas le cas. Si les correcteurs des copies de Bac devaient sanctionner les fautes d'orthographe et de grammaire comme cela se faisait dans le passé, bien peu d'élèves obtiendraient leur Bac. Les copies sont surnotées, cela fait partie des consignes intégrées par les profs depuis un moment.
J’ai compris ça comme un « c’était mieux avant ». Ça n’était peut-être pas ton intention, mais il y a quand même un très fort appel au passé dans cette partie du message. Quoiqu’il en soit, ces éléments ne sont pas pertinents pour montrer que « le français va mal ». Tout ce qu’ils montrent, c’est qu’avant on était intolérants sur la forme.
Il existe plusieurs sortes de français, dont la langue parlée et la langue écrite. Dans le monde réel, quand on bosse, quand on écrit un projet, quand on essaie de transmettre un savoir ou des idées par l'écrit, le minimum consiste à savoir maîtriser la langue sinon on se fait jeter par les interlocuteurs et décideurs que l'on est censé convaincre.
Justement : le problème n’est pas que des gens avec des messages intéressants aient une mauvaise orthographe ou grammaire. Le problème est que l’on rejette des messages intéressants et pertinents sur le fond à cause de cette orthographe et de cette grammaire.
La correction à apporter à notre société, c’est d’arrêter ce genre de rejets, et pas d’exiger une maitrise parfaite de l’orthographe et de la grammaire là où elle est inutile.
D’autre part : la langue écrite ne se réduit pas à l’orthographe et à la grammaire. On pourrait utiliser une orthographe parfaitement phonétique (ou inversement, parfaitement idéographique) et supprimer l’intégralité des exceptions et aberrations grammaticales sans enlever quoi que ce soit à la richesse de l’expression écrite du français. Parce que l’orthographe, en particulier, n’est qu’une convention graphique, en réalité assez annexe à la langue. Se focaliser sur ce point, c’est ignorer tout ce qui fait la richesse de la langue et du message qu’elle véhicule : la richesse du vocabulaire, la pertinente dans sa sélection, la tournure des phrases, le rythme, l’organisation des idées, etc.
Ce n'est pas le cas. Si les correcteurs des copies de Bac devaient sanctionner les fautes d'orthographe et de grammaire comme cela se faisait dans le passé, bien peu d'élèves obtiendraient leur Bac. Les copies sont surnotées, cela fait partie des consignes intégrées par les profs depuis un moment.
C’est dommage, le commentaire auquel tu réponds comportait un lien très intéressant, qui explique notamment que « le français » n’est pas « l’orthographe et la grammaire » comme le laisse penser ta réaction. Et que si, le français va très bien, merci. Je te le remets ici : https://www.tract-linguistes.org/ – je te conseille en particulier les points 5, 6 et 8.
Mais j’imagine que c’est plus facile et confortable de réagir en mode « c’était mieux avant, quand tu pouvais foirer un examen de n’importe quoi parce que tu n’avais pas une orthographe parfaite, même en état un dieu dans la matière qui était censée être notée » plutôt que de se renseigner et se remettre en question.
De mon expérience – qui ne vaut que ça – le cas était assez différent entre Windows XP et 7 :
Les gens ont effectivement gardé Windows XP jusqu’à des dates complètement déraisonnables.
Par contre je connais beaucoup de gens, même non techniques, qui ont migré de Windows 7 à 10. Les OS avaient les mêmes prérequis, et Microsoft poussait très fort cette migration, qui a longtemps été gratuite et légale. Ce cas n’est plus possible pour faire Windows 10 -> 11 à cause des restrictions matérielles – par contre, pour les PC compatibles, Microsoft a aussi poussé Windows 11 très très fort.
Il y a 20 ans côté Sénégal et Mauritanie (j’ai pas d’informations plus récentes), ce qui était demandé, c’était pas de savoir lire le Coran mais de pouvoir le réciter. À des populations dont les langues sont très éloignées de l’arabe. Conséquence : on a des peuples entiers qui sont capable de réciter le Coran sans en comprendre un traitre mot. Oui, ça implique d’apprendre le bouquin entier en phonétique.
C’est le même genre de phénomène qui a poussé l’Église catholique à utiliser les langues locales au lieu du latin lors du concile de Vatican II.
Sisi, le hangeul est bien un alphabet, sauf que les « lettres » ne sont pas disposées linéairement mais dans des carrés, à raison d’un carré par syllabe.
Avec une subtilité supplémentaire : si la série de lettres crée une syllabe qui n’existe pas en coréen, le résultat est considéré comme invalide (et il n’y a pas les codes informatiques pour les coder), ce qui rapproche le résultat d’un syllabaire. Mais le fonctionnement interne et l’apprentissage sont bien ceux d’un alphabet.
Tu as 0.04% de chance de reconstruction sur un disque de fiabilité 10-14 et seulement 43% de chances de le reconstruire malgré des disques spéciaux à 10-15 de fiabilité.
Le problème, c’est que la réalité, c’est presque toujours complexe. Donc, tout programme réel doit se positionner dans cette alternative :
Rester simple, mais se priver volontairement de cas d’usages légitimes.
Répondre à ces cas d’usages, mais augmenter la complexité.
Évidemment, selon l’utilisation réelle du programme, la balance va pencher plus ou moins d’un côté ou de l’autre. Si je développe un logiciel à mon seul usage, je peux ignorer tous les cas d’usage qui ne sont pas les miens. Si je développe le système informatique des impôts d’un pays, je dois impérativement couvrir tous les cas d’usage, quelle que soit la complexité informatique que ça apporte (j’ignore volontairement la question de l’inutile complexité fonctionnelle en partant du principe que le développeur du programme n’a pas la main dessus).
C’est le moment pour préciser que le développeur (au sens large) n’a jamais la légitimité pour nier le besoin fonctionnel d’un utilisateur. Il peut choisir de ne pas la prendre en compte (« Mon logiciel n’est pas adapté pour ton besoin et ne sera pas modifié en ce sens, trouves-en un autre ou adapte-toi. »), mais c’est tout.
Quant à l’illusion de simplicité, ce qui est beau @abriotde c’est que tu fournis ton propre contre-exemple avec CSV. Parce que CSV est l’exemple parfait du format qui a l’air simple, mais qui ne l’est pas. Je pars du principe qu’on utilise le CSV standard (séparateur de champs ,, séparateur décimal . – Excel en Français utilise respectivement ; et ,). Même avec cette hypothèse, le format a les pièges suivants qui font que la plupart des implémentations naïves sont cassées :
Le séparateur de lignes est \n ou \r\n selon le système d’exploitation (oui, il y a des implémentations pétées dès ce point).
Les données peuvent avoir N lignes d’en-tête mais le format ne les différencie pas des données normales, il faut un mécanisme dans le parseur pour les déclarer.
Idem avec des colonnes d’en-têtes, plus rares.
On veut pouvoir avoir n’importe quelle valeur dans les champs, dont des virgules. Il faut donc un délimiteur de champ supplémentaire, facultatif – généralement ".
Ça implique donc d’avoir un mécanisme d’échappement pour pouvoir avoir ce caractère à l’intérieur d’un champ – généralement on double le guillemet : un champ qui ne contient qu’un guillemet s’écrit donc """". Ça implique d’avoir une logique qui compte les " pour savoir quoi faire.
On voit déjà qu’il est possible de générer des fichiers CSV incohérents au-delà du simple nombre de champs par ligne, et donc qu’il faut gérer ces erreurs.
En fait on ne peut pas lire un CSV ligne par ligne, parce qu’un champ protégé par des " peut contenir des sauts de ligne, qui en CSV standard seront enregistrés dans le fichier comme des sauts de ligne indiscernables à priori de ceux qui séparent les séries de données (ça n’est pas des caractères échappés).
Et je ne parle même pas de la problématique de transformation des champs textes obtenus en données typées (nombres entiers et réels, dates…)
Sauf que… beaucoup de développeurs font comme toi dans ton argumentation, ne voient que la partie « simple » du CSV, ne cherchent pas plus loin, en font une implémentation naïve, qui explose en vol dès le premier cas d’usage imprévu rencontré. Un parseur CSV robuste, c’est un parseur à base de jetons et d’une grammaire (certes simple) – ou mieux, une bibliothèque qui gère déjà tous ces cas pénibles. Dans ma carrière, je crois que cette erreur a été faite par les 3/4 des développeurs qui ont dû implémenter du CSV (en lecture ou en génération), et ça a fini par casser à chaque fois (pas de chance, j’ai jamais eu à traiter du cas uniquement numérique en conditions maitrisées de bout en bout).
Là où c’est amusant, c’est que XML a justement comme avantage de pouvoir être traité, validé, filtré et transformé au fil de l’eau, sans tout monter en mémoire. Même si avec les capacités de traitement modernes, c’est un avantage qui n’a plus un intérêt énorme (en particulier, ça ne compense plus sa difficulté de lecture pour un humain et sa verbosité dans la plupart des cas).
Je vise simplement les architecture trop complexes pour le projet et l’application de design patterns pour le seul plaisir d’appliquer un design pattern sans se poser de question. Le genre de trucs qu’on trouvait effectivement dans Java EE ou Spring à l’ancienne (mais pas que), et qui a tendance à disparaitre avec les derniers Spring Boot ou Quarkus.
On peut vouloir tendre vers des principe de clean / hexagonal / onion architecture, sans que cela soit nécessairement de l'overengineering, hein. Tout dépend de la taille du projet.
Ça tombe bien, ça n’est absolument pas mon propos.
Juste pour préciser un point de mon argumentaire : je fais une différence forte entre le code qui est inutilement compliqué parce que non maitrisé, et le code inutilement compliqué parce que conçu et réfléchi comme tel. Je range uniquement le second cas dans le vocable « suringéniérie » ou « overengineering ».
Ça serait beaucoup trop beau si « plus simple = mieux ». Mais c’est généralement faux.
Tout comme « moins de lignes c’est plus simple », d’ailleurs (bonjour Perl, mais pas que).
Parce que « mieux » n’est pas défini dans l’absolu. Par exemple, farbfeld est un excellent format en terme de complexité nécessaire pour le gérer, mais devient mauvais voire catastrophique quand on réfléchit en terme de consommation (mémoire, disque, réseau).
D’une manière générale, beaucoup d’algorithmes simples (et donc peu susceptibles de bugs) sont difficiles à utiliser en conditions réelles parce qu’ils ne sont pas efficaces : trop consommateurs en calcul, en mémoire de toute sorte, en entrées/sorties… Dès que l’on a besoin d’efficacité (et quelle que soit la définition exacte que l’on donne à cette notion d’efficacité), on se retrouve souvent à devoir ajouter de la complexité, et on doit rapidement lorgner vers des techniques qui sont tout sauf triviales : parallélisation, caches, etc.
PS : en terme d’interface, « simple à utiliser » est en réalité souvent « complexe à concevoir et à coder », à la fois à cause de la masse de travail à réaliser pour comprendre ce qu’est un une interface simple pour les utilisateurs et par les automatismes à mettre en place pour y arriver.
PPS : « Simple » dans la définition qui est donnée ici, c’est aussi se couper de cas d’usages légitimes. Par exemple, farbfeld est inutilisable pour qui a besoin de gérer des métadonnes d’images, des profils colorimétriques, etc.
Par contre, je croise souvent un vrai problème de complexité inutile, dans le sens où le code a été conçu et réalisé de façon complexe sans que cette complexité soit là pour répondre à un quelconque problème.
Cela dit, de mon expérience et en entreprise, la source de cette complexité inutile n’est pas tellement la cause de « hackers qui aiment les grandes quantités de code », mais plutôt de personnes qui ne comprennent pas ce qu’elles font et qui n’en ont rien à faire. Sans comprendre le but réel de leurs développements, ces personnes empilent les couches de modifications minimales et de bidouilles ad hoc qui transforment très vite tout code en bloat infâme. Les « complexités "intelligentes" inutiles » (suringéniérie) sont, de mon expérience, beaucoup plus rare et surtout en perte de vitesse (imaginez les classiques « Java pour Entreprise™ » avec des Factory et tout dans tous les sens).
[^] # Re: Je suis pas un grand fan pourtant
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien En fait, l'IA ne sert à rien. Évalué à 4.
C’est surtout « IA » pris dans le sens tel qu’on le voit à toutes les sauces partout en ce moment, le sens sur lesquels il y a des milliards en investissements partout et n’importe où, le sens sur lequel des entreprises se mettent en danger pour sortir « de l’IA » sans savoir ce qu’elles vont pouvoir mettre exactement derrière ce terme et ce juste pour éviter d’être larguées par leurs concurrentes.
Vouloir relativiser le terme « IA » en l’élargissant à tous les sens potentiels qu’on a mis derrière ce terme au fil des années, c’est complètement passer à côté du propos de l’article.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C’est pas « une entreprise » mais « un groupe » (plus exactement : un chaebol)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Xiaomi: un bouton de confidentialité désactivant tous les outils scannant les environs de la voiture. Évalué à 3.
Pour donner un peu plus d’exemples :
Et on pourrait multiplier les exemples à l’infini.
La connaissance libre : https://zestedesavoir.com
[^] # C’est pas « une entreprise » mais « un groupe » (plus exactement : un chaebol)
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Xiaomi: un bouton de confidentialité désactivant tous les outils scannant les environs de la voiture. Évalué à 4. Dernière modification le 29 mars 2024 à 18:50.
« Samsung » n’existe pas en tant qu’entreprise unique, c’est un groupe de 59 sociétés différentes qui elles-mêmes ont des foultitudes de filiales commerciales et techniques.
Ce genre de structure est particulièrement présent en Corée du Sud, on les appelle Chaebol.
Il est donc tout à fait possible que Samsung (ou LG, Hyundai, Lotte…) soit réellement spécialiste à la fois en aspirateurs et en réfrigérateurs et en ordinateurs, etc. Parce qu’en réalité ce sont des produits d’entités différentes vendues avec le même logo, et pas une seule entité qui essaie de tout faire.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Surtout du mythe
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Logiciel libre, entre mythe et réalité !. Évalué à 4. Dernière modification le 24 mars 2024 à 01:12.
D'autant qu'en cherchant 2 secondes, la forme utilisée est systématiquement : « Claudia Weber, avocat » (sans e final). Un exemple d'auto-présentation ici https://itlaw.fr/interview-de-claudia-weber-avocat-associe-fondateur-itlaw-avocats-pour-ozint/
À titre personnel je trouve dommage de ne pas avoir vérifié avant de poster, c'est littéralement plus rapide que de rédiger le message plein de présupposés.
La connaissance libre : https://zestedesavoir.com
[^] # Re: De considérer les politiciens comme ignorants
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien [HS] « Tout sur l’économie, ou presque : Pour comprendre vraiment ce qui cloche dans le système ». Évalué à 4.
La vidéo d’Heu?Reka sur Black & Scholes, justement : https://www.youtube.com/watch?v=bsgEdQB05_U (doit aussi exister sur peertube, le titre de la vidéo est « La faillite du Hedge Fund LTCM (1/5) Arbitrage - Wall Street Stories #4 »).
La connaissance libre : https://zestedesavoir.com
# Certains sites (très utilisés) sont 100x plus lents que PUBG
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien How web bloat impacts users with slow devices. Évalué à 10.
Un extrait hallucinant de l’article :
Je ne résiste pas au plaisir de vous partager cette capture d’écran de la structure HTML de Wix :
La connaissance libre : https://zestedesavoir.com
[^] # Re: C’est déjà géré en standard avec les principaux SGBD
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal autocsv2sql : un utilitaire pour convertir ses CSV sans se poser de question, "écris" en OCaml. Évalué à 5.
Mais du coup, vraie question : quel est l’intérêt d’un outil qui tente de deviner le séparateur et le type des données ?
Ça doit fonctionner avec des données en entrée bien maitrisées, mais dans le cas général c’est la garantie d’avoir du n’importe quoi importé dans tes bases, à cause d’erreurs de détection.
La connaissance libre : https://zestedesavoir.com
# C’est déjà géré en standard avec les principaux SGBD
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal autocsv2sql : un utilitaire pour convertir ses CSV sans se poser de question, "écris" en OCaml. Évalué à 9.
La plupart des SGBD sont capables d’importer des CSV de façon native, avec une commande comme
load data(Oracle, MySQL),copy(PostgreSQL),bulk insert(MSSQL),CSVREAD(H2),.import(SQlite),import(DB2)…La connaissance libre : https://zestedesavoir.com
[^] # Re: Boarf
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Nathalie Azoulai : "Les codeurs informatiques ont un pouvoir d'écriture comparable aux scribes (…). Évalué à 0.
Jolie utilisation du stratagème XXIX (ou peut-être du XVIII, ils se ressemblent beaucoup). Dans tous les cas, c’est toujours dommage de piocher dans les techniques de la dialectique éristique.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Boarf
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Nathalie Azoulai : "Les codeurs informatiques ont un pouvoir d'écriture comparable aux scribes (…). Évalué à 4.
Tu as pourtant écrit (le gras est de moi) :
J’ai compris ça comme un « c’était mieux avant ». Ça n’était peut-être pas ton intention, mais il y a quand même un très fort appel au passé dans cette partie du message. Quoiqu’il en soit, ces éléments ne sont pas pertinents pour montrer que « le français va mal ». Tout ce qu’ils montrent, c’est qu’avant on était intolérants sur la forme.
Justement : le problème n’est pas que des gens avec des messages intéressants aient une mauvaise orthographe ou grammaire. Le problème est que l’on rejette des messages intéressants et pertinents sur le fond à cause de cette orthographe et de cette grammaire.
La correction à apporter à notre société, c’est d’arrêter ce genre de rejets, et pas d’exiger une maitrise parfaite de l’orthographe et de la grammaire là où elle est inutile.
D’autre part : la langue écrite ne se réduit pas à l’orthographe et à la grammaire. On pourrait utiliser une orthographe parfaitement phonétique (ou inversement, parfaitement idéographique) et supprimer l’intégralité des exceptions et aberrations grammaticales sans enlever quoi que ce soit à la richesse de l’expression écrite du français. Parce que l’orthographe, en particulier, n’est qu’une convention graphique, en réalité assez annexe à la langue. Se focaliser sur ce point, c’est ignorer tout ce qui fait la richesse de la langue et du message qu’elle véhicule : la richesse du vocabulaire, la pertinente dans sa sélection, la tournure des phrases, le rythme, l’organisation des idées, etc.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Boarf
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Nathalie Azoulai : "Les codeurs informatiques ont un pouvoir d'écriture comparable aux scribes (…). Évalué à 2.
C’est dommage, le commentaire auquel tu réponds comportait un lien très intéressant, qui explique notamment que « le français » n’est pas « l’orthographe et la grammaire » comme le laisse penser ta réaction. Et que si, le français va très bien, merci. Je te le remets ici : https://www.tract-linguistes.org/ – je te conseille en particulier les points 5, 6 et 8.
Mais j’imagine que c’est plus facile et confortable de réagir en mode « c’était mieux avant, quand tu pouvais foirer un examen de n’importe quoi parce que tu n’avais pas une orthographe parfaite, même en état un dieu dans la matière qui était censée être notée » plutôt que de se renseigner et se remettre en question.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Précisions
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Linux n’a jamais été aussi populaire, le système d’exploitation libre bat un record. Évalué à 4.
De mon expérience – qui ne vaut que ça – le cas était assez différent entre Windows XP et 7 :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Précisions
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Linux n’a jamais été aussi populaire, le système d’exploitation libre bat un record. Évalué à 6.
Là où ça va être intéressant, c’est de voir ce qui va se passer après le 14 octobre 2025, date de fin du support de Windows 10.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Résumé
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Unicode misconceptions. Évalué à 3.
J'ai vécu en Corée, ça aide !
La connaissance libre : https://zestedesavoir.com
[^] # Re: Résumé
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Unicode misconceptions. Évalué à 1.
Il y a 20 ans côté Sénégal et Mauritanie (j’ai pas d’informations plus récentes), ce qui était demandé, c’était pas de savoir lire le Coran mais de pouvoir le réciter. À des populations dont les langues sont très éloignées de l’arabe. Conséquence : on a des peuples entiers qui sont capable de réciter le Coran sans en comprendre un traitre mot. Oui, ça implique d’apprendre le bouquin entier en phonétique.
C’est le même genre de phénomène qui a poussé l’Église catholique à utiliser les langues locales au lieu du latin lors du concile de Vatican II.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Résumé
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Unicode misconceptions. Évalué à 2.
Sisi, le hangeul est bien un alphabet, sauf que les « lettres » ne sont pas disposées linéairement mais dans des carrés, à raison d’un carré par syllabe.
Avec une subtilité supplémentaire : si la série de lettres crée une syllabe qui n’existe pas en coréen, le résultat est considéré comme invalide (et il n’y a pas les codes informatiques pour les coder), ce qui rapproche le résultat d’un syllabaire. Mais le fonctionnement interne et l’apprentissage sont bien ceux d’un alphabet.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mon résumé
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Reflets.info cherchent des fonds pour sa plateforme OSINT. Évalué à 3.
Mais du coup, c’est quoi votre plan pour quand vous aurez un disque mort – si c’est pas un secret professionnel ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mon résumé
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Reflets.info cherchent des fonds pour sa plateforme OSINT. Évalué à 2.
Je confirme, 8 x 12 To je ne vois pas comment tu peux les reconstruire : https://zestedesavoir.com/billets/1828/disques-durs-special-nas-et-reconstruction-de-raid/
Tu as 0.04% de chance de reconstruction sur un disque de fiabilité 10-14 et seulement 43% de chances de le reconstruire malgré des disques spéciaux à 10-15 de fiabilité.
La connaissance libre : https://zestedesavoir.com
# Un vœu pieux, mais une prise de conscience du politique
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Leaders in Industry Support White House Call to Address Root Cause of Many of the Worst Cyber Attack. Évalué à 4.
Évidemment, cette demande est un vœu pieux, à peu près aussi crédible que de dire « Maintenant, faisons des logiciels sans bugs ».
Pour moi, le point intéressant n’est pas dans la demande en elle-même, mais dans ce que l’existence de cette demande implique. En particulier :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des idées intéressantes, mais simplistes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à 6. Dernière modification le 25 février 2024 à 01:05.
Le problème, c’est que la réalité, c’est presque toujours complexe. Donc, tout programme réel doit se positionner dans cette alternative :
Évidemment, selon l’utilisation réelle du programme, la balance va pencher plus ou moins d’un côté ou de l’autre. Si je développe un logiciel à mon seul usage, je peux ignorer tous les cas d’usage qui ne sont pas les miens. Si je développe le système informatique des impôts d’un pays, je dois impérativement couvrir tous les cas d’usage, quelle que soit la complexité informatique que ça apporte (j’ignore volontairement la question de l’inutile complexité fonctionnelle en partant du principe que le développeur du programme n’a pas la main dessus).
C’est le moment pour préciser que le développeur (au sens large) n’a jamais la légitimité pour nier le besoin fonctionnel d’un utilisateur. Il peut choisir de ne pas la prendre en compte (« Mon logiciel n’est pas adapté pour ton besoin et ne sera pas modifié en ce sens, trouves-en un autre ou adapte-toi. »), mais c’est tout.
Quant à l’illusion de simplicité, ce qui est beau @abriotde c’est que tu fournis ton propre contre-exemple avec CSV. Parce que CSV est l’exemple parfait du format qui a l’air simple, mais qui ne l’est pas. Je pars du principe qu’on utilise le CSV standard (séparateur de champs
,, séparateur décimal.– Excel en Français utilise respectivement;et,). Même avec cette hypothèse, le format a les pièges suivants qui font que la plupart des implémentations naïves sont cassées :\nou\r\nselon le système d’exploitation (oui, il y a des implémentations pétées dès ce point)."."""". Ça implique d’avoir une logique qui compte les"pour savoir quoi faire."peut contenir des sauts de ligne, qui en CSV standard seront enregistrés dans le fichier comme des sauts de ligne indiscernables à priori de ceux qui séparent les séries de données (ça n’est pas des caractères échappés).Et je ne parle même pas de la problématique de transformation des champs textes obtenus en données typées (nombres entiers et réels, dates…)
Sauf que… beaucoup de développeurs font comme toi dans ton argumentation, ne voient que la partie « simple » du CSV, ne cherchent pas plus loin, en font une implémentation naïve, qui explose en vol dès le premier cas d’usage imprévu rencontré. Un parseur CSV robuste, c’est un parseur à base de jetons et d’une grammaire (certes simple) – ou mieux, une bibliothèque qui gère déjà tous ces cas pénibles. Dans ma carrière, je crois que cette erreur a été faite par les 3/4 des développeurs qui ont dû implémenter du CSV (en lecture ou en génération), et ça a fini par casser à chaque fois (pas de chance, j’ai jamais eu à traiter du cas uniquement numérique en conditions maitrisées de bout en bout).
Là où c’est amusant, c’est que XML a justement comme avantage de pouvoir être traité, validé, filtré et transformé au fil de l’eau, sans tout monter en mémoire. Même si avec les capacités de traitement modernes, c’est un avantage qui n’a plus un intérêt énorme (en particulier, ça ne compense plus sa difficulté de lecture pour un humain et sa verbosité dans la plupart des cas).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des idées intéressantes, mais simplistes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à 2.
Est-ce que la modération pourrait remplacer
contenusparbilletsdans les URLs ? Merci d'avance !La connaissance libre : https://zestedesavoir.com
[^] # Re: Des idées intéressantes, mais simplistes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à 3. Dernière modification le 23 février 2024 à 19:38.
Je vise simplement les architecture trop complexes pour le projet et l’application de design patterns pour le seul plaisir d’appliquer un design pattern sans se poser de question. Le genre de trucs qu’on trouvait effectivement dans Java EE ou Spring à l’ancienne (mais pas que), et qui a tendance à disparaitre avec les derniers Spring Boot ou Quarkus.
Même sans framework, ça inclut entre autres les interfaces à outrance, les getter/setter générés, le fait de sortir une constante à la moindre valeur présente en double ou bien certains types de commentaires.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des idées intéressantes, mais simplistes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à 2.
Ça tombe bien, ça n’est absolument pas mon propos.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des idées intéressantes, mais simplistes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à 2.
Juste pour préciser un point de mon argumentaire : je fais une différence forte entre le code qui est inutilement compliqué parce que non maitrisé, et le code inutilement compliqué parce que conçu et réfléchi comme tel. Je range uniquement le second cas dans le vocable « suringéniérie » ou « overengineering ».
La connaissance libre : https://zestedesavoir.com
[^] # Des idées intéressantes, mais simplistes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien farbfeld : le format d'image le plus simple du monde. Évalué à 7. Dernière modification le 23 février 2024 à 10:04.
Ça serait beaucoup trop beau si « plus simple = mieux ». Mais c’est généralement faux.
Tout comme « moins de lignes c’est plus simple », d’ailleurs (bonjour Perl, mais pas que).
Parce que « mieux » n’est pas défini dans l’absolu. Par exemple, farbfeld est un excellent format en terme de complexité nécessaire pour le gérer, mais devient mauvais voire catastrophique quand on réfléchit en terme de consommation (mémoire, disque, réseau).
D’une manière générale, beaucoup d’algorithmes simples (et donc peu susceptibles de bugs) sont difficiles à utiliser en conditions réelles parce qu’ils ne sont pas efficaces : trop consommateurs en calcul, en mémoire de toute sorte, en entrées/sorties… Dès que l’on a besoin d’efficacité (et quelle que soit la définition exacte que l’on donne à cette notion d’efficacité), on se retrouve souvent à devoir ajouter de la complexité, et on doit rapidement lorgner vers des techniques qui sont tout sauf triviales : parallélisation, caches, etc.
PS : en terme d’interface, « simple à utiliser » est en réalité souvent « complexe à concevoir et à coder », à la fois à cause de la masse de travail à réaliser pour comprendre ce qu’est un une interface simple pour les utilisateurs et par les automatismes à mettre en place pour y arriver.
PPS : « Simple » dans la définition qui est donnée ici, c’est aussi se couper de cas d’usages légitimes. Par exemple, farbfeld est inutilisable pour qui a besoin de gérer des métadonnes d’images, des profils colorimétriques, etc.
Par contre, je croise souvent un vrai problème de complexité inutile, dans le sens où le code a été conçu et réalisé de façon complexe sans que cette complexité soit là pour répondre à un quelconque problème.
Cela dit, de mon expérience et en entreprise, la source de cette complexité inutile n’est pas tellement la cause de « hackers qui aiment les grandes quantités de code », mais plutôt de personnes qui ne comprennent pas ce qu’elles font et qui n’en ont rien à faire. Sans comprendre le but réel de leurs développements, ces personnes empilent les couches de modifications minimales et de bidouilles ad hoc qui transforment très vite tout code en bloat infâme. Les « complexités "intelligentes" inutiles » (suringéniérie) sont, de mon expérience, beaucoup plus rare et surtout en perte de vitesse (imaginez les classiques « Java pour Entreprise™ » avec des Factory et tout dans tous les sens).
La connaissance libre : https://zestedesavoir.com