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
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.
Non ton argument tiens pas 2 minutes.
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.
Mais mon argument c'était ca : il faut que tu trouves quelqu'un de compétent qui sache faire de genre de maintenance corrective minimale mais indispensable.
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, et je mets ma main à couper que la plupart des frameworks actuels ne seront plus maintenu pour Python 2.x, et qu'il faudra donc mettre la main à la patte de ces frameworks également... Bref, c'est vraiment un pari risqué pour n'importe quelle appli destiné à tourner pendant un petit moment.
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...
On est plus dans la compilation là, on parle d'utiliser une plateforme mal conçu qui nécessite donc de subir des évolutions qui "cassent" l'existant. Un langage dont la sémantique n'est pas standardisé par un consortium d'industriel (ECMA, ISO, OASIS) et donc ne répond pas à leurs préocupation, un langage où les concepteurs disent "le GIL c'est pas un problème, le multi-threading ca sert à rien" (ca c'est visionnaire), bref, autant de chose qui font peur à n'importe quel ingénieur qui doit évaluer une techno pour être utilisée dans telle ou telle techno. Et 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.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
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.
Non ton argument tiens pas 2 minutes.
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.
Mais mon argument c'était ca : il faut que tu trouves quelqu'un de compétent qui sache faire de genre de maintenance corrective minimale mais indispensable.
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, et je mets ma main à couper que la plupart des frameworks actuels ne seront plus maintenu pour Python 2.x, et qu'il faudra donc mettre la main à la patte de ces frameworks également... Bref, c'est vraiment un pari risqué pour n'importe quelle appli destiné à tourner pendant un petit moment.
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...
On est plus dans la compilation là, on parle d'utiliser une plateforme mal conçu qui nécessite donc de subir des évolutions qui "cassent" l'existant. Un langage dont la sémantique n'est pas standardisé par un consortium d'industriel (ECMA, ISO, OASIS) et donc ne répond pas à leurs préocupation, un langage où les concepteurs disent "le GIL c'est pas un problème, le multi-threading ca sert à rien" (ca c'est visionnaire), bref, autant de chose qui font peur à n'importe quel ingénieur qui doit évaluer une techno pour être utilisée dans telle ou telle techno. Et 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.