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: 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.