Je prend un exemple pour illustrer (et pas des moindres il me semble), ça ne veut pas dire qu'il n'y en a pas d'autres. Qui n'a jamais pesté sur le fait qu'il n'y a quasiment jamais de bug trackers sur les produits privatifs ?
Je veux bien un exemple d'une boite qui serait passé de postgresql à MSAccess pour raison technique.
Je n'en fait pas une généralité je constate juste que le côté hacker est une compétence et qu'elle a l'air de manquer à certains. Personnellement c'est le premier intérêt que j'ai trouvé, à l'époque (de minix) on ne parlait même pas de liberté, c'était juste éducatif. Il ne faut pas oublier ce lien étroit entre logiciel libre et éducation (donc compétence), passion etc.
Que penses-tu d'une boite comme apisoft (racheté par sage), qui a un existant sous MSAccess, qui est passé à Oracle (on comprends pourquoi) pour finalement revenir à MSAccess (parcequ'ils n'ont jamais réussi à faire marcher Oracle correctement) ?
Y a de quoi se poser des questions sur les compétences techniques non ?
Vous allez me dire que ce sont des décisions marketings. Mais je suis allé à une formation technique chez eux lorsqu'ils sont passé à Oracle, c'était à mourir de rire de les voir essayer pendant 2h tant bien que mal de se connecter à Oracle avec windev ou vb ou je ne sais quoi… C'est bien un problème de compétence car quand je leur ai montré comment je faisais en deux lignes avec import cx_oracle ils n'en revenaient pas, ils n'avaient jamais entendu parlé de ce genre de possibilités. Et c'est bien un problème de "fans du libre", car comme tout bon hacker il m'est arrivé également de regarder windev et surtout de comprendre comment le système fonctionne ce qui m'a permis de les aider finalement.
Je ne vous parle même pas de la doc fournie, je ne vous parle même pas des règles de sécurité sur l'accès à la base, à des années lumières du premier blog en php d'un ado.
Donc, il n'y a pas que les hackers qui sont compétents, mais ça aide quand même beaucoup…
La plupart du temps j'ai remarqué que ce qui empêche de passer à Postgresql c'est l'existant. Autant pour ce qui tourne (et qu'il ne faut pas pas toucher puisque ça tourne) que pour les compétences. C'est une sorte d'inertie, d'autant plus grande que la boite est grosse.
Ceci dit, je trouve que c'est exagéré, on s'en fait une montagne alors que le temps passé pour mettre à jour une appli de mysql à postgresql permet souvent en même temps de faire un audit de l'application et déceler quelques bugs potentiels ou goulots d'étranglements. Pire, le temps passé à se poser la question de la migration est parfois plus grand que le temps pour la faire la mise à jour !
On le comprend très bien ici, mais le site de démo n'est pas destiné qu'aux devs, ça vaudrait vraiment le coup de l'indiquer clairement sur le site. D'une part pour informer les utilisateurs et d'autre part pour inciter les devs à participer. Sur ce je vais aller faire une petite série…
Posté par wilk .
En réponse à la dépêche Awesome 3.5.
Évalué à 1.
Jusque là je le fait aussi avec fluxbox puisqu'on peut mémoriser l'emplacement et le workspace des fenêtres. Je fait pareil avec le navigateur et le client mail qui sont donc toujours dans leurs workspaces respectifs et à la même place. C'est vrai que je peux lancer plusieurs fois le client mail, mais si je voulais m'en préserver je pourrai faire un petit script pour ça.
Posté par wilk .
En réponse à la dépêche Awesome 3.5.
Évalué à 3.
Je n'ai à priori pas d'autres critères que de pouvoir contrôler mes quelques fenêtres avec les raccourcis VIM. Mais peut-être que je passe à côté de quelque chose dont je n'ai même pas l'idée ?
Posté par wilk .
En réponse à la dépêche Awesome 3.5.
Évalué à 2.
Je me demande toujours quels seraient les avantages par rapport à fluxbox par ex vu que je le pilote déjà entièrement au clavier avec des raccourcis à la vim…
L'idée de la démo en première page c'est un sacré pari, bravo, ça va permettre de faire remonter les bugs d'une part et d'aider le décideur pressé d'autre part.
J'aurai juste une remarque, pour le décideur pressé justement, le mélange d'anglais/français en plein milieu des menus et formulaires ne donne pas l'impression d'un produit finis, ou du moins pas prêt pour le marché français. On se dit tout de suite qu'il risque d'y avoir des soucis pour la paye et la compta par ex (est-ce le cas ?).
pypy est en cours de portage, il va y a un développeur payé pour ça (depuis 4 jours). Encore mieux, le projet prévoit de supporter la 2 et la 3 avec le même code. Le top serait de pouvoir utiliser du code 2 et du code 3 en même temps, ça serait idéal pour les migrations, sinon c'est vrai que c'est un peu le casse tête, il y a toujours une librairie qui manque…
J'ai quelques outils dont je me sert quotidiennement pour mon boulot, qui tournent donc en production, parfois même en milieu industriel, je les libérerai volontiers mais j'ai l'impression que ça me donnerait beaucoup trop de boulot et surtout que ça me contraindrai dans les évolutions. Comme je suis quasiment seul à les utiliser ils évoluent au fur et à mesure de mes besoins, ni plus ni moins, je peux même enlever des fonctionnalités si je sais que je ne m'en servirai plus (pour ne pas encombrer).
Je n'ai pas non plus envie d'en faire la propagande, je ne suis pas spécialement fier de ce que j'ai fait, ça marche pour moi (et mes clients), c'est tout. Quand on développe seul ou presque, on n'a pas à gérer tout un tas de cas de figures dont on sait qui n'arriveront jamais, inversement on doit gérer des cas qui ne concernent plus personne et dont on a plutôt envie de dissuader les autres (par exemple accéder à des bases Access !)
Autre problème, c'est un cercle vicieux, j'utilise mes outils pour créer toutes sortes de projets qui pourraient être libérés (gestion de tâches, compta, sel, blog etc…) ils sont donc interdépendants, il faudrait donc les libérer tous (les outils) ou aucun.
La plupart de ces outils sont finalement assez communs, orm, framework web… Il y en a déjà trop, je ne trouve pas vraiment opportun d'en ajouter d'autres.
Souvent je me dis que je les libérerai quand je serai à la retraite ! mais je ne suis pas sûr que la retraite existe en profession libérale.
Bref, des avis sur le fait qu'il y a déjà pléthore de projets libres et qu'il vaut peut-être mieux s'intéresser aux existants qu'a en rajouter d'autres plus ou moins similaires ?
Voilà l'explication. Pour coder tout seul sur une base de code que tu maîtrises à 100%, dont tu as tout l'historique et l'évolution en tête et dont tu connais parfaitement le domaine fonctionnel un langage très flexible est effectivement souvent une facilité.
Je code souvent tout seul mais j'utilise quand même des bibliothèques externes, parfois j'y contribue. Donc si ça ne devait pas impacter mon propre code, ça devrait quand même avoir un impact sur ma capacité à pouvoir utiliser celui des autres. Hors non, comme je l'ai déjà écrit, je passe moins de temps sur les bibliothèques externes qu'avant et je peux plus facilement contribuer à des bibliothèques externes…
Je n'ai jamais dis que j'avais 20 ans d'xp en python, j'ai fais du java, du C etc aussi (j'en ai mangé du statique !)… Mais je ne veux pas mettre mon xp en avant, la durée n'a rien à voir avec la qualité, c'était juste pour témoigner.
L'avantage en python c'est que le code (pour lire un fichier ou autre) ne sera pas forcément le même suivant le contexte. Il sera très robuste si c'est nécessaire sinon il ne sera pas inutilement lourd.
Par exemple un accès fichier robuste devrait obligatoirement faire un contrôle sur le chemin, tout comme une date de naissance devra vérifier qu'elle est cohérente, ce qui est une erreur bien plus fréquente. La vérification du type et la lourdeur obligatoire autour fait faussement croire que le code va être robuste. Il n'est robuste que pour le compilateur, pas pour l'utilisation.
Un bon exemple où la lourdeur n'est pas nécessaire (et dissuasive) c'est quand on écrit des tests unitaires par ex. Je me sert souvent des tests unitaires comme documentation, il faut qu'ils soient le plus concis possibles. Dans un test unitaire, lire un fichier texte ça doit tenir sur une ligne sans nécessiter de bibliothèque tierce. L'idéal serait je pense d'avoir du typage statique que quand c'est nécessaire, il y a des prémices en python il me semble et on peut déjà utiliser des outils comme pylint pour faire certains contrôles avant exécution, mais au moins ça n'interdit pas les avantages du dynamique et interprété.
Et quand t'arrête de faire des Hello world, des projets d'école et de coder dans ton coin ça donne quoi ?
Si l'expérience est un critère, ça fait bientôt 20 ans que je code à mon compte et que je dois donc assumer tous les choix d'outils de développement que j'ai fais. Si je fais du prosélytisme autour de Python c'est que ma fois je lui dois sûrement ma maison et tout le temps que je peux passer avec mes enfants. Je me souviens de la période où je programmais en Java, en vacance j'avais toujours un livre avec moi !
Tu remarqueras un jour petit scarabée que la programmation n'est qu'une suite de petites choses toutes simples que l'on s'évertue bien souvent à compliquer inutilement.
Tu vois, toi-même tu préfère écrire du java comme si c'était du python ;-)
Il manque quelques décorations autour non ? et il faut carrément une bibliothèque externe pour ça. tu as même oublié le ; !
C'est marrant, je fait l'inverse, langage dynamique pour la plus grosse partie du code et du statique pour les petites parties où la perf est primordiale par ex.
Je sais pas si c'est avec toi que j'en avais déjà discuté mais on m'a déjà sorti l'exemple du X509. Dernièrement j'ai eu à l'utiliser, je confirme volontiers que la doc est imbitable (on dirait presque que c'est moi qui l'ai faite ;-p) mais c'est une exception, on ne peut pas généraliser avec cet exemple. C'est vraiment rare que je me casse la tête sur une bibliothèque comme ça.
Sans doc l'ide va t'aider avec le prototype en java, sans doc je peux assez facilement lire le code en python… C'est au cas par cas après, il faut voir le résultat à la longue (et le contexte bien sûr, dev seul ou en équipe etc.)
Ca m'arrive souvent, en particulier dans mes bibliothèque perso car j'essaye de coder de manière à ce que ce soit facile à relire par la suite. Si je documente j'essaye de faire des doctests.
Dans tous les cas je ne passe pas beaucoup de temps que ce soit dans la doc ou dans le code des bibliothèques, au bout d'un moment j'utilise généralement toujours les mêmes, elles sont suffisamment intuitives pour que je n'ai pas à revenir dessus.
Peut-être que c'est parce que je me fait une règle d'utiliser peu de choses mais que je connais bien ? mais ce qui est sûr c'est qu'en procédant de la même manière en Java, pour exactement les mêmes types d'application j'y passe beaucoup moins de temps. C'est plus une constatation qu'un théorie.
[^] # Re: .
Posté par wilk . En réponse au journal Switch de MySQL vers MariaDB. Merci Oracle ?. Évalué à 4.
Je prend un exemple pour illustrer (et pas des moindres il me semble), ça ne veut pas dire qu'il n'y en a pas d'autres. Qui n'a jamais pesté sur le fait qu'il n'y a quasiment jamais de bug trackers sur les produits privatifs ?
Je veux bien un exemple d'une boite qui serait passé de postgresql à MSAccess pour raison technique.
Je n'en fait pas une généralité je constate juste que le côté hacker est une compétence et qu'elle a l'air de manquer à certains. Personnellement c'est le premier intérêt que j'ai trouvé, à l'époque (de minix) on ne parlait même pas de liberté, c'était juste éducatif. Il ne faut pas oublier ce lien étroit entre logiciel libre et éducation (donc compétence), passion etc.
[^] # Re: .
Posté par wilk . En réponse au journal Switch de MySQL vers MariaDB. Merci Oracle ?. Évalué à 5.
Que penses-tu d'une boite comme apisoft (racheté par sage), qui a un existant sous MSAccess, qui est passé à Oracle (on comprends pourquoi) pour finalement revenir à MSAccess (parcequ'ils n'ont jamais réussi à faire marcher Oracle correctement) ?
Y a de quoi se poser des questions sur les compétences techniques non ?
Vous allez me dire que ce sont des décisions marketings. Mais je suis allé à une formation technique chez eux lorsqu'ils sont passé à Oracle, c'était à mourir de rire de les voir essayer pendant 2h tant bien que mal de se connecter à Oracle avec windev ou vb ou je ne sais quoi… C'est bien un problème de compétence car quand je leur ai montré comment je faisais en deux lignes avec import cx_oracle ils n'en revenaient pas, ils n'avaient jamais entendu parlé de ce genre de possibilités. Et c'est bien un problème de "fans du libre", car comme tout bon hacker il m'est arrivé également de regarder windev et surtout de comprendre comment le système fonctionne ce qui m'a permis de les aider finalement.
Je ne vous parle même pas de la doc fournie, je ne vous parle même pas des règles de sécurité sur l'accès à la base, à des années lumières du premier blog en php d'un ado.
Donc, il n'y a pas que les hackers qui sont compétents, mais ça aide quand même beaucoup…
[^] # Re: .
Posté par wilk . En réponse au journal Switch de MySQL vers MariaDB. Merci Oracle ?. Évalué à 4.
La plupart du temps j'ai remarqué que ce qui empêche de passer à Postgresql c'est l'existant. Autant pour ce qui tourne (et qu'il ne faut pas pas toucher puisque ça tourne) que pour les compétences. C'est une sorte d'inertie, d'autant plus grande que la boite est grosse.
Ceci dit, je trouve que c'est exagéré, on s'en fait une montagne alors que le temps passé pour mettre à jour une appli de mysql à postgresql permet souvent en même temps de faire un audit de l'application et déceler quelques bugs potentiels ou goulots d'étranglements. Pire, le temps passé à se poser la question de la migration est parfois plus grand que le temps pour la faire la mise à jour !
[^] # Re: Et le français (partout) ?
Posté par wilk . En réponse à la dépêche OpenERP 7 vient de sortir. Évalué à 1.
On le comprend très bien ici, mais le site de démo n'est pas destiné qu'aux devs, ça vaudrait vraiment le coup de l'indiquer clairement sur le site. D'une part pour informer les utilisateurs et d'autre part pour inciter les devs à participer. Sur ce je vais aller faire une petite série…
[^] # Re: vs fluxbox ?
Posté par wilk . En réponse à la dépêche Awesome 3.5. Évalué à 1.
Jusque là je le fait aussi avec fluxbox puisqu'on peut mémoriser l'emplacement et le workspace des fenêtres. Je fait pareil avec le navigateur et le client mail qui sont donc toujours dans leurs workspaces respectifs et à la même place. C'est vrai que je peux lancer plusieurs fois le client mail, mais si je voulais m'en préserver je pourrai faire un petit script pour ça.
[^] # Re: vs fluxbox ?
Posté par wilk . En réponse à la dépêche Awesome 3.5. Évalué à 3.
Je n'ai à priori pas d'autres critères que de pouvoir contrôler mes quelques fenêtres avec les raccourcis VIM. Mais peut-être que je passe à côté de quelque chose dont je n'ai même pas l'idée ?
# vs fluxbox ?
Posté par wilk . En réponse à la dépêche Awesome 3.5. Évalué à 2.
Je me demande toujours quels seraient les avantages par rapport à fluxbox par ex vu que je le pilote déjà entièrement au clavier avec des raccourcis à la vim…
[^] # Re: Voir la demo
Posté par wilk . En réponse à la dépêche OpenERP 7 vient de sortir. Évalué à 4.
L'idée de la démo en première page c'est un sacré pari, bravo, ça va permettre de faire remonter les bugs d'une part et d'aider le décideur pressé d'autre part.
J'aurai juste une remarque, pour le décideur pressé justement, le mélange d'anglais/français en plein milieu des menus et formulaires ne donne pas l'impression d'un produit finis, ou du moins pas prêt pour le marché français. On se dit tout de suite qu'il risque d'y avoir des soucis pour la paye et la compta par ex (est-ce le cas ?).
[^] # Re: Pour se faire une idée des perfs
Posté par wilk . En réponse à la dépêche Sortie de LuaJIT 2.0.0. Évalué à 2.
Facteur 10, facteur 20… Il faudrait peut-être quelques exemples sinon on se retrouve un peu à laver plus blanc que blanc !
[^] # Re: Rabat joie
Posté par wilk . En réponse à la dépêche Expérience de déploiements d’OpenERP dans des entreprises françaises. Évalué à 2.
Est-ce que tu pourrais nous en dire un peu plus sur la "problèmatique des migrations" ?
[^] # Re: Souhaitons une belle mort à PHP
Posté par wilk . En réponse à la dépêche Sortie de txt2tags en version PHP. Évalué à 3.
pypy est en cours de portage, il va y a un développeur payé pour ça (depuis 4 jours). Encore mieux, le projet prévoit de supporter la 2 et la 3 avec le même code. Le top serait de pouvoir utiliser du code 2 et du code 3 en même temps, ça serait idéal pour les migrations, sinon c'est vrai que c'est un peu le casse tête, il y a toujours une librairie qui manque…
http://morepypy.blogspot.fr/2012/09/py3k-status-update-6.html
[^] # Re: Editeur Wysiwyg ?
Posté par wilk . En réponse au journal Nouvel article de Bret Victor sur sa vision de l'environnement de développement du futur. Évalué à 3.
Et les développeurs ne les utilisèrent pas et furent tous punis : obligés de programmer en Java.
# Trop de contraintes ?
Posté par wilk . En réponse au sondage Je repousse sans arrêt le lancement de mon projet de logiciel libre, car:. Évalué à 3.
J'ai quelques outils dont je me sert quotidiennement pour mon boulot, qui tournent donc en production, parfois même en milieu industriel, je les libérerai volontiers mais j'ai l'impression que ça me donnerait beaucoup trop de boulot et surtout que ça me contraindrai dans les évolutions. Comme je suis quasiment seul à les utiliser ils évoluent au fur et à mesure de mes besoins, ni plus ni moins, je peux même enlever des fonctionnalités si je sais que je ne m'en servirai plus (pour ne pas encombrer).
Je n'ai pas non plus envie d'en faire la propagande, je ne suis pas spécialement fier de ce que j'ai fait, ça marche pour moi (et mes clients), c'est tout. Quand on développe seul ou presque, on n'a pas à gérer tout un tas de cas de figures dont on sait qui n'arriveront jamais, inversement on doit gérer des cas qui ne concernent plus personne et dont on a plutôt envie de dissuader les autres (par exemple accéder à des bases Access !)
Autre problème, c'est un cercle vicieux, j'utilise mes outils pour créer toutes sortes de projets qui pourraient être libérés (gestion de tâches, compta, sel, blog etc…) ils sont donc interdépendants, il faudrait donc les libérer tous (les outils) ou aucun.
La plupart de ces outils sont finalement assez communs, orm, framework web… Il y en a déjà trop, je ne trouve pas vraiment opportun d'en ajouter d'autres.
Souvent je me dis que je les libérerai quand je serai à la retraite ! mais je ne suis pas sûr que la retraite existe en profession libérale.
Bref, des avis sur le fait qu'il y a déjà pléthore de projets libres et qu'il vaut peut-être mieux s'intéresser aux existants qu'a en rajouter d'autres plus ou moins similaires ?
[^] # Re: typage strict
Posté par wilk . En réponse à la dépêche Sortie de Rust en version 0.3. Évalué à 1.
Par rapport au langage machine (c'est pas péjoratif, je déconne pas).
[^] # Re: Requêtes simultanées
Posté par wilk . En réponse à la dépêche Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org. Évalué à 3.
Merci Bruno pour cette belle démonstration de Go.
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 2.
Fait gaffe, ça fait deux fois que tu penche vers des méthodes toutes pythonesques ;-)
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 3.
Je code souvent tout seul mais j'utilise quand même des bibliothèques externes, parfois j'y contribue. Donc si ça ne devait pas impacter mon propre code, ça devrait quand même avoir un impact sur ma capacité à pouvoir utiliser celui des autres. Hors non, comme je l'ai déjà écrit, je passe moins de temps sur les bibliothèques externes qu'avant et je peux plus facilement contribuer à des bibliothèques externes…
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 4.
Je n'ai jamais dis que j'avais 20 ans d'xp en python, j'ai fais du java, du C etc aussi (j'en ai mangé du statique !)… Mais je ne veux pas mettre mon xp en avant, la durée n'a rien à voir avec la qualité, c'était juste pour témoigner.
L'avantage en python c'est que le code (pour lire un fichier ou autre) ne sera pas forcément le même suivant le contexte. Il sera très robuste si c'est nécessaire sinon il ne sera pas inutilement lourd.
Par exemple un accès fichier robuste devrait obligatoirement faire un contrôle sur le chemin, tout comme une date de naissance devra vérifier qu'elle est cohérente, ce qui est une erreur bien plus fréquente. La vérification du type et la lourdeur obligatoire autour fait faussement croire que le code va être robuste. Il n'est robuste que pour le compilateur, pas pour l'utilisation.
Un bon exemple où la lourdeur n'est pas nécessaire (et dissuasive) c'est quand on écrit des tests unitaires par ex. Je me sert souvent des tests unitaires comme documentation, il faut qu'ils soient le plus concis possibles. Dans un test unitaire, lire un fichier texte ça doit tenir sur une ligne sans nécessiter de bibliothèque tierce. L'idéal serait je pense d'avoir du typage statique que quand c'est nécessaire, il y a des prémices en python il me semble et on peut déjà utiliser des outils comme pylint pour faire certains contrôles avant exécution, mais au moins ça n'interdit pas les avantages du dynamique et interprété.
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 2.
Si l'expérience est un critère, ça fait bientôt 20 ans que je code à mon compte et que je dois donc assumer tous les choix d'outils de développement que j'ai fais. Si je fais du prosélytisme autour de Python c'est que ma fois je lui dois sûrement ma maison et tout le temps que je peux passer avec mes enfants. Je me souviens de la période où je programmais en Java, en vacance j'avais toujours un livre avec moi !
Tu remarqueras un jour petit scarabée que la programmation n'est qu'une suite de petites choses toutes simples que l'on s'évertue bien souvent à compliquer inutilement.
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 1.
Tu arrives à écrire plus de code en python qu'en java, trop fort, je ne peux que m'incliner.
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 1.
Tu vois, toi-même tu préfère écrire du java comme si c'était du python ;-)
Il manque quelques décorations autour non ? et il faut carrément une bibliothèque externe pour ça. tu as même oublié le ; !
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 1.
Regarde le code qu'il faut écrire en Java pour lire un fichier texte, au prix où est la ligne aujourd'hui j'ai pas les moyens :-)
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 3.
C'est marrant, je fait l'inverse, langage dynamique pour la plus grosse partie du code et du statique pour les petites parties où la perf est primordiale par ex.
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 2.
Je sais pas si c'est avec toi que j'en avais déjà discuté mais on m'a déjà sorti l'exemple du X509. Dernièrement j'ai eu à l'utiliser, je confirme volontiers que la doc est imbitable (on dirait presque que c'est moi qui l'ai faite ;-p) mais c'est une exception, on ne peut pas généraliser avec cet exemple. C'est vraiment rare que je me casse la tête sur une bibliothèque comme ça.
Sans doc l'ide va t'aider avec le prototype en java, sans doc je peux assez facilement lire le code en python… C'est au cas par cas après, il faut voir le résultat à la longue (et le contexte bien sûr, dev seul ou en équipe etc.)
[^] # Re: Le titre est trop long
Posté par wilk . En réponse au journal Typage statique versus typage dynamique. Évalué à 1.
Ca m'arrive souvent, en particulier dans mes bibliothèque perso car j'essaye de coder de manière à ce que ce soit facile à relire par la suite. Si je documente j'essaye de faire des doctests.
Dans tous les cas je ne passe pas beaucoup de temps que ce soit dans la doc ou dans le code des bibliothèques, au bout d'un moment j'utilise généralement toujours les mêmes, elles sont suffisamment intuitives pour que je n'ai pas à revenir dessus.
Peut-être que c'est parce que je me fait une règle d'utiliser peu de choses mais que je connais bien ? mais ce qui est sûr c'est qu'en procédant de la même manière en Java, pour exactement les mêmes types d'application j'y passe beaucoup moins de temps. C'est plus une constatation qu'un théorie.