> Le 9/7/12 10:01 AM, Frédéric Bouquet a écrit :
>>> PS : c'est juste ta phrase "tant que ça marche comme je fais, pas besoin d'aller se former a de nouvelles approches" qui
>>> m'a fait réagir car je la trouvais péjorative :)
>> C'était fait pour :)
>> Je suis assez souvent taquin :)
>> Le but de mon message était surtout de dire que j'aime beaucoup les
>> évolutions rapides des langages, j'aime beaucoup le changement, mais
>> que dans beaucoup de cas j'évite de les utiliser pour ne pas perdre
>> mes futurs lecteurs (allez, autre taquinerie : qui préfèrent le soir
>> regarder secret story à dévorer les specs sur les lambda :))
>> Après, l'ajout des lambda dans java, beaucoup les demandent depuis pas
>> mal de temps et j'aurais tendance à dire que ce n'est pas un mal
>> dangereux pour au moins les raisons suivantes :
>> - les formations d'ingé/d'université abordent les approches
>> fonctionnelles donc les concept devraient être compris par les jeunes
>> arrivants
> J'ai appris le lambda calcul en 1986 à la fac. Ca m'a pas fait pêter les boutons de braguettes à l'époque, mais, bon, du point de vue théorique, c'est très intéressant.
> Dans la pratique, après avoir passé une année à étudier LISP en long, large, travers, car et cdr, j'ai trouvé que le prof qui nous expliquait que le cerveau humain raisonnait nativement en récursif avait probablement une alimentation basée sur des champignons qui n'étais pas de Paris...
> Bref, tu peux aborder les concepts, ça ne les rends pas forcément intéressant à utiliser plein pot dans notre boulot de tous les jours.
>> - les langages avec sucre fonctionnel se répandent et l'approche est
>> en général accueillie avec plaisir par les devs (groovy, python, ...)
> Chacun son truc. Déjà, que les devs essayent de rédiger *correctement* des specs fonctionnelles, ce sera un premier pas…
t'es sur que c'est le taf du dev de rédiger des specs fonctionnelles ?
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
Le 7 sept. 2012 à 10:40, Emmanuel Lécharny <elecha...@gmail.com> a écrit :
> Le 9/7/12 10:38 AM, Patrice Trognon a écrit :
>> Chacun son truc. Déjà, que les devs essayent de rédiger *correctement* des specs fonctionnelles, ce sera un premier pas…
>> t'es sur que c'est le taf du dev de rédiger des specs fonctionnelles ?
> non, mais la collision entre programmation fonctionnelle et specs fonctionnelles m'a amusée ;)
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
>>> Chacun son truc. Déjà, que les devs essayent de rédiger *correctement* des specs fonctionnelles, ce sera un premier pas…
>>> t'es sur que c'est le taf du dev de rédiger des specs fonctionnelles ?
>> non, mais la collision entre programmation fonctionnelle et specs fonctionnelles m'a amusée ;)
> héhé :)
Ben si, c'est à ça que sert le test qu'on écrit avant le code !
Vendredi, quand tu nous tiens !
Pour moi, le gros soucis de Java, c'est pas le langage...et bon, comme
tu dis, les lambdas, ça rend le code illisible surtout, amha....
Le soucis de Java, c'est le déploiement...Je bosse de très près avec
des équipes de production,et franchement, à côté du déploiement d'une
application client lourd et/ou C, c'est un vrai fatra.....je pense que
les gens ont oublié que déployer, ça devrait être : Je prends l'UNIQUE
fichier de l'application, je le pose, et pot, ça marche.....Et ben en
fait, c'est jamais ça.....
On 6 sep, 21:40, Emmanuel Lécharny <elecha...@gmail.com> wrote:
> >>> Il y a deux sujets à ne pas agglomérer : JSE et JEE.
> >>> Au risque de passer pour un vieux con, je vois plutôt
> >>> d'un bon œil la stabilisation du langage et de la
> >>> plateforme de base. JSE est déjà très gros et cela n'aide
> >>> pas à l'utiliser pour des tout petits sujets. La
> >>> modularité aidera mais seulement si elle est gérée avec
> >>> des distributions par défaut permettant à chacun
> >>> d'utiliser JSE avec son profil d'utilisation. Après tout
> >>> qui se plaint de la faible évolution de la libc ? Qui se
> >>> plaint de la faible évolution sur C ou C++ ?
> >>> Pour le coup, les 2 dernières évolutions de C et C++, c'était
> >>> plutôt
> >>> un gros morceau par rapport à Java 7...non, franchement,
> >>> aujourd'hui,
> >>> Java est le langage qui évolue le plus lentement entre C++,
> >>> PHP, Java
> >>> et C#....
> >>> David
> >>> En fait, en regardant, Java est pas si pire :)
> >>> PHP accélère, il semble que facebook à plein d'idées (cf les
> >>> generateur) mais
> >>> ils continuent à ne pas vouloir traiter leur problème originel
> >>> (trop de string pas assez d'objet),
> >>> C# ralenti, la version de C# 5 annoncé en 2010 ne sera pas là
> >>> avant 2014 apparemment,
> >>> on a une petite 4.5 en attendant, avec async/await qui est juste
> >>> un yield++,
> >>> il semble que C# à perdu son mojo chez Microsoft.
> >>> Javascript est en pleine guerre entre les différents acteurs
> >>> impliqués et Harmony semble mort
> >>> (du moins pour l'instant),
> >>> C++ fait un grand pas tous les 5/7 ans, C tous les 10 ans et même
> >>> si la spec du C avance,
> >>> Microsoft ne veut pas supporter la nouvelle spec (gloups),
> >>> Python n'en fini pas de faire sa transition entre Python 2 et
> >>> Python 3,
> >>> Ruby à un cycle de release tout les 5 ans et semble s'y tenir.
> >>> Ok, Java avance lentement (et j'aimerais dire surement, mais je
> >>> suis pas sûre), on aura quand même des traits et des lambdas
> >>> l'année prochaine soit deux ans après la 1.7.
> >>> Mais combien d'année après les autres langages? et surtout après que
> >>> cela soit entré dans les meurs du commun du développeur ?
> >> Désolé mais j'ai toujours du mal à lire une lambda (malgrès les
> >> pléthores d'exemples et de comparaison avec d'autres langages), je
> >> n'en utilise pas et je ne saurais pas définir précisément ce qu'est
> >> un trait.
> > Historiquement, Java n'avait pas de lambda car tu t'en tire très bien
> > avec des inner-classes
> > si c'est que les inner-classes sont ultra-verbeuses et pas super
> > efficace.
> > Donc on peut voiren preière approche les lambdas en Java comme une
> > simplification des inner-classes.
> > Comparator<Person> c = new Comparator<Person>() {
> > public int compareTo(Person p1, Person p2) {
> > return p1.getName().compareTo(p2.getName());
> > }
> > };
> > est transformé en
> > Comparator<Person> c = (p1, p2) -> p1.getName().compareTo(p2.getName());
> > La dernière béta de IDEA te propose déjà se refactoring !
> Perso, les lambdas, je m'en passe. Même si les inners classes sont
> verbeuses, vu le degré d'utilisation que j'en fait...
> Je n'ai pas franchement envie de voir du code devenir un sac à lambdas,
> au lieu d'avoir de belles classes avec de belles methodes bien claires
> et documentées. Parce que à la fin, avec les lambdas, ça va se terminer
> comme ça.
> Si je veux faire du lambda calcul, je fais du Lisp, merde, quoi :)
> > Maintenant un trait est une interface qui fourni un plus un ensemble
> > de méthodes prédéfinies,
> > l'implantation de ces méthodes peut être écrit par rapport à une
> > méthode abstraite,
> > par exemple,
> Les traits, par contre, je suis beaucoup plus convaincu. Cela permet de
> simplifier vachement l'écriture de classes avec une hiérarchie complexe,
> sachant que l'héritage multiple est interdit en Java...
> A tout prendre, je garde les traits, et je jette les lambdas à la
> poubelle...
C'est sur qu'avec un client lourd C c'est plus simple. Il faut prendre rdv
avec l'admin sys pour qu'il récupere / compile puis installe les bon
packages, pour finalement se rendre compte qu'ils sont incompatibles avec
l'appli en cobol qui tourne à coté. :)
> Pour moi, le gros soucis de Java, c'est pas le langage...et bon, comme
> tu dis, les lambdas, ça rend le code illisible surtout, amha....
> Le soucis de Java, c'est le déploiement...Je bosse de très près avec
> des équipes de production,et franchement, à côté du déploiement d'une
> application client lourd et/ou C, c'est un vrai fatra.....je pense que
> les gens ont oublié que déployer, ça devrait être : Je prends l'UNIQUE
> fichier de l'application, je le pose, et pot, ça marche.....Et ben en
> fait, c'est jamais ça.....
> On 6 sep, 21:40, Emmanuel Lécharny <elecha...@gmail.com> wrote:
> > Le 9/6/12 4:30 PM, Remi Forax a écrit :
> > > On 09/06/2012 02:43 PM, Thibaud Vibes wrote:
> > >> Le 06/09/2012 13:23, Nicolas Labrot a écrit :
> > >>> Il y a deux sujets à ne pas agglomérer : JSE et JEE.
> > >>> Au risque de passer pour un vieux con, je vois plutôt
> > >>> d'un bon œil la stabilisation du langage et de la
> > >>> plateforme de base. JSE est déjà très gros et cela n'aide
> > >>> pas à l'utiliser pour des tout petits sujets. La
> > >>> modularité aidera mais seulement si elle est gérée avec
> > >>> des distributions par défaut permettant à chacun
> > >>> d'utiliser JSE avec son profil d'utilisation. Après tout
> > >>> qui se plaint de la faible évolution de la libc ? Qui se
> > >>> plaint de la faible évolution sur C ou C++ ?
> > >>> Pour le coup, les 2 dernières évolutions de C et C++, c'était
> > >>> plutôt
> > >>> un gros morceau par rapport à Java 7...non, franchement,
> > >>> aujourd'hui,
> > >>> Java est le langage qui évolue le plus lentement entre C++,
> > >>> PHP, Java
> > >>> et C#....
> > >>> David
> > >>> En fait, en regardant, Java est pas si pire :)
> > >>> PHP accélère, il semble que facebook à plein d'idées (cf les
> > >>> generateur) mais
> > >>> ils continuent à ne pas vouloir traiter leur problème originel
> > >>> (trop de string pas assez d'objet),
> > >>> C# ralenti, la version de C# 5 annoncé en 2010 ne sera pas là
> > >>> avant 2014 apparemment,
> > >>> on a une petite 4.5 en attendant, avec async/await qui est juste
> > >>> un yield++,
> > >>> il semble que C# à perdu son mojo chez Microsoft.
> > >>> Javascript est en pleine guerre entre les différents acteurs
> > >>> impliqués et Harmony semble mort
> > >>> (du moins pour l'instant),
> > >>> C++ fait un grand pas tous les 5/7 ans, C tous les 10 ans et même
> > >>> si la spec du C avance,
> > >>> Microsoft ne veut pas supporter la nouvelle spec (gloups),
> > >>> Python n'en fini pas de faire sa transition entre Python 2 et
> > >>> Python 3,
> > >>> Ruby à un cycle de release tout les 5 ans et semble s'y tenir.
> > >>> Ok, Java avance lentement (et j'aimerais dire surement, mais je
> > >>> suis pas sûre), on aura quand même des traits et des lambdas
> > >>> l'année prochaine soit deux ans après la 1.7.
> > >>> Mais combien d'année après les autres langages? et surtout après que
> > >>> cela soit entré dans les meurs du commun du développeur ?
> > >> Désolé mais j'ai toujours du mal à lire une lambda (malgrès les
> > >> pléthores d'exemples et de comparaison avec d'autres langages), je
> > >> n'en utilise pas et je ne saurais pas définir précisément ce qu'est
> > >> un trait.
> > > Historiquement, Java n'avait pas de lambda car tu t'en tire très bien
> > > avec des inner-classes
> > > si c'est que les inner-classes sont ultra-verbeuses et pas super
> > > efficace.
> > > Donc on peut voiren preière approche les lambdas en Java comme une
> > > simplification des inner-classes.
> > > Comparator<Person> c = new Comparator<Person>() {
> > > public int compareTo(Person p1, Person p2) {
> > > return p1.getName().compareTo(p2.getName());
> > > }
> > > };
> > > La dernière béta de IDEA te propose déjà se refactoring !
> > Perso, les lambdas, je m'en passe. Même si les inners classes sont
> > verbeuses, vu le degré d'utilisation que j'en fait...
> > Je n'ai pas franchement envie de voir du code devenir un sac à lambdas,
> > au lieu d'avoir de belles classes avec de belles methodes bien claires
> > et documentées. Parce que à la fin, avec les lambdas, ça va se terminer
> > comme ça.
> > Si je veux faire du lambda calcul, je fais du Lisp, merde, quoi :)
> > > Maintenant un trait est une interface qui fourni un plus un ensemble
> > > de méthodes prédéfinies,
> > > l'implantation de ces méthodes peut être écrit par rapport à une
> > > méthode abstraite,
> > > par exemple,
> > Les traits, par contre, je suis beaucoup plus convaincu. Cela permet de
> > simplifier vachement l'écriture de classes avec une hiérarchie complexe,
> > sachant que l'héritage multiple est interdit en Java...
> > A tout prendre, je garde les traits, et je jette les lambdas à la
> > poubelle...
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à
> lescastcodeurs@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> lescastcodeurs+unsubscribe@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/group/lescastcodeurs?hl=fr
+1000 (et comme je suis sur Lille, je connais bien le contexte
aussi :-)
Faut aussi savoir que l'informatique, c'est plus forcément une passion
pour tout le monde...c'est un métier qui rentre dans la normalité avec
son chômage, ses gens pas passionnés....ya des gens, informaticiens,
quand ils rentrent le soir chez eux, et bien ils vont jouer au foot et
faire leur jardin...yen a même qui partent en retraite....
On 7 sep, 09:10, Nicolas Delsaux <nicolas.dels...@gmail.com> wrote:
> > A un moment faut réaliser que le développeur moyen, à 95% en France, il est ingénieur !
> Je ne suis pas d'accord.
> Je sais que c'est le cas en région parisienne, à cause d'une forte
> pression de sélection naturelle (les recruteurs prennent d'abord les
> ingénieurs, et il n'y a plus de place pour les autres). Par contre, en
> province (au moins à lille, c'est beaucoup moins le cas : des DUT, des
> diplômes universitaires divers et variés (y compris de chimie), ....
> tout ça, je l'ai vu dans les grosses SSII qui n'hésitent pas à
> recruter n'importe quel gusse connaissant les ordinateurs mieux que ma
> mère.
> > S'il pane pas le parallélisme, la récursivité ou les algos de réduction, il a sérieusement rouillé le pauvre.
> Ben justement, ça n'est pas le cas de ces gens. Quant à
> l'autoformation et la veille technologique, faut pas rêver, ils
> comptent sur leur délégué du personnel pour leur obtenir des
> formations à la coule.
> > Pour moi il a clairement les capacité de comprendre, mais pas assez pratiqué. J'ai beaucoup de mal à croire à une limite de capacité !
> Et malheureusement, c'est pas seulement qu'il n'a pas pratiqué. Ca peut être
> - qu'il a bien assez réfléchi pour avoir son diplôme et considère que
> sa vie professionnelle ne consiste qu'en une simple exploitation
> amrchande dudit diplôme.
> - qu'il ne voit pas pourquoi il changerait de méthode. Après tout,
> Java 1.2 n'a que 12 ans, non ?
> - que de toute façon, les lambdas ne sont qu'une mode qui passera,
> comme les bases objet, comme la programmation COM, et comme tant
> d'autres choses ....
Le 7 septembre 2012 11:18, David Screve <david.scr...@gmail.com> a écrit :
> Faut aussi savoir que l'informatique, c'est plus forcément une passion
> pour tout le monde...c'est un métier qui rentre dans la normalité avec
> son chômage, ses gens pas passionnés....ya des gens, informaticiens,
> quand ils rentrent le soir chez eux, et bien ils vont jouer au foot et
> faire leur jardin...yen a même qui partent en retraite....
On est vendredi et on parle de prolétarisation de l'informatique c'est ça?
> +1000 (et comme je suis sur Lille, je connais bien le contexte
> aussi :-)
> Faut aussi savoir que l'informatique, c'est plus forcément une passion
> pour tout le monde...c'est un métier qui rentre dans la normalité avec
> son chômage, ses gens pas passionnés....ya des gens, informaticiens,
> quand ils rentrent le soir chez eux, et bien ils vont jouer au foot et
> faire leur jardin...yen a même qui partent en retraite....
Y en a même qui vont boire des bières (jte jure) !!
je suis d'accord, on est loin des débuts des années 70 ou l'informaticien était un espèce
de fou furieux (suis en train de lire le bouquin de Wozniac c'est savoureux !)
Pat
Le 7 sept. 2012 à 11:18, David Screve <david.scr...@gmail.com> a écrit :
> +1000 (et comme je suis sur Lille, je connais bien le contexte
> aussi :-)
> Faut aussi savoir que l'informatique, c'est plus forcément une passion
> pour tout le monde...c'est un métier qui rentre dans la normalité avec
> son chômage, ses gens pas passionnés....ya des gens, informaticiens,
> quand ils rentrent le soir chez eux, et bien ils vont jouer au foot et
> faire leur jardin...yen a même qui partent en retraite....
> On 7 sep, 09:10, Nicolas Delsaux <nicolas.dels...@gmail.com> wrote:
>> 2012/9/7 Dimitri <dba...@gmail.com>:
>>> A un moment faut réaliser que le développeur moyen, à 95% en France, il est ingénieur !
>> Je ne suis pas d'accord.
>> Je sais que c'est le cas en région parisienne, à cause d'une forte
>> pression de sélection naturelle (les recruteurs prennent d'abord les
>> ingénieurs, et il n'y a plus de place pour les autres). Par contre, en
>> province (au moins à lille, c'est beaucoup moins le cas : des DUT, des
>> diplômes universitaires divers et variés (y compris de chimie), ....
>> tout ça, je l'ai vu dans les grosses SSII qui n'hésitent pas à
>> recruter n'importe quel gusse connaissant les ordinateurs mieux que ma
>> mère.
>>> S'il pane pas le parallélisme, la récursivité ou les algos de réduction, il a sérieusement rouillé le pauvre.
>> Ben justement, ça n'est pas le cas de ces gens. Quant à
>> l'autoformation et la veille technologique, faut pas rêver, ils
>> comptent sur leur délégué du personnel pour leur obtenir des
>> formations à la coule.
>>> Pour moi il a clairement les capacité de comprendre, mais pas assez pratiqué. J'ai beaucoup de mal à croire à une limite de capacité !
>> Et malheureusement, c'est pas seulement qu'il n'a pas pratiqué. Ca peut être
>> - qu'il a bien assez réfléchi pour avoir son diplôme et considère que
>> sa vie professionnelle ne consiste qu'en une simple exploitation
>> amrchande dudit diplôme.
>> - qu'il ne voit pas pourquoi il changerait de méthode. Après tout,
>> Java 1.2 n'a que 12 ans, non ?
>> - que de toute façon, les lambdas ne sont qu'une mode qui passera,
>> comme les bases objet, comme la programmation COM, et comme tant
>> d'autres choses ....
>> --
>> Nicolas Delsaux
> -- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
> Pour moi, le gros soucis de Java, c'est pas le langage...et bon, comme
> tu dis, les lambdas, ça rend le code illisible surtout, amha....
> Le soucis de Java, c'est le déploiement...Je bosse de très près avec
> des équipes de production,et franchement, à côté du déploiement d'une
> application client lourd et/ou C, c'est un vrai fatra.....je pense que
> les gens ont oublié que déployer, ça devrait être : Je prends l'UNIQUE
> fichier de l'application, je le pose, et pot, ça marche.....Et ben en
> fait, c'est jamais ça.....
Ben .... quand t'as un ear, par exemple, tu fais ça, non ? Tu prend
ton EAR, tu le dépose dans ton serveur d'application, et pouf, ça
marche.
Et quand tu veux déployer un client lourd Swing,c 'est encore plus
simple : tu files l'URL du Java Web start, et ça s'installe (et se met
à jour) tout seul.
A contrario, une appli C, faut te taper l'installeur Windows, c'est chiant.
>> >>> Il y a deux sujets à ne pas agglomérer : JSE et JEE.
>> >>> Au risque de passer pour un vieux con, je vois plutôt
>> >>> d'un bon œil la stabilisation du langage et de la
>> >>> plateforme de base. JSE est déjà très gros et cela n'aide
>> >>> pas à l'utiliser pour des tout petits sujets. La
>> >>> modularité aidera mais seulement si elle est gérée avec
>> >>> des distributions par défaut permettant à chacun
>> >>> d'utiliser JSE avec son profil d'utilisation. Après tout
>> >>> qui se plaint de la faible évolution de la libc ? Qui se
>> >>> plaint de la faible évolution sur C ou C++ ?
>> >>> Pour le coup, les 2 dernières évolutions de C et C++, c'était
>> >>> plutôt
>> >>> un gros morceau par rapport à Java 7...non, franchement,
>> >>> aujourd'hui,
>> >>> Java est le langage qui évolue le plus lentement entre C++,
>> >>> PHP, Java
>> >>> et C#....
>> >>> David
>> >>> En fait, en regardant, Java est pas si pire :)
>> >>> PHP accélère, il semble que facebook à plein d'idées (cf les
>> >>> generateur) mais
>> >>> ils continuent à ne pas vouloir traiter leur problème originel
>> >>> (trop de string pas assez d'objet),
>> >>> C# ralenti, la version de C# 5 annoncé en 2010 ne sera pas là
>> >>> avant 2014 apparemment,
>> >>> on a une petite 4.5 en attendant, avec async/await qui est juste
>> >>> un yield++,
>> >>> il semble que C# à perdu son mojo chez Microsoft.
>> >>> Javascript est en pleine guerre entre les différents acteurs
>> >>> impliqués et Harmony semble mort
>> >>> (du moins pour l'instant),
>> >>> C++ fait un grand pas tous les 5/7 ans, C tous les 10 ans et même
>> >>> si la spec du C avance,
>> >>> Microsoft ne veut pas supporter la nouvelle spec (gloups),
>> >>> Python n'en fini pas de faire sa transition entre Python 2 et
>> >>> Python 3,
>> >>> Ruby à un cycle de release tout les 5 ans et semble s'y tenir.
>> >>> Ok, Java avance lentement (et j'aimerais dire surement, mais je
>> >>> suis pas sûre), on aura quand même des traits et des lambdas
>> >>> l'année prochaine soit deux ans après la 1.7.
>> >>> Mais combien d'année après les autres langages? et surtout après que
>> >>> cela soit entré dans les meurs du commun du développeur ?
>> >> Désolé mais j'ai toujours du mal à lire une lambda (malgrès les
>> >> pléthores d'exemples et de comparaison avec d'autres langages), je
>> >> n'en utilise pas et je ne saurais pas définir précisément ce qu'est
>> >> un trait.
>> > Historiquement, Java n'avait pas de lambda car tu t'en tire très bien
>> > avec des inner-classes
>> > si c'est que les inner-classes sont ultra-verbeuses et pas super
>> > efficace.
>> > Donc on peut voiren preière approche les lambdas en Java comme une
>> > simplification des inner-classes.
>> > Comparator<Person> c = new Comparator<Person>() {
>> > public int compareTo(Person p1, Person p2) {
>> > return p1.getName().compareTo(p2.getName());
>> > }
>> > };
>> > est transformé en
>> > Comparator<Person> c = (p1, p2) -> p1.getName().compareTo(p2.getName());
>> > La dernière béta de IDEA te propose déjà se refactoring !
>> Perso, les lambdas, je m'en passe. Même si les inners classes sont
>> verbeuses, vu le degré d'utilisation que j'en fait...
>> Je n'ai pas franchement envie de voir du code devenir un sac à lambdas,
>> au lieu d'avoir de belles classes avec de belles methodes bien claires
>> et documentées. Parce que à la fin, avec les lambdas, ça va se terminer
>> comme ça.
>> Si je veux faire du lambda calcul, je fais du Lisp, merde, quoi :)
>> > Maintenant un trait est une interface qui fourni un plus un ensemble
>> > de méthodes prédéfinies,
>> > l'implantation de ces méthodes peut être écrit par rapport à une
>> > méthode abstraite,
>> > par exemple,
>> Les traits, par contre, je suis beaucoup plus convaincu. Cela permet de
>> simplifier vachement l'écriture de classes avec une hiérarchie complexe,
>> sachant que l'héritage multiple est interdit en Java...
>> A tout prendre, je garde les traits, et je jette les lambdas à la
>> poubelle...
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
> 2012/9/7 David Screve <david.scr...@gmail.com>:
>> Pour moi, le gros soucis de Java, c'est pas le langage...et bon, comme
>> tu dis, les lambdas, ça rend le code illisible surtout, amha....
>> Le soucis de Java, c'est le déploiement...Je bosse de très près avec
>> des équipes de production,et franchement, à côté du déploiement d'une
>> application client lourd et/ou C, c'est un vrai fatra.....je pense que
>> les gens ont oublié que déployer, ça devrait être : Je prends l'UNIQUE
>> fichier de l'application, je le pose, et pot, ça marche.....Et ben en
>> fait, c'est jamais ça.....
> Ben .... quand t'as un ear, par exemple, tu fais ça, non ? Tu prend
> ton EAR, tu le dépose dans ton serveur d'application, et pouf, ça
> marche.
> Et quand tu veux déployer un client lourd Swing,c 'est encore plus
> simple : tu files l'URL du Java Web start, et ça s'installe (et se met
> à jour) tout seul.
> A contrario, une appli C, faut te taper l'installeur Windows, c'est chiant.
>> On 6 sep, 21:40, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>>> Le 9/6/12 4:30 PM, Remi Forax a écrit :
>>> > On 09/06/2012 02:43 PM, Thibaud Vibes wrote:
>>> >> Le 06/09/2012 13:23, Nicolas Labrot a écrit :
>>> >>> Il y a deux sujets à ne pas agglomérer : JSE et JEE.
>>> >>> Au risque de passer pour un vieux con, je vois plutôt
>>> >>> d'un bon œil la stabilisation du langage et de la
>>> >>> plateforme de base. JSE est déjà très gros et cela n'aide
>>> >>> pas à l'utiliser pour des tout petits sujets. La
>>> >>> modularité aidera mais seulement si elle est gérée avec
>>> >>> des distributions par défaut permettant à chacun
>>> >>> d'utiliser JSE avec son profil d'utilisation. Après tout
>>> >>> qui se plaint de la faible évolution de la libc ? Qui se
>>> >>> plaint de la faible évolution sur C ou C++ ?
>>> >>> Pour le coup, les 2 dernières évolutions de C et C++, c'était
>>> >>> plutôt
>>> >>> un gros morceau par rapport à Java 7...non, franchement,
>>> >>> aujourd'hui,
>>> >>> Java est le langage qui évolue le plus lentement entre C++,
>>> >>> PHP, Java
>>> >>> et C#....
>>> >>> David
>>> >>> En fait, en regardant, Java est pas si pire :)
>>> >>> PHP accélère, il semble que facebook à plein d'idées (cf les
>>> >>> generateur) mais
>>> >>> ils continuent à ne pas vouloir traiter leur problème originel
>>> >>> (trop de string pas assez d'objet),
>>> >>> C# ralenti, la version de C# 5 annoncé en 2010 ne sera pas là
>>> >>> avant 2014 apparemment,
>>> >>> on a une petite 4.5 en attendant, avec async/await qui est juste
>>> >>> un yield++,
>>> >>> il semble que C# à perdu son mojo chez Microsoft.
>>> >>> Javascript est en pleine guerre entre les différents acteurs
>>> >>> impliqués et Harmony semble mort
>>> >>> (du moins pour l'instant),
>>> >>> C++ fait un grand pas tous les 5/7 ans, C tous les 10 ans et même
>>> >>> si la spec du C avance,
>>> >>> Microsoft ne veut pas supporter la nouvelle spec (gloups),
>>> >>> Python n'en fini pas de faire sa transition entre Python 2 et
>>> >>> Python 3,
>>> >>> Ruby à un cycle de release tout les 5 ans et semble s'y tenir.
>>> >>> Ok, Java avance lentement (et j'aimerais dire surement, mais je
>>> >>> suis pas sûre), on aura quand même des traits et des lambdas
>>> >>> l'année prochaine soit deux ans après la 1.7.
>>> >>> Mais combien d'année après les autres langages? et surtout après que
>>> >>> cela soit entré dans les meurs du commun du développeur ?
>>> >> Désolé mais j'ai toujours du mal à lire une lambda (malgrès les
>>> >> pléthores d'exemples et de comparaison avec d'autres langages), je
>>> >> n'en utilise pas et je ne saurais pas définir précisément ce qu'est
>>> >> un trait.
>>> > Historiquement, Java n'avait pas de lambda car tu t'en tire très bien
>>> > avec des inner-classes
>>> > si c'est que les inner-classes sont ultra-verbeuses et pas super
>>> > efficace.
>>> > Donc on peut voiren preière approche les lambdas en Java comme une
>>> > simplification des inner-classes.
>>> > Comparator<Person> c = new Comparator<Person>() {
>>> > public int compareTo(Person p1, Person p2) {
>>> > return p1.getName().compareTo(p2.getName());
>>> > }
>>> > };
>>> > est transformé en
>>> > Comparator<Person> c = (p1, p2) -> p1.getName().compareTo(p2.getName());
>>> > La dernière béta de IDEA te propose déjà se refactoring !
>>> Perso, les lambdas, je m'en passe. Même si les inners classes sont
>>> verbeuses, vu le degré d'utilisation que j'en fait...
>>> Je n'ai pas franchement envie de voir du code devenir un sac à lambdas,
>>> au lieu d'avoir de belles classes avec de belles methodes bien claires
>>> et documentées. Parce que à la fin, avec les lambdas, ça va se terminer
>>> comme ça.
>>> Si je veux faire du lambda calcul, je fais du Lisp, merde, quoi :)
>>> > Maintenant un trait est une interface qui fourni un plus un ensemble
>>> > de méthodes prédéfinies,
>>> > l'implantation de ces méthodes peut être écrit par rapport à une
>>> > méthode abstraite,
>>> > par exemple,
>>> Les traits, par contre, je suis beaucoup plus convaincu. Cela permet de
>>> simplifier vachement l'écriture de classes avec une hiérarchie complexe,
>>> sachant que l'héritage multiple est interdit en Java...
>>> A tout prendre, je garde les traits, et je jette les lambdas à la
>>> poubelle...
>> --
>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
>> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
>> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
>> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
> --
> Nicolas Delsaux
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à lescastcodeurs@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.
> Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
> Pour moi, le gros soucis de Java, c'est pas le langage...et bon, comme
> tu dis, les lambdas, ça rend le code illisible surtout, amha....
> Le soucis de Java, c'est le déploiement...Je bosse de très près avec
> des équipes de production,et franchement, à côté du déploiement d'une
> application client lourd et/ou C, c'est un vrai fatra.....je pense que
> les gens ont oublié que déployer, ça devrait être : Je prends l'UNIQUE
> fichier de l'application, je le pose, et pot, ça marche.....Et ben en
> fait, c'est jamais ça.....
Désolé, Dvid, mais là je pense que tu es complètement à côté de la plaque.
Je ne vois absolument pas en quoi déployer une application Java serait plus difficile qu'en C. Je pense même exactement le contraire... Je n'ai pas le sentiment qu'il faille installer à l'arrache des libs en plus sur la machine cible pour que ton appli Java tourne, par exemple. Tout au plus installer la bonne JVM... Sans compter que ton appli en C compilée pour un bon vieux linux RedHat, tu vas te tripoter le prépuce un bon moment avant de la faire tourner sur un AIX ou un Windows...
Ou alors, tu as autre chose en tête ? Style, c'est la merde en barre de déployer une webapp sur du websphere. Mais ce n'est pas la même histoire, là.
> On 6 sep, 17:25, Henri Gomez <henri.go...@gmail.com> wrote:
>> Java sur iOS, il faudra qu'Apple change ses conditions.
> Rien ne t'emp che d'embarquer une application native avec une JVM
> dedans....On le fait pour Flash et a passe, pourquoi pas pour Java ?
>>>> Files.forEachLine(path).filter(s -> >>>> !s.startsWith("#")).map(Integer::parseInt).reduce(0, (a, b) -> a + b);
>>>> ou
>>>> int sum = 0;
>>>> try(BufferedReader reader = Files.newBufferedReader(path)) {
>>>> String s;
>>>> while ((s = reader.readLine()) {
>>>> if (s.startsWith("#")) {
>>>> continue;
>>>> }
>>>> int value = Integer.parseInt(s);
>>>> sum += value;
>>>> }
>>>> }
>>>> Je dis pas qu'il faudra pas un petit temps d'adaptation, (c'est >>>> quoi filter/map/reduce ?)
>>>> mais si tu compare les deux ya pas photo.
>>> Perso, je pr f re la seconde. Plus verbeuse, mais a pique mois les >>> yeux. Question de go t !
>> Moi aussi. J'ai rin' compris la 1 re.
> je pr f re
> path = "test.txt"
> sum = 0
> for s in open(path):
> if s.startswith("#"):
> continue
> sum += int(s)
> print (sum)
> C'est pas du java et apr s ?
tu veux dire
sum([int(s) for s in open(path) if !s.startswith("#")])
>>>>> Files.forEachLine(path).**filter(s -> !s.startsWith("#")).map(**Integer::parseInt).reduce(0,
>>>>> (a, b) -> a + b);
>>>>> ou
>>>>> int sum = 0;
>>>>> try(BufferedReader reader = Files.newBufferedReader(path)) {
>>>>> String s;
>>>>> while ((s = reader.readLine()) {
>>>>> if (s.startsWith("#")) {
>>>>> continue;
>>>>> }
>>>>> int value = Integer.parseInt(s);
>>>>> sum += value;
>>>>> }
>>>>> }
>>>>> Je dis pas qu'il faudra pas un petit temps d'adaptation, (c'est quoi
>>>>> filter/map/reduce ?)
>>>>> mais si tu compare les deux ya pas photo.
>>>> Perso, je préfère la seconde. Plus verbeuse, mais ça pique mois les
>>>> yeux. Question de goût !
>>> Moi aussi. J'ai rin' compris à la 1ère.
>> je préfère
>> path = "test.txt"
>> sum = 0
>> for s in open(path):
>> if s.startswith("#"):
>> continue
>> sum += int(s)
>> print (sum)
>> C'est pas du java et après ?
> tu veux dire
> sum([int(s) for s in open(path) if !s.startswith("#")])
> Rémi
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à
> lescastcodeurs@googlegroups.**com <lescastcodeurs@googlegroups.com>.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> lescastcodeurs+unsubscribe@**googlegroups.com<lescastcodeurs%2Bunsubscribe@ googlegroups.com>
> .
> Pour plus d'options, consultez la page de ce groupe :
> http://groups.google.com/**group/lescastcodeurs?hl=fr<http://groups.google.com/group/lescastcodeurs?hl=fr>
>>>>>> Files.forEachLine(path).**filter(s -> !s.startsWith("#")).map(**Integer::parseInt).reduce(0,
>>>>>> (a, b) -> a + b);
>>>>>> ou
>>>>>> int sum = 0;
>>>>>> try(BufferedReader reader = Files.newBufferedReader(path)) {
>>>>>> String s;
>>>>>> while ((s = reader.readLine()) {
>>>>>> if (s.startsWith("#")) {
>>>>>> continue;
>>>>>> }
>>>>>> int value = Integer.parseInt(s);
>>>>>> sum += value;
>>>>>> }
>>>>>> }
>>>>>> Je dis pas qu'il faudra pas un petit temps d'adaptation, (c'est quoi
>>>>>> filter/map/reduce ?)
>>>>>> mais si tu compare les deux ya pas photo.
>>>>> Perso, je préfère la seconde. Plus verbeuse, mais ça pique mois les
>>>>> yeux. Question de goût !
>>>> Moi aussi. J'ai rin' compris à la 1ère.
>>> je préfère
>>> path = "test.txt"
>>> sum = 0
>>> for s in open(path):
>>> if s.startswith("#"):
>>> continue
>>> sum += int(s)
>>> print (sum)
>>> C'est pas du java et après ?
>> tu veux dire
>> sum([int(s) for s in open(path) if !s.startswith("#")])
>> Rémi
>> --
>> Vous recevez ce message, car vous êtes abonné au groupe Google
>> Groupes lescastcodeurs.
>> Pour envoyer un message à ce groupe, adressez un e-mail à
>> lescastcodeurs@googlegroups.**com <lescastcodeurs@googlegroups.com>.
>> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
>> lescastcodeurs+unsubscribe@**googlegroups.com<lescastcodeurs%2Bunsubscribe@ googlegroups.com>
>> .
>> Pour plus d'options, consultez la page de ce groupe :
>> http://groups.google.com/**group/lescastcodeurs?hl=fr<http://groups.google.com/group/lescastcodeurs?hl=fr>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google
> Groupes lescastcodeurs.
> Pour envoyer un message à ce groupe, adressez un e-mail à
> lescastcodeurs@googlegroups.com.
> Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse
> lescastcodeurs+unsubscribe@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
SpringSource, a division of VMware
> je suis d'accord, on est loin des débuts des années 70 ou l'informaticien était un espèce
> de fou furieux (suis en train de lire le bouquin de Wozniac c'est savoureux !)
Le développeur moyen est peut être ingénieur (du moins on l'espère),
il n'empêche qu'il est très loin du monde idéal dans lequel beaucoup
pensent (espèrent) vivre.
J'ai passé suffisamment d'années en tant qu'Architecte a dépatouillé
des ingénieurs de développement moyens que je ne peux que constater
qu'il y a des technologies ou méthodos qui sont juste très complexes à
appréhender pour le plus grand nombre.
Ca peut paraitre incompréhensible pour ceux qui suivent les nouveautés
voir les créée, mais le développeur moyen a rarement le temps ou les
moyens d'être sur tous les fronts, UI, BackEnd, Fonctionnel et
langage.
Et c'est justement parce qu'il est ingénieur qu'il arrive à être
raisonnablement compétent dans des domaines aussi variés
qu'HTML/JS/CSS, SQL, Java (5-6) et son fonctionnel métier.
Tout ça pour dire que les évolutions dans Java (8), sont certes très
bien, mais peut être élitistes et certainement pas disponible en
environnement réel (sur des machines de production) avant 4-5 ans.
Ca laisse le temps donc à ceux qui produisent ses nouveautés de
produire toute la documentation nécessaire et suffisante pour que la
masse des développeurs puissent l'appréhender, la comprendre et la
maitriser.
> Ben .... quand t'as un ear, par exemple, tu fais ça, non ? Tu prend
> ton EAR, tu le dépose dans ton serveur d'application, et pouf, ça
> marche.
Ouep...ça c'est la théorie....Déjà, ton EAR, il reste pas longtemps un
EAR, parce qu'on serveur d'appli commence à le dezipper et le triturer
dans tous les sens...et là, les emmerdes commencent parce que le vrai
déploiement, il a lieu en runtime en fait et pas au moment où tu pose
le fichier.
> Et quand tu veux déployer un client lourd Swing,c 'est encore plus
> simple : tu files l'URL du Java Web start, et ça s'installe (et se met
> à jour) tout seul.
> A contrario, une appli C, faut te taper l'installeur Windows, c'est chiant.
Heu, l'installer Windows n'a jamais rien eu d'obligatoire...on peut
même très bien faire sans et ça marche du feu de dieu...Mais les
Windowsiens ont oublié qu'on pouvait juste poser des fichiers...
Ce qui est comique d'ailleurs sur Mac, c'est que Microsoft et toutes
les boites qui bossent sous Windows continuent à faire des installer
alors que c'est une pratique clairement déconseillée par Apple...
> Désolé, Dvid, mais là je pense que tu es complètement à côté de la plaque.
> Je ne vois absolument pas en quoi déployer une application Java serait
> plus difficile qu'en C. Je pense même exactement le contraire... Je n'ai
> pas le sentiment qu'il faille installer à l'arrache des libs en plus sur
> la machine cible pour que ton appli Java tourne, par exemple. Tout au
> plus installer la bonne JVM... Sans compter que ton appli en C compilée
> pour un bon vieux linux RedHat, tu vas te tripoter le prépuce un bon
> moment avant de la faire tourner sur un AIX ou un Windows...
> Ou alors, tu as autre chose en tête ? Style, c'est la merde en barre de
> déployer une webapp sur du websphere. Mais ce n'est pas la même
> histoire, là.
C'est un avis tout à fait personnel, mais je trouve que les équipes de
production galèrent pas mal quand elles doivent déployer des
applications Java...c'est toujours la galère, ya toujours un truc qui
manque, un machin qui merde, un fichier pas dans le bon répertoire,
pas dans la bonne version....et côté surveillance applicative, c'est
le désert total : Tu as une JVM qui tourne, un tomcat qui tourne, et
tu peux avoir ton application en carafe sans savoir pourquoi et avec
comme seule solution rapide de relancer tout le bouzin...Enfin, c'est
du vécu avec des équipes de production. Après, je suis d'accord avec
vous, en théorie, ça marche bien....
> On 7 sep, 12:50, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>> Le 9/7/12 11:13 AM, David Screve a écrit :
>> Désolé, Dvid, mais là je pense que tu es complètement à côté de la plaque.
>> Je ne vois absolument pas en quoi déployer une application Java serait
>> plus difficile qu'en C. Je pense même exactement le contraire... Je n'ai
>> pas le sentiment qu'il faille installer à l'arrache des libs en plus sur
>> la machine cible pour que ton appli Java tourne, par exemple. Tout au
>> plus installer la bonne JVM... Sans compter que ton appli en C compilée
>> pour un bon vieux linux RedHat, tu vas te tripoter le prépuce un bon
>> moment avant de la faire tourner sur un AIX ou un Windows...
>> Ou alors, tu as autre chose en tête ? Style, c'est la merde en barre de
>> déployer une webapp sur du websphere. Mais ce n'est pas la même
>> histoire, là.
> C'est un avis tout à fait personnel, mais je trouve que les équipes de
> production galèrent pas mal quand elles doivent déployer des
> applications Java...c'est toujours la galère, ya toujours un truc qui
> manque, un machin qui merde, un fichier pas dans le bon répertoire,
> pas dans la bonne version....et côté surveillance applicative, c'est
> le désert total : Tu as une JVM qui tourne, un tomcat qui tourne, et
> tu peux avoir ton application en carafe sans savoir pourquoi et avec
> comme seule solution rapide de relancer tout le bouzin...Enfin, c'est
> du vécu avec des équipes de production. Après, je suis d'accord avec
> vous, en théorie, ça marche bien....
Mais là, tu compares deux choses totalement différentes : une application C standalone, et une application web ou J2EE qui tourne dans un serveur d'application, qui par essence est potentiellement distribuée.
Et oui, déployer une appli web/J2EE, ce n'est pas simple mais il n'y a pas l'équivalent en C. Tout est une question de compréhension de ce qu'il faut déployer, et cela nécessite des compétences certaines du serveur d'app dans lequel tu la fait tourner.
Déployer une simple application Java, c'est incomparablement plus simple, et en tout cas aussi simple qu'une appli en C, sauf que en plus, elle est nativement multi plate-forme.
Oui, tu as raison...en fait, ce que je voulais exprimer, c'est qu'en
général, le déploiement et la gestion production des applications j2ee
reste quelquechose de très laborieux....
Je me suis mal exprimé. Désolé.
David
On 7 sep, 20:07, Emmanuel Lécharny <elecha...@gmail.com> wrote:
> > On 7 sep, 12:50, Emmanuel Lécharny <elecha...@gmail.com> wrote:
> >> Le 9/7/12 11:13 AM, David Screve a écrit :
> >> Désolé, Dvid, mais là je pense que tu es complètement à côté de la plaque.
> >> Je ne vois absolument pas en quoi déployer une application Java serait
> >> plus difficile qu'en C. Je pense même exactement le contraire... Je n'ai
> >> pas le sentiment qu'il faille installer à l'arrache des libs en plus sur
> >> la machine cible pour que ton appli Java tourne, par exemple. Tout au
> >> plus installer la bonne JVM... Sans compter que ton appli en C compilée
> >> pour un bon vieux linux RedHat, tu vas te tripoter le prépuce un bon
> >> moment avant de la faire tourner sur un AIX ou un Windows...
> >> Ou alors, tu as autre chose en tête ? Style, c'est la merde en barre de
> >> déployer une webapp sur du websphere. Mais ce n'est pas la même
> >> histoire, là.
> > C'est un avis tout à fait personnel, mais je trouve que les équipes de
> > production galèrent pas mal quand elles doivent déployer des
> > applications Java...c'est toujours la galère, ya toujours un truc qui
> > manque, un machin qui merde, un fichier pas dans le bon répertoire,
> > pas dans la bonne version....et côté surveillance applicative, c'est
> > le désert total : Tu as une JVM qui tourne, un tomcat qui tourne, et
> > tu peux avoir ton application en carafe sans savoir pourquoi et avec
> > comme seule solution rapide de relancer tout le bouzin...Enfin, c'est
> > du vécu avec des équipes de production. Après, je suis d'accord avec
> > vous, en théorie, ça marche bien....
> Mais là, tu compares deux choses totalement différentes : une
> application C standalone, et une application web ou J2EE qui tourne dans
> un serveur d'application, qui par essence est potentiellement distribuée.
> Et oui, déployer une appli web/J2EE, ce n'est pas simple mais il n'y a
> pas l'équivalent en C. Tout est une question de compréhension de ce
> qu'il faut déployer, et cela nécessite des compétences certaines du
> serveur d'app dans lequel tu la fait tourner.
> Déployer une simple application Java, c'est incomparablement plus
> simple, et en tout cas aussi simple qu'une appli en C, sauf que en plus,
> elle est nativement multi plate-forme.
