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é...).
Aller plus loin
- Nuxeo 5 (21 clics)
- La FAQ sur le passage à Java (15 clics)
- Interview de l'équipe technique sur InfoQ (1 clic)
- Le module Nuxeo Runtime (0 clic)
- Nuxeo CPS (14 clics)
# et bien...
Posté par Axel . Évalué à 9.
[^] # Re: et bien...
Posté par Prosper . Évalué à 5.
Ca compensera avec le gain en CPU.
# Et Python ça pue du Zope ?
Posté par dinomasque . Évalué à 4.
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 20 ans !
[^] # Re: Et Python ça pue du Zope ?
Posté par NiCoS . Évalué à 3.
- turbogears ( http://www.turbogears.com)
et d'autres frameworks web (pylons, etc.)
Pour zope, zope 3 devrait arriver mais je suis plus trop son actualité...
[^] # Re: Et Python ça pue du Zope ?
Posté par NiCoS . Évalué à 4.
Donc oui il reste des projets sur python.
Sur zope, il reste notamment plone ( http://www.plone.org )
[^] # Re: Et Python ça pue du Zope ?
Posté par Borax (site web personnel) . Évalué à 4.
Plus exactement, la version 3.3 stable vient de sortir il y a quelques jours.
Le produit a donc atteint une certaine maturité ; mais l'architecture complète du serveur d'applications a été totalement revue et on ne dispose pas encore d'autant de "produits" complémentaires que dans Zope2...
# Bonne nouvelle ?
Posté par Loïc Ibanez . Évalué à 1.
- 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 Prosper . Évalué à 10.
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 Yannick Beynet (site web personnel) . Évalué à 6.
[^] # Re: Bonne nouvelle ?
Posté par Nicolas (site web personnel) . Évalué à 0.
[^] # Re: Bonne nouvelle ?
Posté par Grumbl . Évalué à 1.
[^] # Re: Bonne nouvelle ?
Posté par Stefane Fermigier (site web personnel) . Évalué à 10.
"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 Nicolas (site web personnel) . Évalué à 4.
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 Stefane Fermigier (site web personnel) . Évalué à 9.
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 Nicolas (site web personnel) . Évalué à -1.
Tant mieux. Je pense que le battage se fait très bien sans moi.
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
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.
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 TImaniac (site web personnel) . Évalué à 0.
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 Stefane Fermigier (site web personnel) . Évalué à 9.
"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 Yannick Beynet (site web personnel) . Évalué à -10.
Je vous propose de faire un patch du kernel linux. Le passer en java serait aussi plus vendeur :)
[^] # Re: Bonne nouvelle ?
Posté par Alex G. . Évalué à 2.
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 jcs (site web personnel) . Évalué à 2.
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 stephwww . Évalué à 1.
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 jcs (site web personnel) . Évalué à 4.
Sinon il existe aussi le projet Harmony (http://incubator.apache.org/harmony/ ) qui couvre pour le moment environ 90% de l'API de Java 1.5
[^] # Re: Bonne nouvelle ?
Posté par clearstream . Évalué à 10.
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(...) :
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 boubou (site web personnel) . Évalué à 10.
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 TImaniac (site web personnel) . Évalué à 7.
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.
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 Nicolas (site web personnel) . Évalué à 0.
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 Eric Barroca . Évalué à 3.
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 Gabriel . Évalué à 1.
[^] # Re: Bonne nouvelle ?
Posté par Boa Treize (site web personnel) . Évalué à 10.
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 Loïc Ibanez . Évalué à 6.
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 Stefane Fermigier (site web personnel) . Évalué à 3.
"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 Loïc Ibanez . Évalué à 7.
[^] # Re: Bonne nouvelle ?
Posté par Stéphane Traumat (site web personnel) . Évalué à -1.
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 Larry Cow . Évalué à 4.
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 Stéphane Traumat (site web personnel) . Évalué à 5.
http://about.me/straumat
[^] # Re: Bonne nouvelle ?
Posté par TazForEver . Évalué à -3.
[^] # Re: Bonne nouvelle ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
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 Pierre Jarillon (site web personnel) . Évalué à 5.
Depuis le temps qu'on en parle, ça finit par ressembler à l'Arlésienne... Ou à Duke Nukem.
[^] # Re: Bonne nouvelle ?
Posté par Anonyme . Évalué à 2.
Mais bon c'est tellement plus simple de faire du Java-bashing ...
# Pierre Tramo a frappé !
Posté par tuiu pol . Évalué à 1.
# Bonne nouvelle :)
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
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 Stefane Fermigier (site web personnel) . Évalué à 3.
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 Stéphane Traumat (site web personnel) . Évalué à 1.
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 sylware . Évalué à -1.
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 vrm (site web personnel) . Évalué à 0.
L'intégrisme te dit merci.
[^] # Re: Harcèlement Marketeux
Posté par TImaniac (site web personnel) . Évalué à 2.
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 vrm (site web personnel) . Évalué à 0.
[^] # Re: Harcèlement Marketeux
Posté par Axel . Évalué à -9.
[^] # Re: Harcèlement Marketeux
Posté par left . Évalué à 3.
[^] # Re: Harcèlement Marketeux
Posté par Gniarf . Évalué à 3.
[^] # Re: Harcèlement Marketeux
Posté par - - . Évalué à 4.
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 wilk . Évalué à 6.
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 Calvin0c7 . Évalué à 4.
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 ... a little wood elfe . Évalué à 3.
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 Boa Treize (site web personnel) . Évalué à 3.
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.
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 Nelis (site web personnel) . Évalué à 4.
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.
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.
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 feth . Évalué à 9.
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 Alex G. . Évalué à 1.
[^] # Re: Former des développeurs Python/Zope compétents
Posté par wilk . Évalué à 2.
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 Alex G. . É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 sylware . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 8.
"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 sylware . Évalué à 0.
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).
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.
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 TImaniac (site web personnel) . Évalué à 5.
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 sylware . Évalué à -4.
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. 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?
Bof la portabilité binaire dans le monde du libre/open source. Pas la peine de revenir dessus.
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.
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.
Ç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.
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 TImaniac (site web personnel) . Évalué à 3.
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 Boa Treize (site web personnel) . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Former des développeurs Python/Zope compétents
Posté par sylware . Évalué à 1.
Hum... en tout cas, ce qui ce voit même pour un non initié, c'est ton aggressivité.
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.
Je n'ai jamais eu la prétention de détenir la vérité absolue. Et toi?
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.
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.
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".
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 TImaniac (site web personnel) . Évalué à 2.
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 sylware . Évalué à -1.
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?
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.
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.
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.
Cf messages précédents
.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 TImaniac (site web personnel) . Évalué à 3.
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 sylware . Évalué à -1.
Non, ça s'appelle des solutions hétérogènes C/C++/python/ruby.
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.
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 j'ai répondu à ta question.
Bon allez... je vais récupérer ce que j'ai dit dans un précédent message pour te faire plaisir
[^] # Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (site web personnel) . É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 :)
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 sylware . Évalué à -2.
C'est écrit en quoi une VM? Tu peux me le rappeler?
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:
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 TImaniac (site web personnel) . É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.
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 sylware . Évalué à -1.
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: 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: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.
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
Oh quelle est belle! Voir para précédent.
Zope est une VM? Jt persuadé d'avoir parlé de l'interpréteur de python.
Et le J2ME "éprouvé et testé"TM fut inventé....
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 TImaniac (site web personnel) . Évalué à 3.
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 sylware . Évalué à -2.
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 pris au mot! Damned! GNU/Linux ne respecte donc pas la philosophie d'unix.
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.
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).
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.
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.
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 TImaniac (site web personnel) . Évalué à 3.
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 sylware . Évalué à -1.
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.
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.
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
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.
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.
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.
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...
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.
"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.
...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.
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.
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 TImaniac (site web personnel) . Évalué à 4.
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 Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Former des développeurs Python/Zope compétents
Posté par golum . Évalué à 2.
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (site web personnel) . Évalué à 2.
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 Antoine . Évalué à 2.
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 golum . Évalué à 3.
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 sylware . Évalué à 0.
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é.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.
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.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.
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 golum . Évalué à 2.
Tu réponds tjs à coté de la plaque. Ce ne sont pas les briques qui sont inmaintanables , c'est leur assemblage.
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.
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 sylware . Évalué à -1.
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?
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
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 Stéphane Traumat (site web personnel) . Évalué à 4.
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 sylware . Évalué à 0.
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 Stéphane Traumat (site web personnel) . Évalué à 2.
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 Stéphane Traumat (site web personnel) . Évalué à 5.
Voila, ça va mieux ici maintenant.
http://about.me/straumat
[^] # Re: Former des développeurs Python/Zope compétents
Posté par sylware . Évalué à 1.
Ça fait plaisir à voir.
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: Former des développeurs Python/Zope compétents
Posté par sylware . Évalué à 0.
Mais de temps en temps ç'est bon de participer car cela me permet d'augmenter et d'améliorer mon arsenal argumentaire.
:)
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Stefane Fermigier (site web personnel) . Évalué à 4.
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 golum . Évalué à 2.
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 DPhil (site web personnel) . Évalué à 3.
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 artenum . Évalué à 1.
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 Boa Treize (site web personnel) . Évalué à 3.
- 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 artenum . Évalué à 3.
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 Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: Former des développeurs Python/Zope compétents
Posté par Antoine . Évalué à 5.
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 Stefane Fermigier (site web personnel) . Évalué à 3.
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 Stefane Fermigier (site web personnel) . Évalué à 2.
S.
"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 golum . Évalué à 3.
http://www.robert-tolksdorf.de/vmlanguages.html
[^] # Re: Former des développeurs Python/Zope compétents
Posté par wilk . Évalué à 1.
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.
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 wilk . Évalué à 5.
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 Alex G. . Évalué à 1.
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 Stéphane Purnelle . Évalué à 1.
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 gc (site web personnel) . Évalué à 6.
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 ben (site web personnel) . Évalué à 1.
[^] # Re: Java = le diable ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
http://about.me/straumat
[^] # Re: Java = le diable ?
Posté par gc (site web personnel) . Évalué à 1.
[^] # Re: Java = le diable ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
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 TImaniac (site web personnel) . Évalué à 3.
http://www.kaffe.org/ports.shtml
[^] # Re: Java = le diable ?
Posté par gc (site web personnel) . Évalué à 2.
[^] # Re: Java = le diable ?
Posté par gc (site web personnel) . Évalué à 3.
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 Calvin0c7 . Évalué à 2.
[^] # Re: Java = le diable ?
Posté par Calvin0c7 . Évalué à 3.
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 gc (site web personnel) . Évalué à 5.
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 lasher . Évalué à 3.
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 sylware . Évalué à -2.
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 Stéphane Purnelle . Évalué à 2.
Le C de base est portable, mais pas les implémentations GUI, excepté peut-être QT et GTK.
[^] # Re: Java = le diable ?
Posté par Yusei (Mastodon) . Évalué à 4.
[^] # Re: Java = le diable ?
Posté par Stéphane Purnelle . Évalué à 1.
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 TImaniac (site web personnel) . Évalué à 2.
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 Yusei (Mastodon) . Évalué à 2.
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 Stéphane Purnelle . Évalué à 0.
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 wilk . Évalué à 2.
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
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 Yusei (Mastodon) . Évalué à 2.
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" :)
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 Geraud . Évalué à 8.
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 gallenza . Évalué à -2.
Non pas en Python.
[^] # Re: Java = le diable ?
Posté par Geraud . Évalué à 2.
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 gallenza . Évalué à -3.
[^] # Re: Java = le diable ?
Posté par Geraud . Évalué à 3.
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 gallenza . Évalué à 0.
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 Geraud . Évalué à 4.
- 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 wilk . Évalué à 0.
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 golum . Évalué à 6.
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 Eric Barroca . Évalué à 2.
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 golum . Évalué à 2.
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 golum . Évalué à 4.
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 Damien (site web personnel) . Évalué à 10.
# C'est bien, ils progressent.
Posté par Miguel Moquillon (site web personnel) . Évalué à 5.
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.
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 Miguel Moquillon (site web personnel) . Évalué à 3.
Si ce n'est qu'après avoir rigolé sous mon nez, je leur ai ensuite montré ce que l'on pouvait faire avec ... et là ils ont moins rigolé. Certains ont même commencé à regarder un peu mieux seaside par exemple.
Mais bon, je ne me fais pas de bile, ça n'ira pas plus loin que la curiosité, mais au moins, ils auront été sensibilisé.
Pour les langages fonctionnelles, je leur ai parlé d'Haskell et depuis ils font des jeux de mots avec (du style haskell est bonne) !
[^] # Re: C'est bien, ils progressent.
Posté par Serge Stinckwich (site web personnel) . Évalué à 2.
Si Seaside t'intéresse, il y aura des démonstrations à la prochaine SmalltalkParty le 25 novembre : http://community.ofset.org/wiki/Smalltalk_Party_Paris_2006
[^] # Re: C'est bien, ils progressent.
Posté par Fernandes Hilaire (site web personnel) . Évalué à 1.
http://www.paulgraham.com/avg.html
[^] # Re: C'est bien, ils progressent.
Posté par vieuxshell (site web personnel) . Évalué à 4.
Puis:
Le pdg à écrit: https://linuxfr.org/comments/759589.html#759589
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 Olivier . Évalué à 3.
Voici mon communiqué de presse officiel :
http://www.toonux.org/news/hoax-toonux-arrete-python-pour-vi(...)
[^] # Re: J'arrête aussi le python mais pour Visual Basic
Posté par Alex. . Évalué à 0.
# La pub débarque sur linuxfr!
Posté par jeanmarc . Évalué à 2.
"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 Cali_Mero . Évalué à 7.
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 jeanmarc . Évalué à 1.
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 Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: La pub débarque sur linuxfr!
Posté par jeanmarc . Évalué à 0.
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 Stefane Fermigier (site web personnel) . Évalué à 3.
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 wilk . Évalué à 4.
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 Stéphane Traumat (site web personnel) . Évalué à 4.
http://about.me/straumat
[^] # Re: La pub débarque sur linuxfr!
Posté par wilk . Évalué à 2.
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 Stefane Fermigier (site web personnel) . Évalué à 5.
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:
(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 Stéphane Traumat (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: La pub débarque sur linuxfr!
Posté par golum . Évalué à 3.
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
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 ?
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.
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
extrait de
http://www.python.org/dev/peps/pep-0333/
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 sylware . Évalué à -1.
# Conseil...
Posté par Mathias Bavay (site web personnel) . Évalué à 1.
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
[^] # Re: Conseil...
Posté par Frédéric Lopez . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.