10000 est un choix arbitraire pour ne compiler que le code très utilisé et ne pas pénaliser le démarrage et la mémoire.
La compilation est en temps réel pour être adaptée à l'utilisation en cours, donc en mémoire seulement.
Les gains actuels sont très faibles, l'important jusque là était surtout qu'il n'y ait pas de régression avec l'utilisation de LLVM. C'est à partir de maintenant que ça va commencer !
Psyco vient de sortir. Pour l'instant il n'y a pas encore beaucoup d'info (support des générateurs), mais Christian Tismer, nouveau mainteneur (payé), promet une renaissance du projet !
Personne n'a trop parlé de l'appli, mais ça me semble important aussi. Vous ne trouvez pas curieux qu'un erp engendre autant de requêtes ?
S'il y a une grosse appli centralisée, il doit y avoir moyen de gérer un cache à ce niveau. Si c'est une myriades d'applis qui attaquent la base il faut peut-être envisager d'utiliser quelque chose comme memcached.
Dans tous les cas il est impératif de voir le problème globalement car si c'est un problème de conception, au prochain ajout de fonctionalité le problème risque d'empirer...
Vu l'appli et le nb de requête je rejoint les autres, faut payer un audit.
Je crois que la sortie de cette version 3.1 est le signal pour montrer que la branche 3 est mure et que le portage des modules peut commencer sans crainte.
Par contre, le fait que la branche 2 intègre la plupart des nouveautés de la 3 rend à la fois plus facile la migration à la fois moins nécessaire... Vu que des projets comme unladen-swallow visent à la fois la 2 et la 3, les deux ont encore de beaux jours devant eux.
J'aimerai également bien avoir l'avis de ceux qui ont ou vont switcher, en particulier nous autres étrangers à la langue exotique. Pour ma part le boulot a été énorme lorsque j'ai migré mes projets en unicode. Je redoute de retomber sur des problèmes à ce niveau !
Je me suis amusé à coder le problème des parcours de chevaux aux échecs qui doivent remplir une grille, en utilisant un code le plus semblable possible (sans utiliser les librairies spécifiques des différentes langages).
Par contre, en pratique, d'une part c'est rare que ce genre de code soit déterminant, les perfs se jouent beaucoup plus sur le choix des librairies utilisées, l'algo choisit etc. C'est là que va jouer la "facilité" du langage, le support de la communauté etc. Le résultat peut même s'inverser.
Le plus simple c'est encore de faire tes petites bidouilles dans un clone à part, que tu merge dans ta branche principale quand c'est prêt à pusher. C'est la différence avec git où dans le même répertoire tu peux avoir plusieurs branches aussi distinctes que des clones.
rebase, tu l'as comme extension dans mercurial, ça permettra de "rebaser" tes bidouilles dans l'historique comme si ça avait été dans la même branche, plutôt que de faire des merges. http://www.selenic.com/mercurial/wiki/RebaseProject
Tout dépend de ce que tu fait comme administration !
Par exemple j'utilise un petit programme python qui me génère des comptes mails. Ensuite, je lance l'interpréteur et je peux faire des choses du genre
m = mail.Mail("wilk", "domain.tld")
m.password = 'monpass'
m.write()
J'ai créé mon nouveau mail, c'est un 'objet' mail, très pratique... A utiliser soit dans l'interpréteur, soit bien sur dans un autre script. Si je veux envoyer un mail aux utilisateurs de tel domain, for mail in get_mails('domain.tld'): sendmail(blalabla, mail.email)...
La même chose pour ma conf apache, ftp etc. J'ai un objet site, site.documentroot=..., site.mod_wsgi=...
Ce n'est pas non plus pour autant une usine à gaz avec une interface graphique etc, ça reste du script d'admin.
Dans la vraie vie comme tu dis, plus les données sont importantes, financièrement parlant, plus le critère de choix devient financier également et non plus technique. Bref, c'est l'assureur qui choisit et non le directeur technique.
Sur un éventuel rapprochement de codes entre mercurial et bazaar, il aurait fallu que le copyright soit transféré à cannonical, ce que le développeur de mercurial a refusé, la naissance de mercurial faisant suite à "la leçon Bitkeeper".
En particulier en fin de document : Barrier to Entry où il indique que le temps et l'effort à faire pour faire un checkout de python est déterminant. S'il est trop long ou trop difficile ça risque de dissuader un contributeur potentiel. Ensuite un bench, sans parler du fait qu'il faut un outil particulièrement à jour dans le cas de bazaar.
Ce qui pourrait sauver bazaar c'est qu'il puisse communiquer en natif avec les deux autres.
Je suis passé de bazaar à mercurial il n'y a pas très longtemps, il me semble tout simplement que mercurial est ce que bazaar cherchait à devenir en vain... Simple et rapide, il suffit d'essayer.
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...
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 !
[^] # Re: Ça me brule les lèvres...
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 2.
La compilation est en temps réel pour être adaptée à l'utilisation en cours, donc en mémoire seulement.
Les gains actuels sont très faibles, l'important jusque là était surtout qu'il n'y ait pas de régression avec l'utilisation de LLVM. C'est à partir de maintenant que ça va commencer !
# Psyco V2
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 3.
http://mail.python.org/pipermail/python-announce-list/2009-J(...)
[^] # Re: Avantage
Posté par wilk . En réponse à la dépêche Publication de la version 2009Q2 de Unladen Swallow. Évalué à 4.
[^] # Re: mysql=oracle donc poubelle
Posté par wilk . En réponse au journal Performance MYSQL. Évalué à 1.
Donc btrfs >= oracle
[^] # Re: ton ERP
Posté par wilk . En réponse au journal Performance MYSQL. Évalué à 1.
S'il y a une grosse appli centralisée, il doit y avoir moyen de gérer un cache à ce niveau. Si c'est une myriades d'applis qui attaquent la base il faut peut-être envisager d'utiliser quelque chose comme memcached.
Dans tous les cas il est impératif de voir le problème globalement car si c'est un problème de conception, au prochain ajout de fonctionalité le problème risque d'empirer...
Vu l'appli et le nb de requête je rejoint les autres, faut payer un audit.
[^] # Re: Quand switcher ?
Posté par wilk . En réponse à la dépêche Python arrive en version 3.1. Évalué à 5.
Par contre, le fait que la branche 2 intègre la plupart des nouveautés de la 3 rend à la fois plus facile la migration à la fois moins nécessaire... Vu que des projets comme unladen-swallow visent à la fois la 2 et la 3, les deux ont encore de beaux jours devant eux.
J'aimerai également bien avoir l'avis de ceux qui ont ou vont switcher, en particulier nous autres étrangers à la langue exotique. Pour ma part le boulot a été énorme lorsque j'ai migré mes projets en unicode. Je redoute de retomber sur des problèmes à ce niveau !
[^] # Re: Ça passe très bien :)t
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 4.
[^] # Re: Ça passe très bien :)
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
[^] # Re: Ça passe très bien :)
Posté par wilk . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 4.
c 5s
gcj 7s
java 7s
python2.5 + psyco 18s
python2.5 303s
java est extrêmement performant s'il est utilisé comme du C. On retrouve ces résultats sur http://shootout.alioth.debian.org/
Par contre, en pratique, d'une part c'est rare que ce genre de code soit déterminant, les perfs se jouent beaucoup plus sur le choix des librairies utilisées, l'algo choisit etc. C'est là que va jouer la "facilité" du langage, le support de la communauté etc. Le résultat peut même s'inverser.
# clone à part
Posté par wilk . En réponse au message Mercurial: Publier uniquement ce que l'on veut .... Évalué à 1.
rebase, tu l'as comme extension dans mercurial, ça permettra de "rebaser" tes bidouilles dans l'historique comme si ça avait été dans la même branche, plutôt que de faire des merges.
http://www.selenic.com/mercurial/wiki/RebaseProject
[^] # Re: Cela dépend de ce que tu fais...
Posté par wilk . En réponse au message [Programmation] Shell / Perl / Python. Évalué à 1.
Par exemple j'utilise un petit programme python qui me génère des comptes mails. Ensuite, je lance l'interpréteur et je peux faire des choses du genre
m = mail.Mail("wilk", "domain.tld")
m.password = 'monpass'
m.write()
J'ai créé mon nouveau mail, c'est un 'objet' mail, très pratique... A utiliser soit dans l'interpréteur, soit bien sur dans un autre script. Si je veux envoyer un mail aux utilisateurs de tel domain, for mail in get_mails('domain.tld'): sendmail(blalabla, mail.email)...
La même chose pour ma conf apache, ftp etc. J'ai un objet site, site.documentroot=..., site.mod_wsgi=...
Ce n'est pas non plus pour autant une usine à gaz avec une interface graphique etc, ça reste du script d'admin.
[^] # Re: Karma...
Posté par wilk . En réponse à la dépêche Évolutions du site LinuxFr.org. Évalué à 1.
[^] # Re: Le quatrième plus gros contributeur au noyau Linux?
Posté par wilk . En réponse à la dépêche Oracle achète Sun. Évalué à 4.
[^] # Re: Juste un mot sur mercurial
Posté par wilk . En réponse au journal Python adopte Mercurial. Évalué à 3.
http://www.selenic.com/mercurial/wiki/index.cgi/TranslatingM(...)
[^] # Re: mercurial après bazaar
Posté par wilk . En réponse au journal Python adopte Mercurial. Évalué à 3.
http://article.gmane.org/gmane.comp.version-control.mercuria(...)
Sur un éventuel rapprochement de codes entre mercurial et bazaar, il aurait fallu que le copyright soit transféré à cannonical, ce que le développeur de mercurial a refusé, la naissance de mercurial faisant suite à "la leçon Bitkeeper".
[^] # Re: dommage
Posté par wilk . En réponse au journal Python adopte Mercurial. Évalué à 3.
http://www.python.org/dev/peps/pep-0374/
En particulier en fin de document : Barrier to Entry où il indique que le temps et l'effort à faire pour faire un checkout de python est déterminant. S'il est trop long ou trop difficile ça risque de dissuader un contributeur potentiel. Ensuite un bench, sans parler du fait qu'il faut un outil particulièrement à jour dans le cas de bazaar.
Ce qui pourrait sauver bazaar c'est qu'il puisse communiquer en natif avec les deux autres.
# mercurial après bazaar
Posté par wilk . En réponse au journal Python adopte Mercurial. Évalué à 5.
# Pratique
Posté par wilk . En réponse au journal Python, langage de l'année pour la seconde année consécutive. Évalué à 1.
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...
# L'histoire de python
Posté par wilk . En réponse au journal Explorez les richesses du langage Python. Évalué à 5.
http://python-history.blogspot.com
[^] # Re: sqlgrey...
Posté par wilk . En réponse au journal Luttons intelligemment contre le spam avec Whitelister. Évalué à 1.
[^] # Re: Grandiose
Posté par wilk . En réponse au journal Linuxfr en J2EE. Évalué à 1.
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 ;-)
[^] # Re: Grandiose
Posté par wilk . En réponse au journal Linuxfr en J2EE. Évalué à -2.
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 ;-)
[^] # Re: Grandiose
Posté par wilk . En réponse au journal Linuxfr en J2EE. Évalué à 2.
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...
[^] # Re: Grandiose
Posté par wilk . En réponse au journal Linuxfr en J2EE. Évalué à 3.
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.
[^] # Re: Grandiose
Posté par wilk . En réponse au journal Linuxfr en J2EE. Évalué à 3.
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 !