Discussion :

[François M.]

"Don't feed the troll".

Je ne suis même pas sur que MoumouteMasters est un troll "conscient".

[Logan Mauzaize]

Pourquoi? Mais pourquoi???

Pourquoi offrir un cadre de développement et rester ouvert ? Parce qu'il existe une multitude d'applications ...

Plus sérieusement, mon client me paie pour que je lui sorte du code qui lui est utile.

Tout code qui répond à son besoin est utile. Si un bon framework permet de faire le travail plus proprement et plus rapidement. Ce serait un tord de s'en passer.

Je veux passer du temps sur du code client, et pas jouer du légo avec des briques Java.

Tout système se compose d'autres systèmes

Je ne vois pas de raison a priori de sortir des sentiers battus: il y a un standard, il est supporté, je le suis, et je ne me pose des questions que sur le code client.

Il y a autant de raison que de fonctionnalité non supportée (ex: génération PDF, accès aux bases NoSQL, etc.) ou buggée.

Et je fais confiance à des gens comme toi, des architectes, pour me pondre une solution technique clé en main, gérant à la fois les performances, le multithread, etc.

Un architecte "dessine" un cadre de travail qu'il s'agisse des technologies mais aussi de processus/méthode (y compris les moyens de formation des intervenants). Mais tout cela reste un plan qu'il convient d'ajuster par les retours pertinents des intervenants.
Il n'est pas question d'enseigner les principes de la performance et du multi-thread (sauf débutant), un développeur doit connaître cela car c'est son métier. L'architecte veillera à ce que les choix techniques soient cohérents (en tout temps) avec les besoins de l'application ; et notemment sa capacité à tenir la charge (en multithread ou non). Une raison de plus de sortir du standard.

Et donc, désolé de le dire, mais, dans ce cadre, que ce soit un client ou un architecte, tous vont vouloir tester le dernier truc à la mode. La communauté Java sort un gros framework par 2 ans (à la louche) et tout le monde se précipite dessus. Il suffit de voir à quel point la norme JEE et spring se tirent la bourre.

J2EE a 16ans et Spring 12 ans. Le premier est un standard au sens de spécification et le second un standard de fait.

Et le C# n'a pas ce problème. En C#, tu as une norme sans concurrence, et tu fais gagner à tout le monde un temps précieux: tu fais comme ça, et si ça merde, tu appelles un architecte ou un expert technique. Et nous, développeurs, on se concentre pour savoir ce que le client veut

Trouver des solutions techniques d'implémentation est loin d'être le ressort de l'architecte. Et appeler un expert technique pour tout contournement me donne l'impression de passer à côté du métier de développeur.

Je ne connais pas l'environnement .Net mais je doute que Microsoft fournisse un standard pour tous ce qui existe (logs, TU, mock, messagerie, injection de dépendance, ESB, EAI, router, grille de calcul, cache distribué, etc.).

Il fera quoi lui? Il produira un framework patché qui corrigera le problème?

Et pourquoi pas ? Même si à mon sens c'est plus le rôle du développeur. J'ai souvent patché des COTS (Hibernate, JSF, RichFaces).

Et d'ailleurs, python reprend cette idée. Une seule façon de faire les choses, et les gens s'en portent mieux.
Perso, ça ne marche pas, blam, google. Pas les sources. Mais j'admire.

Ou alors ils font simplement avec, comme toi

La raison est que tu as une seule façon de faire, donc, si ça merde, ça se voit très vite, et c'est patché très vite.
Je trouve ça admirable, mais je ne suis pas certain que tout le monde ait ta curiosité.

Au delà de la correction, ce que je trouve intéressant c'est le débug (comprendre pourquoi ton utilisation ne fonctionne pas), éventuellement comprendre comment ca marche (utile surtout quand la documentation est absconse) et sourtout pour trouver des points d'extension (endroit où l'on peut injecter des changements).


Tout cela nous éloigne de la question initiale, est-ce que le langage Java est mourant. A mon avis, non. Il évolue au fil des ans pour prendre ce qui peut l'être "facilement". Même s'il y a de nombreux langages alternatifs (pour la JVM) intéressant (Groovy, Scala, Ceylon, JavaScript, etc.). Je pense qu'il demeura un langage "simple" et donc le langage standard pour la JVM.

[yahiko]

Je pense (que Java) demeura (...) le langage standard pour la JVM.

Encore heureux !
C'est un peu comme dire que l'ASM x86 restera le jeu d'instruction pour les processeurs Intel

[Logan Mauzaize]

Encore heureux !
C'est un peu comme dire que l'ASM x86 restera le jeu d'instruction pour les processeurs Intel

Beaucoup pensent que Scala deviendra le langage officiel de la JVM à plus ou moins long termes.

[rmaker]

Beaucoup pensent que Scala deviendra le langage officiel de la JVM à plus ou moins long termes.

Jamais entendu ça, mais admettons. Pourquoi à ton avis? Parce que le fonctionnel redevient à la mode? Parce que Scala est un bon mix entre OO et fonctionnel?

[Logan Mauzaize]

Jamais entendu ça, mais admettons.

Ca revient régulièrement sur Quora et autres. Et il me semble également que des gens l'ont déjà mentionné aussi sur DVP.

Pourquoi à ton avis?

D'un certains point de vue, Scala est plus évolué que Java : traits, inférence, pattern matching. Il y a également le support "natif" des structures de données (list, map, tuple, destructuration).
Le support évolué de la programmation fonctionnel est aussi un argument.

Parce que le fonctionnel redevient à la mode?

Parce que le développement asynchrone est un très bon choix pour les environnements concurrents. Et que le paradigme fonctionnel permet de traiter très bien l'asynchronicité et la concurrence. Et comme on demande de plus en plus de choses aux SI, il faut bien en passer par là.

Après on en demande aussi de plus en plus parce qu'on sait en digérer de plus en plus. Mais quand on voit les retours pour les entreprises, elles n'hésitent pas à investir dans des applications de plus en plus gourmandes en données (et en traitements).

Parce que Scala est un bon mix entre OO et fonctionnel?

C'est surement un bon argument. Tant dans le fait que Scala permet de manipuler l'un aussi bien que l'autre indépendamment mais aussi (et surtout) ensemble !

[yahiko]

Tout ce qui pourra tuer Java me convient. Donc gloire à Scala !

[Mickael_Istria]

Que choisir entre Oracle (Java) ou Microsoft (.NET) ? Pas évident

L'ecosysteme Java ne s'arrete pas a Oracle, loin de la.
En fait tu as le choix entre Microsoft et Oracle+IBM+Red Hat+Intel+Google+SAP+Ericsson+Airbus+STMicro+Schneider+...

[Mickael_Istria]

Beaucoup pensent que Scala deviendra le langage officiel de la JVM à plus ou moins long termes.

Plutot "esperent" que "pensent". Car il ne me semble pas que quiconque dans la communaute des developpeurs de Scala ait annonce cette intention, entame les demarches pour que Scala soit standardise via un JCP ou une JSR, et en fait il semblerait que "la majorite silencieuse" n'ait en fait pas besoin de tout ce qu'apporte Scala et se contente tres bien de Java.
Note que je ne suis pas oppose a cette idee, c'est juste qu'elle me parait vraiment lointaine.
Quand le bateau Java/JVM aura entierement coule, que tous les acteurs ayant capitalise sur Java le laisseront sombrer, alors Scala pourra en prendre la barre

[rmaker]

Quand le bateau Java/JVM aura entierement coule, que tous les acteurs ayant capitalise sur Java le laisseront sombrer, alors Scala pourra en prendre la barre

Quand le bateau Java aura coulé, à mon avis, le bateau JVM restera, et il y aura bien un langage plus plaisant qui sortira après la compilation du bytecode.
Et donc, au fond, la grande force du combo Java -> JVM, c'est la JVM. Elle va subsister, mais pas forcément le Java. Et c'est cool pour nos ami-e-s de la DSI, parce qu'on pourra faire exister du legacy (en java) avec du tout beau tout neuf (peut être du scala). Ce n'est pas le cas de cobol ou autre dinosaurerie qui n'a pas de socle (comme la JVM) pour interagir avec le reste du monde. En résumé: vive la JVM, vivement que java rattrape son retard sur le C#.

[François M.]

vivement que java rattrape son retard sur le C#.

C'est difficile pour deux raisons :

- C# est parti avec suffisamment de retard pour éliminer dès sa conception les trucs plus ou moins mal pensés de Java.
- et .... C# continu à évoluer. (on en est à la 5.0, la 6.0 arrive).

[rmaker]

C'est difficile pour deux raisons :

- C# est parti avec suffisamment de retard pour éliminer dès sa conception les trucs plus ou moins mal pensés de Java.
- et .... C# continu à évoluer. (on en est à la 5.0, la 6.0 arrive).

On est bien d'accord. Avec en 5.0 des trucs extraordinaires comme l'asynchronisme. Ce qui m'étonne le plus, c'est que la VM de Microsoft n'ait pas plus pris. Mais c'est une autre histoire. En fait, le C# a pris le chemin inverse: un super langage, et une VM qui n'est pas standard. Dommage!

[Logan Mauzaize]

Je préfère préciser mes propos

Plutot "esperent" que "pensent".

Je pense que certains sont convaincus que ca arrivera un jour.

Car il ne me semble pas que quiconque dans la communaute des developpeurs de Scala ait annonce cette intention, entame les demarches pour que Scala soit standardise via un JCP ou une JSR, et en fait il semblerait que "la majorite silencieuse" n'ait en fait pas besoin de tout ce qu'apporte Scala et se contente tres bien de Java.

Je parle ni des développeurs, ni de "majorité". Juste qu'il y a un certains nombre de personne qui évoquent le sujet. Et comme je le précisai juste avant, je ne partage pas cet avis bien au delà des processus de standardisation requis.

Note que je ne suis pas oppose a cette idee, c'est juste qu'elle me parait vraiment lointaine.

Utiliser Scala comme langage principal est une chose, en faire le langage officiel en est une autre !

Quand le bateau Java/JVM aura entierement coule, que tous les acteurs ayant capitalise sur Java le laisseront sombrer, alors Scala pourra en prendre la barre

Quand la VM coulera, Scala suivra. L'un de ne va pas s'en l'autre. Et concernant Java, au pire, comme toutes les technologies Java, il restera une implémentation de référence d'un langage pour générer du bytecode comme l'est Glassfish pour les serveurs J2EE.

Par ailleurs, je pense que l'idée d'obligation d'une implémentation de référence pour toutes les JSRs est une grande force de Java.

Quand le bateau Java aura coulé, à mon avis, le bateau JVM restera, et il y aura bien un langage plus plaisant qui sortira après la compilation du bytecode.

Il y a déjà un grand nombre de langage alternatif pour la JVM : List of JVM languages

Et donc, au fond, la grande force du combo Java -> JVM, c'est la JVM. Elle va subsister, mais pas forcément le Java. Et c'est cool pour nos ami-e-s de la DSI, parce qu'on pourra faire exister du legacy (en java) avec du tout beau tout neuf (peut être du scala). Ce n'est pas le cas de cobol ou autre dinosaurerie qui n'a pas de socle (comme la JVM) pour interagir avec le reste du monde. En résumé: vive la JVM, vivement que java rattrape son retard sur le C#.

Java ne rattrapera jamais son retard sur C# car toute nouvelle fonctionnalité est longuement discutée avant d'être implémentée. Donc C# continuera à évoluer plus vite que Java ; sauf s'il est abandonné ou qu'on arrête l'innovation.

[rmaker]

Utiliser Scala comme langage principal est une chose, en faire le langage officiel en est une autre !

Pas tellement, non. La seule question, c'est la proportion de gens qui s'en servent. Que scala devienne un standard de fait, ou un langage officiel, ça ne change rien: la communauté va demander un paquet d'innovations, voire les réaliser. Oracle, s'ils sont normalement cablés, va courir après l'argent ses clients potentiels et suivre le marché. Si c'est Scala, même de manière pas officielle, peu importe!

Quand la VM coulera, Scala suivra. L'un de ne va pas s'en l'autre. Et concernant Java, au pire, comme toutes les technologies Java, il restera une implémentation de référence d'un langage pour générer du bytecode comme l'est Glassfish pour les serveurs J2EE.

Non plus. Quand la JVM d'oracle coulera, il existera une alternative open source pleinement compatible avec Scala. Et si Scala n'est qu'un effet de mode, Java ou un autre reprendra le devant de la scène. Ce qui, avec Spark, me parait peu probable, mais passons.

Java ne rattrapera jamais son retard sur C# car toute nouvelle fonctionnalité est longuement discutée avant d'être implémentée. Donc C# continuera à évoluer plus vite que Java ; sauf s'il est abandonné ou qu'on arrête l'innovation.

On est d'accord sur la pauvreté de l'innovation en Java. Microsoft suivant ses clients, je ne crois pas du tout, par contre, à un abandon sec du C#.

[Logan Mauzaize]

Pas tellement, non. La seule question, c'est la proportion de gens qui s'en servent. Que scala devienne un standard de fait, ou un langage officiel, ça ne change rien: la communauté va demander un paquet d'innovations, voire les réaliser. Oracle, s'ils sont normalement cablés, va courir après l'argent ses clients potentiels et suivre le marché. Si c'est Scala, même de manière pas officielle, peu importe!

Sauf qu'Oracle n'est que propriétaire des marques et du (peu de ?) code qui reste encore "close source". Sachant qu'une majorité du code non ouvert n'est même pas la propriété d'Oracle mais de tiers ayant cédé le droit d'utilisation (protocole, compression, algorithme, etc.).

Tout ce qui concerne la JVM fait l'objet d'un processus piloté par un comité. Donc peu importe que la populace demande l'inférence de type, si le comité ne suit pas, cela n'arrivera pas. Après le comité représente la dite populace (éditeurs, JUGs, etc.). Donc pour devenir un langage officiel, il faudra passer par une JSR et ensuite cela imposera que toute évolution passe également par là.
Cela implique également que les propriétaires actuels de la technologie Scala (langage, compilateur, API, documentation, etc.) renoncent à leurs droits et acceptent de s'engagent dans ce processus ; ce dont je doute.

Non plus. Quand la JVM d'oracle coulera, il existera une alternative open source pleinement compatible avec Scala. Et si Scala n'est qu'un effet de mode, Java ou un autre reprendra le devant de la scène. Ce qui, avec Spark, me parait peu probable, mais passons.

Que ce soit Scala, les applications qui se basent dessus et les librairies qui tournent autour (à base de Scala ou non) tous reposent sur la JVM (bytecode, JavaSE API, memory model, etc.). Donc la mort de la JVM signera également la mort de tout ce qui repose dessus.
Des langages ayant les mêmes fonctionnalités que Scala, cela existe.