wilk a écrit 1096 commentaires

un langage simple et élégant[réf.souhaitée]

Par rapport au langage machine (c'est pas péjoratif, je déconne pas).

Merci Bruno pour cette belle démonstration de Go.

Fait gaffe, ça fait deux fois que tu penche vers des méthodes toutes pythonesques ;-)

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 arrives à écrire plus de code en python qu'en java, trop fort, je ne peux que m'incliner.

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 ; !

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

dépasser les 200 lignes ⇒ adios le dynamique

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.

C'est le genre d'exemple qui illustre bien pourquoi faire simple quand on peut faire compliqué juste pour faire plaisir au compilo. L'algo va être complètement noyé, le développeur va passer un temps fou à gérer les types au lieu de s'intéresser à l'algo.

Tu critique et tu répond à la question en même temps.
Quand je programmais en Java j'adorais la documentation, toujours le nez dedans et je lisais pleins de livres passionnants. En python je n'ai jamais eu à acheter un seul livre, la documentation je ne la survole que de temps en temps. Dans mon code, pareil, je le documente rarement, non pas par flemme mais parce que c'est souvent inutile tellement le code est explicite et tien sur un écran. Ca évite également d'avoir une documentation qui n'est pas à jour !
L'exemple classique c'est pour lire un fichier en Java et en python, dans un cas la doc est indispensable !

Ensuite si tu passes ton temps à lancer ton appli et à la tester tu es juste entrain de réinventer les tests unitaires, qui sont nécessaires autant avec un typage statique que dynamique. Par contre, avec un typage statique, même le code des tests unitaires devra être explicitement typé, quel intérêt ?

De toutes façon tout ça est subjectif, ça dépend vraiment des cas, peut-être des personnes… On le voit bien dans les expériences décrites dans les commentaires. Pour moi il n'y a pas photo, le gain que ce soit en temps de développement qu'en maintenance est très largement supérieur avec python que java (sachant que je viens du C et ASM).

foo(int, int) est in-détectable non plus

Détectable,

def date_de_naissance(int, int, int)

date_de_naissance(2010, 9, 14)
date_de_naissance(9, 10, 3923)

Le compilo ne détecte rien du tout, ni l'ordre des paramètres ni leur cohérence. On se retrouve exactement dans le même cas qu'avec tes canards.

Si on veut être prudent on va dire
date_de_naissance(jour, mois, annee)

date_de_naissance(jour=4, mois=3, annee=1950)
L'interpréteur ne va rien vérifier du tout mais on a beaucoup moins de chance de se tromper.

Le compilateur va trouver certaines fautes, c'est incontestable, mais si c'est au détriment d'un code beaucoup plus lourd le gain est annulé et même inversé. Du moins c'est ce que j'ai constaté en passant de Java à Python par ex.

Le rapport avec google et yahoo, si tu te souviens, c'est que leur première interface était épuré et ne servait qu'à une seule chose, sans fioriture à l'opposé de yahoo qui présentait tout un tas de fonctionnalités encombrantes. Ca a cartonné, personne n'y croyait au départ. Personnellement je l'ai nettement vu dans mon boulot, un attirance (chez les utilisateurs) maintenant vers des outils épurés qui ne font qu'une chose bien spécifique.

Et il n'y a pas besoin d'être un hacker pour aimer conserver les choses qui marchent
Je suis d'accord. À supposer qu'elles marchent de façon satisfaisante et qu'elles remplissent les besoins actuels. Libre à toi d'essayer de convaincre les utilisateurs que mutt répond à leurs besoins.

La question n'est pas de convaincre d'utiliser mutt, mais de les inciter à choisir des outils pérennes qui n'ont pas besoin de changer juste pour changer. Et pour ça, forcément c'est beaucoup plus difficile si l'outil en question fait trop de choses diverses. La séparation firefox / thunderbird était une bonne chose par ex.

Pypy est souvent bluffant au niveau des performances. C'est le premier à essayer à essayer vu qu'il n'y a rien à changer au code.

foo(int, int) est in-détectable non plus, open(string), qui va vérifier si le string est bien un nom de fichier et pas un nom d'oiseau ? On pourrait multiplier les exemples avec tout ce qui touche à l'interface utilisateur (a t'il bien rentré le jour avant le mois ?), ou a une requête sql (le compilateur va-t'il aller vérifier le type des champs d'une bdd ?) etc. Le typage s'adresse au compilateur, pas au développeur, sinon le nommage des paramètres serait obligatoire par ex.

le même éditeur de texte depuis 30 ans, avec les mêmes raccourcis claviers

Ah oui, cette mentalité de conservateurs auto-satisfaits qui nous donne des outils à l'ergonomie de m*rde, sans la moindre harmonisation des UI.

Comme ergonomie de m*erde tu penses à google par rapport à yahoo ? La philosophie unix c'est "do one thing and do it well", on aime ou on n'aime pas mais il n'y a pas de honte à en être satisfait. L'harmonisation des UI ? mais figure toi que j'utilise exactement les mêmes raccourcis dans mon éditeur de texte, mon navigateur, mon window manager et j'en passe, raccourcis que je connais depuis plus de 20 ans…
Et il n'y a pas besoin d'être un hacker pour aimer conserver les choses qui marchent. C'est comme un stylo, imagine que chaque année on soit obligé d'apprendre à tenir son stylo d'une nouvelle façon !

Tes utilisateurs ils n'ont pas l'esprit unix c'est tout, ils veulent faire tout et n'importe quoi avec la même usine à gaz. Ensuite ils vont se plaindre que "l'informatique ça change tout le temps", "il faut suivre", "il faut du matériel toujours plus puissant" etc… Pendant ce temps à côté, une petite boite de libristes utilise un outil efficace pour chaque chose, le même éditeur de texte depuis 30 ans, avec les mêmes raccourcis claviers, le même rasoir de sécurité et ne perd pas son temps à des futilités.

Pourquoi un clickodrome comme pan plutôt que slrn ?

Tu veux dire qu'elles risquent de faire la tête car le gain de productivité avec mutt va mettre en péril un de leurs emplois ?

Ca n'est pas qu'une question de volume, c'est relatif à la machine et au type de contenu, surtout en proxy pour des applis. Sur une petite machine Nginx prend aussi toute sa valeur. T'as perdu ton pari, j'ai sauvé un serveur virtualisé comme ça, rien qu'en passant d'apache à nginx.

Après quelques recherche j'ai cru comprendre qu'en base 100 on pourrait faire passer les deux dans le même cable (8 fils), en giga les 8 fils sont utilisés il faut donc 2 cables, j'ai bon ?

Comment ça se passe pour avoir le net ET le téléphone en même temps dans une pièce ? Un cable et deux prises femelles rj45 ?