Journal Linuxfr en J2EE

Posté par  (site web personnel, Mastodon) .
Étiquettes :
129
7
jan.
2009
Que nous propose donc Pierre Tramo, J2EE Lead Architect, pour la refonte de Linuxfr en 2009 ?

Du J2EE bien sûr !

Le cahier des charges : Refaire linuxfr pour noel 2009. La version beta doit être livrée le 1er septembre.
Buget : mieux vaut ne pas y penser.

Déroulement :

Janvier 2009
####
Arrivée des consultants. Ben oui, tout projet J2EE digne de ce nom vient avec sa panoplie de consultant avec des cravates mal attachées et qui jouent tout le temps à cochonland, miniville et autres jeux en flash. C'est un peu une sorte de symbiose naturelle : vous ne trouverez jamais l'un sans l'autre.

Un laptop est donné à chaque consultant. Les deux premières semaines sont passées à configurer le laptop. Chacun installe Eclipse sauf deux qui installent IntelliJ et réclament les licences pour pouvoir l'utiliser. Tous les consultants sont sous Windows sauf un, qui connait bien Linux. Il a installé une Ubuntu puis installé tout à la main depuis les sources.

Les premières réunions sont tenues pour décider de l'architecture. Parce qu'un bon projet, c'est avant tout une bonne architecture. Il est décidé d'utiliser Jboss parce que c'est un serveur d'application libre, ce qui correspond à la philosophie du site. Un représentant de Linuxfr demande ce qu'est un serveur d'application. Un consultant lui fait un diagramme qu'il avoue ne plus comprendre lui-même à la fin. Les premiers shémas voient le jour.

Prise de contact. Le projet est baptisé "Linuxfr-NG". Il suivra un modèle MVC strict. Il utilisera Spring, Struts et plein d'autres noms que seuls les javaistes semblent comprendre.

Février
####
Les consultants installent tous Jboss et, en conséquence, demandent un triplement de la taille de la Ram de leur portable. Deux consultants sont déjà infestés de virus et spamment tout le réseau. Un autre des consultant leur installe un antivirus piraté mais "qui est bien mieux que celui fourni (sic)".

Le shéma des classes est commencé en UML. Fin février, ce shéma s'imprime déjà sur 8 feuilles A4 avec polices en taille 8 qu'il faut assembler dans la salle de réunion.

Un des meneurs identifies différents mécanismes fort semblables et décide de les abstraire avec des Design Patern. Les commentaires et les journaux seront issus d'un FactoryOfUserInput.

Beaucoup de discussions sur le meilleur wiki et le meilleur bugzilla à adopter.

Mars
###
Un problème fondamental est identifié dans ce premier design UML. Tout est refait. Un des consultants entre dans le top 10 de miniville.

Beaucoup de discussions pour savoir si une classe donnée du diagramme UML appartient à M, à V ou à C.

Avril
###
Ce nouveau design semble beaucoup mieux que le précédent. Chaque commentaire est maintenant généré à partir d'un objet FactoryOfSingletonFactoryOfUserComment, ce qui est beaucoup plus propre d'un point de vue MVC (sic). Les consultants suivent une formation sur le développement agile et chacun assigne un rôle à un autre consultant tout en lui collant des post-its de couleur sur l'écran de chaque bug dont il doit s'occuper.

Un couche d'abstraction est créée afin d'intégrer dans la View certains éléments du Controller.

Mai
###
Un des consultants remarque que les tests unitaires écrit en janvier ne se lancent même plus depuis des mois. Il corrige le problème et installe un plugin qui envoie un mail à chaque fois qu'un test ne tourne plus après un commit.

À chaque commit, chaque consultant reçoit 150 mails.

Le chef de projet estime que le bouton "poster un commentaire" fait partie de la View, pas du controller. On décide faire des classes abstraites avec héritage multiple pour satisfaire tout le monde.

Juin (2009 toujours)
###
Réunion avec les clients. La deadline va être difficile à tenir. Si un dépassement de budget est envisageable, on suggère d'embaucher de la main d'oeuvre supplémentaire.

Le nombre de consultants est doublé (et tant pis pour la dépense). Les nouveaux arriveront début juillet.

Le fichier UML fait à présent 16 pages A4. Le code source (pour la plupart généré) atteind 300Mo. Certains fichiers XML de description des propriétés atteignent les 20.000 lignes. Le but de ces fichiers est d'être facilement modifiable par un non-programmeur, le XML étant plus facile que le java.

Juillet
###
Les nouveaux arrivent. Dans le tas se trouve 2 tchèques qui parlent anglais pas trop mal mais sont électroniciens de formation, il n'ont jamais fait de java, 2 italiens qui ne parlent qu'italien.

Le mois de juillet est passé à leur installer l'environnement de développement. On découvre que la procédure d'installation (17 pages sur le wiki, et des longues) n'est plus du tout à jour.

Suite à l'utilisation de librairies spéciales, le projet ne tourne plus que sous Windows. Le consultant qui était sous Linux réinstalle WinXP.

Aout
###
La moitié de l'ancienne équipe travaille à "lancer" les nouveaux dans le projet. Cela commence par leur expliquer ce qu'est Eclipse et comment créer un projet. Les italiens ne pigent rien mais prennent note sur des cahiers. La compilation du projet avec Maven prent 34 minutes en moyenne mais sur une installation fraîche sans aucun cache, cela peut monter à 2h. L'output de la console tourne dans les 30.000 lignes à chaque fois.

Un des tchèques demandent si les tests unitaires vont dans M, dans V ou dans C. Trois réunions s'en suivent parce que certains jugent la question pertinente.

Septembre
###
Implémentation de l'objet AbstractFactoryOfFactoryOfSingletonFactoryOfUserComment. On assigne à un des tchèques la tâche d'écrire les tests unitaires pour tout ce qui a été écrit entre mai et septembre.

La beta est reportée au 1er octobre avec démonstration devant les managers. Le code source fait à présent un total de 800Mo. Le consultant qui utilise Linux ajoute, dans le prototype, un interpréteur Python utilisant Jython car "ça peut toujours servir".

Le wiki comporte 179 pages et la page de garde ainsi que ses descendants directs n'ont plus été modifiés depuis juillet.

À chaque modif, le projet doit être entièrement recompilé pour pouvoir tester. Le serveur doit être également relancé.

Octobre
###
Démonstration du prototype. Le chef de projet ouvre 5 consoles et tape, dans chacune, une commande qui fait facilement 3 lignes de la console en question. Il appuie sur enter, le PC crie et chauffe.

Après quelques minutes de défilement ininterrompus dans les consoles, une interface ressemblant à éclipse apparait. Le tout utilisant la skin Swing. c'est moche à souhait mais le chef de projet, tout fier, explique qu'ils ont utilisé le toolkit eclipse qui permet, par exemple, d'ajouter des "satellites". Au milieu de cette interface, une fenêtre affiche une vue de ce qui ressemble à une liste, genre ce que phpmyadmin affiche quand on explore une table mysql.

Le chef de projet explique que ceci est l'interface d'administration de l'administration du serveur de commentaires. Personne ne comprend.

Il passe ensuite sur une fenêtre Firefox qui met 15 secondes à s'afficher ("désolé, ce PC n'a que 2 Go de Ram mais sur un cluster de serveur, y'a pas de problème hein").

Dans son Firefox apparaît un page blanche avec quelques liens incompréhensibles et un logo Jboss dans le haut de la page.

"Bon, bien sûr, c'est pas l'interface définitive hein ! Ici j'utilise l'interface Jboss et EJB."

Il scrolle. Dans le bas apparait un champ avec un boutton "poster le commentaire".

Le chef de projet tape un petit texte et appuie sur le bouton. Le texte s'affiche alors en haut du champ, en noir.

"Et voilà, commentaire posté !" Il se retourne avec un grand sourire. Voyant le visage des clients, il ajoute : "bien entendu, ce n'est qu'un exemple ! Notre architecture permet une grande souplesse. Imaginez que je souhaite définir un journal, il me suffirait de modifier ça et ça (il ouvre eclipse puis étale sur la table 32 pages attachées sur lesquelles est affiché l'architecture UML).

Les managers sont un peu perplexe.

Novembre
###
La pression de la démo étant passée, le projet n'avance plus trop. Beaucoup de vacances avec la toussaint. Le code des tests unitaires est refactorisé. Trois consultants travaillent sur un framework permettant de gérer plus facilement les tests unitaires du projet (dont près de la moitié passent).

Décembre
###
Le projet a du retard et ne pourra pas être mis en production en janvier 2010. Il est décidé de reprendre la maitenance de la version Templeet et de réduire l'équipe qui travaille sur Linuxfr-NG.

Le chef de projet livre une documentation de 240 pages sur l'état actuel du framework, sur l'étude de faisabilité, sur les forces et faiblesses du projet. Le tout compile un rapport que chaque consultant a du faire. Il y est estimé que le site sera fonctionnel en juin 2010 mais qu'il est important de ne pas s'éparpiller.

Juin 2010
###
Seul 5 consultants sont encore présents pour travailler sur le projet. Ils font principalement la documentation des bugs qu'ils trouvent et qui empêche le projet de se lancer depuis la mise à jour de Windows en SP3.

Novembre 2010
###
Le projet est abandonné mais comme les consultants sont partis petit à petit, personne ne s'en rend vraiment compte. Deux consultants sont d'ailleurs encore là et aide l'équioe templeet depuis 2 mois. On leur donne des trucs à faire par ci par là.

Decembre 2010
###
Personne ne se souvient plus réellement de cette idée. Officiellement, le projet a été fusionné avec la maintenance de la version existante. Le serveur SVN et son 1,6Go de code source crashe, personne ne le restaure.
  • # Autre projet

    Posté par  . Évalué à 10.

    pBpG bosse sur un linuxfr en C#/.Net.
    Il y a des problèmes pour la tenue en charge, mais on compte sur la lois de Moore pour être prêt en 2018. Ça donne du temps.
    • [^] # Re: Autre projet

      Posté par  . Évalué à 6.

      En même temps, ça va coïncider pile poil avec la sortie d'IE9...
    • [^] # Re: Autre projet

      Posté par  . Évalué à 10.

      Je vois mal pourquoi je le reecrirais en C#/.Net alors que j'ai deja un prototype de linuxfr a base de feuilles Excel qui tourne.
      • [^] # Re: Autre projet

        Posté par  . Évalué à -10.

        Ah mais c'est une bonne nouvelle ça. Ca veut dire que tu vas pouvoir faire passer ta propagande sur ton propre prototype à base de C#/.Net où tu seras à l'abris de toutes les personnes qui ne pensent pas comme toi, c'est formidable.

        Et puis, il y aurait un petit avantage secondaire, tu n'aurais pas à déployer toute cette belle énergie juste pour pourrir les discussions où tu prends part.
        • [^] # Re: Autre projet

          Posté par  . Évalué à 10.

          C'est vrai qu'en parlant de pourrir les discussions tu en connais un rayon toi...
          • [^] # Re: Autre projet

            Posté par  . Évalué à -10.

            C'est que je t'ai bien observé avant de te connaître...
            • [^] # Re: Autre projet

              Posté par  . Évalué à 10.

              C'est pas très flatteur pour ton sens de l'observation.
            • [^] # Re: Autre projet

              Posté par  . Évalué à 7.

              La différence entre toi et pasbillpasgates, c'est que lui, il est controversé, mais il le fait exprès et il argumente.

              Toi, tu argumentes comme un enfant en primaire à l'école. Pour ton information, c'est pas très sympa pour toi ;-)
              • [^] # Re: Autre projet

                Posté par  . Évalué à -4.

                Je n'argumente plus avec pbpg, ça ne sert pas à grand chose puisqu'il a forcément raison.
                • [^] # Re: Autre projet

                  Posté par  . Évalué à 7.

                  Tu confonds. pBpG n'a pas forcément raison, c'est toi qui a forcément tort.

                  Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

  • # Vive le vent !

    Posté par  . Évalué à 10.

    T'es bloqué par la neige et le verglas, et tu ne prévois pas de bouger d'où tu es d'ici vendredi ? C'est ça ?
  • # Grandiose

    Posté par  (site web personnel) . Évalué à 9.

    ploum, c'est grandiose. Je fais pas mal de développements web sur mon temps libre (en PHP, voir PhpWebGallery) et du Perl dans le cadre du boulot. Je suis entouré de développeurs Java qui ne jurent que par Eclipse. Même si tu caricatures un poil, c'est pas trop, c'est plausible :-)

    Java, l'art de faire compliqué/complexe quand on peut faire simple. Java, sans IDE t'es rien. Mais bon, y'a des "ressources" (des gens) Java partout pour un coût variant du tout jeune diplômé à l'architecte Java (15 ans d'expérience, s'il vous plaît). C'est un ecosystème qui a encore de beaux jours devant lui : les SSII peuvent chiffrer des centaines de jours sur le moindre ajout d'écran dans une appli et pendant ce temps là, SUN met le paquet pour que les décideurs pressés soient convaincus que Java est la solution. Les écoles d'ingénieurs formant toutes à Java maintenant, la boucle est bouclée. Dans un projet d'informatique de gestion, même si tu ne veux pas faire de Java, les ressources disponibles et la mouvance actuelle font que tu vas forcément vers Java.

    Cela dit, une interface Eclipse, c'est relativement beau et fonctionnel, faut pas être hypocrite.
    • [^] # Re: Grandiose

      Posté par  (site web personnel) . Évalué à 9.


      Java, l'art de faire compliqué/complexe quand on peut faire simple.


      Je pense au contraire que la tendance de faire compliqué ce qui est simple vient en général de ce qui est entre la chaise et le clavier et pas nécessairement de Java ; parce que la plate-forme Java connait un nombre croissant de développeurs, et donc que l'on trouve aussi bien du moins bon que du bon, il est normal que l'on perçoit plus facilement ce genre d'attitude. En tout cas, on trouve bcp de parasites avec une insufférable suffisance.
      En tout cas, ta phrase m'a fait penser à ce que j'ai lu un jour : 'Java est un langage pour débutant'.


      Cela dit, une interface Eclipse, c'est relativement beau et fonctionnel, faut pas être hypocrite.

      Oui ... et avec bcp (trop) de bogues. Quand je peux éviter Eclipse, je le fais.
      • [^] # Re: Grandiose

        Posté par  . Évalué à 1.

        En tout cas, J2EE c'est clairement faire compliqué pour un truc simple.

        Envoyé depuis mon lapin.

        • [^] # Re: Grandiose

          Posté par  (Mastodon) . Évalué à 10.

          J2EE n'a pas été conçu pour permettre de faire facilement des trucs simples, mais pour rendre possible la réalisation d'application très complexes.
      • [^] # Re: Grandiose

        Posté par  . Évalué à 5.

        En tout cas, ta phrase m'a fait penser à ce que j'ai lu un jour : 'Java est un langage pour débutant'.

        Tu pense probablement à cette citation sortie à l'occasion d'une news concernant Arc:

        Java was, as Gosling says in the first Java white paper, designed for average programmers. It's a perfectly legitimate goal to design a language for average programmers. (Or for that matter for small children, like Logo.)

        Paul Graham ( http://paulgraham.com/arcll1.html )
    • [^] # Re: Grandiose

      Posté par  . Évalué à 7.

      Oui toutafé, dans ce journal, on voit bien que le problème, ce sont les "consultants" et les "SSII" et non pas Java en lui même.

      Pourquoi utiliser conjointement Struts et Spring ?

      En utilisant Spring, on a besoin que de Tomcat en serveur, et non JBoss, bien plus lourd. (JBoss inclus Tomcat, et beaucoup, beaucoup d'autres choses).

      (cf. http://static.springframework.org/docs/Spring-MVC-step-by-st(...) ).

      J'ai voulu essayer Tomcat récemment, dans ma distribution Linux. Ca m'a pris 1 heure pour l'installer, le configurer, et essayer les exemples. Et c'était sur un PC avec 256 Mo de RAM.
      • [^] # Re: Grandiose

        Posté par  . Évalué à 6.

        (cf. http://static.springframework.org/docs/Spring-MVC-step-by-st(...) ).
        Un des premiers trucs à faire dans ce tutorial est d'écrire un fichier XML pour ant de 100 lignes ... Franchement, ça me décourage rien qu'à le lire.
        • [^] # Re: Grandiose

          Posté par  . Évalué à 5.

          Tu préfères faire du C et te taper 300 lignes d'autoconf/automake/m4/libtools et passer le prochain mois à essayer de faire marcher le bouzin ?

          On peut critiquer plein de choses, mais la ca devient vraiment ridicule... Ant c'est laid, c'est moche si on veut. Mais t'y passe une journée sur 2 ans de dev ! Lire ce code et comprendre chaque action ça m'a pas pris plus d'une minute.

          C'est quoi ton environnement de dev si parfait ou tout est génial et y'a rien de chiant à faire ? Faut bien le compiler à un moment ton code, et personnellement entre ant, cmake, scons, make ou les autotools y'a rien qui me fait vraiment bander... En l'occurrence dans le fichier qu'ils donnent il n'y a pas d'information redondantes, je vois pas bien comment tu veux faire plus court. C'est juste le XML qui te gène ?
          • [^] # Re: Grandiose

            Posté par  (site web personnel, Mastodon) . Évalué à 4.

            "C'est quoi ton environnement de dev si parfait ou tout est génial et y'a rien de chiant à faire ?"

            Python.

            Tu apt-get install les packages python-xxx qui sont nécessaires pour ton projet.
            Tu lances "python main.py"
            Et voilà...


            Les gars, faut ouvrir un peu les yeux : quand tu dois commencer à utiliser des outils pour pouvoir utiliser tes outils, c'est un peu angoissant. La palme revient quand même à Gcc. Comme c'était compliqué de compiler, on a fait make. Comme faire un makefile, c'est conpliqué, on a fait configure. Comme configure c'était compliqué, on a fait autogen. C'est incroyable. Et Java fonce droit dans la même veine.

            J'avoue que même en python, certains essayent de pourir un peu avec les eggs et des trucs comme ça. Ou pire : zope. Mais dans les projets modernes, tu peux trouver de très gros programmes en python qui se lancent avec python main.py. Pour le développement web, django a une philosophie très similaire.

            Moi perso, dans mes projets, j'estime qu'un programme doit pouvoir se lancer avec un start.sh, rien d'autres. Si ce n'est pas le cas, le programme est mal fichu tout simplement.

            Mes livres CC By-SA : https://ploum.net/livres.html

            • [^] # Re: Grandiose

              Posté par  (site web personnel) . Évalué à 9.

              Moi perso, dans mes projets, j'estime qu'un programme doit pouvoir se lancer avec un start.sh, rien d'autres. Si ce n'est pas le cas, le programme est mal fichu tout simplement.

              Je vois pas le rapport entre des outils pour compiler un langage compilé et lancer ce programme compilé et un programme interprété ou en lance l'interpréteur directement sur les sources.

              Parce que je vois pas ce qui empêche de faire un start.sh pour n'importe quel programme.
              • [^] # Re: Grandiose

                Posté par  . Évalué à 1.

                un programme interprété ou en lance l'interpréteur directement sur les sources.
                En réalité c'est plus compliqué que ça.

                Quand tu lance l'interpréteur sur un fichier source il le compile automatiquement en byte code (.pyc) et se charge de déterminer si il faut le réutiliser ou non à la prochaine exécution en se basant sur la date de dernière modification.
                En gros il fait un gros taf et correctement sans rien demander à personne. Les perf tombent un peu à la première exécution mais on s'en cogne.

                Concernant les fameuses TypeError, les applis Java crashent peut être moins car le compilo impose de catcher toutes les erreurs mais si c'est pour faire comme éclipse et simplement balancer de fenêtres modales avec des messages imbitables ...

                Et pour l'anectode si on veut coder aussi strict qu'avec un compilateur mais en Python on peut très bien utiliser PyLint ou autre.
                • [^] # Re: Grandiose

                  Posté par  . Évalué à 2.

                  PyLint ne peut tout simplement pas deviner tous les types, et donc détectera beaucoup moins d'erreurs. En fait, PyLint ne trouve pas grand chose de plus que l'utilisation de tabs au lieu d'espaces, ou des noms de variables qui ne conviennent pas à son standard (selon lui, il est interdit d'appeler une variable 'i' ou 'n').
            • [^] # Re: Grandiose

              Posté par  . Évalué à 1.

              C'est sur qu'un langage interprété tu n'as pas besoin de le compiler. Tu n'enfonces pas une porte ouverte la ?

              Tu passes de la compilation au lancement de l'application comme si c'était la même chose (en python c'est le cas).

              Python est effectivement un très bon langage qui à lui aussi ses contraintes... Y'a pas de miracle ce que tu gagnes en souplesse tu le perds ailleurs...
              • [^] # Re: Grandiose

                Posté par  (site web personnel, Mastodon) . Évalué à -2.

                Me semblait que Java était également interprété ... (aha, la blague).

                Mais sinon, pourquoi vous voulez absolument compiler ? Quel est l'intérêt ? Ok, cela peut être intéressant pour des raisons de performances mais dans ce cas là on n'utilise pas Java.

                Compiler, c'est un concept dépassé quand on fait du développement, cela ne devrait plus exister que pour l'optimisation d'un produit "fini".

                Mes livres CC By-SA : https://ploum.net/livres.html

                • [^] # Re: Grandiose

                  Posté par  . Évalué à 9.

                  > Compiler, c'est un concept dépassé quand on fait du développement, cela ne devrait plus exister que pour l'optimisation d'un produit "fini".
                  Ouch ! Et les vérifications (de type pour les plus basiques), qui t'évitent par exemple de te taper une méchante et cependant bête TypeError au moment le plus critique que tes tests unitaires (car j'imagine que tu en fais, c'est très sur la vague "développement agile/rapide") n'auront pas détectés, qu'en fais-tu ?
                  • [^] # Re: Grandiose

                    Posté par  . Évalué à 0.

                    Rien à voir avec l'opposition compilation/interprétation. Un langage compilé peut très bien être à typage dynamique (par exemple Objective-C) tandis qu'un langage interprété peut parfaitement bien être à typage statique (par exemple Ch).
                • [^] # Re: Grandiose

                  Posté par  . Évalué à 10.

                  > Me semblait que Java était également interprété

                  C'est un sujet à part entière tellement les limites sont flous.

                  > Mais sinon, pourquoi vous voulez absolument compiler ?

                  Dans un contexte de langage statiquement et fortement typé, un code qui compile est un code qui peut s'exécuter (ça ne dit pas qu'il est correct). Ton code python tu n'as aucune certitude qu'il est capable de s'exécuter dans n'importe quel cas. Il faut connaître tout les flow d'exécution possibles sur le bout des doigts, toutes les variables par cœur et ne jamais faire de typo ou tu le découvrira... un jour.
                  Ça n'a peut être pas d'importance pour toi, mais quand tu bosses sur un projet avec une équipe ça devient vite très difficile à gérer. Ouai c'est très agréable sur des petits trucs ou si tu bosses tout seul. J'aime bien scripter en Python

                  Si tu passes la phase de compilation à l'exécution (ou simplement que tu es en typage dynamique) ça peut péter n'importe quand à runtime pour des milliers de raisons.

                  Si tout les devs qui sont passés de Java 4 à Java 5 ne reviendraient pas en arrière ce n'est pas pour les caractères de cast gagnés ou l'introduction du printf. Les codes sont beaucoup plus robustes (CAML est une merveille dans ce domaine).

                  > pour des raisons de performances mais dans ce cas là on n'utilise pas Java.

                  Il y a énormément de raisons de ne pas utiliser Java mais là non. Si tu ne mets pas des mongoliens derrières le clavier, Java à des perfs très respectables. L'assembleur produit par hotspot est vraiment de bonne qualité, et je t'invite à comparer les sorties d'hotspot (voir http://weblogs.java.net/blog/kohsuke/archive/2008/03/deep_di(...) pour savoir comment activer le mode verbose) à celles de gcc fortran ou C. Le gagnant est assez rapide à trouver. Au dessus de ça, J2SE n'est pas un veau et les performances augmentent de manière significatives à chaque release. Le tableau de Java 1.[0-2] était totalement différent.

                  Je t'invite aussi à lire http://hal.inria.fr/docs/00/31/20/39/PDF/RT-0353.pdf . Tu peux implémenter les benchs en python, ça ne devrait pas te prendre plus d'un à deux mois.

                  Après tu peux rentrer dans un autre monde en tapant beaucoup plus bas niveau mais ce n'est pas le sujet ici.
                  • [^] # Re: Grandiose

                    Posté par  . Évalué à -1.

                    > Ton code python tu n'as aucune certitude qu'il est capable de s'exécuter dans n'importe quel cas.

                    En Java non plus, cf le maintenant célèbre NullPointerException.
                    Et avec les annotations qui arrivent, il sera possible de faire des vérifications de type en Python. Ce sera au final proche de l'Objective-C qui permet à la fois de faire du typage statique et dynamique selon ce qui est le plus adapté pour ton projet, à la seule différence qu'en Python ce sera "par défaut" du dynamique tandis qu'en Objective-C c'est "par défaut" du statique.

                    > Si tu passes la phase de compilation à l'exécution (ou simplement que tu es en typage dynamique) ça peut péter n'importe quand à runtime pour des milliers de raisons.
                    Si tu ne le fais pas aussi. Non sequitur.
                    • [^] # Re: Grandiose

                      Posté par  . Évalué à 3.

                      « [À propos de l'exécution d'un prog dans n'importe quel cas] En Java non plus, cf le maintenant célèbre NullPointerException. »
                      Pas tout à fait d'accord. Ce qui fait de Java un langage « presque » type-safe (« presque » à cause des types primitifs qui ne sont pas des objets), c'est la garantie que ton programme ne sera pas dans un état « bloqué » / « coincé » (stuck). Quand tu as un null pointer exception, ton programme se termine bien « correctement » (même si la sortie est une erreur). À titre de comparaison en C, comme il n'y a pas de sûreté des types, tu peux te retrouver avec des résultats totalement erronés sans pour autant avoir le moyen de vérifier « facilement » que c'est bien le cas.
                • [^] # Re: Grandiose

                  Posté par  (site web personnel) . Évalué à 8.

                  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.
                  • [^] # Re: Grandiose

                    Posté par  (site web personnel, Mastodon) . Évalué à 1.

                    "Contrôle qualité le plus en amont possible."

                    Dans ce cas, il faut utiliser un vérificateur de code où quoi que ce soit d'autres. Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.

                    Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.

                    De plus, quand tu développes, tu peux vouloir tester une fonction tout en sachant que le reste n'est pas encore développé. Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester.

                    L'utilisation du compilateur comme un indicateur de la qualité du code est l'un des trucs les plus effrayant qu'on puisse sortir pour justifier la compilation. Et pose aussi de sérieuses questions quand à la qualité du code produit avec cette méthode.


                    "La question c'est plutôt : pourquoi ne pas compiler alors que le coût (temps) de compilation est ridicule "

                    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". Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois ("sinon y'a des erreurs du à des trucs pas recompilé mais qui devraient l'être (sic)"). 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).

                    Et quand bien même le temps serait vraiment ridicule, ce n'est pas une justification : 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...


                    Lors du développement d'un soft, personnellement je finis toujours par écrire un script qui compile, fais tout ce qu'il faut et qui lance le soft. Je modifie le code, lance mon script pour tester, modifie le code, lance le script, ...

                    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.

                    Mes livres CC By-SA : https://ploum.net/livres.html

                    • [^] # Re: Grandiose

                      Posté par  . Évalué à 7.

                      "Dans ce cas, il faut utiliser un vérificateur de code où quoi que ce soit d'autres. Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.

                      Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur !
                      "
                      Ben justement : utiliser le compilateur semble être tout à fait adapté puisqu'il comporte forcément un vérificateur de code.
                      Si ce dernier gueule, le compilateur renvoie l'erreur relevée.

                      " N'importe qui peut te pondre du code qui compile mais qui ne tourne pas."
                      C'est pour ça qu'on parle de bugs à la compilation (erreur syntaxique) et de bugs à l'exécution (pointeur 'null', dépassement de tableaux...)

                      "De plus, quand tu développes, tu peux vouloir tester une fonction tout en sachant que le reste n'est pas encore développé. Le fait de "vérifier ton code" à ce moment là n'a aucun sens et tu ne pourras pas compiler et donc pas tester."
                      Et l'Homme inventa les interfaces.


                      "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". Et lorsque le projet est un peu foireux, il faut souvent faire un clean à chaque fois ("sinon y'a des erreurs du à des trucs pas recompilé mais qui devraient l'être (sic)"). 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)."
                      Un bon IDE peut compiler le code au fur et à mesure de son écriture. Eclipse (par ex) fait ça très bien, cela ne se ressent pas lors du développement, et voir en (quasi) temps réel les erreurs de syntaxe que l'on commet est un plus non-négligeable.
                      Et je préfère ça à ta méthode qui consiste à tout compiler d'un coup (donc traitement pouvant être long) pour s'apercevoir qu'on a oublié un ';' en fin de ligne...

                      "Lors du développement d'un soft, personnellement je finis toujours par écrire un script qui compile, fais tout ce qu'il faut et qui lance le soft. Je modifie le code, lance mon script pour tester, modifie le code, lance le script, ..."
                      Où est la différence avec un script Ant ?
                      • [^] # Re: Grandiose

                        Posté par  (site web personnel, Mastodon) . Évalué à 4.

                        Je renonce à argumenter plus car je ne ferais que me répéter. Je comprend ton argument comme "Un compilateur comporte un vérificateur de code dont on doit utiliser un compilateur plutôt qu'un vérificateur de code dédié" et cela ressemble à un sophisme.

                        Mais juste une note pour Ant : j'aurais du préciser que j'écris ce script qui compile/lance sauf en python où c'est automatique. Le fait que Ant existe est la preuve que c'est une faiblesse du java mais Ant est justement un outil de plus à apprendre.

                        Ce que j'essaye d'expliquer c'est que, plus tu rajoutes des outils, plus tu complexifies et plus tu vas rajouter des outils pour simplifier. C'est une voie de garage par excellence et c'est complètement anti-productif. ("j'ai passé seulement 2heures et j'ai un super script Ant." Super. C'est 2h que tu n'as pas passé sur ton produit).


                        Je vais faire plus simple : j'ai deux machines qui font un travail. La première comporte un gros boutton rouge. La seconde comporte 5 bouttons : rouge, vert, mauve, jaune, bleu. Le manuel de la première explique qu'il faut appuyer sur le boutton pour la mettre en marche ou pour l'arrêter si elle est en marche. Le manuel de la seconde explique que le boutton mauve est un préchauffage, le boutton bleu l'initialisation, le boutton vert le lancement, le boutton rouge la confirmation du lancement et le boutton jaune l'arrêt de la machine.

                        Et toi, tu es en train de défendre que c'est logique d'appuyer sur le boutton bleu parce que, forcément, il faut bien initialiser la machine et que c'est une machine super facile à utiliser vu que quand tu veux la lancer il suffit de faire mauve, bleu, vert, rouge et encore, le mauve n'est pas toujours nécessaire, t'es pas obligé d'appuyer dessus si l'indicateur de température dépasse une certaine valeur.

                        Mes livres CC By-SA : https://ploum.net/livres.html

                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 3.

                          Je pense surtout que tu "simplifie" un peu. Ant, tu l'utilise pas pour le petit
                          jeu que tu développe en projet d'étude.

                          Ant, ça va te chercher le source par SSH, FTP, HTTP, WTFYW sur le server de dev, compile en local et repousse les class ou il faut sur le serveur de prod. ça, c'est super bien !
                          Ant, ça peut te lancer Firefox à la fin de la compilation de ta servlet avec les bon paramètre en URL.
                          Ant, ça peut te faire des compilations au petit oignon, avec de belle log au bonne endroit, toussa toussa.
                          Ant, ça te fait des Web Archive prêtent à l'emploi.
                          Ant, c'est un outil pour les projets conséquent, je m'en sert pas pour les trucs avec 20 class qui dorme dans un répertoire.

                          De plus, Ant, tu fais un fichier une fois, ensuite, tu le garde dans un coin et tu t'en sert toute ta vie.
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 1.

                          T'es en train de nous dire qu'une cafetière c'est mieux qu'un pc parce qu'il y a moins de boutons ?

                          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                          • [^] # Re: Grandiose

                            Posté par  . Évalué à 1.

                            Il y a même des cafetières sans bouton, le top du top si je comprends bien :-)
                          • [^] # Re: Grandiose

                            Posté par  (site web personnel) . Évalué à 6.

                            Non, la caftière c'est pas bien car elle fait trop de choses : elle fait même le café.
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 2.

                          C'est marrant parce que il existe l'équivalent de make/ant pour python comme par ex scons.
                          C'est donc que ca doit bien servir à quelque chose et pas seulement à compiler comme par exemple enchainer les test unitaires génerer la doc utilisateur, commiter avec un tag , mailer l'equipe avec le changeset, ....

                          Ah oui c'est vrai avec Ant/Java il y a une cible de plus la compil.
                          On en revient au sujet static vs dynamic typing
                          • [^] # Re: Grandiose

                            Posté par  . Évalué à 3.

                            C'est marrant parce que il existe l'équivalent de make/ant pour python comme par ex scons.
                            Gni ? Scons est écrit en python, mais n'est pas destiné pour python à la base ... T'as un exemple ?
                      • [^] # Re: Grandiose

                        Posté par  (site web personnel) . Évalué à 3.

                        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.
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 3.

                          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.


                          J'ai tendance a être daccord avec ploum
                          oui tu donnes de bonnes raisons d'utiliser un compilo, mais en phase de dev, je trouve que c'est un poids, une vérif statique du code ou une compile entre midi et 2 ou la nuit, ça me suffit, le reste du temps je trouve que c'est un poids, car souvent long.
                          • [^] # Re: Grandiose

                            Posté par  . Évalué à 3.

                            C'est pour ça que qu'il faut dissocier les 2 sujets compilation et typage statique.

                            Le typage statique à un intérêt certain et il n'est pas forcément nécessaire de compiler pour utiliser un langage statique avec un interprète.

                            Avec les IDE actuels qui font de la compilation incrémentale ce n'est franchement plus un problème.

                            Les solution telle que Pylint apporte des solutions il est vrai, mais qu'en est t'il lorsque tu importes une librairie qui propose un contrat donné et que tu attends en fait un autre contrat (le fameux duck typing), genre un méthode qui ne figure pas dans la lib importée.

                            Si tu n'as pas fait la couverture de ton code correctement et que tu n'es jamais passé dedans dans tes tests, ca te pète à la figure devant le client.

                            Avec un langage statique et compilé ca n'arrive pas puisque ca compile pas.
                            • [^] # Re: Grandiose

                              Posté par  . Évalué à 3.

                              je pense que tu dérives un peu du débat, on parlait juste de la compilation.
                              Ce que je voulais dire, c'est que par exemple en ocaml on peut développer en mode interprété et compiler pour la livraison, il me semble qu'en python c'est également le cas, où l'on peut compiler en pyc pour la livraison.

                              La compilation incrémentale peut être un plus, en pratique sous eclipse ça a plus tendance à mettre ma machine sur les genoux et à m'empecher de bosser, de plus le fait de compiler est toujours plus lourd qu'une "simple" analyse statique du code.

                              Au sujet du duck typing je suis daccord avec toi, néanmoins ça arrive aussi avec du code compilé, comme par exemple en C++ quand le dev de la lib oublie d'utiliser un pointeur d ( c'est du vécu... et en plus c'était moi le dev en question ;) )
                              • [^] # Re: Grandiose

                                Posté par  . Évalué à 3.

                                de plus le fait de compiler est toujours plus lourd qu'une "simple" analyse statique du code.

                                Gni ? Une analyse statique ça peut être bien bourrain potentiellement suivant ce que tu veux analyser ... étant donné la difficulté du problème de vérification du code.

                                En C++, pour faire pêter le code avec une erreur de typage, il faut le vouloir, genre faire des casts de bourrains ... Pour ton histoire de pointeur, pas compris à quoi tu voulais faire référence, intuitivement je dirai utilisation d'un pointeur sur un objet alloué sur la pile, et dans ce cas c'est pas vraiment une erreur de type.
                                • [^] # Re: Grandiose

                                  Posté par  . Évalué à 0.


                                  Gni ? Une analyse statique ça peut être bien bourrain potentiellement suivant ce que tu veux analyser ... étant donné la difficulté du problème de vérification du code.


                                  Tout à fait, je pensais en fait juste aux erreurs de syntaxes et de typage, bref ce que le compilo vérifie également

                                  Pour être complètement honnête, je n'ai utiliser la compilation incrémentale qu'en c++, ou éclipse refait un make all à chaque fois. Possible qu'en java cela soit mieu géré.

                                  Pour ton histoire de pointeur, pas compris à quoi tu voulais faire référence

                                  http://techbase.kde.org/Policies/Binary_Compatibility_Issues(...)
                                  En c++ ce genre de truc est nécéssaire pour assurer la compatibilitée de tes libs. En réalité c'est un problème de mangling, mais bon, du point de vue développeur, ton programme plante à l'utilisation d'une classe précise (raccourci facile ? bon daccord... ;) )
                          • [^] # Re: Grandiose

                            Posté par  (site web personnel) . Évalué à 2.

                            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.
                          • [^] # Re: Grandiose

                            Posté par  . Évalué à 2.

                            Je ne suis pas d'accord, la plus petite modification du code peut néanmoins entraîner des erreurs qui sont vues à la compil'.
                    • [^] # Re: Grandiose

                      Posté par  (site web personnel) . Évalué à 6.

                      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 ?
                    • [^] # Re: Grandiose

                      Posté par  . Évalué à 5.

                      Un compilateur n'a pas pour but de vérifier ton code, il a pour but de transformer ton code en exécutable.

                      Je ... hein ? Un compilateur fait bien plus que ce que tu sembles croire.

                      La vérification des types, et la garantie de leur sûreté fait partie du rôle du compilateur... Quand la norme/le standard/la spécification du langage le permet. Par exemple en C, faire une vérification de type fiable est difficile, car le langage est faiblement typé. En Java, du moment qu'on exclut les types primitifs (donc pour tout le reste qui nous intéresse déjà beaucoup plus, à savoir les objets), il y a du lambda calcul un peu partout, avec une garantie de « type safety ».

                      Un compilateur sert aussi de « prouveur » -- même si le plus souvent les preuves ne sont que « partielles ». Je veux dire par là que le compilateur, en démontrant que des bouts de ton programme satisfont certaines propriétés -- par exemple, si tu fais une boucle dont l'en-tête est

                      M = 1000;
                      ... // pas de réécriture de M
                      N = M
                      for (i = 0; i < N; ++i)

                      le compilateur devrait être capable d'inférer la borne de la boucle for, et du coup de déterminer certaines propriétés liées à ladite boucle. Bref, le compilateur est aussi là pour garantir certaines propriétés au programmeur concernant son programme. Après, la somme des propriétés dépend des objectifs du langage.


                      Justement, utiliser un compilateur pour contrôler la qualité est vachement inquiétant parce que ça n'a pas été conçu pour ça et, surtout, cela n'a aucune valeur ! N'importe qui peut te pondre du code qui compile mais qui ne tourne pas.

                      Ben non. Plus tu peux déterminer de « fautes » en amont (je mets entre guillemets, parce que parfois soit on fait un truc « crade » mais qui va vite, soit on perd 10 à 20% de perfs, ou plus), et moins ton code risquera d'avoir de bugs. Plus exactement, en C, il est facile de compiler un code, « sans erreur », et que celui-ci plante, ou pire, donne un résultat inexact. En Java, ou encore « pire », en OCaml, certains types d'erreur (comme celles dues au transtypage, ou aux types en règle générale) sont totalement évitées car détectées à la compilation. Je ne vois pas ce que tu peux reprocher à ce comportement. Et oui, c'est clairement le rôle du compilateur de faire tout ça, car de son point de vue (et des specs du langage), il s'agit bien d'une erreur du programmeur.

                      Concernant l'inutilité de l'étape de compilation, je serais d'accord avec toi si les compilateurs étaient de bêtes traducteurs « code source » => « code machine », mais c'est très loin d'être le cas. Il y a bien sûr la partie front-end qui fait les analyses lexicales et grammaticales (et si je ne me trompe pas, une partie des analyses sur les types se fait à ce moment), mais juste après il y aussi le middle-end qui se charge de transformer le code pour l'optimiser, puis le back-end qui génère le code. Sans parler du fait que middle-end et back-end ont besoin de communiquer pour générer efficacement du code, etc.

                      Au final, un bytecode (bien) compilé, avec en plus du JIT pour les parties « chaudes » du programme peut permettre de gros gains de perfs au lancement de l'application.
                      • [^] # Re: Grandiose

                        Posté par  (site web personnel, Mastodon) . Évalué à 2.

                        Je sais pas pourquoi vous vous tuez à vous acharner pour m'expliquer le fonctionnement d'un compilo. Je sais bien que ça fait plein de trucs et que ça trouve des erreurs. Mais ces erreurs là, je les trouve aussi en Python en lançant mon code. Et tout ce que fait le compilo "en plus", ça ne justifie pas le fait de compiler (dont la définition est de produire un exécutable, je le rappelle. On ne compile pas pour vérifier son code, c'est une conséquence, pas un but).

                        Depuis le début, j'explique que je critique la nécessité de "compiler" à chaque fois dans un environnement de dev. Je ne critique pas le fait de checker le code et d'optimiser car c'est très utile mais, en cours de dev, ça devrait juste être facultatif.

                        Mes livres CC By-SA : https://ploum.net/livres.html

                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 6.

                          > Mais ces erreurs là, je les trouve aussi en Python en lançant mon code

                          Bha non tu ne trouves que *certaines* de ces errreurs. En gros tout ce que tu sais c'est que ton code tourne pour le flow d'exécution que tu as pris. On se retrouve toujours avec des flows d'exécution bizarres et merdiques en prod un fois qu'il y a un crétinutilisateur à l'autre bout.

                          Note que même si tu avais une couverture de code à 100% ça ne prouverait rien.

                          Si tu tiens vraiment à ne pas builder ton projet, tu noteras que les utilisateurs d'IDE en Java (il faut être très bête pour s'en priver) se retrouvent avec exactement le même comportement que python puisque seuls les classes modifiées sont recompilées. Cela dit, tu apprends assez vite que tu as tout intérêt à *toujours* tourner ton soft dans les *mêmes* conditions que tes utilisateurs.

                          On pourrait aussi parler des gros refactoring en typage dynamique, c'est toujours un grand moment de joie et de sérénité. C'est assez passionnant de passer son temps à chercher des canards boiteux.

                          Quand tu vois ce qui arrive encore à merder en ayant formatage de code/build/packaging automatique, une grosse suite de test unitaire/fonctionnel/intégration et un build après chaque commit. Bien je me dis que soit y'a des surdoués qui ne font jamais d'erreur soit y'a un paquet de c0wb0yz...

                          En pyton tu passes ton temps à lancer des execs pour voir si ton truc marchouille. Quand je lance un projet java en synchrone c'est par ce que les tests ont foiré, que les logs ne disent rien et qu'il est temps de brancher un debugger. Autrement tu lances les tests fonctionnels sur une autre machines et tu bosses sur autre chose. 12 secondes de compilation (32Mo de source) pour 40 minutes de tests... Quand tu n'es qu'au stade du test unitaire sur une nouvelle classe, avec un IDE c'est exactement comme python !
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 2.

                          C'est ridicule, en python aussi, ton code est compilé à chaque fois... Les deux sont compilés, le temps de compilation global est donc le même (à peu de chose près) !!!

                          C'est juste qu'en Java il est compilé quand tu le tapes, dans ton IDE, avec les belles erreurs/warnings qui s'affiche directement, en te soulignant ce qui va pas et te proposant éventuellement un correction.
                          En python il est compilé juste avant l'exécution, et tu as une erreur quand tu lances ton programme...

                          Qui gagne le plus de temps à ton avis ? Celui qui détecte l'erreur en amont ou celui qui la détecte à l'exécution ?
                          • [^] # Re: Grandiose

                            Posté par  . Évalué à 0.

                            enfin bref, ce qui interesse cest un bon ide
                            et un bon ide ne se prend pas la tête à compiler à chaque fois que tu tapes une ligne, sinon quelle horreur pour les ressources.
                            • [^] # Re: Grandiose

                              Posté par  . Évalué à 1.

                              c'est ce que fait eclipse pourtant.
                              Enfin, pas exactement, il va pas compiler a proprement parler le code fraichement tape, mais il va te souligner en rouge ton nom de classe si tu t'arretes de le taper pendant 2 secondes.
                              • [^] # Re: Grandiose

                                Posté par  . Évalué à 2.

                                c'est ce que fait eclipse pourtant.

                                C'est bien ce que je disais ;)
                                Squeak arrive à faire ça très bien sans pour autant faire bruller ma machine ;)
                              • [^] # Re: Grandiose

                                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                                Je trouve qu'Eclipse est un monstre en termes de ressources, qu'il est complètement anti-ergonomique (et encore) mais, fonctionnellement, je reconnais que ce genre de fonctionnalité est très utile quand on développe.

                                Mes livres CC By-SA : https://ploum.net/livres.html

                                • [^] # Re: Grandiose

                                  Posté par  . Évalué à 1.

                                  Eclipse est un monstre en ressources, certes.
                                  Apres, tu t'en sert souvent sur de gros projet, ou t'as besoin de faire beacuoup de choses. Donc forcement, ca bouffe des ressources, eclipse ou pas.

                                  Pour l'ergonomie, ca s'addresse a des developpeurs, qui comprennent le fonctionnement intime d'une appli et ils peuvent donc se permettre certaines choses que tu peux pas te permettre dans une appli normale. Mais ouais, ya qq trucs qui sont bien pete couilles (le remapping des raccourcis est une horreur notamment, la gestion des plugins est assez foireuse aussi).
                                  • [^] # Re: Grandiose

                                    Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                    c'est pas parce que ça s'adresse à des développeurs que tu dois faire tout en dépit du bon sens. Genre le menu en clic droit qui est "presque" le même que le menu dans la barre d'outils. Manque de bol, y'a une ou deux fonctions qui sont pas les mêmes.

                                    Eclipse n'a tout simplement pas d'interface : c'est juste plein de fonctions (très puissantes et utiles, je l'admet) auxquelles on a assigné des bouttons et puis on a lancé ces bouttons au hasard dans une grosse fenêtre. Lotus Notes est comme ça, Open Office est dans le même genre. C'est la philosophie de GUI des années 90 quoi.

                                    Mes livres CC By-SA : https://ploum.net/livres.html

                                    • [^] # Re: Grandiose

                                      Posté par  . Évalué à 3.


                                      Genre le menu en clic droit qui est "presque" le même que le menu dans la barre d'outils.

                                      Tu préférerais des menus ou la moitié des fonctionnalités sont présentes et l'autre dans la barre comme ca on est obligé de rechercher dans les 2 à chaque fois.

                                      Pour ma part je constate que le menu contextuel porte bien son nom i.e qu'il est spécialisé en ft de l'objet qui est en dessous. Alors que la barre de tâche donne accès à des ft généralistes.

                                      Ta critique adresse en fait l'architecture en plugin qui permet à chacun d'apporter sa pierre à l'édifice.
                                      Forcément ca manque parfois d'homogénité, car les contributeur ne respecte pas tjs les mêmes règles et ne peuvent pas tjs anticiper toutes le extensions qui seront installéés par un utilisateur.

                                      D'aileurs je crois me souvenir que tu adresses la même critique à Firefox qui suit la même philosophie.

                                      Les offres plus contraintes ou moins populaires sont peut être plus homogène mais moins souple (ex: Chrome)

                                      Tout est affaire de compromis entre souplesse et cohérence.
                                      L'approche par plugin au moins facilite la diversité.
                                    • [^] # Re: Grandiose

                                      Posté par  . Évalué à 2.

                                      Ben le clic droit ouvre un menu contextuel, donc meme si tu retrouves des elements qui sont dans un menu, ils changent en fonction de ce sur quoi tu as clique, c'est tres precisement le concept du menu contextuel, ne pas avoir a aller chercher dans le menu plus haut.
                          • [^] # Re: Grandiose

                            Posté par  (site web personnel, Mastodon) . Évalué à 1.

                            Celui qui met le plus de temps, c'est celui qui a deux commandes à taper. Ce n'est que ce que je dis depuis le début. Bien sûr que Python compile de la même manière qu'une voiture automatique change de vitesse : je m'en fous, il fait juste ce que je veux.

                            Mes livres CC By-SA : https://ploum.net/livres.html

                            • [^] # Re: Grandiose

                              Posté par  . Évalué à 1.

                              Sauf qu'à aucun moment je ne t'ai parlé de "taper deux commandes" justement, je sais pas d'où tu les sors celles-là ?!

                              Compiler permet de détecter tes erreurs en amont tout en accélérant ton code pour quand tu vas le lancer plus tard. Tout ceci est fait pendant (j'insiste) que tu tapes ton code automatiquement, donc pendant que ton CPU est en attente.

                              Moi je vois les choses comme ça :
                              - tu détectes tes erreurs avant de lancer ton programme donc tu gagnes du temps sur leurs corrections.
                              - Tu à un code (pseudo-)compilé donc tu gagnes (un peu) de temps sur l'exécution du programme/des tests unitaires.
                  • [^] # Re: Grandiose

                    Posté par  . Évalué à 2.


                    Le bytecode est en partie interprété, en partie Traduit en code natif "à la volée" (JIT).


                    C'est quoi ce code natif ? De l'assembleur ? (Vrai question)
                    • [^] # Re: Grandiose

                      Posté par  . Évalué à 10.

                      La page wikipedia sur le JIT est assez bien faite http://en.wikipedia.org/wiki/Just-in-time_compilation . La pagee dédiée à Java résume aussi assez bien les gros principes d'hotspot:
                      http://en.wikipedia.org/wiki/Java_performance#Just-In-Time_c(...)

                      Voici un résumé très grossier:

                      On part sur un mode d'exécution interprété. On exécute le bytecode dans la JVM, à chaque instruction correspond une translation sur la machine cible. Quand une instruction à été exécutée on passe à la suivante.

                      Si Hotspot détecte que ça en vaut le coup, alors on produit du langage machine qui correspond, à peu près, au bytecode (si ca répond à ta question ce qu'on appel assembleur ce sont des symbole mnémoniques qui seront ensuite traduit en langage machine, une suite de bits). On se passera donc de l'étape de translation pour les prochaines exécutions. On peut faire des optims assez malines grâce au fait que l'on a accès à beaucoup d'informations: stats des exécutions précédentes, proco cible etc. Dans Hotspot il y a deux compilateurs qui sont plus ou moins agressifs.
                      Je disais à peu près car Hotspot est capable de faire de la désoptimisation. C'est à dire qu'il se permet de générer des optimisations non sûres reposant sur des hypothèses qui peuvent devenir fausses. Si il se rend compte à l'exécution que les hypothèses qu'il avait fait deviennent erronées, alors il remplace la frame optimisée par une autre moins optimisée et c'est reparti. Il se passe la même chose si entre la première moitié et la seconde de programme les prédiction de branches changent du tout au tout.

                      La JVM est vraiment une merveille d'optimisations (qu'on aime ou pas ce qui se trouve dessus). Les travaux sur le locking , les optimisations du compilateur, ou le garbage collector sont assez impressionnants. Voir: http://java.sun.com/products/hotspot/whitepaper.html
                      et http://java.sun.com/javase/technologies/hotspot/publications(...)
                      • [^] # Re: Grandiose

                        Posté par  . Évalué à 2.

                        tu es beau :)

                        Merci beaucoup pour cette reponse ! Je ne regarderais plus jamais ma JVM comme avant ! :)
                    • [^] # Re: Grandiose

                      Posté par  (site web personnel) . Évalué à 3.

                      du code machine exécutable.
                  • [^] # Re: Grandiose

                    Posté par  . Évalué à 2.

                    Le langage Java est compilé en bytecode.
                    Le bytecode est en partie interprété, en partie Traduit en code natif "à la volée" (JIT).

                    Python aussi est compilé en bytecode, et le bytecode est interprété. OK, il ne fait pas encore de JIT à part en utilisant PyPy, ce qui est plutôt expérimental.
            • [^] # Re: Grandiose

              Posté par  (site web personnel) . Évalué à 1.

              Ça c'est facile quand même. Si les modules sont pas dispos en package pour la distrib de ton utilisateur? L'utilisateur va se faire l'install à la main. Adieu simplicité.
              Si t'as un module natif (pour un besoin quelconque), tu vas devoir avoir une version pour chaque archi, et pour chaque OS. Ou alors c'est l'utilisateur qui se tape la compil, avec les dépendances qui vont avec, ah ah. Autre problème.
              À une époque pas si lointaine, il fallait Visual C++ pour compiler des modules pour Windows. Sauf si t'avais envie de te faire ta propre version de Python non-officielle avec GCC/MingWin.

              Je vais proposer une parodie de ta solution: je fourni une image de VM pour mes programmes. Plus de dépendance de module. Plus de problème d'OS. Tout est réglé. Faite comme moi.
              • [^] # Re: Grandiose

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                "Ça c'est facile quand même. Si les modules sont pas dispos en package pour la distrib de ton utilisateur? "

                C'est un bug de la distrib et ça se corrige. Mais c'est rarement le cas (et même très rarement) et, au moins, ce n'est pas le cas par défaut. Dans la toute grande majorité des cas, c'est ultra facile.

                Et tu sais quoi ? Ta solution de VM est à présent utilisée par de nombreux logiciels qui se contentent de fournir une image Vmware d'un système configuré. (et à part ça, je vois pas le rapport avec ma solution à moi)

                Mes livres CC By-SA : https://ploum.net/livres.html

            • [^] # Re: Grandiose

              Posté par  . Évalué à 8.

              > apt-get install
              C'est pas un peu simplifié comme gestion de multiplateformes ?

              > Tu lances "python main.py"
              Tu rejettes distutils, soit, mais tu prends l'exemple de django (que je n'ai jamais vraiment utilisé, mais je vais m'inspirer de leur tuto) qui te génère X fichiers dès le début de ton projet. Puis dès que tu vas cumuler avec un autre outil ou 2, ça va vite reprendre l'allure d'usine à gaz que tu reproches à Java.
              • [^] # Re: Grandiose

                Posté par  (site web personnel) . Évalué à 3.

                X = 5
                Un fichier settings.py, un fichier manage.py pour les commandes shell, un fichier url.py pour le root url conf. Auquel tu rajoute 2 fichiers mini par application (view.py et models.py) C'est tout.

                5 fichiers au strict minimum pour faire tourner une instance Django qui permet déjà un paquet de choses.

                Si tu veux des tests, des templates, des fichiers statiques, des middlewares, des fixtures, tu peux en rajouter mais tu n'est nullement obligé de le faire.

                Je ne poursuivrai pas le débat car je connais trés mal distutils.
            • [^] # Re: Grandiose

              Posté par  . Évalué à 7.


              Les gars, faut ouvrir un peu les yeux : quand tu dois commencer à utiliser des outils pour pouvoir utiliser tes outils, c'est un peu angoissant. La palme revient quand même à Gcc. Comme c'était compliqué de compiler, on a fait make. Comme faire un makefile, c'est conpliqué, on a fait configure. Comme configure c'était compliqué, on a fait autogen. C'est incroyable. Et Java fonce droit dans la même veine.


              Ouais. Complètement d'accord. D'ailleurs, l'informatique en général c'est ça. À la base il y a le boulier, mais comme c'est trop compliqué, on fait un ordinateur. Mais comme compter en binaire c'est trop compliqué, on fait des langages de programmation. Vraiment n'importe quoi, cette démarche.
              • [^] # Re: Grandiose

                Posté par  (site web personnel, Mastodon) . Évalué à 1.

                Ta comparaison est complètement foireuse. Le programmeur, il ne connait que le langage de programmation. Il n'a pas besoin de savoir comment c'est implémenté. Tu peux être un excellent programmeur et ne pas savoir ce qu'est un transistor.

                Par contre il doit connaitre, en plus du langage de programmation des tas d'outils pour faire fonctionner son langage de programmation et encore d'autres outils pour faire fonctionner les outils.

                Se compliquer la vie pour tenter de la simplifier, c'est voué à l'échec sur le long terme, faut pas chercher très loin pour s'en rendre compte. 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), n'importe qui avec un peu de recul dirait "mais c'est quoi ce délire ?". Mais bon, le nez dans le guidon est le lot de90% des gens. Y'a peu de gens qui se posent la question "mais au fond, c'est quoi le résultat qu'on aimerait avoir ?". Le problème de la vie c'est que poser cette question, c'est remettre en question le travail, les acquis, la souffrance endurée les années précédentes. Alors, on préfère se convaincre que la question ne doit pas être posée.

                Autolink : http://ploum.frimouvy.org/?197-le-conte-du-mousse-et-des-vin(...)

                Mes livres CC By-SA : https://ploum.net/livres.html

                • [^] # Re: Grandiose

                  Posté par  (site web personnel) . Évalué à 2.

                  . 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.
            • [^] # Re: Grandiose

              Posté par  . Évalué à 5.

              Ce que j'adore c'est que tu compares des choux et des chèvres.

              Avec Python tu as Django effectivement mais tu as aussi CherryPy, Pylons, TurboGears, Zope et j'en passe et des meilleurs.
              En fait, tu as un standard / une spec qu'on appelle WSGI pour remettre de l'ordre dans tout ca et sur laquelle tous tes framework se basent ou le devraient, spec qui ressemble étrangement à une certaine API servlet et frameworks qui rappellent bien l'offre coté Java.

              Et pour chacun d'eux lorsque tu ne prend pas la solution de base parce qu'elle se révele insuffisante en dehors du prototypage, que tu veux pouvoir choisir ton moteur de templating, ta base de donnée, ton ORM, tu dois te palucher des fichiers et des scipts de config à tire larigot l'homogénéité du standard XML en tant que fichier de conf en moins.
              Tout pareil dis donc.
              Pis avec le serveur web embarqué ca tient pas la route, il faut te coltiner l'interface avec un Apache / mod_python.
              Mais là t'es chez toi en bon linuxien et admin tu maitrises tout ca en 3 ligne de commande et 2 fichiers. Ca tombe bien les javaiste aussi sont dans leur elt.
              Pis après les libs standard pyhton sont pas suffisantes et tu veux récupérer tes proprs libs pour gérer le log ou encore te connecter à un annuaire LDAP ..

              Et là fini les joies du "convention over configuration".
              Avec Java c'est pareil . Tu peux faire mumuse avec un Tomcat et un framework unique et crâner en disant ca se fait en 3 clics
              Reste que jusqu'il y a peu ( la phenomène RoR) on avait plus de fichier à configurer à la mimine et que le XML s'est imposé come standard avant cette apparition.

              Tous tes frameworks python (hormis Zope que tu critiques pour sa lourdeur) sont issus de la même veine basée sur les conventions.

              Rassures toi avec Java tu peux le faire aussi, quasiment tous les frameworks ont evolué en ce sens et d'autres sont né sur cette idée
              comme par exemple Play qui est passé par ici
              http://linuxfr.org/2008/09/04/24453.html
              mais il doit en exister d'autres.

              Bref ce que tu nous décris ce sont des pbs de choix de solutions d'architecture, de choix qui sont de plus en plus ardus à mesure qu'un ecosytème et son offre de composants s'enrichissent.
              Python n'y échappe pas.
              Reste le troll langage statique vs dynamique.
              Ca tombe bien tu peux aussi utiliser ton langage dynamique préféré J2EE et ses librairies et frameworks comme JRuby On Rails qui est réputé plus robuste que son grand frère natifs, ou encore Grails et même Jython (avec ses wagons de release de retards) est présent.

              A toi de choisir le mieux ou bien de rester avec ton Django, ses limites et qui à ce que je sache n'est toujours pas foutu de proposer un projet de forge convenable.
              Mais tu as raison Django et ses 1928 sites à haute disponibilité témoignent pour lui
              http://www.djangosites.org/

              Bonne année à tous , elle démarre sur les chapeaux de roue.

              Bozo pasJ2EEpasLeadArchitect
              • [^] # Re: Grandiose

                Posté par  (site web personnel) . Évalué à 2.

                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...
                • [^] # Re: Grandiose

                  Posté par  . Évalué à 5.

                  Où est-ce que tu as vu que Ruby est au point mort ? Et Rails ? Et Python ?

                  La seule chose qui freine pour Ruby, Python et leurs frameworks, 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. Et elles sont encore plus frileuses sur l'open-source parce qu'elles n'ont pas la "garantie" de fiabilité qu'offre un système vendu par une société commerciale, sur la base du "si ils le vendent ils vont écouter leurs clients / faire un bon produit / le maintenir / le faire évoluer". 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".
                  • [^] # Re: Grandiose

                    Posté par  (site web personnel) . Évalué à 2.

                    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 ?
                    • [^] # Re: Grandiose

                      Posté par  (site web personnel, Mastodon) . Évalué à 3.

                      Vu le nombre d'offres d'emploi que je vois pour des dev django dans les sites spécialisés, je me dit que ça commence à devenir sérieux. Je connais même des spécialistes J2EE qui se sont retrouvé à apprendre Django pour des missions de quelques mois. Le marché évolue, c'est comme tout le reste.

                      Personnellement, j'ai un gros problème avec Java (alors que c'est avec Java que j'ai commencé l'informatique, que j'ai failli abandonné le domaine jusqu'au jour où j'ai découvert le C). Et j'aime troller. Du coup, on comprend mieux mes messages ;-)

                      Mais plus sérieusement : J2EE est bien (waw, ça me fait mal de le dire). C'est la solution actuelle. Mais J2EE est devenu trop complexe, trop gros. Le futur est à des outils plus légers dont, je pense, font partie Django et Python. Et eux-même seront remplacés par autre chose dans quelques années, c'est l'évolution qui veux ça. Et selon que l'on soit conservateur, que l'on soit confronté à des problèmes présents, urgents et concrets ou que l'on soit idéaliste, rêveur et un peu visionnaire, on soutiendra Cobol, J2EE ou Python. Et dans quelques années, on rechangera...

                      Mes livres CC By-SA : https://ploum.net/livres.html

                      • [^] # Re: Grandiose

                        Posté par  (site web personnel) . Évalué à 3.

                        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...
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 6.

                          Il faut aussi avouer que Python n'a pas eu le même soutien que Java, ni la même publicité au départ ...
                    • [^] # Re: Grandiose

                      Posté par  . Évalué à 3.

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

                        Posté par  (site web personnel) . Évalué à 3.

                        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.
                        • [^] # Re: Grandiose

                          Posté par  (site web personnel, Mastodon) . Évalué à 2.

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

                          Un truc qui me fait peur avec les "experts J2EE", c'est qu'ils m'ont tous toujours tenu le même discours concernant la lisibilité du code :

                          - Les commentaires sont inutiles, un bon code parle de lui-même.
                          - Il faut écrire le moins de lignes possibles : pas d'espaces entre les classes, pas de commentaires "inutiles"
                          - Les commentaires nuisent à la lisibilité du code (sic).


                          Bon, ce n'est évidemment pas lié au langage mais je trouve significatif que tous les chefs de projets J2EE (et certains C++) m'aie sorti, à peu de choses près, ce genre de choses. Et généralement ces règles sont même écrites sur la page Coding Rules du wiki !

                          J'ai pour habitude, lorsque j'ai pris du temps à comprendre un bout de code, de mettre un commentaire expliquant ce que j'ai compris (histoire de pas devoir refaire le boulot). Durant ma brêve carrière J2EE, ces commentaires étaient systématiquement effacés par les commit après moi.


                          Mais je reconnais 100% que ce n'est pas techniquement lié au langage. Je pense que cela fait plus partie d'une culturee très présente dans le milieu J2EE.

                          Mes livres CC By-SA : https://ploum.net/livres.html

                          • [^] # Re: Grandiose

                            Posté par  (site web personnel) . Évalué à 3.

                            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.
                            • [^] # Re: Grandiose

                              Posté par  (site web personnel, Mastodon) . Évalué à 2.

                              oui mais, par définition, tout code que tu écris te parle sur le moment. Mais pas 2 mois plus tard.

                              Personnellement, je suis en train de tester une nouvelle approche : plutôt que de commenter ce que je fais, je commente pourquoi je le fais. On verra à la longue.

                              Mes livres CC By-SA : https://ploum.net/livres.html

                              • [^] # Re: Grandiose

                                Posté par  (site web personnel) . Évalué à 1.

                                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.
                              • [^] # Re: Grandiose

                                Posté par  . Évalué à 4.

                                Tu as essayé le « litterate programming » de Knuth ? :)
                            • [^] # Re: Grandiose

                              Posté par  . Évalué à 2.

                              Ceci dit, la difficulté à maintenir des commentaires nait de la redondance du code, et Java incite à la redondance du code. Exemple :
                              > en Java :
                              class Machin {
                              /**
                              ...
                              */
                              public String truc() {
                              ...
                              }

                              /**
                              ...
                              */
                              public String truc(String blah) {
                              ...
                              }

                              /**
                              ...
                              */
                              public String truc(String blah, int zorg) {
                              ...
                              }

                              /**
                              ...
                              */
                              public String truc(String blah, int zorg, boolean asif) {
                              ...
                              }
                              }

                              > en Ruby :
                              class Machin
                              =begin
                              ...
                              =end
                              def truc(*args)
                              ...
                              end
                              end

                              Rien que sur ce détail (il y en a d'autres) on est "obligé" si l'on veut bien commenter de se taper plusieurs blocs de commentaires là où un suffirait largement.

                              Pour inciter un codeur à accompagner son travail de commentaire, il faut qu'il ne se sente pas comme un bon Sisyphe à pousser un rocher qui de toute façon retombe dès que le sommet de la colline est atteint. S'il a l'impression que son travail est inutile, soit parce qu'il pense que son code est déjà limpide, soit parce qu'il voit que de toute façon une fois le code à peine modifié il faut faire trois fois autant de modifications de commentaires, le codeur il n'a pas très envie de commenter.

                              Oh, je suis sûr qu'il y a des moyens de "gruger" avec Java et de mettre en place du commentaire propre et non redondant, mais je n'ai pas passé beaucoup de temps sur cette plate-forme (ce qui me dérangeait plus que la redondance de commentaires c'est le redondance de code).
                              • [^] # Re: Grandiose

                                Posté par  . Évalué à 2.

                                Tu vois pas comme des légères différences entre les 2 ? Tu vois pas que d'un côté tes paramètres sont nommés et pas de l'autre ? Tu vois pas que d'un côté les types sont spécifiés et pas de l'autre ?
                                • [^] # Re: Grandiose

                                  Posté par  . Évalué à 3.

                                  Nommer, répertorier, expliquer les paramètres possibles, je préfère le mettre dans les commentaires, comme de toute façon chaque paramètre doit s'expliquer dans les commentaires ça évite d'écrire deux fois les choses. Et je n'arrive plus à voir l'intérêt de spécifier les types en Ruby, où on préfère la philosophie du "duck typing" (si ça se comporte comme un canard et que j'ai besoin d'un truc qui se comporte comme un canard, pas besoin de lui faire faire un test adn).

                                  Par exemple, en Java, si une méthode à besoin de travailler sur un objet qui implémente une interface IJeSaisFaireQuelqueChose pour utiliser sa méthode abstraite faireQuelqueChose, alors je vais devoir implémenter l'interface pour chaque objet passé en paramètre, voir dans certains cas faire des héritages de classes définies dans des bibliothèques externes pour pouvoir leur coller juste une bête interface.

                                  En Ruby, si une méthode à besoin d'un objets qui réponde à la méthode faire_quelque_chose(), il suffit que mon objet répondre à cette méthode et ça roule. Si vraiment je veux faire mon paranoïaque je peux tester si l'objet répond à la méthode à la réception de l'argument et lancer une exception si ce n'est pas le cas. Ca permet de découpler beaucoup mieux les classes.

                                  Encore mieux, si j'ai une instance d'objet à passer à ma méthode, et qu'il n'a pas la méthode faire_quelque_chose(), je peux faire un module contenant une implémentation de faire_quelque_chose() et le coller à la volée à l'instance (ou à la classe) avant de le donner à manger à la méthode en question, ce qui simplifie énormément le développement orienté comportement.

                                  On y gagne en lisibilité (code plus concis, moins de méthodes vides juste pour implémenter des interfaces, moins de méthodes qui se contentent d'en appeller une autre du même nom pour faire varier le nombre de paramètres, moins de sous-classes définies uniquement pour donner un nouveau comportement à du code existant), en temps (pour écrire des commentaires, des tests), et en réutilisabilité (pas besoin de se taper des diagrammes d'héritages ou des API de 1000+ pages pour réutiliser des libraries bien claires et bien commentées, le code est plus facile à découpler et facotriser).

                                  Je sais que ça fait peur, on a l'impression qu'il n'y a plus de structure, que les autres développeurs (qui sont forcément nuls, fainéants, etc.) ne sont plus obligés de suivre strictement des lignes de conduite rigides et indépassables et vont faire de la merde, forcément, mais franchement, même avec Java un développeur qui fait de la merde peut vraiment faire des trucs bien puants, bien crados. Ce n'est pas la flexibilité du langague qui fait que l'on pond de la merde ou pas, c'est la méconnaissance des bonnes pratiques et la paresse.
                                  • [^] # Re: Grandiose

                                    Posté par  . Évalué à 1.

                                    > [blabla]
                                    La justification de l'imposition des types est débattue plus haut dans le thread.
                              • [^] # Re: Grandiose

                                Posté par  . Évalué à 1.

                                et la un developpeur appelle truc(blah, zorg, asif, paramEnTrop) .
                                et tu vas passer 2 jours en debug a comprendre ce qu'il se passe.

                                c'est pas equivalent. La seconde notion est certainement utile, mais elle n'est clairement pas du tout equivalente.
                                Un truc qui s'en rapprochera sera plutot un public void truc(Object[] obj);

                                Et si je vois un truc comme ca un jour dans du Java, c'est une balle dans la nuque sur la place publique pour le cochon qui l'a ecrit.
                                • [^] # Re: Grandiose

                                  Posté par  . Évalué à 0.

                                  Completement

                                  A la rigueur je préfère la méthode c++ avec des valeurs par défaut aux paramètres
                                • [^] # Re: Grandiose

                                  Posté par  . Évalué à 4.

                                  Ben non, pourquoi ? Quand une exception se produit en Ruby, on a aussi une stack trace, c'est pas une spécificité du Java (je sais que ça peut surprendre, mais déjà en PHP ça existait, si si).

                                  Et non, effectivement, les deux ne sont pas équivalente. On peut utiliser les deux notations pour produire des résultats identiques, mais si elles étaient équivalentent je n'aurais pas pris de temps ici pour pointer leur différence.

                                  Sinon, oui on peut émuler le duck-typing en Java avec un tableau d'objets ou un hash (c'est d'ailleurs ce que tôt ou tard on finit par faire quand on en a assez de devoir faire évoluer X méthodes quand on change juste une petite chose dans l'un des paramètres fondementaux), mais c'est tellement plus simple d'utiliser un langage fait pour ça, d'autant plus que les types natifs de Java rendent souvent l'opération pénible.

                                  Oh, je n'aime pas beaucoup répondre "ligne par ligne" parce que souvent les citations sorties du contexte sont mal interprétées, mais celle-là est trop belle :
                                  Et si je vois un truc comme ca un jour dans du Java, c'est une balle dans la nuque sur la place publique pour le cochon qui l'a ecrit.
                                  Ben oui, c'est bien là le problème. En Java, on dit ne pas aimer la répétition, mais prône la verbosité. Ruby prétends que la verbosité est contre-productive, et qu'elle n'est rien d'autre qu'une autre forme de répétition de structure. Par exemple, si en Java je veux qu'une méthode fonctionnant de la même façon soit donnée à plusieurs classes existantes n'ayant pas d'ancêtre commun modifiable, ça va m'obliger à :

                                  - créer une interface
                                  - créer des sous-classes de chaque objet
                                  - créer un objet qui contienne ma méthode
                                  - créer dans mes sous-classes un conteneur pour mon nouvel objet
                                  - créer une instance du nouvel objet dans le constructeur de chaque sous-classes
                                  - créer dans chaque sous-classes une méthode paravent pour appeller celle qui m'intéresse du nouvel objet

                                  Beurk

                                  En Ruby :
                                  - créer un module contenant ce qu'il faut pour que ma méthode marche
                                  - implémenter ma méthode (à la volée dans un instance ou dans la classe, ou dans la déclaration de ma classe si c'est moi qui la crée) pour chaque classe

                                  Hop
                                  • [^] # Re: Grandiose

                                    Posté par  . Évalué à 2.

                                    erratum :
                                    - intégrer mon module (à la volée dans un instance ou dans la classe, ou dans la déclaration de ma classe si c'est moi qui la crée) pour chaque classe
                          • [^] # Re: Grandiose

                            Posté par  . Évalué à 2.

                            pas de commentaires "inutiles"
                            Mouais, je connais pas grand monde qui pense que les commentaires inutiles sont utiles. Au mieux, ils pourraient être pertinent.

                            Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                          • [^] # Re: Grandiose

                            Posté par  . Évalué à 3.

                            Rassure-moi, quand même : le commit ne supprimait pas les commentaires Javadoc (avant une classe/méthode) ???
                            Parce qu'autant, on peut discuter longtemps de l'utilité (ou non) de commentaires au sein d'une méthode, autant je doute que quiconque remette en question les commentaires Javadoc précédant ladite méthode...
                          • [^] # Re: Grandiose

                            Posté par  . Évalué à 2.

                            C'est avant tout une question de culture je pense, j'ai passé un an dans une SSII à faire du Java et j'ai abdondamment commencé, et l'expert Java de la boîte m'a toujours soutenu et pris en modèle pour ça. Je n'ai d'ailleurs jamais rencontré dans ma carrière (beaucoup de PHP, un peu de Java, pas mal de JavaScript et technos diverses associées au web) de gens qui prônaient le non-commentaire. Tout au plus j'ai rencontré (en grand nombre) des développeurs qui en parlaient beaucoup et n'en faisait pas trop, mais je crois que le consensus est plutôt à commenter son code.

                            Par contre, c'est toujours mieux de faire un code court et lisible qu'un code long et incompréhensible, à commentaire égal.
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 3.

                          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.
                          • [^] # Re: Grandiose

                            Posté par  (site web personnel) . Évalué à 2.

                            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...
                            • [^] # Re: Grandiose

                              Posté par  . É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  (site web personnel) . Évalué à 2.

                                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  . Évalué à 2.

                                  "le GIL c'est pas un problème, le multi-threading ca sert à rien"
                                  Tu sors ca d'où ?
                                  Les threads existent en python aussi.
                                  http://docs.python.org/library/threading.html

                                  Qu'est-ce qu le le GIL ?
                                  • [^] # Re: Grandiose

                                    Posté par  (site web personnel) . Évalué à 2.

                                    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
                                    • [^] # Re: Grandiose

                                      Posté par  . Évalué à 1.

                                      Merci, mais c'est un faux pb, ca ne tient pas au langage mais à l'implémentation de l'interprète qui supporte le langage.
                                      Il existe des implémentations qui n'utilisent pas le GIL.
                                      Merci à Timaniac de nous l'avoir pointé :)
                                      http://linuxfr.org/comments/969578.html#969578
                                      • [^] # Re: Grandiose

                                        Posté par  (site web personnel) . Évalué à 2.

                                        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 :)
                                        • [^] # Re: Grandiose

                                          Posté par  (site web personnel) . Évalué à 2.

                                          Et puis on peut dire adieu à toutes les libs natives développées pour CPython
                                          • [^] # Re: Grandiose

                                            Posté par  . Évalué à 2.

                                            Rien que ça c'est un aveu d'impuissance.
                                            Python ne peut être un langage généraliste qui offre une plateforme complète puisqu'il s'appuie sur le C pour pallier ses défauts et rest un langage de glue.

                                            Au fait c'est quoi la lib graphique native python.
                                            Tkinter , non c'est du Tk et ca s'inspire de la philosophie Tcl.
                                            wxWindows ? C++
                                            Qt ? C++
                                            Gtk ? C
                                            Fox ? c++
                                            Swt ? Java
                                            Swing ? Java

                                            C'est sûr que si on abandonne le GIL ca va faire mal, il doit bien y avoir des bouts de not thread-safe.

                                            Guido a beau esquiver en invoquant le web et le fait qu'une architecture evolutive doit permettre de fonctionner sur plusieurs noeuds, et que les threads servent à rien, il y a tout le reste: les applis natives qui elles peuvent tirer avantage du multi-coeur.
                                            Sans oublier les clients riches.

                                            Merci Timaniac de m'avoir ouvert les yeux.
                                            Ca me conforte dans le choix d'un langage dynamique au dessus de la JVM qui ne réinvente pas la roue: Groovy.
                                            Je vais suivre Grails de plus en plus près
                                        • [^] # Re: Grandiose

                                          Posté par  . Évalué à 2.

                                          Pour les synchros et les mutex, pas besoin de multiprocesseur à priori.

                                          Sauf si c'est pas le cas avec l'implémentation python :
                                          * tu peux pas supposer grand chose sur l'ordre et le temps d'exécution de tes deux trheads, et l'un d'eux peut être interrompu en plein milieu d'une écriture disque. Si l'autre thread a besoin du même fichier, faut un mécanisme pour être sur qu'ils y accèdent pas tout les deux "en même temps".

                                          * Pour la synchro, pareil, tu peux lancer un calcul dans un thread, laisser l'autre faire ce qu'il veut, et à un moment attendre la fin du calcul par exemple.
                                    • [^] # Re: Grandiose

                                      Posté par  . Évalué à 4.

                                      Pour resituer le contexte voici la réponse de Guido à propos du GIL avec la venue de python 3000


                                      Q. Multi-core processors will be standard even on laptops in the near future. Is Python 3.0 going to get rid of the GIL (Global Interpreter Lock) in order to be able to benefit from this feature?

                                      A. No. We're not changing the CPython implementation much. Getting rid of the GIL would be a massive rewrite of the interpreter because all the internal data structures (and the reference counting operations) would have to be made thread-safe. This was tried once before (in the late '90s by Greg Stein) and the resulting interpreter ran twice as slow. If you have multiple CPUs and you want to use them all, fork off as many processes as you have CPUs. (You write your web application to be easily scalable, don't you? So if you can run several copies on different boxes it should be trivial to run several copies on the same box as well.) If you really want "true" multi-threading for Python, use Jython or IronPython; the JVM and the CLR do support multi-CPU threads. Of course, be prepared for deadlocks, live-locks, race conditions, and all the other nuisances that come with multi-threaded code.

                                      http://www.artima.com/forums/threaded.jsp?forum=106&thre(...)
                                      • [^] # Re: Grandiose

                                        Posté par  (site web personnel) . Évalué à 2.

                                        J'adore : dire qu'il va y avoir des deadlocks pour argumenter sur le fait que Python n'est pas réellement multithread, c'est fort. "Dis-moi ce dont tu as besoin, je te dirais comment t'en passer".

                                        Plus on parle de Python, et moins je comprend la "mode" Python : il y a des limitations relativement contraignantes, et la seule façon de passer outre est de... Changer de langage (Si j'ai bien compris, Jython ou IronPython ne sont pas 100% compatible avec Python, c'est ça?)
                                        • [^] # Re: Grandiose

                                          Posté par  . Évalué à 1.

                                          C'est un choix, qu'on fait la plupart des langages de scripts pour garder la possibilité d'avoir des bindings C, sans pour autant se casser la tête à savoir ce qui est thread safe ou pas. Au final on peut tout de même utiliser le multicore à "l'ancienne" à coup de forks.
                                          On critique la lourdeur de java, la question est de savoir si forker n fois une vm n'est au final pas plus consommateur de ressources (ptet pas pour 2 cores... mais bon quand on voit qu'intel à préparer un proto à 80 cores...)

                                          Changer de langage (Si j'ai bien compris, Jython ou IronPython ne sont pas 100% compatible avec Python, c'est ça?)

                                          jconnais pas python, mais si jai tout compris, si le langage reste le même, c'est tout ce qui a autour qui change (bindings C d'un coté, java ou .net de l'autre). Etant donné la variété de libs java qui éxiste, je ne pense pas que ça soit un gros problème. En fait AMHA la question est de savoir si les frameworks python (django, zope et cie) sont compatibles.
                                        • [^] # Re: Grandiose

                                          Posté par  (site web personnel, Mastodon) . Évalué à 1.

                                          le débat sur les multicores me fait rigoler vu que la majorité des programmes C, C++ ou Java n'exploitent pas non plus le multicore.

                                          Perso, je vois le multicore comme une opportunité de faire tourner des processus différents, pas de gagner en perf sur mon programme monoprocessus. D'ailleurs, si les perfs sont si importantes pour ton programme, tu ne l'écris pas en Java ou en Python.

                                          Je trouve donc que la discussion n'a pas beaucoup de sens et qu'avant d'optimiser un programme pour qu'il utilise le multi-core, il faut d'abord avoir le programme complètement fonctionnel et optimisé au poil sous tous les autres aspects.

                                          Mes livres CC By-SA : https://ploum.net/livres.html

                                          • [^] # Re: Grandiose

                                            Posté par  . Évalué à 7.

                                            « le débat sur les multicores me fait rigoler vu que la majorité des programmes C, C++ ou Java n'exploitent pas non plus le multicore. »

                                            Tout dépend le type de code. En Java, pour du code qui utilise du calcul intensif par exemple, avec beaucoup d'irrégularité mémoire (pointer chasing), on a des programmes aussi rapides qu'en C++ (à condition de faire du « vrai » C++, et pas du « C avec namespaces et templates » -- dans ce dernier cas, C gagne, mais pas forcément de beaucoup).

                                            En Python, puisqu'on peut embarquer relativement simplement des fonctions C externes, il est dommage de ne pas avoir de « vrai » modèle de threads.

                                            Dernière chose : l'argument du « de toute manière les codes actuels n'exploitent pas le multicore », bien qu'énonçant un fait véridique, n'est pas solide : jusqu'à il y a peu, l'intérêt d'utiliser du multiprocesseur en dehors de programmes serveur ou de certains programmes types (comme Photoshop/Gimp par ex) n'avait pas vraiment de sens. Maintenant qu'on est coincé à la même fréquence mais avec plus d'unités de calcul, il va falloir réapprendre à programmer pour inclure l'option parallèle. Parce que plusieurs coeurs c'est bien, mais s'ils doivent se partager non seulement la mémoire cache (4 Mo pour 2 coeurs c'est très bien, 4 Mo pour 4 ça devient pas très grand), mais aussi - et surtout - le bus mémoire, tes processus parallèles, pour peu qu'ils soient limités par l'accès à la bande passante mémoire, risquent de faire la gueule. Je ne parle même pas de la concurrence pour accéder à une carte réseau, ou un disque dur, etc. Le problème existait déjà avant, mais avec la présence de plusieurs coeurs, il s'amplifie.

                                            En fait le multicore amène dans le grand public (et donc plus précisément aux programmeurs qui programment « pour » ledit grand public) des problématiques qui auparavant étaient réservées au domaine du calcul scientifique. Dans l'absolu, je préférerais de loin que tout soit programmé séquentiellement, car on s'enlève tout un tas de bugs potentiels, mais le fait est que je vois difficilement comment on peut se passer de paralléliser certains bouts de codes. Par exemple, un certain nombre de programmes qui permettent de faire du calcul scientifique sont faits en Python, avec derrière des bibliothèques mathématiques programmées en C. Bon, très bien. C'est juste dommage de ne pas pouvoir paralléliser les calculs quand ont sait qu'on a un système multicore. Idem pour tout ce qui est encodage, filtre pour images, etc.
                                            • [^] # Re: Grandiose

                                              Posté par  (site web personnel, Mastodon) . Évalué à 2.

                                              Effectivement. C'est un cas assez limite mais tout à fait valable auquel je n'avais pas pensé.

                                              Mes livres CC By-SA : https://ploum.net/livres.html

                                    • [^] # Re: Grandiose

                                      Posté par  . Évalué à 2.

                                      Ici
                                      http://www.infoq.com/news/2007/05/ruby-threading-futures

                                      Tu trouveras un point de vue intéressant et approfondi sur cette problématique du GIL pour ruby. Y est abordé la solution d'Erlang et de ses "lighweight processes" et de l'approche m:n qui résoud le cas des multi procs.
                                      A comparer avec Stackless Python
                                      • [^] # Re: Grandiose

                                        Posté par  (site web personnel) . Évalué à 2.

                                        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).
                                        • [^] # Re: Grandiose

                                          Posté par  . Évalué à 2.

                                          Sauf que tu ne réponds pas sur Erlang et l'approche m:n.
                                          des threads natifs qui embarquent chacun leur propre ordonnanceur , c'est peut-être la voie à suivre.

                                          Sinon, sous OS/2 je bossais avec de la mémoire partagée en C et je regrette cette époque.
                                          • [^] # Re: Grandiose

                                            Posté par  (site web personnel) . Évalué à 2.

                                            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é.
                                        • [^] # Re: Grandiose

                                          Posté par  . Évalué à 2.

                                          enfin ca indique surtout que l'approche des threads n'est pas la seule pour exploiter les machines multi-coeurs/processeurs.
                                          Les threads pratiques ? évidemment, mais ils apportent leur lots de galères
                                          Les forks plus surs ? surement, mais ça manque de souplesse. L'idéal serait encore de laisser le choix aux dev (c'est un peu le cas avec jython ou jruby, mais je me laisse dire que ces implémentations ne sont pas encore au point, en tout cas c'est le cas pour jruby).

                                          Néanmoins l'appoche de python semble avoir été faite dans un soucis de gain de perfs si j'en crois ce qui a été écrit ailleurs dans cette discussion.
                                          • [^] # Re: Grandiose

                                            Posté par  (site web personnel) . Évalué à 2.

                                            Néanmoins l'appoche de python semble avoir été faite dans un soucis de gain de perfs si j'en crois ce qui a été écrit ailleurs dans cette discussion.
                                            Nan de simplicité : faciliter l'utilisation de lib C sans se poser de question quand aux accès concurrent.
                                            Du coup ils se retrouvent face à un piège : s'ils veulent ajouter le support de la concurrence sans casser l'existant, il sont obligé de mettre des locks partout par défaut (là où normalement le programmeur choisi intelligement où il faut les mettre);.. et c'est globalement 2 fois plus lent lors des tests qu'ils ont fait. Conclusion le choix de départ les conduits aujourd'hui dans une impasse : l'intérêt d'avoir plusieurs threads s'exécutant en parallèle devient de plus en plus intéressant (les machines neuves sont toutes multi-core) mais ils ne peuvent pas y passer sans casser la sémantique ou alors une lourde refonte de l'interpréteur avec un impact désastreux sur les perfs...
                                • [^] # Re: Grandiose

                                  Posté par  . É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.
                                  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  (site web personnel) . É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...
                                    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  (site web personnel) . Évalué à 4.

                                      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 !

                                      Cet exemple est complètement irréaliste. (Principalement à cause de la dernière phrase.)
                                    • [^] # Re: Grandiose

                                      Posté par  . Évalué à 1.

                                      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 ;-)
                                      • [^] # Re: Grandiose

                                        Posté par  (site web personnel, Mastodon) . Évalué à 3.

                                        hihi, c'est vrai que c'est pas mal. Et autour de moi, le principal argument en faveur de Java est "Tout le monde utilise Java". Qui est un argument tout à fait recevable, il est vrai, mais un peu dommage quand même...

                                        Mes livres CC By-SA : https://ploum.net/livres.html

                                        • [^] # Re: Grandiose

                                          Posté par  (site web personnel) . Évalué à 2.

                                          C'est parce que tu n'as pas bossé dans un milieu où les dépassements de tableau et les pointeurs aux destinations inconnues sont la norme :-)
                                          J'ai mieux à faire de mes journées que de traquer la mémoire corrompue aléatoirement, c'est pour ça que pour contrer ces incompétents je vote "Java"!
                                  • [^] # Re: Grandiose

                                    Posté par  (site web personnel) . Évalué à 3.

                                    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...

                                    s t n'a p a c q'u c p c.

                                    Tu n'as pas compris?
                                    C'est plus court, plus concis, plus clair, ce sont les premières lettre du début de ta phrase.
                                    --> Ce n'est pas parce que c'est plus court, plus concis que ça aide à s'y retrouver, loin de la.
                                    Désolé, mais un manque de typage, ça éclairci certes le code, mais je ne supporte pas : le débugguage de code non typé est bien plus chiant : c'est plus rapide à écrire, mais plus long à débugguer.

                                    Ton affirmation est loin d'être évidente, si tu ne le comprends pas, je ne vois pas quoi rajouter...
                    • [^] # Re: Grandiose

                      Posté par  . Évalué à 1.

                      Bon je suis daccord pour rails, a mon grand malheur.
                      Néanmoins faut pas éxagerer, php et python sont énormément utilisés, même si bien sur on reste loin de java.

                      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é

                      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.
                      • [^] # Re: Grandiose

                        Posté par  (site web personnel) . Évalué à 1.

                        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.
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 3.

                          En général, les décideurs en SSII ne sont pas des techniciens, ils ne savent pas bien comment ça marche et franchement ils s'en foutent. Ils veulent des mots-clef, des idées qui percutent, des arguments tout fait fournis généralement par les ingénieurs qui bossent pour eux, ou la presse "spécialisée" qui leur digère (je ne parle bien entendu pas de de publication technique mais de publication manageriale).

                          Au grand maximum, que Python "casse la rétro-compatibilité peut effrayer les ingénieurs, qui sont en contact avec la technique, mais d'une part pas forcément, d'autre part pas forcément plus que la rétro-compatibilité forcenée de Java qui lui fait maintenir des types natifs non-objet contre vents et marée malgré toutes les complications que ça implique pour les développeurs, la maintenance, la propreté du code et la standardisation.

                          Par contre, c'est vrai qu'un décideur aura tendance à être plus en contact avec des infos sur les technologies commerciales puisqu'elles font de la pub à longueur de page dans la presse "spécialisée" (souvent sous forme d'articles d'ailleurs), donc il est naturel que Java ait des facilités à se maintenir dans les SSII où la direction n'est généralement pas proche du technique...
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 3.

                          Putain mais de quel cassage tu parles ? Python est resté rétro-compatible durant toute la série 2.x (2000-2009, voire plus jusqu'à la fin de la maintenance du 2.6 qui n'est pas pour tout de suite), c'est déjà pas mal, non ?
                          • [^] # Re: Grandiose

                            Posté par  (site web personnel) . Évalué à 1.

                            c'est déjà pas mal, non ?

                            Non.
                            Pour toi 8 ans c'est peut-être super-méga-génial, moi j'en rigole : le code que j'ai pondu il y a 15 ans en C fonctionne toujours aujourd'hui, ça c'est du "pas mal".
                            Et je sais que le code que je pond aujourd'hui en C/C++ sera compatible avec la prochaine norme C++, ce qui me rassure.

                            Chacun son truc, je n'ai personnellement pas compris l'engouement sur Python, je dois être hermétique aux nouveautés mais tout ce que Python fait, je sais le faire "mieux" et plus maintenable pour le futur en C/C++. Avant, on parlait de Perl à fond, puis Java à fond, puis RoR, et maintenant Python, en attendant le suivant (C#? Mono? Autre?) : est-ce vraiment pérenne? Combien d'interpréteurs Python? Un seul. Qui décide comme il veut de casser la compatibilité. Hum, c'est facile d'être seul pour développer son "langage", le C/C++ a montré, lui, qu'on peut avoir plusieurs "concurrents" et une plus grande évolutivité.
                            • [^] # Re: Grandiose

                              Posté par  . Évalué à 4.

                              Bon, autant je suis un grand grand fan du langage C, mais dire que « tout ce que Python fait, je sais le faire "mieux" et plus maintenable pour le futur en C/C++ » me semble très présomptueux.

                              Même en utilisant les bibliothèques C qui vont bien, il faut bien avouer que les langage dits de 4è génération (Python, Ruby, Perl, et dans une moindre mesure - car orienté web uniquement - PHP) permettent de développer bien plus rapidement quelque chose de fonctionnel qu'en C. De plus très souvent, si on veut tout refaire « depuis zéro » (parce qu'on aime réinventer la roue, parce qu'on a le syndrôme du « Not Invented Here », ou tout bêtement parce qu'une vraie bonne raison le requiert), ces langages proposent nativement tout un tas de trucs (tables de hachage, augmentation dynamique et implicite de la taille des tableaux, etc). En C, je n'en parle même pas. En C++, certes, il y a la STL, mais il y a tout de même de gros écueils à éviter, et des subtilités parfois très euh ... subtiles. Un exemple tout bête :


                              for (i = <un_certain_type_d_iterateur;<condition>; i++) {
                              // quelque chose à faire
                              }


                              Bon, ben si l'opérateur '++' a été surchargé, on se retrouve avec deux évaluations de l'objet i, ce qui d'un point de vue perfs est pas génial. On me dira que oui mais bon, quand on surcharge un opérateur, il faut faire gaffe, mais c'est un exemple relativement simple de pourquoi C++ est loin d'être le meilleur langage « universel ». Je préfère 100 fois un programme Perl ou Python. S'il y a besoin d'aller vite, évidemment, alors il faut commencer à fureter du côté de C ou C++. Et même là, parfois on a des surprises.

                              Sinon, le fait est que malgré l'ascension de Python et Ruby (et avant eux de PHP), Perl reste encore très utilisé (peut-être plus par les admins que par des dévs purs et durs, je te l'accorde). Perl date de 1987 d'après wikipedia. Il a été utilisé (et l'est encore) depuis vingt ans, je trouve que c'est déjà pas mal du tout. Certes, C est plus vieux, mais il lui manque une bibliothèque standard aussi fournie que celle de Java ou au moins C++ (oui, il y a la glibc, mais tout le monde ne veut/peut pas l'utiliser -- vu que c'est pas standard, justement).

                              Enfin, si on parle de C++, le principal problème à mon avis est le fait que malgré l'existence d'une norme, l'implémentation de celle-ci est partielle au mieux [1] (je pense à C++98 notamment). Je ne parle même pas de la compatibilité entre compilateurs, ou des classes qui existent désormais dans la STL, mais qui sont redondantes avec celles mises au point par de gros frameworks (genre Qt) à l'époque où aucun standard n'existait, mais évidemment avec des différences de comportement, d'API, etc.

                              Tout ça pour dire quoi ? Affirmer qu'on fait mieux et plus maintenable que Python (ou un langage du genre) peut être vrai, mais je doute très fortement que ce soit réalisé dans les mêmes délais (après, faire du code crade, quel que soit le langage, c'est possible, bien sûr).

                              [1] Et même en C, C99 n'est pas implémenté intégralement, même par GCC, à cause de fonctionnalités « avancées » voulues par le comité de normalisation mais qui sont fichtrement difficiles à mettre en oeuvre.
                              • [^] # Re: Grandiose

                                Posté par  (site web personnel) . Évalué à 2.

                                La, ce dont tu parles, c'est le gain d'avoir une bibliothèque "standard" plus fournie du côté des langage comme Python.
                                Ca ne parle pas beaucoup du langage en lui-même!

                                Oui, Python et consort ont l'avantage de fournir une bibliothèque "standard" bien plus fournie que C/C++.
                                Mais avait-on besoin d'inventer un nouveau langage pour proposer une bibliothèque qui aide au développement? Je ne pense pas.

                                C'est relativement simple de fournir une bibliothèque "standard" quand on est le seul à proposer une implémentation (comme Python le fait).

                                Certes, l'avantage de Python est de proposer un éco-système plus complet (Langage + Bibliothèque), mais est-ce que ça en fait un langage "mieux"? Ca aide sûrement au développement rapide quand ce dont on a besoin est dans la bibliothèque Python et pas dans la bibliothèque C/C++, mais quand on doit faire un truc qui n'existe pas des deux côté, quel est l'avantage de Python en tant que langage?

                                Ce que je trouve dommage est qu'on doivent s'obliger à inventer un langage "approprié" la où on aurait pu faire une bibliothèque pour un langage déjà existant.
                                Personnellement, je reste quand même non motivé pour utiliser des langage dont il n'existe qu'un "compilateur" (ou interpréteur) : je doute de leur pérennité (et Python 3 me le confirme : des programmes en Python 2 ne vont bientôt plus avoir d'interpréteur supporté et qui évolue, vu que les efforts vont être mis sur Python 3)

                                Me reste plus qu'à porter la bibliothèque standard Python en C++ pour lui enlever cet avantage :-D.
                                • [^] # Re: Grandiose

                                  Posté par  . Évalué à 3.

                                  Attend là, on est quand même en train de comparer un langage interprété à typage dynamique à un autre compilé à typage statique, tu ne peux pas les trouver comparables même à bibliothèque standard équivalente ...

                                  Et en ce qui concerne le "cassage" de la 2.x, faudrait vous renseigner, c'est pas du cassage de tordu : c'est juste pour quelques trucs qui étaient déjà "borderline" ...
                                • [^] # Re: Grandiose

                                  Posté par  . Évalué à 4.

                                  « Mais avait-on besoin d'inventer un nouveau langage pour proposer une bibliothèque qui aide au développement? Je ne pense pas. »

                                  Pas que. Je développe en C et Perl (C pour mes « vrais » programmes, Perl pour des scripts qui exploitent et post-traitent les sorties de mes progs C). Ne serait-ce qu'à cause de la façon dont le typage fonctionne dans chaque langage, en Perl je fais des choses qui fonctionnent aussi rapidement qu'en C (du moment que le goulot d'étranglement est le disque dur ou le réseau, honnêtement, Perl/Python/etc n'ont rien à envier à C/C++) mais ça me prend facilement cinq fois moins de temps.

                                  Par exemple j'ai des fichiers dont le format se rapproche du CSV. Je dois manipuler les données dans tous les sens. En Perl [1] je n'ai eu qu'à me faire un petit module pour manipuler ce genre de fichiers (dont la fonction principale est quelque chose du genre csv_to_array() ), et surtout, une fois que j'ai récupéré mes données sous forme de tableau 2D, je peux les traiter en foutant le tout dans un tableau de hachage (qui est un type natif de Perl, pas besoin d'appeler une bibliothèque externe, et si je veux faire un hash de hash, tout est fait dynamiquement ... En C, et même en C++, ce serait quand même assez galère à obtenir comme comportement), un autre tableau, etc. En C, pour faire la même chose (ie faire mon petit module d'extraction « brute » de données, et le post-traitement à proprement parler), j'aurais eu non-seulement plus de lignes de code (ça à la limite, on s'en fiche, si c'est bien écrit et encapsulé), mais aussi bien plus de manipulations de fonctions pour extraire les infos en fonction de la nature de mes données. Je ne peux pas trop expliciter plus, mais tout mon discours ici est de dire que, même si j'adore vraiment le C, quand il s'agit de développer vite une application qui n'est pas trop intensive niveau I/O, utilisation CPU, etc., alors Python/Perl/Ruby & co sont clairement de meilleurs choix selon moi. Je ne parle même pas du côté merveilleux de Python à pouvoir accepter des fonctions C « directement » quand on a besoin de perfs supplémentaires (en Perl on peut aussi faire, mais c'est beaucoup, beaucoup plus lourd).


                                  [1] Je ne connais pas assez bien Python, donc je ne peux pas trop en parler, et de façon générale il faudrait que je m'y prenne différemment car il est fortement typé, donc les opérations sur des floats ou des strings devraient être « explicites », mais ce serait évidemment faisable aussi.
                              • [^] # Re: Grandiose

                                Posté par  . Évalué à -1.

                                Même en utilisant les bibliothèques C qui vont bien, il faut bien avouer que les langage dits de 4è génération (Python, Ruby, Perl, et dans une moindre mesure - car orienté web uniquement - PHP)
                                Php uniquement orienté web ? J'en parlerai à mon /usr/bin/php tiens.
                                • [^] # Re: Grandiose

                                  Posté par  . Évalué à 2.

                                  Je savais que quelqu'un allait tiquer. :-) En pratique, je ne connais personne, ni aucun projet d'envergure utilisant php sans le web. Ça en fait un « langage du Web » selon moi.
                                  • [^] # Re: Grandiose

                                    Posté par  . Évalué à 1.

                                    Doit-on être d'envergure internationale afin d'exister ?
                                    Le php peut très bien être utilisé en tant que langage de script et il est difficile de faire d'un script de ci de là, un projet d'envergure.
                                    • [^] # Re: Grandiose

                                      Posté par  . Évalué à 2.

                                      PHP est déjà d'envergure internationale. C'est un langage très utilisé. N'empêche, quand on parle de scripter des petits trucs hors le Web, j'entends 10 fois plus parler de Python, Perl, ou Ruby que de PHP.

                                      Maintenant, oui, on peut se servir de PHP comme d'un langage de script « générique ». Il n'a juste pas été fait pour ça à la base.
                          • [^] # Re: Grandiose

                            Posté par  (site web personnel) . Évalué à 2.

                            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 !
                            • [^] # Re: Grandiose

                              Posté par  . Évalué à 2.

                              Bon, t'as rien suivi, quoi.

                              Tu peux très bien faire des libs qui sont compatibles entre Python 2.x et 3. Le "cassage" fait qu'il faut juste changer quelques trucs pour qu'ils passent en 3.0, mais ça restera compatible 2.x.
                              • [^] # Re: Grandiose

                                Posté par  . Évalué à 2.

                                Je pense que les « quelques trucs » c'est ce qui fait qu'on peut dire que ce n'est pas compatible. Je ne sais pas à quel point les modifications à faire sont importantes - et surtout à quel point elles peuvent se révéler sensibles - mais ce n'est pas trivial, surtout si tu dois requalifier ton code ensuite ...
                    • [^] # Re: Grandiose

                      Posté par  . Évalué à 2.

                      Je n'avoue qu'une chose : ce que j'ai voulu dire, c'est que ce n'est pas parce qu'une technologie n'est pas massivement employée par des SSII qu'elle est "au point mort", surtout dans l'open-source. Ca veut surtout dire qu'il faut un moment pour qu'elle fasse ses preuves aux yeux des SSII, et ça ne peut se faire que par deux moyens : convaincre la direction (qui généralement n'y connaît rien à la technique et lit des journaux bourrés de pubs d'éditeurs commerciaux) et convaincre la clientèle (qui est généralement assez peut orientée techniquement ou prône à conserver l'existant).

                      Par contre, Ruby et Rails commence à séduire les hébergeurs et les structures plus petites, à cause de la productivité, la lisibilité du code, la fiabilité (suite de tests intégrée, pas très difficile à mettre en place), le fait de maîtriser beaucoup mieux le workflow et la facilité de réutilisation des plugins / gems souvent assez peu intrusifs. Il a aussi séduit des startups qui développent des sites commerciaux (ou pas), et qui n'ont pas les moyens ni le besoin de faire appel à d'énormes machineries pour leurs débuts, et veulent un code propre qui évolue rapidement.

                      A ce propos, et sans vouloir t'offenser, la rétro-compatibilité n'est pas l'apanage de Java. Ce n'est pas parce qu'une plate-forme open-source évolue qu'elle ne répercute pas des corrections critiques sur les version "vivantes" précédentes, et même pour d'importants sauts de versions il est fréquent que l'essentiel du code existant reste viable à quelques légères modifications près.

                      Sinon, je ne peux pas tellement parler de python, je n'y ai pas (encore) mis les pieds, mais je ne vois pas en quoi un système à base Python ou Ruby ne pourrait pas tenir 10 ans, voir plus, à condition que, comme pour une appli Java de cette ancienneté, il y ait de la maintenance et de la mise à jour effectué. Il se trouve que pour Ruby, Python, ou d'autres logiciels Open-Source, on a envie de faire évoluer la plate-forme au cours de la vie d'une application, personnellement je ne vois pas de mal à ça, je trouve plutôt ça positif. A ma connaissance, c'est d'ailleurs ce qui se passe pour toute plate-forme de développement tant qu'elle n'est pas morte. Evidemment, ça devient de plus en plus difficile de trouver des développeurs COBOL de nos jours, mais les développeurs COBOL sont également de moins en moins demandés, ceci accompagne cela...
                      • [^] # Re: Grandiose

                        Posté par  (site web personnel) . Évalué à 1.

                        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.
                        • [^] # Re: Grandiose

                          Posté par  . Évalué à 2.

                          Pour le python, je ne connais pas, donc je te crois sur parole. Je ne parlais pas que du python.
                • [^] # Re: Grandiose

                  Posté par  . Évalué à 2.

                  Ruby on Rails au point mort ? J'ai l'impression au contraire d'une croissance exponentielle, en tout cas en terme d'intérêt général des développeurs autour de moi.
                  • [^] # Re: Grandiose

                    Posté par  . Évalué à 2.

                    Et même qui commence à interpeller les SSII, puisque j'ai déjà fait de l'initiation à Ruby on Rails dans la boîte que je viens de quitter parce que le directeur voulait que des gens qui restent gardent un oeil dessus, au cas où...
                    • [^] # Re: Grandiose

                      Posté par  (site web personnel) . Évalué à 2.

                      Tu t'es barré parce que tu as dispensé une formation RoR? :-)
                      (sur le coup j'ai sursauté)
                      • [^] # Re: Grandiose

                        Posté par  . Évalué à 2.

                        Au contraire le contraire, je n'ai pu former certains de mes collègues à RoR que parce que je partais et que le directeur voulait garder un oeil sur les nouvelles technos du web. Pas besoin d'avoir peur.
          • [^] # Re: Grandiose

            Posté par  . Évalué à 2.

            J'avais en tête Django, qui me génère automatiquement le fichier de conf (pour faire une comparaison à peu près valable, puisqu'il n'y a pas de compilation). Et on y passe 10 min sur 2 mois de dev ... Quant à la redondance, j'en vois un peu quand même, je pense que si ce fichier pouvais être généré automatiquement à la base ça pourrait être pas mal.
          • [^] # Re: Grandiose

            Posté par  . Évalué à 2.

            "C'est quoi ton environnement de dev si parfait ou tout est génial et y'a rien de chiant à faire"

            Ada avec les Gnat Project Files : tu donnes le répertoire avec les sources, le fichier qui contient la procédure de départ, les flags pour la compile et le reste roule tout seul. Même sur des gros programmes, ça fait pas des fichiers inbitables de n*1000 lignes.
        • [^] # Re: Grandiose

          Posté par  . Évalué à 4.

          Je pense que malheureusement ces outils sont faits dans un environnement par et pour des personnes qui sont habitués à ces docs et tutos assez imbitables, et que cela perpétue cette image d'usine à gaz, de pestilence corporate.
          J'imagine que cela entretient aussi l'image du programmeur java stupide qui collera sans sourciller du code qu'il ne comprend pas, qui n'a quasiment aucune compétence de programmation, ni aucune "culture" ou recul.
    • [^] # Re: Grandiose

      Posté par  . Évalué à 10.

      C'est pas que c'est presque ça, c'est que c'est tout à fait ça. Et c'est pas tellement une question de Java, j'ai vu des trucs pire en SSII en PHP (ok, pas codé par des experts PHP mais plutôt des dérivants Java ou carrément des pas codeux). C'est plutôt le format SSII qui mène à ça en fait, même s'il y a moyen de faire des trucs efficacement en SSII, la bureaucratie plombe tout et tire vers le bas niveau outils :
      - tu dois utiliser windows parce que sinon tes petits camarades te regardent d'un drôle d'air
      - tu dois utiliser ms office parce que sinon ton chef de projet n'aime pas que tu blaste involontairement ses outils avancé de productivisation positronique qui lui gagnent le temps qu'il perd à les utiliser
      - comme tout le monde est sous Eclipse on va utiliser SVN plutôt que GIT pour gérer les versions même si c'est moins bien
      - le temps qui devrait être alloué à la rédaction de tests est offert en cadeau au client, mais on pressurise l'équipe pour faire le travail dans le temps vendu, donc pas de tests unitaires

      "Bureaucracy expands to meet the needs of the expanding bureaucracy." Oscar Wilde
      Quand on en est là, ça fait ça que le projet soit en Java, en PHP, en Ruby on Rails ou en C, ça sera la même chose partout. Mais c'est vrai que Java facilite quand même beaucoup l'arrivée à ce stade au sein même des équipes de développement.
      • [^] # Re: Grandiose

        Posté par  . Évalué à 3.

        Ce que je trouve étonnant dans ce milieu, c'est que les mecs qui conduisent ces SSII sont généralement bien de droite et contre la bureaucratie de l'état, et préfèrent le libéralisme tout puissant qui résoudra les lourdeurs du système actuel.

        Le jour où "ceux d'en bas" se rendront contre que leur argumentaire contre les tares de l'état sont là pour qu'ils recréent les mêmes, mais les leurs, autre part, on aura fait un grand pas.
        • [^] # Re: Grandiose

          Posté par  . Évalué à 1.

          Eh oui, la bureaucratie, les états n'en ont pas le monopole, et l'inefficacité non plus.

          Enfin, ça dépend ce qu'on appelle inefficace, si l'objectif est d'en foutre plein les fouilles à un petit nombre, alors le modèle économique ultra-libéral est très bien fait. Si bien fait qu'il permet aux gagnants de provoquer des crises, les faire payer par la collectivité sans rien donner en échange, même pas de vagues promesses de mieux se conduire, et de continuer à dire du mal de l'état et des services publiques.
    • [^] # Re: Grandiose

      Posté par  (site web personnel) . Évalué à 4.

      "Java (15 ans d'expérience, s'il vous plaît). "

      Personne ne note, mais ca me rappelle une blague en 200 d'un mec qui cherchais quelqu'un avec 7 ans d'expérience en java ...
      • [^] # Re: Grandiose

        Posté par  (site web personnel, Mastodon) . Évalué à 10.

        Ben perso, le sysadmin de mon université, avec qui je m'engueulais, m'a dit : "qu'il ne fallait pas le prendre pour un idiot, qu'il connaissait Linux depuis longtemps et qu'il avait même donné des formations Linux dans les années 70".

        Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Grandiose

      Posté par  . Évalué à 3.

      "Java, sans IDE t'es rien."

      Ah bon. Enfin, j'imagine que certains considérent emacs comme un IDE.
      • [^] # Re: Grandiose

        Posté par  . Évalué à 3.

        Ca dépend, est-ce qu'un système d'exploitation peut être considéré comme un IDE ?...
  • # Je n'aurais qu'une seule chose à dire...

    Posté par  . Évalué à 10.

    FOUTAISES!
  • # Ce que j'attends avec impatience...

    Posté par  . Évalué à 10.

    ... c'est la refonte de Linuxfr avec l'architecture web utilisée par Voyages-SNCF.
    • [^] # Re: Ce que j'attends avec impatience...

      Posté par  . Évalué à 10.

      mais vous n'avez pas compris ? C'est justement ce que vient de nous avoir été décrit avec brio dans ce journal ! Quand on a déjà un framework opérationnel, les consultants le réutilisent généralement. Par contre pour voyages-sncf ils ont ensuite rajouté des bindings vers asp, ce qui peut expliquer les quelques ralentissements occasionnés...

      Bravo pour ce splendide et hilarant journal Ploum. Il aurait été sorti le 31 décembre 2008, j'aurais dit que c'était le plus drôle de l'année, là c'est encore tôt mais c'est en bonne voie :)

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

  • # Mdr

    Posté par  . Évalué à 4.

    Excellent journal, qui bien qu'ironique n'est pas si loin de la réalité telle qu'elle a été il y a quelques années.

    Heureusement, depuis, les choses ont évolué et beaucoup de ces pseudo-consultant virés depuis sont revenus par une autre porte, convertis à des technicobuzz plus récents (méthodes Agiles, par exemple : rien de mauvais en soi mais si mal "consulté"...). Et la technologie aussi, elle, a évolué, un peu, quoi, si...

    Tiens, je devrais écrire une parodie "mise à jour" sur J2EE :)
  • # Un grand MERCI pour cette crise de rire! :D

    Posté par  . Évalué à 10.

    Ca m'a rapellé le boulot tiens ...
  • # Tout est vrai

    Posté par  . Évalué à 10.

    Tout le crois que ce journal est une facétieuse plaisanterie, mais en fait non. C'est rien que du vrai.

    A part le coup de l'héritage multiple, rien n'est éxagéré...
  • # Tellement vrai

    Posté par  . Évalué à 7.

    C'est tellement vrai que ça me fait peur ! Pourvu que je ne tombe jamais sur ce genre de projet...
    • [^] # Re: Tellement vrai

      Posté par  . Évalué à 6.

      Ben va pas falloir bosser en SSII alors...
      • [^] # Re: Tellement vrai

        Posté par  (site web personnel) . Évalué à 2.

        en SSII on est payé à la ligne de code, alors on n'est pas à ça près :-)

        Axel
        • [^] # Re: Tellement vrai

          Posté par  . Évalué à 1.

          C'est pour ça que je me suis cassé de ma dernière SSII. Je m'y plaisait niveau ambiance, collègues, mais j'arrivais pas à supporter de me voir devenir "that bad a coder" à cause de la pression du groupe et de la bureaucratie. Je n'avais pas envie de rester le mec qui "n'en est pas à ça près" et qui faisait "la merde qu'on lui demande".

          Après chacun ses envies, il y en a qui tolèrent très bien ça s'il y a un gros chèque à la fin du mois...
          • [^] # Re: Tellement vrai

            Posté par  . Évalué à 1.

            Après chacun ses envies, il y en a qui tolèrent très bien ça s'il y a un gros chèque à la fin du mois...

            C'est quoi le nom de cette SSII ?? :o)
            • [^] # Re: Tellement vrai

              Posté par  . Évalué à 1.

              Je parlais des gens qui y travaillent qui tolèrent ce genre de système du moment qu'ils y touchent une somme qu'ils trouvent (arbitrairement) élevée (25k€ / an ça paraît une fortune pour certaines personnes).
  • # J'ai l'impression d'être vendredi tous les jours

    Posté par  (site web personnel) . Évalué à 10.

    Bon démarrage de dlfp en 2009, on a vraiment l'impression que c'est vendredi tous les jours ... et ça : C'est vraiment bien !!!! j'adhère à 100%.
    C'est vraiment agréable de ne plus attendre le vendredi pour sourire.
  • # Rire jaune

    Posté par  . Évalué à 6.

    Rire jaune, parce que c'est hyper drôle, mais ça se passe réellement comme ça dans les entreprises. Toujours faire plus compliqué pour justifier un budget, au final rien ne marche, et on achete la solution d'un concurent qui l'aura lui fait intelligement.

    Remarquez comment la "philosophie" du développement Agile est fièrement mis en avant au début et royalement non appliqué par la suite :)

    Bravo

    Gaetan
    • [^] # Re: Rire jaune

      Posté par  . Évalué à 10.

      Le problème avec les buzzwords, c'est qu'il y a une manière perverse de les employer non pas pour populariser et répandre les idées qu'ils désignent, mais comme argument conclusif de discussion pour convaincre un décideur ou un groupe d'adhérer à quelque chose de tout à fait différent. Par exemple :

      "Mes chers amis, en tant que chef de projet j'ai une bonne nouvelle : Nous allons pratiquer la nouvelle méthode Agile de développement.

      Je n'ai pas besoin de vous expliquer Agile, il y a la wikipedia pour ça.

      Bien entendu, dans un premier temps et pour respecter les deadlines, nous allons nous contenter de certaines pratiques et exclure les choses qui font perdre du temps inutilement comme le codage par pair (pas besoin de mettre 2 personnes sur un même code) et les tests automatisés (on ne va pas perdre du temps à installer et écrire une suite de test, je vous fais confiance pour faire du bon code qui marche du premier coup n'est-ce pas ?) et plutôt que de faire du refactoring, on va bien concevoir notre architecture de classe dès les début pour prévoir tous les cas.

      Oh, et aussi, toutes les communications avec le client passent par moi, et le cahier des charge, les specs fonctionnelles et les specs techniques ont été établies préalablement par un cabinet de consultant.

      Messieurs, au travail."
    • [^] # Re: Rire jaune

      Posté par  . Évalué à 3.

      C'est ça qui est flippant dans son journal : je n'e connais rien en développement java en environnement professionnel mais j'ai vraiment eu l'impression qu'il a intégré de nombreuses anecdoctes vécues dans son histoire :s
      • [^] # Re: Rire jaune

        Posté par  (site web personnel) . Évalué à 5.

        Comme a dit quelqu'un d'autre, le problème est plus au niveau de la gestion de projet que dans la techno elle-même (bon, j'ai jamais fait de J2EE complet). Ce n'est pas en faisant "durée de dev requise / nombre de mois avant la date butoir = nombre de contractants" qu'on risque de faire du bon boulot. Les boîtes victimes de ce genre de problèmes veulent le beurre, l'argent du beurre et le sourire de la boulangère: ne pas embaucher, et avoir des gens motivés qui voient le projet à long terme. Ça sonne faux.

        Je suppose qu'on a tous plus ou moins ce genre d'anecdote (comme refaire les specs quand le projet est sensé être abouti à 80%). Ça me fout les boules d'être entrainé dans ce genre de situation, j'en ressens une grande impression d'impuissance, et d'être amené de manière inéluctable à faire une grosse bouse.
        • [^] # Re: Rire jaune

          Posté par  . Évalué à 2.

          Ah j'oubliais, je parle aussi d'expérience mais je n'ai jamais fait de java. Je parle du monde du C/C++, c'est pareil et il parait que java c'est pire. C'est quand on a des "décideurs" qui ne s'y connaissent rien à la technique qu'on arrive à des situations comme ça. Un chef qui sait mettre les mains dans le cambouis peut dire franchement à un ingé : "là, t'as ton algo est 10 fois trop complexe pour que c'est sencé faire, tu peux faire comme ça, comme ça et comme ça".

          Alors que pour un chef non technique, plus c'est compliqué, mieux ça doit être...
        • [^] # Re: Rire jaune

          Posté par  . Évalué à 6.

          ce genre de problèmes veulent le beurre, l'argent du beurre et le sourire de la boulangère
          Tu vas acheter ton beurre chez la boulangère toi ?
      • [^] # Re: Rire jaune

        Posté par  . Évalué à 5.

        Et oui. Bon nombre de manager n'integre tout simplement pas la notion de bug. Ils se disent qu'il devraient imputé une certaine somme sur le salaire du gars qui a écrit un bug, comme ça la prochaine fois il recommencera pas, le salaud.

        Savent pas qu'un bug peut être conceptuel, ie, pas de bug de codage mais que l'archi en elle meme puisse etre vereuse, et qu'il faille tout changer.

        sans savoir qu'il y a une contradiction forte entre la "productivité" (bien souvent résumé au nombre de ligne de code écrite, ou, parfois, au nombre de bugs résolu ou de feature développé/semaine) et "qualité". Les deux partages la même quantité de ressource (le cerveau de l'ingé), donc on peut pas tirer sur l'un sans diminuer 'autre.


        Et il savent ce que sont les maths, c'est pas dûr je te dis :
        - un ingé de base corrige 1 bug/jour
        - deux ingé corrigeront 2 bug/jour
        ...

        Ca lui viendrait pas à l'esprit qu'un bug mal corrigé puisse en générer 15.

        si 2 ingé sur le même poste n'écrivent qu'1 feature/jour (ou corrige qu'1 bug/jour) il produise du code meilleur pour plein de raison psychologiques difficilement mesurable :
        Exemple, moi :
        1) quand je suis seul je code comme un porc, personne peut me relire sur le fond, dans les revues les collegues s'attaquent qu'aux erreurs esthétiques, un if mal indenté, des variables qui respectent pas la nomenclature,...) sans savoir si le code fonctionne réellement. Evidement je suis un Dieu et je fais aucun bug (en fait j'ai développer une technique secrete "masquage de potentielle probleme sous une argumentation fumeuse", et quelques points en "correction de mes bugs en revue de code des autres bugs... et parfois des miens), mais tout le monde ne l'est pas.
        2) quand un gars est a coté de moi et comprend ce que je fais, à la premiere erreur il me le fait remarqué. Evidement au début ça gonfle et j'ai envie de lui faire manger mon clavier, mais quand on se rend compte des résultats (j'ai pas de bug à corriger pendant les réunions, donc je peux dormir), j'adhére totalement en tant que développeur.

        Si j'étais manager je l'appliquerais immédiatement. Mais, perso, je suis pour une approche hybride:
        - phase de prototyping : méthode agile 100%, release early/often, codage par pair, test driven development,...
        - phase de développement industriel traditionel (si absolument nécessaire pour un grand compte par exemple, une fois l'archi trouvée et validée) : on reprend le cycle en V avec un beau cahier des charges, un plan de test bien propre, un développement... qui est déjà fait un test sur terrain bien lourd et bien complet.
        • [^] # Re: Rire jaune

          Posté par  . Évalué à 7.

          Ouais. Mais : en SSII, je n'ai jamais rencontré de manager / chef d'équipe / chef d'entreprise assez éclairé ou assez courageux pour prendre sur lui d'autoriser l'équipe à travailler par prototypage. Ils préfèrent passer beaucoup de temps sur des specs abstraites et mal comprises par le client, mais qui génèrent une paperasse bien indigeste qui "prouve" qu'ils ont bien fait le boulot, et donne l'impression au client qu'il y aura beaucoup de temps à passer sur le code pour que ça fonctionne, alors que l'approche par prototype ça donne souvent ça :
          "Ah, ben vous l'avez déjà presque terminé en fait, c'est bien, vous avez un peu vu gros pour le devis initial mais me voilà rassuré, vous allez nous développer ça moitié prix *wink*wink* *nudge*nudge*".

          Pour que l'utilisation du prototypage fonctionne, il faut alors que les deux équipes client et développeur soient proches pour discuter du bidule fréquemment (sinon c'est difficile de prototyper correctement sans se viander en cours) et pour que le client réalise que le prototype ne peut pas être le machin final ni servir directement de squelette ou de base et réduir le temps de travail prévu (cf plus haut).

          Ou alors, si ça bloque, il reste la technique de bâtard (mais elle a déjà fonctionnée) :
          - on fait un prototype "dans son garage" sans en avertir le client
          - on fait rapidement une spec. fonctionnelle bourrée de captures d'écran du prototype, et on dit que c'est juste une maquette
          - on laisse le client faire "ouaou" à la réunion de validation, et on est quand même mieux préparé pour mettre en production
          • [^] # Re: Rire jaune

            Posté par  . Évalué à 2.

            c'est ce qu'on a fait a un moment dans ma boite (technique de bâtard) Et ça a tellement bien marché que le client ne nous lachait plus. Le client est pas le problème (il paye pour un truc et si on lui montre une maquette il sera content), c'est en interne que ça coince. Il faudrait que le code soit parfait dès le début, alors que les specs ca évolue, les algos sont pas nécessairement optimaux au début (surtout quand les spec évoluent, c'est horrible d'optimiser un code et de se rendre comte que c'est pas la bonne chose qui est faite).


            Les managers ont peur des erreurs. Pour eux c'est le mal absolu de faire des erreurs, ils ne comprennent pas qu'en faisant des erreurs (en prototypage) on apprend et que la prochaine fois (en développement réel) on code mieux. Alors ils changent le projet d'équipe... et ça recommence.

            Perso, sur certains projet maintenant je me dis que j'ai vraiment écrit de la merde à un moment, et que si je devais refaire tel algo je le ferais différement. Mais si je prend pas le temps de me planter, évidement je n'apprend pas et je ponds un truc qui marche mais qui n'est pas parfait.

            Faut leur apprendre à valoriser les erreurs au lieu de comptabilisé ça dans un tableau et tenter de le réduire au strict minimum. C'est ce que le développement agile promouvoit : releae often pour identifier immédiatement les soucis, et ne pas hésiter à réécrire le code from scratch quand on est dans l'impasse, au lieu de maintenir un code dépassé.
  • # pas mal !

    Posté par  . Évalué à 6.

    Une belle caricature qui m'a bien fait rire.

    Le principal problème des développements JEE c'est en effet les gens qui aiment faire de manière complexe ce qui peut être fait simplement.

    Et puis après tout une ré-écriture de LinuxFR en java ça peut être marrant à faire.
    (Ca y'est j'ai marché dedans)
    Y-a-t-il des gens motivés ? :-)
    • [^] # Re: pas mal !

      Posté par  . Évalué à 3.

      Je développe actuellement sur mon temps libre un logiciel de gestion de braderie en J2EE, mais après, pourquoi pas :)
    • [^] # Re: pas mal !

      Posté par  . Évalué à 2.

      C'était le poisson d'avril de quel année linuxfr en java ?

      Envoyé depuis mon lapin.

  • # Sympa mais ...

    Posté par  (site web personnel) . Évalué à 2.

    Personne n'a remarqué l'incohérence dans ce journal ?

    Janvier 2009

    Tous les consultants sont sous Windows sauf un, qui connait bien Linux. Il a installé une Ubuntu puis installé tout à la main depuis les sources.


    Puis :

    Juillet

    Suite à l'utilisation de librairies spéciales, le projet ne tourne plus que sous Windows. Le consultant qui était sous Linux réinstalle WinXP.


    Enfin :

    Septembre

    Le consultant qui utilise Linux


    Lisez les journaux !
    • [^] # Re: Sympa mais ...

      Posté par  . Évalué à 5.

      J'avais remarque mais j'ai pense que ce consultant étant assez calé en informatique a installé Windows en virtualité dans son Linux ...
      • [^] # Re: Sympa mais ...

        Posté par  . Évalué à 9.

        S'il était calé en informatique, il n'aurait pas choisi une Ubuntu

        (c'est trollesque depuis le début, donc je sors pas :-p )
        • [^] # Re: Sympa mais ...

          Posté par  . Évalué à 3.

          va dire ça à Linus Torvald...
          (il utilise RedHat et Ubuntu)

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: Sympa mais ...

      Posté par  . Évalué à 4.

      Comme tout le reste est très bon, je me dit que Ploum voulait dire:

      "Le consultant qui [connait] Linux" ou "Le consultant qui[, d'habitude,] utilise Linux"

      Tom
  • # Top 10

    Posté par  . Évalué à 5.

    C'est excellent cela marche aussi avec SAP par exemple !
    Qui connait SAP DreamWeaver ? Le meilleur, ou le pire c'est selon le point de vue, de J2EE et de SAP, ensemble !

    Le dernier grand projet auquel j'ai participer pour un client du TOP 10 aéronautique dans une SSII dans le Top10 bien entendu ! mdr

    Remarquer bien que le développement en couche et modèle MVC c'est aussi très tendance chez Billou et dot.Net !
    • [^] # Re: Top 10

      Posté par  (site web personnel) . Évalué à 2.

      Ca marche avec SAP, mais faut rajouter les consultant allemands .
    • [^] # Re: Top 10

      Posté par  . Évalué à 1.

      C'est excellent cela marche aussi avec SAP par exemple !

      Pas faux... Et ça marche même avec php, d'ailleurs ;-)

      Le mot clef là dedans c'est euh... FOUTAISES ! ;-)
  • # tu nous tiens en haleine !

    Posté par  . Évalué à 4.

    ...personne ne s'inquiète de savoir si l'un des consultants a atteint le top 10 de cochonland ???
  • # C'est trop drôle

    Posté par  . Évalué à 1.

    Voilà une caricature qui m'a bien faire rire.

    Cependant, sans vouloir paraître péremptoire, ce serait encore mieux si l'orthographe n'écorchait pas les yeux (franchement "shéma", c'est pas joli-joli comme erreur).
    • [^] # Re: C'est trop drôle

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      ça a été fait d'un jet à une heure du mat, complètement crevé et sans relire et de manière non-linéaire (j'ai écrit les mois puis j'ai rajouté des trucs par-ci par-là au feeling). Cela explique (sans excuser) les fautes et les incohérences... désolé.

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: C'est trop drôle

        Posté par  . Évalué à 1.

        C'est pas un mal, je suis le premier à faire des fautes quand je claviotte.
        Et comme je déteste faire des fautes, je suis content quand on me les pointe.
        Et donc, je me permets de rendre la pareille en pointant celles des autres (à la différence que c'est plus jouissif dans ce sens là).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.