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.
Aller plus loin
- Blog GWT (5 clics)
- Google Web Toolkit (2 clics)
- Exemples (9 clics)
# Ca va booster le web2.0
Posté par Matthieu . Évalué à 2.
Peut-être verra-t-on fleurir du GWT dans esup :-)
[^] # Re: Ca va booster le web2.0
Posté par Nicolas Legrand (site web personnel) . Évalué à 6.
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 (site web personnel) . Évalué à -1.
http://about.me/straumat
[^] # Re: Ca va booster le web2.0
Posté par Antoine . Évalué à 1.
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 . Évalué à 8.
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 (site web personnel) . Évalué à 4.
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).
http://about.me/straumat
[^] # Re: GWTSAPU...
Posté par jigso . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 ?
http://about.me/straumat
[^] # Re: GWTSAPU...
Posté par jigso . Évalué à 1.
Allez, c'est 22¤. A bientôt et soignez-vous bien.
[^] # Re: GWTSAPU...
Posté par golum . Évalué à 3.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 4.
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...
Posté par encre (site web personnel) . Évalué à 2.
[^] # Re: GWTSAPU...
Posté par Stéphane Traumat (site web personnel) . Évalué à 1.
http://about.me/straumat
[^] # Re: GWTSAPU...
Posté par encre (site web personnel) . Évalué à 2.
# et avant ?
Posté par Anonyme . Évalué à 4.
Il me semble que c'etait deja disponible sous une licence libre depuis quelques mois ...
# GWT est-il vraiment libre ?
Posté par golum . Évalué à 5.
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 . Évalué à 5.
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 . Évalué à 0.
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 !!
Posté par soulflyb (Mastodon) . Évalué à 3.
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 . Évalué à 6.
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 soulflyb (Mastodon) . Évalué à 1.
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 . Évalué à 3.
(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 Victor . Évalué à 2.
[^] # Re: Enorme !!
Posté par golum . Évalué à 2.
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...
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
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 :(
http://about.me/straumat
[^] # Re: Un retour d'expérience sur GWT...
Posté par Jérôme BENOIS . Évalué à 1.
[^] # Re: Un retour d'expérience sur GWT...
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
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");
http://about.me/straumat
[^] # Re: Un retour d'expérience sur GWT...
Posté par golum . Évalué à 2.
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 (site web personnel) . Évalué à 2.
http://about.me/straumat
# J'adore !
Posté par Flipo . Évalué à 2.
[^] # Re: J'adore !
Posté par julione . Évalué à 1.
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
Posté par manatlan (site web personnel) . Évalué à 2.
http://pyjamas.pyworks.org/FR/
nulle doute que ça va booster pyjamas !
[^] # Re: Excellente nouvelle
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
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...)
http://about.me/straumat
[^] # Re: Excellente nouvelle
Posté par manatlan (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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é
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 2.
C'est ça, qui est plus rapide que l'execution du même source python sous cpython
[^] # Re: Excellente nouvelle
Posté par Pinaraf . Évalué à 2.
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 (site web personnel) . Évalué à 2.
"ç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 . Évalué à 3.
; ) ;) ;) ;) ;)
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 (site web personnel) . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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.
http://about.me/straumat
[^] # Re: Excellente nouvelle
Posté par manatlan (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
http://about.me/straumat
[^] # Re: Excellente nouvelle
Posté par wilk . Évalué à 3.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 1.
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 . Évalué à 3.
Si mais tu ne le découvres pas à l'execution en prod
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"
pas élegant peut-être pas mais cohérent sûrement.
http://docs.python.org/tut/node11.html#SECTION00115100000000(...)
"This is depth-first, left-to-right"
Faudra qu'ils remettent à jour leur doc alors
Le problème a résoudre est que je cherche le mot clé protected et non private.
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 . Évalué à 2.
http://www.python.org/dev/peps/pep-0333/
"Status = Draft"
:D
[^] # Re: Excellente nouvelle
Posté par Antoine . Évalué à 2.
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 . Évalué à 2.
Je ne savais pas que python était une norme.Mes compliments
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 . Évalué à 3.
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 . Évalué à 3.
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 . Évalué à 2.
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:
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
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.
Les 2 l'implémentent avec des libs ou au travers des annotations.
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.
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 . Évalué à 2.
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 . Évalué à 2.
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 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 . Évalué à 2.
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 . Évalué à 2.
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.
Toi aussi ... le business loto :D
[^] # Re: Excellente nouvelle
Posté par manatlan (site web personnel) . Évalué à 2.
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 . Évalué à 3.
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:
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
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 (site web personnel) . Évalué à 3.
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 . É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.
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 . Évalué à 2.
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.
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 . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 2.
"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 . Évalué à 2.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 2.
[^] # Re: Excellente nouvelle
Posté par Sylvain Sauvage . Évalué à 2.
Des sauvages, il y en a partout, il suffit d'une forêt.
Et puis je suis hétéro…
[^] # Re: Excellente nouvelle
Posté par golum . Évalué à 2.
La fac, ca remonte à quelques années pour moi.
[^] # Re: Excellente nouvelle
Posté par Stéphane Traumat (site web personnel) . Évalué à 2.
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.
http://about.me/straumat
[^] # Re: Excellente nouvelle
Posté par golum . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
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 :)
[^] # Re: Excellente nouvelle
Posté par manatlan (site web personnel) . Évalué à 3.
(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...
Posté par ome . Évalué à 1.
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).
# brevet de l'interface graphique
Posté par romi . Évalué à 3.
http://akosh.pcinpact.com/actu/news/33390-brevet-google-interface.htm
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.