Posté par lym .
En réponse à la dépêche Firefox 69 ☯.
Évalué à 3.
Flash est certes enfin dégagé quasiment à 100% du web, merci html5… Mais reste utilisé par pas mal de sites embarqués pour configurer du matériel réseau, type caméra IP.
Bon, on change pas tous les jours des config l'utilisant (type zones de détection de mouvement) alors l'activer à la demande n'est pas vraiment un problème pour ce type d'usage limité.
Par contre, ce serait bien que cela ne dégage pas totalement tout de même, histoire de ne pas devoir mettre à la poubelle du matériel fonctionnel au moindre besoin de reconfiguration. En tout cas pour ceux qui n'auront pas forcément le réflexe de garder une ancienne version et ses dépendances dans un coin de leur arborescence pour cet usage.
Mais bon, sous Linux ce serait visiblement aussi éviter Wayland ce qui ne fonctionnera qu'un temps même si pour ma part je continuerais à le faire aussi longtemps que possible: Je ne souhaite en effet pas revenir plus de 20 ans en arrière et ne pouvoir tirer une appli graphique à travers le réseau en X11 forwarding (via ssh), se retrouver à tirer un bureau complet (j'ai des machines headless sans environnement de bureau et juste une install X minimale via la version frame-buffer xvfb, ce qui apporte du confort comparé à quelques terminaux en permettant d'utiliser de l'applicatif simple comme rxvt et autres nedit d'une unique connection ssh) via un ersatz de VNC ou RDP, non merci. X a été conçu traversé par la pile réseau et a priori c'était pas trop les plans des développeurs de Wayland, ce qui était pour moi une regression incroyable tant tout le monde utilise ceci. Bon, ca a peut-être changé ceci dit, vu que la réponse il y a qq années m'avait fait en plus du tout regarder ce projet. Attitude pas sans rappeler celle du projet Gnome au passage de 2 à 3, avec les utilisateurs qui hurlaient (Cinnamon, voire Mate sur de petites configs, ont depuis résolu le problème).
Pour en revenir au sujet, côté politique extensions, cela m'a surtout affecté pour Thunderbird: Beaucoup de monde étant passé (par facilité, c'est quand même un pis-aller) au webmail, il a sans doute bcp moins d'utilisateurs que Firefox et aussi de suivi des plugins par leurs auteurs. Là j'ai du bloquer ses MAJ car je me passe assez difficilement de l'extension "attachment extractor" qui n'a pas passé la version 60, je suis donc resté en 52 (Debian = versions ESR).
C'est donc toujours dommage, en effet, de faire de la casse là dessus. Surtout quand leur variété fut un gros point fort.
Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.
Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.
Sinon, j'ai sans doute plus écrit de C sans aucune dépendance (même pas la libc) qu'avec. Mais contexte un peu particulier.
On part AMHA déjà mal car ce n'est pas vraiment un problème lié au langage d'une part (la solution ne sera donc pas à ce niveau) et d'autre part, un problème devenu complexe car il n'a pas souvent été bien géré dès le départ. Une dépendance correctement pensée/architecturée niveau API (n'ayant donc pas à être modifiée un jour) et le problème se ramène à du versionnage (quels appels dispo sur telle version) et une compatibilité ascendante.
Rien de plus simple, en fait.
Quand on écrivait des specs bien revues au lieu de post-it qui s'envolent, je dirais que cela se passait tout de même un peu mieux. Ce qui donne tout de même un léger avantage aux vieux langages comparé aux nouveaux.
Vieux qui d'ailleurs permettent encore d'ailleurs d'écrire, certes à condition d'aimer réinventer la roue (sauf contexte particulier), du code capable de s’exécuter sans tirer… la moindre dépendance!
En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…
La richesse des libs python permet de faire pas mal de choses rapidement, mais en illustration je suggère la vision de la fosse remplie de serpents d'un épisode d'Indiana Jones!
En réalité, les multiples interpréteurs (et leur obésité qui en arrive à les faire peser plus lourd que le système complet qui les fait tourner), les possibilités de casse système ou au mieux limitées à l'utilisateur induites par les chemins multiples d'installation de paquets, ce qui amène aux environnements virtuels (et autant de doublons) cela me rappelle un truc: Le syndrome Java!
Ce que j'appelle le syndrome Java, c'est que quasiment chaque appli codée en Java embarque désormais le plus souvent sa VM et dépendances pour éviter (même pas toujours) les ennuis/instabilités. Un gâchis faramineux.
Il n'y a bien que sous Androïd que Google semble avoir réussi, vu de (pas trop, j'espère?) haut tout du moins, à bien cadrer l'affaire. Au prix d'un applicatif bien lent tout de même, surtout à avoir snobbé Jazelle pour ne pas se lier pieds et poings à l'architecture ARM.
En même temps… c'était le prix Turing. Donc pas vraiment le lieu pour la pratique!
Pour le reste, quelque soit le domaine quasiment l'intégralité de ce qui est fait en bas niveau l'est désormais chez les fondeurs. Tout simplement car ils en ont besoin pour tester eux-mêmes (et des composants de plus en plus complexes) et que le logiciel libre (à travers de projets comme u-boot ou l'horreur EDKII, qui si Intel ne s'y était pas collé n'aurait jamais pu déployer un UEFI si inutilement complexe que de plus en plus de monde cherche à le remplacer…) offrait un cadre à mutualisation qui est aussi devenu un élément concurrentiel.
Ajoutons que chez certains (Intel pour ne pas le nommer), cela permet aussi de bâcler les docs: On fournit le code, prenez le donc et foutez nous la paix. De toutes manières notre support est nul!
Bref, vous achetez le dernier SoC de chez Cavium ou Freescale et le u-boot de la carte de référence sera donné, certes à adapter à votre matériel mais ça tourne et a un niveau ou le debug se fait à la bite et au couteau, mine de rien par rapport à il y a 20 ans ca compte. Surtout avec la complexité croissante des chips.
Côté Intel, on refusera tout support bas niveau, ne fournissant même pas les firmwares non signés (sauf à se faire vraiment botter le cul) et vous enverra vers un fournisseur de BIOS qui, en fait, n'est plus qu'un intégrateur du EDK2 fourni par Intel, des reference code (RC) de la plateforme (en particulier le gros morceau du MRC chargé de l'init DDR, faite toute en soft chez Intel contrairement à d'autres ou c'est un paramétrage et un enable suite auquel le hardware se démerde pendant quelques dizaines de ms et roule) également fournis par Intel (c'est la version source du FSP, qui permet à coreboot d'exister, mais avec qq API manquantes pour un projet industriel, c'est conçu pour!)… auquel on ajoute quelques libs (crypto etc) sous licence MIT et les petits ajouts cosmétiques d'un AMI/Insyde/Poenix ainsi que l'IDE qui va avec. Tout ceci bien entendu traînant sa chaîne de compilation: Intel pour le pur Intel (RC), Microsoft pour EDK2 (même si GCC semble utilisable ici) et le code de l'éditeur, GNU pour les libs libres.
Sur ce dernier point, proprement ahurissant de complexité inutile, on est sur EDK2 en implémentation de référence sur un nb de lignes de code comparable au kernel Linux. Pour un boot loader qui est loin derrière niveau fonctionnalités. Il faut dire qu'avec ses 3 phases (SEC/PEI/DXE) relativement étanches, pas mal de choses utiles aux trois doivent en réalité être codées en autant d'exemplaires.
=> La majorité du boulot en UEFI… c'est l'infra UEFI elle-même. Pas vraiment du bas niveau dont Intel se charge entièrement et fait tout pour que ça dure.
Niveau GPU, je ne connais pas personnellement mais je ne pense pas que grand chose sorte de chez NVIDIA ou AMD.
Il n'y a pas des dizaines de milliers de personnes, principalement chez un nombre de fondeurs principaux se comptant sur les doigts d'une main, sur ce qui tape vraiment bas.
Niveau sécurité, je ne crois pas qu'il y ait grand chose à relativiser dans sa prise en compte: Sa présentation à réception de son prix Turing est d'ailleurs fondatrice dans le domaine.
Pour le reste, combien de personnes sont encore capables actuellement de coder un truc bare-metal, sans dépendances plus ou moins maîtrisées ni système de build tordu pour faire tomber tout cela en marche (avec le moindre "hello world" qui en sorte pesant quelques dizaines de MB)? Quelques centaines de personnes peut-être sur la masse mondiale des codeurs divers, sans doute plutôt désormais à rechercher chez les fondeurs dans les équipes qui supportent leurs reference design et spécialisées dans le démarrage initial d'un processeur… et pas vraiment pour faire un OS complet derrière.
J'en parle, certes sans grande expérience de ce langage, car je trouve vraiment dangereux d'avoir a ce point voulu imposer une présentation propre (ce qui en soit se défend) aux dépens de la robustesse du langage (ce qui est indéfendable).
Surtout, encore une fois, que sans délimiteurs aucun outil ne peut décider automatiquement comment corriger le tir. Du C formaté cochon, en quelques milli-secondes c'est rectifiable automatiquement. Si on fait des "beautifier" de source, c'est justement pour ne pas s'emmerder à cela. Des boites les passent automatiquement, d'ailleurs, pour imposer sans douleur cette partie des règles de codage dès qu'on check-in des modifications de sa branche de dev. Simple et efficace. On peut même quand on prends des sources y coller son formatage préféré car on a le cerveau cablé depuis des années dessus, sans impact pour les autres. C'est la différence entre la mentalité BDFL, ou pas!
D'autres ont souligné plus haut que python 3 semble ne plus vouloir interpréter des lignes mixant tabulations et espaces. Comme quoi je n'ai pas dû être le seul à pester là dessus et j'espère même que cette vérification est faite au niveau du source complet. Sinon une ligne ajoutée en fin de bloc pré-existant avec un éditeur non configuré à l'identique du précédent peut aussi poser problème.
Tout source passé par plusieurs éditeurs dont au moins un n'était pas configuré pour transformer les tabulations en espace peut poser le problème sur la/les lignes de fin de bloc.
Je ne crois par ailleurs pas avoir dit que C était plus fiable que Python. Juste que sauf bug compilo ou processeur, au moins il fait toujours ce que le programmeur voit dans son éditeur préféré. Qu'on l'évite de plus en plus partout ou il est évitable ne me pose pas de problème, mais bon, travaillant au ras des pâquerettes c'est forcément 99% de ce que je produis et si ca n'avait pas été le cas, n'importe quel autre langage utilisant des délimiteurs (cad l'immense majorité) aurait pu être pris en exemple.
Vu comme on nous flique sur ce qu'on livre, surtout depuis 10 ans que blackduck repère/colle une licence sur chaque bout de code y compris compilé (=> à partir de là, n'importe quel concurrent faisant un dump de votre firmware s'il y trouvait un bout de code GPL pouvait vous obliger à en publier des pans entiers ou vous bloquer niveau vente!), pas de risque d'aller à la pêche sur le net.
Je n'ai pour ma part en effet fait que du 2, essentiellement pour de petits outils/scripts ou le shell montrait ses limites…
Bonne chose que cela ait été corrigé en 3. Désormais, je passe un "expand -t 8" dès que je récupère un source pour voir visuellement si un truc se décale. Mais c'est vraiment fastidieux car cela oblige à comprendre chaque bout de source ou le problème se présente pour savoir de quel côté il faut mettre la/les lignes en question.
Astyle reformate n'importe quel code C au goût de celui qui le reprends, sans erreur possible.
Forcément, là le style on s'en fout car la grammaire est robuste.
Délimiter les blocs avec des indentations est LA très mauvaise idée du Python ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
Après cela, on a beau jeu de dire que le C est dangereux…
Ce qui éviterait d'avoir l'interpréteur qui exécute parfois un code qui n'est pas celui présenté visuellement à son auteur.
Ne pas avoir voulu mettre de délimiteur de bloc amène à cette situation. C'est certes volontaire pour pousser à présenter correctement, mais c'est hyper dangereux: Le nb de fois ou j'ai eu la fin d'un bloc qui était sorti du bloc après édition avec des éditeurs configurés différemment, sans que visuellement cela apparaisse.
Et sur un langage avec délimiteurs (genre {} en C), les outils automatiques permettent de reformater sans problème. Pas avec Python: Il faut avoir en tête ce que fait le programme pour savoir s'il y a un truc qui sort du bloc pour des questions de présentation ou non.
Le genre de "détail" qui flingue un langage pour une utilisation ou la fiabilité est fondamentale.
Se rendre compte qu'il y a un problème le jour ou la branche de code interprétée de travers (vs sa représentation visuelle) est exécutée, c'est vraiment un problème.
Un programme C mal présenté: Astyle s'en sort toujours. En Python, non.
[^] # Re: la version Wayland de Firefox ne prend pas en charge Flash
Posté par lym . En réponse à la dépêche Firefox 69 ☯. Évalué à 3.
Flash est certes enfin dégagé quasiment à 100% du web, merci html5… Mais reste utilisé par pas mal de sites embarqués pour configurer du matériel réseau, type caméra IP.
Bon, on change pas tous les jours des config l'utilisant (type zones de détection de mouvement) alors l'activer à la demande n'est pas vraiment un problème pour ce type d'usage limité.
Par contre, ce serait bien que cela ne dégage pas totalement tout de même, histoire de ne pas devoir mettre à la poubelle du matériel fonctionnel au moindre besoin de reconfiguration. En tout cas pour ceux qui n'auront pas forcément le réflexe de garder une ancienne version et ses dépendances dans un coin de leur arborescence pour cet usage.
Mais bon, sous Linux ce serait visiblement aussi éviter Wayland ce qui ne fonctionnera qu'un temps même si pour ma part je continuerais à le faire aussi longtemps que possible: Je ne souhaite en effet pas revenir plus de 20 ans en arrière et ne pouvoir tirer une appli graphique à travers le réseau en X11 forwarding (via ssh), se retrouver à tirer un bureau complet (j'ai des machines headless sans environnement de bureau et juste une install X minimale via la version frame-buffer xvfb, ce qui apporte du confort comparé à quelques terminaux en permettant d'utiliser de l'applicatif simple comme rxvt et autres nedit d'une unique connection ssh) via un ersatz de VNC ou RDP, non merci. X a été conçu traversé par la pile réseau et a priori c'était pas trop les plans des développeurs de Wayland, ce qui était pour moi une regression incroyable tant tout le monde utilise ceci. Bon, ca a peut-être changé ceci dit, vu que la réponse il y a qq années m'avait fait en plus du tout regarder ce projet. Attitude pas sans rappeler celle du projet Gnome au passage de 2 à 3, avec les utilisateurs qui hurlaient (Cinnamon, voire Mate sur de petites configs, ont depuis résolu le problème).
Pour en revenir au sujet, côté politique extensions, cela m'a surtout affecté pour Thunderbird: Beaucoup de monde étant passé (par facilité, c'est quand même un pis-aller) au webmail, il a sans doute bcp moins d'utilisateurs que Firefox et aussi de suivi des plugins par leurs auteurs. Là j'ai du bloquer ses MAJ car je me passe assez difficilement de l'extension "attachment extractor" qui n'a pas passé la version 60, je suis donc resté en 52 (Debian = versions ESR).
C'est donc toujours dommage, en effet, de faire de la casse là dessus. Surtout quand leur variété fut un gros point fort.
[^] # Re: Bazar!
Posté par lym . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 0.
Ce qui est bien conçu/découpé, quitte en effet à faire peu mais bien et stable, n'a pas vraiment besoin de changer. Le changement ne vient alors que de nouveaux besoins à travers de nouvelles API.
Ce que je visais, c'est l'effet délétère de l'agile sur le développement informatique réfléchi en général. Un vrai carnage dès qu'il est sorti de son cadre initial (les IHM, essentiellement) pour arriver sur des fondamentaux plateforme.
Sinon, j'ai sans doute plus écrit de C sans aucune dépendance (même pas la libc) qu'avec. Mais contexte un peu particulier.
[^] # Re: Bazar!
Posté par lym . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 0.
On part AMHA déjà mal car ce n'est pas vraiment un problème lié au langage d'une part (la solution ne sera donc pas à ce niveau) et d'autre part, un problème devenu complexe car il n'a pas souvent été bien géré dès le départ. Une dépendance correctement pensée/architecturée niveau API (n'ayant donc pas à être modifiée un jour) et le problème se ramène à du versionnage (quels appels dispo sur telle version) et une compatibilité ascendante.
Rien de plus simple, en fait.
Quand on écrivait des specs bien revues au lieu de post-it qui s'envolent, je dirais que cela se passait tout de même un peu mieux. Ce qui donne tout de même un léger avantage aux vieux langages comparé aux nouveaux.
Vieux qui d'ailleurs permettent encore d'ailleurs d'écrire, certes à condition d'aimer réinventer la roue (sauf contexte particulier), du code capable de s’exécuter sans tirer… la moindre dépendance!
En résumé: Les dépendances ont toujours été un problème, il va croissant avec les process généralisés ces 10 dernières années (totalement sortis de leur contexte initial, il faut le dire). Et en prime, aucun langage moderne ne sait plus s'en passer! De quoi expliquer le problème posé, certes, mais de là à le justifier…
# Bazar!
Posté par lym . En réponse à la dépêche Python — partie 3 — Installation de Python et de paquets. Évalué à 0.
La richesse des libs python permet de faire pas mal de choses rapidement, mais en illustration je suggère la vision de la fosse remplie de serpents d'un épisode d'Indiana Jones!
En réalité, les multiples interpréteurs (et leur obésité qui en arrive à les faire peser plus lourd que le système complet qui les fait tourner), les possibilités de casse système ou au mieux limitées à l'utilisateur induites par les chemins multiples d'installation de paquets, ce qui amène aux environnements virtuels (et autant de doublons) cela me rappelle un truc: Le syndrome Java!
Ce que j'appelle le syndrome Java, c'est que quasiment chaque appli codée en Java embarque désormais le plus souvent sa VM et dépendances pour éviter (même pas toujours) les ennuis/instabilités. Un gâchis faramineux.
Il n'y a bien que sous Androïd que Google semble avoir réussi, vu de (pas trop, j'espère?) haut tout du moins, à bien cadrer l'affaire. Au prix d'un applicatif bien lent tout de même, surtout à avoir snobbé Jazelle pour ne pas se lier pieds et poings à l'architecture ARM.
[^] # Re: Relativisons
Posté par lym . En réponse à la dépêche Portrait de Ken Thompson. Évalué à 0.
En même temps… c'était le prix Turing. Donc pas vraiment le lieu pour la pratique!
Pour le reste, quelque soit le domaine quasiment l'intégralité de ce qui est fait en bas niveau l'est désormais chez les fondeurs. Tout simplement car ils en ont besoin pour tester eux-mêmes (et des composants de plus en plus complexes) et que le logiciel libre (à travers de projets comme u-boot ou l'horreur EDKII, qui si Intel ne s'y était pas collé n'aurait jamais pu déployer un UEFI si inutilement complexe que de plus en plus de monde cherche à le remplacer…) offrait un cadre à mutualisation qui est aussi devenu un élément concurrentiel.
Ajoutons que chez certains (Intel pour ne pas le nommer), cela permet aussi de bâcler les docs: On fournit le code, prenez le donc et foutez nous la paix. De toutes manières notre support est nul!
Bref, vous achetez le dernier SoC de chez Cavium ou Freescale et le u-boot de la carte de référence sera donné, certes à adapter à votre matériel mais ça tourne et a un niveau ou le debug se fait à la bite et au couteau, mine de rien par rapport à il y a 20 ans ca compte. Surtout avec la complexité croissante des chips.
Côté Intel, on refusera tout support bas niveau, ne fournissant même pas les firmwares non signés (sauf à se faire vraiment botter le cul) et vous enverra vers un fournisseur de BIOS qui, en fait, n'est plus qu'un intégrateur du EDK2 fourni par Intel, des reference code (RC) de la plateforme (en particulier le gros morceau du MRC chargé de l'init DDR, faite toute en soft chez Intel contrairement à d'autres ou c'est un paramétrage et un enable suite auquel le hardware se démerde pendant quelques dizaines de ms et roule) également fournis par Intel (c'est la version source du FSP, qui permet à coreboot d'exister, mais avec qq API manquantes pour un projet industriel, c'est conçu pour!)… auquel on ajoute quelques libs (crypto etc) sous licence MIT et les petits ajouts cosmétiques d'un AMI/Insyde/Poenix ainsi que l'IDE qui va avec. Tout ceci bien entendu traînant sa chaîne de compilation: Intel pour le pur Intel (RC), Microsoft pour EDK2 (même si GCC semble utilisable ici) et le code de l'éditeur, GNU pour les libs libres.
Sur ce dernier point, proprement ahurissant de complexité inutile, on est sur EDK2 en implémentation de référence sur un nb de lignes de code comparable au kernel Linux. Pour un boot loader qui est loin derrière niveau fonctionnalités. Il faut dire qu'avec ses 3 phases (SEC/PEI/DXE) relativement étanches, pas mal de choses utiles aux trois doivent en réalité être codées en autant d'exemplaires.
=> La majorité du boulot en UEFI… c'est l'infra UEFI elle-même. Pas vraiment du bas niveau dont Intel se charge entièrement et fait tout pour que ça dure.
Niveau GPU, je ne connais pas personnellement mais je ne pense pas que grand chose sorte de chez NVIDIA ou AMD.
Il n'y a pas des dizaines de milliers de personnes, principalement chez un nombre de fondeurs principaux se comptant sur les doigts d'une main, sur ce qui tape vraiment bas.
[^] # Re: Relativisons
Posté par lym . En réponse à la dépêche Portrait de Ken Thompson. Évalué à -4.
Niveau sécurité, je ne crois pas qu'il y ait grand chose à relativiser dans sa prise en compte: Sa présentation à réception de son prix Turing est d'ailleurs fondatrice dans le domaine.
https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
Pour le reste, combien de personnes sont encore capables actuellement de coder un truc bare-metal, sans dépendances plus ou moins maîtrisées ni système de build tordu pour faire tomber tout cela en marche (avec le moindre "hello world" qui en sorte pesant quelques dizaines de MB)? Quelques centaines de personnes peut-être sur la masse mondiale des codeurs divers, sans doute plutôt désormais à rechercher chez les fondeurs dans les équipes qui supportent leurs reference design et spécialisées dans le démarrage initial d'un processeur… et pas vraiment pour faire un OS complet derrière.
Non, sincèrement, je ne vois rien à relativiser!
[^] # Re: Retour sur des grosses applications
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 2.
J'en parle, certes sans grande expérience de ce langage, car je trouve vraiment dangereux d'avoir a ce point voulu imposer une présentation propre (ce qui en soit se défend) aux dépens de la robustesse du langage (ce qui est indéfendable).
Surtout, encore une fois, que sans délimiteurs aucun outil ne peut décider automatiquement comment corriger le tir. Du C formaté cochon, en quelques milli-secondes c'est rectifiable automatiquement. Si on fait des "beautifier" de source, c'est justement pour ne pas s'emmerder à cela. Des boites les passent automatiquement, d'ailleurs, pour imposer sans douleur cette partie des règles de codage dès qu'on check-in des modifications de sa branche de dev. Simple et efficace. On peut même quand on prends des sources y coller son formatage préféré car on a le cerveau cablé depuis des années dessus, sans impact pour les autres. C'est la différence entre la mentalité BDFL, ou pas!
D'autres ont souligné plus haut que python 3 semble ne plus vouloir interpréter des lignes mixant tabulations et espaces. Comme quoi je n'ai pas dû être le seul à pester là dessus et j'espère même que cette vérification est faite au niveau du source complet. Sinon une ligne ajoutée en fin de bloc pré-existant avec un éditeur non configuré à l'identique du précédent peut aussi poser problème.
[^] # Re: Retour sur des grosses applications
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 0. Dernière modification le 11 septembre 2019 à 08:45.
Tout source passé par plusieurs éditeurs dont au moins un n'était pas configuré pour transformer les tabulations en espace peut poser le problème sur la/les lignes de fin de bloc.
Je ne crois par ailleurs pas avoir dit que C était plus fiable que Python. Juste que sauf bug compilo ou processeur, au moins il fait toujours ce que le programmeur voit dans son éditeur préféré. Qu'on l'évite de plus en plus partout ou il est évitable ne me pose pas de problème, mais bon, travaillant au ras des pâquerettes c'est forcément 99% de ce que je produis et si ca n'avait pas été le cas, n'importe quel autre langage utilisant des délimiteurs (cad l'immense majorité) aurait pu être pris en exemple.
Vu comme on nous flique sur ce qu'on livre, surtout depuis 10 ans que blackduck repère/colle une licence sur chaque bout de code y compris compilé (=> à partir de là, n'importe quel concurrent faisant un dump de votre firmware s'il y trouvait un bout de code GPL pouvait vous obliger à en publier des pans entiers ou vous bloquer niveau vente!), pas de risque d'aller à la pêche sur le net.
[^] # Re: Pourquoi je n'aime pas Python...
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 0.
Je n'ai pour ma part en effet fait que du 2, essentiellement pour de petits outils/scripts ou le shell montrait ses limites…
Bonne chose que cela ait été corrigé en 3. Désormais, je passe un "expand -t 8" dès que je récupère un source pour voir visuellement si un truc se décale. Mais c'est vraiment fastidieux car cela oblige à comprendre chaque bout de source ou le problème se présente pour savoir de quel côté il faut mettre la/les lignes en question.
[^] # Re: Retour sur des grosses applications
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 1.
Astyle reformate n'importe quel code C au goût de celui qui le reprends, sans erreur possible.
Forcément, là le style on s'en fout car la grammaire est robuste.
Délimiter les blocs avec des indentations est LA très mauvaise idée du Python ayant mené à des tétra-chiées de bugs sans doute fort coûteux.
Après cela, on a beau jeu de dire que le C est dangereux…
[^] # Re: Pourquoi je n'aime pas Python...
Posté par lym . En réponse à la dépêche Python pour la rentrée 2019 — partie 1 ― Popularité. Évalué à 3.
Ce qui éviterait d'avoir l'interpréteur qui exécute parfois un code qui n'est pas celui présenté visuellement à son auteur.
Ne pas avoir voulu mettre de délimiteur de bloc amène à cette situation. C'est certes volontaire pour pousser à présenter correctement, mais c'est hyper dangereux: Le nb de fois ou j'ai eu la fin d'un bloc qui était sorti du bloc après édition avec des éditeurs configurés différemment, sans que visuellement cela apparaisse.
Et sur un langage avec délimiteurs (genre {} en C), les outils automatiques permettent de reformater sans problème. Pas avec Python: Il faut avoir en tête ce que fait le programme pour savoir s'il y a un truc qui sort du bloc pour des questions de présentation ou non.
Le genre de "détail" qui flingue un langage pour une utilisation ou la fiabilité est fondamentale.
Se rendre compte qu'il y a un problème le jour ou la branche de code interprétée de travers (vs sa représentation visuelle) est exécutée, c'est vraiment un problème.
Un programme C mal présenté: Astyle s'en sort toujours. En Python, non.