Avenir de Java

[Nicolas Labrot]

Bonjour à tous,

Je me tâtais depuis un moment à créer ce fil.

• Les features reportés sur Java 8
• Java 8 qui sera lancé été 2013 avec des features que possèdent bcp de ses concurrents
  
• JSF 2.2 reporté à la fin de l'année 2012
• Les fonctionnalités Cloud JEE reportées, à cause d'un progrès trop lent de la spécification
• La montée en puissance des SoC ARM, l'absence de Java sur iOS, Android, Win RT (?).
  
• J'en manque surement pleins d'autres
  

Je ne trouve pas que le Java made in Oracle soit très dynamique et montre une réelle volonté d'Oracle de le pousser. Cela m'inquiète même.

Vous en pensez quoi ? ;)

a+

Nicolas

[Philippe Charrière]

moi je suis preneur :)

2012/9/5 Nicolas Labrot <nit...@gmail.com>

Nicolas

--
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

--
http://about.me/ph.charriere

[Patrice Trognon]

+1, tu viens même de publier une feuille de route pour un prochain épisode :)

Pat

[Emmanuel Feller]

Bonjour,

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++ ? 

Après il y a JEE... C'est un autre problème et un autre monde. Le retard de JSF ne me gêne pas, ce que j'aimerai voir c'est une prise de recul sur les specs et des modèles alternatifs qui soient proposés en full stack (comme Play ou consors) avec un beau guide utilisateur qui dirait voilà comment on fait et qui remettrait les architectes à leur vraie place. Ce qui me gêne c'est cet accumulation de spécification qui au final est bâti sur servlet dans une vision d'invocation de méthode (doget, dopost).

JEE devrait se réinventer et proposer une solution innovante en marge de l'ensemble de specs actuelle. Le premier ensemble à trouvé son public, il est temps pour les nouveaux problèmes d'envisager d'autres solutions et de ne pas chercher à patcher les specs actuelles pour leur faire faire papa maman.

Je ne crois pas une seconde que les applications actuelles (jdk5 en prod) seront transformées pour prendre ces nouveautés : ce sera d'autres applications, donc pourquoi pas une autre solution.

My2cts,

Emmanuel

Le 5 sept. 2012 à 11:16, Nicolas Labrot <nit...@gmail.com> a écrit :

[Nicolas Labrot]

2012/9/5 Emmanuel Feller <emmanue...@gmail.com>

Bonjour,

Il y a deux sujets à ne pas agglomérer : JSE et JEE.

Mon propos est global à l’écosystème Java Oracle, il inclut donc aussi bien JSE que 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++ ? 

Ceux l'ayant abandonné au profit des autres langages ? ;)

 

[Patrice Trognon]

Le 5 sept. 2012 à 14:03, Nicolas Labrot <nit...@gmail.com> a écrit :

 

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++ ? 

Ceux l'ayant abandonné au profit des autres langages ? ;)

heu tu me provoques la ?

:)

[David Screve]

On 5 sep, 13:01, Emmanuel Feller <emmanuel.fel...@gmail.com> wrote:
> Bonjour,
>
> 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

[Remi Forax]

On 09/05/2012 11:38 PM, David Screve wrote:
>
> On 5 sep, 13:01, Emmanuel Feller <emmanuel.fel...@gmail.com> wrote:
>> Bonjour,
>>

>> 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.

R�mi

[Xavier Combelle]

Le 06/09/2012 01:27, Remi Forax a �crit :

> Python n'en fini pas de faire sa transition entre Python 2 et Python 3,

Python a fini sa transition entre Python 2 et Python 3 il y a quelques
librairies (je pense entre autre � twisted et � PIL) qui n'ont pas suivi
mais globalement python avance

[Nicolas Labrot]

2012/9/6 Remi Forax <fo...@univ-mlv.fr>

On 09/05/2012 11:38 PM, David Screve wrote:

On 5 sep, 13:01, Emmanuel Feller <emmanuel.fel...@gmail.com> wrote:

Bonjour,

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 ?

[Emmanuel Lécharny]

Le 9/5/12 11:16 AM, Nicolas Labrot a écrit :
> Bonjour à tous,

Bonjour !

>
> Je me tâtais depuis un moment à créer ce fil.

Normalement, c'est un fil qui est lancé en début d'année, comme lchaque
année depuis 1996 : "Is Java dead" ?...
>
> - Les features reportés sur Java 8
Vu que Java 7 n'est toujours pas en prod massivement, et de loin, je ne
pense pas que l'on ai un besoin urgent de ces features...
> - Java 8 qui sera lancé été 2013 avec des features que possèdent bcp de
> ses concurrents
La question c'est plutôt : qui utilise les concurrents de Java, et quel
est leur niveau de stabilité et d'utisabilité...
> - JSF 2.2 reporté à la fin de l'année 2012
Là, pour le coup, "is JSF dead" devrait recevoir une réponse positive...
> - Les fonctionnalités Cloud JEE reportées, à cause d'un progrès trop
> lent de la spécification

So what ? Who cares about J2EE cloud ?

> - La montée en puissance des SoC ARM, l'absence de Java sur iOS,
> Android, Win RT (?).
Je ne suis pas sûr que ce soit problématique, actuellement...

>
>
> Je ne trouve pas que le Java made in Oracle soit très dynamique et montre
> une réelle volonté d'Oracle de le pousser. Cela m'inquiète même.

Il y a de quoi être inquiet concernant Oracle, c'est sûr. Pour Java, je
pense que c'est une autre histoire. Dans les 5-10 ans à venir, je ne
vois pas Java disparaître. Un peu comme C, en fait...


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[Julien Gaucher]

java sur arm, il me semble quand même que oracle bosse dessus
https://blogs.oracle.com/henrik/entry/oracle_releases_jdk_for_linux


2012/9/6 Emmanuel Lécharny <elec...@gmail.com>:

[Thibaud Vibes]

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.

Comment peut-on dire "comme ça" que ces fonctionnalités sont entrées dans le commun des développeurs?
<sarcasme>
Vous faites passer des entretien d'embauches et demandez ce qu'est un trait où une closure, vous? Tous vos candidats vous répondent et vous pondent un exemple sur tableau blanc? (dites le moi car je compte bien recruter un nouveau dev à court terme donc faudrait pas que je prenne un has-been)
</sarcasme>

Je suppose que le commun des développeurs, lui il attend qu'on lui facilite le développement. Dans ce sens j'aime bien Java7 parce qu'il apporte plein de petites réponses sympa à des trucs qui sont pénibles "au quotidien" :
- Project Coin (opérateur diamant, multi-catch, try-with-resources, les "underscores" dans les nombres même on peut les mettre n'importe comment. Ex: 1_0_0_0_; 0_0 ...)
- la nouvelle API pour la gestion des fichiers

Dans les trucs encore pénibles, la gestion des dates. Donc la jsr310, dans ma liste de noël de développeur commun.

Je parle pas de Fork/Join. L'API a l'air sympa mais j'aurais pas souvent l'occasion de l'employer.

C'est peut-être de la broutille, ça aurait pu être intégré y a 3ans... Mais est-ce que chaque version de Java doit intégrer un nouveau concept de programmation?
Au moins avec Java, c'est que ça ne part pas dans tous les sens. Il reste donc une plateforme "rassurante" et sera donc bien plébiscité pour cela.
Je pense qu'il n'y a pas qu'un type de développeur, il y en a des milliers. Java ne contentera jamais tout le monde.

(bon je fini sur une banalité mais j'aurais pu la mettre au début)

[Julien Ponge]

Oui, tu peux meme lancer un Glassfish :-)

http://julien.ponge.info/notes/javaee6-and-glassfish-on-a-beagleboard/

2012/9/6 Julien Gaucher <julie...@gmail.com>:

[Ronan Michaux]

> ...non, franchement, aujourd'hui, Java est le langage qui évolue le plus lentement entre C++, PHP, Java et C#....

+1, si Java était devenu assez moderne/expressif, il n'y aurait pas eu l'émergence de Clojure, Groovy, Scala, Kotlin, Ceylon, Xtend, etc.

<Troll>Il y a 15 ans, j'aurai jamais imaginé que je dirai ça un jour : "Java est vraiment balourd." ;o)</Troll>

[Baptiste MATHUS]

Le 6 septembre 2012 14:50, Ronan Michaux <ronan_...@yahoo.com> a écrit :

> ...non, franchement, aujourd'hui, Java est le langage qui évolue le plus lentement entre C++, PHP, Java et C#....

+1, si Java était devenu assez moderne/expressif, il n'y aurait pas eu l'émergence de Clojure, Groovy, Scala, Kotlin, Ceylon, Xtend, etc.

Soyons réalistes : tu peux faire évoluer le langage (ouvert) que tu veux, autant que tu veux, tu auras toujours ce type de projets autour.

D'après toi, Java aurait pu évoluer pour convenir à 100% des gens ?

Peut-être que, justement, le nombre important de projets autour montre simplement la vivacité de Java et de son écosystème.

 

<Troll>Il y a 15 ans, j'aurai jamais imaginé que je dirai ça un jour : "Java est vraiment balourd." ;o)</Troll>

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Patrice Trognon]

on peut aussi raisonner en terme de type d'application.

En ce qui concerne le SI, c'est a dire web et JEE, oui java est majoritaire.

En ce qui concerne les applications UI, si ils n'avaient pas merdoyé comme ils l'ont fait entre Swing et ce qui 

a suivi on en parlerait peut être plus, aujourd'hui les dev UI se font toujours majoritairement en natif.

En ce qui concerne l'embarqué la aussi toujours pas photo, le C (et ses dérivés) domine.

En ce qui concerne le dev de jeux idem, majoritairement du C, un peu de C++, et les rares qui font du java ils font l'IA en java et ensuite tous les appels au graphisme, son, gestion des io (clavier, souris, track, gamepad, etc) ce sont des appels a des libs C par JNI.

Donc Java majoritaire dans le petit monde du SI, je suis d'accord.

dans les autres je demande a voir :)

L'avenir de java je le poserai autrement, l'avenir du concept de VM qui n'a pas tenu a mes yeux ses promesses sinon on le retrouverai dans l'embarqué. ( je parle du vrai embarqué venez pas me les briser avec les smartphones :) )

Pat

[Gabriel Landais]

Le 6 septembre 2012 15:10, Patrice Trognon <ptro...@gmail.com> a écrit :

Donc Java majoritaire dans le petit monde du SI, je suis d'accord.

dans les autres je demande a voir :)

Un petit oubli : Android

[Patrice Trognon]

oui enfin, dire que java est majoritaire sur android c'est comme dire que obj-c est majoritaire sur iOS hein,

t'as pas le choix.

Sur ce, t'écris pas tout a fait du java pour android que pour ton pc, que moi le code que j'écris pour iOS

ou pour OS X est strictement le meme, je n'ai aucune gymnastique limite schizophrénique a faire pour

me mettre dans l'un ou l'autre contexte.

(c'était juste au passage, on s'égare).

Pat

[Nicolas Labrot]

2012/9/6 Emmanuel Lécharny <elec...@gmail.com>

Le 9/5/12 11:16 AM, Nicolas Labrot a écrit :

Bonjour à tous,

Bonjour !

Je me tâtais depuis un moment à créer ce fil.

Normalement, c'est un fil qui est lancé en début d'année, comme lchaque année depuis 1996 : "Is Java dead" ?...

    - Les features reportés sur Java 8

Vu que Java 7 n'est toujours pas en prod massivement, et de loin, je ne pense pas que l'on ai un besoin urgent de ces features...

    - Java 8 qui sera lancé été 2013 avec des features que possèdent bcp de
    ses concurrents

La question c'est plutôt : qui utilise les concurrents de Java, et quel est leur niveau de stabilité et d'utisabilité...

a priori pas toi ;). Je pense que la question de stabilité ou d'utilisabilité de groovy (entre autre) n'est pas/plus à démontrer

 

    - JSF 2.2 reporté à la fin de l'année 2012

Là, pour le coup, "is JSF dead" devrait recevoir une réponse positive...

JSF n'est pas mort, au contraire même

 

    - Les fonctionnalités Cloud JEE reportées, à cause d'un progrès trop
    lent de la spécification

So what ? Who cares about J2EE cloud ?

C'est un des points parmi d'autres pour montrer la relative lenteur et les retards des évolutions de Java.

 

    - La montée en puissance des SoC ARM, l'absence de Java sur iOS,
    Android, Win RT (?).

Je ne suis pas sûr que ce soit problématique, actuellement...

Je ne trouve pas que le Java made in Oracle soit très dynamique et montre
une réelle volonté d'Oracle de le pousser. Cela m'inquiète même.

Il y a de quoi être inquiet concernant Oracle, c'est sûr. Pour Java, je pense que c'est une autre histoire. Dans les 5-10 ans à venir, je ne vois pas Java disparaître. Un peu comme C, en fait...

D'un point de vu légal / propriété, peut on comparer la situation du C (qui est un standard iso) et de Java ?  Je n'en suis pas sur. Si Oracle décide que Java n'évoluera plus quel recourt peut avoir la communauté?
 

[Remi Forax]

On 09/06/2012 02:43 PM, Thibaud Vibes wrote:
>
> Le 06/09/2012 13:23, Nicolas Labrot a �crit :
>>
>>
>> 2012/9/6 Remi Forax <fo...@univ-mlv.fr <mailto:fo...@univ-mlv.fr>>

>>
>> On 09/05/2012 11:38 PM, David Screve wrote:
>>
>>
>> On 5 sep, 13:01, Emmanuel Feller <emmanuel.fel...@gmail.com

>> <mailto:emmanuel.fel...@gmail.com>> wrote:
>>
>> Bonjour,
>>

>> 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 !


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,

interface Ordering<T, U extends Comparable<U>> extends Comparator<T> {
public abstract U transform(T t);
public default int compareTo(T t1, T t2) {
return transform(t1).compareTo(transform(t2));
}
}

L�, on dit que si on sait transform� un T en un truc comparable avec
lui-m�me (U),
alors on sait comparer des T, et dans ce cas tu peux �crire

Ordering<Person, String> ordering = p -> p.getName());
Comparator<Person> c = ordering;

et en utilisant une r�f�rence de m�thode et tout sur une ligne

Comparator<Person> c = (Ordering<Person, String>) p::getName;

qui est un comparateur de Person par rapport � leur nom.

bon, pas s�re que cela soit un super exemple pour d�buter,
mais �a ouvre des perspectives en terme d'�criture d'API.

R�mi

>
> Comment peut-on dire "comme �a" que ces fonctionnalit�s sont entr�es
> dans le commun des d�veloppeurs?

> <sarcasme>
> Vous faites passer des entretien d'embauches et demandez ce qu'est un

> trait o� une closure, vous? Tous vos candidats vous r�pondent et vous

> pondent un exemple sur tableau blanc? (dites le moi car je compte bien

> recruter un nouveau dev � court terme donc faudrait pas que je prenne
> un has-been)
> </sarcasme>
>
> Je suppose que le commun des d�veloppeurs, lui il attend qu'on lui
> facilite le d�veloppement. Dans ce sens j'aime bien Java7 parce qu'il
> apporte plein de petites r�ponses sympa � des trucs qui sont p�nibles
> "au quotidien" :
> - Project Coin (op�rateur diamant, multi-catch, try-with-resources,
> les "underscores" dans les nombres m�me on peut les mettre n'importe

> comment. Ex: 1_0_0_0_; 0_0 ...)
> - la nouvelle API pour la gestion des fichiers
>

> Dans les trucs encore p�nibles, la gestion des dates. Donc la jsr310,
> dans ma liste de no�l de d�veloppeur commun.

>
> Je parle pas de Fork/Join. L'API a l'air sympa mais j'aurais pas
> souvent l'occasion de l'employer.
>

> C'est peut-�tre de la broutille, �a aurait pu �tre int�gr� y a 3ans...
> Mais est-ce que chaque version de Java doit int�grer un nouveau
> concept de programmation?
> Au moins avec Java, c'est que �a ne part pas dans tous les sens. Il
> reste donc une plateforme "rassurante" et sera donc bien pl�biscit�
> pour cela.
> Je pense qu'il n'y a pas qu'un type de d�veloppeur, il y en a des

> milliers. Java ne contentera jamais tout le monde.
>

> (bon je fini sur une banalit� mais j'aurais pu la mettre au d�but)
>
> --
> 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

[Nicolas Labrot]

2012/9/6 Baptiste MATHUS <bma...@batmat.net>

Le 6 septembre 2012 14:50, Ronan Michaux <ronan_...@yahoo.com> a écrit :

> ...non, franchement, aujourd'hui, Java est le langage qui évolue le plus lentement entre C++, PHP, Java et C#....

+1, si Java était devenu assez moderne/expressif, il n'y aurait pas eu l'émergence de Clojure, Groovy, Scala, Kotlin, Ceylon, Xtend, etc.

Soyons réalistes : tu peux faire évoluer le langage (ouvert) que tu veux, autant que tu veux, tu auras toujours ce type de projets autour.

D'après toi, Java aurait pu évoluer pour convenir à 100% des gens ?

Peut-être que, justement, le nombre important de projets autour montre simplement la vivacité de Java et de son écosystème.

Le nombre de projets est je pense révélateur que Java ne suffit plus et qu'une demande non négligeable existe.


 

 

<Troll>Il y a 15 ans, j'aurai jamais imaginé que je dirai ça un jour : "Java est vraiment balourd." ;o)</Troll>

--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

[Remi Forax]

On 09/06/2012 11:43 AM, Xavier Combelle wrote:
> Le 06/09/2012 01:27, Remi Forax a �crit :

>> Python n'en fini pas de faire sa transition entre Python 2 et Python 3,
> Python a fini sa transition entre Python 2 et Python 3 il y a quelques

> librairies (je pense entre autre � twisted et � PIL) qui n'ont pas

> suivi mais globalement python avance
>

oui,
mais il reste pas mal de boulot, Django par exemple.

cf https://python3wos.appspot.com/

R�mi

[Remi Forax]

On 09/06/2012 04:34 PM, Nicolas Labrot wrote:
>
>
> 2012/9/6 Baptiste MATHUS <bma...@batmat.net <mailto:bma...@batmat.net>>

>
>
> Le 6 septembre 2012 14:50, Ronan Michaux <ronan_...@yahoo.com

> <mailto:ronan_...@yahoo.com>> a �crit :
>
> > ...non, franchement, aujourd'hui, Java est le langage qui �volue le

> plus lentement entre C++, PHP, Java et C#....
>

> +1, si Java �tait devenu assez moderne/expressif, il n'y
> aurait pas eu l'�mergence de Clojure, Groovy, Scala, Kotlin,
> Ceylon, Xtend, etc.
>
>
> Soyons r�alistes : tu peux faire �voluer le langage (ouvert) que

> tu veux, autant que tu veux, tu auras toujours ce type de projets
> autour.

> D'apr�s toi, Java aurait pu �voluer pour convenir � 100% des gens ?
>
> Peut-�tre que, justement, le nombre important de projets autour
> montre simplement la vivacit� de Java et de son �cosyst�me.
>
>
>
> Le nombre de projets est je pense r�v�lateur que Java ne suffit plus
> et qu'une demande non n�gligeable existe.

non, il y avait plein de projet de langage fin 90, Cecil, Kea, Dylan
pour citer des un peu connu
mais c'�tait plus dure que maintenant de d�velopper un langage, surtout
si tu target la JVM ou LLVM,
tu n'as plus que le runtime � �crire.

Un bonne indicateur est de regarder le nombre de personnes qui bosse �
plein temps sur ces langages,
les �quipes de dev sont petites, ce qui n'enl�ve rien au cot� h�roique
de la chose soit dit en passant.

R�mi

[Baptiste MATHUS]

Le 6 septembre 2012 16:34, Nicolas Labrot <nit...@gmail.com> a écrit :

2012/9/6 Baptiste MATHUS <bma...@batmat.net>

Le 6 septembre 2012 14:50, Ronan Michaux <ronan_...@yahoo.com> a écrit :

> ...non, franchement, aujourd'hui, Java est le langage qui évolue le plus lentement entre C++, PHP, Java et C#....

+1, si Java était devenu assez moderne/expressif, il n'y aurait pas eu l'émergence de Clojure, Groovy, Scala, Kotlin, Ceylon, Xtend, etc.

Soyons réalistes : tu peux faire évoluer le langage (ouvert) que tu veux, autant que tu veux, tu auras toujours ce type de projets autour.

D'après toi, Java aurait pu évoluer pour convenir à 100% des gens ?

Peut-être que, justement, le nombre important de projets autour montre simplement la vivacité de Java et de son écosystème.

Le nombre de projets est je pense révélateur que Java ne suffit plus et qu'une demande non négligeable existe.

Pas sûr. Peut-être est-ce simplement lié à la qualité de la JVM elle même ?

Beaucoup de langages se créent donc non pas forcément autour de Java, le langage, mais autour de la plateforme Java qu'est la JVM.

J'ai par exemple entendu dire que JRuby était plus rapide que la VM standard Ruby. Facebook regarderait du côté de la JVM pour faire tourner son PHP...

[Thibaud Vibes]

Merci d'avoir pris le temps d'expliquer.

Le 06/09/2012 16:30, Remi Forax a écrit :
> On 09/06/2012 02:43 PM, Thibaud Vibes wrote:
>>

>> 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 !
Ne dis t-on pas "classe anonymes" plutôt que inner-classes?
(oui oui j'ose bien reprendre M. Forax, j'ai pas froid aux yeux :-))

>
>
> 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,
>
> interface Ordering<T, U extends Comparable<U>> extends Comparator<T> {
> public abstract U transform(T t);
> public default int compareTo(T t1, T t2) {
> return transform(t1).compareTo(transform(t2));
> }
> }
>

> Là, on dit que si on sait transformé un T en un truc comparable avec
> lui-même (U),
> alors on sait comparer des T, et dans ce cas tu peux écrire

>
> Ordering<Person, String> ordering = p -> p.getName());
> Comparator<Person> c = ordering;
>

> et en utilisant une référence de méthode et tout sur une ligne

>
> Comparator<Person> c = (Ordering<Person, String>) p::getName;
>

> qui est un comparateur de Person par rapport à leur nom.
>
> bon, pas sûre que cela soit un super exemple pour débuter,
> mais ça ouvre des perspectives en terme d'écriture d'API.

ça va être la fête des "generics" on dirait avec les "traits".

>
> Rémi

[Nicolas Delsaux]

2012/9/6 Thibaud Vibes <tvi...@onyme.com>:

> Merci d'avoir pris le temps d'expliquer.
>

> Ne dis t-on pas "classe anonymes" plutôt que inner-classes?
> (oui oui j'ose bien reprendre M. Forax, j'ai pas froid aux yeux :-))
>

Ben en fait, les classes anonymes sont un cas particulier d'inner
classes (puisqu'elles n'ont pas de nom, mais se retrouvent après la
compilation avec des noms en ClasseParente$1).
Et pour rebondir un peu, ce qui est malheureux avec les classes
anonymes/inner, c'est que peu de gens ont compris à quel point elles
étaient proches du closure parce que (avant guava) elles n'étaient
essentiellement utilisées que dans le code Swing pour faire des
EventListener et autres Renderers.
A mon avis, si on attend encore un peu, et que Guava devient
utilisable par le plus grand monde, on se rendra compte que les
closures sauce Java n'en sont qu'une réimplémentation plus propre.
D'ailleurs, au niveau compilé, ça va se passer comment ces closures ?
Avec les mêmes magouilles que les classes internes/anonymes ?

>
>
> ça va être la fête des "generics" on dirait avec les "traits".
>

C'est pas déja le cas ?
Ca ressemble vachement à ce truc Ruby, là ... les mixins

--
Nicolas Delsaux

[Henri Gomez]

Java sur iOS, il faudra qu'Apple change ses conditions.

Java sur ARM, Oracle s'en occupe (Redhat le faisait déjà) et il y a un
marché double.
Les portables tout de suite et les serveurs massivement multi-coeurs
dans quelques temps :)

[Remi Forax]

On 09/06/2012 05:20 PM, Nicolas Delsaux wrote:
> 2012/9/6 Thibaud Vibes <tvi...@onyme.com>:
>> Merci d'avoir pris le temps d'expliquer.
>>

>> Ne dis t-on pas "classe anonymes" plut�t que inner-classes?

>> (oui oui j'ose bien reprendre M. Forax, j'ai pas froid aux yeux :-))
>>
> Ben en fait, les classes anonymes sont un cas particulier d'inner

> classes (puisqu'elles n'ont pas de nom, mais se retrouvent apr�s la

> compilation avec des noms en ClasseParente$1).

oui, classe anonyme est un meilleur terme ici, r��lement,
ce sont les classes anonymes implantant des interfaces poss�dant une
seul m�thode abstraite.

> Et pour rebondir un peu, ce qui est malheureux avec les classes

> anonymes/inner, c'est que peu de gens ont compris � quel point elles
> �taient proches du closure parce que (avant guava) elles n'�taient
> essentiellement utilis�es que dans le code Swing pour faire des
> EventListener et autres Renderers.

Il y a d�j� un certain nombre d'interfaces qui joue le r�le de 'function
interface' dans le JDK,
genre java.util.Comparator, java.io.FileFilter,
javax.sql.rowset.Predicate, mais c'est vrai
que guava � ouvert les yeux de pas mal de devs.

> A mon avis, si on attend encore un peu, et que Guava devient
> utilisable par le plus grand monde, on se rendra compte que les

> closures sauce Java n'en sont qu'une r�impl�mentation plus propre.
> D'ailleurs, au niveau compil�, �a va se passer comment ces closures ?
> Avec les m�mes magouilles que les classes internes/anonymes ?

oui et non, l'implantation actuelle g�n�re des inner-classes � runtime
pour �viter de bouffer du disque pour rien (et �viter la verfi du
bytecode aussi)
et r�utilise le m�me objet si la lambda ne capture pas de valeur du scope.

Apr�s, on jouera avec des method handles pour rendre les trucs plus efficace
mais cela demande d'expliquer un certain nombre de choses au JIT, donc
c'est pas pour tout de suite.

>>
>> �a va �tre la f�te des "generics" on dirait avec les "traits".
>>
> C'est pas d�ja le cas ?
> Ca ressemble vachement � ce truc Ruby, l� ... les mixins
>

R�mi

[Benoit Perroud]

ça va être la fête avec les "traits".

>>
>> 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 à
> 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
>

--
sent from my Nokia 3210

[Guillaume Laforge]

Il paraît que c'est "trait" drôle à utiliser :-)

2012/9/6 Benoit Perroud <ben...@noisette.ch>

--
Guillaume Laforge
Groovy Project Manager
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/

Social: @glaforge / Google+

[Emmanuel Lécharny]

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 :
>>>
>>>
>>> 2012/9/6 Remi Forax <fo...@univ-mlv.fr <mailto:fo...@univ-mlv.fr>>
>>>
>>> On 09/05/2012 11:38 PM, David Screve wrote:
>>>
>>>
>>> On 5 sep, 13:01, Emmanuel Feller <emmanuel.fel...@gmail.com
>>> <mailto:emmanuel.fel...@gmail.com>> wrote:
>>>
>>> Bonjour,
>>>

>>> 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...

[Emmanuel Lécharny]

Le 9/6/12 4:26 PM, Nicolas Labrot a écrit :
> 2012/9/6 Emmanuel Lécharny <elec...@gmail.com>

>
>
>> La question c'est plutôt : qui utilise les concurrents de Java, et quel
>> est leur niveau de stabilité et d'utisabilité...
>>
> a priori pas toi ;). Je pense que la question de stabilité ou
> d'utilisabilité de groovy (entre autre) n'est pas/plus à démontrer

Groovy n'est pas pour moi un concurrent à Java : c'est un langage
complémentaire. Je cautionne l'utilisation de Groovy.

>> - JSF 2.2 reporté à la fin de l'année 2012
>> Là, pour le coup, "is JSF dead" devrait recevoir une réponse positive...
>>
> JSF n'est pas mort, au contraire même

Merde. J'envoie des tueurs tout de suite !

>> - Les fonctionnalités Cloud JEE reportées, à cause d'un progrès trop
>>> lent de la spécification
>>>
>> So what ? Who cares about J2EE cloud ?
>>
> C'est un des points parmi d'autres pour montrer la relative lenteur et les
> retards des évolutions de Java.

Non. Ca démontre simplement qu'accoler un Buzzword à un système qui
meurt sous son propre poid n'en fait pas une danseuse. Cela n'a rien à
voir avec Java...

>
>>> Je ne trouve pas que le Java made in Oracle soit très dynamique et montre
>>> une réelle volonté d'Oracle de le pousser. Cela m'inquiète même.
>>>
>> Il y a de quoi être inquiet concernant Oracle, c'est sûr. Pour Java, je
>> pense que c'est une autre histoire. Dans les 5-10 ans à venir, je ne vois
>> pas Java disparaître. Un peu comme C, en fait...
>>
> D'un point de vu légal / propriété, peut on comparer la situation du C (qui
> est un standard iso) et de Java ?

Non, et c'est un vrai problème.

> Je n'en suis pas sur. Si Oracle décide
> que Java n'évoluera plus quel recourt peut avoir la communauté?

Aucun. Cf Apache Harmony...

[Remi Forax]

On 09/06/2012 09:40 PM, Emmanuel L�charny wrote:

>> Donc on peut voir en premi�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...

C'est une question d'oeuf et de poule, inner class trop verbeux donc
j'utilise pas, donc pas besoin d'avoir une syntaxe moins verbeuse
puisque je ne les utilise pas.

>
> 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.

Non, tu auras toujours de belles classes avec des belles m�thodes, ou au
moins de belles interfaces bien document�es
mais le code � l'int�rieur de certaines m�thodes va �tre simplifi�e.
tu pr�f�res,

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.

>
> Si je veux faire du lambda calcul, je fais du Lisp, merde, quoi :)

c'est vrai qu'il manque les macros, mais c'est pr�vu pour Java 9 ou 10
(je rigole qu'� moiti�)

>>
>>
>> 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...

Je suis compl�tement d'accord, les traits sont plus important que les
lambdas, mais faut pas trop le dire (ou l'�crire zut)
car j'aimerais bien �viter les r�-actions hepidermiques du genre, Oracle
� pourri les interfaces de Java.

En fait comme tu ne peux pas d�clarer de vrai champs dans les
interfaces, c'est mieux que l'h�ritage multiple car tu ne contraints pas
la fa�on dont les valeurs sont stock�es dans les classes qui implantent
les interfaces.

Sur la liste, je sais plus qui parlait des mixins de Ruby, ici, l'id�e
des traits est de raisonner � l'envers des mixins de Ruby.
En Ruby, tu � une implantation que tu peux r�utiliser sans que cela se
voit en terme de hi�rarchie d'h�ritage,
comme l'h�ritage priv�e de C++ d'ailleurs. c'est pas la bonne solution,
car l'implantation, le fait de savoir si on stocke un truc sur deux ou
trois champs, est presque jamais un truc int�ressant � r�utiliser, pas
contre, r�utiliser des comportements, �a c'est int�ressant.

>
> A tout prendre, je garde les traits, et je jette les lambdas � la
> poubelle...
>

Tu as m�me pas � choisir, tu peux avoir les deux (mais pas avec jigsaw).

R�mi

[Henri Gomez]

> Non, tu auras toujours de belles classes avec des belles méthodes, ou au
> moins de belles interfaces bien documentées
> mais le code à l'intérieur de certaines méthodes va être simplifiée.
> tu préfères,

>
> 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.

Ce qui m'inquiète, tout comme Manu, c'est que ce genre de code est
très élégant mais pas directement compréhensible par le développeur
Java moyen.

On m'a appris il y a longtemps que ce qui faisait la différence en
programmation c'était la lisibilité et la facilité avec laquelle tout
un chacun peut intervenir sur du code qu'on a écrit.

Hors dans une équipe et à plus forte raison une entreprise, normale,
les développeurs ne sont pas tous des stars, loin de là.
Et des constructions trop complexes ou mal comprises peuvent faire
plus de mal que de bien en maintenance ;-(

[Remi Forax]

On 09/07/2012 12:09 AM, Henri Gomez wrote:
>> Non, tu auras toujours de belles classes avec des belles m�thodes, ou au
>> moins de belles interfaces bien document�es
>> mais le code � l'int�rieur de certaines m�thodes va �tre simplifi�e.
>> tu pr�f�res,

>>
>> 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.

> Ce qui m'inqui�te, tout comme Manu, c'est que ce genre de code est
> tr�s �l�gant mais pas directement compr�hensible par le d�veloppeur
> Java moyen.

C'est un argument � la TF1 pour justifier secret story et autres merdes.
Le dev moyen, comme la m�nag�re de moins de 50 ans, �a existe pas, enfin
pas en vrai.
Tu as d�j� rencontr� un mec qui te dis, bonjour je suis d�velopeur
moyen, nan,
tous le monde �volue, un d�velopeur moyen c'est juste une fa�on de figer
les choses
en regardant le pass� alors qu'entre temps, toute la team c'est mis � guava
et r�le parce que �a serait plus cool d'avoir une syntaxe plus adapt�
que les inners classes.
M�me GoldmanSachs � une biblioth�que � base de lambdas qui s'ignore (et
sur github en plus).

Pour la petite histoire, je me souvient d'une discussion vers 97 d'un
mec qui candidatait
pour un poste d'enseignant de C++ et qui a gentillement expliqu� que la
programmation objet
c'�tait trop compliqu� pour le developeur moyen, heureusement, avec
Visual C++,
on pouvait �crire du code C en faisant semblant que c'est du C++.

> On m'a appris il y a longtemps que ce qui faisait la diff�rence en
> programmation c'�tait la lisibilit� et la facilit� avec laquelle tout
> un chacun peut intervenir sur du code qu'on a �crit.

Oui, mais en m�me temps les pratiques �voluent, car les besoins �voluent.
Exemple extr�me, on voit des designers se mettre � javascript puis � NodeJS,
et l� c'est farci de callbacks, de triggers partout, bref de lambdas.

> Hors dans une �quipe et � plus forte raison une entreprise, normale,
> les d�veloppeurs ne sont pas tous des stars, loin de l�.

Oui, mais en m�me temps, pas besoin d'�tre une star pour comprendre les
lambdas,
compar� aux inner-classes, au mod�le de m�moire/� la concurrence, � la
reflection,
les lambdas c'est plus simple car une fois que tu as pig� la '->' et le
'::', le reste c'est que
de l'API, donc si tu comprends pas tu fais comme tout le monde, tu
invokes le dieu javadoc.

> Et des constructions trop complexes ou mal comprises peuvent faire
> plus de mal que de bien en maintenance ;-(
>

On a plac� quelques garde fous pour �viter que cela d�rive trop, et le
g�nie de Brian Goetz
(rendons � c�sar ce qui appartient � c�sar) est d'avoir compris qu'une
lambda devait juste
�tre une fa�on de cr�er un objet qui implante une interface et donc que
contrairement � Scala,
Java n'avait pas besoin d'avoir un type repr�sentant des fonctions.

Cela fait ressembler les lambdas � des classes anonymes plus simple,
donc logiquement
pour les g�n�rations futures de dev Java, il y a de bonne chance qu'ils
apprennent ce qu'est
un lambda avant de savoir ce qu'est une classe anonyme
(je vais tester �a cette ann�e avec mes Master 1, on va voir).

Maintenant, oui le langage �volue, oui, c'est un nouveau concept, ou
tout du moins un concept
qui n'avait pas �t� expliqu� comme tel avant, et oui la syntaxe est
bizarre m�me si on a repomp�
en partie celle de C# expr�s pour essayer de pas trop troubler de monde
et en ce disant que si
Java avait eut des lambdas dans la version 1.0, C# l'aurait repomp� :)

Enfin bref, j'esp�re que les lambdas seront autant utiliser que l'est le
for(:)* plut�t que
ne l'est invokedynamic :)

R�mi
* et tu peux toujours dire que le for-each ne marche pas avec des Iterator,
dans ce cas je te montrerais comment r�soudre le probl�me avec des
lambdas :)

[Emmanuel Lécharny]

Le 9/6/12 11:47 PM, Remi Forax a écrit :
> On 09/06/2012 09:40 PM, Emmanuel Lécharny wrote:
>
>>> Donc on peut voir en premiè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...

>
> C'est une question d'oeuf et de poule, inner class trop verbeux donc
> j'utilise pas, donc pas besoin d'avoir une syntaxe moins verbeuse
> puisque je ne les utilise pas.
>
>>

>> 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.
>

> Non, tu auras toujours de belles classes avec des belles méthodes, ou
> au moins de belles interfaces bien documentées
> mais le code à l'intérieur de certaines méthodes va être simplifiée.
> tu préfères,
>

> 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 !

>
>
>>>
>>>
>>> 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...
>
> Je suis complètement d'accord, les traits sont plus important que les
> lambdas, mais faut pas trop le dire (ou l'écrire zut)
> car j'aimerais bien éviter les ré-actions hepidermiques du genre,
> Oracle à pourri les interfaces de Java.
>
> En fait comme tu ne peux pas déclarer de vrai champs dans les
> interfaces, c'est mieux que l'héritage multiple car tu ne contraints
> pas la façon dont les valeurs sont stockées dans les classes qui
> implantent les interfaces.
>
> Sur la liste, je sais plus qui parlait des mixins de Ruby, ici, l'idée
> des traits est de raisonner à l'envers des mixins de Ruby.
> En Ruby, tu à une implantation que tu peux réutiliser sans que cela se
> voit en terme de hiérarchie d'héritage,
Ce que l'on peut déjà faire en Java avec une bonne vieille méthode static...

> comme l'héritage privée de C++ d'ailleurs. c'est pas la bonne

> solution, car l'implantation, le fait de savoir si on stocke un truc

> sur deux ou trois champs, est presque jamais un truc intéressant à
> réutiliser, pas contre, réutiliser des comportements, ça c'est
> intéressant.

Oui. Parfois, tu voudrais avoir des classes implémentant deux interfaces
distinctes, mais partageant une interface commune, style :

InterfaceA o--- AbstractClassA

InterfaceB
InterfaceC

Class1 extends AbstractClassA implements InterfaceB
Class2 extends AbstractClassA implements InterfaceC
Class3 extends AbstractClassA implements , InterfaceB, InterfaceC

Avec des méthodes définies dans InterfaceB et d'autres dans InterfaceC,
mais que tu es obligé d'implémenter dans Class1, 2 et 3 puisque tu n'as
pas la possibilité de les implémenter dans AbstractClassA.

Les traits permettent de résoudre ce problème.

>
>>
>> A tout prendre, je garde les traits, et je jette les lambdas à la
>> poubelle...
>>
>
> Tu as même pas à choisir, tu peux avoir les deux (mais pas avec jigsaw).

Ce que je voulais dire, dans le cadre de la question initiale : "is Java
dead" et de l'interrogation sur le fait que Java n'évolue pas assez
vite, c'est que parfois l'évolution d'un langage ne lui est pas
forcément bénéfique... (style, de mon point de vue, l'ajout des lambdas
ne me paraissait pas une nécessité absolue, par contre j'eusse aimé que
Java 8 voit disparaître cette dualité type de base/Object qui fait chier
tout le monde, à savoir qu'on ne peut *toujours* pas créer de
HashMap<int>... Qu'en 1995 ils aient décidé qu'il fallait conserver des
types de base pour des raison de performance, pourquoi pas (quoique je
considère que c'est une absurdité : c'est d'abord et avant tout un
problème de compilation de savoir s'il faut transformer un object Int en
type de base en interne, mais bon...) mais qu'on se traîne cette
absurdité en 2012, et que l'auto-boxing n'ait pas résolu ce cas là,
j'avoue, j'ai du mal à comprendre...)

J'aime bien

[Emmanuel Lécharny]

Le 9/7/12 2:04 AM, Remi Forax a écrit :

> On 09/07/2012 12:09 AM, Henri Gomez wrote:

>>> Non, tu auras toujours de belles classes avec des belles méthodes,
>>> ou au

>>> moins de belles interfaces bien documentées
>>> mais le code à l'intérieur de certaines méthodes va être simplifiée.
>>> tu préfères,
>>>

>>> 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.

>> Ce qui m'inquiète, tout comme Manu, c'est que ce genre de code est
>> très élégant mais pas directement compréhensible par le développeur

>> Java moyen.
>
> C'est un argument à la TF1 pour justifier secret story et autres merdes.

Je pense que c'est exactement l'inverse.

TF1 fait de la merde pour "créer du temps de cerveau disponible", ie tu
sors d'un tunnel de merde prêt à absorber un message "intelligent", la pub.

Dans ce qu'explique Henri, et je partage son point de vue, l'idée c'est
de rester dans un cadre où celui qui va maintenir le code que tu écris
en Arte style (mais le Arte de 1992, hein parce que Arte aujourd'hui,
c'est largement regardable par les masses...) puisse "comprendre" ce que
tu as fait sans se faire des noeuds au cerveau.

Pour sortir des analogies foireuses, il est possible de sortir des chefs
d'oeuvre compréhensible par le commun des mortels sans utiliser
profusions de tournures de style que le vulgus pecum ne saisie pas, et
ce d'autant plus facilement que ces tournures de style n'existent pas :)
Bon, on peut *aussi* faire de la merde :-)

> Le dev moyen, comme la ménagère de moins de 50 ans, ça existe pas,
> enfin pas en vrai.
Ca existe, à condition d'en avoir plusieurs :)

Disons que c'est la moyenne entre le petit jeune qui sort de l'école et
le vieux con avec 30 ans d'expérience...

> Tu as déjà rencontré un mec qui te dis, bonjour je suis dévelopeur
> moyen, nan,
> tous le monde évolue, un dévelopeur moyen c'est juste une façon de
> figer les choses
> en regardant le passé alors qu'entre temps, toute la team c'est mis à
> guava
> et râle parce que ça serait plus cool d'avoir une syntaxe plus adapté
> que les inners classes.
> Même GoldmanSachs à une bibliothèque à base de lambdas qui s'ignore

> (et sur github en plus).

Concernant les inner-class, je peux te garantir que j'en vois
extrèmement peu dans les projets sur lesquels je bosse et sur les
projets que je suis amener à regarder (principalement des projets
Apache). Cela veut dire deux choses :
- on peut largement s'en passer
- dans les rares cas où on ne s'en passe pas, on préfère avoir du code
verbeux mais proche de la syntaxe classique pour éviter de "perturber"
le futur nouveau committer...

L'idée de base est de faciliter ce que j'appelle "l'entrée dans le code"
des futurs participants. Une syntaxe abstruse n'aide pas, et c'est un
peu la raison de ma croisade contre Scala (merde, je viens d'atteindre
le point Goodwin ici ;) : ça relève la barrière d'accès à un point que
le petit nouveau ne va pas pouvoir apporter sa contribution sauf effort
conséquent...

>
> Pour la petite histoire, je me souvient d'une discussion vers 97 d'un
> mec qui candidatait

> pour un poste d'enseignant de C++ et qui a gentillement expliqué que
> la programmation objet
> c'était trop compliqué pour le developeur moyen, heureusement, avec
> Visual C++,
> on pouvait écrire du code C en faisant semblant que c'est du C++.

:) Vous l'avez pris ?

>
>> On m'a appris il y a longtemps que ce qui faisait la différence en

>> programmation c'était la lisibilité et la facilité avec laquelle tout
>> un chacun peut intervenir sur du code qu'on a écrit.
>
> Oui, mais en même temps les pratiques évoluent, car les besoins évoluent.
Ca fait pas mal de temps que je bosse, et les besoins n'évoluent pas si
vite que ça. Ce que l'on fait en Java, on le faisait déjà en Smalltalk
il y a 40 ans. Certes beaucoup plus lentement ;-)

C'est juste qu'aujourd'hui, on n'a plus besoin de mettre 50 000€ sur la
table pour faire tourner une IDE sur une machine ayant la puissance
nécessaire...

Et si on compare Java avec C++, il y a même pas mal de choses en moins
dans le langage (héritage multiple, surcharge d'opérateurs, pointeurs de
fonctions...), ce qui le rend beaucoup plus simple à utiliser. Le fait
que Java intègre un GC nativement a aussi été une des principales raison
de son adoption (le write once, run everywhere aussi). Dans ce cadre, le
besoin a surtout été de proposer "a better C++". Et c'est un succès.

> Exemple extrème, on voit des designers se mettre à javascript puis à
> NodeJS,
> et là c'est farci de callbacks, de triggers partout, bref de lambdas.
Alors là, je me marre d'avance en attendant les résultats :) Et si je me
mettais à faire du Design, moi qui suis un développeur ? Ah, merde, le
problème, c'est que le Design, ça se voit immédiatement que ce que je
vais produire, c'est juste de la merde en bâton, vu mes "talents
graphiques" ;-) Bref, chacun son métier, les ports TCP seront bien
gardés ...

>
>> Hors dans une équipe et à plus forte raison une entreprise, normale,
>> les développeurs ne sont pas tous des stars, loin de là.
>
> Oui, mais en même temps, pas besoin d'être une star pour comprendre
> les lambdas,
> comparé aux inner-classes, au modèle de mémoire/à la concurrence, à la
> reflection,
> les lambdas c'est plus simple car une fois que tu as pigé la '->' et

> le '::', le reste c'est que
> de l'API, donc si tu comprends pas tu fais comme tout le monde, tu
> invokes le dieu javadoc.

C'est pas faux. Mais je ne suis pas sûr que ça ne va pas rendre le code
moins lisible. On risque de voir fleurir le code basé sur les callbacks,
et je te raconte pas l'enfer que ça va être pour débugger tout ce plat
de spaghettis...

Parce que au final, c'est quand même facile de retrouver une méthode par
son nom dans un IDE digne de ce nom, plutôt qu'une lambda... Mais c'est
peut-être un aspect qui n'intéresse pas trop celui qui écrit sa lambda
en pensant bien faire ?

[Frédéric Bouquet]

> Ce qui m'inquiète, tout comme Manu, c'est que ce genre de code est
> très élégant mais pas directement compréhensible par le développeur
> Java moyen.

Sans parler du développeur java moyen, pas plus tard qu'hier je me
suis retrouvé confronté à ce qui pourrait arriver avec les lambdas,
mais en Groovy. J'avais un code qui utilisait une closure ainsi que
quelques autres joyeusetés bien pratiques. Mon code faisait pas ce que
je voulais alors je demande l'avis d'un collègue. Sa première réaction
: "mais ya plein d'erreur de syntaxe dans ton code". Le bug était
simplement une variable qui n'était pas orthographiée comme il
fallait. La réaction de mon collègue et qu'il était habitué à du vieux
java car il ne s'était pas mis à jour sur les possibilités offertes
par Groovy. J'ai encore ce type de réaction de temps en temps avec les
for (Objet objet : collection), donc je n'ose même pas imaginer le
jour où l'on passera à java 8 :)
Pour beaucoup, même des gens pas mauvais que je côtoie, "tant que ça
marche comme je fais, pas besoin d'aller se former à de nouvelles
approches".

--
Frédéric Bouquet
Twitter/Github : bouquetf
http://www.espacedefouille.org/

[Dimitri]

A un moment faut réaliser que le développeur moyen, à 95% en France, il est ingénieur !

S'il pane pas le parallélisme, la récursivité ou les algos de réduction, il a sérieusement rouillé le pauvre.
Pour moi il a clairement les capacité de comprendre, mais pas assez pratiqué. J'ai beaucoup de mal à croire à une limite de capacité !

Je vote mille fois :

>>>> Files.forEachLine(path).filter(s ->
>>>> !s.startsWith("#")).map(Integer::parseInt).reduce(0, (a, b) -> a + b);

Ne serait-ce que pour la sensation que ce code est beaucoup plus testable (méthode par méthode).

-------------------------------
Dimitri BAELI

> --
> 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.

[Thibaud Vibes]

Le 07/09/2012 04:29, Emmanuel Lécharny a écrit :
> Le 9/6/12 11:47 PM, Remi Forax a écrit :
>>

Moi aussi. J'ai rin' compris à la 1ère.

En lisant la 1ère version j'ai raté le "!" devant s.startsWith("#")
parce qu'il y a plein de symbole et que c'est très compacte.

Sur la 2ème version on voit bien avec le mot clef "continue" la
condition qui "filtre".
De plus avec la 1ère version, j'ai toujours du mal à voir les passages
de paramètres: à la fonction map ou reduce on est tout perdu.

Je suis d'accord qu'on peut évoluer mais je vois pas l'intérêt de
régresser (puisque pendant un temps je ne vais plus comprendre du code Java)

[Patrice Trognon]

la formation n'est pas forcement uniquement une démarche personnelle du développeur curieux, pour un
développeur curieux et up2date comme on en rencontre beaucoup ici on va en avoir 10 qui sont plus
suiveurs.
Au début de nos discussions sur les lambda ma réaction à été de dire que c'était une connerie de mettre
ça dans java, ensuite j'ai adapté mon propos (en vous lisant) pour être plus sur une position :
Ok pour les lambda dans java mais c'est une option par défaut débrayée pour les 10 développeurs dont je parle
et les warriors (les castcodeurs) eux pourront l'activer. [tiens il est rigolo de constater que le correcteur automatique de Mail.app
remplace castcodeur par cascadeur (sic)]
Je suis toujours sur cette position !

Comme tu dis il va falloir se former sur les nouvelles approches, seulement les plus de 90% de code
maintenu et a maintenir sont écrit par des développeurs qui ne se formeront pas si leur entreprise ne
les y force pas ,et c'est bien la tout le problème avec ces features de warrior.

Pour mémoire Java a séduit rapidement dans les années 90 parce qu'il répondait simplement et avec une certaine
élégance a des problèmes hautement techniques posés par C++, comment en coupant dans le gras et en faisant
simple. Je ne peux donc que constater que les introductions de toutes ces features que seul les 10% de dev-cascodeurs
pourront manipuler sont un retour en arrière de Java et un desavoeux de ses origines !

J'utilise des syntaxe lambda dans d'autres langages (obj-c surtout) je ne le ferai jamais en java car ça n'a rien à y foutre !

Ca n'a rien à y foutre car ces syntaxes sont dangereuses pour qui ne sait pas les manipuler finement, et cela sera
90% des codeurs.
Le "tant que ça marche comme je fais, pas besoin d'aller se former a de nouvelles approches" c'est ce qui fait
qu'un projet ne se casse pas directement la gueule, ne l'oublions pas !
Ils ne se formeront pas parce que l'entreprise dans laquelle ils bossent les envoie tous les 5 ans au mieux
en formation, parce que pas le temps, parce que ça coute cher, parce que la gestion RH est catastrophique, parce que
parce que, il y en a des centaines pour ne pas former ses équipes, alors qu'il devrait en avoir des milliers pour les former !

Tout le monde ne se lève pas le matin avec l'envie d'absorber une nouvelle techno comme nous !

Alors ne jetons pas trop l'opprobre sur ces développeurs qui "refusent d'évoluer" car bien souvent ils n'ont pas le choix !
J'ai côtoyés longtemps ces devs lors de formation quand je faisais bcp de java et derrière il y a parfois des drames humains.

Java comme je dis souvent est le cobol des années 2000, alors vouloir y faire entrer des concepts trop abstrait est une erreur
a moins que ceux ci soient débrayable comme je disais au dessus.

Pat

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 :)

> --
> Frédéric Bouquet
> Twitter/Github : bouquetf
> http://www.espacedefouille.org/
>

> --

> 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.

[Patrice Trognon]

Le 7 sept. 2012 à 08:56, Dimitri <dba...@gmail.com> a écrit :

> A un moment faut réaliser que le développeur moyen, à 95% en France, il est ingénieur !
>

non ! va voir les équipes de devs dans les administrations françaises, dans le tertiaire d'une manière
générale. le développeur moyen il est arrivé la par hasard, il ne s'est pas réveillé a 14 ans en se disant :
putain je vais faire de l'assembleur sur ma calculette pour faire un starwar dessus et jouer pendant
mes cours !
Parce que celui qui est tombé dans la marmite il est pas dans ces équipes car ce type de boulot le gonfle
trop vite.

Ensuite "ingénieur" en informatique parlons en !
sur tout ceux que j'ai côtoyé la grande majorité avait pompé leurs TP de programmation et n'était pas
foutu d'écrire 3 lignes de code sans faire 10 horreurs, faut arrêter ingénieur en informatique c'est une
formation pour neuneu au cerveau vide pour la grande majorité, mis a part quelques rares écoles
leur formation ne porte pas sur le code.

Pat

[Nicolas Delsaux]

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

[Thibaud Vibes]

Le 07/09/2012 09:05, Patrice Trognon a écrit :
> Le 7 sept. 2012 à 08:56, Dimitri <dba...@gmail.com> a écrit :
>
>> A un moment faut réaliser que le développeur moyen, à 95% en France, il est ingénieur !
>>
> non ! va voir les équipes de devs dans les administrations françaises, dans le tertiaire d'une manière
> générale. le développeur moyen il est arrivé la par hasard, il ne s'est pas réveillé a 14 ans en se disant :
> putain je vais faire de l'assembleur sur ma calculette pour faire un starwar dessus et jouer pendant
> mes cours !
> Parce que celui qui est tombé dans la marmite il est pas dans ces équipes car ce type de boulot le gonfle
> trop vite.
>
> Ensuite "ingénieur" en informatique parlons en !
> sur tout ceux que j'ai côtoyé la grande majorité avait pompé leurs TP de programmation et n'était pas
> foutu d'écrire 3 lignes de code sans faire 10 horreurs, faut arrêter ingénieur en informatique c'est une
> formation pour neuneu au cerveau vide pour la grande majorité, mis a part quelques rares écoles
> leur formation ne porte pas sur le code.
>
> Pat

En tant qu'ingénieur en informatique, je suis d'accord.
(a telle point que je ne poste plus d'offre dans mon ancienne école)

>
>> S'il pane pas le parallélisme, la récursivité ou les algos de réduction, il a sérieusement rouillé le pauvre.
>> Pour moi il a clairement les capacité de comprendre, mais pas assez pratiqué. J'ai beaucoup de mal à croire à une limite de capacité !

A voila, je viens de comprendre la raison pour laquelle j'avais du mal
avec les lambdas.

[Patrice Trognon]

Le 7 sept. 2012 à 09:10, Thibaud Vibes <tvi...@onyme.com> a écrit :

>
> Le 07/09/2012 09:05, Patrice Trognon a écrit :
>> Le 7 sept. 2012 à 08:56, Dimitri <dba...@gmail.com> a écrit :
>>
>>> A un moment faut réaliser que le développeur moyen, à 95% en France, il est ingénieur !
>>>
>> non ! va voir les équipes de devs dans les administrations françaises, dans le tertiaire d'une manière
>> générale. le développeur moyen il est arrivé la par hasard, il ne s'est pas réveillé a 14 ans en se disant :
>> putain je vais faire de l'assembleur sur ma calculette pour faire un starwar dessus et jouer pendant
>> mes cours !
>> Parce que celui qui est tombé dans la marmite il est pas dans ces équipes car ce type de boulot le gonfle
>> trop vite.
>>
>> Ensuite "ingénieur" en informatique parlons en !
>> sur tout ceux que j'ai côtoyé la grande majorité avait pompé leurs TP de programmation et n'était pas
>> foutu d'écrire 3 lignes de code sans faire 10 horreurs, faut arrêter ingénieur en informatique c'est une
>> formation pour neuneu au cerveau vide pour la grande majorité, mis a part quelques rares écoles
>> leur formation ne porte pas sur le code.
>>
>> Pat
> En tant qu'ingénieur en informatique, je suis d'accord.
> (a telle point que je ne poste plus d'offre dans mon ancienne école)
>

les "faceux" passé l'informatique m'ont souvent surpris en programmation, très fort niveau d'abstraction.

passer des annonces tu peux, faut juste sélectionner ensuite par un vrai entretien technique, ça tu dois
savoir faire à te lire ;)

un candidat pour un poste de dev c'est assez facile, un ordi dans une piece, une connexion internet,
un sujet à traiter en deux heures, le mec doit installer ses outils et développer, que ça marche ou pas
au bout de deux heures tu t'en cogne ce qui compte c'est ce qu'il a fait et pourquoi, tu le fais parler
sur les outils qu'il a utilisé, sur le code qu'il a écrit, et tu sais si tu peux le prendre.
Ca fonctionne le seul défaut c'est qu'en faisant ainsi tu n'embauches que tes clones, bonjour la diversité
dans l'entreprise.

Pat

>>
>>> S'il pane pas le parallélisme, la récursivité ou les algos de réduction, il a sérieusement rouillé le pauvre.
>>> Pour moi il a clairement les capacité de comprendre, mais pas assez pratiqué. J'ai beaucoup de mal à croire à une limite de capacité !
> A voila, je viens de comprendre la raison pour laquelle j'avais du mal avec les lambdas.
>>>
>>> Je vote mille fois :
>>>>>>> Files.forEachLine(path).filter(s ->
>>>>>>> !s.startsWith("#")).map(Integer::parseInt).reduce(0, (a, b) -> a + b);
>>>
>>> Ne serait-ce que pour la sensation que ce code est beaucoup plus testable (méthode par méthode).
>>>
>>> -------------------------------
>>> Dimitri BAELI
>

[Thibaud Vibes]

Le 07/09/2012 09:35, Patrice Trognon a écrit :
> Le 7 sept. 2012 à 09:10, Thibaud Vibes <tvi...@onyme.com> a écrit :
>
>> Le 07/09/2012 09:05, Patrice Trognon a écrit :
>>> Le 7 sept. 2012 à 08:56, Dimitri <dba...@gmail.com> a écrit :
>>>
>>>> A un moment faut réaliser que le développeur moyen, à 95% en France, il est ingénieur !
>>>>
>>> non ! va voir les équipes de devs dans les administrations françaises, dans le tertiaire d'une manière
>>> générale. le développeur moyen il est arrivé la par hasard, il ne s'est pas réveillé a 14 ans en se disant :
>>> putain je vais faire de l'assembleur sur ma calculette pour faire un starwar dessus et jouer pendant
>>> mes cours !
>>> Parce que celui qui est tombé dans la marmite il est pas dans ces équipes car ce type de boulot le gonfle
>>> trop vite.
>>>
>>> Ensuite "ingénieur" en informatique parlons en !
>>> sur tout ceux que j'ai côtoyé la grande majorité avait pompé leurs TP de programmation et n'était pas
>>> foutu d'écrire 3 lignes de code sans faire 10 horreurs, faut arrêter ingénieur en informatique c'est une
>>> formation pour neuneu au cerveau vide pour la grande majorité, mis a part quelques rares écoles
>>> leur formation ne porte pas sur le code.
>>>
>>> Pat
>> En tant qu'ingénieur en informatique, je suis d'accord.
>> (a telle point que je ne poste plus d'offre dans mon ancienne école)
>>
> les "faceux" passé l'informatique m'ont souvent surpris en programmation, très fort niveau d'abstraction.

Oui. Notre 1er embauché a été un "faqueux" (si tu laisses un "c" ça fait
le son "ce", c'est comme les lambdas, c'est dure à lire), le 2nd aussi,
le 3ème...
Ben fait d'école d'ingé, y a que mon associé et moi :-)

> passer des annonces tu peux, faut juste sélectionner ensuite par un vrai entretien technique, ça tu dois
> savoir faire à te lire ;)

Ben y a aussi que, si j'en passe, ils veulent pas répondre, ou alors...
les "ingénieurs informatiques" qui sortent d'école se trouvent trop bien
pour écrire du code mais pensent que c'est une étape obligatoire. C'est
pour ça qu'y en a (enfin on en a déjà pas mal discuté sur la liste).

Est-ce que ces gens se soucient de l'avenir de Java? Est-ce que les
lambdas vont leur donner envie de continuer?
Hier un mec a frappé à la porte pour déposer son CV, il faisait du C# et
ils nous a dit: "je peux me mettre au Java!"
J'aurais du lui demander ce qu'il pensait des retards de java8 tiens
avant de prendre son CV (je pense qu'il aurait économisé un CV)

> un candidat pour un poste de dev c'est assez facile, un ordi dans une piece, une connexion internet,
> un sujet à traiter en deux heures, le mec doit installer ses outils et développer, que ça marche ou pas
> au bout de deux heures tu t'en cogne ce qui compte c'est ce qu'il a fait et pourquoi, tu le fais parler
> sur les outils qu'il a utilisé, sur le code qu'il a écrit, et tu sais si tu peux le prendre.
> Ca fonctionne le seul défaut c'est qu'en faisant ainsi tu n'embauches que tes clones, bonjour la diversité
> dans l'entreprise.

J'aime bien cette approche mais c'est un peu long.
Au prochain entretien, je balance direct l'exemple de Rémi Forax et je
demande au candidat qu'est-ce que ça fait?

Après je suis pas contre embaucher "mes clones", je serais sûr qu'ils
sont bons et que je vais bien m'entendre avec :-)

(bon je m'égare un peu mais c'est vendredi)

[Frédéric Bouquet]

> 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
- les langages avec sucre fonctionnel se répandent et l'approche est
en général accueillie avec plaisir par les devs (groovy, python, ...)

[Cédric Champeau]

Le 07/09/2012 08:22, Fr�d�ric Bouquet a �crit :
> Le bug �tait simplement une variable qui n'�tait pas orthographi�e
> comme il fallait.
<offtopic>Tiens, t'es pile dans un des use cases pour @TypeChecked dans
Groovy 2</offtopic> :)

--
C�dric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau

[Emmanuel Lécharny]

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...

[Patrice Trognon]

> 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 ?

>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

[Emmanuel Lécharny]

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 ;)

[Patrice Trognon]

Le 7 sept. 2012 à 10:40, Emmanuel Lécharny <elec...@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 ;)
>

héhé :)

>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>

[David Screve]

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 ?

[Frédéric Bouquet]

>>> 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 !

[David Screve]

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.....

[Nicolas Labrot]

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é. :)

2012/9/7 David Screve <david....@gmail.com>

[David Screve]

+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....

[Gabriel Landais]

Le 7 septembre 2012 11:18, David Screve <david....@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?

[Thibaud Vibes]

Le 07/09/2012 11:18, David Screve 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....

Y en a même qui vont boire des bières (jte jure) !!

[Patrice Trognon]

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

[Nicolas Delsaux]

2012/9/7 David Screve <david....@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.

> --
> 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
>

--
Nicolas Delsaux

[Frédéric Bouquet]

Ou quand tu prends le dmg/rpm/... généré par Henri, ça marche comme
sur des roulettes :)

[Emmanuel Lécharny]

Le 9/7/12 11:13 AM, David Screve a écrit :

> 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à.

[Xavier Combelle]

>>> tu pr�f�res,

>>>
>>> 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 ?

[Remi Forax]

On 09/07/2012 11:10 AM, David Screve wrote:
>
> 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 ?
>

Je crois que c'est l'approche de Oracle aussi,
http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm#BCGIBBCI

R�mi

[Remi Forax]

tu veux dire
sum([int(s) for s in open(path) if !s.startswith("#")])

R�mi

[Nicolas Labrot]

Et en scala %9.⊥:>>(_1, %9)

C'était trop tentant... ;)

2012/9/7 Remi Forax <fo...@univ-mlv.fr>

On 09/07/2012 01:19 PM, Xavier Combelle wrote:

tu préfères,

  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.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeurs+unsubscribe@googlegroups.com.

[Guillaume Laforge]

Mais où est ma monade ??? Euh... la limonade, pardon, j'ai soif :-)

2012/9/7 Nicolas Labrot <nit...@gmail.com>

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
SpringSource, a division of VMware

Blog: http://glaforge.appspot.com/

Social: @glaforge / Google+

[Henri Gomez]

> 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.

Serviteur

[Emmanuel Lécharny]

Le 9/7/12 2:14 PM, Nicolas Labrot a écrit :

> Et en scala %9.⊥:>>(_1, %9)

Point Goodwin atteint :)

[David Screve]

On 7 sep, 11:32, Nicolas Delsaux <nicolas.dels...@gmail.com> wrote:
> 2012/9/7 David Screve <david.scr...@gmail.com>:

>

>
> 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...

[David Screve]

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....

[Emmanuel Lécharny]

Le 9/7/12 7:40 PM, David Screve a écrit :

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.

[David Screve]

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

[yannick grenzinger]

Leave the developers alone !

Le développeur "moyen" (je suis loin d'être une brute en programmation et encore pire en maths) est largement capable de comprendre les lambdas à la sauce Java 8.
Ce n'est pas plus (voir moins) compliqué que la plomberie Java courante (JAX-B, WebServices, Spring, AOP, maven, hibernate ...)
Je me prends bien plus la tête sur faire marcher un Aspect qui passe sur un Managed Bean JMX et me dit que c'est pas possible que sur une callback ou un lambda.

Franchement je croise plus de mauvais managers et organisations que de mauvais développeurs (bon ok le code de l'out-sourcing fait souvent peur).

Par contre, pour le développeur qui ne veut plus apprendre (qui en 80 devait dire qu'il faut rester sur Cobol et en 90 ne surtout pas passer sur ce langage qu'est Java), oui les lambdas c'est peut être difficile à comprendre.

Yannick

[Patrice Trognon]

Le 8 sept. 2012 à 11:51, yannick grenzinger <yannick.g...@gmail.com> a écrit :

Leave the developers alone !

Le développeur "moyen" (je suis loin d'être une brute en programmation et encore pire en maths) est largement capable de comprendre les lambdas à la sauce Java 8.
Ce n'est pas plus (voir moins) compliqué que la plomberie Java courante (JAX-B, WebServices, Spring, AOP, maven, hibernate ...)
Je me prends bien plus la tête sur faire marcher un Aspect qui passe sur un Managed Bean JMX et me dit que c'est pas possible que sur une callback ou un lambda.

Franchement je croise plus de mauvais managers et organisations que de mauvais développeurs (bon ok le code de l'out-sourcing fait souvent peur).

Par contre, pour le développeur qui ne veut plus apprendre (qui en 80 devait dire qu'il faut rester sur Cobol et en 90 ne surtout pas passer sur ce langage qu'est Java), oui les lambdas c'est peut être difficile à comprendre.

Le développeur qui est resté sur Cobol et qui accepte de partir travailler dans une banque suisse, ok le boulot est ultra chiant, 

par contre je peux te dire qu'il a un salaire à faire pâlir  même le mieux payé de cette liste.

Pat

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/aNtS4cyKhggJ.

[yannick grenzinger]

La on parle de plan de carrière pas de dev moyen qui reste sur Cobol parce que Java c'est trop compliqué.
Pour info, Java dans la finance en Suisse c'est largement au dessus de 100k par an (j'ai vu passé une annonce à 130k).

De plus choisir une techno d'entreprise (Cobol, DBA Oracle, Admin Websphère, SAP ...) est souvent un bon choix quand on veut un job alimentaire qui paye bien :)

Yannick

[David Screve]

Moi, quand je lis dans la même phrase java et compliqué, je pense
"gros fail" pour un langage dont la promesse qui était étalée dans
toute la presse était de faire qqchose de plus simple que c++, qui
était trop compliqué......

On 8 sep, 14:24, yannick grenzinger <yannick.grenzin...@gmail.com>
wrote:

> La on parle de plan de carrière pas de dev moyen qui reste sur Cobol parce
> que Java c'est trop compliqué.
> Pour info, Java dans la finance en Suisse c'est largement au dessus de 100k
> par an (j'ai vu passé une annonce à 130k).
>
> De plus choisir une techno d'entreprise (Cobol, DBA Oracle, Admin
> Websphère, SAP ...) est souvent un bon choix quand on veut un job
> alimentaire qui paye bien :)
>
> Yannick
>
>
>
>
>
>
>
> On Saturday, September 8, 2012 1:21:26 PM UTC+2, Patrice Trognon wrote:
>

> > Le 8 sept. 2012 à 11:51, yannick grenzinger <yannick.g...@gmail.com<javascript:>>
> > a écrit :
>
> > Leave the developers alone !<http://knowyourmeme.com/memes/leave-britney-alone>

> >> > Emmanuel Lécharnywww.iktek.com<http://xn--lcharnywww-b7a.iktek.com/>

>
> > --
> > Vous recevez ce message, car vous êtes abonné au groupe Google
> > Groupes lescastcodeurs.
> > Cette discussion peut être lue sur le Web à l'adresse
> >https://groups.google.com/d/msg/lescastcodeurs/-/aNtS4cyKhggJ.
> > Pour envoyer un message à ce groupe, adressez un e-mail à

> > lescast...@googlegroups.com <javascript:>.

> > Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse

> > lescastcodeur...@googlegroups.com <javascript:>.

[Remi Forax]

On 09/09/2012 12:46 AM, David Screve wrote:
> Moi, quand je lis dans la m�me phrase java et compliqu�, je pense
> "gros fail" pour un langage dont la promesse qui �tait �tal�e dans
> toute la presse �tait de faire qqchose de plus simple que c++, qui
> �tait trop compliqu�......

Java reste plus simple que le C++ qui lui aussi se complexifie,
mais bon est-ce vraiment une bonne id�e de ce comparer � C++.

R�mi

>
> On 8 sep, 14:24, yannick grenzinger <yannick.grenzin...@gmail.com>
> wrote:

>> La on parle de plan de carri�re pas de dev moyen qui reste sur Cobol parce
>> que Java c'est trop compliqu�.

>> Pour info, Java dans la finance en Suisse c'est largement au dessus de 100k

>> par an (j'ai vu pass� une annonce � 130k).

>>
>> De plus choisir une techno d'entreprise (Cobol, DBA Oracle, Admin

>> Websph�re, SAP ...) est souvent un bon choix quand on veut un job

>> alimentaire qui paye bien :)
>>
>> Yannick
>>
>>
>>
>>
>>
>>
>>
>> On Saturday, September 8, 2012 1:21:26 PM UTC+2, Patrice Trognon wrote:
>>

>>> Le 8 sept. 2012 � 11:51, yannick grenzinger <yannick.g...@gmail.com<javascript:>>
>>> a �crit :

>>> Leave the developers alone !<http://knowyourmeme.com/memes/leave-britney-alone>

>>> Le d�veloppeur "moyen" (je suis loin d'�tre une brute en programmation et
>>> encore pire en maths) est largement capable de comprendre les lambdas � la
>>> sauce Java 8.
>>> Ce n'est pas plus (voir moins) compliqu� que la plomberie Java courante

>>> (JAX-B, WebServices, Spring, AOP, maven, hibernate ...)

>>> Je me prends bien plus la t�te sur faire marcher un Aspect qui passe sur

>>> un Managed Bean JMX et me dit que c'est pas possible que sur une callback
>>> ou un lambda.
>>> Franchement je croise plus de mauvais managers et organisations que de

>>> mauvais d�veloppeurs (bon ok le code de l'out-sourcing fait souvent peur).
>>> Par contre, pour le d�veloppeur qui ne veut plus apprendre (qui en 80

>>> devait dire qu'il faut rester sur Cobol et en 90 ne surtout pas passer sur

>>> ce langage qu'est Java), oui les lambdas c'est peut �tre difficile �
>>> comprendre.
>>> Le d�veloppeur qui est rest� sur Cobol et qui accepte de partir travailler

>>> dans une banque suisse, ok le boulot est ultra chiant,

>>> par contre je peux te dire qu'il a un salaire � faire p�lir m�me le mieux
>>> pay� de cette liste.

>>> Pat
>>> Yannick
>>> On Friday, September 7, 2012 11:36:16 PM UTC+2, David Screve wrote:
>>>> 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:
>>>>> Le 9/7/12 7:40 PM, David Screve a �crit :
>>>>>> 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.
>>>>> --
>>>>> Regards,
>>>>> Cordialement,

>>>>> Emmanuel L�charnywww.iktek.com<http://xn--lcharnywww-b7a.iktek.com/>
>>> --
>>> Vous recevez ce message, car vous �tes abonn� au groupe Google
>>> Groupes lescastcodeurs.
>>> Cette discussion peut �tre lue sur le Web � l'adresse
>>> https://groups.google.com/d/msg/lescastcodeurs/-/aNtS4cyKhggJ.
>>> Pour envoyer un message � ce groupe, adressez un e-mail �
>>> lescast...@googlegroups.com <javascript:>.
>>> Pour vous d�sabonner de ce groupe, envoyez un e-mail � l'adresse