L'utilité des langages dynamiques
Moandji Ezana
Ca n'est pas pour rien si Scala ajoute une extension dynamique au langage, et que Groovy a enfanté Groovy++ qui, lui, tend vers le typage statique : ça montre simplement qu'au sein d'un même langage, les 2 ont leur place. Il faut simplement savoir quand utiliser l'un et l'autre.
Guillaume Laforge
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Moandji Ezana
Je t'invite à utiliser Groovy dans une semaine, et je relèverai ta copie à ce moment là :-)
Guillaume Laforge
Moandji--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Alexandre Bertails
> C'est justement parce que ce sont des langages dynamiques que beaucoup d'API
> sont simplifiées (tout en étant aussi puissantes si ce n'est plus), qu'on
> peut écrire du code métier lisible, etc.
Quel est les criteres pour "simplifiées", "aussi puissantes si ce
n'est plus" et "code métier lisible" ?
> Les langages statiques arrivent aussi à faire des choses pas mal non plus,
> mais souvent un cran en deça de ce que peut faire un langage dynamique.
Y a de la recherche [1] sur le sujet ou des bouquins [2] pour se faire
une reelle idee en tant que programmeur. C'est plus utile que de
lancer des assertions sans reel fondement.
On est en 2011, on a plusieurs decennies de recherche en theorie des
langages derriere nous, mais encore trop peu de gens capable de parler
formellement (ni meme qualitativement) de langages informatiques avec
un niveau satisfaisant...
J'accepte que l'implementeur d'une API me dise "le typage statique ca
me fait un peu mal a la tete car je dois reflechir un peu plus". Mais
au moins, en tant qu'utilisateur, je peux me laisser guider par les
types, aide par l'analysateur statique de mon langage prefere. Et ca,
quelque soit la metrique retenue (et un peu de mauvaise foi) pour dire
qu'un langage dynamique sera mieux, je ne l'abandonnerai pour rien au
monde.
Alexandre Bertails, W3C Systems Team.
[1] http://crpit.com/confpapers/CRPITV91Holkner.pdf
[2] http://www.manning.com/ghosh/
Guillaume Laforge
Emmanuel Lecharny
> C'est justement parce que ce sont des langages dynamiques que beaucoup d'API
> sont simplifiées (tout en étant aussi puissantes si ce n'est plus), qu'on
> peut écrire du code métier lisible, etc.
> Les langages statiques arrivent aussi à faire des choses pas mal non plus,
> mais souvent un cran en deça de ce que peut faire un langage dynamique.
Bof... C'est pas un arguement, Guillaume, c'est du marchéage...
Si c'était aussi évident, les langages statiquement liés ne seraient pas
dominant...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Guillaume Laforge
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Emmanuel Lecharny
> Je dois avouer que ce soir j'ai pas le courage de passer des heures sur ce
> thread là, où je sais qu'on n'aboutira à rien, car il y aura toujours des
> partisants pour l'un ou pour l'autre camp, sans que jamais qui que ce soit
> tombe d'accord.
dans l'autre ? Les langages dynamiques répondre à un cerain type de
problèmes, les langages statiques à un autre. A quel esprit opacifié par
la pâte à rire viendrait-il l'idée d'écrire des scripts en java, par
exemple ? Et à contrario, pour une application critique avec de spbs de
perfs à la clé, pourquoi chosirait-on un langage dynamique (ta mère) ?
> Mon expérience fait que j'arrive beaucoup plus facilement à écrire des APIs
> et des algorithmes en Groovy qu'en Java ou en Scala.
*ton* expérience. Mais tu Groovytes depuis des années.
> Plus facile qu'en Java car le code est beaucoup plus lisible, plus concis,
> moins verbeux, grâce à des aspects de programmation fonctionnelle, les
> closures, la syntaxe allégée, etc...
Oauis, bon, là, je te rejoins pas. Je fais parti du clan de ceux qui
pense que rajouter toutes ces cocherneries dans un langage c'est juste
filer du viagra à des violeurs en séries...
> et j'ai aussi beaucoup moins mal au
> crâne que quand j'utilise Scala, avec son type system super complexe.
Bon, désolé, j'ai pas d'aspirine. Et j'ai pas non plus envie d'avoir mal
au crane, donc je fais pas de Scala. Scala, c'est comme plus haut, le
viagra, sauf que là, tu le donnes au violeur en série et tu lui indiques
le chemin le plus court pour aller au pensionnat de jeune filles d'à
côté (et en plus, tu lui files le code de la porte)...
> Personnellement, c'est plus la pratique qui me fait préférer les langages
> dynamiques que les langages statiquement compilés.
ca se comprend.
> J'aime évidemment particulièrement Groovy car tu as le "typage optionnel"
> qui te permet d'ajouter autant de typage dont tu as besoin, ou avec lequel
> tu te sens à l'aise dans tes baskets.
> Voila.
C'est sûr que c'est plus confortable que des rangers (Java)... D'un
autre côté, dans un chemin boueux :)
> Je ne cherche pas à convaincre qui que ce soit, ou à sortir des études
> partisanes de mon chapeau.
ben voilà...
Julien Ponge
On est en 2011, on a plusieurs decennies de recherche en theorie des
langages derriere nous, mais encore trop peu de gens capable de parler
formellement (ni meme qualitativement) de langages informatiques avec
un niveau satisfaisant...
Cédric CHAMPEAU
Ainsi, un langage dynamique comme Groovy permet :
- de typer dynamiquement
- de spécifier le comportement des appels de méthodes au runtime
- de spécifier le comportement d'appels de méthodes manquantes ou de propriétés manquantes au runtime
- de répondre à des problématiques complexes comme l'héritage multiple de façon très élégante
- de se concentrer sur les algorithmes plus que sur le modèle de données (ce qui est aussi l'adage des langages fonctionnels)
Par exemple, le "duck typing" est une fonctionnalité très intéressante des langages dynamiques. En Java pur, vous devriez définir de multiples interfaces pour chaque algorithme travaillant sur des objets ayant des méthodes communes (Java n'ayant pas le concept de propriétés, il est même impossible de faire des algorithmes se basant uniquement, par contrat, sur ces dernières). Le principe du duck typing est de dire qu'un algorithme fonctionne à partir du moment où un objet répond à un contrat donné, ledit contrat n'ayant pas besoin d'être explicité. C'est un peu le principe philosophique de ce qui définit un être humain : est-ce son comportement, ou sa spécification ? Connaît-on toutes les caractéristiques qui font un être humain ? Une machine qui penserait, serait capable de sentiments, aurait l'apparence humaine, capable de se reproduire avec des êtres humains serait-elle ou non un être humain (que les amateurs de Battlestar Gallactica lèvent le doigt) ? Souvent, il n'est pas possible, ne serait-ce que parce qu'on utilise une API tierce, de connaître toutes les utilisations possibles d'un objet à l'avance, et donc toutes les caractéristiques qui pourraient être communes avec d'autres implémentations. Pourtant, les méthodes et les propriétés sont là, il n'y "a qu'à".
L'autre avantage d'un langage comme Groovy, dynamique, est donc évidemment les DSL. Là, on entre même dans ce qui fait leur gloire. Pour changer, je vais juste copier/coller un bout de code, il s'agit bien de code, Ruby, vu ce jour même (http://iain.nl/2011/01/cucumber-vs-steak/) :
Feature: pay bill on-line
In order to reduce the time I spend paying bills
As a bank customer with a checking account
I want to pay my bills on-line
Scenario: pay a bill
Given checking account with $50
And a payee named Acme
And an Acme bill for $37
When I pay the Acme bill
Then I should have $13 remaining in my checking account
And the payment of $37 to Acme should be listed in Recent
Payments
Cette capacité d'écrire du code lisible, compréhensible par des non programmeurs fait peur à certains, parce que leur IDE ne leur offre aucune complétion automatique, et ne leur dit pas de quel type est l'expression "Given checking accoun with $0". La réalité, c'est qu'on s'en moque totalement : ce qui importe, c'est que ce soit lisible.
Dans les pourfendeurs du dynamique, on trouve aussi de nombreuses personnes qui vont dire "c'est très facile d'écrire du code illisible ou crado". La réalité, pour la vivre au quotidien, c'est qu'il n'y a pas besoin de donner un langage dynamique à quelqu'un pour qu'il produise du code illisible ou crado. En revanche, une réalité, c'est que moins de code à lire, c'est aussi moins de code à maintenir, et donc moins d'endroits où chercher des bugs. En revanche, certains algorithmes ou certains cas d'usage (pensez à l'industrie aéronautique) nécessitent un typage fort et un contrôle de code statique extrêmement pointu, et il est donc strictement nécessaire de disposer d'un comportement sans surprise. Ma position est donc simple : un bon langage est un langage capable de faire les 2. En ce qui concerne Java et Groovy, ni l'un, ni l'autre ne le font. Java est strictement statique, Groovy rigoureusement dynamique.
Ainsi, pour reprendre la réflexion qui a fait naître ce thread, on voit bien que l'ajout de "code statique" dans Groovy++ et l'ajout de dynamisme à Scala convergent bien vers cette idée : nous avons besoin d'un langage capable de faire les 2. En philo, j'aurais eu au moins la moyenne, pour avoir respecté le principe de la thèse/antithèse/synthèse :)
Guillaume Laforge
Mais c'est ça qui est stupide ! Poruquoi faudrait-il être d'un camp ou dans l'autre ? Les langages dynamiques répondre à un cerain type de problèmes, les langages statiques à un autre. A quel esprit opacifié par la pâte à rire viendrait-il l'idée d'écrire des scripts en java, par exemple ? Et à contrario, pour une application critique avec de spbs de perfs à la clé, pourquoi chosirait-on un langage dynamique (ta mère) ?
Julien Ponge
Donc je peux te dire que les langages dynamiques ne sont pas bons que pour du scripting, et pas bons pour des applications critiques.Idées préconçues tout ça.
Emmanuel Lecharny
> 2011/1/31 Emmanuel Lecharny<elec...@gmail.com>
>
>> [...]
>> Mais c'est ça qui est stupide ! Poruquoi faudrait-il être d'un camp ou dans
>> l'autre ? Les langages dynamiques répondre à un cerain type de problèmes,
>> les langages statiques à un autre. A quel esprit opacifié par la pâte à rire
>> viendrait-il l'idée d'écrire des scripts en java, par exemple ? Et à
>> contrario, pour une application critique avec de spbs de perfs à la clé,
>> pourquoi chosirait-on un langage dynamique (ta mère) ?
>>
> Ca encore c'est des a priori justement.
> Je citerais deux gars que je connais : l'un fait de la simulation numérique
> scientifique dans le nucléaire... avec du Groovy...
Heureusement que c'est que de la simulation :)
> et l'autre fait de la
> finance quantique (je sais plus comment ça se traduit en français) pour des
> hedge funds pour les traders (et je peux te dire qu'il y a une tonne de
> calculs là-dedans).
Ouais... Il était chez Lehmann Brother en 2008 ? ;)
> Donc je peux te dire que les langages dynamiques ne sont pas bons que pour
> du scripting, et pas bons pour des applications critiques.
> Idées préconçues tout ça.
Bien sûr. Mais ça n'a pas d'importance. Globalement, ceux qui aiment les
langages dynamques pensent que c'est mieux, ceux qui aiment les langages
statiques pensent que c'est mieux, et les autres utilisent ce qui
correspond le plus à leur besoin.
Que demander de plus ?
Henri Gomez
Jython quel serait votre top 3.
PS: Guillaume tu n'as pas le droit de voter :)
Stephane Maldini
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Stephane Maldini
Emmanuel Lecharny
<rant non personnel>
dans ton mail, j'ai pas compris la moitié de choses, il me donne mal à
la tête...
J'ai pas la prétention d'être un cador du dev, mais j'ai quand même un
certain background et technique et pratique dans la besace.
Si je comprend pas la moitié de ce que tu racontes sans avoir besoin
d'aspirine et de co-doliprane, alors je pense qu'il y a bien la moitié
des développeurs qui comprennent pas non plus.
Pas de chance, c'est avec eux qu'on bosse tous les jours... Alors,
désolé, si je tombe sur un gars sur un projet qui me sort des trucs
aussi imbitables, moi, je le gicle ou je me démerde pourt qu'il revienne
à une pratique du code absorbable par ses petits camarades.
Nivellement par le base ? Peut-être. Mais franchement, j'en ai ma claque
des têtes d'ampoules qui me chient des frameworks à la mord moi le
chibre sur un projet, et qui se cassent au bout de trois mois pour aller
pondre leur bouse dans une techno top de la pointe, en laissant leur
fatras à des personnes qui n'ont pas le bagage technique pour reprende
le travail pas fini et non maintenable...
</rant non personel>
Sinon, je suis sûr qu'à l'INIRIA, il y a de la place pour ce genre de
technos :) Non, franchement, on a l'impression qu'ici, tout le monde
développe un nouveau Linux dans leur salon le soir avant d'aller se
brosser les dents !
Sérieusement, vous avez *déjà* bossé dans une équipe projet avec plus de
2 personnes ???
>> lescastcodeur...@googlegroups.com<lescastcodeurs%2Bunsu...@googlegroups.com>
>> .
>> Pour plus d'options, consultez la page de ce groupe :
>> http://groups.google.com/group/lescastcodeurs?hl=fr
>>
>>
>
--
Henri Gomez
Emmanuel dans son style inimitable souligne un point important que
nous connaissons tous.
Dans la plupart des boutiques, la population n'est pas homogène.
* Les cadors qui sortent des trucs de folie avec des frameworks en
0.87-dev et que personne ne comprend (le framework et le cador).
D'ailleurs ils changent tellement souvent de framework nouveaux
qu'après quelques années, plus personne en plus ne les écoute. Par
contre on se retrouve avec un beau SICOB où il y a tellement de piles
différentes qu'on se demande souvent comment ça fonctionne.
* Des personnes qui feront leur job de bien à médiocrement parce que
le développement ce n'est juste pas leur truc. L'informatique est un
boulot qui n'est pas leur passion et font ce qu'on leur demande, sans
forcément chercher à juger ou remettre en cause.
* Des chefs de projets et fonctionnels qui se moquent de la beauté de
l'archi mais veulent juste que ça marche en temps et heure et
martellent qu'on nettoiera quand on aura le temps (donc jamais).
* Des équipes de productions qui frémissent dès qu'on leur met pose un
nouveau dev, tant ils ont été échaudés dans 20 précédents qu'on leur
avait juré mordicus qu'ils passeraient comme une lettre à la poste.
* Des architectes qui essaient de faire le pendant dans tout ça, en
essayant d'injecter un peu de nouveautés mais qu'ils savent abordables
par la majorité des acteurs, travail de longue haleine qui passe par
des POC sans fins et des .... sur la table.
Tout ça pour dire que je comprends le point de vue d'Emmanuel, la
France ne comporte pas 60 millions de Castcodeurs, loin de là, et
adopter une technologie, c'est souvent le parcours du combattant, et
on retient bien souvent les solutions en fonction de l'environnement
humain plus que technique ou fonctionnel.
Stephane Maldini
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Emmanuel Lecharny
> <snip/>
> Tout ça pour dire que je comprends le point de vue d'Emmanuel, la
> France ne comporte pas 60 millions de Castcodeurs, loin de là, et
> adopter une technologie, c'est souvent le parcours du combattant, et
> on retient bien souvent les solutions en fonction de l'environnement
> humain plus que technique ou fonctionnel.
Merci Henri de mettre un peu de baume sur mon quad-core ...
Monvécu, c'est que généralement, quand on fait appel à moi, on est déjà
dans la merde fumante avec une mise en prod dans quinze jours max (et
oui, la première mise en prod a foirée comme un pet liquide trois
semaines avant, et là, faut des Terminators pour rectifier le code...).
Bilan :
"Non, manu, *TU CASSES PAS TOUT*"
"Non, manu, *ON *PEUT* *PAS* TOUT REFAIRE"
"Non, manu, on peut pas *VIRER* le fou furieux qui a voulu mettre de
l'AspectJ dans le framework et ouvrir des sockets dans des entity beans,
il est déjà parti il y a 6 mois chez un autre client (d'ailleurs, il en
est aussi parti, et c'est ta prochaine mission, si tu l'acceptes)"
Je plaisante à peine...
Un jour, faudra faire une session "Jean-Pierre Coffe" au Jug, j'en ai
des belles à raconter sur ce que j'ai vu...
Stephane Maldini
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Moandji Ezana
Emmanuel Lecharny
note bien que mon rant ne te prenais pas pour cible.
Je pense qu'il s'agit plus d'un débat style "si jeunesse savait, si
vieillesse pouvait"...
Henri a, comme d'habitude, bien résumé ma pensée.
J'ai peur aussi de ne pas être un technophile, je hais les buzzwords, je
deteste toute nouvelle techno par principe, et 95% du temps, j'ai
raison, mais il faut attendre un ou deux ans pour avoir raison, et dans
les 5% des cas, et bien, je passe pour un sale réac.
Le plus marrant, c'est qu'il m'arrive aussi de m'enthousiasmer pour de
nouvelles technos. Quelques exemples :
- en 2001, j'ai découvert Spring framework et j'avais trouvé ça génial.
Par contre, ce que je trouvait génial n'était pas du tout lié à l'IOC
(que je trouve totalement sur-utilisé), mais plutôt ce qu'apportait
SpringMVC, qui était franchement 100 fois plus clean que Strutseuarg (et
meeeerde, j'ai encore vomis)
- Jess : un moteur de règle en java, qui était open source (et qui ne
l'est plus malheureusement). Par contre, pas à mettre entre toutes les
mains.
- REST. Si vous cherchez une techno dans laquelle investir, allez à fond
là dedans
- Eclipse. Parce qu'à l'époque, je venais de VisualAge, probablement une
des plus merdique IDE du monde et de l'univers.
- RAP : le pendant web de RCP. On peut ne pas aimer Eclipse, mais SWT
c'est quand même de la balle
- JMS : juste essentiel
- Log4J, JUnit, Ant
- NoSQL : parceque ça peut être plus utile que de se fader un énorme
base oracle dans certains cas
- Groovy : perce que c'est un meilleur langage que Jython, et que c'est
le premier langage dynamique vraiment bien foutu qui tourne sur une JVM
Ca fait pas beaucoup, mais c'est plus que suffisant pour bosser.
Dans ce que je déteste :
- Agile, Scrum, Craftmanship, XPair programming, enfin toutes les
méthodes de mes boules qui ne durent que le temps que fowler chie de
nouveaux slides pour ses présentations à 2500 $ les 4 heures. Tout ça,
c'est des conneries. Soit vous savez bosser en équipe, soit vous savez
pas. Et la meilleur façon de savoir, c'est d'avoir un bon chef de
projet, ou d'en devenir un vous même.
- AOP : de la branlette de manchots
- DSL : En fait, c'est l'acronyme de 'désolé'. Ca a été inventé il y a
environ 6000 ans, les DSL, et vous en avez la preuve dans un de mes
livres de contes pour enfant préféré (Genèse 11,1-9). c'est un bon moyen
pour que votre code soit inmaintenable.
- J2EE : il y a 60 millions d'années, on a eu la chance de voir
disparaitre les dinosaures. 2011 est là, on attend la second extinction
massive des dinausores de l'informatique. REST in peace, J2EE...
- SOAP : à ne pas faire tomber dans une douche collective, ça fait le
même effet qu'en prison. Le problème, c'est que vous avez même pas
besoin de le faire tomber pour en ressentir les effets.
- SOA : la vaseline qui permet de faire passer le SOAP.
- Design Pattern : Où un bouquin écrit par des mecs qui ont décrit des
principes de développement d'une UI est maintenant utilisé pour tout , y
compris l'épluchage de pommes de terre. Le GoF est brandi par des
personnes qui croient que La Bible nous dit que l'univers a été créée il
y a environ 9000 ans.
- Spring : le plus débile des framework. Ca me rappelle Lisp, mais Lisp
était un beau langage : Spring est sans doute implémenté en Spring.
Quand je vois du Spring sur un projet, j'impose que le code coverage
soit de 200% : 100% pour les code lui-même, et je punis les développeurs
en imposant de tester les tests eux-même, d'où les 100% suplémentaires.
Généralement, au bout de 15 jours de ce traitement, ils laissent tomber
Spring...
- RoR, Grails, Grouik, ROTFL, enfin, tous les frameworks qui sont
développés au dessus de languages qui ne sont pas fait pour.
- Play! Framework : parce qu'on me fera pas croire qu'il est possible en
2010 d'inventer le framework qui remplace tous les autres, comme si en
10 ans, les mecs qui avaient dévelopés des frameworks web était qu'une
bande de débiles consanguins (quoique...).
- Scala : parce que c'est un super langage, et qu'utilisé par n'importe
qui, ça va donner n'importe quoi (il y a certainement matière pour une
vidéo à Montpellier, là). Un peu comme si vous donniez une ferrari à
tous le monde.
J'en ai certainement oublié.
>> lescastcodeur...@googlegroups.com<lescastcodeurs%2Bunsu...@googlegroups.com>
>> .
>> Pour plus d'options, consultez la page de ce groupe :
>> http://groups.google.com/group/lescastcodeurs?hl=fr
>>
>>
>
--
Moandji Ezana
Emmanuel Lecharny
je suis trop fainéant :) Bon, faut que j'arrête, j'ai fini mon café...
Guillaume Laforge
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Stephane Maldini
- Scala : je ne comprends pas toujours le hype autour, c'est plutôt moche même si c'est aussi rapide que Java. Cela dit il y a de bons concepts, là ou c'est dommage c'est que Groovy et Scala convergent finalement vers le même objectif. Tantôt l'un ajoute du statiquesme (copyright) et l'autre du dynamisme. D'un côté en tournant sur la JVM tous les 2, on peut finalement les pratiquer sur des endroits différents, encapsuler des algorithmes répétés Scala dans de la beauté Groovy ?
- Play! Je ne comprends pas non plus le hype et je me sens stupide. Qu'est ce que ça apporte fonctionnellement parlant par rapport à Grails du coup ? (ou Lift ou je ne sais pas). Pourquoi diantre le touilleur est aussi fan ? A t'il des participations dans la boîte de Play ? Bref autant de questions sans réponses, mais vu ma douteuse objectivité il doit forcément il y en avoir une.
- Roo : l'excellence de la merdasse AOP.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Benoît Dissert
Julien Ponge
> l'écosystème actuel de Groovy est plus important
> que celui de Scala, donc si on a que des développeurs Groovy, taille-haut,
> faisons du Groovy, mais à part ça ?
Si je mets de cote la static vs dynamic, Groovy est plus "facile" a
apprendre que Scala aussi. Le langage en lui-meme est tres vite vu :
c'est Java avec des allegements et une syntaxe de closure.
Guillaume Laforge
Guillaume,Tu louvoies et tu ne réponds pas à la question.
C'est pas pour te provoquer ou pour recréer un débat qui serait déjà présent ailleurs (où d'ailleurs)
Evidemment Groovy est mieux que Java pour plein d'aspects, mais c'est à cause de la compatibilité et de l'historique.
Comparons avec un langage statique, que ne traîne pas de casserolse : Scala, qui bénéficie des mêmes avantagesque ceux dont tu parles.
La question est :"Dans quel cas d'utilisation est-il plus pertinent d'utiliser Groovy (ou un autre langage dynamique) que Scala ?"
Sans vouloir répondre à ta place, je vois un avantage pour Groovy : l'écosystème actuel de Groovy est plus importantque celui de Scala, donc si on a que des développeurs Groovy, taille-haut, faisons du Groovy, mais à part ça ?
Nicolas Delsaux
>
> Le super système de typage de Scala me fait peur, et j'aimerais pas avoir à
> maintenir des librairies qui l'utilisent. Prends par exemple n'importe
> quelle classe de Scalaz comme celle-ci :
> https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/FingerTree.scala
> Tu es noyé par le type system, et ton code devient vite illisible. Sans
> parler des supers opérateurs qui ressemblent à des smileys, à des flèches
> bizarres, etc.
Euh Guillaume ?
Fais gaffe, t'as marché dans un troll, t'en as plein les pompes.
Limite on va croire qu'Emmanuel L est dans ta tête (et ça, ça me
ferait peur).
--
Nicolas Delsaux
Moandji Ezana
Emmanuel Lecharny
> Le super système de typage de Scala me fait peur, et j'aimerais pas
> avoir à
> maintenir des librairies qui l'utilisent. Prends par exemple n'importe
> quelle classe de Scalaz comme celle-ci :
> https://github.com/scalaz/scalaz/blob/master/core/src/main/scala/scalaz/FingerTree.scala
*Finger*Tree, rien que le nom... Je crois pas qu'ils fassent référence à
Cadbury :)
Benoît Dissert
Nicolas Martignole
(nicolas = moi = blog le touilleur express)
> Play! Je ne comprends pas non plus le hype et je me sens stupide. Qu'est ce que ça apporte
> fonctionnellement parlant par rapport à Grails du coup ? (ou Lift ou je ne sais pas).
Play est un clone de Ruby on Rails et de différents frameworks webs qui ne viennent pas
du monde Java. C'est d'ailleurs un framework web à 100%.
Par rapport à Grails, tu perds GORM et le côté dynamique. Les tags sont moins puissants,
mais c'est aussi du Groovy pour la partie vue. Le code est compilé une fois pour toute, est-ce que
cela tourne plus vite que Grails ? Il faudrait faire le test sur une appli iso-fonctionnelle.
Play est un peu plus facile à apprendre que Grails, mais il y a pas
autant de module et la communauté est 10 fois plus petite. Donc c'est pas encore gagné
mais c'est un framework intéressant à connaître. Et surtout, surtout, c'est pas codé
par des gens biberonnés à la sauce J2EE comme nous les vieux. Y'a pas de Spring (mais tu peux
en mettre) c'est du JPA, le module Scala est bien pensé.
Ce qui me fait triper c'est le code et l'architecture qui est supra-simple et efficace.
> Pourquoi diantre le touilleur est aussi fan ? A t'il des participations dans la boîte de Play ?
> Bref autant de questions sans réponses, mais vu ma douteuse objectivité il doit forcément il y en avoir une.
et l'un des 10 développeurs de Play! Sinon on peut dire que j'aurai aussi des actions
de Lunatech, la boîte de Nicolas Leroux...
Y'a un an on pensait que j'étais payé par Spring Source pour écrire sur Grails ou par
eXo Platform pour pondre des articles sur les portails.
Ah et y'a deux ou trois ans, c'était Xebia... et avant c'était JBoss...
J'ai l'habitude (je suis vieux) et je comprends qu'on puisse s'interroger.
Pas de soucis
a+
Nicolas
Stephane Maldini
Benoît Dissert
> Play! Je ne comprends pas non plus le hype et je me sens stupide. Qu'est ce que ça apporte
> fonctionnellement parlant par rapport à Grails du coup ? (ou Lift ou je ne sais pas).
Nicolas Martignole
--
Loic Descotte
aussi un (petit) blog sur Java, et j'ai eu la même tentation de
n'écrire que sur Play quand j'ai découvert ce framework. Et c'est ce
que j'ai fait moi pendant un moment.
Ce que je trouve beau là dedans, comme Nicolas, c'est la simplicité du
code et la clarté de l'architecture. On s'encombre pas de soit disant
bonne pratiques dont tout le monde a oublié les fondements. Des qu'on
a un truc à développer on est surpris du peu de lignes et du peu de
temps que ça prend.
Que ce soit pour faire du Web ou simplement exposer des services REST
c'est actuellement le moyen le plus rapide ou efficace que je
connaisse.
Pour ceux que ça intéresse, mes modestes tuto sur play :
http://coffeebean.loicdescotte.com/search/label/Play%20fr
> > là ou c'est dommage c'est que Groovy et Scala convergent finalement vers le
> > même objectif. Tantôt l'un ajoute du statiquesme (copyright) et l'autre du
> > dynamisme. D'un côté en tournant sur la JVM tous les 2, on peut finalement
> > les pratiquer sur des endroits différents, encapsuler des algorithmes
> > répétés Scala dans de la beauté Groovy ?
> > coup ? (ou Lift ou je ne sais pas). Pourquoi diantre le touilleur est aussi
> > fan ? A t'il des participations dans la boîte de Play ? Bref autant de
> > questions sans réponses, mais vu ma douteuse objectivité il doit forcément
> > il y en avoir une.
> >>>>
> >>>> .
> >>>> Pour plus d'options, consultez la page de ce groupe :
> >>>> http://groups.google.com/group/lescastcodeurs?hl=fr
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >> --
> >> Regards,
> >> Cordialement,
> >> Emmanuel Lécharny
> >> www.iktek.com
> >>
> >> --
> >> Vous recevez ce message, car vous êtes abonné au groupe Google
> >> Groupes lescastcodeurs.
> >> Pour envoyer un message à ce groupe, adressez un e-mail à
> >> lescast...@googlegroups.com.
> >> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> >> lescastcodeur...@googlegroups.com<lescastcodeurs%2Bunsu...@googlegroups.com>
> >> .
> >> Pour plus d'options, consultez la page de ce groupe :
> >> http://groups.google.com/group/lescastcodeurs?hl=fr
> >>
> >>
> >
> >
> > --
> > www.doc4web.com
> > EMC partner - www.emc.com
> > --
> > http://fr.linkedin.com/in/smaldini
> >
> >
> > --
> > Vous recevez ce message, car vous êtes abonné au groupe Google
> > Groupes lescastcodeurs.
> > Pour envoyer un message à ce groupe, adressez un e-mail à
> > lescast...@googlegroups.com.
> > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
Stephane Maldini
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Loic Descotte
Stephane Maldini
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Grégory Bougeard
school en la sortant sur la table qu'on compare une fois pour toute?
plus chatieusement, Einstein disait "La théorie, c'est quand on sait
tout et que rien ne fonctionne. La pratique, c'est quand tout
fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni
théorie et pratique : Rien ne fonctionne... et personne ne sait
pourquoi !"
donc un peu de code serait peut-etre plus simple qu'un long
discours...
Guillaume Laforge
Genre tu fais du REST avec Grails, tu veux retourner un résultat sous
form de JSON dans ton action de ton contrôleur...
Et ben c'est très compliqué en Grails, t'as juste à faire :
myResuts as JSON
:-)
C'est ce genre d'exemple que tu veux ?
2011/2/4 Grégory Bougeard <gbou...@gmail.com>:
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
>
>
--
Grégory Bougeard
pas trop ton exemple vu que je trouve ça super simpliste (tes
résultats ils arrivent d'où? d'une BDD? appelée comment? en Grails?)
Là j'ai l'impression qu'il y a de la magie que je ne maitrise pas :D
je ne vais pas demander un exemple particulier (je ne pense pas etre
encore demandeur d'une nouvelle techno j'essaye pour le moment de
maitriser déjà la dernière que j'ai attaquée)
mais tu dois etre plus à même de pouvoir nous donner l'exemple typique
qui fait que ta religion est meilleure que celle des autres, non? :)
On 4 fév, 09:59, Guillaume Laforge <glafo...@gmail.com> wrote:
> Et tu veux quoi comme exemples concret précisément ?
>
> Genre tu fais du REST avec Grails, tu veux retourner un résultat sous
> form de JSON dans ton action de ton contrôleur...
> Et ben c'est très compliqué en Grails, t'as juste à faire :
>
> myResuts as JSON
>
> :-)
>
> C'est ce genre d'exemple que tu veux ?
>
>
>
>
>
>
>
>
>
> > dites, au lieu de toujours blablater, vous voulez pas la jouer old
> > school en la sortant sur la table qu'on compare une fois pour toute?
>
> > plus chatieusement, Einstein disait "La théorie, c'est quand on sait
> > tout et que rien ne fonctionne. La pratique, c'est quand tout
> > fonctionne et que personne ne sait pourquoi. Ici, nous avons réuni
> > théorie et pratique : Rien ne fonctionne... et personne ne sait
> > pourquoi !"
>
> > donc un peu de code serait peut-etre plus simple qu'un long
> > discours...
>
> > --
Guillaume Laforge
C'est comme d'essayer de prouver que dieu existe ! Ou pas :-O
2011/2/4 Grégory Bougeard <gbou...@gmail.com>:
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cédric CHAMPEAU
compare Java � Groovy. C'est l'exemple absolu pour moi. Pas facile �
copier/coller de tes prez, tu peux copier �a ?
Le 04/02/2011 10:06, Gr�gory Bougeard a �crit :
> alors je connais nib' en groovy, grails& autres donc ca ne me parle
> pas trop ton exemple vu que je trouve �a super simpliste (tes
> r�sultats ils arrivent d'o�? d'une BDD? appel�e comment? en Grails?)
> L� j'ai l'impression qu'il y a de la magie que je ne maitrise pas :D
>
> je ne vais pas demander un exemple particulier (je ne pense pas etre
> encore demandeur d'une nouvelle techno j'essaye pour le moment de
> maitriser d�j� la derni�re que j'ai attaqu�e)
> mais tu dois etre plus � m�me de pouvoir nous donner l'exemple typique
Emmanuel Lecharny
> dites, au lieu de toujours blablater, vous voulez pas la jouer old
> school en la sortant sur la table qu'on compare une fois pour toute?
Posez donc vos bits sur la table !
Guillaume Laforge
C'est quand je présente le projet Gaelyk.
Gaelyk, c'est un framework super léger au dessus du SDK de Google App
Engine, pour développer facilement et rapidement des applications en
Groovy, pour être déployées sur Google App Engine :
Jetez-y un coup d'oeil ;-)
En fait, ce que Cédric me suggère, c'est de vous montrer l'exemple
d'envoi de mail.
Quand on utilise Java, c'est généralement JavaMail qu'on utilise pour
envoyer des mails.
En plus, comme ça balance des checked exceptions, on est obligé de les
catcher, etc.
Et l'API est très verbeuse, au lieu de proposer des racourcis.
Du coup, en Java, pour envoyer un mail, à peu de choses près, on fait ça :
Properties props = new Properties();
Session session = Session.getDefaultInstance(props, null);
try {
Message msg = new MimeMessage(session);
msg.setFrom(new InternetAddress("ot...@gmail.com"));
msg.addRecipient(Message.RecipientType.TO,
new InternetAddress("t...@example.com"));
msg.setSubject("Hello World");
msg.setText("<bold>Hello</bold>");
Transport.send(msg);
} catch (AddressException e) {}
} catch (MessagingException e) {}
Avec Gaelyk, et sa fine surcouche au-dessus du SDK de App Engine, je
fais juste ça :
mail.send to: 't...@gmail.com', from: 'ot...@gmail.com', subject: 'Hello
World', htmlBody: '<bold>Hello</bold>'
Bon, sur plusieurs lignes, c'est plus joli comme ça :
mail.send to: 't...@gmail.com',
from: 'ot...@gmail.com',
subject: 'Hello World',
htmlBody: '<bold>Hello</bold>'
Voila.
Souvent, beaucoup de frameworks font compliqué même quand ils peuvent
faire simple.
Alors que des frameworks style Gaelyk, Grails, Play! essaient
justement de faire plus simple, plus lisible, plus concis, et donc au
final plus maintenable.
Guillaume
2011/2/4 Cédric CHAMPEAU <cedric....@gmail.com>:
> Guillaume, j'adore ton exemple de DSL pour envoyer des mails, qui compare
> Java à Groovy. C'est l'exemple absolu pour moi. Pas facile à copier/coller
> de tes prez, tu peux copier ça ?
>
> Le 04/02/2011 10:06, Grégory Bougeard a écrit :
>>
>> alors je connais nib' en groovy, grails& autres donc ca ne me parle
>> pas trop ton exemple vu que je trouve ça super simpliste (tes
>> résultats ils arrivent d'où? d'une BDD? appelée comment? en Grails?)
>> Là j'ai l'impression qu'il y a de la magie que je ne maitrise pas :D
>>
>> je ne vais pas demander un exemple particulier (je ne pense pas etre
>> encore demandeur d'une nouvelle techno j'essaye pour le moment de
>> maitriser déjà la dernière que j'ai attaquée)
>> mais tu dois etre plus à même de pouvoir nous donner l'exemple typique
>> qui fait que ta religion est meilleure que celle des autres, non? :)
>>
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail
> à lescast...@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> lescastcodeur...@googlegroups.com.
Moandji Ezana
En fait, ce que Cédric me suggère, c'est de vous montrer l'exemple d'envoi de mail.
Guillaume Laforge
> 2011/2/4 Guillaume Laforge <glaf...@gmail.com>
>>
>> En fait, ce que Cédric me suggère, c'est de vous montrer l'exemple d'envoi
>> de mail.
>
> Mais c'est juste un exemple d'API. En 10 minutes, j'ai créé une API
> similaire en Java: https://gist.github.com/810948 (il y a peut-être des
> erreurs parce que je n'ai pas testé et je connais mal JavaMail, mais c'est
> l'API qui compte).
Bien sûr, même en Java, tu peux faire plus simple que du pur JavaMail !
Mais pourquoi les gens qui développent des APIs font souvent plus
compliqué alors qu'ils peuvent faire plus simple ???
> A l'utilisation, ça donne (avec un import statique de
> MailBuilder.from) :
> from("mwa...@gmail.com")
> .to("lescast...@googlegroups.com", "glaf...@gmail.com")
> .subject("Hello, world")
> .body("Bonjour.")
> .send();
>
> Il est probable qu'avec Fantom ou Scala ce serait un peu plus joli.
Par exemple, avec ton "builder" (ta "fluent API"), avec Groovy 1.8, tu
peux la réutiliser directement, mais avec moins de ponctuation :
from "mwa...@gmail.com" to "lescast...@googlegroups.com",
"glaf...@gmail.com" subject "Hello, world" body "Bonjour." send()
Bon, ça fait une longue ligne, cela dit :-)
> Pour éviter les accusations de concours de longueur (quoique, là c'est la
> plus courte qui gagne :), je veux juste montrer qu'il ne faut pas confondre
> problèmes d'API et problèmes de langage.
Malheureusement, tout est lié.
Néanmoins les langages alternatifs permettent de faire plus simple et
plus lisible, bien souvent.
Du coup, les gens qui développent des frameworks avec ces langages là
sont plus soucieux de faire du code plus concis et lisible.
Un autre exemple pour la lisibilité, les DSLs, etc.
En Groovy, tu peux écrire un truc comme ça, par exemple :
take 3.pills of chloroquinine after 6.hours
Si je devais l'écrire en Java de la manière la plus lisible possible,
ça deviendrait sans doute quelque chose comme ça :
take( 3, pills ).of ( chloroquinine ).after ( 6, hours )
> Stephan Schmidt m'a fait me rendre
> compte de ça il y a plus de 2 ans
> : http://codemonkeyism.com/funny-some-rubyists-are-stupider-than-a-piece-of-wood/ (le
> titre du billet est plus virulent que son contenu...). Toutefois, je suis
> sûr que c'est 10 fois moins pénible de créer ce genre d'API avec un langage
> dynamique qu'en Java (et 3 fois moins qu'en Fantom/Scala) et qu'il y a
> quelques APIs impossibles à reproduire dans un langage statique.
> Grégory disait "donc un peu de code serait peut-etre plus simple qu'un
> long discours..." mais je pense que c'est assez difficile de trouver un
> exemple court qui reflète la réalité d'un projet de taille significative
> pour décrire les avantages d'un langage dynamique sur un langage statique
> moderne.
Je suis aussi d'accord que tous les exemples qu'on trouvera, et
bien... on trouvera quelque chose à redire :-)
Guillaume
> Moandji
Moandji Ezana
Malheureusement, tout est lié.
Néanmoins les langages alternatifs permettent de faire plus simple et
plus lisible, bien souvent.
Du coup, les gens qui développent des frameworks avec ces langages là
sont plus soucieux de faire du code plus concis et lisible.
Un autre exemple pour la lisibilité, les DSLs, etc.
En Groovy, tu peux écrire un truc comme ça, par exemple :
take 3.pills of chloroquinine after 6.hours
Guillaume Laforge
> [...]
> Je suis assez d'accord, mais est-ce que ce n'est pas aussi que beaucoup de
> ces API Java ont été créées il y a 10-15 ans et que maintenant on fait
> mieux? Etaient-elles bonnes pour l'époque? Aussi, beaucoup de ces API
> essaient d'être le plus bas niveau possible (cf. les souvent décriées APIs
> I/O). Ce qui est vraiment dommage, c'est qu'aucun effort n'ait été fait pour
> mettre une couche plus haut niveau par-dessus, et qu'il faille donc avoir
> recours à Commons-Lang, Commons-IO, etc.
Ici, c'est clair que c'est le problème aussi de l'exemple.
JavaMail, c'est effectivement une vieille API.
Mais quand je vois du code Java pondu encore aujourd'hui, on se
gargarise de layers et d'abstractions (au cas où on en ait besoin un
jour) au lieu de penser à la simplicité d'abord.
J'ai l'impression que dans la sphère Java, il faut vraiment se forcer
(ou forcer la main des gens), pour avoir ce principe de simplicité (et
YAGNI aussià dans la tête.
> [...]
>> En Groovy, tu peux écrire un truc comme ça, par exemple :
>>
>> take 3.pills of chloroquinine after 6.hours
>
> Je pense (sans vraiment savoir) qu'on pourrait reproduire la même syntaxe en
> Scala.
Je ne me souviens plus exactement des détails, mais en Scala, on peut
faire ce genre de choses aussi, mais il y a un peu plus de
contraintes, de mémoire pour l'écriture de ce genre de "phrases"
(style seulement avec un nombre impair de "mots", et je sais plus trop
quoi). Faudrait que je me replonge dans le bouquin de Scala que j'ai,
mais j'ai pas le courage :-)
Stephane Maldini
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--