Et toi tu fais semblant de pas comprendre que le multiprocessing élimine toute une classe de problèmes, et est donc très important pour permettre aux neuneus^W^W à tous de programmer, au même titre que les langages managés. Comme j'ai précisé, on peut transiger dans de nombreux cas. Mais pour en revenir un peu à la choucroute l'argument initial pour firefox de "oh mon dieu nettoyer vraiment toussa c'est dur et tout, faisons plutôt des trucs biens à court terme" est in my not at all humble opinion un mauvais calcul pour les deux raisons magiques en question : stabilité (sur un code volumineux on obtient des effets statistiques, donc la stabilité serait mécaniquement meilleure si l'architecture cherchait à empêcher des classes de pb par sa conception), accessibilité aux contributions. Je peux en ajouter d'autre : revues et raisonnements plus faciles...
Sur la multiprogrammation, je ne sais pas si j'ai tout compris, mais en tout cas j'ai compris pas mal de chose en effet. Mon taf m'a amené à débugger du code multithreadé dans divers couches télécoms libres, où malheureusement les fameux deadlocks se ramassent à la tracto-pelle. Bref, en résumé, j'ai nettoyé à moultes reprises la merde laissée par d'autres, qui pensaient sans doute être suffisamment malins pour ne pas avoir fait caca partout. A voir certaines immondices je suis certain d'être plus malin que certains d'entre eux, mais sans doute pas que tous. Partant de ce constat, j'estime qu'il est futile d'étaler sa maîtrise du multithreading ad-hoc car soit on est juste plus mauvais qu'on croit et on fait caca partout, soit certes on fait un truc qui fonctionne, mais celui qui passe après ne va pas comprendre toutes les subtilités et le château de carte en équilibre instable va finir par s'effondrer. Ce schéma transparaît clairement dans le code de nombreux logiciels. Seules des revues poussées permettent d'éviter cela (cf. Linux) mais tous les projets ne les imposent pas et/ou les revues peuvent être inapplicables dans certains contexte (exemple : plug-in tiers), et si une architecture permet d'avoir des revues moins poussées et/ou de tolérer un peu plus du code tiers buggé alors elle est préférable. (On peut aussi choisir la solution très tendance du moment de MS et d'Apple : interdire les plugins.)
C'est pas des arguments d'autorité toussa (de quelle autorité d'abord ???), c'est des règles d'ingénierie et des constats de gestion de projet logiciel. Mais je sais, je sais, l'ingénierie c'est plus vraiment à la mode.
[^] # Re: à troll troll et demi
Posté par Guillaume Knispel . En réponse au journal Mozilla, son cycle de développement de 6 semaines et Eletrolysis. Évalué à 2.
Et toi tu fais semblant de pas comprendre que le multiprocessing élimine toute une classe de problèmes, et est donc très important pour permettre aux neuneus^W^W à tous de programmer, au même titre que les langages managés. Comme j'ai précisé, on peut transiger dans de nombreux cas. Mais pour en revenir un peu à la choucroute l'argument initial pour firefox de "oh mon dieu nettoyer vraiment toussa c'est dur et tout, faisons plutôt des trucs biens à court terme" est in my not at all humble opinion un mauvais calcul pour les deux raisons magiques en question : stabilité (sur un code volumineux on obtient des effets statistiques, donc la stabilité serait mécaniquement meilleure si l'architecture cherchait à empêcher des classes de pb par sa conception), accessibilité aux contributions. Je peux en ajouter d'autre : revues et raisonnements plus faciles...
Sur la multiprogrammation, je ne sais pas si j'ai tout compris, mais en tout cas j'ai compris pas mal de chose en effet. Mon taf m'a amené à débugger du code multithreadé dans divers couches télécoms libres, où malheureusement les fameux deadlocks se ramassent à la tracto-pelle. Bref, en résumé, j'ai nettoyé à moultes reprises la merde laissée par d'autres, qui pensaient sans doute être suffisamment malins pour ne pas avoir fait caca partout. A voir certaines immondices je suis certain d'être plus malin que certains d'entre eux, mais sans doute pas que tous. Partant de ce constat, j'estime qu'il est futile d'étaler sa maîtrise du multithreading ad-hoc car soit on est juste plus mauvais qu'on croit et on fait caca partout, soit certes on fait un truc qui fonctionne, mais celui qui passe après ne va pas comprendre toutes les subtilités et le château de carte en équilibre instable va finir par s'effondrer. Ce schéma transparaît clairement dans le code de nombreux logiciels. Seules des revues poussées permettent d'éviter cela (cf. Linux) mais tous les projets ne les imposent pas et/ou les revues peuvent être inapplicables dans certains contexte (exemple : plug-in tiers), et si une architecture permet d'avoir des revues moins poussées et/ou de tolérer un peu plus du code tiers buggé alors elle est préférable. (On peut aussi choisir la solution très tendance du moment de MS et d'Apple : interdire les plugins.)
C'est pas des arguments d'autorité toussa (de quelle autorité d'abord ???), c'est des règles d'ingénierie et des constats de gestion de projet logiciel. Mais je sais, je sais, l'ingénierie c'est plus vraiment à la mode.