Oué bah Erlang a évolué pour autoriser une véritable concurrence. C'est cool pour Erlang, mais pour Python ou Ruby c'est pas à l'ordre du jour. Comme je le disais plus haut, le risque c'est de se retrouver avec une sémantique différente, des contraintes de synchro supplémentaires, bref péter la compatibilité.
c'est quand même bien fumeux que de dire "oué le multi-processus c'est pas si mal que ca" pour justifier l'absence de support multi-thread effectif. Si les threads ont été inventé, c'est pour éviter la lourdeur des processus. Et franchement je préfères communiquer des objets entre 2 threads que de me taper des FIFO ou des shared map entre 2 processus...
En tout la fin de l'article résume bien la situation : y'a que JRuby et IronRuby qui offrent véritablement une concurrence d'exécution. La conclusion : "oué peut être bien que le futur des threads dans Ruby va évoluer".
Bref, à l'heure actuelle ils essaient juste de contourner le problème en proposant des solutions loin d'être friendly pour les programmeurs, et loin d'être friendly pour les perfs (la gestion multi-thread est plus efficace que multi-process au niveau OS, lancer plusieurs processus implique également le chargement de 2 VM, plus de conso mémoire toussa).
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...
Effectivement, ca ne va pas de soit, donc je vois pas quoi d'autre rajouter non plus...
J'ai du mettre quelques mois pour apprendre à sortir quelque chose de cohérent en java, en python ça m'a pris quelques jours.
Forcement, quand t'as appris Java t'étais débutant :)
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.
Allez mon gars : y'a un bug critique dans l'appli, t'apprends python 2.6 et tu trouves d'où ca vient : je te préviens, ca vient peut être pas de l'appli mais du framework bidule qui n'est plus maintenu pour python 2.6.
T'as 24h si tu veux pas perdre ton job !
Y compris du multi-thread !
En exploitant un seul core de la machine, ca va t'es pas trop frustré ?
Bien entendu, mais ca casse la sémantique. Si tu pars du principe que c'est véritablement multi-thread comme en Jython ou IronPython, alors il va falloir gérer la synchro, les mutex, etc. Bref, ces implémentations supportent de "vrais" threads mais au prix d'une incompatibilité avec l'implémentation de référence (CPython). Bref, j'ai envie de dire que ce n'est plus vraiment le même langage, donc qu'on parle plus vraiment de la même chose :)
Le Global Interpreter Lock. C'est ce qui fait qu'en gros t'auras beau faire des threads en Python, ben que t'es une machine mono-core ou quadri-core ca changera kedal parcque Python sera incapable de les exploiter, il n'en exploitera toujours qu'un seul à la fois. http://en.wikipedia.org/wiki/Global_Interpreter_Lock
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.
Encore faut-il retrouver le dit code !
Tu m'expliques le rapport avec le langage ? L'organisation des sources et leur décomposition n'a pas grand chose à voir là dedans !
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 !
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 ?
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 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...
Putain mais de quel cassage tu parles ?
Ben de Python 3 tiens !
La maintenance de Python en soit c'est pas le problème, ce qui va être difficile à maintenir c'est tous les outils, frameworks et compétences futures !
Mouais, enfin cest argument était également applicable à java à sa sortie : pourquoi prendre le risque de miser sur une techno faites pour l'embarqué, alors qu'on avait déjà smalltalk, c++, etc... et dont on avait à l'époque pas plus de garantie sur la compatibilité ascendante.
Ben java n'a pas été adopté dès le début dans le l'industrie, c'est venu progressivement.
Quand les versions suivantes sont sorties, les décideurs étaient rassurés : support Sun, politique de compatibilité et de support des anciens API, etc.
Python, ils cassent la rétro-compatibilité de manière explicite. Si j'étais décideur ca me ferait peur.
A ce propos, et sans vouloir t'offenser, la rétro-compatibilité n'est pas l'apanage de Java.
Je ne dis pas que c'est l'apanage de Java. Je dis juste que c'est pas celui de Python.
oui mais, par définition, tout code que tu écris te parle sur le moment.
Pas convaincu :)
Personnellement je me pose systématiquement des questions existentielles au moment de nommer mes variables et méthodes, pour qu'elles soient le plus parlante possible et être compris sans commentaire supplémentaire.
lutôt que de commenter ce que je fais, je commente pourquoi je le fais. On verra à la longue.
Oui ca revient à ce que je disais plus haut : il faut ajouter un commentaire quand le "pourquoi" n'est pas trivial. Ca paraît beaucoup plus pertinent. Pour le reste, il faut que le code soit auto-descriptif, il ne l'est pas par naturellement.
J'aime assez la philosophie "pas de commentaire" et pourtant je suis pas un adepte de J2EE :)
En fait la philosophie marche à mon sens, à condition que :
- le code doit parler de lui-même. Et c'est pas facile. Mais c'est justement là le but de la philosophie "pas de commentaire" : faire en sorte que le code parle de lui-même.
- il ne faut pas s'empêcher de documenter les API (doxygen toussa)
- il ne faut pas s'empêcher d'ajouter un commentaire quand c'est pertinent (signaler la raison qui a conduit à utiliser telle ou telle méthode, signaler un lien vers un pattern, signaler un hack)
Bref, c'est une philosophie qui a du sens si son objectif est de forcer le programmeur à pondre un code qui parle de lui-même. Si l'objectif est uniquement de ne pas "polluer" le code, ca ne marche pas.
Car les commentaires ca reste compliqué à maintenir : bien souvent ils ne sont pas maintenus car pas "utiles" à la bonne exécution du programme, et du coup on se retrouve avec des informations obsolète, voir fausse ou contradictoire, bref une vraie plaie.
Si la maintenance d'un programme ne dépendait que de la compatibilité ascendante du langage ce serait merveilleux !!!
C'est pas le seul soucis, mais ça reste un gros soucis quand même. Regarde les "experts Cobol", ils se font des couilles en or car ils sont devenus rares et indispensable à maintenir des applis codés dans une vieille techno. J'imagine même pas ce qu'adviendrait d'une application Python codé aujourd'hui dans 10 ou 15 ans...
Et c'est là qu'entre en jeu les avantages des langages comme python avec un code beaucoup plus concis et beaucoup plus explicite.
Bof. Quand on est habitué, un code java est tout à fait lisible. Ce qui compte le plus pour moi c'est le nommage, la séparation des responsabilité et l'intuitivité des choix de décomposition. Après quelque soit le langage, le développeur étant censé le maîtrisé...
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.
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.
je suis d'accord que J2EE devient un "mastodonte" et qu'une plateforme plus "light" pourrait tirer son épingle du jeu.
Cela dit pour moi Python n'est pas une alternative crédible à mon sens, cette plateforme est beaucoup trop bancale dans un contexte de plateforme généraliste. MS a .NET comme alternative sérieuse, mais y'a aussi Adobe qui se lance sérieusement côté serveur.
Comme je l'ai mis plus haut, Python existe pourtant depuis que Java a été créé, et ils n'ont pas du tout eu le même succès, ca me paraît être vraiment optimiste de croire que la vapeur va se renverser...
Où est-ce que tu as vu que Ruby est au point mort ? Et Rails ? Et Python ?
Ben, tu l'avoues toi même dans le paragraphe suivant en tentant de trouver une explication à ce phénomène :)
c'est que les SSII sont frileuses sur les nouvelles techs, ça on le sait ça a fait la même chose il y a 10-15 ans avec Java, et il y a 5-10 ans avec PHP.
Java 1.0 : 1995
PHP 1.0 : 1995
Python 1.0 : 1994
Et cet effet est aussi valable pour les clients de la SSII, qui même pour un prix supérieur préfèrent souvent des bases commerciales si elles ont une "garantie".
Ben oué, une plateforme bien conçue, supportée, qui offre une rétrocompatibilité, forcement, ca demande des moyens que veux-tu.
Il est où le standard Python ? Elle est où la rétrocompatibilité dans Python 3.0 ? Elle est où la bonne conception du GIL à l'heure du multi-threading ?
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 ?
Pour aller dans ton sens c'est un peu ce qui fait que Python et Ruby sont au point mort à l'heure d'aujourd'hui (par rapport à l'avenir prometteur qu'on leur accordait il y a quelques années) : les langages sont venus avec des frameworks "sexy" (notamment RoR), d'où le buzz, et puis finalement les gens se sont aperçus que le framework pouvait être porté pour d'autres plateformes...
. Lorsqu'un programmeur passe 2 semaines pour réussir à compiler un projet sans toucher une ligne du projet lui-même (juste les makefile et les configure)
C'est pas parcque l'outil est une merde qu'il faut remettre en cause le langage. Les autotools sont une bonne grosse daube niveau productivité, mais je peux te faire des autotools tout pourri pour gérer un gros projet Python avec les même problèmes.
Tout dépend des plateformes. En C ou C++ évidemment.
mais avec des plateformes modernes comme .NET ou Java qui sont conçus pour être productif dans leur environnement de dev associé, cet argument tombe en miette. Il ne reste donc plus aucune raison de s'en passer.
Allez j'en rajoute une couche,
ton compilateur qui sert à rien :
- il rend ton programme plus rapide que si celui-ci était interprété
- il me permet de transformer mon programme dans un format standard utilisable par d'autre langages et outils.
- il me permet d'obtenir un fichier "portable" sans seposer de question existentielle sur l'encodage par défaut sur telle ou telle machine.
Un compilateur n'a pas pour but de vérifier ton code,
S'il veut le transformer, il faut qu'il l'interprète, et pour ca il a intérêt à vérifier un ton code. Bref, c'est un premier rempart. Il ne remplace pas les autres outils de vérification, mais il est complémentaire, et a l'avantage d'être situé en amont de la chaîne (sur le poste du développeur). Bref c'est tout bénef, donc pourquoi s'en passer ?
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça
Blablabla. Les compilateurs sont pensés en binôme avec le langage, les possibilité de contrôle (qualité) statique du compilateur sont pris en compte dans la grammaire du langage. Évidemment avec un langage non conçu pour être vérifié statiquement/compilé comme Python...
t, surtout, cela n'a aucune valeur !
Ah bah oui, moi je connais des gens qui roulaient à 180km/h et qui se sont tués avec une ceinture de sécurité, c'est bien la preuve que la ceinture de sécurité n'a aucune valeur !
Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.
public void foo()
{
//todo : implement this !
}
ca compile, et je peux tester autre chose.
Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.
Mais c'est pas une méthode ! C'est pas un plus un gage de qualité ! C'est juste un outil qui permet d'éviter un certain nombre d'erreur, et qu'à ce titre il paraît idiot de chercher à s'en passer.
C'est comme les tests unitaires, les outils d'analyses statiques de code, toussa, ce sont des outils, qui offrent un certain nombre de vérification, et il est toujours mieux de les utiliser que de s'en passer.
Le bonus c'est que la plupart sont complémentaires.
Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps".
C'est peanuts par rapport au nombre de vérification que fait le compilateur. Combien de milliers de tests unitaires en Python faudrait-il écrire pour effectuer toutes les vérifications que fait le compilateur Java ? et le temps d'exécution de ces tests ?
Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois
Bof, un serveur d'intégration fait tout ça très bien.
Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).
Sauf que toi t'as 100 fois plus de bugs à débogguer, pendant ce temps moi le compilateur il m'a prévenu 100 fois que ca servait à rien de lancer mon code et de chercher à comprendre, l'erreur elle est là, à la ligne 13, caractère 20, d'ailleusr il me suggère même quoi faire. Niveau perte de temps, je sais pas qui en perd le plus...
tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...
Forcement, si tu pars du principe que :
- faire l'analyse lexicale
- faire l'analyse syntaxique
- faire des vérifications sémantique : typage, initialisation des variables, etc.
- faire des vérifications de contrat d'interface, de versionning, etc.
tout ca ne sert à rien avant d'exécuter ton programme, effectivement tu dois rêver.
Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.
Ben non, ca prouve juste une chose : que le temps de compilation est suffisamment anecdotique pour que tu recompiles systématiquement avant d'exécuter :-p
Ce qui est hallucinant surtout, c'est que t'es pas capable de te rendre compte du boulot que fait le compilateur (associé à un langage avec une syntaxe stricte et un typage statique). Tu dis que le compilateur fait rien, mais dans ta technique (sans compilateur), qui fait tout le "rien" du compilateur ? et quand ?
Me semblait que Java était également interprété ...
Le langage Java est compilé en bytecode.
Le bytecode est en partie interprété, en partie Traduit en code natif "à la volée" (JIT).
Quel est l'intérêt ?
Contrôle qualité le plus en amont possible.
La question c'est plutôt : pourquoi ne pas compiler alors que le coût (temps) de compilation est ridicule ?
Ok, cela peut être intéressant pour des raisons de performances mais dans ce cas là on n'utilise pas Java.
On peut vouloir un compromis niveau perf entre Python et le C.
Compiler, c'est un concept dépassé quand on fait du développement
Ce qui est dépassé, c'est de croire qu'on peut se passer de compilateur et que Python va tout révolutionner.
T'es vraiment d'une mauvaise foi totale.
dotGNU vise à implémenter ce qui est spécifié à l'ECMA/ISO, comme Mono. Donc y dit qu'il voit le rapport. Comme je l'ai déjà dis, cette pile + la pile d'API Gnome offerte par Mono est largement suffisante pour la majorité des applications Linux.
De plus dotGNU, comme Mono, vise également à implémenter des API pas standardisés comme les WinForms pour permettre à des utilisateurs d'applications uniquement Windows de changer d'OS pour utiliser un OS libre (au pif : Linux), en quoi est-ce mauvais pour l'utilisateur ? C'est la même politique qui a guidé le projet GNU depuis le début.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
En tout la fin de l'article résume bien la situation : y'a que JRuby et IronRuby qui offrent véritablement une concurrence d'exécution. La conclusion : "oué peut être bien que le futur des threads dans Ruby va évoluer".
Bref, à l'heure actuelle ils essaient juste de contourner le problème en proposant des solutions loin d'être friendly pour les programmeurs, et loin d'être friendly pour les perfs (la gestion multi-thread est plus efficace que multi-process au niveau OS, lancer plusieurs processus implique également le chargement de 2 VM, plus de conso mémoire toussa).
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Effectivement, ca ne va pas de soit, donc je vois pas quoi d'autre rajouter non plus...
J'ai du mettre quelques mois pour apprendre à sortir quelque chose de cohérent en java, en python ça m'a pris quelques jours.
Forcement, quand t'as appris Java t'étais débutant :)
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.
Allez mon gars : y'a un bug critique dans l'appli, t'apprends python 2.6 et tu trouves d'où ca vient : je te préviens, ca vient peut être pas de l'appli mais du framework bidule qui n'est plus maintenu pour python 2.6.
T'as 24h si tu veux pas perdre ton job !
Y compris du multi-thread !
En exploitant un seul core de la machine, ca va t'es pas trop frustré ?
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
http://en.wikipedia.org/wiki/Global_Interpreter_Lock
[^] # 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.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . 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 !
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 !
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 ?
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 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...
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Ben de Python 3 tiens !
La maintenance de Python en soit c'est pas le problème, ce qui va être difficile à maintenir c'est tous les outils, frameworks et compétences futures !
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 1.
Ben java n'a pas été adopté dès le début dans le l'industrie, c'est venu progressivement.
Quand les versions suivantes sont sorties, les décideurs étaient rassurés : support Sun, politique de compatibilité et de support des anciens API, etc.
Python, ils cassent la rétro-compatibilité de manière explicite. Si j'étais décideur ca me ferait peur.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 1.
Je ne dis pas que c'est l'apanage de Java. Je dis juste que c'est pas celui de Python.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 1.
Pas convaincu :)
Personnellement je me pose systématiquement des questions existentielles au moment de nommer mes variables et méthodes, pour qu'elles soient le plus parlante possible et être compris sans commentaire supplémentaire.
lutôt que de commenter ce que je fais, je commente pourquoi je le fais. On verra à la longue.
Oui ca revient à ce que je disais plus haut : il faut ajouter un commentaire quand le "pourquoi" n'est pas trivial. Ca paraît beaucoup plus pertinent. Pour le reste, il faut que le code soit auto-descriptif, il ne l'est pas par naturellement.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 3.
En fait la philosophie marche à mon sens, à condition que :
- le code doit parler de lui-même. Et c'est pas facile. Mais c'est justement là le but de la philosophie "pas de commentaire" : faire en sorte que le code parle de lui-même.
- il ne faut pas s'empêcher de documenter les API (doxygen toussa)
- il ne faut pas s'empêcher d'ajouter un commentaire quand c'est pertinent (signaler la raison qui a conduit à utiliser telle ou telle méthode, signaler un lien vers un pattern, signaler un hack)
Bref, c'est une philosophie qui a du sens si son objectif est de forcer le programmeur à pondre un code qui parle de lui-même. Si l'objectif est uniquement de ne pas "polluer" le code, ca ne marche pas.
Car les commentaires ca reste compliqué à maintenir : bien souvent ils ne sont pas maintenus car pas "utiles" à la bonne exécution du programme, et du coup on se retrouve avec des informations obsolète, voir fausse ou contradictoire, bref une vraie plaie.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 3.
C'est pas le seul soucis, mais ça reste un gros soucis quand même. Regarde les "experts Cobol", ils se font des couilles en or car ils sont devenus rares et indispensable à maintenir des applis codés dans une vieille techno. J'imagine même pas ce qu'adviendrait d'une application Python codé aujourd'hui dans 10 ou 15 ans...
Et c'est là qu'entre en jeu les avantages des langages comme python avec un code beaucoup plus concis et beaucoup plus explicite.
Bof. Quand on est habitué, un code java est tout à fait lisible. Ce qui compte le plus pour moi c'est le nommage, la séparation des responsabilité et l'intuitivité des choix de décomposition. Après quelque soit le langage, le développeur étant censé le maîtrisé...
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.
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.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 3.
Cela dit pour moi Python n'est pas une alternative crédible à mon sens, cette plateforme est beaucoup trop bancale dans un contexte de plateforme généraliste. MS a .NET comme alternative sérieuse, mais y'a aussi Adobe qui se lance sérieusement côté serveur.
Comme je l'ai mis plus haut, Python existe pourtant depuis que Java a été créé, et ils n'ont pas du tout eu le même succès, ca me paraît être vraiment optimiste de croire que la vapeur va se renverser...
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
Ben, tu l'avoues toi même dans le paragraphe suivant en tentant de trouver une explication à ce phénomène :)
c'est que les SSII sont frileuses sur les nouvelles techs, ça on le sait ça a fait la même chose il y a 10-15 ans avec Java, et il y a 5-10 ans avec PHP.
Java 1.0 : 1995
PHP 1.0 : 1995
Python 1.0 : 1994
Et cet effet est aussi valable pour les clients de la SSII, qui même pour un prix supérieur préfèrent souvent des bases commerciales si elles ont une "garantie".
Ben oué, une plateforme bien conçue, supportée, qui offre une rétrocompatibilité, forcement, ca demande des moyens que veux-tu.
Il est où le standard Python ? Elle est où la rétrocompatibilité dans Python 3.0 ? Elle est où la bonne conception du GIL à l'heure du multi-threading ?
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 ?
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
C'est pas parcque l'outil est une merde qu'il faut remettre en cause le langage. Les autotools sont une bonne grosse daube niveau productivité, mais je peux te faire des autotools tout pourri pour gérer un gros projet Python avec les même problèmes.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 2.
mais avec des plateformes modernes comme .NET ou Java qui sont conçus pour être productif dans leur environnement de dev associé, cet argument tombe en miette. Il ne reste donc plus aucune raison de s'en passer.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 3.
ton compilateur qui sert à rien :
- il rend ton programme plus rapide que si celui-ci était interprété
- il me permet de transformer mon programme dans un format standard utilisable par d'autre langages et outils.
- il me permet d'obtenir un fichier "portable" sans seposer de question existentielle sur l'encodage par défaut sur telle ou telle machine.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 3.
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 6.
S'il veut le transformer, il faut qu'il l'interprète, et pour ca il a intérêt à vérifier un ton code. Bref, c'est un premier rempart. Il ne remplace pas les autres outils de vérification, mais il est complémentaire, et a l'avantage d'être situé en amont de la chaîne (sur le poste du développeur). Bref c'est tout bénef, donc pourquoi s'en passer ?
Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça
Blablabla. Les compilateurs sont pensés en binôme avec le langage, les possibilité de contrôle (qualité) statique du compilateur sont pris en compte dans la grammaire du langage. Évidemment avec un langage non conçu pour être vérifié statiquement/compilé comme Python...
t, surtout, cela n'a aucune valeur !
Ah bah oui, moi je connais des gens qui roulaient à 180km/h et qui se sont tués avec une ceinture de sécurité, c'est bien la preuve que la ceinture de sécurité n'a aucune valeur !
Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.
public void foo()
{
//todo : implement this !
}
ca compile, et je peux tester autre chose.
Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.
Mais c'est pas une méthode ! C'est pas un plus un gage de qualité ! C'est juste un outil qui permet d'éviter un certain nombre d'erreur, et qu'à ce titre il paraît idiot de chercher à s'en passer.
C'est comme les tests unitaires, les outils d'analyses statiques de code, toussa, ce sont des outils, qui offrent un certain nombre de vérification, et il est toujours mieux de les utiliser que de s'en passer.
Le bonus c'est que la plupart sont complémentaires.
Euh là, je ne pige pas : le temps de compilation n'est pas ridicule, justement. Sur un projet Java un peu conséquent, cela prend "longtemps".
C'est peanuts par rapport au nombre de vérification que fait le compilateur. Combien de milliers de tests unitaires en Python faudrait-il écrire pour effectuer toutes les vérifications que fait le compilateur Java ? et le temps d'exécution de ces tests ?
Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois
Bof, un serveur d'intégration fait tout ça très bien.
Quand tu veux débugues et que tu testes une modif par minute, chaque seconde de plus est un calvaire (et une perte de temps).
Sauf que toi t'as 100 fois plus de bugs à débogguer, pendant ce temps moi le compilateur il m'a prévenu 100 fois que ca servait à rien de lancer mon code et de chercher à comprendre, l'erreur elle est là, à la ligne 13, caractère 20, d'ailleusr il me suggère même quoi faire. Niveau perte de temps, je sais pas qui en perd le plus...
tu me proposes de rajouter une étape supplémentaire qui n'apporte rien avec pour justification "oui mais ça prend pas longtemps". Attend, dis moi que je rêve...
Forcement, si tu pars du principe que :
- faire l'analyse lexicale
- faire l'analyse syntaxique
- faire des vérifications sémantique : typage, initialisation des variables, etc.
- faire des vérifications de contrat d'interface, de versionning, etc.
tout ca ne sert à rien avant d'exécuter ton programme, effectivement tu dois rêver.
Je pense que je suis loin d'être le seul à faire cela et, en faisant cela, on admet que l'étape de compilation est inutile.
Ben non, ca prouve juste une chose : que le temps de compilation est suffisamment anecdotique pour que tu recompiles systématiquement avant d'exécuter :-p
Ce qui est hallucinant surtout, c'est que t'es pas capable de te rendre compte du boulot que fait le compilateur (associé à un langage avec une syntaxe stricte et un typage statique). Tu dis que le compilateur fait rien, mais dans ta technique (sans compilateur), qui fait tout le "rien" du compilateur ? et quand ?
[^] # Re: Grandiose
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 8.
Le langage Java est compilé en bytecode.
Le bytecode est en partie interprété, en partie Traduit en code natif "à la volée" (JIT).
Quel est l'intérêt ?
Contrôle qualité le plus en amont possible.
La question c'est plutôt : pourquoi ne pas compiler alors que le coût (temps) de compilation est ridicule ?
Ok, cela peut être intéressant pour des raisons de performances mais dans ce cas là on n'utilise pas Java.
On peut vouloir un compromis niveau perf entre Python et le C.
Compiler, c'est un concept dépassé quand on fait du développement
Ce qui est dépassé, c'est de croire qu'on peut se passer de compilateur et que Python va tout révolutionner.
[^] # Re: Tout est vrai
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 5.
[^] # Re: Tout est vrai
Posté par TImaniac (site web personnel) . En réponse au journal Linuxfr en J2EE. Évalué à 10.
[^] # Re: ca fou les boules
Posté par TImaniac (site web personnel) . En réponse au journal Retour sur le Isaac Meeting 2008. Évalué à 2.
dotGNU vise à implémenter ce qui est spécifié à l'ECMA/ISO, comme Mono. Donc y dit qu'il voit le rapport. Comme je l'ai déjà dis, cette pile + la pile d'API Gnome offerte par Mono est largement suffisante pour la majorité des applications Linux.
De plus dotGNU, comme Mono, vise également à implémenter des API pas standardisés comme les WinForms pour permettre à des utilisateurs d'applications uniquement Windows de changer d'OS pour utiliser un OS libre (au pif : Linux), en quoi est-ce mauvais pour l'utilisateur ? C'est la même politique qui a guidé le projet GNU depuis le début.