Nuxeo CPS tournera sous Java

Posté par (page perso) . Modéré par Mouns.
Tags :
0
28
sept.
2006
Java
Nuxeo CPS (Collaborative Portal Server) est un logiciel de gestion de contenu et de travail collaboratif en GPL. Actuellement basé sur Zope, il est en cours de portage vers Java, plus spécifiquement Java EE 5, et utilise un grand nombre de technologies standards (JCR, EJB3, JSF, OSGi…) et de produits libres (Apache Jackrabbit, Lucene, JBoss AS, jBPM, JBoss Rules, Seam…).

Le logiciel a été au passage renommé Nuxeo 5, et devrait sortir au novembre d’après la feuille de route du projet. Il sert à réaliser des applications à la fois en environnement serveur (Java EE) et en environnement client riche (RCP).

Il repose sur
  • un module qui fournit un système de composants extensibles et faciles à déployer et baptisé Nuxeo Runtime. Ce module peut d’ailleurs être utilisé dans tout type d’application Java. La version 1.0 a été annoncée cette semaine,
  • un “coeur de gestion documentaire”, Nuxeo Core qui fournit les fonctions de base de la gestion documentaire, et qui peut être embarqué aussi bien dans des applications serveurs que clientes. La version 1.0 sortira en octobre

Nuxeo 5 utilisera la licence LGPL.
Nuxeo 5 est édité par la société Nuxeo, un éditeur de logiciels libres, spécialisé dans l’ECM (discipline qui regroupe la GED, la collaboration, le workflow, la gestion de contenu web, la gestion de la conformité...).
  • # et bien...

    Posté par . Évalué à 9.

    c'est pas ça qui va faire baisser le prix de la RAM!
    • [^] # Re: et bien...

      Posté par . Évalué à 5.

      c'est pas ça qui va faire baisser le prix de la RAM!

      Ca compensera avec le gain en CPU.
  • # Et Python ça pue du Zope ?

    Posté par . Évalué à 4.

    Jeu de mot pourri mis à part, que deviens Zope ?

    Zope était super à la mode il y a quelques années à l'époque ou Python devait régner sur l'univers. Mais depuis que c'est Ruby qui est le futur empereur intergalactique du web je n'en entends plus trop parler.

    Y a-t-il encore des projets actifs basés sur Zope ?

    BeOS le faisait il y a 15 ans !

  • # Bonne nouvelle ?

    Posté par . Évalué à 1.

    J'avoue être assez dubitatif en lisant l'article :
    - c'est certainement une bonne nouvelle pour CPS car peu d'entreprises ont la capacité, ou l'intention, d'entretenir et de gérer des compétences Python/Zope et Java. Ce portage devrait donc convaincre beaucoup de réticents.
    - c'est une mauvaise nouvelle pour Zope qui perd l'exclusivité d'un très bon produit.
    - c'est une horrible nouvelle pour les performances.

    Au passage je constate avec amertume que les marketologues gonfleurs de bulles, et vendeurs de "nouvelle économie" sont de retour et bien décidés à nous en remettre plein la vue :
    '... Java EE 5, et utilise un grand nombre de technologies standards (JCR,
    EJB3, JSF, OSGi…) et de produits libres (Apache Jackrabbit, Lucene, JBoss AS, jBPM, JBoss Rules, Seam…)' sauf que là c'est 'standard' et 'libre', donc on va en avoir encore plus pour notre argent et pour nos yeux : ressortez les Ray-Ban les gars ! :-)
    • [^] # Re: Bonne nouvelle ?

      Posté par . Évalué à 10.

      - c'est une horrible nouvelle pour les performances.

      C'est marrant mais j'aurais dis exactement le contraire , python n'est vraiment pas célèbre pour ses performances.
    • [^] # Re: Bonne nouvelle ?

      Posté par (page perso) . Évalué à 10.

      "c'est une horrible nouvelle pour les performances": je ne vois pas ce qui te fait dire ca. Si on fait ce switch, c'est aussi parce qu'on pense avoir touché le plafond en terme de performance de Zope sur des grosses applications. Donc on pense bien, et les mesures actuelles le montrent, arriver à des gains très nets en performances et en scalabilité.

      "marketologues gonfleurs de bulles": là je vois pas le rapport. JCR est une API Java standard depuis 1 an 1/2 (la JSR-170). EJB3 est le fondement de la nouvelle version de Java EE, Java EE 5, qui remplace J2EE. JSF est le framework de présentation standard de Java EE. OSGi est une technologie Java qui est le fondement du modèle de plugins d'Eclipse. Enfin Jackarabbit, Lucene, etc sont des composants, car la richesse du logiciel libre, c'est de pouvoir faire des applications complexes en assemblant des briques plus simples. C'est aussi pourquoi nous avons concu Nuxeo Runtime, pour bénéficier de cette "architecture de composants" qui nous facilite la vie en tant que développeurs (et facilite la vie des intégrateurs qui utilisent nos produits).

      S.

      --
      Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

      "There's no such thing as can't. You always have a choice." - Ken Gor

      • [^] # Re: Bonne nouvelle ?

        Posté par (page perso) . Évalué à 4.

        ["marketologues gonfleurs de bulles": .....]

        Je trouve tout de même que cela ressemble énormément à cela. Tes arguments sont sûrement légitimes et je ne permettrais pas de te mettre en doute sur les points que tu mets en avant. Mais auprès du décideur pressé java ça fait nettement plus sérieux que python.

        De plus, nuxeo certfie à ses clients depuis des années que zope/python sont des technologies robustes éprouvées, maitrisées en interne... Il va falloir embaucher un super commercial pour expliquer au client pourquoi la technologie d'hier ne sera plus celle utilisée demain. Comment expliquer au client qui a capitalisé sur zope/python/cps depuis des années, qu'il peut tout jeter et se mettre à java ?

        Nuxeo cherche à embaucher un développeur java:
        http://fr.lolix.org/search/offre/offre.php3?id=6192

        Il n'y a pas de compétences en interne ? Personnellement ça ne m'inciterait pas à migrer.

        Les développeurs déjà présents chez nuxeo vont-ils rester ? Qu'en pensent-ils ? Je pense notament à Tarek. Je le vois mal se mettre à java!!
        • [^] # Re: Bonne nouvelle ?

          Posté par (page perso) . Évalué à 9.

          Merci de pointer vers notre annonce de recrutement, ca nous aidera peut-être à trouver les bonnes personnes.

          Mais d'un autre côté, tu prends les choses un peu à l'envers:

          1. Nuxeo cherche à recruter, parce que Nuxeo est une boite en croissance et que pour faire tous les projets qu'on a à faire (sans parler de tous ceux qu'on va arriver à vrendre plus facilement parce qu'on est passé à Java), on a besoin de développeurs.

          2. Vu qu'on a changé de techno, autant que le profil du poste corresponde à ce que les gens vont faire une fois embauché: du Java, avec des outils et des librairies libres.

          Maintenant, bien sûr qu'on a déja des compétences, vu la base de code qu'on a déjà écrite: http://svn.nuxeo.org/

          Enfin, en ce qui concerne l'aspect commercial, ne t'inquiète pas: ce switch a été décidé en partie pour répondre aux attentes des clients et des partenaires.

          S.

          --
          Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

          "There's no such thing as can't. You always have a choice." - Ken Gor

          • [^] # Re: Bonne nouvelle ?

            Posté par (page perso) . Évalué à -1.

            Merci de pointer vers notre annonce de recrutement, ca nous aidera peut-être à trouver les bonnes personnes.


            Tant mieux. Je pense que le battage se fait très bien sans moi.

            1. Nuxeo cherche à recruter, parce que Nuxeo est une boite en croissance et que pour faire tous les projets qu'on a à faire (sans parler de tous ceux qu'on va arriver à vrendre plus facilement parce qu'on est passé à Java), on a besoin de développeurs.


            J'adore cette façon d'éluder les questions. J'imagine que le changement de techno a dûr être difficile et que cela n'a pas dû être une mince affaire de convaincre les développeurs de cps d'abandonner python au profit de java. Mais si je comprends bien tout ce qu'on lit sur la page d'accueil du projet cps, c'est du vent ? La plateforme zope robuste ? Non, on va utiliser jboss! etc

            2. Vu qu'on a changé de techno, autant que le profil du poste corresponde à ce que les gens vont faire une fois embauché: du Java, avec des outils et des librairies libres.


            java est tout sauf libre. Je veux bien admettre à la rigueur qu'il soit opensource mais absolument pas libre. Ne parlons même pas de la machine virtuelle.

            Enfin, en ce qui concerne l'aspect commercial, ne t'inquiète pas: ce switch a été décidé en partie pour répondre aux attentes des clients et des partenaires.


            On va finir par y arriver! C'est ce que je disais dans mon message un peu plus haut. java c'est plus vendeur que python auprès du décideur pressé. Après on mets ses convictions de côté.

            Je ne voudrais pas être le premier client qui va essuyer les plâtres du passage de cps à nuxeo5.

            Je ne suis pas décideur mais un simple développeur qui commençait à lorgner du côté de cps. Je vais passer mon chemin.
            • [^] # Re: Bonne nouvelle ?

              Posté par (page perso) . Évalué à 0.

              java est tout sauf libre. Je veux bien admettre à la rigueur qu'il soit opensource mais absolument pas libre. Ne parlons même pas de la machine virtuelle.
              Oué d'ailleur on s'est bien connu, la FSF et ses softs GNU sont pas du tout libre, "à peine" open-source, comme le compilateur Java GCJ ou le projet de bibliothèque de classes GnuClassPath.
              D'ailleur la licence qu'ils utilisent est pas libre du tout, et ca a contaminé pleins de projets autour de Java, ces traitres étant cités dans cette dépêche. Certains ont même fait l'affrond d'utiliser une licence encore moins libre du type MIT/X11, vous vous rendez compte ?
              Java c'est vraiment pas libre.
            • [^] # Re: Bonne nouvelle ?

              Posté par (page perso) . Évalué à 9.

              "Tu imagines": c'est ca le pb, tu imagines des trucs mais bon c'est pas comme ca en vrai.

              "Java est tout sauf libre": je ne parle pas dans ma phrase de Java (relis ce que j'ai écris), mais des outils et des librairies libres. Je parle d'Eclipse, de Jackrabbit, de Lucene, de JBoss, de jPBM, etc. Alors ne me fais pas dire ce que je n'ai pas dit STP.

              "Java est plus vendeur que Python": ben oui, c'est ca l'objet (outre les aspects technologiques) du changement. Ca correspond mieux aux schémas directeurs dans pas mal de boites ou de ministères. C'est plus facile à faire accepter dans les SSII. C'est plus facile à intégrer dans les SI. Y a plus de librairies libres disponibles. Etc. Faire le meilleur logiciel du monde, si personne ne l'utilise, ca ne sert à rien. Donc c'est important d'utiliser des technologies que les gens acceptent facilement.

              "Après on mets ses convictions de côté": Avoir des convictions, c'est bien, mais il faut aussi qu'elles soient conformes à la réalité. Et la réalité change, alors les convictions doivent aussi s'adapter. Le choix de Zope était pertinent pour nous en 2000, il ne l'est plus en 2006.

              "Je ne suis pas décideur": je suis sûr que tu prends des décisions, la preuve. Je suis désolé que notre nouvelle orientation ne te convienne pas, notre objectif est bien qu'il y a des développeurs qui soient convaincus de la pertinence de notre choix. Mais si ce n'est pas toi, il y en aura d'autres.

              Donc sans rancune, et on se donne RDV quand on aura les première versions "montrables" (i.e. d'ici un mois).

              S.

              --
              Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

              "There's no such thing as can't. You always have a choice." - Ken Gor

              • [^] # Re: Bonne nouvelle ?

                Posté par (page perso) . Évalué à -10.

                Vous avez bien raison.
                Je vous propose de faire un patch du kernel linux. Le passer en java serait aussi plus vendeur :)
              • [^] # Re: Bonne nouvelle ?

                Posté par . Évalué à 2.

                Bonjour,
                Perso je comprends tout à fait le choix de Nuxeo.
                Ceci ne m'empêche pas de pleurer la perte d'une entreprise qui utilisait Python avec brio.
                Je suis développeur Java et j'aimerais plutôt trouver un job python tellement je trouve ce language (et sa dynamique de communauté) plus attrayant.
                Je comprends bien que vous aviez vraiment atteint des limittes de ZODB mais sur ce point, il suffisait d'utiliser une base SQL plutôt que ZODB pour certains objets.
                Je suis peiné d'une décision qui me semble avant tout marketing En effet j'ai vraiment l'impression qu'il faut surtout rassurer les décideurs des administrations qui on fait le choix de java et qui n'ont pas confiance dans leur développeurs pour intégrer des choses nouvelles.
            • [^] # Re: Bonne nouvelle ?

              Posté par (page perso) . Évalué à 2.

              java est tout sauf libre. Je veux bien admettre à la rigueur qu'il soit opensource mais absolument pas libre. Ne parlons même pas de la machine virtuelle.


              Erreur, la JVM est elle aussi "open source" (sinon il n'y aurait pas de JVM sous BSD) mais simplement elles ne sont pas distribuées avec le JDK.
              • [^] # Re: Bonne nouvelle ?

                Posté par . Évalué à 1.

                Je connais asser mal le milieu Java et ta remarque me laisse perplexe, je
                comprends pas grand chose avec les licences Java :
                Les outils comme la JVM, Jboss, gcj & co peuvent être libres et distribués
                librement, mais pas le JDK, c'est le kit de dev ? Quand tu développes en Java
                il te faut forcément un JDK, non ? Pour écrire du code Java il faut une licence ?
            • [^] # Re: Bonne nouvelle ?

              Posté par . Évalué à 10.

              > java est tout sauf libre.

              Quel java ? Celui de Sun ?
              Effectivement il n'est pas libre.
              Celui dans gcj/etc ?
              Ils sont libres.

              Pour indication, gcj/etc est dans par Fedora Core et RHEL (et sûrement beaucoup d'autre). Or le responsable juridique de Fedora Core et RHEL est Red Hat ! Ce dernier est le concurrent le plus sérieux de Solaris (Red Hat pique plein de clients à Solaris).
              Afin après l'achat de JBoss par Red Hat, Red Hat commence à se faire pas mal de pognon avec java :
              http://www.redhat.com/about/news/prarchive/2006/earnings_200(...) :
              JBoss-related revenue of $7 million


              S'il y avait le moindre problème avec gcj/etc :
              - Red Hat retirerait gcj/etc.
              - Sun attaquerait Red Hat
            • [^] # Re: Bonne nouvelle ?

              Posté par (page perso) . Évalué à 10.

              java est tout sauf libre. Je veux bien admettre à la rigueur qu'il soit opensource mais absolument pas libre. Ne parlons même pas de la machine virtuelle.

              C'est vraiment pénible de lire encore et toujours de telles stupidités. Je vais encore faire ma pub, mais je te conseille vivement de lire mon article paru dans linux mag il y a deux ans (http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf ) tu comprendras peut être que :
              1) on peut implémenter Java (jre+jdk) sous une licence libre et c'est ce que font les projets classpath, harmony, kaffe, etc.
              2) open source ne devrait être utilisé que dans le sens des inventeurs du terme, l'OSI. Dans ce cas il veut dire libre.

              Enfin, Sun a annoncé officiellement le passage intégral de son implémentation de Java en open source (cf http://community.java.net/jdk/opensource/ ). On devrait voir les premiers morceaux en octobre. Si tu veux des détails, je te suggère de lire le prochain numéro de linux mag (la semaine prochaine) pour mon nouvel article sur Java et .NET (et pour tous les autres articles du mag, bien sûr).
        • [^] # Re: Bonne nouvelle ?

          Posté par (page perso) . Évalué à 7.

          De plus, nuxeo certfie à ses clients depuis des années que zope/python sont des technologies robustes éprouvées, maitrisées en interne... Il va falloir embaucher un super commercial pour expliquer au client pourquoi la technologie d'hier ne sera plus celle utilisée demain
          Si t'as lu tout l'article, tu constateras que c'est aussi une demande des clients ce changement technologique : pour beaucoup d'entre eux il est difficile d'avoir des personnes compétentes/acteurs compétents en Python. Même si la techno est robuste et éprouvée, faut pas perdre de vue tout l'ecosystème qui gravite autour. Et forcé de constater que Java est beaucoup plus garni dans ce domaine.
          En fait c'est un problème bien connu de dépendance envers des solutions "exotiques" qui obligent l'utilisateur/client à être dépendant d'un nombre réduit d'acteurs.
          • [^] # Re: Bonne nouvelle ?

            Posté par . Évalué à 10.

            je confirme que mon supérieur et moi même on a été au début supris de l'annonce car nuxeo était un gros contributeur de zope.


            mais cps 4 annonçait déjà l'usage de java

            et oui, en tant qu'admin systeme qui fera du développement autour de nuxeo (car on utilise déjà cps ) le passage à Java est très intéressant.

            Peu de gens ont des compétences zope. Nous avons beaucoup d'outils autour de nous pour travailler avec java. Il nous sera plus facile de nous mettre au développement java que zope.

            alors bien sur il y a foule de terme techniques commençant en J et pour certains cela semble être du marketing vide. Java est très standardisé, à tous les niveaux : api, déploiement, modélisation de l'application, etc. On a de nombreux outils qui sont pour la plupart mature. De plus , je ne pense pas qu'on puisse considérer Lucene, les projets apache et autre Jboss comme des projets vides à la "startup". Ils existent depuis des années et sont utilisés dans de nombreuses entreprises.

            pour le déploiement d'applications web, franchement, où se situe zope/python ?
            entre j2ee/java et apache/php ? qu'apporte-t-il concrètement ? Java est complexe, java est lourd à mettre en oeuvre, mais zope ne l'était pas moins. et au moins on profite de la GALAXIE de développements autour de Java. Java est déjà pérennisé. Les gens sont formés à Java. Il n'y a pas de monopole de technologies Java, on peut contacter je ne sais combien de SSII pour travailler sur java. du point de vue d'entreprise c'est très dur de convaincre avec une autre technologie.

            Quand j'ai commencé à m'intéresser à la gestion documentaire et à CPS, zope/python m'a clairement _rebuté_.
            Je suis obligé de me farcir ZopeDB etc pour pratiquement UN seul logiciel (cps., qui va me parler d'autre chose ? plone ? ). Java au contraire je le retrouve dans je ne sais plus combien des autres outils d'entreprise.

            je peux comprendre python pour créer des applications Gnomes et du développement rapide, mais en tant que langage pour applications d'entreprises je ne vois pas .
            Zope/python n'est pas plus rapide, n'est pas plus simple, il a moins d'outils dédiés à son développement que java, à moins d'entreprises qui contribuent à son amélioration, est + obscure que java, moins documenté, moins de composants s'interfaçant avec, etc.


            la seule tâche à java c'est que sun n'a pas encore mis la jvm sous une licence libre qui autorise sa distribution dans tous les linux.


            "Prétendre que tout le monde gagne à cette uniformisation c'est faux : comme avec Microsoft ce sont des centaines de solutions technologiques alternatives telles que Zope qui risquent de disparaître à long terme."
            c'est le marché et des gens comme moi qui font que cela disparaisse ou non.

            S'il y a toujours une demande zope, zope continuera.

            Linux, personne ne l'attendait, dans un monde tout windows, mais il y avait un Besoin, une NECESSITE, et ca a pris son temps mais ca n'a fait que grandir et mûrir.


            ici, nous ne sommes pas dans une bataille de "libre contre propriétaire".
            mais plutôt dans une nostalgie, où l'on voit qu'une technologie est très implantée et victorieuse et où le challenger, de qualité certes, ne décolle pas.

            peut être un jour nous verrons pareil avec Ruby et Php.
            • [^] # Re: Bonne nouvelle ?

              Posté par (page perso) . Évalué à 0.

              Michel a bien résumé ce que j'ai en vain essayer de dire:

              "Prétendre que tout le monde gagne à cette uniformisation c'est faux : comme avec Microsoft ce sont des centaines de solutions technologiques alternatives telles que Zope qui risquent de disparaître à long terme."
              c'est le marché et des gens comme moi qui font que cela disparaisse ou non.


              Je suis juste déçu par la direction que prend nuxeo.

              Après si un jour il faut faire du web avec un serveur d'application tournant avec java, pourquoi devrai-je utiliser un nouveau produit (nuxeo5) et pas un produit ayant fait ses preuves tel que documentum par exemple ? C'est une question très sérieuse. Pourquoi nuxeo qui change de techno comme de chemise plutôt qu'une autre société qui a fait le "pari" de java dès le départ ?
              • [^] # Re: Bonne nouvelle ?

                Posté par . Évalué à 3.

                Parce que Documentum n'a pas du tout fait le pari de Java dès le départ? Parce que Nuxeo5 offre plus d'avantages que Documentum? Parce qu'il est meilleurs techniquement, fonctionnellement et moins cher à mettre en oeuvre?

                Pour info, Documentum c'est du bon vieux C avec une architecture qui date de 15 ans...

                Bonne soirée,

                EB.
                • [^] # Re: Bonne nouvelle ?

                  Posté par . Évalué à 1.

                  Et pour avoir discuté avec des gens qui ont utilisé cet outil, Documentuum, c'est un parcours du combattant, entre bugs et manques de fonctionnalités... un mot en 5 lettres me vient à l'esprit
              • [^] # Re: Bonne nouvelle ?

                Posté par (page perso) . Évalué à 10.

                Pourquoi nuxeo qui change de techno comme de chemise

                Pourquoi tous les commentateurs disent-ils que Nuxeo change de techno comme de chemise ?! Parce qu'il n'y a pas eu de pré-annonce et de plan média auparavant ?

                Garder quelque chose six ans et mettre plus de six mois à se décider à en changer, j'appelle pas ça changer de chemise. Ou alors, nous n'avons pas les mêmes valeurs. Moi c'est une fois par jour, et ça me prend une dizaine de secondes pour choisir quelle chemise mettre.
      • [^] # Re: Bonne nouvelle ?

        Posté par . Évalué à 6.

        Je regrette que pour faire la promotion d'un bon produit Nuxeo se sente obligé de faire un inventaire à la Prévert de composants J2EE. Ca n'impressionne plus guère et ça éveille surtout les soupçons de ceux qui ont le spectre de la bulle internet en mémoire.

        Pour ce qui est de Java/J2EE, je pense que le consortium ObjectWeb pèse de tout son poids idéologique...
        • [^] # Re: Bonne nouvelle ?

          Posté par (page perso) . Évalué à 3.

          "Inventaire à la Prévert": comme je l'ai écrit dans d'autres commentaires, on est dans le cadre d'une architecture à base de composants. Il est important de bien identifier chacun des composants importants qui sont utilisés dans l'architecture, et aussi, et peut-être surtout, sur quelles spécifications standards ils s'appuient, lorsque c'est le cas (ex: JCR, aka JSR-170, JSF, aka JSR-252, etc.).

          "je pense que le consortium ObjectWeb pèse de tout son poids idéologique": je pense surtout que c'est "le marché" qui pèse en faveur de Java EE. Le consortium ObjecWeb participe à son niveau à l'écosystème Java libre, comme la Fondation Apache, la fondation Eclipse, JBoss, et bien d'autres, petits ou grands. Il s'agit d'un mouvement de fond, modelé par de nombreux acteurs, aussi bien côté vendeurs que côté utilisateurs, et dans lequel l'excellence technique est un facteur important, mais aussi la capacité à susciter l'adhésions des autres acteurs autour d'une technologie donnée.

          S.

          --
          Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

          "There's no such thing as can't. You always have a choice." - Ken Gor

          • [^] # Re: Bonne nouvelle ?

            Posté par . Évalué à 7.

            "Il s'agit d'un mouvement de fond, modelé par de nombreux acteurs, aussi bien côté vendeurs que côté utilisateurs, et dans lequel l'excellence technique est un facteur important, mais aussi la capacité à susciter l'adhésions des autres acteurs autour d'une technologie donnée." Stop Stefane. La dialectique science-pipo ça ne m'impressionne plus, et pour cause. Ton "mouvement de fond" est assez simple à décortiquer : - pour les développeurs c'est augmenter la probabilité de trouver un emploi en ne maîtrisant qu'un language : Java - pour les entreprises c'est limiter les risques de dérapages salariaux en ne gérant qu'une population homogène d'informaticiens : des développeurs Java. D'où Ie fait que tes clients te poussent à faire du Java. Prétendre que tout le monde gagne à cette uniformisation c'est faux : comme avec Microsoft ce sont des centaines de solutions technologiques alternatives telles que Zope qui risquent de disparaître à long terme. Maintenant je ne t'en veux pas : tu dois avant tout assurer la pérennité de ton entreprise et il est clair que dans ce cadre porter CPS sous Java était une nécessité. Au passage bravo à Nuxeo pour sa créativité et ses talents.
            • [^] # Re: Bonne nouvelle ?

              Posté par . Évalué à -1.

              "Java - pour les entreprises c'est limiter les risques de dérapages salariaux "

              mmmm As tu vu le salaire moyen des développeurs Java ?
              Je peux te dire que si tu veux éviter les dérapages salariaux, mieux vaut chercher des développeurs windev ou php.

              De plus, il y a quand même une sacré pénurie de ce type de développeur....

              http://about.me/straumat

              • [^] # Re: Bonne nouvelle ?

                Posté par . Évalué à 4.

                Je peux te dire que si tu veux éviter les dérapages salariaux, mieux vaut chercher des développeurs windev ou php.

                Tout dépend ce que tu entends par "dérapages salariaux". Si c'est rapport au salaire, il est clair qu'un bon dév Java te coutera plus cher qu'un des sus-nommés.

                Maintenant, si tu cherches un développeur qui sait coder, mieux vaut éviter le développeur Windev ("hein? c'est quoi un algorithme?" - authentique) et le codeur PHP ("gruiiiik!"). BIen entendu, ça reste statistique, mais c'est des langages dont l'écosystème est rempli de boulets incompétents qui auraient mieux fait de rester dans l'agriculture (pour Windev) et de djeunz nourris au web "de zéro" (pun intended) plus habitués à faire des sites vite fait pour le groupe de rock des potes qu'à concevoir une application complexe.

                Après, faut pas me faire dire ce que j'ai pas dit : je doute qu'il existe un langage dont la communauté soit exemplaire. Je suis même plutôt convaincu qu'un développeur ayant plusieurs cordes à son arc (et si possible des cordes assez éloignées, pas trop "C/C++/C#/Java", si vous voyez ce que je veux dire) sera largement plus adaptable. Après, évidemment, si ce qu'on veut c'est de le rentabilité à court terme et un renouvellement à moyen/long terme... autant prendre du jetable ("Écoute Jean-Guy, le Java ça paye plus cette année, faudrait voir à nous virer tous les petits gars du 3è et à les remplacer par des ingénieurs C#, ok?").
    • [^] # Re: Bonne nouvelle ?

      Posté par . Évalué à 5.

      Je pense qu'il suffit de tester Hibernate, EJB3, Spring, JUnit, JSF pour voir qu'il y a bien plus que du marketing... Rien que l'IOC et l'AOP devrait en épater plus d'un.

      http://about.me/straumat

    • [^] # Re: Bonne nouvelle ?

      Posté par . Évalué à -3.

      non. On passe d'un produit libre sur une plateforme libre à un produit libre sur le produit non libre de Sun. C'est dommage d'avoir travaillé en JEE5 au lieu de 2. Quel gâchi :/ En attendant que gcc et cp avancent ...
      • [^] # Re: Bonne nouvelle ?

        Posté par . Évalué à 1.

        VOUS ETES LOURD :)

        Sun est en train de libérer le JDK... vous pouvez pas attendre 3 à 6 mois ?

        http://about.me/straumat

        • [^] # Re: Bonne nouvelle ?

          Posté par (page perso) . Évalué à 5.

          Sun est en train de libérer le JDK...

          Depuis le temps qu'on en parle, ça finit par ressembler à l'Arlésienne... Ou à Duke Nukem.
          • [^] # Re: Bonne nouvelle ?

            Posté par . Évalué à 2.

            Mauvaise foi a l'etat pur, Sun va publier le JDK complet sous une licence opensource. Le processus est en cours, et ils regardent meme quel gestionnaire de SCM utiliser.

            Mais bon c'est tellement plus simple de faire du Java-bashing ...
  • # Pierre Tramo a frappé !

    Posté par . Évalué à 1.

    C'est le titre d'un journal qui parlait déjà de ce sujet hier: https://linuxfr.org/~account/22766.html
  • # Bonne nouvelle :)

    Posté par . Évalué à 4.

    Félicitations pour ce passage, c'est très intéressant !
    Perso, nous sommes passé de PHP, ASP, Delphi... à Java... et on a vu une nette amélioration en terme de qualité, temps de développements, réutilisation et performances.

    Pour information, cet avis est celui de ma société et n'est pas valable dans tous les cas, pour toutes les sociétés et toutes les applications :)

    http://about.me/straumat

    • [^] # Re: Bonne nouvelle :)

      Posté par (page perso) . Évalué à 3.

      Salut Stéphane,

      Ta société = SCUB (http://www.scub.net) ?

      Peut-être aura-t-on l'occasion de bosser ensemble un de ces jours ;)

      S.

      --
      Stefane Fermigier, PDG, Nuxeo -- http://www.nuxeo.com/

      "There's no such thing as can't. You always have a choice." - Ken Gor

      • [^] # Re: Bonne nouvelle :)

        Posté par . Évalué à 1.

        Oui Scub et ma société et j'en suis le dirigeant :)

        J'espère bien que l'on pourra bosser ensemble un jour !
        En tout cas, on va pouvoir proposer vos produits (et oui, avantage de Java, on pourra s'nterfacer facilement car nuxeo va respecter les standards).

        A bientôt j'espère :)

        http://about.me/straumat

  • # Harcèlement Marketeux

    Posté par . Évalué à -1.

    Alors là... Je ne sais pas combien de journaux on a eu droit sur le sujet. Bluffant...

    Est-ce que ce nouveau CPS tournera sur une VM libre??

    Parce qu'il faut le souligner, une VM proprio ou un OS proprio c'est la même chose.

    Je tiens à rappeler qu'il est possible de faire la même chose en beaucoup plus libre avec python/ruby/perl/php/C/C++ etc etc...
    Je vous encourage à être le plus libre possible dans vos choix de plateformes technologiques.
    • [^] # Re: Harcèlement Marketeux

      Posté par (page perso) . Évalué à 0.

      Merci pour ce gentil rapel moraliste.
      L'intégrisme te dit merci.
    • [^] # Re: Harcèlement Marketeux

      Posté par (page perso) . Évalué à 2.

      Je tiens à rappeler qu'il est possible de faire la même chose en beaucoup plus libre avec python/ruby/perl/php/C/C++ etc etc...
      Comme je l'ai précisé plus haut, tout dépend de quelle liberté tu parles. Pour beaucoup d'entreprise, ils s'en cognent d'être dépendant d'une VM proprio (souvent elle ne coûte rien ou presque). Ce qu'ils veulent comme liberté, c'est pouvoir choisir les acteurs avec lesquels ils vont travailler, faire jouer la concurrence, trouver des collaborateurs compétents dans la techno, etc.
      La liberté de choisir ne peut malheuresement pas être imposée dans une licence logicielle, seule une adoption massive par les acteurs du secteur informatique et la présence de nombreuses implémentations permet de garantir une certaine "liberté" de choix.
      C'est pour ca que maintenant je réfléchi à 2 fois quand je parle à un "décideur" sur les libertés qu'apporte certains logiciels libre, ca les fait doucement rire car pour eux c'est souvent synonyme de dépendance et d'enfermement avec un acteur compétent spécifique.
      • [^] # Re: Harcèlement Marketeux

        Posté par (page perso) . Évalué à 0.

        et surtout la liberté d'utiliser une architecture qui va supporter la montée en charge.
      • [^] # Re: Harcèlement Marketeux

        Posté par . Évalué à 4.

        c'est exactement ainsi qu'il faut me parler.

        Attention, je suis très convaincu par la GPL, par la nécessité du libre et aussi l'opensource; j'ai appris linux, freebsd, apache, etc à une époque où les gens s'en moquaient, mais avoir un logiciel "gpl" ne suffit pas pour "libérer" sa propre entreprise.


        alors, bien sur une technologie sous licence libre va favoriser l'éclosion d'une myriade de sociétés fournissant la dite technologie et on pourra les mettre en concurrence et au final tout le monde y gagne en indépendance, en liberté, en souplesse etc
        mais des fois y a des technologies certes "libre" mais que personne ne maîtrise. et vous êtes dépendants de la seule petite boîte ou petite communauté derrière et vous n'y gagnez rien (sauf à devoir devenir soit même contributeur. pas toutes les sociétés ont les raisons et possibilités de le faire).

        "C'est pour ca que maintenant je réfléchi à 2 fois quand je parle à un "décideur" sur les libertés qu'apporte certains logiciels libre, ca les fait doucement rire car pour eux c'est souvent synonyme de dépendance et d'enfermement avec un acteur compétent spécifique."

        Très vrai.
        c'est aussi pour cela que je privilégie dans le libre tout ce qui semble devenir "industriel" .

        la liberté pour une société doit se traduire en POSSIBILITE concrète et DISPONIBLE.
        pas seulement en "potentiel" d'une licence.
  • # Former des développeurs Python/Zope compétents

    Posté par . Évalué à 6.

    nos clients et nos partenaires nous ont rapporté avoir d'importantes difficultés à trouver ou former des développeurs Python/Zope compétents.

    On entend souvent ce discours comme quoi il manquerait de programmeurs python, avec ici une couche supplémentaire disant qu'ils sont difficiles à former. Je trouve ça vraiment très bizarre car python est vraiment un des langages les plus facile a apprendre, et spécialement au sein de Nuxeo il doit y avoir largement de quoi former les nouveaux arrivants (en interne ou pour des clients).

    Alors que la tendance actuelle est de plus en plus orienté langages de script, que ce soit chez MS avec ironpython ou chez Sun avec jython et jruby, est-ce que jython a été envisagé pour tirer partie du meilleur des deux mondes ?
    • [^] # Re: Former des développeurs Python/Zope compétents

      Posté par . Évalué à 4.

      Ce n'est pas si simple.
      N'oublie pas que tous les développeurs ne sont pas des adeptes du libre, loin loin de là. Beaucoup ne souhaite pas s'investir dans une technologie dont il n'ont jamais entendu parler.

      Aujourd'hui il reste plus facile de trouver un développeur java qu'un développeur python.

      Et même si on en trouve un il reste la peur de se retrouver seul utilisateur d'une technologie que tout le monde a fini par abandonner (qui se souvient de Pacbase...)
      • [^] # Re: Former des développeurs Python/Zope compétents

        Posté par . Évalué à 3.

        Et même si on en trouve un il reste la peur de se retrouver seul utilisateur d'une technologie que tout le monde a fini par abandonner (qui se souvient de Pacbase...)


        Moi ! J'ai été formé à Pacbase il y a un an et demi et depuis je n'ai pas arrêté de coder avec (projet mis en prod il y a quelques jours).

        Pacbase est toujours trés utilisé dans les banques et les assurances françaises (qui refusent que IBM en cesse le support d'ailleurs). La seule chose qui a changé c'est qu'on ne fait plus d'écrans 3270 mais qu'à la place on a un pont permettant d'appeler le site central depuis une appli J2EE.


        J2EE que par ailleurs je trouve immonde, enfin surtout les jsp. Je n'aime pas du tout cette façon de faire de mélanger dans une seule page de code plusieurs langages (html et java en l'occurrence, voire javascript en plus bien souvent - mais c'est pareil avec php d'ailleurs).
        • [^] # Re: Former des développeurs Python/Zope compétents

          Posté par (page perso) . Évalué à 3.

          Le problème dont tu parles à propos des JSP (mélange de genres) est connu depuis de nombreuses années et de très nombreux frameworks, API, et standards ont pour objectif de gérer ce problème en minimisant voire annulant la présence de code Java et JavaScript dans les JSP.

          Seul un vraiment mauvais programmeur te fera un mix ingérable de HTML et Java dans une JSP.
          • [^] # Re: Former des développeurs Python/Zope compétents

            Posté par . Évalué à 2.

            C'est vrai, et à chaque fois il faut se retaper l'étude du framework en question, différent d'un projet à un autre, avant de pouvoir pondre une page.
            De ce coté là je préfère nettement l'approche des templates de turbogears (kid) ou rubyonrails: tu connais le langage (python ou ruby) => tu peux écrire les templates dans ce langage
            • [^] # Re: Former des développeurs Python/Zope compétents

              Posté par (page perso) . Évalué à 4.

              Excuse moi mais c'est stupide ce que tu dis ...

              Déjà, avec la JSTL (la librairie de tag standard des JSP), tu ne dois quasiment plus mettre de code Java dans les JSP. A côté de ces tags, la plupart des frameworks utilisent des JSP avec quelques tags supplémentaires (Struts, Spring MVC, ...).

              Ensuite, quel que soit le framework, tu dois quand même le comprendre pour l'utiliser, qu'elle que soit le langage. Et tu changes rarement de framework 10x par jour.

              Je ne vois pas en quoi les templates de RoR (que je connais un peu) diffère de Java : tu connais le langage (Java) => tu peux écrire les templates dans ce langage
              • [^] # Re: Former des développeurs Python/Zope compétents

                Posté par . Évalué à 2.

                Excuse moi mais c'est stupide ce que tu dis ...

                Merci, ça fait toujours plaisir

                Déjà, avec la JSTL (la librairie de tag standard des JSP), tu ne dois quasiment plus mettre de code Java dans les JSP. A côté de ces tags, la plupart des frameworks utilisent des JSP avec quelques tags supplémentaires (Struts, Spring MVC, ...).

                Je ne dis pas qu'il faut mettre du java dans ses JSP, d'ailleurs je ne le fais pas.
                C'est justement les taglib que je n'aime pas: cette manie de faire de la programmation en XML, désolé mais ça me saoule. D'ailleurs rien à vois mais ça m'y fait penser: ant est pas mal non plus à ce niveau là.

                Ensuite, quel que soit le framework, tu dois quand même le comprendre pour l'utiliser, qu'elle que soit le langage. Et tu changes rarement de framework 10x par jour.

                Ben des fois tu change de projet, de client ou tu bosses sur plusieurs en même temps.


                Je ne vois pas en quoi les templates de RoR (que je connais un peu) diffère de Java : tu connais le langage (Java) => tu peux écrire les templates dans ce langage

                Ce que j'aime pas avec les jsp, c'est qu'il te faut connaitre tout un tas de taglib, dont les mots clé sont evidemment différent de ceux de java, et la sémantique pas toujours très claire. Et accessoirement il faut aussi connaitre EL.

                Regarde l'exemple fourni sur le site de KID :
                http://www.kid-templating.org/trac/wiki/KidExamples

                C'est quoi dans les attributs? ben c'est du python: j'ai rien de plus à savoir. pas de langage pour les expression, ou autre taglib.
      • [^] # Re: Former des développeurs Python/Zope compétents

        Posté par . Évalué à 1.

        J'ai fais l'effort d'apprendre python, car ce langage m'intéressait, notamment pour mes projets universitaire, il y a 5-6 ans maintenant.

        Mais je n'ai jamais pu travaillé en python en entretreprise, car tout le monde ne jure que par Java, et je trouve que c'est dommage.
        Donc je fait du java, comme tout le monde, et souvent je peste...
        • [^] # Re: Former des développeurs Python/Zope compétents

          Posté par (page perso) . Évalué à 9.

          Just do java and be right: it's more than time to come out and be proud !

          We all have to concentrate and favour the industrie's choices in order to build the magnificent world of tommorrow !

          Let me also urge everybody to comment in english, because this is the only free language.
          Of course french has qualities, and is also technically free, but not economically: so few people can anderstand anything but english that we might restrict ourselves to a very little shortlist of potential commenters if we don't switch asap.
        • [^] # Re: Former des développeurs Python/Zope compétents

          Posté par . Évalué à 1.

          Pareil, je ferais volontier du Python mais je ne vois rien sur Lyon autour de ça.
          • [^] # Re: Former des développeurs Python/Zope compétents

            Posté par . Évalué à 2.

            Y a quelques mois il y avait un poste très intéressant sur Lyon chez Fluendo... Et apparement ils avaient beaucoup de mal a trouver des compétences en Python. C'est un cercle vicieux, pas de compétences donc pas d'investissement etc.

            Le mieux c'est de sortir de ce vislard de cercle et se mettre à son compte, on peut faire du Python toute la journée :-).
            • [^] # Re: Former des développeurs Python/Zope compétents

              Posté par . Évalué à 2.


              Ouip à l'époque j'ai postulé mais mon profil n'était pas celui recherché (trop d'études, trop d'expérience). J'étais prêt à négocier mais il ne m'en ont pas laissé le temps. Après un échange par mail il ne m'ont plus jamais répondu.
    • [^] # Re: Former des développeurs Python/Zope compétents

      Posté par . Évalué à 2.

      Il faut sortir la tête du sable: Python est un des langages les plus facile à maîtriser.
      De plus, les langages (je devrais dire plateformes) reposant sur une compilation de code statique pour ensuite tourner sur des VMs, et bien c'est pas très futé (j'aurais tendance à être beaucoup plus cassant...).
      Ces derniers cumulent les désavantages des langages compilés nativement, c'est à dire bien plus complexes à maîtriser que les langages dynamiques comme python (et les autres!), ajoutés des désavantages des langages dynamiques, comme tourner sur une VM (parfois prioprio... donc encore pire... ça ne vaut gère mieux qu'un OS proprio... mais je me répète). Pour enfoncé le clou, ils ont inventé la compilation JIT, qui est un aveu même de la lenteur d'exécution de ces langages: A quoi bon avoir la complexité et la lourdeur d'une VM (allez proprio pendant qu'on y est) avec une compilation JIT, si c'est pour tourner en natif?? C'est particulièrement c... ahem... disons plutôt: "It's not a limitation... it's a feature!"

      La technique est simple: tu prends une boîte qui bosse pas avec tes technos et qui a une certaine crédibilité dans un milieu où il y a des dèvs/geeks/entousiates qui roxent. Tu passes "un partenariat" ou tu mets un gros paquet de pognon sur la table avec le deal suivant: "vous laissez tomber vos technos et passer aux nôtres en hurlant que les nôtres sont plusse meilleures". Bin voilà... le tour est joué! Personnellement ça m'éc½ure...
      • [^] # Re: Former des développeurs Python/Zope compétents

        Posté par (page perso) . Évalué à 8.

        Moué alors on peut très bien prendre tous tes arguments et les tourner dans l'autre sens :
        "Ces derniers cumulent les désavantages des langages compilés nativement,"
        Pour moi ils tirent justement des langages compilés les atouts : à savoir la typage statique (souvent propre aux langages compilés même si pas toujours vrai), et justement la possibilité de compiler le code de la VM en code natif, donc avec des performances décentes.
        "joutés des désavantages des langages dynamiques, comme tourner sur une VM "
        C'est encore un avantage : abstraction de la plateforme matérielle, ce qui est le but premier, sans pour autant sacrifier les perfomances (le problème des perfs vient plutôt de la présence services ajoutés : gestion mémoire, sécurité, isolation, etc.).

        "A quoi bon avoir la complexité et la lourdeur d'une VM (allez proprio pendant qu'on y est) avec une compilation JIT, si c'est pour tourner en natif"
        Parcque justement le jeu d'instruction d'une VM est plus simple (et non plus complexe) car de plus haut niveau qu'un jeu d'instruction assembleur. Le compilateur JIT n'est pas un aveu de lenteur puisqu'il fait partie intégrante de la solution. Ce qui compte c'est le résultat : c'est du code machine qui s'exécute, on ne sacrifie pas la portabilité, pas trop les perfs, on garde du code de haut niveau, avec la possibilité d'y adjoindre de nombreux services qui participent à la qualité du code : sécurité, gestion mémoire, introspection, etc.

        "It's not a limitation... it's a feature!"
        Exactement, elles ont été conçu pour ca, et non l'inverse : le code machine n'offre pas la possibilité d'adjoindre tous les services que j'ai cité : il faut proposer un modèle plus "restreind" et de plus haut niveau : une machine virtuelle.

        Bin voilà... le tour est joué! Personnellement ça m'éc½ure...
        Peut être que le jour où tu participeras au développement d'une grosse solution logicielle de plusieurs dizaines de milliers de lignes de code, tu apprécieras tout les services de ces plateformes, qui n'ont d'autre objectif que de te rendre plus productifs et donc globalement plus agréable à utiliser.
        • [^] # Re: Former des développeurs Python/Zope compétents

          Posté par . Évalué à 0.

          Pour moi ils tirent justement des langages compilés les atouts : à savoir la typage statique (souvent propre aux langages compilés même si pas toujours vrai), et justement la possibilité de compiler le code de la VM en code natif, donc avec des performances décentes.


          Effectivement, ce que tu avances c'est que ce genre de langage n'apporte rien de significatif par rapport aux langages compilés nativement. Par contre ils ont l'immense désavantage de dépendre d'une VM lourde et complexe (souvent proprio d'ailleurs).

          Parcque justement le jeu d'instruction d'une VM est plus simple (et non plus complexe) car de plus haut niveau qu'un jeu d'instruction assembleur. Le compilateur JIT n'est pas un aveu de lenteur puisqu'il fait partie intégrante de la solution. Ce qui compte c'est le résultat : c'est du code machine qui s'exécute, on ne sacrifie pas la portabilité, pas trop les perfs, on garde du code de haut niveau, avec la possibilité d'y adjoindre de nombreux services qui participent à la qualité du code : sécurité, gestion mémoire, introspection, etc.


          De ce que j'ai lu des jeux d'instructions des VMs est beaucoup plus proche des services offerts par un OS/bibliothèques de base que d'un jeu d'instructions assembleurs.
          C'est pour cela que je dis qu'une VM proprio ne vaut guère plus qu'un OS proprio.
          Aujourd'hui avec l'offre des bibliothèques du libre on tourne sur plus de plateformes que les VMs SANS dépendre d'une VM. De plus la portabilité n'est pas l'exclusivité des VMs...

          Au final, ces langages n'apportent rien de significatif par rapport à ce qu'offre le vrai libre: C/C++/python/ruby/perl/php etc. Je dis le vrai libre car ces langages ressemblent plus à des putch marketeux sur l'informatique. Ils ne sont pas révolutionnaires, même plutôt maladroits pour les raisons que j'ai évoquées précédement.

          Peut être que le jour où tu participeras au développement d'une grosse solution logicielle de plusieurs dizaines de milliers de lignes de code, tu apprécieras tout les services de ces plateformes, qui n'ont d'autre objectif que de te rendre plus productifs et donc globalement plus agréable à utiliser.


          Outres les attaques personnelles à coup de "j'ai la plus grosse", j'apprécie énormément tous les services que m'offrent les bibliothèques du libre d'une portabilité sans éguales qui sont un véritable plaisir à utiliser et qui me rendent plus productifs sans avoir à dépendre de technologies lourdes ,complexes, maladroites et au final inutiles dont l'indépendance est très discutable.
          • [^] # Re: Former des développeurs Python/Zope compétents

            Posté par (page perso) . Évalué à 5.

            Effectivement, ce que tu avances c'est que ce genre de langage n'apporte rien de significatif par rapport aux langages compilés nativement.
            Tu fais exprès ou quoi ? La portabilité binaire c'est pas significatif ? Tous les services que j'ai décris c'est pas significatif ? La sécurité c'est pas significatif ?

            Par contre ils ont l'immense désavantage de dépendre d'une VM lourde et complexe
            T'utilises les adjectifs qui t'intéresse sans rien démontrer, sans un cas c'est "pas significatif", dans l'autre c'est "immense". Alors montre moi les "immenses" désaventages d'une VM pour des plateformes de type Java/.NET.

            C'est pour cela que je dis qu'une VM proprio ne vaut guère plus qu'un OS proprio.
            On s'en tape, on est sur LinuxFR, et on parle de logiciels libres, alors permet moi de ne considérer que les VM libres. D'ailleur au même titre qu'il y a des VM proprio il y a des compilos pour des langages "compilés en natif" qui sont tout aussi proprio. Je vois vraiment pas où tu veux en venir.

            De ce que j'ai lu des jeux d'instructions des VMs est beaucoup plus proche des services offerts par un OS/bibliothèques de base que d'un jeu d'instructions assembleurs.
            Bravo ! Tu viens de trouver un autre avantage largement significatif des VM : l'indépendance vis-à-vis de l'OS !

            De plus la portabilité n'est pas l'exclusivité des VMs...
            Euh, la portabilité binaire en code natif je demande à voir... A moins de t'amuser à faire des universalbinaries comme Apple, qui multiplie par 2 la taille de ton code et qui te demande du travail en amont, désolé, je vois pas.

            Au final, ces langages n'apportent rien de significatif par rapport à ce qu'offre le vrai libre: C/C++/python/ruby/perl/php etc.
            Oué, y'a le vrai libre et le faux libre. C'est vraiment n'importe quoi ton raisonnement. Tu cherches des arguments techniques complètement bidons pour justifier au fond une préférence éthique envers les LL.

            Tu ferais bien de te poser une question : pourquoi n'y a-t-il pas d'équivalent avec une techno libre (une vraie comme tu dis) à J2EE ? Parcque les langages interprétés de type Python&Co n'ont pas été conçu pour ca, et les langages natifs de type C/C++ le sont encore moins.

            Ils ne sont pas révolutionnaires, même plutôt maladroits pour les raisons que j'ai évoquées précédement.
            Evidemment qu'ils ne sont pas révolutionnaire, mais ce sont des évolutions non négligeable.
            • [^] # Re: Former des développeurs Python/Zope compétents

              Posté par . Évalué à -4.

              Tu fais exprès ou quoi ? La portabilité binaire c'est pas significatif ? Tous les services que j'ai décris c'est pas significatif ? La sécurité c'est pas significatif ?
              Je passe outre une fois de plus sur le début de tes propos. La portabilité binaire? Sur des logiciels libres donc open source? Allons un peu de sérieux. A quoi sert la portabilité binaire avec des logiciels open source? Allez... on va dire quasiment à rien.
              Tous les services que tu décris et la "sécurité" (très à la mode) ne sont en rien l'exclusivité de ces VMs. C/C++/ruby/python/perl/php offrent la même gamme de services, d'ailleurs souvent ses services sont des librairies en commun à toutes ces plateformes et langages.
              T'utilises les adjectifs qui t'intéresse sans rien démontrer, sans un cas c'est "pas significatif", dans l'autre c'est "immense". Alors montre moi les "immenses" désaventages d'une VM pour des plateformes de type Java/.NET.
              Quand un composant logiciel qui fait des milliers de lignes de codes, et qu'il ne m'apporte rien de significatif et bien pour moi c'est un immense désaventage.
              En fait, il faut plutôt retourner la question: qu'est-ce que m'apporte l'utilisation d'une VM (dont l'indépendance est très discutable en plus) dans le monde libre/open source pour des langages non dynamiques?
              Euh, la portabilité binaire en code natif je demande à voir... A moins de t'amuser à faire des universalbinaries comme Apple, qui multiplie par 2 la taille de ton code et qui te demande du travail en amont, désolé, je vois pas.
              Bof la portabilité binaire dans le monde du libre/open source. Pas la peine de revenir dessus.
              Bravo ! Tu viens de trouver un autre avantage largement significatif des VM : l'indépendance vis-à-vis de l'OS !
              Je faisais remarquer que tu avais tord en comparant le byte code des VMs (que j'ai eu l'occasion de survoler) au jeu d'instructions des langages machines, mais qu'il fallait plutôt le comparer aux fonctions qu'offrent un OS/bibliothèques de base. Quand à l'indépendance de l'OS, une fois de plus, cela est loin d'être l'exclusivité de ces VMs.
              Oué, y'a le vrai libre et le faux libre. C'est vraiment n'importe quoi ton raisonnement. Tu cherches des arguments techniques complètement bidons pour justifier au fond une préférence éthique envers les LL.
              Pfff... ce que tu peux être aggressif. Là j'avoue que pour le libre, j'ai aussi une préférence éthique: comme le dit Linus, on est sur un modèle de travail collaboratif et on a prouvé qu'on pouvait faire du travail aussi bon voir meilleur que sur le modèle de la compétition acharnée. Bon, il faut relativisé dans le sens où ça n'est pas vrai pour tous les domaines. Ça serait trop beau! J'en suis tellement convaincu, qu'il est pour moi immorale de fournir mes compétences à tout autre type de logiciels. Attention tout n'est pas blanc ou noir et ma moralité n'est pas sans faille. C'est une question de feeling... en général je procède par élimination: si je ne peux pas utiliser un soft GPL/LGPL je regarde du côté des softs BSD et si toujours je n'y arrive pas je passe au propriétaire si il existe. Si vraiment je juge que la fonction du soft est importante pour mon travail et que l'existant ne me convient pas, je n'hésiterai pas une seconde à monter un projet GPL/LGPL.
              Tu ferais bien de te poser une question : pourquoi n'y a-t-il pas d'équivalent avec une techno libre (une vraie comme tu dis) à J2EE ? Parcque les langages interprétés de type Python&Co n'ont pas été conçu pour ca, et les langages natifs de type C/C++ le sont encore moins.
              Ça n'est pas vrai. L'ensemble des logiciels libres couvre largement ce que sait faire J2EE/.NET aussi bien ou mieux et sans les soucis d'indépendance de ces technologies vis-à-vis de leur entreprise mère respective.
              Evidemment qu'ils ne sont pas révolutionnaire, mais ce sont des évolutions non négligeable.
              reBof... évolution... non, plutôt pétard mouillé technique mais bombe H marketing. Les tirages de couverture entre Sun&Co et MS me gonfle. Heureusement, il y a une troisième voix.
              Personnellement, je ne perdrais pas mon temps avec ces technologies. Je suis très bien avec la qualité de l'offre libre/open source en C/C++/python/ruby/perl/php/lua/erlang/haskell/bash/openssl/gnutls/apache/
              cheerokee etc etc... je serais pas fute-fute de me lier à ces technos si discutables alors que j'ai une plétor technos sans ce soucis et parfaitement opérationnelles à porté d'un click sur le net.
              • [^] # Re: Former des développeurs Python/Zope compétents

                Posté par (page perso) . Évalué à 3.

                Allons un peu de sérieux. A quoi sert la portabilité binaire avec des logiciels open source? Allez... on va dire quasiment à rien.
                T'as déjà écrit une application répartie ? T'as déjà déployer une application sur plus d'une plateforme ?
                Monsieur le client, c'est open-source, démerdez-vous pour recompiler, et tant pis pour l'application répartie !
                T'as aucune idée de ce qu'apporte une plateforme de type Java/.NET, et ca se voit.

                C/C++/ruby/python/perl/php offrent la même gamme de services, d'ailleurs souvent ses services sont des librairies en commun à toutes ces plateformes et langages.
                Mais arrête d'affirmer n'importe quoi sans argumenter !
                Explique moi comment tu peux offrir en C/C++ les services d'isolation mémoire offert par les VM ? Montre moi le super service d'introspection qu'offre C/C++ histoire de rigoler un coup !

                et qu'il ne m'apporte rien de significatif et bien pour moi c'est un immense désaventage.
                C'est pas en faisant l'autiste qui se répète avec force "c'est pas significatif" que ca va rendre ton affirmation plus vraie.

                Bof la portabilité binaire dans le monde du libre/open source.
                Oué c'est clair, d'ailleur c'est pour ca que tous les langages modernes de l'open-source (Ruby, Python & co) utilise une VM pour s'abstraire du matos. C'est pas parcque t'as les sources que ton appli va forcement tourner sur toutes les plateformes quand elle est écrite dans un langage bas-niveau. T'as tous les problème d'alignement mémoire, les types de base (entier, etc.) qui n'ont pas la même représentation sur toutes les machines, enfin bref, un vrai bordel. Et t'as intérêt d'avoir des "bons" programmeurs qui savent éviter tous ces problèmes.
                Ah oui, et tout le monde n'est pas sur slackware, y'a même des linuxiens qui utilisent des distributions basés sur un système de package binaire, et rien de plus "pète couille" que d'avoir des repositories non compatibles pour la simple et bonne raison que tout le monde recompile dans son coin les mêmes appli. (Exemple typique de problème de déploiement).

                Je faisais remarquer que tu avais tord en comparant le byte code des VMs (que j'ai eu l'occasion de survoler) au jeu d'instructions des langages machines, mais qu'il fallait plutôt le comparer aux fonctions qu'offrent un OS/bibliothèques de base.
                Non c'est tout à fait comparable. Une VM offre un jeu d'instruction qui s'apparente à l'assembleur. Il n'y a effectivement pas "seulement" ca, mais il y a "aussi" ca. Y'a effectivement de nombreux services annexes qui peuvent pour certains s'apparenter à des fonctionnalités d'un OS.

                Quand à l'indépendance de l'OS, une fois de plus, cela est loin d'être l'exclusivité de ces VMs.
                Euh, par définition, pour être indépendant de l'OS/machine, il faut créer une couche d'abstraction... et c'est la définition même d'une VM : "machine virtuelle". Mais vas-y, plutôt que d'affirmer encore une fois de plus quelque chose, montre moi.

                Là j'avoue que pour le libre, j'ai aussi une préférence éthique
                Ben on est au moins d'accord sur un point.

                i. L'ensemble des logiciels libres couvre largement ce que sait faire J2EE/.NET aussi bien ou mieux et sans les soucis d'indépendance de ces technologies vis-à-vis de leur entreprise mère respective.
                Et une affirmation, et une !
                C'est quoi cette plateforme alors ?
                Nan parcque ca intéresserait des millions de développeurs/entreprises.

                C/C++/python/ruby/perl/php/lua/erlang/haskell/bash/openssl/gnutls/apache/
                T'as en partie compris le problème du libre : il n'y a aucune plateforme cohérente qui propose l'ensemble des services que propose Java/.NET. Zope est une des rares solutions à proposer un serveur d'application. Mais Zope est loin de proposer tout ce que fourni J2EE par exemple. Et visiblement le choix d'un langage interprété dynamique montre ces limites. C'est même pas imaginable en C/C++, c'est bien qu'il manque une brique indispensable entre les 2. Devines laquelle.
                • [^] # Re: Former des développeurs Python/Zope compétents

                  Posté par (page perso) . Évalué à 1.

                  tout le monde n'est pas sur slackware, y'a même des linuxiens qui utilisent des distributions basés sur un système de package binaire

                  Huh ? Slackware est basée sur un système de package binaire. Tu confonds avec Gentoo je pense.
                • [^] # Re: Former des développeurs Python/Zope compétents

                  Posté par . Évalué à 1.

                  T'as déjà écrit une application répartie ? T'as déjà déployer une application sur plus d'une plateforme ?
                  Monsieur le client, c'est open-source, démerdez-vous pour recompiler, et tant pis pour l'application répartie !
                  T'as aucune idée de ce qu'apporte une plateforme de type Java/.NET, et ca se voit.
                  A mon tour :) ! Puisque tu es à plein temps sur les journaux et que j'ai un peu de temps on va s'amuser! Je vois que tu as vu que j'avais placer Erlang. Framework pour la mise au point d'applications distribuées. Pour dire vrai, la dernière fois qu'on a m'a proposer un poste dans la téléphonie mobile, ct pour gérer l'infrastructure de déploiement de programmes sur les JVM certifiées J2ME. Bin il avait des matrices de compatibilité dans tous les sens car la portabilité binaire ct du pipo.
                  Hum... en tout cas, ce qui ce voit même pour un non initié, c'est ton aggressivité.
                  Mais arrête d'affirmer n'importe quoi sans argumenter !
                  Explique moi comment tu peux offrir en C/C++ les services d'isolation mémoire offert par les VM ? Montre moi le super service d'introspection qu'offre C/C++ histoire de rigoler un coup !
                  Isolation mémoire? C'est pas un service de l'OS par hasard? Processus? Je sais que la VM est un OS au dessus de l'OS mais bon, pas la peine de le rappeller à chaque fois. Introspection? Je sais qu'ils travaillent dessus sur les gobjects de la glib et qu'ils s'en servent pour générer les bindings de python (ruby quelqu'un?). À part cela je n'ai jamais été confronté à ce jour à l'utilité de l'introspection.
                  C'est vrai que je réduis en parlant seulement de C/C++/python/ruby/perl/php etc etc... il faut que je mettre aussi l'OS dedans pour essayer d'avoir un tout plus cohérent fonctionnellement. Donc linux dans mon cas.
                  C'est pas en faisant l'autiste qui se répète avec force "c'est pas significatif" que ca va rendre ton affirmation plus vraie.
                  Je n'ai jamais eu la prétention de détenir la vérité absolue. Et toi?
                  Oué c'est clair, d'ailleur c'est pour ca que tous les langages modernes de l'open-source (Ruby, Python & co) utilise une VM pour s'abstraire du matos. C'est pas parcque t'as les sources que ton appli va forcement tourner sur toutes les plateformes quand elle est écrite dans un langage bas-niveau. T'as tous les problème d'alignement mémoire, les types de base (entier, etc.) qui n'ont pas la même représentation sur toutes les machines, enfin bref, un vrai bordel. Et t'as intérêt d'avoir des "bons" programmeurs qui savent éviter tous ces problèmes.
                  Ah oui, et tout le monde n'est pas sur slackware, y'a même des linuxiens qui utilisent des distributions basés sur un système de package binaire, et rien de plus "pète couille" que d'avoir des repositories non compatibles pour la simple et bonne raison que tout le monde recompile dans son coin les mêmes appli. (Exemple typique de problème de déploiement).
                  Hum, la VM dans les langages comme python, ruby and co, sont probablement adapté au dynamisme de ces langages. Je pense même qu'il est plus préférable d'utiliser le terme "d'interpréteur" pour ces langages.
                  Non c'est tout à fait comparable. Une VM offre un jeu d'instruction qui s'apparente à l'assembleur. Il n'y a effectivement pas "seulement" ca, mais il y a "aussi" ca. Y'a effectivement de nombreux services annexes qui peuvent pour certains s'apparenter à des fonctionnalités d'un OS.
                  J'ai considéré le byte code dans ça globalité. Pour moi cela reste plus proche des services d'un OS que d'un jeu d'instructions en assembleur.
                  Et une affirmation, et une !
                  C'est quoi cette plateforme alors ?
                  Nan parcque ca intéresserait des millions de développeurs/entreprises
                  L'ensemble des OS/Langages/bibliothèques libres. Hum... là tu as raison... il ne faut pas diminuer les efforts pour mettre au parfum un maximum de monde et d'entreprises sur la "troisième voix".
                  C/C++/python/ruby/perl/php/lua/erlang/haskell/bash/openssl/gnutls/apache/
                  T'as en partie compris le problème du libre : il n'y a aucune plateforme cohérente qui propose l'ensemble des services que propose Java/.NET. Zope est une des rares solutions à proposer un serveur d'application. Mais Zope est loin de proposer tout ce que fourni J2EE par exemple. Et visiblement le choix d'un langage interprété dynamique montre ces limites. C'est même pas imaginable en C/C++, c'est bien qu'il manque une brique indispensable entre les 2. Devines laquelle.
                  Et après c'est moi qui affirme sans argumenter... Ce qui va faire pencher la balance c'est la sensibilité de chacun. Le tout est de bien avoir été exposé à un maximum d'arguments afin de faire un choix qui convient le mieux.
                  Plateforme cohérente? Ça veut dire que les autres sont incohérentes :D! Tu veux dire que le prix de l'indépendance vis à vis de l'appropriation de l'informatique par un oligopole d'entreprises est avoir de nombreux composants intéropérables pour former une informatique cohérente? Si ça n'avait pas été le cas, très vite tout le logiciel libre aurait été noyauté par le petit nombre d'entreprises que l'on connait bien.
                  Perso, je conseille vivement à ceux qui nous lisent de faire évoluer les solutions basées sur les linux/C/C++/python/ruby/perl/php.... Dans la majorité des cas, je pense qu'elles vont donneront pleinement satisfaction, et si il vous manque une brique, n'hésitez pas à monter des projets libres pour que le développement soit collaboratif.
                  • [^] # Re: Former des développeurs Python/Zope compétents

                    Posté par (page perso) . Évalué à 2.

                    Bin il avait des matrices de compatibilité dans tous les sens car la portabilité binaire ct du pipo.
                    Oué, c'est J2ME, chacun y va se son implémentation et de sa sous partie des API qu'il a envie de définir. Restons côté J2SE/J2EE ok ? :)

                    Hum... en tout cas, ce qui ce voit même pour un non initié, c'est ton aggressivité.
                    Désolé mais t'es gonflant à sortir des affirmations gratuites sans la moindre argumentation ou exemple pour ettayer.

                    Isolation mémoire? C'est pas un service de l'OS par hasard?
                    Si bien entendu, mais il est limité à une séparation des adresses mémoires entre les processus. Cela peut être géré de manière beaucoup plus fine et intelligente au niveau d'une VM, sans d'ailleur à avoir à se soucier de ce que fait tel ou tel OS (qui a dit application portable ?).

                    Je sais qu'ils travaillent dessus sur les gobjects de la glib et qu'ils s'en servent pour générer les bindings de python (ruby quelqu'un?).
                    C'est pour ca que je te disais : montre moi le "super" service d'introspection. C'est vraiment limité, bien souvent c'est du "parsing" de source (yahoo), et à l'exécution t'as rien du tout, la génération de code dynamique tu peux également te toucher, enfin bref, c'est pas ce que j'appel un service d'introspection digne de ce nom.

                    Je n'ai jamais eu la prétention de détenir la vérité absolue. Et toi?
                    Non, mais au moins après avoir dis ca tu arrêtes enfin de répéter "non significatif" sans argumenté :) But atteint ;)

                    Je pense même qu'il est plus préférable d'utiliser le terme "d'interpréteur" pour ces langages.
                    Ces langages peuvent tout de même être compilés, il existe par exemple IronPython, une implémentation de Python pour .NET/Mono. Le résultat : gains de perfs et accès à toutes les bibliothèques de la plateforme. C'est où les inconvénients ?

                    Pour moi cela reste plus proche des services d'un OS que d'un jeu d'instructions en assembleur.
                    Si tu veux, mais tu veux démontrer quoi exactement ?

                    il ne faut pas diminuer les efforts pour mettre au parfum un maximum de monde et d'entreprises sur la "troisième voix".
                    Mais c'est quoi la 3ème voix ? Elle est où la plateforme qui intègre tout ce qui est nécessaire pour faire des appli n-tiers avec serveur d'applications, clients lourds, pages web dynamiques, un modèle de composant et des perfs décentes ?

                    t si il vous manque une brique, n'hésitez pas à monter des projets libres pour que le développement soit collaboratif.
                    Ben justement, c'est ce que fond tous ceux qui implémente des JVM, des serveursr d'applications J2EE et tout le tintouin.
                    Visiblement le libre est incapable de gérer une plateforme d'une telle taille de manière cohérente, alors il se contente de "singer" le proprio. C'est dommage, mais en attendant on n'a pas d'alternative, à moins de se "contenter" des technos hétéroclytes que tu cites, en ayant la moitié des services en moins, pleins d'incohérences, de difficultés d'intéractions, des problèmes de déploiement, des technos très différentes à assimilés pour un résultat... ben non y'en a pas.
                    (J'exagère, puisque Zope existe, mais comme le montre cette news, avec des limites).
                    • [^] # Re: Former des développeurs Python/Zope compétents

                      Posté par . Évalué à -1.

                      Désolé mais t'es gonflant à sortir des affirmations gratuites sans la moindre argumentation ou exemple pour ettayer.
                      C'est vrai que toi par contre, c'est merveilleux. Ça va les chevilles?

                      Si bien entendu, mais il est limité à une séparation des adresses mémoires entre les processus. Cela peut être géré de manière beaucoup plus fine et intelligente au niveau d'une VM, sans d'ailleurs à avoir à se soucier de ce que fait tel ou tel OS (qui a dit application portable ?).
                      A quoi ça sert d'avoir une gestion plus fine à part avoir du code à priori plus complexe? Tu veux dire que le modèle d'abstraction des VMs est plus sophistiquée que celui des OS courant?
                      C'est pour ca que je te disais : montre moi le "super" service d'introspection. C'est vraiment limité, bien souvent c'est du "parsing" de source (yahoo), et à l'exécution t'as rien du tout, la génération de code dynamique tu peux également te toucher, enfin bref, c'est pas ce que j'appel un service d'introspection digne de ce nom.
                      Python/ruby et probablement d'autres offrent ce service d'introspection sur leur "objets", non? D'ailleurs j'avoue que le concept existe depuis longtemps dans les middleware objet. Je n'ai jamais eu l'occasion de développer du soft qui en avait besoin.
                      Ces langages peuvent tout de même être compilés, il existe par exemple IronPython, une implémentation de Python pour .NET/Mono. Le résultat : gains de perfs et accès à toutes les bibliothèques de la plateforme. C'est où les inconvénients ?
                      Pourquoi je bloaterais mes programmes en python? 5000 lignes de C (commentaires+lignes vides) l'interpréteur de CPython... combien pour les autres VMs? Je choisirai parrot comme VM alternative qui semble bien plus libre que les .net/Java and co. Mais bon, ce que je recherche avant tout c'est la simplicité et le dynamisme des langages comme python/ruby/perl and co, pas une VM. Je serai content avec l'interpréteur le plus léger possible pour chaque langage.
                      Si tu veux, mais tu veux démontrer quoi exactement ?
                      T'insiste sur le fait que les VMs sont plus proches du langage machine, à ce que j'ai vu, elles sonts plus proches des services d'un OS.
                      Mais c'est quoi la 3ème voix ? Elle est où la plateforme qui intègre tout ce qui est nécessaire pour faire des appli n-tiers avec serveur d'applications, clients lourds, pages web dynamiques, un modèle de composant et des perfs décentes ?
                      Cf messages précédents
                      .
                      Ben justement, c'est ce que fond tous ceux qui implémente des JVM, des serveursr d'applications J2EE et tout le tintouin.
                      Visiblement le libre est incapable de gérer une plateforme d'une telle taille de manière cohérente, alors il se contente de "singer" le proprio. C'est dommage, mais en attendant on n'a pas d'alternative, à moins de se "contenter" des technos hétéroclytes que tu cites, en ayant la moitié des services en moins, pleins d'incohérences, de difficultés d'intéractions, des problèmes de déploiement, des technos très différentes à assimilés pour un résultat... ben non y'en a pas.
                      (J'exagère, puisque Zope existe, mais comme le montre cette news, avec des limites).
                      Cf messages précédent.

                      Donc j'en remet une couche: chers amis du libre, attention aux technologies à l'indépendance douteuses. Choisissez vos composants logiciels les plus libres possibles: préférer les plateformes C/C++/python/ruby/erlang/php/perl/linux etc... etc... pour développer vos applications.
                      • [^] # Re: Former des développeurs Python/Zope compétents

                        Posté par (page perso) . Évalué à 3.

                        C'est vrai que toi par contre, c'est merveilleux. Ça va les chevilles?
                        Vois pas le rapport, mais c'est vrai que j'ai essayé de te pondre quelques exemples.
                        - "oué c'est pas significatif"
                        - "Exemple1, Exemple2"
                        - "oué c'est pas significatif"
                        - "..."

                        A quoi ça sert d'avoir une gestion plus fine à part avoir du code à priori plus complexe?
                        Avoir aucun débordement de tampon possible, assurer qu'un soft ne puisse pas attaquer directement l'OS (et y attaquer d'éventuelle faille de sécu), bénéficier de la "légèreté" des thread sans sacrifier l'isolation qu'offre les processus mais en plus "lourd". Ca suffit non comme atouts ? Trouve moi des désavantages :)

                        Python/ruby et probablement d'autres offrent ce service d'introspection sur leur "objets", non?
                        Tout à fait ! Mais faut choisir, tu peux pas prendre les atouts de C/C++ quand ca t'arrange (pas de VM toussa) et ceux de Python/Ruby quand ca t'arrange :) Ce mix ca s'appel les solutions intermédiaires de type .NET/Java, avec en plus des services non proposés par les extrêmités ;-)

                        combien pour les autres VMs?
                        Et ? C'est quoi le problème du nombre de lignes ? Linux il fait combien de lignes ? Gnome ? KDE ? c'est des gros bloats ! Je continue à utiliser ce bon vieux DOS tiens, au moins il tient sur ma disquette 3"1/4. C'est très maigre comme inconvénient par rapport à tous les avantages que ca apporte.

                        Je choisirai parrot comme VM alternative qui semble bien plus libre que les .net/Java and co.
                        Encore t'as définition du "plus libre" et du "moins libre". Pourtant les licences sont souvent les mêmes... Et puis parrot n'offre pas tous les services qu'offre les autres plateformes.

                        Je serai content avec l'interpréteur le plus léger possible pour chaque langage.
                        Oué pour faire du script ou des petites appli. Dès que t'as besoin de perfs ou de grosses applis, faut passer à quelque chose de plus sérieux. Un GC efficace, ca se code pas en 50 lignes de codes par exemple. Un compilateur JIT qui boost les perfs c'est pas 30 lignes. Après faut savoir ce qu'on veut, mais faut comparer ce qui est comparable.

                        T'insiste sur le fait que les VMs sont plus proches du langage machine, à ce que j'ai vu, elles sonts plus proches des services d'un OS.
                        Et donc ?

                        Cf messages précédents
                        On dirait que t'ose pas citer une plateforme :) Allez vas-y, propose moi une alternative :)
                        • [^] # Re: Former des développeurs Python/Zope compétents

                          Posté par . Évalué à -1.

                          Vois pas le rapport,
                          Le genre de débat que nous avons ici, ne vaut pas plus que quelques clous. Tes clous comme les miens.
                          Tout à fait ! Mais faut choisir, tu peux pas prendre les atouts de C/C++ quand ca t'arrange (pas de VM toussa) et ceux de Python/Ruby quand ca t'arrange :) Ce mix ca s'appel les solutions intermédiaires de type .NET/Java, avec en plus des services non proposés par les extrêmités ;-)
                          Non, ça s'appelle des solutions hétérogènes C/C++/python/ruby.
                          Avoir aucun débordement de tampon possible, assurer qu'un soft ne puisse pas attaquer directement l'OS (et y attaquer d'éventuelle faille de sécu), bénéficier de la "légèreté" des thread sans sacrifier l'isolation qu'offre les processus mais en plus "lourd". Ca suffit non comme atouts ? Trouve moi des désavantages :)
                          Aucun débordement de tampon possible... oulala, tu as du faire rigoler des gars en sécu. Les OS courant ont déjà pas mal de difficultés avec de l'aide du hard et magie... tu balances que les VM sont toutes super plus sécure que les OS sur lesquelles elle tournent en utilisant les même mécanismes... ça c rigolo... :D En tout cas, ce que tu me décris est bien les fonctions d'un OS... un inconvénient, un énorme tas de code compliqué redondant vis à vis du code de l'OS: arithmétique simple: plus de code=plus d'emm*****. La VM sert à rien, tu as du hard, tu met linux et tu te fais pas ch*** avec le paquet de code de la VM.Linux est une super VM. Tu verras.

                          Encore t'as définition du "plus libre" et du "moins libre". Pourtant les licences sont souvent les mêmes... Et puis parrot n'offre pas tous les services qu'offre les autres plateformes.
                          Le libre dans logiciel libre ne signifie pas *que* des licences "libres", si tu n'as pas pigé ça... Pour parrot ce qui m'embête c'est qu'elle se bloatifie très vite à cause de la volonté de supporter tous les langages de la terre! Perso, il faut suivre parrot de prêt, il paraît que perl6 bombera avec elle.
                          Et donc ?
                          Et donc j'ai répondu à ta question.
                          On dirait que t'ose pas citer une plateforme :) Allez vas-y, propose moi une alternative :)
                          Bon allez... je vais récupérer ce que j'ai dit dans un précédent message pour te faire plaisir
                          sylware a dit:
                          L'ensemble des OS/Langages/bibliothèques libres.
                          • [^] # Re: Former des développeurs Python/Zope compétents

                            Posté par (page perso) . Évalué à 2.

                            Non, ça s'appelle des solutions hétérogènes C/C++/python/ruby.
                            ? COmment vas-tu tout à coup offrir l'introspection et la sécurité d'un code derrière une VM à une appli C++ ? Nan parcque ca serait très intéressant quand même :)

                            tu balances que les VM sont toutes super plus sécure que les OS sur lesquelles elle tournent en utilisant les même mécanismes... ça c rigolo... :D
                            Oui parcque justement ces VM ont été conçus dans ce but de sécurité, S'il y a une faille, elle est dans la VM, mais c'est plus facile de patcher une VM qu'un hardware :) Evidemment qu'il n'y a pas de risque 0, mais il faut bien reconnaître que ce n'est pas tous les jours que tu vois un problème de débordement de tampon dans une appli écrite en Java/.NET, alors que c'est une des failles les plus répendues dans les langages bas niveau.

                            En tout cas, ce que tu me décris est bien les fonctions d'un OS...
                            Ca n'en fait pas pour autant un inconvénient.

                            un inconvénient, un énorme tas de code compliqué redondant vis à vis du code de l'OS: arithmétique simple: plus de code=plus d'emm*****.
                            ? Le but est d'abstraire les fonctionnalités de l'OS, et je préfère 1000 fois une gestion des threads implémentée et éprouvée dans la VM, quitte à être redondante, que d'être obligé de m'adapter suivant l'OS à tous les types de thread. Evidemment, abstraire ca a un coût. Mais faut savoir ce qu'on veut, et pour la portabilité c'est indispensable. Donc de toute façon dans ta solution magique alternative, t'as forcement quelque chose de similaire.

                            Le libre dans logiciel libre ne signifie pas *que* des licences "libres", si tu n'as pas pigé ça...
                            Je préfères effectivement être libre d'utiliser l'implémentation que je veux d'une techno, en sachant que j'ai la liberté de changer si l'uune d'entre elle me pose problème, plutôt que de dépendre d'une seule implémentation (genre Ruby ou Python) où rien n'est standardisé, et où tout bouge sans cesse. Suis le processus de normalisation d'une norme Java, tu comprendras.

                            Et donc j'ai répondu à ta question.
                            Génial :)

                            L'ensemble des OS/Langages/bibliothèques libres.
                            ...
                            Tu oublies que cette solution, moi je te dis "montre moi une autre maison", toi tu me dis : "tiens j'ai un tas des poutres, des briques, une baraque à frite, une tente, une friteuse, un meuble ikea en pièces détachées, des vis et une fourchette".
                            • [^] # Re: Former des développeurs Python/Zope compétents

                              Posté par . Évalué à -2.

                              COmment vas-tu tout à coup offrir l'introspection et la sécurité d'un code derrière une VM à une appli C++ ? Nan parcque ca serait très intéressant quand même :)
                              Je ne parlais de la killer feature d'instrospection que tu peux faire en python et en ruby si tu en trouves l'utilité, je te parlais de combiner C/C++python/ruby pour faire des applications hétérogènes.
                              Oui parcque justement ces VM ont été conçus dans ce but de sécurité, S'il y a une faille, elle est dans la VM, mais c'est plus facile de patcher une VM qu'un hardware :) Evidemment qu'il n'y a pas de risque 0, mais il faut bien reconnaître que ce n'est pas tous les jours que tu vois un problème de débordement de tampon dans une appli écrite en Java/.NET, alors que c'est une des failles les plus répendues dans les langages bas niveau.
                              C'est écrit en quoi une VM? Tu peux me le rappeler?
                              ? Le but est d'abstraire les fonctionnalités de l'OS, et je préfère 1000 fois une gestion des threads implémentée et éprouvée dans la VM, quitte à être redondante, que d'être obligé de m'adapter suivant l'OS à tous les types de thread. Evidemment, abstraire ca a un coût. Mais faut savoir ce qu'on veut, et pour la portabilité c'est indispensable. Donc de toute façon dans ta solution magique alternative, t'as forcement quelque chose de similaire.
                              Tiens tu remets le couvert avec ta portabilité. RE:la portabilité binaire avec des soft open source portables... bof. Ah, les threads sont moins bien éprouvée dans l'OS? Et les threads de ta VM c'est pas celles de ton OS par hasard. C'est une hard feature des OS le threading, tu ne peux pas d'abstraire du modèle et ordonnancement de threading des OS, sauf si tu as l'intention d'avoir des threads qui s'exécutent séquentiellement. Et puis le coût dont tu parles, si tu le considère pas trop élevé tant mieux pour toi, tu es riches, mais pour ma part c'est un no-go pour ce que ces plateformes m'apportent. En fait, on aurait du s'arrêter là: je considère que ces framework ne m'apportent rien à par des inconvénients, donc la dîme VM.... ahem... par contre je dis pas pour python,ruby par exemple qui sont vraiment plus simples vraiment dynamiques et ont un interpréteur poids plume comparé aux VM de tes framework... là, je pense être prêt à payer la taxe interpréteur.
                              Comme je l'ai dit:
                              un énorme tas de code compliqué redondant vis à vis du code de l'OS: arithmétique simple: plus de code=plus d'emm*****. La VM sert à rien, tu as du hard, tu met linux et tu te fais pas ch*** avec le paquet de code de la VM.Linux est une super VM. Tu verras.

                              Tu oublies que cette solution, moi je te dis "montre moi une autre maison", toi tu me dis : "tiens j'ai un tas des poutres, des briques, une baraque à frite, une tente, une friteuse, un meuble ikea en pièces détachées, des vis et une fourchette".
                              Allez... une analogie à 2 balles 30, fais-le toi-même, tu es grand: http://freshmeat.net ah... et c'est que le hall d'entrée (1 balle 2). :D
                              • [^] # Re: Former des développeurs Python/Zope compétents

                                Posté par (page perso) . Évalué à 1.

                                je te parlais de combiner C/C++python/ruby pour faire des applications hétérogènes.
                                Moi je voulais justement te montrer qu'il y a des plateformes qui sont homogènes, et qui prennent le meilleur de chaque monde.

                                C'est écrit en quoi une VM? Tu peux me le rappeler?
                                Et donc ? une VM est écrite une seule fois, elle est largement testée et éprouvée, alors que le développeur créer souvent du code neuf pour une nouvelle appli, et c'est là qu'il peut laisser traîner pleins de trou de sécu. Sans parler du fait que ce n'est généralement pas du tout les même développeurs avec les mêmes compétences qui développent les applis et la VM.

                                RE:la portabilité binaire avec des soft open source portables... bof.
                                RE: rappel toi, j'ai argumenté en montrant que même dans le libre on en a besoin, que le C/C++ c'est portable seulement quand on le veut bien, que pour le déploiement c'est pas naz, et pour créer des applications réparties qui tournent sur des OS différents c'est encore plus naz.

                                Ah, les threads sont moins bien éprouvée dans l'OS?
                                Désolé, j'ai mélangé 2 exemples, je voulais dans un premier temps parler de la gestion mémoire, et du fait que beaucoup de programmeurs C/C++ réinventait la roue plutôt que d'utiliser une implémentation éprouvée, et je suis ensuite parti sur le problème des threads pour montrer qu'ils étaient bien différents d'une plateforme à l'autre, et qu'à ce titre il fallait une couche d'abstraction indispensable.

                                , tu ne peux pas d'abstraire du modèle et ordonnancement de threading des OS
                                Ben pourtant les VM y arrive...

                                Et puis le coût dont tu parles, si tu le considère pas trop élevé tant mieux pour toi, tu es riches
                                Euh, je te parle du coût dont tu parlais : y'a besoin de plus de 5000 lignes de code pour avoir des services efficaces et performants.

                                ui sont vraiment plus simples vraiment dynamiques et ont un interpréteur poids plume comparé aux VM de tes framework
                                Et alors ? Quand tu veux des perfs et des services éprouvées et testés tu fais comment ? Tu crois que Zope est "léger" et fait 5000 lignes de code ?
                                Figure toi qu'à une époque Java était interprété, et qu'il y avait sûrement des implémentations très légères, notamment pour l'embarqué, mais personne n'a vu l'intérêt de rester sur ces modèles, c'était plus une limitation dû à un manque de connaissances dans le domaine. Y'a plus que toi pour trouver ca bien.

                                Allez... une analogie à 2 balles 30, fais-le toi-même, tu es grand: http://freshmeat.net ah... et c'est que le hall d'entrée (1 balle 2). :D
                                Oué et on retrouve la poutre et les briques derrière ta porte :) T'es gentil mais là tu me proposes pas la solution, tu me proposes de la faire moi même ma solution. Moi j'ai pas forcement envie de réinventer la roue tous les jours tu vois.

                                Ce que tu as du mal à comprendre, c'est que Java/.NET ne sont pas de simple "buzz" marketing, c'est avant tout une réponse à un besoin client. Et y'a de la demande. Je trouverai dommage que le libre laisse se créneau, heuresement y'a des gens qui penses pas comme toi et qui travaille à apporter ces technos dans le libre, dont le projet Apache (et ses nombreux framework Java), la FSF par l'interpédiaire de ses projets GNU (ClassPath, DotGNU, etc.), Novell, Red Hat, enfin tout ceux qui ont envie de faire progresser les LL plutôt que de le laisser à la traîne pour des raisons aussi débile que préférer une bouse interprétée qui va à 2 à l'heure mais qui fait "que" 5000 lignes de code !
                                • [^] # Re: Former des développeurs Python/Zope compétents

                                  Posté par . Évalué à -1.

                                  Moi je voulais justement te montrer qu'il y a des plateformes qui sont homogènes, et qui prennent le meilleur de chaque monde.
                                  Tu devrais quitter le monde unix, car tu n'as pas très bien compris sa philosophie... :D Mais tu as le droit de n'être pas d'accord en prônant exactement le contraire sur un site consacré à un des unix les plus populaires! Les framework homogènes font des compromis, et les compromis riment avec le sacrifice du meilleur de certains monde.
                                  C'est écrit en quoi une VM? Tu peux me le rappeler?
                                  Et donc ? une VM est écrite une seule fois, elle est largement testée et éprouvée, alors que le développeur créer souvent du code neuf pour une nouvelle appli, et c'est là qu'il peut laisser traîner pleins de trou de sécu. Sans parler du fait que ce n'est généralement pas du tout les même développeurs avec les mêmes compétences qui développent les applis et la VM.
                                  Bah, tu ne veux pas répondre... et bien je vais le faire à ta place une VM s'est écrit en langage de bas niveau et comme tu l'as très bien fait remarquer:
                                  ..alors que c'est une des failles les plus répandues dans les langages bas niveau
                                  Bon, je te dis ça, hein histoire que tu ne fasses pas trop rigoler les gars en sécu. Tu as le même discours que les Crosofteux qu'il y avait à la Black Hat: "super sécure, éprouvé etc etc...".
                                  RE: rappel toi, j'ai argumenté en montrant que même dans le libre on en a besoin, que le C/C++ c'est portable seulement quand on le veut bien, que pour le déploiement c'est pas naz, et pour créer des applications réparties qui tournent sur des OS différents c'est encore plus naz.
                                  re:Erlang? Assure toi d'avoir faire une recherche sur http://freshmeat.net et http://www.google.com avant de réduire le libre au C/C++. Tiens en dépêche tu as un serveur pour faire du JABBER/XMPP en répartie.

                                  Ah, les threads sont moins bien éprouvée dans l'OS?
                                  Désolé, j'ai mélangé 2 exemples, je voulais dans un premier temps parler de la gestion mémoire, et du fait que beaucoup de programmeurs C/C++ réinventait la roue plutôt que d'utiliser une implémentation éprouvée, et je suis ensuite parti sur le problème des threads pour montrer qu'ils étaient bien différents d'une plateforme à l'autre, et qu'à ce titre il fallait une couche d'abstraction indispensable.
                                  Le gestion de la mémoire(la vraie), tu crois que c'est pas dépendant de l'OS tout ça... Et oui sur les threads... re :D

                                  Ben pourtant les VM y arrive...
                                  Oh quelle est belle! Voir para précédent.

                                  Tu crois que Zope est "léger" et fait 5000 lignes de code ?
                                  Zope est une VM? Jt persuadé d'avoir parlé de l'interpréteur de python.
                                  Figure toi qu'à une époque Java était interprété, et qu'il y avait sûrement des implémentations très légères, notamment pour l'embarqué, mais personne n'a vu l'intérêt de rester sur ces modèles, c'était plus une limitation dû à un manque de connaissances dans le domaine. Y'a plus que toi pour trouver ca bien.
                                  Et le J2ME "éprouvé et testé"TM fut inventé....

                                  Oué et on retrouve la poutre et les briques derrière ta porte :) T'es gentil mais là tu me proposes pas la solution, tu me proposes de la faire moi même ma solution. Moi j'ai pas forcement envie de réinventer la roue tous les jours tu vois.
                                  Et bien, en fonction de tes besoins tu fais ton "shopping" en choississant les libs/soft qui te conviennent en fonction des paramètres que tu cherches: robustesse, sécu, vitesse, features, licence, RAD etc ... En général, les roues de base viennent toujours d'un petit nombre de libs/soft. Pas besoin de plus la plupart du temps.

                                  Je pense qu'une des meilleurs VM qui soit est linux. Du hard et boom linux dessus. Inutile de s'encombrer d'une VM additionnelle qui va ajouter des tonnes de code supplémentaire à prendre en compte et à gérer. Gardons les choses simples. En terme de langage piocher dans C/C++/python/ruby/perl/erlang etc... en fonction des caractéristiques voulues de la solution cliente avec les libs/soft qui vont bien. Complètement dans l'esprit unix.
                                  • [^] # Re: Former des développeurs Python/Zope compétents

                                    Posté par (page perso) . Évalué à 3.

                                    Tu devrais quitter le monde unix, car tu n'as pas très bien compris sa philosophie...
                                    Oué, sa c'était la philosophie d'il y a 30 ans. Heuresement les mentalités évoluent.
                                    KDE ou GNOME sont des grosses plateformes qui dans la philosophie Unix ne devrait pas exister, rappel toi, normalement tous les softs devraient être des jolis exécutables qui discutent avec des pipes...

                                    en prônant exactement le contraire sur un site consacré à un des unix les plus populaires!
                                    Je suis sûr un site consacré à GNU Linux, et GNU is NOT Unix ! :-p

                                    Bah, tu ne veux pas répondre... et bien je vais le faire à ta place une VM s'est écrit en langage de bas niveau et comme tu l'as très bien fait remarquer
                                    C'est bon merci, je suis pas con, j'ai même argumenté derrière en expliquant pourquoi je préfère largement que les services les plus courants qui nécessite d'être codé avec un langage de bas niveau (gestion mémoire toussa) le soit une fois pour toute dans la VM, codée par des personnes compétentes, et que le jour où une faille de sécu est corrigée, toutes les applis qui tournent dessus en profite !

                                    re:Erlang?
                                    T'es incorrigible, t'es toujours pareil, dès que tu cherches un atout, tu le cherche dans une autre brique. Evidemment que Erlang permet de faire du réparti, c'est fait pour. Mais en attendant Erlang ne propose pas une plateforme aussi complète que Java ou .NET.

                                    Le gestion de la mémoire(la vraie), tu crois que c'est pas dépendant de l'OS tout ça...
                                    Ah oui, y'a la vraie gestion mémoire et la fausse... En attendant ton OS favori il a vraiment du mal à gérer les débordement tampons et les fuites mémoires. Moi je fais confiance au modèle de sécurité des VM modernes et à leur GC bien plus sécurisés que mes malloc.

                                    Zope est une VM? Jt persuadé d'avoir parlé de l'interpréteur de python.
                                    Je voulais te montrer que dans la vraie vie avec des vraies applis, on ne peut se contenter de l'interpréteur Python de 5000 lignes, et que Zope fait plus de 5000 lignes pour être un minimum performant.

                                    En général, les roues de base viennent toujours d'un petit nombre de libs/soft. Pas besoin de plus la plupart du temps.
                                    Oué et je joue au mécano ? Comment j'assemble tout ca ? Qui va s'assurer que mon assemblage ne va pas être bourré de trous de sécu ? Nan parcque moi je suis un simple développeur/Architecte, je suis pas un guru de la sécu.
                                    Et puis bon, qui va résoudre tous mes problèmes d'intégration et de déploiement, nan parcque déployer une appli dont le coeur est codé en C/C++, le serveur d'application en erlang, les pages web en PHP, les clients lourds en Qt et les scripts en Perl, merci ! T'es à 15000 km des réalités du développement de grosses solutions toi c'est pas possible.

                                    Inutile de s'encombrer d'une VM additionnelle
                                    C'est pour ca que tu me dis juste après de choisir parmi Python ou Ruby. Bordel soit cohérent. Soit tu dénigre les VM et t'arrête de me parler de ces solutions et on en revient à C/C++, soit tu reconnais qu'elles peuvent être utilent et on continue la discussion.
                                    • [^] # Re: Former des développeurs Python/Zope compétents

                                      Posté par . Évalué à -2.

                                      Oué, sa c'était la philosophie d'il y a 30 ans. Heuresement les mentalités évoluent.
                                      KDE ou GNOME sont des grosses plateformes qui dans la philosophie Unix ne devrait pas exister, rappel toi, normalement tous les softs devraient être des jolis exécutables qui discutent avec des pipes...

                                      Les mentalité changent, des bonnes recettes restent et on refait les mêmes erreurs...
                                      KDE et GNOME sont des assemblages cohérents de libs. gnome va essayer de dropper corba car bien trop complexe pour les tâches d'un desktop (overkill). En effet, un des fondateurs a fait ce mauvais choix, mais avec lui c'est en train de devenir une habitude. Le but de ces projets est de fournir le service "desktop" pour utilisateur normal. Le service desktop est indépendant de xorg qui gère l'affichage. KDE,gnome et d'autres se fédèrent autour de freedesktop pour que la miriades d'éléments composant l'offre des desktops puissent intéropérer malgré leur différence dans les choix d'implémentation. Si ce projet réussi, à terme on pourra "composer" un desktop cohérent avec un certain degré de liberté... rien de plus normal pour du libre et dans le cadre de la philosophie unix.
                                      Je suis sûr un site consacré à GNU Linux, et GNU is NOT Unix ! :-p
                                      Je suis pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.

                                      C'est bon merci, je suis pas con, j'ai même argumenté derrière en expliquant pourquoi je préfère largement que les services les plus courants qui nécessite d'être codé avec un langage de bas niveau (gestion mémoire toussa) le soit une fois pour toute dans la VM, codée par des personnes compétentes, et que le jour où une faille de sécu est corrigée, toutes les applis qui tournent dessus en profite !
                                      Ta VM tourne un OS. Si l'OS est compromis tu pourra faire tourner la VM la plus sécure de la terre, elle sera compromise. Déléguer la gestion mémoire, ou gérer plus finement sa gestion mémoire, c'est un choix (du moins tant qu'on te le laisse... huhu...). Si tu souhaites ne pas gérer ta mémoire, tu peux utiliser des libs de garbages collectors si tu veux. Mais bon, le meilleur compromis seraient que les codeurs s'intéresse un peu plus à la sécu pour coder au mieux "secure" tout en conservant une gestion fine de leur besoin de mémoire.
                                      T'es incorrigible, t'es toujours pareil, dès que tu cherches un atout, tu le cherche dans une autre brique. Evidemment que Erlang permet de faire du réparti, c'est fait pour. Mais en attendant Erlang ne propose pas une plateforme aussi complète que Java ou .NET.
                                      On m'a dit qu'Erlang était conçu dans le but de faire de l'informatique réparti pour les télécom et de le faire bien, et que pour pouvoir faire au mieux, il possédait une sémantique/syntax adaptée, ce que les autres langages n'offrent pas (tant pis pour eux, ils n'auront pas le meilleur de ce monde).
                                      Ah oui, y'a la vraie gestion mémoire et la fausse... En attendant ton OS favori il a vraiment du mal à gérer les débordement tampons et les fuites mémoires. Moi je fais confiance au modèle de sécurité des VM modernes et à leur GC bien plus sécurisés que mes malloc.
                                      Je parlais de la mémoire (allocation de page physique), pas de la gestion mémoire... pas grave, ct ambigüe. Sinon, je te renvois au paragraphe au dessus concernant la sécurité de la VM. Une règle général en sécurité: plus tu as de code, modulé par sa complexité, plus tu as de risques d'avoir des failles de sécurité. Donc pour réduire les risques de failles, j'aurais tendance à virer la VM (beaucoup de code complexe), simplifier au maximum le code et me concentrer sur les failles de l'OS.
                                      Je voulais te montrer que dans la vraie vie avec des vraies applis, on ne peut se contenter de l'interpréteur Python de 5000 lignes, et que Zope fait plus de 5000 lignes pour être un minimum performant.
                                      Tout ce je sais, c'est que j'ai pas sortie l'énormité que Zope avait 5000 lignes de code. Le framework python, avec ces libs standards, aux alentours de 250000 lignes de C et de pyhton aux dernières nouvelles. Le C est là pour la performance et/ou abstaire les services de l'OS/libs de base plus "pythoniquement". En effet, dans certains cas, abstraire ces derniers services en C et bien plus efficace que de le faire en python (qu'avec des appels directs aux fonctions des services de bases) ou que d'alourdir et complexifier l'interpréteur en y ajoutant de nouveaux opcodes.
                                      Oué et je joue au mécano ? Comment j'assemble tout ca ? Qui va s'assurer que mon assemblage ne va pas être bourré de trous de sécu ? Nan parcque moi je suis un simple développeur/Architecte, je suis pas un guru de la sécu.
                                      Et puis bon, qui va résoudre tous mes problèmes d'intégration et de déploiement, nan parcque déployer une appli dont le coeur est codé en C/C++, le serveur d'application en erlang, les pages web en PHP, les clients lourds en Qt et les scripts en Perl, merci ! T'es à 15000 km des réalités du développement de grosses solutions toi c'est pas possible.
                                      En général, tu as des entreprises qui offrent des audit de sécurité et qui peuvent fournir du conseil en sécu. Les composants exposés à des attaques réelles pourront être audités et le développement pourra être assisté par un consultant en sécu. Au bout du compte, cela revient à placer sa confiance dans certains composants, et beaucoup de composants du libre ont acquis cette confiance (qui continue de se propager) de manière noble, cad pas par des campagnes de pub/com. Perso, les applications les plus gourmandes dont j'ai entendu parlées ont été re-écrites en langage machines. Cela dit, les solutions les plus hétérogènes que j'ai pu voir étaient des solutions qui avait vieilli sur des années, récupérant diverses technologies de divers âges au fur et à mesure de leur évolution fonctionnelle. C'est passionnant!
                                      • [^] # Re: Former des développeurs Python/Zope compétents

                                        Posté par (page perso) . Évalué à 3.

                                        KDE et GNOME sont des assemblages cohérents de libs
                                        Et tu m'expliques pourquoi Java et .NET ne serait pas des assemblages cohérents ? Ils ont été conçus justement pour être cohérents !

                                        . Si ce projet réussi, à terme on pourra "composer" un desktop cohérent avec un certain degré de liberté... rien de plus normal pour du libre et dans le cadre de la philosophie unix.
                                        Tout comme avec une plateforme Java, qui elle est déjà normalisée, tu choisies les briques qui t'intéresse, de la simple VM embarquée au serveur d'application, du composant sous licence libre au composant proprio, et tu gardes une cohérence technique de A à Z.

                                        Je suis pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.
                                        Oué elle était facile, mais pas si dénuet d'intérêt : Unix à la base c'est du 100% proprio, si on t'écoute on aurait dû garder la philosophie ;)

                                        Si l'OS est compromis tu pourra faire tourner la VM la plus sécure de la terre, elle sera compromise.
                                        Oué mais c'est totalement indépendant de ton appli, j'y suis pour rien. Et si ca arrive trop souvent, je peux justement changer facilement d'OS vers un OS moins troué grâce à l'indépendance que me procure la VM ;-)

                                        Si tu souhaites ne pas gérer ta mémoire, tu peux utiliser des libs de garbages collectors si tu veux.
                                        Oué, si tu veux. Sauf que globalement t'es bien obligé de respecter les libs que t'utilises, tu t'amuses pas à utiliser un GC dans ton coin, une autre lib utilise le sien, l'autre fait des malloc à la main et libère, l'autre fait des malloc mais sous-entend que c'est à l'utilisateur de libérer, enfin un vrai foutoir d'intégration qui se finit en fuites mémoires. (attention je dis pas qu'avec les VM c'est impossible, juste que le modèle mémoire est normalisé).

                                        Mais bon, le meilleur compromis seraient que les codeurs s'intéresse un peu plus à la sécu pour coder au mieux "secure" tout en conservant une gestion fine de leur besoin de mémoire.
                                        Oué ca c'est dans le meilleur des mondes... Y'a 2 approches :
                                        - "la gestion mémoire est tellement importante que je préfères ne pas laisser la machine s'en occuper"
                                        - "la gestion mémoire est tellement importante que je préfères ne pas laisser un humain s'en occuper"
                                        Choisi celle que tu veux moi c'est tout vu :-)

                                        (tant pis pour eux, ils n'auront pas le meilleur de ce monde).
                                        Tu vas rire, mais les plateformes comme Java ou .NET/Mono peuvent accueillir de nouveaux langages, même que si tu google un peu Erlang + Java ...

                                        Une règle général en sécurité: plus tu as de code, modulé par sa complexité, plus tu as de risques d'avoir des failles de sécurité.
                                        Ben justement, je préfère amplement avoir une plateforme cohérente de A à Z, de la couche d'accès aux données aux clients lourds en passant par le serveur web, pour justement éviter la complexité et la lourdeur de ponts intermédiaires artisanaux qui engendre de nombreux problèmes techniques.

                                        j'aurais tendance à virer la VM (beaucoup de code complexe),
                                        Je préfères encore une fois faire confiance à la VM qui n'a sûrement pas été codée avec les pieds qu'à moi même pour réinventer la roue ;)

                                        Le framework python, avec ces libs standards, aux alentours de 250000 lignes de C et de pyhton aux dernières nouvelles.
                                        Une plateforme comme Mono (je parle de ce que je connais), c'est le même ordre de grandeur en nombre de lignes de code...

                                        . Au bout du compte, cela revient à placer sa confiance dans certains composants, et beaucoup de composants du libre ont acquis cette confiance
                                        Le problème ne vient pas des composants en soit (qui sont souvent auditer de manière individuel), les problèmes viennent de l'assemblage "sur-mesure" que tu créés, qui est nouveau, et apporte une complexité et des risques supplémentaires.

                                        C'est passionnant!
                                        Oué bah j'espère que t'as la chance de ne pas faire la maintenance :)
                                        • [^] # Re: Former des développeurs Python/Zope compétents

                                          Posté par . Évalué à -1.

                                          Et tu m'expliques pourquoi Java et .NET ne serait pas des assemblages cohérents ? Ils ont été conçus justement pour être cohérents !

                                          La plateforme python est cohérente, la plateforme perl avec leur système CPAM est cohérente, la plateforme erlang est cohérente etc etc... et il est tout à fait possible d'assembler des solutions hétérogènes qui forment un tout cohérent.

                                          Tout comme avec une plateforme Java, qui elle est déjà normalisée, tu choisies les briques qui t'intéresse, de la simple VM embarquée au serveur d'application, du composant sous licence libre au composant proprio, et tu gardes une cohérence technique de A à Z.
                                          Quand c'est une norme, ça veut dire que c'est passé par un organisme de normalisation. Ces organismes sont nombreux. Certains ont plus ou moins bonne réputation. Dernièrement je traîne pas mal sur le site de l'organisme OASIS qui a normalisé le format open document et toujours sur le même site je m'intéresse à la norme docbook. Quel organisme de bonne réputation a normalisé quelle partie de la plateforme java? Ça me trouble car normé avec un degré de rigueur correcte des plateformes gigantesques et tentaculaires comme java qui évolue assez vite donc rendrait la norme vite obsolète me semble utopique.

                                          Oué elle était facile, mais pas si dénuet d'intérêt : Unix à la base c'est du 100% proprio, si on t'écoute on aurait dû garder la philosophie ;)
                                          J'écoutais un discours de RMS qui rappellait qu'a la base, les logiciels étaient libres. C'est en train de revenir, et c'est tant mieux! Les bonnes choses reviennent toujours. Pour en revenir à la philosophie d'unix et autre motto bourrés de bon sens... http://en.wikipedia.org/wiki/Unix_philosophy et http://en.wikipedia.org/wiki/Live_free_or_die#Use_in_Unix

                                          Oué mais c'est totalement indépendant de ton appli, j'y suis pour rien. Et si ca arrive trop souvent, je peux justement changer facilement d'OS vers un OS moins troué grâce à l'indépendance que me procure la VM ;-)
                                          Tu n'y es pour rien? Tu ne peux rien y faire? Pas très rassurant tout ça... brrr! Portez une VM et tout son framework sur un OS prétendu "moins troué". Quelles jolies galipettes! (Cf J2ME). Mettre au point et maintenir des combinaisons de HARD+OS c'est déjà pas forcément facile, alors les combinaisons HARD+OS+VM... euh... non merci.

                                          Oué, si tu veux. Sauf que globalement t'es bien obligé de respecter les libs que t'utilises, tu t'amuses pas à utiliser un GC dans ton coin, une autre lib utilise le sien, l'autre fait des malloc à la main et libère, l'autre fait des malloc mais sous-entend que c'est à l'utilisateur de libérer, enfin un vrai foutoir d'intégration qui se finit en fuites mémoires. (attention je dis pas qu'avec les VM c'est impossible, juste que le modèle mémoire est normalisé).
                                          Tu n'as besoin de respecter le GC que là où tu as en besoin, ailleurs, ça serait du gâchis de ressources. Perso, je n'aime pas beaucoup les garbage collector, ce gâchis et cette perte de contrôle.... beurk! Mais, j'essayerais un jour de coder quelquechose en C++ avec un garbage collector. Lorsque j'ai travaillé en téléphonie mobile, pour "vendre super sécure"(TM), un composant de la solution n'avait tout bonnement pas d'allocation mémoire dynamique, tout était statiquement alloué à la compilation et préparé aux petits oignons. Mais seulement le composant exposé, les autres était pénards et pouvait utiliser la politique de gestion mémoire qu'ils souhaitaient.
                                          Oué ca c'est dans le meilleur des mondes... Y'a 2 approches :
                                          - "la gestion mémoire est tellement importante que je préfères ne pas laisser la machine s'en occuper"
                                          - "la gestion mémoire est tellement importante que je préfères ne pas laisser un humain s'en occuper"
                                          Choisi celle que tu veux moi c'est tout vu :-)
                                          Pourquoi exclusivement machine ou humain? La meilleurs solution n'est certainement pas l'une ou l'autre, ça dépend de ce que tu as besoin de faire et des ressources dont tu disposes. En aucun cas l'un ou l'autre n'est magique: "les humains sont tous de nullards" et "les ordinateurs sont super intelligents"? Il faut être capable de faire des compromis entre ces deux politiques de gestion mémoire pour arriver au meilleur résultat.

                                          Tu vas rire, mais les plateformes comme Java ou .NET/Mono peuvent accueillir de nouveaux langages, même que si tu google un peu Erlang + Java ...
                                          Dans ce paragraphe, je parlais de langage, de syntax, de sémantique, pas de VM/runtime. Si j'ai bien compris la VM parrot à l'intention de devenir la VM universelle. Après une bref recherche sur google j'ai trouvé ça: http://www.sics.se/~joe/ericsson/du98024.html Bon... il faut avouer que les benchs.... ça se détournent... à tel point que les benchs hurlés partout sur le net valent encore quelque chose...

                                          Ben justement, je préfère amplement avoir une plateforme cohérente de A à Z, de la couche d'accès aux données aux clients lourds en passant par le serveur web, pour justement éviter la complexité et la lourdeur de ponts intermédiaires artisanaux qui engendre de nombreux problèmes techniques.
                                          Moi aussi, je préfère largement avoir une plateforme cohérente qui répondent au besoin métier du clients. Et je me passe très bien de VM qui est une dépendance qui ne fait qu'alourdir ma solution par l'ajout d'une quantité de code loin d'être négligeable qu'il va falloir gérer et maintenir.
                                          Je préfères encore une fois faire confiance à la VM qui n'a sûrement pas été codée avec les pieds qu'à moi même pour réinventer la roue ;)
                                          "sûrement"? Si ça te suffit... :D "L'OS de MS est le meilleur du monde(TM) car c'est la plus grosse boîte du monde et que donc par définition il ne peuvent pas faire de la mBIP!" te suffit également? Je suis désolé mais ça n'est pas suffisant: Ce que je vois, c'est un mastodonte de code à gérer et à maintenir qui duplique les services qui me sont offerts par mon OS préféré et ses libs de base, donc si je peux m'en passer je m'en passe. Pourquoi tu veux réinventer la roue? Utilise et améliore les libs existantes plutôt.
                                          Une plateforme comme Mono (je parle de ce que je connais), c'est le même ordre de grandeur en nombre de lignes de code...
                                          ...dans le pb de dépendance vis-à-vis de MS, comme JAVA de Sun? C'est l'ensemble de la plateforme python, l'interpréteur python faire 5000 lignes de C, combien de ligne de code C pour la VM de Mono? Erlang 41000 pour la VM tu disais? Il faudrait aussi voir du côté de la VM parrot, de ruby, de perl et des autres.
                                          Le problème ne vient pas des composants en soit (qui sont souvent auditer de manière individuel), les problèmes viennent de l'assemblage "sur-mesure" que tu créés, qui est nouveau, et apporte une complexité et des risques supplémentaires.
                                          En général, il n'y a pas tant de libs que ça, et souvent les combinatoires sont les mêmes. Les risques et les efforts de maintenance sont proportionnels à la quantité de code modulé par sa complexité. Arithmétique simple: HARD+OS/libs+VM+FRAMEWORK ou HARD+OS/libs pour faire la même chose.
                                          C'est passionnant!
                                          Oué bah j'espère que t'as la chance de ne pas faire la maintenance :)
                                          J'ai fait de la maintenance sur des applications complexes tapant les millions de lignes: un cauchemar, C'était plus des amas de rustines et de code tordu pour compenser le design malfoutu et les bugs des "produits"(TM) de boîtes qui "certifiait"(TM) et "supportait"(TM) ta mère ton oncle et la paix dans le monde(TM)... ct pas passionnant plutôt irritant et dévalorisant, par contre tous les projets que j'ai fait sur du libre dans une optique unix, ct passionnant et intéressant.
                                          • [^] # Re: Former des développeurs Python/Zope compétents

                                            Posté par (page perso) . Évalué à 4.

                                            La plateforme python est cohérente, la plateforme perl avec leur système CPAM est cohérente, la plateforme erlang est cohérente etc etc...
                                            On est d'accord, donc .NET et Java n'ont pas une lacune de ce côté là. Merci d'avoir confirmé.

                                            Quel organisme de bonne réputation a normalisé quelle partie de la plateforme java?
                                            Ben, le JCP, organisme dédié avec des tarlouz comme Sun et IBM. Dans tous les cas il y a un effort de normalisation pour garantir l'interopérabilité. Et ca c'est le principal. On ne peut en dire autant de plateforme style Ruby, Python ou Php.

                                            J'écoutais un discours de RMS qui rappellait qu'a la base, les logiciels étaient libres.
                                            Rattrapes toi comme tu veux, Unix n'était pas libre à ses débuts. Heuresement RMS est arrivé.

                                            Tu n'y es pour rien? Tu ne peux rien y faire? Pas très rassurant tout ça... brrr!
                                            ... T'es bête ou quoi ? Oui, si je me contente de développer une appli sur un OS, c'est évident que si y'a un trou dans l'OS j'y suis pour rien. Je suis responsable des trous dans mon appli uniquement. Alors moi je prégères contrôler au niveau de mon appli ce que je peux contrôler, et utiliser les services de sécurité de la VM (et l'indépendance vis-à-vis de l'OS) pour éviter que mon appli devienne une porte d'entrée vers mes données mais aussi l'OS (l'obstacle VM marche dans les 2 sens).

                                            Il faut être capable de faire des compromis entre ces deux politiques de gestion mémoire pour arriver au meilleur résultat.
                                            Dans tous les cas, quand tu utilises une plateforme, il faut que le modèle de gestion mémoire soit clairement exposé (et normalisé), pour assurer l'interopérabilité entre les composants. Alors désolé, mais y'a pas de "juste milieu", faut choisir quelque chose de standard pour la plateforme. En C/C++, c'est le joyeux bordel, chacun y va de sa technique exposée par ses libs. Dans les plateformes plus modernes, ca a été heuresement évité et normalisé : y'a un GC, il a un comportement dont les specs sont écrites noir sur blanc afin de garantir que toutes les implémentations produisent les mêmes résultats : interopérabilité.

                                            Dans ce paragraphe, je parlais de langage, de syntax, de sémantique, pas de VM/runtime.
                                            Justement ! Ces plateformes peuvent accueillir de nouvelles syntaxe/sémantique tout en profitant des services offerts !
                                            Genre je prends .NET/Mono, certains voulaient une syntaxe ala Python, on a vu fleurir IronPython et Boo, et les composants écrits dans ces langages sont interopérables avec les autres composants sans qu'il n'y est de "pont" à écrire.

                                            Et je me passe très bien de VM qui est une dépendance qui ne fait qu'alourdir ma solution par l'ajout d'une quantité de code loin d'être négligeable qu'il va falloir gérer et maintenir.
                                            Donc tu codes tout en C/C++. (et encore C++, y'a une gestion des exceptions et tout, y'a des services au runtime, ouahou, allé, C seulement !)
                                            Et bien amuse toi bien, code ton serveur d'application en C, tes pages dynamique en C, tes clients lourd en C, amuse toi bonhomme, pendant ce temps là y'en a qui s'amuse avec d'autres plateformes : Java, Python, etc.

                                            Pourquoi tu veux réinventer la roue? Utilise et améliore les libs existantes plutôt.
                                            Ben justement, et en l'occurence en matière de serveur d'application, d'outil de mapping objet/relationnel, d'outils d'analyse de code, ben j'en ai marre de réinventer la roue dans des langages de bas niveau, je préfères largement utiliser celle de libs Java qui existent depuis des années.

                                            C'est l'ensemble de la plateforme python, l'interpréteur python faire 5000 lignes de C
                                            Avec des perfs de merde. Merci. Compare ce qui est comparable bordel ! C'est pour ca que je te parlais de Zope !

                                            Arithmétique simple: HARD+OS/libs+VM+FRAMEWORK ou HARD+OS/libs pour faire la même chose.
                                            Un calcul avec autant de mauvaise foi montre ton incompétence total.

                                            Enfin au final t'es vraiment d'une incohérence totale dans tous tes propos. Moi j'essai juste de te démontrer que les VM apporte de réels atouts et avantages que les langages bas-niveau n'offre pas, que ce soit en matière de sécurité, de déploiement, de simplicité, d'interopérabilité, bref de productivité.
                                            Toi tu fais quoi : tu cherches uniquement à dire le contraire de ce que je te dis. Un coup tu me dis que les langages de bas niveau c'est mieux, un autre coup tu me ressorts Erlang alors que c'est architecturé de la même manière que les plateformes que je prends en exemple, quand je te dis "oué mais tu peux pas profité de l'introspection quand tu code en C/C++" tu me dis "oué mais y'a Python etc.".
                                            Bref tu te fou royalement de ma gueule, t'es inccapable de tenir une argumentation cohérente, on sait pas si t'aime bien les VM, un coup tu dis que tel ou tel langage c'est bien parcque pas de VM, un autre coup l'autre est bien aussi (parcqu'il en a une), ton seul objectif c'est de cracher avec une totale mauvaise foi sur des plateformes qui ont été initiées par des grosses boîtes. Si ca peut te faire bander, continue tout seul. (Ah oui au fait, Erlang, c'est pas issu d'une grosse boîte par hasard ? Bouuuuuh beurk.)
                                            • [^] # Re: Former des développeurs Python/Zope compétents

                                              Posté par . Évalué à 2.

                                              Oui timaniac... tu as raison. Je suis d'accord avec toi et tu as fait de très bon posts. Mais slyware est un incompétent. je crois qu'on doit se rendre à l'évidence, il est nul en informatique et en développement. Ce mec est un vrai boulet et en plus, il est de mauvaise foi !

                                              http://about.me/straumat

                                            • [^] # Re: Former des développeurs Python/Zope compétents

                                              Posté par . Évalué à 2.

                                              Je ne serai pas aussi tranchant que Stéphane, mais m'est avis que tu perds ton temps.
                                            • [^] # Re: Former des développeurs Python/Zope compétents

                                              Posté par (page perso) . Évalué à 2.

                                              Je crois que tu peux t'arrêter, là, on est tous d'accord, on a tous compris, sauf l'autre là, qui va poster encore une réponse, une variante des précédentes... Plus la peine de répondre, tout a été dit. Laisse-lui le dernier mot, celui qui tombe dans une salle de conférence déserte...
                                  • [^] # Re: Former des développeurs Python/Zope compétents

                                    Posté par (page perso) . Évalué à 2.

                                    En fait tu te fou vraiment de ma gueule.
                                    Je viens de regarder vite fait Erlang...
                                    Erlang a une VM qui se base sur l'interprétation d'un byte-code dans le but affiché est d'avoir une indépendance de la plateforme au niveau binaire.
                                    Rrien qu'en comptant les sources écrites en C, y'a 41000 lignes, et j'ai pas compté les lignes codées en Erlang, qui doivent correspondre aux libs de base.
                                    Ensuite Erlang a un environnement d'exécution qui offre de nombreux services (mémoire, distribution, chargement à chaud, etc.).
                                    C'est vraiment une plateforme du même type que .NET/Java au niveau architecture.

                                    Ah moins que Erlang aussi ca soit naz ?
                    • [^] # Re: Former des développeurs Python/Zope compétents

                      Posté par . Évalué à 2.

                      Ces langages peuvent tout de même être compilés, il existe par exemple IronPython, une implémentation de Python pour .NET/Mono. Le résultat : gains de perfs

                      Hu ? IronPython est plus lent que Python.
                      http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...)

                      Visiblement le libre est incapable de gérer une plateforme d'une telle taille de manière cohérente

                      ???
                      Les "plateformes" du libre, ce sont les distributions, comme Ubuntu, Debian, Mandriva & co. Question taille, il n'y a pas à rougir.
                  • [^] # Re: Former des développeurs Python/Zope compétents

                    Posté par . Évalué à 3.

                    Le problème dans ton discours c'est que tu nous ressorts à chaque fois une solution différente pour chaque aspect alors qu'on insiste ici sur le fait que la force de Java ou de Mono est la mise à disposition d'une plateforme "cohérente" et pas composée de bouts assemblés dans tous les sens et inmaintenables.

                    Fort bien, tu as erlang qui traite mieux le developpement distribué. Mais il tourne sur un "runtime". Il offre donc lui aussi des services de l'OS ? Alors tu préfères un OS ou un runtime? Et comment tu fais pour prendre le meilleur de Erlang et de python ? Tu bases ton architecture sur des composants qui communiquent avec un protocole et une infrastructure communes (bus). C'etait pas un peu l'idée de Corba au départ. Hélas même les devs de KDE et de Gnome lui ont tourné le dos en l'adaptant à leur sauce parce que les perf étaient dégradées en environnement "non" distribué. Alors maintenant tu as ta dipsosition des plateformes libres ou "quasiment" qui offrent des services prêts à l'emploi et permettent de rajouter des composants (JEE, Mono, XPCOM-Mozilla, UNO -OpenOffice, ...). Mais le choix se réduit encore lorsqu'il faut couvrir le réparti, le local, le mutili OS.
                    Tu as aussi la solution de récupérer toutes les technos du libre éparses et de les assembler par des ponts divers et variés. Quid de la cohérence, la montée en charge, la stabilité sur une architecture exotique ?
                    Le piège du soi-disant "oligopoles" se transforme en la quête du mouton à 5 pattes et la chasse à la compléxité superflue?
                    Et quelle librairie graphique portable s'interface avec Erlang. Qt ? Est-ce adapté pour tirer bénéfice des possibilités du langages. Quand on voit les trésors d'ingéniosité déployés par l'auteur de PyQt pour étendre le mécanisme des signaux/slots et les rendre dynamiques, on comprend qu'un langage conditionne une architecture.

                    Et pour revenir sur les services du runtime qui s'apparentent à celui de l'OS. Comment assurer simplement la portabilité entre OS justement, si tu bases ton code sur des spécificités d'un OS. suggeères tu que la portabilité soitassurée par l'OS. Ce que tu reproches à M$ tu voudrais l'imposer. Les runtimes encapsulent justement ces services avec une API commune et lorsque les spécificités de l'OS permettent d'optimiser ces
                    services, elles sont prises en compte.
                    La section critique se base sur des mécanismes offerts par l'OS (sans quoi elle ne serait pas fiable) et pourtant c'est bien un service offert par le langage ou le runtime qui est de plus haut niveau que le sémaphore (je ne connais pas les détails de l'implémentation, aussi je peux me tromper mais c'est sur l'idée que j'insiste).
                    • [^] # Re: Former des développeurs Python/Zope compétents

                      Posté par . Évalué à 0.

                      Le problème dans ton discours c'est que tu nous ressorts à chaque fois une solution différente pour chaque aspect alors qu'on insiste ici sur le fait que la force de Java ou de Mono est la mise à disposition d'une plateforme "cohérente" et pas composée de bouts assemblés dans tous les sens et inmaintenables.
                      Tout à fait, linux est inmaintenable, python non plus, ruby non plus, KDE, gnutls; openssh; xorg, mozilla, gcc.

                      Fort bien, tu as erlang qui traite mieux le developpement distribué. Mais il tourne sur un "runtime". Il offre donc lui aussi des services de l'OS ? Alors tu préfères un OS ou un runtime? Et comment tu fais pour prendre le meilleur de Erlang et de python ? Tu bases ton architecture sur des composants qui communiquent avec un protocole et une infrastructure communes (bus). C'etait pas un peu l'idée de Corba au départ. Hélas même les devs de KDE et de Gnome lui ont tourné le dos en l'adaptant à leur sauce parce que les perf étaient dégradées en environnement "non" distribué.
                      Euh... tu te goures, ORBit à la réputation d'être rapide. KDE à dropper corba car ct inutilement complexe et lourd pour les tâches d'un desktop. Miguel De Icaza, le MS copycat de gnome, à eu la très mauvaise idée de copier le modèle de composant MS COM pour le mapper sur corba. Gnome le drop pour embrayer sur dbus aussi à cause de la complexité.
                      Alors maintenant tu as ta dipsosition des plateformes libres ou "quasiment" qui offrent des services prêts à l'emploi et permettent de rajouter des composants (JEE, Mono, XPCOM-Mozilla, UNO -OpenOffice, ...). Mais le choix se réduit encore lorsqu'il faut couvrir le réparti, le local, le mutili OS.
                      JEE Mono sont des technologies dont l'indépendance et très discutable... je ne me contente pas d'une licence libre quand je parle de logiciel libre. XPCOM-Mozilla est très simple comparé à ces derniers. Je ne sais pas pour UNO.
                      Tu as aussi la solution de récupérer toutes les technos du libre éparses et de les assembler par des ponts divers et variés. Quid de la cohérence, la montée en charge, la stabilité sur une architecture exotique ?
                      Le piège du soi-disant "oligopoles" se transforme en la quête du mouton à 5 pattes et la chasse à la compléxité superflue?
                      Pour ma part, je préfère mettre ensemble des composants simples qui font bien leur boulot (cf moto d'unix), et cela ne signifie pas du tout "complexité" que d'avoir tout regroupé dans une super plateforme qui tente de tout faire. As-tu regardé les spécifications de java, celle de .net... c'est horriblement complexe, même corba m'a semblé plus simple à côté. Le bilan est le suivant: tu vois des frameworks d'une complexité inouïe passés en force, alors que de l'autre côté par la pratique et à la force de la raison, comme tu l'as souligné avec corba, on les abandonne ces bloats complexes pour un ensemble de petits éléments plus simples.

                      Et quelle librairie graphique portable s'interface avec Erlang. Qt ? Est-ce adapté pour tirer bénéfice des possibilités du langages. Quand on voit les trésors d'ingéniosité déployés par l'auteur de PyQt pour étendre le mécanisme des signaux/slots et les rendre dynamiques, on comprend qu'un langage conditionne une architecture.
                      Erlang bourrine dans les télécoms paraît-il. Si tu veux mettre un interface graphique à une framework pensé pour les télecoms, libre à toi.

                      Et pour revenir sur les services du runtime qui s'apparentent à celui de l'OS. Comment assurer simplement la portabilité entre OS justement, si tu bases ton code sur des spécificités d'un OS. suggeères tu que la portabilité soitassurée par l'OS. Ce que tu reproches à M$ tu voudrais l'imposer. Les runtimes encapsulent justement ces services avec une API commune et lorsque les spécificités de l'OS permettent d'optimiser ces
                      services, elles sont prises en compte.
                      La section critique se base sur des mécanismes offerts par l'OS (sans quoi elle ne serait pas fiable) et pourtant c'est bien un service offert par le langage ou le runtime qui est de plus haut niveau que le sémaphore (je ne connais pas les détails de l'implémentation, aussi je peux me tromper mais c'est sur l'idée que j'insiste).

                      Bon je récapitule MA vision des choses:
                      Je vois des frameworks d'une complexité à la all-in-one(cf specs), dont l'indépendance est sujettes à caution, qui sont poussés complètement artificiellement sur le devant de la scène. Leurs langages en terme de difficulté est similaire au C/C++ donc rien de significativement novateur (spécial dédicasse pour qui celui qui se reconnaitra).. Par contre , en cado bonux tu as une VM à maintenir pour chaque combinaison OS+HARD qui finalement fait du JIT car trop lente (chercher l'erreur).
                      Je vois la montée des langages dit dynamiques (python, ruby ...). Beaucoup plus simples que leur homologues précédent avec un interpréteur loin de la complexité des VM précédentes car ne se vantant pas d'aller plus loin que la complexité déjà élevée des OS courants, et puis surtout c'est "libre", pas Sun ni MS...
                      On me parle de cohérence d'une plateforme, alors que les termes adéquats seraient homogène et hétérogènes. Mais l'opposé de cohérent ça fait péjoratif. Donc tout ce qui n'est pas "cohérent" est BIP! Donc tout ce qui est pas leur framework est BIP! En fait, ces frameworks sont plus homogènes (comme zope)... par contre cela n'empêche en rien un système hétérogène d'être parfaitement cohérent!
                      Ensuite, quand on regarde ce qui se passe: beaucoup de projets du libre recherche la simplification par modularisation (divide and conquiere) ou carrément abandonne les bloat complexes: xorg qui se modularise et qui sous peu sera le berceau de XCB, gnome qui drope finalement corba car trop complexe, mozilla qui passe à xulrunner. Et malgré ça, on apprend toujours pas, tu en as toujours pour pousser de nouveaux giga bloat complexes et donc refaire les mêmes erreurs...
                      • [^] # Re: Former des développeurs Python/Zope compétents

                        Posté par . Évalué à 2.


                        Tout à fait, linux est inmaintenable, python non plus, ruby non plus, KDE, gnutls; openssh; xorg, mozilla, gcc.


                        Tu réponds tjs à coté de la plaque. Ce ne sont pas les briques qui sont inmaintanables , c'est leur assemblage.



                        JEE Mono sont des technologies dont l'indépendance et très discutable... je ne me contente pas d'une licence libre quand je parle de logiciel libre. XPCOM-Mozilla est très simple comparé à ces derniers. Je ne sais pas pour UNO.

                        Tu as raison, des centaines de developpeurs produisent des LL sur la plateformes JEE? Il y des serveurs d'application : Geronimo, Jboss, Jonas, des librairies en pagaille, des IDEs , des applis desktops. Mais toi tu sais mieux que tout ce petit monde. Tu es un vrai sage.
                        Quant à XPCOM il est tellement simple qu'il ne prend pas en charge le traitement réparti. Alors forcément dès que tu prend en charge plusieurs OS, le traitement réparti ou non , ben c'est un peu plus compliqué. Mais au moin c'est bien défini. Alors qu'avec des briques empilées sans le plan qui va avec tu risques d'obtenir un edifice scabreux et fragile.


                        Erlang bourrine dans les télécoms paraît-il. Si tu veux mettre un interface graphique à une framework pensé pour les télecoms, libre à toi.

                        Je croyais qu'on trouvait tout en mieux dans le "pure" libre.Alors comment tu fais pour faire un ihm potable sur un backend erlang en distribué. Tu mets un peu de TCL/Tk en client lourd du PHP en léger , qui passe par un connection SSH, avec un serveur Apache en frontend. Ca doit pas fuir de toute part ca. Au niveau du deploiement ca doit être simplissime. Pis va falloir les dieux du dev
                        pour maîtriser le bouzin. Les J2EE lead architect, c'est des enfants de choeur à coté.

                        Le reste est un délire incompréhensible.
                        T'es vraiment despérant, je jettes l'éponge
                        • [^] # Re: Former des développeurs Python/Zope compétents

                          Posté par . Évalué à -1.


                          Tu réponds tjs à coté de la plaque. Ce ne sont pas les briques qui sont inmaintanables , c'est leur assemblage.
                          C'est vrai rien ne marche ensemble.Complètement inmaintenable. Tu en as d'autres comme ça?
                          Tu as raison, des centaines de developpeurs produisent des LL sur la plateformes JEE? Il y des serveurs d'application : Geronimo, Jboss, Jonas, des librairies en pagaille, des IDEs , des applis desktops. Mais toi tu sais mieux que tout ce petit monde. Tu es un vrai sage.
                          JEE n'est pas libre, ce petit monde fait des LL dans un framework non libre. Faire du LL sur des OS proprios c'est pareil. Bien sûr, pour rester dans l'esprit des LL, ils s'évertuent à faire tourner leurs softs sur des VMs libres, non? C'est ce que va faire nuxeo?
                          Je croyais qu'on trouvait tout en mieux dans le "pure" libre.Alors comment tu fais pour faire un ihm potable sur un backend erlang en distribué. Tu mets un peu de TCL/Tk en client lourd du PHP en léger , qui passe par un connection SSH, avec un serveur Apache en frontend. Ca doit pas fuir de toute part ca. Au niveau du deploiement ca doit être simplissime. Pis va falloir les dieux du dev
                          pour maîtriser le bouzin. Les J2EE lead architect, c'est des enfants de choeur à coté.

                          http://erlgtk.sourceforge.net/ ... Tu n'aimes pas le "pure" libre? Alors je te conseille l'adresse suivante où tu trouveras pleins de copains (plus qu'ici à priori, car on aime bien le libre nous) http://msdn.microsoft.com

                          Le reste est un délire incompréhensible.
                          T'es vraiment despérant, je jettes l'éponge
                          Ah dsl, j'aurais p'tet du descendre de mon nuage de sage pour me mettre à ton niveau? Crois-moi, je ne jette pas l'éponge moi, je veux vous sauvez, je vous aime!

                          Utilisez C/C++/Python/Ruby/erlang/linux etc... Sauvez votre âme.
                          • [^] # Re: Former des développeurs Python/Zope compétents

                            Posté par . Évalué à 4.

                            Je le répète aussi... tu es désespérant.. comme tous mes collègues l'ont dit.

                            Je voulais juste signaler au passage : Tu mélanges framework, norme, implémentations et tout ça... Dire que JEE n'est pas libre, c'est comme de dire que TCP/IP n'est pas libre. Mais comme je l'ai dit plus haut, tu brilles par ta complète incompétence !

                            http://about.me/straumat

                            • [^] # Re: Former des développeurs Python/Zope compétents

                              Posté par . Évalué à 0.

                              Je sais ce genre de joute tribal est lamentable et j'en suis le premier à m'en plaindre... car c'est en fait ce que je voulais démontrer. Je n'ai pas à être convaincu des choix technologiques de A ou B. J'ai fait les miens. Ce qui est très dommage ce sont les entristes de tous les bords qui sillonnent les points névralgiques du net pour le LL, dont linuxfr, pour les polluer y vomissant leur diatribes ou leur campagne de comm/marketing.

                              CQFD

                              Pour en revenir à nuxeo, ce qui va suivre est une question fermée, la réponse est oui ou non.


                              Est-ce que le nouveau CPS de nuxeo en java tournera sur des JVM libres?
                              • [^] # Re: Former des développeurs Python/Zope compétents

                                Posté par . Évalué à 2.

                                Ta question est débile !

                                Est ce que nuxeo développe des machines virtuelles libres ? NON

                                La réponse à ta question est que ce n'est pas le problème de nuxeo... et que ça n'a aucun rapport...
                                la question serait aussi débile que "est ce que linux tourne avec un des firmware libre ?" dans le cas de non, ce n'est pas une raison pour ne pas parler de linux.

                                http://about.me/straumat

          • [^] # Re: Former des développeurs Python/Zope compétents

            Posté par . Évalué à 5.

            Slyware.. excuse moi, ce commentaire ne sert à rien... et je vais me faire moinsser et je vais le mériter mais dans tes commentaires et tes avis, tu fais preuve d'une totale mauvaise foi et d'un total manque de compétences.

            Voila, ça va mieux ici maintenant.

            http://about.me/straumat

    • [^] # Re: Former des développeurs Python/Zope compétents

      Posté par (page perso) . Évalué à 4.

      A propos de la formation des gens à Python/Zope: former les développeurs à Python, normalement c'est pas trop dur. Une journée pour avoir de bonnes bases, et ensuite on apprend sur le tas. Bien sûr, entre la réalité et la perception, il y a un écart: il faut que les gens soient motivés pour apprendre, il faut que les responsables ne se braquent pas contre cette idée, etc. Donc effectivement, au niveau perception, on a un obstacle à franchir.

      Le deuxième obstacle c'est Zope: Zope 2 est en voie d'obsolescence, le futur c'est Zope 3. Ou pas. En l'état, l'état de l'art consiste à mélanger du Zope 2 et du Zope 3 en utilisant un "bridge" baptisé Five. Donc en terme de formation, un développeur pour bien maitriser la plateforme doit connaitre Zope 2, Zope 3 (qui n'a plus grand chose à voir avec Zope 2, c'est vraiment des concepts complètement différents) et Five (qui a ses propres spécificités). Et la ca devien t vraiment difficile de motiver les gens pour apprendre ces trois technos, sachant qu'il y en a deux qui seront bientôt obsolètes (ou pas).

      Zope était le choix rationnel quand on voulait faire du Web en Python en 2000, maintenant il y a Django et Turbogears. La communauté Python est partagée sur ce sujet. C'est assez compliqué à expliquer quand on ne suit pas tout ca de près, mais bon l'impression générale c'est qu'on voit pas trop où ca va.

      J'avais essayé de synthétiser la situation il y a 8 mois avec un schéma, maintenant c'est encore plus compliqué (et ca m'intéresse moins): http://blogs.nuxeo.com/sections/blogs/fermigier/2006_01_22_u(...)

      A propos de Jython: Jython ( http://www.jython.org/ ) c'était une idée géniale en 2000, quelque chose de super prometteur, qui a été embarqué dans les 2-3 années qui ont suivi dans pas mal d'applications (libres et propriétaires, et oui!). Le problème, c'est que la version de 2006 n'a pas évolué (ou si peu) par rapport à la version de 2000. On est toujours bloqué à la version 2.1 de Python, alors que "CPython", l'implémentation "standard" vient de sortir en 2.5. Il y a donc des grosses différences entre les deux. Donc à l'heure actuelle plus grand monde ne s'intéresse à Jython, et il n'y a plus personne pour bosser dessus.

      En l'état, on n'a pas encore choisi quel sera le langage de script de la plateforme Nuxeo 5. Mais rassure-toi, il y en aura un ! Pour l'instant on hésite encore entre JavaScript (et oui!), JRuby, Jython et Groovy. Le prérequis évident, c'est que le langage qu'on choisira devra tourner sur la JVM et s'interfacer avec Java conformément à la JSR 223 (http://jcp.org/en/jsr/detail?id=223).

      S.
      --
      Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

      "There's no such thing as can't. You always have a choice." - Ken Gor

      • [^] # Re: Former des développeurs Python/Zope compétents

        Posté par . Évalué à 2.

        Pour Zope, il ne faut pas oublier que Guido n'y participe plus et bosse maintenant chez Google. Alors si le JIT est un aveu de lenteur de Java, que dire de la désertion du créateur de ce langage que j'affectionne par ailleurs ?

        Pour Jython, il semblerait que tout le monde attend déséspérément la venue de PyPy. Qu'en est t'il aujourd'hui ?

        A propos de Django et Turbogears.Ca ressemble plus à un assemblage de briques eparses (CherryPy, ....) qu'a une offre consistante. Ca n'est pas encore comparable à RoR. La communauté Python cherche encore son framework web:
        http://www.boddie.org.uk/python/web_frameworks.html
        Espérons que cette pléthore d'offres ne lui sera pas préjudiciable.
        • [^] # Re: Former des développeurs Python/Zope compétents

          Posté par (page perso) . Évalué à 3.

          A propos de Django et Turbogears.Ca ressemble plus à un assemblage de briques eparses (CherryPy, ....) qu'a une offre consistante. Ca n'est pas encore comparable à RoR.

          Pour avoir bosser avec ROR et bossant actuellement avec Django,je peux t'assurer qu'il n'a rien a lui envier. Django est mature, il existe depuis aussi longtemps que ROR ( si ce n'est pas plus ).

          Pour ce qui est de TurboGears, oui c'est un assemblage de différents composants et c'est une très bonne idée je trouve. On utilise des briques éprouvées et on peut réutiliser le code en dehors du framework.


          La communauté Python cherche encore son framework web:

          Pour quoi ne devrait-il y avoir qu'un seul framework ?
          A chacun ses spécificités, Django étant plus orienté publication et TurboGears plus orienté application.
      • [^] # Re: Former des développeurs Python/Zope compétents

        Posté par . Évalué à 1.

        Bonjour à tous,

        En ce qui concerne Jython, je ne suis pas d'accord.

        Certes le projet lui-même semble marquer le pas en termes d'évolutions par rapport aux versions de CPython.

        Mais d'une part, cela reste cependant une solution très intéressante comme langage de script pour Java et d'autre part, quand on sait s'en servir, le couple Jython+Java offrent de très bonnes performances et rend le prototypage extrêmement souple.

        De nombreux projets Java utilisent Jython comme language de script, en particulier dans le domaine scientifique.

        Je prends pour simple exemple JyConsole, la console Jython que nous avons développée (http://www.artenum.com/fr/products/jyconsole.php). Elle intègre une complétion orientée objet (comme dans Eclipse), s'appliquant de manière totalement transparente que l'objet manipulé soit en Jython (i.e Python) soit en Java, voir y compris... en C++ si on passe par une couche JNI.

        C'est franchement pratique pour prototyper.

        JyConsole a été intégrée à Cassandra (http://www.artenum.com/fr/products/cassandra.php) notre visualiseur scientifique 3D ainsi qu'à plusieurs autres projets open-source comme HermesJMS (http://www.hermesjms.com/).

        Dans Cassandra, JyConsole nous permet par exemple de manipuler simplement et facilement, avec la complétion objet, toute la bibliothèque VTK...

        JyConsole et Jython sont aussi intégrés dans le projet de l'ESA SPIS (voir http://www.spis.org et surtout http://linuxfr.org/2006/09/07/21295.html). Les scientifiques issus du Fortran apprécient beaucoup Jython pour gérer le passage du séquentiel à l'objet (Java et C++)...

        Donc Jython n'est pas mort et est utilisé, je vous le confirme. Ce que cela montre surtout, c'est que le couple Jython+Java constitue vraiment un ensemble très efficace et pratique en particulier pour le prototypage et le contrôle en ligne de commande.

        PyPy semble très prometteur, en particulier en termes de performances. C'est à suivre donc. Mais l'avantage de Jython (dont l'interpréteur est en pur Java) réside dans sa portabilité et le fait qu'il ne nécessite de ne déployer qu'une seule Virtual Machine. Il reste donc facile à intégrer/embarquer dans des applications Java.

        Cela dit concernant les plate-formes collaboratives, l'ensemble Java/J2EE est aussi la solution technologique que nous avons retenu pour notre plate-forme collaborative LibreSource (http://www.libresource.org).

        Même si certains critiquent la complexité de mise en oeuvre de J2EE, le plan performances et surtout inter-opérabilité avec les autres plate-formes, le gain est ici significatif par rapport aux solutions sur base Python de type Zope.

        LibreSource étant diffusée et largement utilisée en production depuis près de deux ans avec de très bons retours de nos utilisateurs, cette solution est maintenant validée.

        Nuxeo marche donc sur les traces de LibreSource. Cela fait plaisir de voir que la voie ouverte il y a deux ans est maintenant suivie.

        Julien Forest
        Gérant d'Artenum
        • [^] # Re: Former des développeurs Python/Zope compétents

          Posté par (page perso) . Évalué à 3.

          Pourquoi utilisez-vous la licence QPL pour vos contributions open-source ? Je trouve ses termes dérangeants, notamment :

          - Possibilité de votre part d'utiliser du code QPL dérivé du vôtre dans des versions commerciales de vos produits
          - Obligation de vous fournir tout travail dérivé du vôtre, même si ce travail n'est pas public
          - Obligation de distribuer tout travail dérivé du vôtre sous forme de patches à appliquer à vôtre distribution initiale

          JyConsole est sympa, mais je ne me suis pas plongé dedans outre mesure à cause de sa licence.
          • [^] # Re: Former des développeurs Python/Zope compétents

            Posté par . Évalué à 3.

            D'abord merci pour le commentaire sur JyConsole. Ça fait plaisir.

            Concernant la QPL... Ha la la! ...  Qu'est-ce qu'on nous aura posé comme questions à son sujet ! ... Il est nécessaire de préciser plusieurs choses.

            1) Vous avez tous utilisé Qt (via KDE) pendant des années sans que cela ne gène personne, alors qu'il était diffusé en QPL jusqu'à il y a très peu de temps. Donc finalement, on peut se demander si la QPL est vraiment un problème en soit.

            2) Pourquoi diffusons nous en QPL ? Pourquoi ce mécanisme de reversion, qui nous permet d'utiliser aussi les contributions de la communauté dans nos produits fermés?

            Mais, c'est parce que nous sommes un petite entreprise et que nos projets sont tout jeunes.

            Nous voulons être honnête avec la communauté open-source. Artenum est entreprise commerciale et nous devons aussi vivre... en vendant services et logiciels... même s'ils sont open-source.

            Nos projets sont jeunes et, pour l'instant, très majoritairement développés par nous-même, ce qui constitue un investissement initial important pour des logiciels qui sont finalement aussi mis en libre accès à la communauté. Le mécanisme de reversement rétribue en partie cet effort initial, du moins dans un premier temps. Je dirais qu'avec la LGPL ce serait pareil pour la communauté, les auteurs initiaux du projet pourraient faire ce qu'ils veulent de vos contributions.

            Lorsque la part des contributions de la communauté deviendra plus importante dans nos projets, nous reverrons probablement notre politique avec peut-être une migration vers des licences de type GPL ou en double licensing GPL/QPL. L'essentiel pour nous devenant à ce moment de définir naturellement des "open-standards" sur la base ouverte et commune de nos code.

            Par ailleurs, je souligne que la QPL est de droit européen, ce qui est mieux pour les auteurs.

            Enfin, la QPL est, comme la GPL, contaminante au sens où elle oblige à mettre les codes rediffusés en open-source, par contre elle n'oblige pas (au contraire de la GPL) à rediffusé sous les termes de la même licence. En fait, c'est de la GPL et de son côté extrêmement contaminant que vient le problème.

            3) Doit-on mettre tout développement sous QPL ? Non. Et il y a deux cas de figures :

            a. Vous souhaitez utiliser nos codes comme composants logiciels pour développer pour autre chose, distinct du projet initial, ce n'est donc pas une modification de nos codes,... vous faites ce que vous voulez, si cela reste de l'open-source au sens de l'OSI. C'est le cas de HermesJMS, qui a intégré JyConsole est qui a sa propre vie.

            b. Vos modifiez nos codes, c'est une contribution et/ou une modification, elle doit être diffusée soit en QPL soit en GPL avec la « petite phrase magique » comme le préconise la FSF (voir http://www.gnu.org/licenses/license-list.fr.html).

            En pratique, les contributions soumises restent accessibles à la communauté. Bref, tant que tout le monde joue le jeu de l'open-source, c'est pareil qu'avec la GPL.

            Indépendamment de notre politique de release, c'est un mauvais procès que l'on fait à la licence QPL, qui est plutôt bien écrite et finalement assez « carrée » dans l'échange équitable qu'elle propose.

            Julien Forest
            Gérant d'Artenum.
            • [^] # Re: Former des développeurs Python/Zope compétents

              Posté par (page perso) . Évalué à 1.

              Si la GPL est trop loin du droit européen, il suffit de prendre CECILL : Elle est 100% française et compatible GPL.
              • [^] # Re: Former des développeurs Python/Zope compétents

                Posté par . Évalué à 5.

                Si la GPL est trop loin du droit européen, il suffit de prendre CECILL

                Que la CECILL soit française, en quoi cela garantit-il quoi que ce soit vis-à-vis du droit européen ?
                Le droit de la propriété littéraire et artistique n'est à ma connaissance pas normalisé en UE.
                D'autre part il y a la convention de Berne, mais elle est aussi signée par les USA dont sont originaires les licences GNU.
        • [^] # Re: Former des développeurs Python/Zope compétents

          Posté par (page perso) . Évalué à 3.

          Salut Julien,

          je suis heureux d'apprendre que Jython est beaucoup utilisé dans le domaine du calcul scientifique et de la visualisation. Je savais que c'était déja le cas pour CPython, grâce à différents systèmes d'interfaces avec C (SWIG, Pyrex), C++ (SWIG, BOOST, SIP, etc.) et Fortran - cf. http://wiki.python.org/moin/IntegratingPythonWithOtherLangua(...) - qui sont particulièrement utiles dans le domaine du calcul scientifiques.

          Comme je l'ai écrit, Jython était une idée géniale au départ (même si d'autres langages de scripts, et notamment Tcl, avaient eu une implémentation sur la JVM avant Python, Jython offrait l'avantage de présenter un modèle objet similaire à celui de Java).

          J'ai moi-même utilisé Jython il y a quelques mois pour scripter rapidement quelques tests sur Jackrabbit, au tout début de notre projet de migration.

          Microsoft a récemment (il y a deux ans quand même) investi sur Python en embauchant le développeur d'IronPython, portage de Python sur la CLR .NET.

          Face à cela, Sun semble avoir fait le choix de Ruby, en embauchant le mois dernier les deux développeurs de JRuby (portage de Ruby sur la JVM, tout le monde l'aura deviné).

          La JSR 223 promet une bonne intégration entre l'environement Java et les langages de scripts qui ont été portés sur la JVM. Il y a déja une vingtaine de langages qui répondent à la spec, dont: Python, TCL, Ruby, JavaScript, PHP, Groovy, Scheme, Pnuts, Judoscript, etc.

          On constate qu'aucun expert Python (aucun connu de moi, en tout cas), ne semble avoir participé au groupe d'expert dans le cadre du JCP: http://www.jcp.org/en/jsr/detail?id=223 Mais ce n'est sans doute pas un problème, ca montre juste un désintérêt, il me semble.

          Maintenant, si personne ne se motive pour mettre Jython à jour avec la version 2.5 de Python (qui présente quand même de très gros changements avec la version 2.1, en fait c'est dans les 2.2, 2.3 et 2.4 qu'ont été introduits les "new style classes", les métaclasses, les annotations, etc. - bref toutes les features modernes de Python), il est clair que les gens vont se tourner vers d'autres langages de scripts pour scripter leurs applis Java.

          J'en suis le premier désolé. C'est la règle du logiciel libre (et du logiciel en général): s'il n'y a personne pour développer, ca n'avance plus.

          D'un autre côté, c'est un projet passionnant, je trouve, et il y a peut-être des lecteurs de LinuxFR à la recherche d'un projet dans le domaine de la compilation et de l'implémentation d'un langage moderne qui seront tentés. Peut-être même qu'il y a de l'inspiration à chercher du côté d'IronPython.

          S.
          --
          Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

          "There's no such thing as can't. You always have a choice." - Ken Gor

      • [^] # Re: Former des développeurs Python/Zope compétents

        Posté par . Évalué à 1.

        C'est donc zope, le framework, qui dérange et non le langage, ce que je comprend tout à fait, un framework a toujours des limites à moment donné.
        Hors vous donnez l'impression de replonger jusqu'au cou dans un autre framework, aussi standard soit-il.

        amha, la solution réellement pérenne qui se dessine en ce moment en python c'est wsgi, c'est à dire quelque chose d'extrèmement modulaire à base de librairies plutôt que de frameworks. Mais c'est jeune c'est vrai.

        Oubien je me trompe et tous ces Jxyz sont plus proches d'un système comme wsgi que d'un framework ?
    • [^] # Re: Former des développeurs Python/Zope compétents

      Posté par . Évalué à 5.

      python n'est pas dur

      mais les universités forment à java (je travaille dans une université, le poids de java est important, php un peu aussi pour enseigner à faire de petits sites web dynamique)

      Java c'est Eclipse, dingue ce que les enseignants peuvent connaître comme plugins de développement pour eclipse...
      java c'est 2000 serveurs d'applications en tout genre
      java c'est tout le poids d'Apache et de ses projets
      java c'est SUN et ce n'est pas rien
      java c'est IBM et c'est décidément pas rien
      java ce sont des normes et des livres par milliers
      java c'est un très grand nombre de composants commerciaux, libres, opensource, propriétaires ou gratuits disponibles tout de suite là.
      java c'est aussi une des technologies répandus dans les mobiles

      pourquoi voulez vous réinventer la roue en python ? sera-t-elle plus stable ?
      sera-t-elle moins chère que java ?

      Python va pas disparaître vu qu'il est très utile comme langage interprété et qu'on peut développer de chouettes logiciels avec sous unix.
      Est ce que Ruby disparaît malgré l'omniprésence de PHP ? non. car y a une demande en ruby. cela sera pareil pour python.

      >tous les développeurs ne sont pas des adeptes du libre
      ha mais je suis adepte du libre. faut juste que je voie l'intérêt d'une technologie.
      • [^] # Re: Former des développeurs Python/Zope compétents

        Posté par . Évalué à 5.

        Pour le coup c'est l'inverse, nuxeo va réinventer ce qu'ils ont fait en python pour le refaire en java...

        Sinon, ben l'intérêt de python le langage, c'est tout simplement qu'il est beaucoup plus agréable à utiliser et permet d'aller ainsi beaucoup plus vite.
        • [^] # Re: Former des développeurs Python/Zope compétents

          Posté par . Évalué à 1.

          Je plussois.
          Autant j'étais d'accords avec les avantages sus-cités de Java, autant dire que Python n'apporte rien est mal connaître ce langage.
          Pour citer deux points où Java pèche par conception (à mon avis):
          - flexibilité/robustesse des interfaces grâce aux arguments par défauts et passage de paramètres par mot clé, arguments dictionnaires
          - expressivité grâce à la surcharge de tous les opérateurs (même les getter/setter, iterateur....). Pas besoin de faire du bytecode pour

          Là où il faut 10 000 lignes de Java il en faut souvent 3 000 en Python et c'est autant de gagné en maintenance

          Je pense que Nuxeo gagne dans le passage seulement parcequ'ils touchaient effectivement des limites de leur plateforme actuelle et auraient dû développer certains composant de base par eux même en Java ils peuvent réutiliser l'énorme travail de Apache - Jboss.
          Perso je crois que le coup de grâce reste la pression de leur clients pour avoir du JAVA. En effet je me demande si à long termes Nuxeo va vraiment gagner (quand ils se trouverons limittés par les composants actuels).
  • # Java = le diable ?

    Posté par . Évalué à 1.

    Qu'avez-vous tous contre Java ?
    A vous lires, on dirait que Java est le diable en personne.

    Malgré le fait que ce language est propriétaire, il fonctionne sur plus de plate-forme que tout les autres languages de dernière génération.

    Vous préférez peut-être dire que mono est plus libre que Java ?
    Peutr-être par sa licence, mais pas par sa compatibilité et les librairies qui les accompagne.

    Quand vous parlez à quelqu'un pur microsoft, python il ne connait pas, Java il connait.

    De même pour les performances, les dernières versions de java se sont grandement amélioré de ce côté.

    Pour info, un JDK 6 est sortit !
    • [^] # Re: Java = le diable ?

      Posté par (page perso) . Évalué à 6.

      Malgré le fait que ce language est propriétaire, il fonctionne sur plus de plate-forme que tout les autres languages de dernière génération.

      va sur sun.com, java (j2se) tourne sur : windows (peut-etre uniquement x86 mais c'est pas indiqué), solaris (sparc, x86, x64), linux (x86, x64), mac (ppc).

      les "autres langages de dernière génération" libres qui sont tous écrits en C (python, ruby, ocaml, j'en passe) tournent sur toutes ou quasi toutes les architectures supportées par Linux, ce qui doit en faire environ 15.
      • [^] # Re: Java = le diable ?

        Posté par (page perso) . Évalué à 1.

        Tu as oublié freeBSD, et aussi je pense d'autre BSD
      • [^] # Re: Java = le diable ?

        Posté par . Évalué à 3.

        Renseigne toi un peu.. Il n'y a pas que sun qui fournit des machines virtuelles Java !

        http://about.me/straumat

        • [^] # Re: Java = le diable ?

          Posté par (page perso) . Évalué à 1.

          renseigne-moi :) alors, combien d'archi/OS supportés par les JVM certifiées par Sun ?
          • [^] # Re: Java = le diable ?

            Posté par . Évalué à 2.

            Je te propose de jeter un coup d'oeil à
            http://www.bea.com/framework.jsp?CNT=index.htm&FP=/conte(...)
            http://www-128.ibm.com/developerworks/java/jdk/
            ça te donnera déjà une idée !

            http://about.me/straumat

            • [^] # Re: Java = le diable ?

              Posté par (page perso) . Évalué à 3.

              On peut ajouter Kaffe et ses nombreuses plateformes :
              http://www.kaffe.org/ports.shtml
              • [^] # Re: Java = le diable ?

                Posté par (page perso) . Évalué à 2.

                kaffe est pas certifié sauf erreur (et il me semble que c'est loin d'être le cas, les espoirs du côté d'une JVM libre se portent beaucoup plus sur gcj de nos jours).
            • [^] # Re: Java = le diable ?

              Posté par (page perso) . Évalué à 3.

              bon puisque tu listes pas je suppose qu'il y a tromperie sur la marchandise, je vais donc jeter un coup d'oeil (si je trouve pas tout ce sera de ta faute..) :

              BEA JRockit supports both Microsoft Windows and Linux operating systems on 32-bit and 64-bit Intel server platforms.

              Ok donc rien de mieux du côté BEA.

              Du côté d'IBM ça rajoute les "series" d'IBM sous Linux (2 archis), et les mainframes sous AIX.

              On est encore loin du compte...
              • [^] # Re: Java = le diable ?

                Posté par . Évalué à 2.

                Il me semble que HP (PA-RISK) fourni une jvm pour ses HP-UX (non en fait j'en suis sûr : je l'utilise)
                • [^] # Re: Java = le diable ?

                  Posté par . Évalué à 3.

                  Ah oui et je pense que si on ajoute les plateformes mobiles (il existait une VM java pour le pda EME505F de casio par exemple sur processeur MIPS 64 bits) on augmente encore le nombres.
                  x86
                  x86-64
                  pa-risk
                  iseries (c'est pas rien ça quand même)
                  mainframe (oui oui)
                  power-pc
                  mips
                  ARM

                  pour linux, windows ce/xp..., macos, *bsd, et sûrement plein d'autre que j'oublie.
                  Tout ça avec des jvm fournit par nombre d'éditeur.
                  Non quand même sérieusement ça fait beaucoup, et comparer java aujourd'hui à une solution propriétaire c'est abusé.
                  • [^] # Re: Java = le diable ?

                    Posté par (page perso) . Évalué à 5.

                    Ah oui et je pense que si on ajoute les plateformes mobiles

                    j'avais dit J2SE. J2ME est bien moins intéressant.

                    ceci dit dans ta liste tu oublies les sparc - ce serait quand même un comble :)

                    Non quand même sérieusement ça fait beaucoup, et comparer java aujourd'hui à une solution propriétaire c'est abusé.

                    c'est pas ce que j'ai dit ; je dis juste que les langages libres sont dispos sur bien plus d'architectures que ce qui est possible avec les JVM (J2SE) certifiées.

                    d'après ta liste sans ARM et avec sparc, on est à 8 architectures matérielles supportées par des JVM certifiées, alors que Linux 2.6 supporte 16 architectures.
                    • [^] # Re: Java = le diable ?

                      Posté par . Évalué à 3.

                      Mouais. D'un autre côté, combien de temps a-t-il fallu attendre pour obtenir une version de C qui soit standardisée ? Voyons voir ... C apparaît vers 1974-75, la première norme ISO/ANSI en 1989-90... La norme C99 est sortie, et pourtant, même GCC n'est pas capable de tout implémenter (faut dire que certaines fonctionnalités du langage sont bien tordues), et pourtant il s'agit d'un compilateur extrêmement respectueux des standards.

                      De plus, C est porté par la force des choses sur plein de plate-formes parce qu'il a été au moins autant imposé sur toutes les architectures qui voulaient de l'UNIX.

                      Java est sorti en 1995 si ma mémoire est bonne : on peut donc attendre encore 3-4 ans avant qu'il ne soit totalement libéré, si l'on suit la même courbe d'évolution que pour le langage C (oui, je fais preuve de mauvaise foi ici).
                    • [^] # Re: Java = le diable ?

                      Posté par . Évalué à -2.

                      Effectivement, quand on prend du recul et qu'on laisse tomber toute mauvaise foi: linux+biblios libres est de très loin le framework le plus portable et performant que je connaisse.
                      D'où l'inutilité de l'existence de la VM pour les langages non dynamiques.
                      Les langages dynamiques (python/ruby/perl etc...) tournent sur différentes VMs. Cela dit, il est maladroit de faire tourner ces langages sur des VMs qui ont été pensées pour des langages non-dynamiques. On obtiendrait à priori de bien meilleurs résultats à les faire tourner sur des VMs qui ont été pensées à la base pour leur dynamisme.
      • [^] # Re: Java = le diable ?

        Posté par . Évalué à 2.

        Je doute quand même que ton programme écrit en C/python tourne sur les plate-formes ( Windows, Linux, .... ) les plus en vogues sans avoir à faire une compilation !

        Le C de base est portable, mais pas les implémentations GUI, excepté peut-être QT et GTK.
        • [^] # Re: Java = le diable ?

          Posté par . Évalué à 4.

          Je ne crois pas qu'il parlait d'un programme écrit en C et Python, mais d'un programme écrit en Python, exécuté par un interpréteur codé en C. Pour être portable, tu as besoin de compiler l'interpréteur Python, exactement comme pour Java où tu as besoin de compiler une JVM.
          • [^] # Re: Java = le diable ?

            Posté par . Évalué à 1.

            Compiler une JVM ?
            Tant que ta plate-formes aie une JRE fonctionnelle, il n'y a pas de problème.
            Tu prends un programme écrit en Java avec les librairies standard, tu en fait un fichier jar et puis tu peux l'utiliser sur n'importe quelle machines équipée d'une machine virtuel java. Je ne connait pas suffissement python pour savoir si ce language à les mêmes propriétés.

            La seule chose qui m'@!$# c'est de lire des réflexions 'c'est pas libre, ça pue' a propos de Java. Alors que Java est un language assez facile à maitriser, portable, et qui possède une floppée d'outils autour. Cela va du simple gedit/notepad, à eclipse. Si vous voulez faire du c#, soit vous devez prendre mono (avec son flou juridique vis à vis de M$), soit sous windows utiliser Visual Studio. L'outil de programation est propriétaire et payant (sauf Mono). L'ouverture et le mode de fonctionnement de SUN pour la propagation de son language à permit une libéralisation de l'envirronement de dev autour du language, ce qui n'est pas forcément le cas pour d'autres languages

            Pour en revenir sur le sujet de l'article à savoir Nuxeo, avec java, je suis sûr que leur solution tourne sur la majorité des plates-formes actuel, à savoir :
            Windows, Linux et Mac.
            • [^] # Re: Java = le diable ?

              Posté par (page perso) . Évalué à 2.

              L'outil de programation est propriétaire et payant (sauf Mono).
              Eh y'a quand même des outils gratuits comme Visual Studio Express, ou bêtement le framework .NET lui même qui contient tous les compilos, et même des outils libres comme l'IDE SharpDevelop. Visual Studio n'est pas indispensable, pas plus que ne l'est netbeans ;)
            • [^] # Re: Java = le diable ?

              Posté par . Évalué à 2.

              Compiler une JVM ?
              Tant que ta plate-formes aie une JRE fonctionnelle, il n'y a pas de problème.

              Une JVM, c'est un interpréteur pour le bytecode Java. Java tourne sur une plateforme s'il est possible de compiler une JVM sur cette plateforme.

              Tu peux remplacer "Java" dans la phrase ci-dessus par n'importe quel langage, que ce soit Python, Ruby, Perl, Lisp... c'est toujours valable. Je ne sais pas sur combien de plateformes on trouve l'interpréteur Python, mais je doute que ce soit moins portable que Java. Déjà, c'est disponible sous Windows, les variantes de Linux et de BSD, MacOS X compris. Le grand succès marketing de Sun, ça a été de faire croire que le concept de machine virtuelle était propre à Java.

              Au final, quand tu dis que Java est le plus portable des langages de dernières générations, quelque chose me dit que tu ne le compares qu'à .NET. Il y a même un paquet de langages de haut niveau (et plus novateurs) qui sont compilables, au choix, en natif ou en bytecode Java, et qui sont par conséquent au moins aussi portables que Java. Voir par exemple OCaml, mais ce n'est pas le seul.
              • [^] # Re: Java = le diable ?

                Posté par . Évalué à 0.


                Une JVM, c'est un interpréteur pour le bytecode Java. Java tourne sur une plateforme s'il est possible de compiler une JVM sur cette plateforme.


                Attend, la il y a un truc qui cloche :

                - JRE = java runtime environnement = une JVM
                - JDK = java dev kit = un "compilateur java"

                Donc quand tu dis compiler une JVM, je comprend donc "avoir une JVMdisponible pour cette plate-forme" qu'elle soit SUn ou pas.

                Je sais très bien que le concept de machine virtuel n'est pas né avec Java. Cependant, dans les derniers language né, c'est lui qui est le plus avancé (de mon point de vue). Je m'excuse d'avance, mais perl, python ne sont pas pour moi des languages de haut niveau, plus de script. D'ailleurs je pense que l'on dira plus facilement un script perl qu'un programme perl. Je ne veux pas dire que perl, c'est de la ...., mais, moi développeur, je veux un language facile, portable, graphique inclus (GUI). Je m'en fout (un peu) de la lourdeur de Java, la portabilité du bytecode est le couteau à double tranchant de Java.

                Et pour terminer sur le thème de la lourdeur, n'y-a-t-il pas du java dans le téléscope hubble ?
                • [^] # Re: Java = le diable ?

                  Posté par . Évalué à 2.

                  Je m'excuse d'avance, mais perl, python ne sont pas pour moi des languages de haut niveau

                  Tu fais bien de t'excuser parceque tu ne dis pas en quoi ils sont de moins haut niveau que java. Voici la définition indiquée dans wikipedia
                  qui permet au programmeur de s'abstraire de détails inhérents au fonctionnement de la machine, ceux-ci étant pris en compte lors de la compilation. Il permet de manipuler des concepts bien plus élaborés, mais empêche la gestion de certains de ces détails.


                  Hors c'est justement parceque java oblige à se soucier de trop de détails qu'il est moins facile que python. (et que d'autre diront que c'est un avantage car ça oblige à être plus rigoureux). cqfd.
                • [^] # Re: Java = le diable ?

                  Posté par . Évalué à 2.

                  Donc quand tu dis compiler une JVM, je comprend donc "avoir une JVM disponible pour cette plate-forme"

                  On est d'accord. Que ce soit Java ou Python, il faut un interpréteur, mais sur toutes les plateformes où un interpréteur existe, c'est "portable" :)

                  mais perl, python ne sont pas pour moi des languages de haut niveau, plus de script.

                  Je n'ai jamais vu personne faire une distinction entre "de haut niveau" et "de scripts". On fait plus souvent une distinction entre langage compilé et langage de scripts, mais même ainsi la séparation est très arbitraire. Dans la catégorie des langages qu'on appelle généralement "de scripts", on trouve quand même Ruby, pour lequel il est difficile de prétendre qu'il est de plus bas niveau que Java.

                  Note qu'en disant que Java n'était pas "le plus portable", je ne voulais pas le critiquer, simplement souligner qu'on trouve des langages récents, novateurs et libres qui sont au moins aussi portables que Java. Après, à chacun de choisir selon ses goûts, on peut aussi faire du Java en n'utilisant que des outils libres.

                  (À titre personnel, j'avoue détester ce langage. Mais tout le monde s'en fiche, et ils ont raison.)
                • [^] # Re: Java = le diable ?

                  Posté par . Évalué à 8.

                  Cher M. Purnelle,

                  Je m'excuse d'avance, mais perl, python ne sont pas pour moi des languages de haut niveau, plus de script. D'ailleurs je pense que l'on dira plus facilement un script perl qu'un programme perl. Je ne veux pas dire que perl, c'est de la ...., mais, moi développeur, je veux un language facile, portable, graphique inclus (GUI).


                  Puisque le fait de s'excuser par avance semble permettre de se dédouaner de dire n'importe quelle connerie, je souhaite donc m'excuser par avance, mais tiens à vous signaler que vous êtes au mieux un troll velu, au pire un idiot et un incompétent dont je ne recommanderai le CV à personne.

                  La première phrase à elle seule démontre clairement votre totale ignorance en matière de théorie des langages. Un langage de script EST un langage de haut niveau. Un langage de haut niveau est un langage qui donne un plus haut niveau d'abstraction que le langage machine. Cela permet de ne pas avoir à se soucier de certains détails dépendants du matériel tels que par exemple, l'allocation de mémoire, les registres, la pile d'exécution, etc. En général, plus le niveau est haut, plus le langage est spécialisé dans une tâche particulière.

                  Le terme "langage de script" est plus difficile à définir. Initialement, un langage de script était un langage permettant de joindre des composants déjà existants ou d'automatiser certaines tâches manuelles. Souvent dotés d'une syntaxe plus compacte, ils sont de-facto des langages de haut niveau. Le consensus actuel (et la bêtise ambiante qui plombe l'industrie informatique en général) tend à faire l'amalgame entre langage de script et langage interprété.

                  À lire votre commentaire, on peut légitimement se demander si votre expérience avec Perl ne se resume pas qu'à des oneliners pour parser des logs apache. Si vous avez un jour l'occasion de rencontrer un programmeur de chez Amazon, j'aimerai être là pour le voir vous botter le cul lorsque vous lui parlerez de ses "scripts perl".

                  Vos désirs de developpeurs semblent légitimes, et en me basant sur vos propres critères, j'en viendrai presque à m'étonner de votre attachement à Java. Soit, la "facilité" d'un langage reste une notion que vous aurez, je l'espère, l'occasion de m'expliquer. À défaut d'avoir la votre, je vais utiliser ma définition.

                  Un langage "facile" serait un langage qui me permette simplement de manipuler des structures de données, de pouvoir transcrire sans verbosité excessive aussi bien des algorithmes simples que complexes, qui soit suffisamment flexible de manière à ce que tout changement inopiné des spécifications ne soit pas un casse-tête à implémenter. Perl correspond parfaitement à cette définition en ce qui me concerne. J'attends toujours que l'on me montre comment réaliser simplement une transformation Schwartzienne en Java.

                  <digression>
                  Les commentaires concernant la "lisibilité" de Perl faisant référence indirectement ou non à l'exercice stylistique connu sous le nom de perl golf au sein de la communauté Perl ne m'intéressent pas. On peut écrire du code imbitable dans n'importe quel langage. Ce n'est pas parce que l'Obsfucate C existe que les développeurs en font usage dans les sources du noyau Linux.
                  </digression>

                  Si par portabilité, vous parlez du nombre de plateformes où votre application peut tourner, je suis heureux de vous annoncer que Perl est disponible sur un plus grand nombre de plateformes que Java. Si vous évoquez le fait que le même code tourne sur plusieurs plateformes, Java effectivement a un léger avantage (pour autant que JNI ne soit pas utilisé) comparé à Perl par exemple (qui souffre du même problème si l'on utilise XS).

                  Le problème de l'interface graphique en Perl existe en effet, mais est loin d'être insurmontable, des bindings existent pour Tk, WxWidgets, GTK, Qt, et d'autres encore. À ma connaissance, Python souffre moins de ce problème et possède des bindings avec de nombreux toolkits. Le fait que Microsoft ait embauché le créateur d'IronPython est un plus indéniable pour l'adoption du langage sous Windows.

                  Java a certainement sa place dans le monde des langages informatiques, mais est à des années lumières d'être un langage parfait, n'en déplaise à certains fanatiques vociférants. Nombreux sont les langages qui offrent des fonctionnalités puissantes que Java, au mieux, implémente de manière bancale ou simplement ignore. Je ne puis que vous inviter à essayer d'autres langages, dans d'autres familles pour vous en rendre compte. Une connaissance, sans aller jusqu'à devenir un guru s'entend, de Smalltalk, Prolog ou Lisp pour n'en citer que quelques uns vous apportetait des outils supplémentaires à vos habitudes de programmeur et vous éviterait probablement le ridicule sur des forums publiques.

                  Cordialement,

                  G.
                  • [^] # Re: Java = le diable ?

                    Posté par . Évalué à -2.

                    >On peut écrire du code imbitable dans n'importe quel langage.
                    Non pas en Python.
                    • [^] # Re: Java = le diable ?

                      Posté par . Évalué à 2.

                      Mon Dieu, mon Dieu. La propension qu'ont certains à être stupide et à vouloir le faire savoir reste pour moi quelque chose de fascinant.

                      Passons. Dans un désir d'éduquer les plus idiots, je tiens à faire partager ce petit morceau de code trouvé en une minute grâce à GrandMa' Google. Attention, Mr. gallenza, ceci pourrait ébranler les fondements même de votre conception de la réalite. Je vous conseille donc de vous accrocher fortement à un objet qui vous tient à coeur. Un nounours, une tétine ou un doudou feront très bien l'affaire.

                      < -- snip -- >
                      #!/usr/local/bin/python

                      f = lambda x:map(lambda o:(map(lambda c:map(lambda l:
                      o.__setslice__(l[0],l[1],l[2]),([o[2]+3,o[2]+4,[o[0]]],[0,3,[o[1],
                      reduce(lambda x,o:x+o,o[:2]),o[2]+1]])),range(x)),o)[1],[[1,1,0]+
                      range(x)])[0][3:]

                      print f(20)
                      < -- snip -- >

                      Lisible, hein?

                      Je reste sur ma position.

                      G.
                      • [^] # Re: Java = le diable ?

                        Posté par . Évalué à -3.

                        ça tombe bien personne n'utilise reduce, map et lambda; Guido compte les faire disparaitre de python et la personne ayant pondu ça ira programmer avec un autre langage ^^
                        • [^] # Re: Java = le diable ?

                          Posté par . Évalué à 3.

                          Vraiment fascinant, en effet. On va faire court.

                          http://www.python.org/doc/essays/ppt/accu2006/Py3kACCU.ppt [Slide 14]

                          - Last year, I said I wanted lambda to die
                          - We still don't have a better version
                          - So lambda lives!

                          Concernant votre généralisation sur la non-utilisation de reduce, map et lambda, je me retiendrai de commenter.

                          S'il vous plaît, cessez. Cela vous dessert.

                          G.
                          • [^] # Re: Java = le diable ?

                            Posté par . Évalué à 0.

                            Arrête d'être condescendant t'es pénible.
                            Depuis des années Guido prépare le terrain en expliquant à qui veut l'entendre que son seul gros regret dans python ce sont les lambda, mais en fait par lambda il sous-entend toutes le reste des fonctionnalités pseudo-fonctionnelles de python, que ça te plaise ou non.

                            About 12 years ago, Python aquired lambda, reduce(), filter() and map(), courtesy of (I believe) a Lisp hacker who missed them and submitted working patches. But, despite of the PR value, I think these features should be cut from Python 3000.
                            • [^] # Re: Java = le diable ?

                              Posté par . Évalué à 4.

                              Bon, on va reprendre depuis le debut.

                              - On ne peut pas écrire du code imbitable en Python.

                              Faux! Quand bien même tu refuses d'accepter l'exemple de l'obfuscation, un développeur a toujours la possibilité d'écrire des fonctions ayant pour nom un ou deux caracteres. Idem pour les noms de variables. Même si le langage impose des restrictions sur la présentation pour améliorer la lisibilité, le code reste imbitable. Et cela est valable pour n'importe quel langage!

                              - Personne n'utilise lambda() ...

                              Faux! L'extrait du blog de Guido van Rossum (datant d'il y a 18 mois, pas moins) que tu donnes est ridicule. Il ne dit rien des motivations de GvR pour retirer ces fonctions. Le principal grief qu'il a contre celles-ci sont d'ordre esthétique : pour le néophyte, ces fonctions peuvent être déroutantes, et pour chacune d'elles il donne une syntaxe moins 'fonctionnelle' produisant un résultat équivalent.

                              Il semble cependant que la tétrachiée de commentaires à cette entrée l'ait soit convaincu, tout du moins forcé à revenir sur sa décision.

                              « After about a year of attempts to convince people that lambda had to die or be improved, I gave up. Lambda lives. See http://mail.python.org/pipermail/python-dev/2006-February/06(...) for details. »

                              Ne t'en déplaise, il semblerait qu'une minorité (suffisament bruyante cependant) utilise lambda(), map() et consorts en Python.

                              - Le rejet de programmation fonctionnelle par GvR

                              J'avoue manquer d'information sur le processus de validation de ce qui rentre et de ce qui sort de Python à chacune des releases. Cependant, l'incorporation du PEP-309 dans Python 2.5 --qui permet de faire du currying via 'partial'-- me laisse penser que la programmation fonctionnelle en Python a encore de beaux jours devant elle.

                              Pour finir, le ton condescendant. C'est généralement le ton que j'utilise lorsque je lis des affirmations non fondées, non réfléchies ou emprunte d'une bêtise incommensurable comme tu as pu en écrire. Je puis t'assurer que j'aurais utlisé une formulation crue bien plus tôt si j'avais su que cela avait ta préférence.

                              G.
    • [^] # Re: Java = le diable ?

      Posté par . Évalué à 0.

      Tu tends un peu le baton pour te faire battre là...

      Malgré le fait que ce language est propriétaire

      Quand vous parlez à quelqu'un pur microsoft, python il ne connait pas, Java il connait
      Sauf que ironpython c'est maintenant chez microsoft, c'est quand même incroyable qu'en tant que développeur python on se sente maintenant plus proche de microsoft que de java !

      pour les performances, les dernières versions de java se sont grandement amélioré de ce côté

      Tu confirmes donc qu'il y a des problèmes de perfs !

      Pour info, un JDK 6 est sortit !

      Qui sous-entend qu'il faut courir après la dernière version pour avoir quelque chose de potable ?

      En fait on s'en fout que java soit le diable ou pas, ce qui dérange dans cette news ce n'est pas tant qu'ils aillent chez java (ils auraient été chez .net ou autre ça aurait été pareil) mais plutôt qu'ils laissent tomber python.

      Ceci dit d'après ce que j'ai compris c'est plus zope que python qui dérangeait...
  • # Troll Pyhton vs Java mis à part

    Posté par . Évalué à 6.

    Si on recentrait un peu le débat sur le logiciel en question .

    Stéphane , peux tu nous parler un peu plus des fonctionnalités de Nuxeo.

    Il s'agit d'un ECM
    http://www.nuxeo.com/solutions/ecm/
    mais on en apprend guère plus sur Nuxeo si ce n'est sur son architecture.

    Votre logiciel couvre plusieurs aspect mais peut il se mesurer au logiciels les plus en vue dans chacun de ses domaines ?

    Au niveau de la GED, qu'apporte t'il de plus que Documentum ou Alfresco ?

    Pour les CMS, qu'est ce qui le différencie de solutions comme SPIP .

    Pour le collaboratif que propose t'il ? (calendrier, instant messaging, ...)

    Ce n'est pas une question piège.
    • [^] # Re: Troll Pyhton vs Java mis à part

      Posté par . Évalué à 2.

      Bonsoir,

      Merci de recentrer.

      Au niveau architecture, il commence à y avoir pas mal d'informatio disponible ici: http://www.nuxeo.org.

      Au niveau architecture, Nuxeo Runtime et Nuxeo Core sont très intéressants et nous en sommes fiers! :-)

      Au niveau fonctionnel, un des principal intérêt et la fusion entre les fonctions de collaboration et de GED. Et quelques suprises qui devraient arriver dans les prochains mois/semaines tel que l'intégration profonde du mail de l'instant messaging, de la signature électroniques, etc.

      Nous sommes tout a fait disponible pour expliquer plus en détail tout cela.


      Bonne soirée,

      EB.
      • [^] # Re: Troll Pyhton vs Java mis à part

        Posté par . Évalué à 2.

        Merci d'avoir pris la peine de me répondre mais je reste un peu sur ma faim.
        Un client ce qui l'intéresse avant tout ce sont les fonctionnalités. Ce qu'il y a sous le capot l'interesse moins.

        Votre site met en avant l'architecture mais ne présente pas ce que Nuxeo peut offrir au client. On n'y trouve que quelques généralités (ou alors faut vraiment bien chercher).

        Je comprend que la release ne soit pas encore sortie mais il faut un minimum à se mettre sous la dent. (une démo, un livre-blanc, des screenchautes, ...).
        Sinon ce n'est pas la peine de faire de la comm. Vous auriez tout aussi bien pu attendre la sortie définitive du produit.
        Même pour attirer des developpeurs c'est "leger". On n'a pas tous envie de récuperer la dernière snapshot SVN et de s'installer un serveur d'appli pour comprendre à quoi ca sert.
        • [^] # Re: Troll Pyhton vs Java mis à part

          Posté par . Évalué à 4.

          Je me réponds à moi même.
          Désolé je n'étais allé faire un tour que sur nuxeo.org où l'on ne parle que de Nuxeo 5
          alors que votre produit actuel est Nuxeo CPS (dernier lien).
  • # \o/ FOUTAISES

    Posté par (page perso) . Évalué à 10.

    non ? bon ok :)
  • # C'est bien, ils progressent.

    Posté par (page perso) . Évalué à 5.

    C'est bien ... peu à peu ils passent à des choix technologiques qui non seulement ont fait leur preuve, mais en plus permettent une meilleur extension, évolution, maintenance et montée en charge.
    Attention, je ne dénigre pas Python, seulement Zope ne m'a jamais convaincu comme serveur d'application lorsqu'il s'agit de créer de véritables applications d'entreprises devant monter bien en charge avec de grosses fonctionnalités, notamment d'EAI. Sinon, les concepts derrière Zope sont intéressants.

    Bon, maintenant, à quelle version ils finiront par passer sur un produit qui apporte un véritable gain et une meilleur expressivité : Smalltalk + seaside ?
    (Pour voir ce que l'on peut faire avec et rapidement, voir la démo
    de http://dabbledb.com/ .)

    Parce que Java (je fais quasiment que ça dans mon boulot) c'est bien ... mais c'est lourd.

    Sinon, c'est bien beau de suivre la mode ... faudrait peut-être mieux qu'ils choisissent vraiment l'outil en fonction des besoins, des impératifs et des contraintes ! Mais bon, ça demanderait alors une analyse de tout ça en amont, voir une analyse métier ... ce que ne fait pratiquement jamais les entreprises et ceci aboutit à un bordel pas possible avec des modes d'urgences mal gérés.

    Note : je sens que je ne vais pas me faire des amis ;-)
    • [^] # Re: C'est bien, ils progressent.

      Posté par . Évalué à 3.

      Déjà si tu parle de python on te regarde avec de grand yeux,
      mais là, avec smalltalk, on risque de te rire au nez (expérience vécue),
      et c'est domage car c'est un excellent langage.
      Surtout, ne parle jamais de lisp, ou même d'un autre langage fonctionnel, tu risquerait de te faire virer.
    • [^] # Re: C'est bien, ils progressent.

      Posté par (page perso) . Évalué à 4.

      Attention, je ne dénigre pas Python, seulement Zope ne m'a jamais convaincu comme serveur d'application lorsqu'il s'agit de créer de véritables applications d'entreprises devant monter bien en charge avec de grosses fonctionnalités, notamment d'EAI.


      Puis:

      Sinon, c'est bien beau de suivre la mode ... faudrait peut-être mieux qu'ils choisissent vraiment l'outil en fonction des besoins, des impératifs et des contraintes !


      Le pdg à écrit: https://linuxfr.org/comments/759589.html#759589

      "c'est une horrible nouvelle pour les performances": je ne vois pas ce qui te fait dire ca. Si on fait ce switch, c'est aussi parce qu'on pense avoir touché le plafond en terme de performance de Zope sur des grosses applications. Donc on pense bien, et les mesures actuelles le montrent, arriver à des gains très nets en performances et en scalabilité.


      Pour moi, techniquement parlant, cette explication est suffisante pour justifier un changement.

      Quand tu arrives aux limites de la techno que tu utilises en terme de perfs tu as 2 choix:
      * tu ne vas pas plus loin (pas de nouveau client, tu expliques aux anciens qu'ils ne pourront plus utiliser le truc, ...)
      * tu changes.

      My 2 cents.
  • # J'arrête aussi le python mais pour Visual Basic

    Posté par . Évalué à 3.

    Moi aussi j'arrête le python , mais pour Visual Basic, le python c'était bien avant, mais depuis l'arrivée du web2.0 il faut avouer que c'est complètement périmé.

    Voici mon communiqué de presse officiel :

    http://www.toonux.org/news/hoax-toonux-arrete-python-pour-vi(...)
  • # La pub débarque sur linuxfr!

    Posté par . Évalué à 2.

    Dans cette dépêche de première page, on apprend juste que nuxeo va passer de python à java pour son logiciel.
    "Va passer" donc ils n'ont même pas une version définitive à nous proposer mais c'est tellement vital pour le libre qu'il faut que tout le monde le sache.
    Ca me fait penser aux communiqués où on apprend que telle super boite va s'associer à telle autre super boite pour faire de supers trucs à l'avenir.
    Ce que je trouve le plus dommage, c'est qu'au final, cette dépêche se transforme en un rassemblement de gros bras de java (qui attendent gentillement que Sun tienne ses promesses de liberté) qui dénigrent le libre python au nom du soi-disant pragmatisme économique.
    Que nuxeo préfère passer à java parce qu'ils ne trouvent pas leur compte dans python / zope, je le conçoit aisément mais qu'il faille absolument passer une dépêche dessus, même si elle émane de Stéphane fermigier en personne, je trouve ça dérangeant.
    • [^] # Re: La pub débarque sur linuxfr!

      Posté par . Évalué à 7.

      En même temps, un logiciel libre qui change de plateforme, c'est pas si fréquent. Et de python vers Java, cela soulève quand même un paquet de questions bien légitimes, qu'on soit intéressé par l'une ou l'autre des technos.

      De plus, il y a peut-être ici des personnes ayant accumulé de l'expérience sur CPS et que cette news touche donc directement...
      • [^] # Re: La pub débarque sur linuxfr!

        Posté par . Évalué à 1.

        En même temps, un logiciel libre qui change de plateforme, c'est pas si fréquent.
        Ton affirmation est bien trop vague pour être vraie. Dans la constellation de logiciels libres qui existent, comment peux-tu être sûr qu'il n'y a pas de changement de langage de programmation. Je pense que nous avons tous au moins un exemple en tête même s'il s'agit d'un projet minuscule.
        De toute façon, ce qui est le plus intéressant, ce sont les raisons qui ont ammené à ce choix et ça, l'auteur s'est bien gardé de le faire dans la dépêche dans le plus grand respect du style des communiqués de presse. Il en parle dans les commentaires pour répondre à cette question.

        De plus, il y a peut-être ici des personnes ayant accumulé de l'expérience sur CPS et que cette news touche donc directement...
        Les personnes vraiment concernées et intéressées sont au courant depuis un moment puisque cette migration avait déjà été annoncée comme le dit plus haut Stéphane Fermigier.
    • [^] # Re: La pub débarque sur linuxfr!

      Posté par . Évalué à 2.

      si tu lis les commentaires, tu verras que ce n'est pas juste un plan, une bonne partie du code Java est dispo sur le CVS !

      http://about.me/straumat

      • [^] # Re: La pub débarque sur linuxfr!

        Posté par . Évalué à 0.

        Je ne remet pas en cause l'existence de ce code ou l'engagement de nuxeo dans le libre. Je constate juste que nuxeo reste quand même une entreprise et que cette dépêche ressemble fortement à de la publi-information d'autant plus que les raisons qui ont poussé ce changement sont en grande partie dues à des choix commerciaux comme expliqué dans leur faq.
        Je cite :
        L'utilisation de Python comme principal langage de développement et l'appartenance à sa communauté vont nous manquer, mais notre but est avant tout de satisfaire nos clients et d'atteindre l'excellence. En effet, nos clients et nos partenaires nous ont rapporté avoir d'importantes difficultés à trouver ou former des développeurs Python/Zope compétents.


        Je ne suis pas un intraigriste du libre mais je pense qu'il faut que les choses soient claires pour que nos idéaux (je suppose que pas mal de personnes ici croient au logiciel libre...) ne se diluent pas dans le flou artistique créé par ce genre de dépêches.
        Je milite pour des dépêches avec un ton plus frais (pas genre communiqué de presse) et plus vrai (python, zope peu plus. Trop galère. On passe à Java, un vrai langage, ça défrise quelqu'un?) sur linuxfr.
        • [^] # Re: La pub débarque sur linuxfr!

          Posté par (page perso) . Évalué à 3.

          Tu es doublement de mauvaise foi:

          1. Tu ne cites qu'un bout de la FAQ, celui qui t'arrange. Les raisons du changement sont doubles, techniques et commerciales, et, contraîrement à ce que tu as l'air de penser, les deux ne s'opposent pas. L'excellence technique n'a de sens que si elle peut être utilisée en vrai, dans le contexte d'un système d'information, avec des équipes à formers, etc.

          2. Ta citation n'est pas extraite de la dépêche de LinuxFR, mais de notre site. La dépêche en elle-même se focalise sur les aspects techniques de notre annonce, les produits libre et les technologies ouvertes que l'on utilise, le fait que le code est disponible et qu'on a commencé à releaser un module intéressant (en attendant la suite...).

          Donc non seulement je ne suis pas d'accord avec toi, mais l'intérêt suscité par cette dépêche dans la communauté LinuxFR (108 commentaires en 1 jour 1/2, ca me parait pas mal du tout :) ) m'incitent à renouveler l'initiative lorsque nous annoncerons de nouveaux modules, en suivant la roadmap (http://www.nuxeo.org/sections/about/roadmap ), à commencer par Nuxeo Core et Nuxeo EP.

          Merci à tous pour vos commentaires, et à certains pour votre soutien.

          Amitiés à tous ceux qui me connaissent.

          S.
          --
          Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

          "There's no such thing as can't. You always have a choice." - Ken Gor

          • [^] # Re: La pub débarque sur linuxfr!

            Posté par . Évalué à 4.

            A propos de roadmap et de phrase sortie du contexte, comment allez vous tenir une roadmap en allant 5 fois moins vite ?
            Java sera toujours 5 fois plus long à écrire dixit un ingénieur de chez vous dans un interview de jdn.

            Bon, je déconne hein, je sais bien que ce n'est pas la vitesse de pissage de ligne de code qui compte mais la richesse des composants. Je disais ça juste pour dire à ceux qui ne savent pas quoi faire de ce we de taper nuxeo java python sur un moteur de recherche, c'est assez marrant, enfin pas pour tout le monde. Bon courrage quand même.
            • [^] # Re: La pub débarque sur linuxfr!

              Posté par . Évalué à 4.

              Faut savoir aussi que les temps changent... rien qu en utilisant Spring, on a grandement réduit le nombre de lignes de code à taper. Si on compare notre java d'aujourd'hui à notre java d'il y a deux ans... ça n'aurait rien à voir.

              http://about.me/straumat

              • [^] # Re: La pub débarque sur linuxfr!

                Posté par . Évalué à 2.

                Les temps changent vraiment très très vite alors, l'interview dont je parle date de cette année 2006...
                Mais donc, si ce qui a été écrit y a deux ans n'a rien à voir avec ce qui est écrit aujourd'hui, ça va donner quoi dans deux ans ? Bonjour la pérénité des applis et les coûts de formation des developpeurs !
                Faites un peut attention avec ce genre d'arguments à la lessive qui lave plus blanc, c'est a double tranchant.
                • [^] # Re: La pub débarque sur linuxfr!

                  Posté par (page perso) . Évalué à 5.

                  Bah oui, les temps changent vite dans le monde de l'informatique, et comme on dit aussi, il n'y a que les imbéciles qui ne changent pas d'avis (en particulier quand la réalité a changé entre temps).

                  Ce qu'on a toujours dit, et qui ne change pas, depuis l'article fondateur de John Ousterhout en 1998 (http://en.wikipedia.org/wiki/John_Ousterhout ), Scripting: Higher Level Programming for the 21st Century (http://home.pacbell.net/ouster/scripting.html ), c'est qu'il y a une place pour les deux types de langages, les langages de scripts et les langages de programmation de composants (qu'il appelle lui "langages de programmation système"), et que les deux sont complémentaires:


                  Scripting languages, on the other hand, have actually generated significant software reuse. They use a model where interesting components are built in a system programming language and then glued together into applications using the scripting language. This division of labor provides a natural framework for reusability. Components are designed to be reusable, and there are well-defined interfaces between components and scripts that make it easy to use components.


                  (Là c'est Ousterhout qui parle).

                  Donc la question n'est pas: tel langage est meilleur que tel autre, mais tel langage (+ l'ecosystème qui va avec, les librairies et les outils de développement, notamment) est plus adapté que tel autre à tel type de problème. Notre métier, c'est l'ECM, et pour faire des composants d'ECM, le meilleur choix aujourd'hui, à notre humble avis, c'est Java, indépendamment des qualités que Python (ou Ruby, ou Groovy, ou JavaScript/ECMAScript) garde par ailleurs. Ces composants d'ECM sont ensuite assemblés, configurés, scriptés, en utilisant des outils plus souples, notamment des descripteurs de types de documents (ex: schémas XML), de formulaires (ex: XForms), des fichiers de configuration de composants (XML), des règles métier, des workflows (ex: BPEL), des scripts.

                  S.
                  --
                  Stefane Fermigier, PDG, Nuxeo - http://www.nuxeo.com/

                  "There's no such thing as can't. You always have a choice." - Ken Gor

                • [^] # Re: La pub débarque sur linuxfr!

                  Posté par . Évalué à 2.

                  Je n'ai pas à faire attention, c'est la réalité.. On change très souvent de technologies et mes développeurs passent un temps très important à se former. Là, par exemple, on vient de passer à Google Web Toolkit ( http://www.scub.net/blogs/straumat/?postid=4 ) alors qu'on était passé il y a pas très longtemps à JSF...

                  http://about.me/straumat

                • [^] # Re: La pub débarque sur linuxfr!

                  Posté par . Évalué à 3.

                  Clap Clap !
                  La fameuse interview de Tarek Zadié.
                  Afin que tout le monde puisse décrypter l'article en entier
                  http://developpeur.journaldunet.com/itws/060208-itw-nuxeo-zi(...)

                  J'ai moi aussi quelques extraits savoureux sortis de leur contexte


                  Le premier défaut vient de sa conception : il s'agit d'un langage dynamique et interprété donc il est logiquement plus lent.

                  Ca aide pas les performances ca. Derrière la "publi-information" Stefane a aussi donné des raisons techniques: Zope a atteint ses limites.
                  Ah et Zope c'est basé dur ZODB. Ca en est oû les SGBDOO aujourd'hui ?


                  Des outils manquent, également. Delphi dispose d'un éditeur très performant, et excellent pour la productivité. Python ne dispose pas d'un EDI majeur. Il y a bien sûr PyDev sous Eclipse, ou Boa Constructor, mais ils restent en-dessous d'un outil propriétaire.

                  Bon ben c'est vrai on est hyper productif avec python pour prototyper, mais à un moment faut industrialiser un peu: génération de code, refactoring et design patterns. Ipyhton ca parait un peu leger pour tout ça.


                  Une blague récurrente du monde Python est : quand on est étudiant, on fait du Python, mais si on veut manger, on fait du Zope.

                  D'ailleurs, l'auteur de PyDev voudrait manger aussi
                  http://www.eclipseplugincentral.com/Web_Links-index-req-view(...)


                  Ah et pour reprendre un de tes propos

                  amha, la solution réellement pérenne qui se dessine en ce moment en python c'est wsgi, c'est à dire quelque chose d'extrèmement modulaire à base de librairies plutôt que de frameworks. Mais c'est jeune c'est vrai.


                  extrait de
                  http://www.python.org/dev/peps/pep-0333/


                  By contrast, although Java has just as many web application frameworks available, Java's "servlet" API makes it possible for applications written with any Java web application framework to run in any web server that supports the servlet API.

                  Il va falloir attendre combien de temps avant d'avoir un socle pérénne et pouvour se concentrer sur les performances et la montée en charge avec python ?
                  Aujourd'hui l'ensemble des frameworks passent par des ponts pour supporter la spec.
                  Ca doit encore booster les perfs ça
  • # Novell fait des émules?

    Posté par . Évalué à -1.

    Après le Novell Blog System voici le Nuxeo Blog Sytem!
  • # Conseil...

    Posté par (page perso) . Évalué à 1.

    Bonjour !

    Il se trouve que je dois gerer dans deux mois un projet qui va rassembler tout un tas de labos, plein de groupes scientifiques differents, etc pour definir et developer une infrastructure de mesures (definition soft et hard, puis construction du hard, dev du soft, puis deploiement), le tout en open source et de facon collaborative.

    Je pensais betement faire plein de wiki et des repertoires partages (c'est moche, mais c'est simple), mais en voyant le site de Nuxeo, je me dis que ca serait ideal pour mon projet.

    Donc avec Nuxeo, pour monter un projet collaboratif, il faut compter des millions d'euros et embaucher 30 personnes, ou bien je peux me faire un truc simple et qui marche bien assez rapidement et a peu pres tout seul? (j'ai besoin de gestion de documents partages, de gestion de versions, d'indexation, de gestion de forums ou autres espaces de discussion (entre autre discussions quand aux modifications apportees aux documents), puis de publication (lorsque les specifis sont figees)).

    Donc les CPS, c'est ce qu'il me faut?

    Mathias

Suivre le flux des commentaires

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