wilk a écrit 1201 commentaires

Parce qu'il est tellement pratique que pour ce que je fait ça a fait mentir l'adage comme quoi on programme mieux dans le langage qu'on connait le mieux et avec celui qui est en théorie le plus adapté au besoin. Le tout qui se vérifie sur la durée au niveau de la maintenance.
Que demander de plus ?

Ce que je fait avec ? Des scripts d'admin, de graphisme, de gestion, en ligne ou pas, sous linux ou pas, pro ou pas.

Et pour le plaisir d'être plus proche du système, de mes goûts, par nostalgie, pour que ça tourne plus vite, je m'autorise de lui coller un peu de C.

La seule fois où j'ai perdu du temps avec Python c'est quand j'ai décidé de migrer mes applis en utf8/unicode au lieu d'attendre la v3...

Guido est en train d'écrire l'histoire de python :
http://python-history.blogspot.com

Quelle est le meilleur ordre ? greylist puis rbl ou l'inverse ?

Forcement, quand t'as appris Java t'étais débutant :)
C'est ça qui est génial, je peux rester débutant tout en assurant mon job grâce au Python !
Je reviens sur mon paradoxe, autant on trouve pléthore de raisons pour obliger les développeurs à faire du java, autant tous ceux qui utilisent python l'on fait par choix. Curieux non ?
Bon j'arrête sinon je vais être obligé de raconter ma vie ;-)

Euh, même si tu divises le nombre de lignes par 2, je vois toujours pas le rapport, pour retrouver la méthode bidule, t'iras toujours la chercher dans la classe machin dans le fichier truc dans le dossier pouet.
Si tu n'arrives pas à comprendre qu'un code plus court, plus concis et plus clair aide à s'y retrouver, je vois pas quoi rajouter... Mon argument ne tien peut-être pas a tes yeux deux minutes, mais ça fait quelques années que je l'apprécie au quotidien :-)

Moi je mets ma main à couper que dans 10 ans il va être super balaise de trouver un mec suffisament compétent pour intervenir rapidement sur ce genre d'appli,
J'ai du mettre quelques mois pour apprendre à sortir quelque chose de cohérent en java, en python ça m'a pris quelques jours. Je ne vois pas pourquoi dans 10 ans on aurait du mal à former quelqu'un dans un langage aussi simple et facile d'accès et qui ne bouge quasiment pas malgré ce qu'on peut lire ici.

un décideur qui a un ingénieur dubitatif devant lui, il prend peur et va se rassurer chez Sun MS ou autre IBM qui va lui offrir des garanties de support sur le long terme.
On en revient toujours au même. Quand on a un problème on s'imagine toujours que les autres les ont aussi, on regarde donc quels outils ils ont pour les résoudre au lieu de se demander s'ils ont eux aussi ces problèmes... L'IDE, le framework etc.
Un autre exemple tout bête. On dit souvent qu'il n'y a pas autant de livres sur python que sur java. Certe, mais autant en java j'ai du acheter d'énormes bouquins, en python aucun. Pourtant je fait exactement les mêmes choses avec... Y compris du multi-thread !

Un temps j'étais même fan de java, pourquoi j'aurai abandonné pour python ?
Soit parce que je suis compétent, et c'est donc un bon choix. Soit parce que je suis incompétent mais alors c'est encore mieux si un langage permet à un incompétent d'être encore plus productif ! ça devrait pourtant être l'inverse avec un langage qui rattrape autant d'erreurs ;-)

Tu m'expliques le rapport avec le langage ? L'organisation des sources et leur décomposition n'a pas grand chose à voir là dedans !

C'est tout simple, j'ai réécrit des programmes java en python, ils perdent statistiquement la moitié en lignes de code tout en devenant encore plus clairs et explicites (pas comme perl par ex). Ils perdent du volume d'une part parce que le langage est moins verbeux mais aussi par ce qu'il est moins contraignant.

Ah oué et demain t'as une faille de sécu et t'as 24h pour la corriger, tu fais quoi ? Tu réécris tout en Python ?
Je parle de grosses modifs. Si c'est pour corriger des bugs, quelque soit le langage comme je t'ai dit, ce n'est pas le plus gros problème, pas la peine de réécrire quoique ce soit.

C'est le problème de ton "je". Si t'es plus là ? faudra trouver quelqu'un qui maîtrise Python 2.x quand tout le monde sera à Python 5. Le mec s'apercevra peut être même que le bug est dans une lib Python que plus personne ne maintient parcque elle a été réécrite 3 fois...
Justement ce n'est pas le problème de mon "je" vu ça restera simple. L'avantage du KISS. Ce qui fait aussi que les soit disant problèmes d'incompatibilités entre les versions de python sont assez insignifiantes. Et de toutes façon, je me répète, l'environnement change beaucoup plus vite et oblige à beaucoup plus d'adaptations que les contraintes du langage.
Tu te focalises sur LE bug de l'application qui n'a pas évolué depuis 10ans et que tu n'aurais peut-être pas eu grace à la compilation...

Quand on est habitué, un code java est tout à fait lisible.

Encore faut-il retrouver le dit code ! J'ai encore quelques applis en java que je n'ai pas encore réécrite en python. Je passe mon temps à chercher où ce passe quoi ou à quoi pouvait bien servir tel autre code !
La encore Ploum a mis juste, on sent le vécu, le code était-il du M, du V ou du C !

Allez, je vais quand même avouer une chose, j'ai énormément appris quand j'ai fait du Java, à me structurer, à prévoir les failles etc. C'est un très bon langage théorique je dirai.

Franchement quand on fait de la maintenance, pour moi la priorité c'est d'assurer la non-régression, et tout les outils/méthodes qui peuvent m'offrir un certain niveau de sécurité sont le bienvenu. Bien plus que les backups ou la journalisation qui sont des problématiques totalement différentes de la maintenance. Ca c'est une problématique d'exploitation/infrastructure qui est globalement indépendance de ton langage de programmation.

La maintenance au niveau bug sur un programme qui tourne depuis 10 ans, normalement elle est quasiment inexistante... C'est d'ailleurs, pour ça, qu'on n'a plus les programmeurs qui vont avec. J'ai des applis qui ont une quinzaine d'années, en access et windev qui tournent comme des horloges, personne n'osera dire que c'est grâce au langage ! Par contre si je dois faire des grosses modifications, j'aurai plus vite fait de les réécrire en python que d'essayer d'aller voir si à l'époque j'écrivais du code maintenable ! Et la ce qui est important c'est d'avoir prévu des exports de données tout simplement.

Le piège, que Ploum a encore très justement mis en avant, est justement de penser que les problèmes d'exploitations sont différents des problèmes de programmation.
Dans 10 ans qu'est-ce qui m'empêchera de retrouver un environnement exactement identique à celui d'aujourd'hui ? Je n'ai besoin que de vim, python et deux ou trois librairies d'une taille ridicule. Grâce à la surveillance de Guido (de garder une implémentation simple) je suis même assuré de pouvoir corriger moi-même les éventuels bugs que je pourrai trouver dans le langage lui-même ou une des bibliothèques ! C'est là que ce jouera toute la différence dans le temps.

Ah ces SSII, qu'est ce qu'elles attendent pour coder en Python ? Qui veut coder une application qui dans 10 ans sera inmaintenable parcque Python 5 aura cassé 2 fois la compatibilité et qu'on trouvera plus un couillon qui sait faire du Python 2.6 ?

Si la maintenance d'un programme ne dépendait que de la compatibilité ascendante du langage ce serait merveilleux !!! Mais c'est déjà bien d'amener la discussion sur la maintenance, bien plus importante que la correction de bugs.

Déjà ça dépend de bien d'autres facteurs comme l'environnement système, les bibliothèques utilisées, les bases de données etc. Mais là tu vas nous expliquer, avec raison d'ailleurs, comment java résout le problème beaucoup mieux que python. Mais surtout ça dépend de la clarté du code et de la simplicité de son architecture. Et c'est là qu'entre en jeu les avantages des langages comme python avec un code beaucoup plus concis et beaucoup plus explicite. Souviens toi toujours de la règle qui dit qu'on passe beaucoup plus de temps à faire évoluer un code qu'à l'écrire ou à maintenir l'existant. Il ne faut pas se focaliser sur le bug de syntaxe, ce genre de bug, mis à part pour les départs de navette spatiale, généralement ils ne sont pas très gênant et se réparent dans tous les cas très rapidement. Et quand bien même, ce n'est ni par la compilation ni par les tests unitaires qu'on s'en protège, mais plutôt par des solutions de backup et de journalisation. Par contre le bug du client qui au dernier moment dit que ce n'est pas du tout ça qu'il voyait, celui la il est très fréquent et beaucoup plus difficile à déceler à la compilation ou au checker !

C'est un projet personnel ou y en a d'autres sur le coup ?

Les contraintes de ces grosses boites, c'est pas que les cravates, c'est aussi le nombre de développeurs qui y travaillent pour gagner leur croute. L'intérêt de java est de pouvoir bien cadrer tout ce petit monde quitte a sacrifier les ressources machines. Par contre pour des projets à taille plus humaine et a ressources restreintes où on a besoin de l'innovation et de la motivation des développeurs c'est plutôt un frein. Ce n'est pas pour rien non plus que ces même grosses boites dont tu parles utilisent aussi d'autres langages.

Vu la vitrine que représente linuxfr ce serait intéressant de faire du choix du framework et du langage une sorte de défi. On prendrait une partie critique du site à faire et on bencherait autant la vitesse de sortie que le nombre de ligne de code.

>>> from string import Template
>>> print Template('bonjour $nom $prenom').substitute(nom='archi', prenom='bald')
bonjour archi bald

J'ai compris comme toi, l'intérêt de perf et de taille c'est quand le format binaire est utilisé
http://code.google.com/apis/protocolbuffers/docs/encoding.ht(...)
Ce n'est du coup plus du tout lisible...
Ce que je comprend c'est en gros qu'on a là un format binaire pour échanger des données entre c++, java et python.
Bof aussi donc...

Je n'ai pas tellement suivit l'évolution de svn, mais j'aimerai préciser que l'intérêt des "décentralisé" n'est pas que d'être décentralisés. Du reste ils peuvent également être utilisé en mode centralisé ! (l'inverse aussi d'ailleurs).
Personnellement, travaillant la majorité du temps seul et voyageant plutôt à vélo qu'en avion, je me décentralise rarement. Pourtant je profite énormément de bazaar. Pour ce que j'avais du mal a faire avec cvs :
Je crée pleins de branches (c'est rapide et léger).
Une par fonctionalité, bug.
Une par client (qui n'utilisent pas tous la même version).
Ce que j'aime bien avec bazaar c'est qu'après une fusion je garde dans les logs une trace visible (indenté) de quoi a été fait pour qui.
Ca donne quelque chose du genre (qui il me semble ne rend pas comme ça avec hg ou git)

revno : 1234
date ...
message :
merge bs
revno : xxx
message :
entete en couleur pour bs
revno : yyy
message :
tri demandé par machin de chez bs

revno: 1233
date ...
message :

merge bug trucmuch
revno : xxx
message :
finalisation de la correction
revno : xxx
message :
1ere tentative de correction


etc. Donc chaque étape regroupant plusieurs commits dans une branche à part reste bien visible. Une étape peut également montrer une autre étape s'il y a un merge entre deux branches (indenté d'avantage etc.).

Ensuite, si je souhaite montrer le code à un collègue il y a bien sur tout un tas de possibilité de push pull & co, automatique ou non...

Sur l'interface lourde vs légère, on peut aussi prendre le problème à l'envers et chercher comment le résoudre pour ne plus avoir besoin d'une interface trop riche. On profite par exemple d'une interface web pour décentraliser et ainsi alléger les taches de chacun. C'est ce qu'on me demande en très grande majorité.

Mais d'après ce que j'ai compris vous avez prévu les deux solutions.

A propos de la communauté postgresql, quelle est la mailing liste (ou forum) francophone la plus active ? Je suis inscrit par sur http://www.postgresql.org/mailpref/pgsql-fr-generale mais je la trouve vraiment peu fréquentée...

De plus en plus souvent je constate qu'en entreprise il y a beaucoup plus de chance d'avoir un pépin local (à cause des configs locales qui sont de plus en plus complexes et qui changent tout le temps) qu'un pépin réseau (externe).
De même pour la confidentialité, il y a beaucoup plus de problème de fuites au sein même de l'entreprise que sur un serveur en ligne.
Inutile de parler des backups !

Je compare avec vmware server, pas esx, c'est peut-être pour ça ?

C'est curieux je constate exactement l'inverse ! Chez moi virtualbox est beaucoup plus véloce d'une part et la gestion de la mémoire est meilleure également, j'arrive à lancer beaucoup plus de machines virtuelles en même temps.

A noter que le sdk est fourni avec django, webob et pyyaml

Je l'utilise pour tous mes devs pro ou perso.
Même si je bosse essentiellement seul je trouve pratique de pouvoir créer des branches pour tester des nouvelles fonctionnalités et par client lorsqu'ils ont les mêmes applis mais pas aux mêmes versions.
Mais pour moi, l'intérêt de bzr en particulier est de pouvoir changer de méthode (workflow) facilement suivant si je suis connecté ou pas, si je bosse avec quelqu'un ou pas, fréquemment ou pas etc.

Par contre, c'est vrai que même pour des petits projets il reste assez poussif bien que les devs semblent s'arracher les cheveux sur ce problème depuis pas mal de temps.

L'auteur a rectifié par la suite :
http://article.gmane.org/gmane.comp.version-control.bazaar-n(...)


> Last 100 revisions:
>
> $ time git log -100 >/dev/null
> real 0m0.011s
>
> $ time bzr log -l100 >/dev/null
> real 2m10.270s

git: 0m0.009s
bzr: 0m26.562s

> Last 10 revisions:
>
> $ time git log -10 >/dev/null
> real 0m0.007s
>
> $ time bzr log -l10 >/dev/null
> real 2m9.163s

git: 0m0.005s
bzr: 0m25.519s


Ceci dit ça ne change pas le fait que le résultat est instantané ou pas.

La différence de taille c'est que le programmeur méritocrate n'a de pouvoir que sur ce qu'il fait alors que l'aristocrate a un pouvoir sur ce qui ne le concerne pas.
En d'autres termes, il ne faut pas confondre avoir de l'autorité et être autoritaire...
En d'autres termes informatique ça veut dire que tu peux forker.

Pour ce qui est de l'égalité c'est pareil, il ne faut pas confondre les gens sont égaux et les gens ont des droits égaux quand bien même ils seraient différents...
Qu'on retrouve également dans les logiciels libres, chacun à également le droit d'utiliser un même logiciel suivant ces préférences et non celle du développeur.

L'anarchobizounours t'embrasse ;-)

On ne répond pas que les enfants ne peuvent pas perturber un conducteur, d'ailleurs dans les bus c'est écris noir sur blanc. On répond que c'est justement parce qu'il y a déjà pas mal d'éléments perturbateurs que c'est pas la peine d'en rajouter d'autres surtout s'ils ne sont pas du tout indispensables (contrairement aux enfants).
Du reste, les enfants à l'arrière, on sait à l'avance qu'ils vont faire du bordel, le problème du téléphone c'est pas tant de converser c'est surtout l'effet de surprise quand il sonne et ensuite quand il annonce qu'on vient de se faire virer.

Si on se souciait de sécurité ça fait longtemps que les portables seraient interdits vu les dégâts qu'ils causent entre les ondes et les déconcentrations d'automobilistes...