Posté par golum .
En réponse au journal lzma.
Évalué à 2.
notament moraceaux beacoup sucitte interret
C'est encore un journal humoristique qui nous evoque la théorie qui explique que l'ordre des lettres dans un mot n'a aucune importance pour la compréhension
Tu parles de protoypage en réduisant les langages dynamiques au rôle de langages de script.
Mais si on suit ton raisonnement , on prototype rapidement avec un tel langage et après on réecrit tout avec un langage fortement typé pour assurer performance et sécurité ( ou on regénère du code à partir d'UML). Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
La démarche que j'explicite est différente.
Tu prototypes sans contrainte de type au début ce qui te permet d'explorer différentes pistes ou architectures.Tu ecris tes tests unitaires en même temps mais tu introduis tes contrats progressivement et itérativement à mesure que ta conception se précise.
Tu ne livres pas de code non testé en prod puisque ton code est testé et validé par les contrats. Tu relâches les contraintes progressivement à mesure que la qualité de ton code s'améliore (tout comme les niveaux de logging ou les options de debug) et tu conserves malgré tout une plus grande souplesse durant la phase de conception.
Concernant les IDE :
Bien entendu les fonctionnalités que tu decris sont intéressantes même pour un langage dynamique. Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
La compilation JIT n'a d'utilité que pour des langages compilés comme Java.
L'expressivité et la concision de langage comme Python ou Ruby rendent moins crucial le besoin d'outils performants de refactoring, d'introspection.... Python a ses défauts inhérents à son design mais Java n'est pas exempt non plus.Relis mon post , j'ai bien précisé qu'il s'agissait d'un troll en réaction à tes à prioris
Bref tout est affaire de compromis entre performance et productivité.
Il faut donc définir sa stratégie en fonction des besoins.
Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
cf. notre thread sur http://linuxfr.org/comments/589849,1.html(...)
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ben c'est plus long que de ne pas l'indiquer
Il faut le mettre dans les declarations, dans les cast sans compter les
modificateurs à la pelle
On a inventé les génériques :
Pile maPile;
Quelle différence avec les templates C++
Tu es bien obligé de preciser le type d'objet lorsque tu l'utilises et donc tu as bien genéré un bytecode correspondant à ton "instanciation'"
Par exemple
List myIntList = new LinkedList(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = (Integer) myIntList.iterator().next(); // 3
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Ben justement avec un langage dynamique tu n'est pas obligé de passer par de tels artifices.
En Java tu peux aussi passer par des interfaces (plus propre conceptuellement) mais tu es de toute façon obligé de rajouter du code
(cf le lien sur la page de Bruce Eckel que j'ai donné)
Genre toi ....
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), ....
Absolument pas. Tu ne dois pas tester les types d'objets avec tes test unitaires
Tu définis un contrat qui est nettement plus rigoureux(précondition/postconditions , invariants) et va plus loin que la simple vérification de type.
Après tu valides le tout au moment de l'assemblage de tes composants.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme .... et on code APRES.
cf . contrats
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Des trolls comme ca tu les gardes parce que moi aussi je peux jouer, genre:
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
Ce qui est contre productif c'est d'être obligé de mettre des déclarations de type partout alors qu'on veut simplement tester une idée.
Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Moi je préfère me concentrer sur l'idée en utilsant un langage dynamique. Tu developpes ta classe et ton test unitaire associé en même temps..
Après comme devermineur tu peux utiliser les "contrats" qui apportent plus de garanties que le simple type checking.
Si tu veux vraiment pousser, tu disposes d'outils de verification pour les langages dynamiques comme pychecker pour python.
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Ca n'en est qu'une étape et je ne suis pas le seul à le penser http://fr.wikipedia.org/wiki/Compilation(...)
L'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...). Et n'oublions pas les optimisations à l'execution.
Bref la frontière entre langage interprété et complié est de plus en plus ténue en terme de performances
Par contre les inconvénients du typage fort subsistent. http://www.mindview.net/WebLog/log-0025(...)
Oui mais Corba ne te limite pas à l'usage d'un langage.
Corba c'est un protocole et un standard. Ce sont les impléméntations qui divergent.
Mono implémente son propre protocole dans son coin (.net remoting je suppose) tout comme RMI
Oué mais là ca n'a pas plus d'intérêt que C#/Mono qui a les mêmes avantage. ....
Et là ca ne te dérange plus de changer de techno et de langage, bizarre.
S'il Zope n'est pas soutenu il y a peut être aussi une raison. IBM aurait très bien pu se tourner vers autre chose que Java.
Ou peut être qu'il y a pas assez de business à se faire et qu'il ont déjà pas mal investi dans java au moment ou zope a démarré. Python a surtout évolué ces denières années.
D'ailleur c'est pas les mêmes qui on créé un tk graphique pour concurrencer un autre parce qu'il le trouvait "inadapté".
Qui sait ? ils finiront peut être par comprendre que c'est la même chose avec Java
Quant aux performance le JITs c'est récent et il n'est pas exclu que des progrès soient accompli avec python aussi. Ppour ;l'instant ce n'était pas la priorité mais chaque nllle version de Cpython améliore les perforamances sans compter le projet Psyco.
L'engouement de la communauté du libre est assez récent..
L'avantage avec python c'est son coté dynamique lui permet d'evoluer très vite.
Bref on est dans du plus pur troll.
Merci pour ton point de vue mais je crois que chacun campera sur ses positions
===> [ ]
RMI pas besoin, tu as Corba pour ca au moins c'est multilangage mais en cherchant un peu je suis sûr qu'on peut trouver.
Bref tu considères que le tout intégré c'est la panacée mais c'est aussi la contrainte d'où le succès grandissant des solutions LAMP
Concernant la table , les equivalences sont sur la plateforme Zope ce qui montre que cette plateforme est quasi- complète et donc intégrée.
Il faut aussi comprendre que la plateforme est dédiée au langage donc qu'il est nullement obligatoire de respecter le JSR??? pour proposer un serveur d'application équivalent.
L'avantage de python c'est qu'il est versatile et ne cible pas uniquement le monde du Web il s'exprime pleinenent sur le poste de travail car il s'intègre bien avec tout un tas de toolkit.
Quand t'as un programme qui doit effectuer des manips sur le poste, des fois le modèle de sécurité de Java, il est pesant
Quant aux parts de marché, Zope n'est pas soutenu par les mastodontes commme IBM BEA Sun & Co donc forcément ca ce ressent mais les entreprises appéecient de plus en plus la liberté y compris de technologie.
Sauf que ce que j'explique c'est que c'est en train de changer.
Je ne prétends pas pas que la technologie Zope/Python peut encore se mesurer aux grand comptes mais elle est en train de monter et ca pourrait changer.
Zope est un véritable serveur d'application et supporte le transactionnel.
La charge, je ne sais pas, je ne suis pas "Zope architect" ;-)
En tout cas je n'ai pas l'impression que l'audience de Gnu linux magazine (cf. sujet du journal) correspondent principalement à des "daicideurs" de grands comptes donc pour moi Zope/Plone/Python est une bonne alternative qui aurait pu figurer dans cette étude.
Bon d'accord y'a peut-être pas de transactionnel là-dedans mais il faut laisser le temps au temps, l'API J2EE ne s'est pas créée en un jour que je sache.
En plus ce sont peut-être pas les mêmes niches de marché.
Une PME n'a pas forcément les moyens de payer des millions pour une solution B2C de la mort qui tue en J2EE.
Le typage fort n'est pas forcément la panacée.
La philosophie de python est celle du unit testing qui est AMHA nettement plus sûr que le typage fort tout en luimitant les inconvénients au niveau du refactoring.
Certains projets proposent même d'introduire du typage fort progressivement dans ton code ce qui laisse la possibilté de prototyper rapidement et d'introduire plus de sécurité ensuite.
De même, il y a possibilté de faire de la programmation par contrat
de l'AOP, les decorator, bref Python n'a pas à rougir à cpté des dernières features Java.
Les interfaces: Python supporte l'heritage multiple mais mieux que ca on dispose du "duck typing" qui est encore plus souple. Si ton animal nage, court et fait coin coin c'est que c'est un canard, inutile de le préciser.
Les performances ne sont pas les seuls critères à prendre en compte dans le cadre d'un dévelopement, il y a aussi la productivité , la maintenabilité, la liberté, .....
Mais même sur ce point c'est contestable (J'avais vu des benchs surprnant sur ce point nottamment avec Psycho)
En outre il est toujours possible d'optimiser des parties de codes avec du compilé natif et les passerelles sont beaucoup plus aisée qu'avec du JNI.
Bref nous voilà parti dans un beau troll des familles.
Pour la conception, il suffit de voir les alternatives à J2EE qui fleurissent un peu partout y compris dans le monde Java pour comprendre que ce n'est pas la panacée notamment à cause de sa lourdeur. Et à la différence de Java ou C# , les évolutions y compris en terme de conception sont plus rapides avec Pyhton notamment en raison de son faible typage et de ses structures de haut niveau.
Que vous argumentiez en disant qu'il s'agit d'une technologie encore immature OK mais réduire Python à un simple langage de script alors là STOP.
Jython also has features that allow nearly transparent usage of existing Java code. Java packages can be imported into Jython as though they were Jython modules, and Java objects can be created using Jython object creation syntax. For the most part, you can use the Java objects in your Jython program exactly as though they were Jython objects
Immagine le truc, une personne fait plusieurs fautes dans son journal,. Les gens vont corriger son journal et personne ne va se concentrer le thêème de son petit journal...
Moi, c'est marrant !
Plus il y a de fautes et moins j'arrive à me concentrer sur thème du journal.
Après la bourse des droits à polluer à la City, je propose qu'on ouvre une bourse aux XP.
Ceux qui ont des XPs en rab plussoient ceux qui en manquent pour faire remonter leur niveau et en echange augmentent leurs quotas de journaux HS.
Après à il faut encore trouver des moyens d'empaqueter le tout sinon tu te retrouveras de nouveau avec une dépendance à un intreprète pour ton langage de script.
Bonne quête du Graal et poste un nouveau journal avec tes choix et motivations quand tu auras décidé. Ca peut servir aux autres
En fait tu dois choisir entre des toolkits graphiques portables genre Qt, GTK, Fox, wxWidget, ..... qui sont compilés nativement et qui offrent des wrappers
et des platetformes d'exécution (interprète, bytecode) qui offrent des mecanismes de partage d'objet et un support multilangage.
Tu as ainsi:
Mono/CLR
J2SE/JRE
Mozilla(XPCOM)/XulRunner
De même XulRunner n'est pas encore achevé ce qui t'oblige à installer FF ou Mozilla, sauf qu'avec Mozilla le langage de l'interface graphique t'es imposé: Javascript, même si tu peux te creer des composants dans différents langages via XPCOM. Le langage de description de l'interface graphique XUL (dtd XML) t'apporte une bonne séparation présentation/tratement. Le support à venir de SVG et la plateforme de déploiement (.xpi) peuvent être un plus.
Pour Java tu peux faire exactement la même chose que IronPython pour Mono, avec Jython et acceder ainsi aux librairies graphiques Java au travers d'un langage descript (Swing, SWT, Java2D).Le lagge
Dans tous les cas, ca necessite de connaitre le framework et son API à défaut du langage de référence.
[^] # Re: Bière open source
Posté par golum . En réponse au journal Un bière OpenSource. Évalué à 2.
Très peu pour moi, merci.
==========>[ ]
[^] # Re: Je vais encore dire des conneries...
Posté par golum . En réponse au journal Les auteurs de logiciels de P2P bientôt poursuivis ?. Évalué à 2.
ou peut être encore
"Le télechargement de correcteurs orthographiques et grammaticaux sous copyright est illégal" :D
# J'ai compris
Posté par golum . En réponse au journal lzma. Évalué à 2.
moraceaux
beacoup
sucitte
interret
C'est encore un journal humoristique qui nous evoque la théorie qui explique que l'ordre des lettres dans un mot n'a aucune importance pour la compréhension
~~~~~~~~>[ ]
[^] # Re: Ruby On Rails
Posté par golum . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
Mais si on suit ton raisonnement , on prototype rapidement avec un tel langage et après on réecrit tout avec un langage fortement typé pour assurer performance et sécurité ( ou on regénère du code à partir d'UML). Autant développer le prototype directement avec le langage cible même s'il est fortement typé quitte à sacrifier à la souplesse et à la productivité.
La démarche que j'explicite est différente.
Tu prototypes sans contrainte de type au début ce qui te permet d'explorer différentes pistes ou architectures.Tu ecris tes tests unitaires en même temps mais tu introduis tes contrats progressivement et itérativement à mesure que ta conception se précise.
Tu ne livres pas de code non testé en prod puisque ton code est testé et validé par les contrats. Tu relâches les contraintes progressivement à mesure que la qualité de ton code s'améliore (tout comme les niveaux de logging ou les options de debug) et tu conserves malgré tout une plus grande souplesse durant la phase de conception.
Concernant les IDE :
Bien entendu les fonctionnalités que tu decris sont intéressantes même pour un langage dynamique. Il n'empêche que pour des langages fortement typés, elles sont pratiquement indispensables pour compenser les manques de productivité.
La compilation JIT n'a d'utilité que pour des langages compilés comme Java.
L'expressivité et la concision de langage comme Python ou Ruby rendent moins crucial le besoin d'outils performants de refactoring, d'introspection.... Python a ses défauts inhérents à son design mais Java n'est pas exempt non plus.Relis mon post , j'ai bien précisé qu'il s'agissait d'un troll en réaction à tes à prioris
Bref tout est affaire de compromis entre performance et productivité.
Il faut donc définir sa stratégie en fonction des besoins.
Autant je t'accorde que Mono/J2EE s'impose pour des grands comptes, autant les solutions RAD type Ruby On Rails (Ai pas testé Ruby) me paraissent pertnentes lorsque le coût et le délai l'emporte sur les perfs.
cf. notre thread sur
http://linuxfr.org/comments/589849,1.html(...)
Si tu es interessé par les contrats tu retrouveras un excellent article de synthèse sur le defunt "Développeur Reference"
http://web.archive.org/web/20031204022702/www.devreference.net/devr(...)
Perso je l'utilise au travers d'un module POA dans le cadre d'un petit dev associatif et j'e ne m'en plains pas:
http://www.logilab.org/projects/aspects/documentation/contracts(...)
Mais tu trouveras sûrement de meilleurs equivalents pour .net, java ou ruby
[^] # Re: Ruby On Rails
Posté par golum . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 2.
Personne ne t'empêche de tester une idée dans un langage à typage "faible".
De plus c'est pas non plus super long d'écrire le type hein.
Ben c'est plus long que de ne pas l'indiquer
Il faut le mettre dans les declarations, dans les cast sans compter les
modificateurs à la pelle
On a inventé les génériques :
Pile maPile;
Quelle différence avec les templates C++
Tu es bien obligé de preciser le type d'objet lorsque tu l'utilises et donc tu as bien genéré un bytecode correspondant à ton "instanciation'"
Par exemple
List myIntList = new LinkedList(); // 1
myIntList.add(new Integer(0)); // 2
Integer x = (Integer) myIntList.iterator().next(); // 3
Tu généres en quelques sorte le bytecode de classe de ListInt.
Dans ma boîte on utilise massivement les templates C++ et je peux te garantir que ca dégrade pas mal les temps de compil, sans compter les problèmes de fabrication associés.Maintenant les genrerics en Java (depuis la 1.5 seulemen) je ne sais pas ce que ca donne
Mais n'importe quoi là ! Tu dis que c'est mieux d'avoir des piles de n'importe quoi, mais tu veux pas utiliser Object parcque ca apporte des erreurs ! Et ton n'importe quoi il va pas en apporter peut être ?
Ben justement avec un langage dynamique tu n'est pas obligé de passer par de tels artifices.
En Java tu peux aussi passer par des interfaces (plus propre conceptuellement) mais tu es de toute façon obligé de rajouter du code
(cf le lien sur la page de Bruce Eckel que j'ai donné)
Genre toi ....
Je te ferais remarquer que l'absence de typage fort et statique t'oblige à générer beaucoup plus de tests unitaires (puisqu'en gros tu dois te coltiner le boulot du compilo), ....
Absolument pas. Tu ne dois pas tester les types d'objets avec tes test unitaires
Tu définis un contrat qui est nettement plus rigoureux(précondition/postconditions , invariants) et va plus loin que la simple vérification de type.
Après tu valides le tout au moment de l'assemblage de tes composants.
Les test unitaires , ca sert uniquement à creer une suite de test et à t'assurer de la non régression.
C'est le contrat qui doit être exhaustif.
Autant le faire dès le début, ca sera toujours ca de fait. C'est comme .... et on code APRES.
cf . contrats
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Mais si ! Ca fait parti du boulot du compilateur, c'est un fait dans la plupart des compilo. Point barre. C'est fou ca vouloir faire croire aux gens que la réalité est ailleur.
C'est une étape obligée pour pouvoir compiler mais ce n'est pas la finalité de la compilation.
Psycho c'est joli mais c'est x86 only, tu pers la portabilité, bref tu perds une grosse partie de l'intérêt d'un langage de haut niveau interprété, ce n'est donc pas une solution, juste un cache-misère pour faire croire que Python est portable, performant et enlarge ton penis.
C'est vrai que des projets comme gcj ca n'a aucun intêret c'est pour ca qu'il existent. Java ca roxe
Des trolls comme ca tu les gardes parce que moi aussi je peux jouer, genre:
En fait je comprends maintenant pourquoi on a besoin de super IDE
de la mort qui tue en Java et pas en Python
Parce faire du refactoring, tout recompiler=>(compli incrémentale), completer toutes les déclarations de type ... toussa il faut mettre les moyens pour retrouver de la productivité.
[^] # Re: Ruby On Rails
Posté par golum . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 3.
Ce qui est contre productif c'est d'être obligé de créer des templates et de les instancier en générant du code pour pouvoir s'en servir (pile d'entier, pile de float, ...) alors qu'il est tellemnet plus simple de s'en servir sans contrainte de type.
De même disposer de pile de n'importe quoi (si je veux ajouter un entier puis un float) est plus interessant que d'être obligé de passer par des void* en C ou des Object ce qui revient à contourner le typage statique et ouvre la porte aux erreurs qu'on est sensé eviter.
Moi je préfère me concentrer sur l'idée en utilsant un langage dynamique. Tu developpes ta classe et ton test unitaire associé en même temps..
Après comme devermineur tu peux utiliser les "contrats" qui apportent plus de garanties que le simple type checking.
Si tu veux vraiment pousser, tu disposes d'outils de verification pour les langages dynamiques comme pychecker pour python.
Une voie de progrès serait d'introduire le typage statique à posteriori lors des phases d'integration du produit.
cf. debats de la communauté python
http://www.google.fr/search?q=python+optional+static+typing&sou(...)
Enfin il faut pas assimiler la validation syntaxique à la compilation comme le fait Timaniac.
Ca n'en est qu'une étape et je ne suis pas le seul à le penser
http://fr.wikipedia.org/wiki/Compilation(...)
L'intêret de la compilation est dans les performances qui peuvent être améliorée dans le cadre de l'execution et là aussi on dispose d'outils d'optimisation pour les langages dynamiques (psyco ...). Et n'oublions pas les optimisations à l'execution.
Bref la frontière entre langage interprété et complié est de plus en plus ténue en terme de performances
Par contre les inconvénients du typage fort subsistent.
http://www.mindview.net/WebLog/log-0025(...)
[^] # Re: Avatar ? Kézako ?
Posté par golum . En réponse au journal Réouverture de JabberFR.org. Évalué à 3.
Rôôooo , je sais pas ce que tu fais faire à ton jabber et je ne veux pas le savoir mais fais gaffe quand même ;-)
[^] # Re: Alternative
Posté par golum . En réponse au journal Java, .NET et les logiciels libres. Évalué à 1.
Ruby on Rails
http://linuxfr.org/2005/06/18/19160.html(...)
Si tu as un avis eclairé là dessus?
[^] # Re: Alternative
Posté par golum . En réponse au journal Java, .NET et les logiciels libres. Évalué à 1.
Corba c'est un protocole et un standard. Ce sont les impléméntations qui divergent.
Mono implémente son propre protocole dans son coin (.net remoting je suppose) tout comme RMI
Oué mais là ca n'a pas plus d'intérêt que C#/Mono qui a les mêmes avantage. ....
Et là ca ne te dérange plus de changer de techno et de langage, bizarre.
S'il Zope n'est pas soutenu il y a peut être aussi une raison. IBM aurait très bien pu se tourner vers autre chose que Java.
Ou peut être qu'il y a pas assez de business à se faire et qu'il ont déjà pas mal investi dans java au moment ou zope a démarré. Python a surtout évolué ces denières années.
D'ailleur c'est pas les mêmes qui on créé un tk graphique pour concurrencer un autre parce qu'il le trouvait "inadapté".
Qui sait ? ils finiront peut être par comprendre que c'est la même chose avec Java
Quant aux performance le JITs c'est récent et il n'est pas exclu que des progrès soient accompli avec python aussi. Ppour ;l'instant ce n'était pas la priorité mais chaque nllle version de Cpython améliore les perforamances sans compter le projet Psyco.
L'engouement de la communauté du libre est assez récent..
L'avantage avec python c'est son coté dynamique lui permet d'evoluer très vite.
Bref on est dans du plus pur troll.
Merci pour ton point de vue mais je crois que chacun campera sur ses positions
===> [ ]
[^] # Re: Alternative
Posté par golum . En réponse au journal Java, .NET et les logiciels libres. Évalué à 1.
Bref tu considères que le tout intégré c'est la panacée mais c'est aussi la contrainte d'où le succès grandissant des solutions LAMP
Concernant la table , les equivalences sont sur la plateforme Zope ce qui montre que cette plateforme est quasi- complète et donc intégrée.
Il faut aussi comprendre que la plateforme est dédiée au langage donc qu'il est nullement obligatoire de respecter le JSR??? pour proposer un serveur d'application équivalent.
L'avantage de python c'est qu'il est versatile et ne cible pas uniquement le monde du Web il s'exprime pleinenent sur le poste de travail car il s'intègre bien avec tout un tas de toolkit.
Quand t'as un programme qui doit effectuer des manips sur le poste, des fois le modèle de sécurité de Java, il est pesant
Quant aux parts de marché, Zope n'est pas soutenu par les mastodontes commme IBM BEA Sun & Co donc forcément ca ce ressent mais les entreprises appéecient de plus en plus la liberté y compris de technologie.
[^] # Re: Alternative
Posté par golum . En réponse au journal Java, .NET et les logiciels libres. Évalué à 1.
Je ne prétends pas pas que la technologie Zope/Python peut encore se mesurer aux grand comptes mais elle est en train de monter et ca pourrait changer.
Zope est un véritable serveur d'application et supporte le transactionnel.
La charge, je ne sais pas, je ne suis pas "Zope architect" ;-)
En tout cas je n'ai pas l'impression que l'audience de Gnu linux magazine (cf. sujet du journal) correspondent principalement à des "daicideurs" de grands comptes donc pour moi Zope/Plone/Python est une bonne alternative qui aurait pu figurer dans cette étude.
C'est tout.
[^] # Re: Alternative
Posté par golum . En réponse au journal Java, .NET et les logiciels libres. Évalué à 1.
une petite table de comparaison
http://www.boddie.org.uk/python/web_modules_enterprise.html(...)
[^] # Re: Alternative
Posté par golum . En réponse au journal Java, .NET et les logiciels libres. Évalué à 1.
Ca va faire plaisir à tous ces gens ce que tu dis
http://www.zope.org/Resources/Testimonials(...)
http://www.weblmi.com/manage_copyright(...)
Bon d'accord y'a peut-être pas de transactionnel là-dedans mais il faut laisser le temps au temps, l'API J2EE ne s'est pas créée en un jour que je sache.
En plus ce sont peut-être pas les mêmes niches de marché.
Une PME n'a pas forcément les moyens de payer des millions pour une solution B2C de la mort qui tue en J2EE.
[^] # Re: Alternative
Posté par golum . En réponse au journal Java, .NET et les logiciels libres. Évalué à 2.
http://www.zdnet.fr/actualites/informatique/0,39040745,39233250,00.(...)
Le typage fort n'est pas forcément la panacée.
La philosophie de python est celle du unit testing qui est AMHA nettement plus sûr que le typage fort tout en luimitant les inconvénients au niveau du refactoring.
Certains projets proposent même d'introduire du typage fort progressivement dans ton code ce qui laisse la possibilté de prototyper rapidement et d'introduire plus de sécurité ensuite.
De même, il y a possibilté de faire de la programmation par contrat
de l'AOP, les decorator, bref Python n'a pas à rougir à cpté des dernières features Java.
Les interfaces: Python supporte l'heritage multiple mais mieux que ca on dispose du "duck typing" qui est encore plus souple. Si ton animal nage, court et fait coin coin c'est que c'est un canard, inutile de le préciser.
Les performances ne sont pas les seuls critères à prendre en compte dans le cadre d'un dévelopement, il y a aussi la productivité , la maintenabilité, la liberté, .....
Mais même sur ce point c'est contestable (J'avais vu des benchs surprnant sur ce point nottamment avec Psycho)
En outre il est toujours possible d'optimiser des parties de codes avec du compilé natif et les passerelles sont beaucoup plus aisée qu'avec du JNI.
Bref nous voilà parti dans un beau troll des familles.
Pour la conception, il suffit de voir les alternatives à J2EE qui fleurissent un peu partout y compris dans le monde Java pour comprendre que ce n'est pas la panacée notamment à cause de sa lourdeur. Et à la différence de Java ou C# , les évolutions y compris en terme de conception sont plus rapides avec Pyhton notamment en raison de son faible typage et de ses structures de haut niveau.
Que vous argumentiez en disant qu'il s'agit d'une technologie encore immature OK mais réduire Python à un simple langage de script alors là STOP.
[^] # Re: Alternative
Posté par golum . En réponse au journal Java, .NET et les logiciels libres. Évalué à 1.
http://www.python.org/doc/2.4.1/modindex.html(...)
et ca
http://twistedmatrix.com/(...)
ou encore ca
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Appendi(...)
et si tu insistes tu as même ton api avec des structures de plus haut niveau
http://www.onjava.com/pub/a/onjava/2002/03/27/jython.html(...)
[^] # Re: golum golum dans la case :-)
Posté par golum . En réponse au journal Réforme de la netiquette sur LinuxFr. Évalué à -3.
[^] # Re: Konqueror est sympa
Posté par golum . En réponse au journal Réforme de la netiquette sur LinuxFr. Évalué à 7.
Lés lojissiels praupriétheres ! Gé konfiensse
==============>[ ]
[^] # Re: Intérrésant...
Posté par golum . En réponse au journal Réforme de la netiquette sur LinuxFr. Évalué à 3.
Moi, c'est marrant !
Plus il y a de fautes et moins j'arrive à me concentrer sur thème du journal.
[^] # Re: N'importe quoi
Posté par golum . En réponse au journal Réforme de l'ortograf. Évalué à 2.
et vu ton score je me dis qu'il y en a qui n'ont définitivement aucun humour sur DLFP.
[^] # Re: Bon ben alors ...
Posté par golum . En réponse au journal /!\/!\/!\ Journal Inutil /!\/!\/!\. Évalué à 1.
Valery t'es démasqué, tu recherches les traitres qui ont refusé ton chef d'oeuvre sur les forums ...hein ;-)
Au reouard :D
[^] # Re: Multi-anniversaire ?
Posté par golum . En réponse au journal /!\/!\/!\ Journal Inutil /!\/!\/!\. Évalué à -1.
Après la bourse des droits à polluer à la City, je propose qu'on ouvre une bourse aux XP.
Ceux qui ont des XPs en rab plussoient ceux qui en manquent pour faire remonter leur niveau et en echange augmentent leurs quotas de journaux HS.
En réponse au ketady (http://linuxfr.org/~jokx/18536.html(...) ) on pourrait l'appeler le "takaplussé"
M'en vais déposer un brevet de ce pas moi~~~~~~~~~~~>[ ]
# On est tranquille avec
Posté par golum . En réponse au journal Firefox progresse mais toujours mais pour combien de temps encore.... Évalué à 1.
http://www.framasoft.net/article3877.html(...)
http://diveintogreasemonkey.org/(...)
C'est pas demain que M$ va donner la possibilité à l'utilisateur de filtrer les infos qu'ils recoit d'un site ou de le "défigurer" à son goût
[^] # Re: python
Posté par golum . En réponse au journal GUI portable. Évalué à 1.
Mozilla =>Runtime (XulRunner)
Mono =>Runtime (CLR)
GTK, Fox =>X11
Tes choix se réduisent donc QT ou wxWidget
Après à toi de trouver les bons bindings avec le langage qui te convient et les lib accessoires qui te manquent
Pour wxPython tu as encore une couche d'abstracion supplémentaire
avec wax et pythoncard
http://wiki.wxpython.org/index.cgi/Wax(...)
http://wiki.wxpython.org/index.cgi/PythonCard(...)
Après à il faut encore trouver des moyens d'empaqueter le tout sinon tu te retrouveras de nouveau avec une dépendance à un intreprète pour ton langage de script.
Bonne quête du Graal et poste un nouveau journal avec tes choix et motivations quand tu auras décidé. Ca peut servir aux autres
[^] # Re: Merci journal
Posté par golum . En réponse au journal GUI portable. Évalué à 0.
et des platetformes d'exécution (interprète, bytecode) qui offrent des mecanismes de partage d'objet et un support multilangage.
Tu as ainsi:
Mono/CLR
J2SE/JRE
Mozilla(XPCOM)/XulRunner
et même OpenOffice
UNO/URE
http://udk.openoffice.org/servlets/NewsItemView?newsItemID=287(...)
Tu disposes alors du binding python pyUNO.
http://udk.openoffice.org/python/python-bridge.html(...)
L'inconvénient c'est que pour l'instant il faut installer OOo .
mais le runtime URE arrivera pour OO 2.0
De même XulRunner n'est pas encore achevé ce qui t'oblige à installer FF ou Mozilla, sauf qu'avec Mozilla le langage de l'interface graphique t'es imposé: Javascript, même si tu peux te creer des composants dans différents langages via XPCOM. Le langage de description de l'interface graphique XUL (dtd XML) t'apporte une bonne séparation présentation/tratement. Le support à venir de SVG et la plateforme de déploiement (.xpi) peuvent être un plus.
Pour Java tu peux faire exactement la même chose que IronPython pour Mono, avec Jython et acceder ainsi aux librairies graphiques Java au travers d'un langage descript (Swing, SWT, Java2D).Le lagge
Dans tous les cas, ca necessite de connaitre le framework et son API à défaut du langage de référence.
Si tu affectionnes Ruby tu as aussi JRuby qui permet la même chose
http://jruby.sourceforge.net/index.shtml(...)
L'equivalent mono ou XPCOM doit exister mais je n'ai pas creusé.
Bon courage
[^] # Re: python
Posté par golum . En réponse au journal GUI portable. Évalué à 1.
http://sourceforge.net/forum/forum.php?thread_id=1273014&forum_(...)