Realize that for every good new idea that you hear about, there are at least a 100 that were funded, developed, and failed before you ever saw them. The naive reaction is “well, they were stupid”. That’s nonsense, history has shown over and over that we find new ideas amongst the insight we gain by building the bad ideas. Without doing that, we don’t learn what was bad and we don’t recognize what is good.
Comprenez que pour chaque nouvelle bonne idée dont vous entendez parler, il y en a au moins cent qui ont été financées, développées et ont échoué avant que vous ne les voyiez. La réaction naïve est « bon, elles étaient stupides ». C’est un non-sens, l’histoire a montré encore et encore que nous trouvons les nouvelles idées avec le recul obtenu en développant les mauvaises. Sans ça, nous n’apprenons pas ce qui était mauvais et nous ne reconnaissons pas ce qui est bien.
Larry Mc Voy, kerneltrap.org, 28/05/2002
C’est la version moderne du « c’est en forgeant qu’on devient forgeron », appliquée à l’innovation de manière globale. Tant de choses nous semblent évidentes et simples parce que mille autres théories, possibilités, configurations... ont été essayées sans succès. L’un des enjeux de l’informatique actuelle est de pouvoir continuer à expérimenter tous azimuts, sans se laisser enfermer par un choix technologique d’un fournisseur.
We are not tolerant people.
We prefer drastically effective solutions.
Nous ne somme pas des gens tolérants.
Nous préférons les solutions drastiquement efficaces.
(Anonyme)
Les informaticiens n’ont jamais été des gens portés sur la mesure et le compromis, ni portés à ménager la chèvre et le chou.
This product does exactly the source code says it does.
All other documentation is purely opinion.
Ce produit fait exactement ce que le code source dit qu’il fait.
Toute autre documentation est pure opinion.
(Anonyme)
À garder à l’esprit quand on lit la documentation d’un outil... Mais soyons honnête : la documentation pêche plutôt par sa pure et simple absence, et les bugs ne sont de toute manière pas documentés.
If a line of code doesn’t exist, then it cannot contain a bug.
Si une ligne de code n’existe pas, elle ne peut pas contenir un bug.
wowbagger, Slashdot.org, 23/01/2003
C’est simple mais il fallait y penser. C’est en partie à cause de leur verbosité que ne m’attirent ni Java (pas assez pratiqué pour le haïr de manière honnête), ni l’ABAP (l’existence même de ce langage est un non-sens), et par sa compacité que python me plaît.
Ce qui suit décrit une longue partie de mon existence gaspillée à maintenir du code écrit par des débutants ou des Indiens pour un ERP :
Don’t be afraid to refactor code every so often (...) Even good coders crumble to cost and schedule, and band-aid code that just plain needs to be rethought. In some environments, that’s a fact of life. In others you will have to fight for it, but you can get code rewritten.
In my experience, programming for an employer is the process of secretly introducing quality. This usually consists of debugging and refactoring on the sly while your pointy-haired boss thinks you're adding ‘features’.
Is it just me, or this the way it's done most places?
N’ayez pas peur de refactoriser le code de temps à autre (...) Même les bons développeurs doivent céder devant les coûts et les plannings, et les rustines a repenser complètement. Dans certains environnements, ça fait partie de la vie. Dans d’autres, vous devrez vous battre, mais vous arrivez à réécrire du code.
D’après mon expérience, programmer pour un employeur consiste à introduire secrètement la qualité. Cela consiste habituellement à déboguer et refactoriser furtivement pendant que votre incompétent de chef croit que vous ajoutez des « fonctionnalités ».
Est-ce juste moi, ou c’est comme ça que ça se passe presque partout ?
sbszine, Slashdot.org, 23/01/2003
Where I work, firing any number of the “developers” would thoroughly and permanently cripple the company. These guys are just irreplaceable. Use
Strict
?Option Explicit?
Comments? Documentation? Proper English? Any jedi craves not these things.
Là où je travaille, virer n’importe quel nombre de « développeurs » handicaperait complètement et définitivement la société. Ces gars sont irremplaçables. UtiliserStrict
?Option Explicit
? Des commentaires ? La documentation ? Du vrai français ? Un jedi n’a pas besoin de ces choses.
Darth_Burrito, Slashdot.org, 29/01/2003
Sans commentaire. Avoir du code glauque que l’on est seul à comprendre est à la fois une protection contre le chômage (illusoire quand le chef croit que n’importe quel Indien saura faire pareil), et contre toute promotion (une personne indispensable reste où elle est (problème des gens très compétents également)).
J’aime bien celle-là aussi, dans la série des priorités dans la vie :
Save the whales,
feed the hungry,
free the mallocs.
Sauvez les baleines,
nourrissez les affamés,
libérez lesmalloc
.
(Anonyme)
Évidemment, en python, c’est hors sujet...
2 réactions
1 De Steve Schnepp - 27/04/2009, 11:57
Vu que tu écris “et par sa compacité que python me plaît.”, tu devrais encore plus apprécier Perl alors :-)
Le sujet Perl/Python est évidemment assez emblématique (comme d’autres d’ailleurs : emacs/vi ?) du fait que l’informatique, c’est aussi un peu une religion :-)
Allez, encore un peu d’essence sur le feu : http://stackoverflow.com/questions/…
2 De Le webmestre - 27/04/2009, 20:34
@Steve : Ça doit pouvoir se démontrer en terme de théorie de l’information, mais tous les langages sont à peu près aussi compacts, une fois gzippés…
Le sous-entendu implicite était « langage lisible » :o)