Articles précédents : Développeur
- [53] Java Standard Edition 6 est sorti
- [15] IBM libère un framework pour le Web sémantique
- [11] LibreSource passe en version 2.0
- [44] O.S.T.D.C. une introduction au Développement en équipe
- [10] Cooki3d : une première version GNU/GPL
- [18] Nomination pour les Trophées du Libre
- [48] D-Bus 1.0, future fondation de nos bureaux
- [127] Java libre : un rêve devient réalité
- [4] Base audio libre de mots chinois
- [137] Mono passe en version 1.2
Liens connexes
- Blog GWT (892 hits)
- Google Web Toolkit (1526 hits)
- Exemples (2250 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Google Web Toolkit sous licence Apache 2.0
Posté par Bayle Christian (). Modéré le 13 décembre 2006.
Ce toolkit permet d'écrire son interface en java, qui est ensuite convertie en Javascript compatible avec la grande majorité des navigateurs. Il est ainsi possible de tester ou déboguer son code sans se préoccuper de telle ou telle implémentation de Javascript. Une façon élégante de faire de l'Ajax.
![[en]](../../../images/en.png)
Blog GWT (892 hits)-
Google Web Toolkit (1526 hits)
-
Exemples (2250 hits)
> Lire les commentaires (87 commentaires, moyenne: 2,3).
Ca va booster le web2.0
Une telle libération de code va sûrement faire des contents parmis les développeur d'applications web et sûrement accélerer l'utilisation des techniques du web2.0. Surtout pour les applications Java qui n'avait pas beaucoup de framework de ce niveau.
Peut-être verra-t-on fleurir du GWT dans esup :-)
-
[^]Re: Ca va booster le web2.0
Posté par Nicolas Legrand () le 13/12/2006 à 14:23. (lien). Évalué à 6.Super... C'est vrai que gmail est génial. Et leur framework a l'air très bien...
Mais bon, je trouve que d'une part, tout faire dans son navigateur, ça risque de devenir un peu lourdingue, d'autant que firefox n'est pas un exemple de légerté (même s'il est très bien tout ça).
Et puis à la fin avec les XMLHttpRequest, les RSS, les Web service qui utilisent HTTP, on commence un peu trop à utiliser à tout bout de champs un pauvre protocole qui n'a pas trop été conçu pour ça au début. Comme si d'un coup HTTP devenait la surcouche de tous les autres protocoles ou était utilisé en dépit du bon sens quand un protocole n'existe pas pour créer un truc batard (C'est bien RSS hein ? Tout ce trafic généré pour rien qui fait exploser la facture d'hébergement de certains...).
Et pour le Web 2.0, je suis plutôt de l'avis de ce monsieur :
http://www.lassila.org/blog/archive/2006/11/i_dont_mean_to_1(...)-
[+] [^]Re: Ca va booster le web2.0
Posté par Stéphane TRAUMAT (page perso, ) le 13/12/2006 à 14:49. (lien). Évalué à -1.Perso... peu importe le protocole... HTTP marche partout et GWT masque les "défauts" et "détails" du protocole... donc ça me convient nickel :)
-
[^]Re: Ca va booster le web2.0
Posté par Antoine () le 13/12/2006 à 21:09. (lien). Évalué à 1.HTTP marche partout et GWT masque les "défauts" et "détails" du protocole...
Pour toi peut-être (encore que quand ça rame, ça rame), pas pour les serveurs.
cf. la remarque du monsieur au-dessus : « C'est bien RSS hein ? Tout ce trafic généré pour rien qui fait exploser la facture d'hébergement de certains... »
-
-
-
[^]GWTSAPU...
Posté par jigso () le 13/12/2006 à 15:25. (lien). Évalué à 8.Lancez gmail avec firebug, c'est assez édifiant : la console se rempli à toute vitesse, le code généré est horrible, et quasiment impossible à comprendre et a débuguer : il y a des empilements de frame/iframe/div qui finissent par une ligne de javascript pire qu'un uni-ligne perl, les liens n'en sont pas - cad du texte avec une bonne couche de css/javascript pour faire croire que, mais en fait non (résultat : pas de navigation au clavier avec TAB, ou de bookmarks).
Une personne handicapée ne peut absolument pas utiliser ce genre d'interface, sincèrement si ce genre de site se répand suite à la mise à disposition de ce framework. c'est dommage.
Le seul espoir réside dans une correction de ce bouzin pour générer du code 'propre', mais vu l'état du truc c'est sûrement plus simple de repartir de zéro...-
[^]Re: GWTSAPU...
Posté par Stéphane TRAUMAT (page perso, ) le 13/12/2006 à 15:32. (lien). Évalué à 4."le code généré est horrible, et quasiment impossible à comprendre et a débuguer "
Le but de GWT est de justement simplifier la génération de code et le débuggage mais cela se fait en Java (qui est tip top pour la génération et le débuggage). Le code généré n'a pas a être compris ou débuggé (sauf par une petite partie des mainteneurs de GWT).
L'ajax en général n'a pas l'air trop fait pour les handicapés j'ai l'impression (utilisation intensive des divs).-
[^]Re: GWTSAPU...
Posté par jigso () le 13/12/2006 à 15:39. (lien). Évalué à 1.L'ajax en général n'a pas l'air trop fait pour les handicapés j'ai l'impression (utilisation intensive des divs).
Le fait qu'il y ait des div n'implique pas un manque d'accessibilité. Et Ajax non plus. Il est tout a fait possible de transformer des appels ajax en bon vieux liens classiques, et donc de rendre l'interface plus accessible. Si en plus le code est généré, c'est d'autant plus simple de faire générer le site en mode avec ou sans javascript. Et pour l'instant on a dans le source de la page dans un noscript : "JavaScript doit être activé pour utiliser Gmail avec le mode d'affichage standard. Il semble que ce langage soit désactivé ou qu'il ne soit pas pris en charge dans votre navigateur. etc..."
Bref, GWTSAPUR1PEUMOINS le jour ou ça pourra générer du code qui fonctionne sans javascript.-
[^]Re: GWTSAPU...
Posté par Stéphane TRAUMAT (page perso, ) le 13/12/2006 à 15:47. (lien). Évalué à 1.mmmm je suis perplexe sur ton analyse... mais je ne suis pas sur de mon coup.
Imagine que tu as une page avec un gros DIV. Et tu as 50 écrans qui se suivent et que tu mets dans le div.... ça donne quoi en HTML classique ? ça reste utilisable ?-
[^]Re: GWTSAPU...
Posté par jigso () le 13/12/2006 à 21:01. (lien). Évalué à 1.Un suppo de http://www.alsacreations.com/ le soir, et un cachet de http://openweb.eu.org/ le matin avant le petit déjeuner, et ça ira mieux d'ici 8-10 jours.
Allez, c'est 22¤. A bientôt et soignez-vous bien.
-
-
-
[^]Re: GWTSAPU...
Posté par golum () le 13/12/2006 à 15:48. (lien). Évalué à 3.M'est avis que tu est tombé sur un chasseur de troll expérimenté et bien camouflé.
Il nous en a débusqué 3 énormes spécimens l'air de rien:
le Firefoxsapucélourd, le Ajaxcapucétaimieuavant et son petit frère le HTTPcépafépourservirdepassoiràtou.
Bonne chance ;-)-
[^]Re: GWTSAPU...
Posté par Nicolas Legrand () le 13/12/2006 à 22:30. (lien). Évalué à 4.Mhmm, tu as oublié "le web 2.0 c'est un buzzword commercial qui ne veut rien dire parlons plutôt de web sémantique". J'avoue qu'il était plus caché, plus subtil, plus improbable.
Après pour moi il s'agit de vrais problèmes. Détourner un protocole est plus simple que d'en créer un nouveau, mais on ne fait que le contourner. Quand le petit hack malin devient une règle, il serait plutôt temps de bâtir quelque chose de vraiment solide plutôt que de bricoler dans tous les sens. RSS est devenu indispensable, ça n'empèche pas qu'il soit mal foutu.
Ensuite un autre truc que je trouve juste marrant, et qui marque la diversité de Linuxfr :-). Il y a quelques temps je m'étais fait à moitié descendre parce que je disais que ce n'était pas réaliste d'obliger le Web a se plier systématiquement aux standards du W3C. Il y avait des stal qui aurait voulu qu'à la moindre erreur ton navigateur plante. Je suis a peu prêt sûr (vu comment Google respecte les dits standards) que ce code ne génère pas quelques chose de standard. Et là ça ne choque personne. Ha tiens. Le geek victime de l'effet qui clignote ? Oui monsieur j'en prends dix boîtes de votre produit, j'aime bien la couleur.
Mhmm... Suis-je d'humeur vendrediesque en ce moment ? Bha pensez ce que vous voulez, moi je trouve que ces points ne manquent pas d'intérêt :-).-
[^]Re: GWTSAPU...
Posté par Antoine () le 13/12/2006 à 23:18. (lien). Évalué à 4.Je suis a peu prêt sûr (vu comment Google respecte les dits standards) que ce code ne génère pas quelques chose de standard. Et là ça ne choque personne.
Sur Linuxfr il y a des standards de pensée à respecter. (*)
Quand on parle de Microsoft, insinuer que c'est le diable, farci d'arrière-pensées ignominieuses, et que ça plante tout le temps (même si on n'a jamais testé le logiciel en question pour vérifier qu'effectivement, ça plante).
Quand on parle de Google, ce sont les bienfaiteurs du Web, inventeurs de tas d'applis sympas, ils sont donc au-dessus des remarques mesquines qu'on n'hésite pas à infliger à d'autres.
Quant au W3C, c'est Dieu lui-même, toucher à un cheveu d'un standard adoubé par le W3C est forcément une preuve d'obscurantisme indécrottable et probablement mal intentionné (même si XHTML est critiqué par nombre de défenseurs du W3C, hein).
(*) pas que sur Linuxfr d'ailleurs, on retrouve les mêmes comportements sur beaucoup de blogs vénérés ici, comme Standblog & co.
-
-
-
-
[^]Re: GWTSAPU...
-
[^]Re: GWTSAPU...
Posté par Stéphane TRAUMAT (page perso, ) le 13/12/2006 à 18:28. (lien). Évalué à 1.mm je crois bien que si !
-
[^]Re: GWTSAPU...
Posté par encre (page perso, ) le 14/12/2006 à 14:42. (lien). Évalué à 2.Non, je ne vois pas pourquoi je suis à -1. Bruce Johnson a déjà parlé maintes fois du sujet, par exemple dans son mail daté 12/6/2006 5:43 PM et intitulé "Re: Help me pitch GWT to the team...", sur la ML officielle. La seule appli chez Google actuellement visible et utilisant GWT est http://images.google.com/imagelabeler/.
-
-
-
et avant ?
Il etait sous quelle licence avant ?
Il me semble que c'etait deja disponible sous une licence libre depuis quelques mois ...
GWT est-il vraiment libre ?
Dans la version précédente les libs java et et leur équivalent javascript étaient libres.
C'est à dire qu'une fois déployée ton appli tout ce que tu utilises qui a été généré est libre.
Le runtime de test et le compilo qui transforme le code Java en javascript ne l'étaient pas.
Rien n'empêchait Google de laisser se répandre sa techno et de décider de faire passer son compilo en payant.
Pour les applis qui l'utilisent, 2 solutions: faire la maintenance à la mano ou cracher au bassinet.
C'est pas ce que j'appelais un web toolkit libre
Est ce que ca a changé avec la 1.3 ?
Le news de Google n'est pas très explicite.
-
[^]Re: GWT est-il vraiment libre ?
Posté par domak () le 13/12/2006 à 10:19. (lien). Évalué à 5.Je me suis posé la même question.
Oui, si on en croit la page http://code.google.com/webtoolkit/makinggwtbetter.html dont voici un extrait:
GWT took off much faster than we expected, and it quickly became clear that the most sensible way to advance GWT quickly would be to open it sooner rather than later. While we've never actually felt particularly stingy about keeping the source closed, now the all code for the GWT Java to JavaScript compiler, the hosted mode browser, and so on can progress before your eyes. We're very much looking forward to contributions of ideas, bug reports, and patches.
Finallement, j'ai été voir rapidement dans Subversion et j'ai trouvé le compilo sous licence Apache:
http://google-web-toolkit.googlecode.com/svn/trunk/dev/core/(...)
Je vais peut-être me remettre à développer des applis web...
-
[^]Re: GWT est-il vraiment libre ?
Posté par Matthieu MARC () le 13/12/2006 à 10:31. (lien). Évalué à 0.Rien n'empêchait Google de laisser se répandre sa techno et de décider de faire passer son compilo en payant.
Oui, mais en ce moment, le compilo est gratuit, donc tu peux le garder ad vitam eternam. Je ne pense pas que Google puisse le rendre payant rétroactivement, seulement des versions ultérieures. Dans ce cas, tu as la certitude d'avoir à disposition un compilateur, donc tu ne seras jamais bloqué complètement (tu peux l'être si tu tombes sur un bug bloquant corrigé dans l'hypothétique version payante). Donc pour moi, ce n'est pas complètement bloquant que le compilateur ne soit pas libre car s'il devient full propriétaire et payant tu pourras toujours continuer à utiliser le compilateur actuel, le temps de migrer tes applications sous une autre technologie.
Et je ne pense pas qu'il faille avoir peur de devoir migrer ses applis ultérieurement, car en informatique, notre destinée est de toujours tout refaire tous les 2 ans à cause des améliorations dans le domaine.
Enorme !!
Je viens de regarder le site de GWT, et je viens de me rendre compte d'une chose : mais c énorme !!
Je suis développeur Java sur mon temps libre, et en ayant une conception propre de son appli (MVC par exemple, ou tout modèle qui sépare correctement interface et noyau fonctionnel), cela veut dire que l'on va pouvoir assez facilement faire deux versions de son appli : une version "lourde" sur son pc et une version web quand on est en déplacement ... par exemple.
Je regarde ça dès que j'ai un peu de temps, mais ça m'a l'air assez prometteur. En tout cas, j'ai déjà plein d'idées :) :)
-
[^]Re: Enorme !!
Posté par golum () le 13/12/2006 à 12:33. (lien). Évalué à 6.Si tu veux t'y mettre voici 2 petits tutos (en anglais) que j'avais bookmarké.
Bon coding
http://www-128.ibm.com/developerworks/library/j-ajax4/index.(...)
http://www.xml.com/pub/a/2006/07/12/google-web-toolkit-ajax-(...)-
[^]Re: Enorme !!
Posté par SOULfly_B (Jabber id, page perso, ) le 13/12/2006 à 13:45. (lien). Évalué à 1.Merci pour ces liens forts utiles que je viens de parcourir rapidement.
Je profite de ce que tu as l'air de connaitre un peu GWT pour te poser une question dont je n'ai pas réussi à trouver la réponse : quelle est la configuration requise pour le serveur web ?
En effet, pour utiliser GWT, il faut Java, mais qu'en est-il du code compilé pour le "web mode" ? J'ai cru comprendre qu'il ne s'agissait que d'HTML et de Javascript, dans ce cas, n'importe quel serveur peut faire l'affaire. En fait, ma crainte est qu'il faille une machine Java sur le serveur (Tomcat ou autre), ce qui réduirait pas mal les applications de GWT, en tout cas pour un usage "amateur".-
[^]Re: Enorme !!
Posté par golum () le 13/12/2006 à 13:53. (lien). Évalué à 3.GWT s'éxecute sur n'importe quel serveur Web. C'est une différence entre GWT et echo2 dont je parle plus bas dans le lien sur serverside.C'est d'ailleurs précisé dedans.
(PS: je m'interesse à la techno mais je n'ai pas encore eu le temps de mettre les mains dans le cambouis)-
[^]Re: Enorme !!
Posté par kaouete (page perso, ) le 13/12/2006 à 19:03. (lien). Évalué à 2.Sauf si il y a une partie servlet qui elle devra tourner sur un serveur a la tomcat.
-
[^]Re: Enorme !!
Posté par golum () le 14/12/2006 à 09:11. (lien). Évalué à 2.Tu as parfaitement raison mais SOULfly_B parlait d'un usage amateur. Je pense que ca ne le dérange pas que la logique applicative soit déportée complétement sur le navigateur. L'important dans ce cas est de pouvoir developper son site en Java est de pouvoir le bazarder sur son site perso après la compilation vers Javascript avec juste son MySQL d'activé. Mais ca doit avoir rapidement ses limites.
C'est l'avantage de GWT par rapport à echo2, la logique applicative peut être placée entièrement coté client ou répartie entre le client et serveur alors que Echo2 impose de la répartir des 2 cotés. La contrepartie à cette souplesse c'est peut-être qu'avec l'approche echo2 tu as une partie du travail de répartition de la charge qui est déjà faite de façon optimisée alors que tu dois sûrement faire tout ça à la mano dans le cas de GWT. Ca reste à vérifier.
-
-
-
-
Un retour d'expérience sur GWT...
Ma société utilise beaucoup GWT pour développer les applications et je dois dire que nous sommes enchantés (juste un ou deux points gênants)... j'ai fait un retour d'expérience sur le sujet :
http://www.scub.net/blogs/straumat/?postid=4
Par contre, j'avais oublié de préciser un défaut... pour le moment, pas de tests unitaires automatisés de l'interface possible comme on le faisait avec JSF et canoo web test :(
-
[^]Re: Un retour d'expérience sur GWT...
Posté par Jérôme BENOIS (page perso, ) le 13/12/2006 à 12:28. (lien). Évalué à 1.Intéressant ton retour d'expérience... Tu dis utiliser beaucoup GWT, penses-tu qu'il soit utilisable dans une application existante, est-ce facile à intégrer coté design, css ... ?
-
[^]Re: Un retour d'expérience sur GWT...
Posté par Stéphane TRAUMAT (page perso, ) le 13/12/2006 à 14:33. (lien). Évalué à 2.Je pense qu'il est utilisable dans une appli existante nico techno. Nous utilisons des services partagées via RMI... donc nous avons juste développé des servlets qui rendent ces services accessibles à GWT (on s'embête par contre beaucoup à transformer les objets pour qu'ils soient sérialisable en javascript).
Pour le côté design... les CSS marchent très bien et tu peux même spécifier un style particulier en code... par exemple button.setStyle("monStyle");
-
-
[^]Re: Un retour d'expérience sur GWT...
Posté par golum () le 13/12/2006 à 12:51. (lien). Évalué à 2.As tu déjà evalué Echo2 ?
Sur ton blog un lien sur une comparaison entre les 2 a été posté.
(probablement biaisée puisque provenant d'un des membres du projet echo2)
http://www.theserverside.com/news/thread.tss?thread_id=40804-
[^]Re: Un retour d'expérience sur GWT...
Posté par Stéphane TRAUMAT (page perso, ) le 13/12/2006 à 14:33. (lien). Évalué à 2.Non :( pas eu le temps ! maheursement.. leur démos sont très impressionnantes... mais GWT nous permettait de s'interfacer facilement avec notre façon de développer actuelle.
-
J'adore !
Je connaissais assez bien Swing et pas du tout JSF. Je voulais me mettre à la programmation AJAX. J'ai essayé les deux approches (JSF et GWT) et je dois dire que GWT est vraiment hyper-simple (pour moi en tout cas). C'est le même principe de panels imbriqués que Swing avec un système de RPC qui fait penser à RMI pour communiquer avec le serveur d'applications. Une superbe réalisation. Et en plus ça tourne sous Linux et MacOSX. Bravo Google !
Plus je connais les hommes, plus j'aime ma machine.
-
[^]Re: J'adore !
Posté par julione () le 13/12/2006 à 12:19. (lien). Évalué à 1.Je suis perplexe en lisant la news sur l'utilité d'un tel framework en comparaison avec les frameworks AJAX de haut niveau qui existent dans la sphère JSF.
Je pense notamment à ICE FACES qui vient lui aussi de passer dans l'open source et qui offre aux développeurs JSF une importante collection de composants AJAX de qualités (http://component-showcase.icefaces.org/component-showcase/).
Excellente nouvelle
Ils adoptent la même licence que l'équivalent libre de GWT en python !
http://pyjamas.pyworks.org/FR/
nulle doute que ça va booster pyjamas !
-
[^]Re: Excellente nouvelle
Posté par Stéphane TRAUMAT (page perso, ) le 13/12/2006 à 14:48. (lien). Évalué à 2.mmm je ne connais pas python mais c'est de l'interprété non ?
Si oui, je trouve ça moins intéressant que GWT... parce que c'est du Java, ça permet de faire du développement web en profitant des avantages d'un langage comme Java (compilation, ide, complétion, refactoring...)-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 13/12/2006 à 16:15. (lien). Évalué à 2.python est interprété la première fois, en générant du bytecode qui sera executé au prochain tour (lemeilleur des 2 mondes, à mon sens)
La compilation du python, c'est pour bientôt (cf pypy et autres shredskin)
Sinon Eclipse+pydev permet de dev du python, avec la complétion, le refactoring et tout qui va bien ...
SI tu veux allé plus loin tu peux générer des .class avec jython (et non ce n'est pas mort) ... ou des assembly .net/mono avec ironpython-
[^]Re: Excellente nouvelle
Posté par golum () le 13/12/2006 à 16:30. (lien). Évalué à 2.Je pense qu'il voulait dire que python est typé dynamiquement.
La compilation du python, c'est pour bientôt (cf pypy et autres shredskin)
C'est pour quand parce que ca n'a pas l'air de beucoup bouger (sortie de la 0.9.0)
Ca fait combien de temps que le projet a été lancé
SI tu veux allé plus loin tu peux générer des .class avec jython (et non ce n'est pas mort) ... ou des assembly .net/mono avec ironpython
Non jython n'est pas mort, c'est juste qu'il a 3 releases de retard sur l'implémentation de réference en cpython.Vivement que Pypy vienne solutionner tout ça :)
Pour les codeurs java qui veulent se mettent au scripting, il y a un petit langage qui fait très bien l'affaire avec des closures et tout et tout et qui vient de passer en RC-1 récemment.
http://groovy.codehaus.org/News
Il devrait sortir en finale avant la fin de l'année.-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 13/12/2006 à 17:01. (lien). Évalué à 2.> C'est pour quand parce que ca n'a pas l'air de beucoup bouger (sortie de la 0.9.0)
y a un post récent sur reddit (mais c en carafe actuellement ?!), qui annonce que c'est imminent ...-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 13/12/2006 à 18:03. (lien). Évalué à 2.En fait, sur le site off de pypy, c'est prévu pour février 2007
http://codespeak.net/pypy/dist/pypy/doc/news.html
au dernières nouvelles, pypy est encore 20x plus long que cpython en interprété
mais une fois le code c généré et compilé en binaire, c'est 10x plus rapide que du cpython-
[^]Re: Excellente nouvelle
Posté par Pinaraf (Jabber id, ) le 13/12/2006 à 20:00. (lien). Évalué à 2.Heu
Qu'est-ce-qui est 10x plus rapide ?
L'exécution de code quelconque avec Pypy ? Non, ça reste au mieux 3 fois plus lent que CPython
L'exécution de code quelconque traduit en C et compilé par pypy ? Non, c'est plus que 10 fois plus rapide....-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 13/12/2006 à 20:07. (lien). Évalué à 2.C'est pypy qui traduit le code python en source C. et c'est make/gcc qui va compiler le C en binaire ...
C'est ça, qui est plus rapide que l'execution du même source python sous cpython-
[^]Re: Excellente nouvelle
Posté par Pinaraf (Jabber id, ) le 13/12/2006 à 20:53. (lien). Évalué à 2.C'est pypy qui traduit le code python en source C. et c'est make/gcc qui va compiler le C en binaire ...
C'est ça, qui est plus rapide que l'execution du même source python sous cpython
Heu, tu peux me dire ce que désigne ton "ça" ? Parce que là franchement ... Je pense que ça désigne le processus de traduction, et lui il est franchemenet extrêmement lent par rapport à l'interprétation du script...-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 13/12/2006 à 22:38. (lien). Évalué à 2.bah dis donc, tu as vraiment du mal ?!
"ça" : c'est l'executable ... le binaire généré par gcc ... (un .exe si tu prefères ;-)
(il n'y a plus de python à ce niveau là, capito ?!)-
[^]Re: Excellente nouvelle
Posté par golum () le 13/12/2006 à 22:56. (lien). Évalué à 3.Bon les filles, passe encore que vous fassiez de la pub a peine déguisée pour votre chouchou (que j'apprécie par ailleurs) en vous raccrochant aux branches mais si vous alliez jouer ailleurs. C'est pas ce qui manque les news et les journaux python
; ) ;) ;) ;) ;)
Ils adoptent la même licence que l'équivalent libre de GWT en python !
http://pyjamas.pyworks.org/FR/
C'est plus un clin d'oeil c'est une paralysie faciale
Pour un peu on parierait que vous êtes sous Ubuntu.
Entre le thread python et le troll web2.0 on a du mal à se rendre compte qu'on est sur une dépêche GWT Java
Aux moinsseurs : Chargez, Feu !
J'me sens d'humeur suicidaire ce soir.-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 14/12/2006 à 07:33. (lien). Évalué à 3.Ne te sens pas obligé de lire ...
moi je parlais juste de la refonte de GWT en python, aka pyjamas
(je pense que ça a sa place)
Après on a dévié sur eclipse/pypy pk le gars il n'avait pas l'air de connaître python.
Et comme python, c'est le "next big thing" dans le dev web, je pense que c'est important d'en parlé ... (pyjamas)
D'ailleurs ... YOUTUBE est entièrement fait en python
http://mail.python.org/pipermail/python-dev/2006-December/07(...)
et sinon, oui, je suis sous 'buntu ;-)
-
-
[^]Re: Excellente nouvelle
Posté par Pinaraf (Jabber id, ) le 14/12/2006 à 11:25. (lien). Évalué à 2.Oui, et donc je pige pas d'où tu sors tes chiffres abracadabrantesques, pour reprendre quelqu'un.
Pypy traduit en C et compilé, c'est plus lent que CPython (plus de 3 fois plus lent avec le SVN actuel). Le binaire généré est de plus très lourd, et toute la librairie standard n'est pas implémentée.
-
-
-
-
-
-
-
-
-
[^]Re: Excellente nouvelle
Posté par Antoine () le 13/12/2006 à 21:14. (lien). Évalué à 2.mmm je ne connais pas python mais c'est de l'interprété non ?
Si oui, je trouve ça moins intéressant que GWT... parce que c'est du Java, ça permet de faire du développement web en profitant des avantages d'un langage comme Java (compilation, ide, complétion, refactoring...)
Rassurez-moi, c'est un troll, hein ?
Java c'est mieux parce qu'il faut recompiler à chaque fois ?
On ne peut pas "refactorer" en Python ?
On ne peut pas faire de l'auto-complétion en Python ?
Java c'est mieux "parce que c'est du Java" ?
Bon, ça doit être un troll.-
[^]Re: Excellente nouvelle
Posté par Stéphane TRAUMAT (page perso, ) le 13/12/2006 à 21:43. (lien). Évalué à 2."Rassurez-moi, c'est un troll, hein ?"
Non, j'ai bien précisé que je ne connaissais pas.
"Java c'est mieux parce qu'il faut recompiler à chaque fois ?"
Oui, enfin la recompilation au fil de l'eau, ça existe...
"On ne peut pas "refactorer" en Python ?"
Et bien, je serais épater de voir un outil de refactoring aussi puissant qu'eclipse sous python.. mais je connais pas.
"On ne peut pas faire de l'auto-complétion en Python ?"
si si... erreur de ma part...
"Java c'est mieux "parce que c'est du Java" ?"
non, c juste qu'avec Eclipse.. c sympa de développer avec GWT.
plus de javascript, plus de html.... ça compile, ça debug et ça marche.. donc voila.-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 13/12/2006 à 22:45. (lien). Évalué à 2.bah tu prends eclipse
t'installes le plugin "pydev" (c'est un plugin eclipse pour dev du python)
et tu verras que ça marche tout aussi bien, avec du python
(eclipse n'est pas un editeur dédié au java, il y a plein de plugins pour plein de languages)-
[^]Re: Excellente nouvelle
Posté par Stéphane TRAUMAT (page perso, ) le 14/12/2006 à 10:01. (lien). Évalué à 2.Il n'est pas dédié au java mais tu as quand même un paquet de trucs qui sont super bien fait pour Java.... le refactoring, la complétion, le correcteur, et le debugger pour Java sont terrible et c'est loin d'être le cas pour le plugin php...
-
[^]Re: Excellente nouvelle
Posté par wilk (Jabber id, page perso, ) le 14/12/2006 à 12:12. (lien). Évalué à 3.Les outils indispensables à un langage (java) ne le sont pas forcément à un autre (python). Il ne faut donc pas les comparer tels-quels avant de bien connaitre le langage en question.
Par exemple la compilation au fil de l'eau n'a pas a être gérée par l'éditeur puisque c'est automatique en python.
La complétion n'est pas aussi indispensable qu'en java vu que le code est beaucoup plus concis.
Le debuggage dans l'éditeur n'est pas non plus forcément la meilleure solution vu qu'on peut par ex lancer un interpreteur directement dans une page web en cas d'erreur et faire de l'introspection dans l'appli qui tourne (paste.EvalException). On peut aussi lancer un interpréteur accessible par telnet (Twisted), je parle bien de l'interpréteur utilisé par l'appli qui tourne.
Etc...
Le point principal je crois c'est que les programmes sont vraiment beaucoup plus concis en python donc l'éditeur a vraiment beaucoup moins d'importance.-
[^]Re: Excellente nouvelle
Posté par golum () le 14/12/2006 à 13:15. (lien). Évalué à 3.Oui et surtout python est un vrai langage objet.
Il ne supporte pas l'héritage d'interface et nous vend son duck typing.
Un principe révolutionnaire lorsque tu dois faire de l'intégration de composants, surtout couplé avec son typage dynamique. Lorsque tu assembles des modules que tu n'avais pas conçu initialement pour ca et que tu découvres en prod que tu passes pas dans un cas non prévu (les test d'intégration etant plus difficiles à mettre en place que les test unitaires) alors que la compilation te l'aurait indiqué dès la phase de dev. La sécurité en devient imparable.
Grâce à ce même typage dynamique, tu en es réduit à utiliser les tests unitaires pour déverminer tes programmes alors que le contrôle de type à la compilation te permet de gagner un temps fou. 2 précautions ne valent mieux qu'une.
Quel développeur qui adopte une programmation defensive n'en est pas réduit à poser des
assert sur le type de la classe attendu.
Du coup certains ont implémenté les interfaces dans des libs non standard.
Tu n'as pas d'attributs ou de méthodes protégées.
Tu déclares tes attributs privés en les déclarant avec __ et tu peux casser aisément l'encapsulation par programme.
Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.
Tu dois te coltiner des idiomes du langage pour implémenter des structures de contrôles aussi basiques qu'un do while.
Tu peux faire de l'introspection sur tes objets en explorant le dictionnaire qui lui est associé, même si on te le déconseille parce que ca peut changer. Preuve que son modèle objet est figé.
Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++ (ou en l'évitant grâce à l'héritage d'implémentation simple couplé avec l'héritage d'interface et la délégation comme en Java)
Tu n'as pas RMI en standard
pas de libs standard équivalente aux servlets, aucune spécification commune, ce qui t'oblige à choisir parmi une pléthore de frameworks dont aucun n'arrive à s'imposer.
.....-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 14/12/2006 à 13:39. (lien). Évalué à 2.toi tu cherches le troll ...
Il y a également une pléthore de désavantages à utiliser des languages non dynamique et fortement typé ...
Après tout dépends de tes préférences et de tes besoins ...
Moi, je mange du csharp au boulot tous les jours (depuis 5ans), et du python à la maison. Et je connais bien ces 2 mondes
Mais tu ne m'oteras pas l'idée qu'on est 4 à 5 fois plus productif en python avec un simple notepad, qu'en java avec le mega ide qui tue (ou cshap avec vs2005)
Après c'est une façon de faire/programmer, mais ton language fortement typé et sa compilation ne t'enlevera pas les "null object reference", ni les erreurs de castage qu'on peut faire dans ces 2 languages au runtime ...-
[^]Re: Excellente nouvelle
Posté par golum () le 14/12/2006 à 13:52. (lien). Évalué à 1.Disons que le prosélytisme des pythonneux dans les news java me lasse un peu.
Et pourtant je ne suis pas le dernier à utiliser ce langage à l'occasion.
Ces faiblesses que je pointe, expriment ma frustation de ne pas voir ces aspects progresser dans les versions de Python qui se succèdent. La plupart de ces griefs ont reçu des propositions d'amélioration dans les PSP et ont été rejetée ou retardées. On assiste du coup à un éclatement de la communauté que je trouve dommageable. (fork de python http://boo.codehaus.org/, librairies complémentaires d'usage générales, ...)-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 14/12/2006 à 15:40. (lien). Évalué à 3.oulala ... mauvaise pioche ...
j'ai fait pas mal de boo jadis (j'ai fait un smarty like en boo)...
C'est une implémentation d'un "python"-like dans la CLR (.net/mono) ...mais ça ne doit plus avoir grand chose à voir avec python ! (ils avaient pas mal de prob à faire du dynamique pure, du coup ils ont pas mal "statiquiifié" boo)
sinon python3 devrait te plaire ...
Mais en aucun cas, on peut parler de fork de python ;-), boo est un autre language qui reprends qques concepts de python (tout comme groovy pour java) ... et il n'y a aucun éclatement dans la communauté python ... mais pypy assainira la chose, ça c'est certain (un seul et même python pour java/dot.net et python)
-
-
-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 08:30. (lien). Évalué à 1.Grâce à ce même typage dynamique, tu en es réduit à utiliser les tests unitaires pour déverminer tes programmes
Parce que le typage statique permet aux programmes de se "déverminer" sans intervention humaine peut-être ? Voilà une nouvelle inattendue.
pas de libs standard équivalente aux servlets, aucune spécification commune
Python Web Server Gateway Interface
http://www.python.org/dev/peps/pep-0333/
Du coup certains ont implémenté les interfaces dans des libs non standard.
Oui, en même temps le fait que ce soit possible est plutôt une qualité du langage. Python évite l'inflation de mots-clés en fournissant un langage souple qui permet aux programmeurs de réaliser les abstractions dont ils ont besoin sans que ça ait l'air affreux.
Son héritage multiple est bancal (en profondeur d'abord de gauche à droite) puisqu'il ne résoud pas le pb de l'héritage en diamant de façon élégante comme le C++
Elégant, le mot-clé "virtual" dans la spécification des classes de base ? :-O
Au fait, je ne sais pas ce qui a pu te faire arriver à la conclusion que l'héritage multiple de Python se fait en profondeur d'abord :
>>> class A(object): pass
...
>>> class B(A): pass
...
>>> class C(A): pass
...
>>> class D(B, C): pass
...
>>> D.__mro__
(<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class '__main__.A'>, <type 'object'>)
L'ordre de résolution est : D, B, C, A, object. Profondeur d'abord ??
Ceci dit quand on se retrouve avec un graphe d'héritage suffisamment compliqué pour que les relations de précédence ne soient pas triviales, c'est un signe de mauvaise conception. Surtout si on donne le même nom à des méthodes à différents endroits du graphe, avec des sémantiques différentes.
Tu n'as pas d'attributs ou de méthodes protégées.
C'est quoi le problème à résoudre ?
Si tu veux déclarer qu'un attribut est à usage interne, tu n'as qu'à le préfixer d'un underscore, c'est une convention suffisamment explicite pour indiquer à l'utilisateur de ta classe qu'il ne faut pas toucher à cet attribut-là.
Si l'utilisateur en question est assez téméraire pour passer outre, c'est son problème.
La philosophie de Python n'est pas de prendre les développeurs pour des enfants et de mettre des barrières partout (contrairement à Java qui favorise le contexte social d'une informatique réalisée par une armée de tâcherons sous-payés et incompétents) ; c'est un langage pour adultes consentants. A chacun d'être à la hauteur.
Comble de l'élegance, tu dois passer le paramètre self à toute tes déclarations de méthodes.
C'est effectivement élégant parce que cela implique qu'une méthode est l'équivalent d'une fonction.
Le langage est ainsi plus orthogonal, et il n'y a pas de variable au statut particulier ou magique (comme "this").
(oui, en Java il n'y a pas de fonctions proprement dites, du coup pour compenser il y a des "méthodes" statiques, qui ne sont des méthodes que sur le plan syntaxique et non sémantique, comme c'est rigolo)
Si des langages comme Java n'imposent pas de devoir taper "self", ils imposent de taper systématiquement "private", "public" et toute une inflation délirante de mots-clés, enfin bref...-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 09:05. (lien). Évalué à 3.
Parce que le typage statique permet aux programmes de se "déverminer" sans intervention humaine peut-être ? Voilà une nouvelle inattendue.
Si mais tu ne le découvres pas à l'execution en prod
Oui, en même temps le fait que ce soit possible est plutôt une qualité du langage. Python évite l'inflation de mots-clés en fournissant un langage souple qui permet aux programmeurs de réaliser les abstractions dont ils ont besoin sans que ça ait l'air affreux.
Tout a fait la logique se décrit avec 2 propositions. (non p et p=>q si mes souvenirs sont exacts)
On a juste créé 3 autres fonctions loqiques (et, ou et ou exclusif) pour faire affreux et pas pour du tout pour simplifier l'ecriture des propositions.
en python on a pas besoin du do while
while 1:
...
if(cond):
break
est beaucoup plus "joli"
Elégant, le mot-clé "virtual" dans la spécification des classes de base ? :-O
pas élegant peut-être pas mais cohérent sûrement.
L'ordre de résolution est : D, B, C, A, object. Profondeur d'abord ??
http://docs.python.org/tut/node11.html#SECTION00115100000000(...)
"This is depth-first, left-to-right"
Faudra qu'ils remettent à jour leur doc alors
C'est quoi le problème à résoudre ?
Si tu veux déclarer qu'un attribut est à usage interne, tu n'as qu'à le préfixer d'un underscore, c'est une convention suffisamment explicite pour indiquer à l'utilisateur de ta classe qu'il ne faut pas toucher à cet attribut-là.
Si l'utilisateur en question est assez téméraire pour passer outre, c'est son problème.
Le problème a résoudre est que je cherche le mot clé protected et non private.
La philosophie de Python n'est pas de prendre les développeurs pour des enfants et de mettre des barrières partout (contrairement à Java qui favorise le contexte social d'une informatique réalisée par une armée de tâcherons sous-payés et incompétents) ; c'est un langage pour adultes consentants. A chacun d'être à la hauteur.
Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Tu devrais peut-être te remettre au C
Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
Ca c'est de l'argumentaire.
Je ne relèverai même pas sur l'incompétence.-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 09:08. (lien). Évalué à 2.Ah oui et PEP 333
http://www.python.org/dev/peps/pep-0333/
"Status = Draft"
:D-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 13:45. (lien). Évalué à 2.Ah oui et PEP 333
http://www.python.org/dev/peps/pep-0333/
"Status = Draft"
Oui, comme beaucoup de RFCs de l'IETF...
Ce qui ne l'empêche pas WSGI d'être de plus en plus implémenté :
- liste de frameworks :
http://wsgi.org/wsgi/Frameworks
- liste de serveurs :
http://wsgi.org/wsgi/Servers
- liste d'applications :
http://wsgi.org/wsgi/Applications-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 22:35. (lien). Évalué à 2.
Oui, comme beaucoup de RFCs de l'IETF...
Je ne savais pas que python était une norme.Mes compliments
Ce qui ne l'empêche pas WSGI d'être de plus en plus implémenté :
Si j'ai bien compris, il y a autant d'implémentations que de framework..
javax.serlvet dispose d'une implémentation standard.
Vivement que wsgi fasse parie intégrante de la standard library :)
Bon c'est pas mal, il reste encore un peu de travail pour obtenir une spec aussi complète que JEE (EJB, RMI, ....)-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 22:56. (lien). Évalué à 3.Je ne savais pas que python était une norme.Mes compliments
Ma remarque renvoyait à "Status: Draft", pas à l'hypothèse d'un Python normalisé par l'IETF. :-)
Si j'ai bien compris, il y a autant d'implémentations que de framework..
WSGI est une API de communication entre serveurs Web et frameworks/applications. Je ne vois pas pourquoi il devrait y avoir une implémentation unique, l'intérêt de standardiser une API étant précisément de permettre la diversité des implémentations.
Ceci dit il y a bel et bien une "implémentation de référence" dans la lib standard.
http://docs.python.org/lib/module-wsgiref.html
("wsgiref is a reference implementation of the WSGI specification that can be used to add WSGI support to a web server or framework." : c'est donc surtout un jeu de fonctions pour se faciliter la tâche)
-
-
-
-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 13:43. (lien). Évalué à 3.en python on a pas besoin du do while
C'est une absence mineure, comme celle du switch case.
Je préfère cela à une absence majeure comme celle des fonctions comme objets à part entière.
Note que vouloir opposer Java à Python pour la concision du code est perdu d'avance de toute façon.
Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Python a le typage fort et le GC.
Il lui manque certes les "contrats" (mais Java les a-t-il ? hmmm ?).
Note qu'avec un peu d'imagination, tu pourrais faire une bibliothèque de contrats pour Python avec des décorateurs de fonctions. Je crois même que ça existe, mais j'ai la flemme de vérifier.
Le problème a résoudre est que je cherche le mot clé protected et non private.
Mais encore une fois, l'utilité d'une méthode se spécifie par la documentation, pas en ajoutant des mots-clés à qui mieux-mieux pour contrôler les accès. Un langage de programmation n'est pas un OS (quoiqu'au début, on nous prédisait littéralement que Java deviendrait l'OS ; j'imagine que dans cette optique il fallait garantir programmatiquement la protection des accès à chaque composant...).
En d'autres termes :
- soit ta méthode est privée et tu la préfixes par un underscore, la signification étant évidente
- soit ta méthode est destinée aux classes dérivées, et tu l'expliques dans la documentation (vu que de toute façon, il faut bien documenter tout ce qui est non-privé, n'est-ce pas ?)
Sinon va faire un tour sur les annonces d'emploi des devs Java et tu verras comme ils sont sous-payés.
Mmmh ?
Java a bien été conçu dans l'optique où le programmeur fait beaucoup de bêtises et où il faut une tonne de mécanismes impératifs pour le forcer à faire les choses correctement. C'est pour ça que c'est un langage très rigide et très verbeux.
Il ne faut pas croire aux fables de l'informatique d'entreprise : si Java s'est imposé en entreprise, ce n'est pas simplement parce qu'il y a un GC et un typage fort...
Java fait croire qu'il permet de tayloriser le travail de programmation, et donc de former des "informaticiens" à la chaîne dans l'optique de baisser les coûts. Evidemment en pratique un programmeur compétent est toujours nécessaire pour faire du bon code ; et un programmeur compétent est en général au moins aussi productif en Python (ou Ruby, etc.) qu'en Java. Hum.-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 22:21. (lien). Évalué à 2.
En python on a pas besoin du do while
C'est une absence mineure, comme celle du switch case.
Je préfère cela à une absence majeure comme celle des fonctions escomme objets à part entière.
Ce que je voulais signaler c'est qu'il vaut mieux utiliser des conventions explicites en enrichissant la syntaxe lorsque c'est nécessaire plutôt que de faire confiance à des idiomes du langage qui sont sujets aux défaillances humaines.
un programmeur inexpérimenté qui veut implémenter le do while sera tenté de mettre en place un truc du genre:
bloc_code1
while(cond):
... bloc_code1
au lieu de la construction montrée plus while 1:.
Il augmentera les chances d'erreur puisqu'il devra resynchroniser bloc_code1 dans les 2 références alors qu'il peut en fait n'en utiliser qu'une seule avec la construction while 1:
Note que vouloir opposer Java à Python pour la concision du code est perdu d'avance de toute façon.
Je ne cherche pas à démontrer que Java ou un langage typé statique est plus concis qu'un langage dynamique. Je montre simplement que le gain de productivité pour le prototypage et le dev est perdu en maintenance puisque le code produit par les premiers est de meilleure qualité et que le client s'expose à moins de déconvenues (cf. mon post plus bas) http://linuxfr.org/comments/785080.html#785080
Oui rejetons tout ce qui pemet d'apporter de la qualité aux developpement: les contrats, le typage fort, les GC.
Python a le typage fort et le GC.
Je voulais dire typage statique.
Pourquoi se passer d'une précaution supplémentaire. Le GC en est une autre et il servait d'exemple.
Il lui manque certes les "contrats" (mais Java les a-t-il ? hmmm ?).
Note qu'avec un peu d'imagination, tu pourrais faire une bibliothèque de contrats pour Python avec des décorateurs de fonctions. Je crois même que ça existe, mais j'ai la flemme de vérifier.
Les 2 l'implémentent avec des libs ou au travers des annotations.
Mais encore une fois, l'utilité d'une méthode se spécifie par la documentation, pas en ajoutant des mots-clés à qui mieux-mieux pour contrôler les accès.
...
- soit ta méthode est destinée aux classes dérivées, et tu l'expliques dans la documentation (vu que de toute façon, il faut bien documenter tout ce qui est non-privé, n'est-ce pas ?)
Oui et tu fais quoi si la lib que tu utilises n'emploie pas les mêmes conventions de documentation que toi ou que le dev n'a pas documenté tous les aspects. Il vaut mieux se palucher une fonction de doc de 15 lignes pour découvrir dedans que les attributs sont protégés plutôt que le langage te l'explicite. Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance. Rajoutes à ca qu'il faut documenter les exceptions que tu peux lever, les types de paramètres attendus si tu fais des traitements particuliers (ex de la somme des éléments d'une liste d'entiers). Tu peux aussi rajouter des assert qui ne sont vérifiés qu'à l'exécution et ne te protègent tjs pas des cas non prévus. Autant faire confiance au typage statique.
Mmmh ?
Java a bien été conçu dans l'optique où le programmeur fait beaucoup de bêtises et où il faut une tonne de mécanismes ....nformaticiens" à la chaîne dans l'optique de baisser les coûts.
On peut aussi dire que Java permet d'entreprendre des projets de plus grande envergure puisque les sources d'erreurs humaines qui ne sont as toujours dues à l'incompétence que tu insinues sont évitées.
Les développeurs du projet communautaire Apache sont-ils des victimes de ce taylorisme d'entreprises ?
Ca n'a pas forcément à voir avec la compétence des développeurs. Le même développeur devra être encore plus vigilant avec son code Python et perdra tout le temps gagné au prototypage à verrouiller son code. Ce point ne peut-être amélioré pour une langage dynamique alors que le codeur Java peut se reposer sur son IDE pour gagner en productivité.
En plus le monde Java dispose maintenant d'un langage dynamique avec une syntaxe à la Java et basé sur l'API Java Groovy. La boucle prototypage en langage dynamique et réécriture en langage statique a des fins d'optimisations ou de qualité est plus simple avec le couple Groovy/Java que le couple Python/C.-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 22:48. (lien). Évalué à 2.Oui et tu fais quoi si la lib que tu utilises n'emploie pas les mêmes conventions de documentation que toi ou que le dev n'a pas documenté tous les aspects.
Heu... la convention de documentation par excellence, c'est le langage naturel (l'anglais de préférence). Si la lib que tu utilises est documentée en islandais ou pas documentée du tout, le mot-clé "protected" ne va pas t'apporter grand'chose.
Je préfère faire confiance à la machine plutôt que m'en remettre à l'humain et à son inconstance.
L'humain est inconstant mais il est capable de faire passer des idées qu'un langage formel ne permet en général pas (ou alors au prix d'une lourdeur énorme : tu peux toujours créer des "ontologies" et coder ta doc en RDF (et qui débugge la doc ? :-)).
Bref, il est délicat de savoir où situer la frontière entre les deux. La distinction typage statique / typage dynamique relève aussi en partie de cette frontière (en partie seulement, cf. ci-dessous).
Autant faire confiance au typage statique.
Mais le typage statique étant statique, ta fonction "sum" qui additionne des entiers est impropre à l'addition d'autres choses que des entiers (par exemple, des réels ou des complexes). Il n'est pas sans contrepartie.
Apparemment certains langages (Haskell ?) ont un typage structurel, c'est-à-dire une sorte de duck typing à la compilation, où la vérification des arguments consiste à tester qu'ils supportent les bonnes opérations (et non pas qu'ils sont instances d'un type donné). Qu'on me corrige si je me trompe, mais ça me semble une version plus intéressante du typage statique.
La boucle prototypage en langage dynamique et réécriture en langage statique a des fins d'optimisations ou de qualité est plus simple avec le couple Groovy/Java que le couple Python/C.
En pratique on ne réécrit jamais de code Python en C, sauf parfois quelques bouts très critiques.-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 23:02. (lien). Évalué à 2.
Mais le typage statique étant statique, ta fonction "sum" qui additionne des entiers est impropre à l'addition d'autres choses que des entiers (par exemple, des réels ou des complexes). Il n'est pas sans contrepartie.
sauf si tu créer un interface qui répond à ton comportement (dans ton ca être sommable) ou que tu utilises des type paramétrés (templates).En outre on a une approche descendante, on modélise son système au niveau structurel (classe, intefaces).
C'est vrai que C++ permet la surcharge des opérateurs à la différence de Java. Ca a ses avantages mais c'est complexe à mettre en oeuvre.
En pratique on ne récrit jamais de code Python en C, sauf parfois quelques bouts très critiques.
En pratique on modélise son application et on génère le squelette décode à partir de ça et on le complète.
Je citais ca à titre d'exemple pour montre que l'approche était possible avec Java. Groovy étant plus proche de Java que jython ou jRuby.
Bon j'me marrais bien avec vous mais là j'vais m'pieuter-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 23:32. (lien). Évalué à 2.sauf si tu créer un interface qui répond à ton comportement (dans ton ca être sommable)
Oui, donc pour chaque méthode "toto" susceptible d'être appelée dans une fonction somme_toto(), tu vas définir une interface ITotoable que chaque classe ayant la méthode "toto" devra implémenter pour être utilisable dans somme_toto().
Hélas, un jour tu tombes sur une classe écrite par une autre personne, qui a bien implémenté une méthode toto(), mais sans référence à l'interface ITotoable. En effet, si "toto" est une notion connue bien d'informatique, ITotoable est de ton invention (et la communauté Java en étant à la standardisation de IFooBarable, il y a encore 5342 interfaces triviales à standardiser avant d'arriver à ITotoable... damned).
Alors là tu es bien marri pour utiliser sa classe dans ta fonction somme_toto() : tu dois écrire un adapteur pour renvoyer, à partir d'une instance de sa classe, une instance implémentant l'interface ITotoable et qui ne fera que wrapper l'instance originale.
Ce qui fait beaucoup de code, comment dire, un peu inutile. Tout ça parce que le typage dynamique, c'est mal (tm).
En outre on a une approche descendante, on modélise son système au niveau structurel (classe, intefaces)
Ah oui et quand on intègre des composants extérieurs (c'est quand même la base de ton argumentation sur le typage statique), on a vachement la maîtrise des classes et interfaces.
(ceci dit, tu as réussi à placer "approche descendante", chapeau :-)).-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 23:54. (lien). Évalué à 2.La sécurité est à ce prix. Ca coûte toujours moins cher que 2 jours d'indisponibilité chez le client. Chacun ses priorités.Perdre un client ou se faire plaisir.
Ah oui et quand on intègre des composants extérieurs (c'est quand même la base de ton argumentation sur le typage statique), on a vachement la maîtrise des classes et interfaces.
S'il s'agit de composants développé à l'extérieur on doit adapter mais au moins on maîtrise ce qu'on fait.
Et l'adaptateur ne fait pas partie des design pattern du Gof pour rien.
Par contre si il s'agit de composant développé en interne mais appelé depuis un autre module, il faut juste une bonne conception.
ceci dit, tu as réussi à placer "approche descendante", chapeau :-)).
Toi aussi ... le business loto :D
-
-
-
-
-
-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 15/12/2006 à 16:12. (lien). Évalué à 2.> Si mais tu ne le découvres pas à l'execution en prod ...
décidément ;-)
si "i" est NULL, ça pete en prod ça :
string s = i.ToString();
non ? ;-)
c'est bien du typage static, et seul les unittests peuvent les sortir ...
et ce n'est pas relevé par eclipse, le compilateur ou tout autre truc magique ...-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 20:55. (lien). Évalué à 3.Evidemment, tu me sors unr erreur qui ne peut être détectée qu'à l'exécution.
Je n'ai jamais prétendu qu'on pouvait se passer des tests unitaires avec les langages à typage statique et c'est pas pour rien qu'il existe jUnit en Java.
Le typage statique apporte simplement un niveau de sécurité supplémentaire.
Maintenant observe le code suivant:
l=range(35)
>>> def sum(l):
... j=0
... for i in l:
... j=j+i
... return j
...
>>> a=sum(l)
>>> sum(range(35))
595
Imagines que la fonction sum soit placée dans un module m1, qu'un développeur utilise cette fonction dans son propre module m2 et l'inclue dans une fonction plus spécifique qui accepte encore "l" en paramètre.Imagines que cette fonction soit mal documentée (l'erreur est humaine et la paresse encore plus), ou encore que celui qui utilise m2 implémente un algorithme complexe pour construire la liste en paramètre à la fonction de m2.
Du coup la liste passée en paramètre en prod est.
l=[1,"2",3]
(Les test d'intégrations ne pouvant être jamais être exhaustifs en raison de la combinatoire)
Résultat des courses en prod
Traceback (most recent call last):
File "", line 1, in ?
File "", line 4, in sum
TypeError: unsupported operand type(s) for +: 'int' and 'str'
Avec un langage typé statiquement, tu as déclaré un type tableau d'entiers en paramètre des fonctions et l'algorithme de l'utilisateur devra accepter des int ou ne compilera pas(éventuellement après un cast s'il manipule des Object ou d'autres types).
Et là on parle des types de base, mais on a le même type de contrôles avec des classes ou des interfaces alors que le duck typing ne vérifiera rien et te lanceras des exceptions tout pareil.
Imagines que tu aies affaire à des dizaines de composants avec de nombreuses dépendances et tu augmentes la probabilité de ce genre d'erreur, surtout si tu intègres des modules externes que ton équipe n'a pas développé. Là où la documentation fait foi et où on se base sur des conventions implicites qui sont sujettes à négligence ou oubli, le typage explicite et uniforme montre sa supériorité.
Avec Java, les exceptions sont également vérifiées à la compilation et sont explicitées alors qu'avec un langage typé dynamiquement tu dois te coltiner tout l'arbre de dépendance pour vérifier dans la doc ou dans le code toutes les exceptions qui sont susceptibles d'être levées.-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 15/12/2006 à 22:31. (lien). Évalué à 3.Certes, ce que tu dis est vrai ...
mais ce n'est que les différences entre 2 types de langage ...
il y a vraiment 2 écoles ...
(moi pour eviter ce genre de problème en aval, j'ai tendance à mettre des assert, ça evite d'avoir des surprises plus loin (mais c au runtime : on est d'accord))
> le typage explicite et uniforme montre sa supériorité.
Comme disait qqu'un dans le thread ... ça permet surtout à un programmeur de ne pas faire des erreurs bêtes (sinon ça compile pas). Ce qui permet de prendre des devs moins "experimentés" (dans le sens, suffit de lire le message d'erreur du compilateur, puis de corriger)
On est d'accord, ça donne un certain gage de "qualité" ... le dev est corrigé en amont !
Mais, vraiment, pour faire du csharp(~=java) à longueur de journée, ça apporte aussi énormément de bruit, et d'obligations (déclaration de type, castage toutes les 2 lignes) .... pour des choses souvent simples/triviales. Ca a aussi tendance à augmenter énormément le nb de lignes (5 à 10x) pour un même algo. ça prends du temps !
J'aurai tendance à penser qu'on est en permanence en train de lutter avec ces obligations et ces syntaxes, ce qui empêche réellement de se concentrer sur l'algorithme qu'on est en train d'implémenter. Le cerveau est en permanence agacé par ce bruit. (oui, les habitudes et un bon ide aident énormément)
En python, tu as cette liberté qui est énorme, le cerveau est totallement libre pour se concentrer sur l'essentiel : l'algorithme à implémenter.
Après c'est des conventions de codage, et de documentation. On doit plus faire confiance à l'humain, au dev.
Certes en statiquement typé, tu peux aussi faire du "dynamique", travailler avec des "objects" et caster à tout bout de champs. Mais dès que t'as besoin de faire de l'introspection, de créer des class dynamiquement, et toutes ces genres de choses : ça rentre très vite dans du code complexe, voire très tordu. (genre appelé dynamiquement une méthode d'une instance de classe que tu ne connais pas).
Maintenant dans la vraie vie pythonesque, j'utilise énormément de libs que j'ai pas codé et même pas vu le code .... et je peux te dire que c'est très très rare de tomber sur le genre d'erreur que tu décris (même si c'est techniquement possible)
Tu tombes bien plus souvent sur des "null object reference" que sur des erreurs de type ... et ça j'ai aussi avec des assemblies externes que je n'ai pas codé, en csharp (et dont je ne peux pas voir le code, en passant ;-)
L'avantage de python : c'est la vitesse de développement, bien supérieure aux langages statiquement typé.
Mais au boulot, quand je dois concevoir un "algo complexe" (embriquement d'algo), je le fais vite fait en python pour voir si ça roule, et je le traduis après en cs. C'est bien plus rapide que le faire en CS. Quand je dis complexe : c pas qqchose de pondable en "one shot", donc ça necessite qques tatonnements, et avec les languages compilés tu perds déjà 50% du temps à compiler avant de tester rellement l'algo ... et 30% du temps à batailler avec les syntaxes/obligations.
(bon quand ça compile, ça me laisse le temps de surfer ;-)
-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 22:32. (lien). Évalué à 2.Avec un langage typé statiquement, tu as déclaré un type tableau d'entiers en paramètre des fonctions et l'algorithme de l'utilisateur devra accepter des int ou ne compilera pas(éventuellement après un cast s'il manipule des Object ou d'autres types).
Oui, mais si tu ajoutes un cast depuis Object, tu reviens aux effets que tu critiques, à savoir : possibilité d'exception à l'exécution.
tu dois te coltiner tout l'arbre de dépendance pour vérifier dans la doc ou dans le code toutes les exceptions qui sont susceptibles d'être levées.
Ben non, tu ne dois pas te coltiner l'arbre de dépendances, puisque l'effet souhaité pour la plupart des exceptions est d'arrêter totalement le programme (ou la branche concernée), pas d'effectuer un traitement de réparation spécifique. Il y a peu d'erreurs qui soient rattrapables correctement.
C'est justement l'intérêt des exceptions par rapport à l'utilisation de valeurs de retour que de pouvoir se propager automatiquement jusqu'au toplevel, au lieu de devoir les propager à la main.-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 22:49. (lien). Évalué à 2.Oui, mais si tu ajoutes un cast depuis Object, tu reviens aux effets que tu critiques, à savoir : possibilité d'exception à l'exécution.
Non puisque tu dois transformer ta chaîne "2" en int avant de la passer à ta liste en paramètre. Dons c'est à la compil que tu détecte le pb.
Ben non, tu ne dois pas te coltiner l'arbre de dépendances, puisque l'effet souhaité pour la plupart des exceptions est d'arrêter totalement le
...
C'est tout le contraire.
Le but du jeu c'est justement que chaque bloc appelant intercepte l'exception à son niveau pour libérer des ressources qu'il a ouvert( fichier ouvert, connection à une db,..) et relance aux niveau supérieur.
En plus si tu ne l'intercepte pas à un moment donne tu sors du programme. Donc il faut bien faire le tri entre les exceptions qui te permettre de retrouver un état stable et celles qui sont irrécupérables.-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 23:05. (lien). Évalué à 3.Non puisque tu dois transformer ta chaîne "2" en int avant de la passer à ta liste en paramètre.
Heu, en général quand on fait ce genre d'erreur c'est que la chaîne provient de l'extérieur, pas qu'on a ajouté des guillemets par erreur dans le source. Du coup le compilateur ne voit qu'un Object et il ne peut que déférer la résolution du cast à l'exécution.-
[^]Re: Excellente nouvelle
Posté par golum () le 15/12/2006 à 23:17. (lien). Évalué à 2.Relis mon exemple,c'est bien appelé depuis l'extérieur mais refusera de compiler avec un tableau d'Object en paramètres. Il devra donc le transformer en tableau de int et aura donc anticipé le pb.
Avec du python tu construis ta liste sans faire au fait qu'elle peut contenir des chaînes. Quand ca pète en prod tu cherches dans l'urgence et merde j'ai oublié de transformer les objets de ma liste en en entiers avant l'appel.-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 23:35. (lien). Évalué à 2.Il devra donc le transformer en tableau de int et aura donc anticipé le pb.
"Anticipé" comment ça ? Si tu ne sais pas avant l'exécution qu'il y aura une chaîne de caractères parmi ces Object, l'erreur ne sera levée qu'à l'exécution.
Quand ca pète en prod tu cherches dans l'urgence et merde j'ai oublié de transformer les objets de ma liste en en entiers avant l'appel.
Heu, il n'y a toujours pas de différence avec un cast dynamique qui foirerait à l'exécution... Juste que dans un cas, il y a un test de type, alors que dans l'autre il y a un test structurel (présence d'une méthode).-
[^]Re: Excellente nouvelle
Posté par golum () le 16/12/2006 à 00:22. (lien). Évalué à 2.Oui t'as raison sur ce coup là. J'aurais pas du parler d'Object juste de int.
Reste que l'argument initial est quand même valable.
Le fait que le dev python sera quand même tenté d'utiliser des listes d'objets de types différent sans s'apercevoir qu'une liste d'entier est attendue parce que la fonction intermédiaire le masque.
Le dev Java sera prévenu et s'il ne bidouille pas sa liste(caste vers Object puis downcast), y'a pas de pbs.
Pour le fait que tu es limité à des int (cf. ton post sur les ontologies) tu as quand même les types paramétrés.
Mais c'est vrai que si tu veux utiliser des listes d'objets hétérogènes tu t'exposes aux mêmes risques qu'avec les langages dynamiques , la verbosité en plus.
-
-
-
-
-
-
-
-
[^]Re: Excellente nouvelle
Posté par Sylvain Sauvage () le 15/12/2006 à 18:13. (lien). Évalué à 4.Tout a fait la logique se décrit avec 2 propositions. (non p et p=>q si mes souvenirs sont exacts)
Un seul opérateur suffit pour définir les opérateurs usuels de la logique du 1er ordre, nand :
not(a) = nand(a, a)
or(a, b) = nand(not(a), not(b))
and(a, b) = not(nand(a, b))
…-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 15/12/2006 à 19:57. (lien). Évalué à 2.tu as un rapport avec seb sauvage ?
-
[^]Re: Excellente nouvelle
Posté par Sylvain Sauvage () le 16/12/2006 à 10:40. (lien). Évalué à 2.Non, pas à ma connaissance.
Des sauvages, il y en a partout, il suffit d'une forêt.
Et puis je suis hétéro…
-
-
[^]Re: Excellente nouvelle
-
-
-
-
-
[^]Re: Excellente nouvelle
Posté par Stéphane TRAUMAT (page perso, ) le 14/12/2006 à 13:56. (lien). Évalué à 2.La complétion et l'aide au code est à mon avis fondamental... que ce soir pour parcourir des objets ou pour gérer les imports de manière automatique.
Le debuggage dans Eclipse est formidable, on a une vision de tous les objets, on peut remonter dans les appels, faire tout ce qu'on veut d'une manière hyper simple et hyper propre !, honnêtement, ça n'a rien à voir avec le genre de debuggage dont tu me parles.
et tu peux aussi debugger une appli distante.
Quand au refactoring, cet aspect me parait fondamental. Quand tu veux changer le nom d'une classe ou d'un package sur une appli qui a des milliers de lignes de code, c hyper simple et ça ne te fait pas d'erreur.-
[^]Re: Excellente nouvelle
Posté par golum () le 14/12/2006 à 14:44. (lien). Évalué à 2.Bon je vais les aider un peu.
Python founit un module de refactoring pas trop mal fait qui peut être intégré dans pas mal d'IDE
http://bicyclerepair.sourceforge.net/
D'ailleur un IDE assez sympatoche le propose (pyQT)
http://www.die-offenbachs.de/detlev/eric.html-
[^]Re: Excellente nouvelle
Posté par wilk (Jabber id, page perso, ) le 14/12/2006 à 16:16. (lien). Évalué à 2.Bien sûr qu'il y a tous ces outils, ce que je voulais dire simplement c'est qu'ils ne sont pas aussi indispensables qu'ils ne le sont en java. Donc la course aux armements n'a pas forcément de sens.
Concrêtement j'ai besoin de beaucoup moins d'outils d'aide quand je fait du python que quand je faisait du java. Tout simplement puisque mes programmes sont beaucoup plus courts (hors ils font toujours à peu près le même genre de choses).
Je sais c'est agaçant à entendre sans arrêt, j'ai fait aussi du java, je compatis ;-)
-
-
[^]Re: Excellente nouvelle
Posté par Antoine () le 15/12/2006 à 08:47. (lien). Évalué à 2.La complétion et l'aide au code est à mon avis fondamental...
Ce sont des choses gérées par l'interpréteur Python.
Après c'est une question de méthodes de travail : en Java on aime avoir un énorme IDE tout-en-un, en Python l'interpréteur interactif fournit la possibilité d'explorer les modules (y compris la documentation) et de tester des bouts de code à la volée.
Mais dire que Python ne fournit pas de possibilités d'introspection, de parcours de modules, c'est au mieux de l'ignorance.
(et il y a certainement des IDE qui intègrent la ligne de commande Python)
-
-
-
-
[^]Re: Excellente nouvelle
Posté par Putifuto () le 14/12/2006 à 10:13. (lien). Évalué à 2.la nature du langage python très dynamique rend une complétion parfaite impossible.
exemple:
>>> class Titi:
... pass
...
>>>t=Titi()
>>>t.plop=2 # que la complétion s'amuse avec ça :)
>>>exec("t.vole=1") # et avec ça aussi :)
>>> dir(t)
['__doc__', '__module__', 'plop', 'vole']
>>> delattr(t,"plop")
>>> delattr(t,"vole")
>>> dir(t)
['__doc__', '__module__']
ainsi, pour avoir les membres de l'objet t, il faut exécuter le code.
Perso, j'aime bien python mais je ne rêve pas sur une complétion parfaite. Et celle d'Eclipse est très loin d'être parfaite :)--
http://linuxfr.org/board <-- des moules, du sang, de la violence-
[^]Re: Excellente nouvelle
Posté par manatlan (Jabber id, page perso, ) le 14/12/2006 à 12:32. (lien). Évalué à 3.tout à fait, ce n'est pas encore tout à fait au point dans eclipse avec pydev
(cependant ça semble bien plus avancée dans la version payante de pydev)
Cependant aussi : ulipad (anciennement newedit) va beaucoup plus loin.
et est capable de trouver la méthode plop de l'instance de ta class titi. (comme dit, j'ai l'impression qu'il execute en live ?!)
Mais on est d'accord, c'est beaucoup moins necessaire en python quand java/csharp.
La completion des objets dispo dans le source suffit amplement (scite le fait très bien)
-
-
-
-
-
Ajax et la sécu...
C'est génial de faciliter/accélérer le taf de la couche présentation. En général c'est pas la partie la plus passionnante.
Mais...il y a quelques semaines, je suis tombé la-dessus: http://it.slashdot.org/article.pl?sid=06/12/01/1634203 concernant Ajax justement (le JavaScript évidement).
Cette page a été générée par Templeet en 17.7262s (dont 0.0234 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.