Mikaël nous demandait quel langage parviendra à combiner les avantages d’un langage de haut niveau (Smalltalk, PHP, Ruby ou autre) et les qualités de la JVM ?

Pour Jean-françois, il semblerait bien que ce soit Scala.

A propos de Scala, Guillaume viens de voir que les outils pour Scala sous Eclipse sont plutôt abondants et riches. Le pauvre, il va devoir abandonner Java ;-).
Fort heureusement, avec 18 annonces monster pour Scala sur l’ensemble des US, il semblerait que nos jobs de développeurs Java ne soient pas en péril pour tout de suite !

Bruno (M. eclipsetotale) va (enfin !) venir apporter un peu de lumière dans le débat :

« J’ai beaucoup trop de remarques à faire, en voici quelques unes :

- Guillaume, l’outillage est certes important, mais je ne pense que ça soit une raison du succès de Java sachant que pour moi Java s’est imposé sur la période 1996-2002, soit avant l’arrivée d’Eclipse. A l’époque il y avait soit VisualAge qui existait pour d’autres langages soit JBuilder qui était largement inspiré de l’outillage C++ (idem pour les autres IDE de l’époque). Aujourd’hui effectivement, un outillage correct est devenu un critère important pour d’éventuels successeurs à Java, ça explique le choix de Google avec GWT et Android : profiter du fait que java est établi, bien outillé et largement utilisé plutôt que d’essayer de pousser un langage alternatif.

– D’ailleurs si on accepte mon point de vue sur la période 1996-2002, on a peut-être une explication du fait que PHP ne se soit pas imposé : PHP est réellement un langage objet depuis la V5 (soit depuis 2004). Ce critère de l’objet était vraiment incontournable à l’époque.

– Je ne crois pas au succès possible de Scala : la rupture est trop violente pour la majorité des développeurs, il suffit de voir quelques lignes de code pour s’en rendre compte… Mais tout le monde ne partage pas cet avis.

Sur Scala, deux liens avec des avis opposés :

- Le post du créateur de Groovy indiquant que pour lui Scala c’est l’avenir de Java (à noter cette phrase : « I can honestly say if someone had shown me the Programming in Scala book, I’d probably have never created Groovy ») : http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
– Le compte rendu d’une présentation récente (Devoxx il y a deux semaines) intitulé ‘Next Big java Language’ : http://blog.loof.fr/2010/11/next-big-java-language.html
(pour avoir un argumentaire plus détaillé de l’orateur : http://www.jroller.com/scolebourne/entry/the_next_big_jvm_language1 )

Guillaume lui répond :

Je savais qu’il ne fallait pas contredire Bruno ! Cependant, tel le lemming, je continue tout droit :

Tu as raison quand tu écris que l’outillage n’est pas la raison pour laquelle Java s’est imposé, mais la raison pour laquelle il sera difficile de le remplacer. On a tendance à oublier les débuts de Java.

Je me rappelle le truc qui m’a le plus surpris quand j’ai découvert Java : « Quoi ? Le compilateur et le SDK sont GRATUITS ? » Vous pouvez pleurer sur smalltalk, mais VisualWorks + Envy/Developper ça coutait un bras
ndr: ça coute toujours un ou deux bras, mais depuis il y a aussi des VM et environnements opensource et gratuits … Voir squeak par exemple.

Le BIG langage de l’époque était le C++, et Java était objectivement mieux que C++ pour le développeur lambda : GC inclus, librairies objets plus simples, synchronized, awt, puis ensuite Swing.
Portable ! Fini le ./configure --prefix=/usr/local make make install. Il fallait y passer la journée pour compiler un programme C++.

Voilà pourquoi Java : mieux que C++, tout simplement.

Et ça a mis du temps, je me rappelle chez Sema en 99~2000 : « vous voulez faire un serveur en Java ?!? Vous n’y pensez pas ! Les serveurs c’est en C++, Java c’est bon pour faire des applets !« .

Donc, Java a remplacé C++ parce que pareil mais en plus simple. C’est pourquoi OCaml n’a jamais remplacé Java. Ca peut militer contre Scala, si c’est trop élitiste et trop éloigné de Java.

Bon tout ça, c’est bien joli les gars mais, Mikaël, le Programmeur de Base, il sait ce qui l’attend :

« Je garde tous ces échanges pour les relire dans quelques années …
Dans 10 ans, on dira quelque chose comme: JBidul c’est de la daube, ça gère pas les rétro-types dynamiques asynchrones. Il faut passer à eTruc, qui est 10 fois mieux que Machin++.

Et ça sera tout pareil : les mêmes bugs, le même bordel, les mêmes usines à gaz imbuvables ! Au mieux les fenêtres seront un peu plus jolies.

Finalement, je vais apprendre Cobol. Ca c’est l’avenir. »

On laissera la conclusion à Bruno :

Java c’est le COBOL de demain : c’est tout à fait vrai !

Le Java de demain : C# ? Non je pense plus que la tendance ça va être l’utilisation de langages plus spécifiques. Pour voir émerger un successeur il faudrait voir apparaître une nouvelle gamme de besoins. Si on prend les critères non techniques qui ont permis à Java de s’imposer, je vois un seul candidat pour l’instant : JavaScript !

La liste des critères qui pour moi explique le succès de Java dès son origine :

- la gratuité ! (exactement ce que tu décris dans ton message)

– le buzz et la visibilité (les applets et l’intégration de la JVM dans NetScape et IE dès 1996)

– la politique : dès 96, IBM, Oracle et Sun se sont alliés pour pousser Java. Leur intérêt commun était de proposer une solution pour contrer la montée en puissance de Microsoft côté serveur

Après le langage en lui-même est moyen mais finalement une assez bonne synthèse de ce qui se faisait : Objet classique, syntaxe à la C++, VM, GC et surtout librairies tout aussi gratuites que le compilateur et la JVM.

Si on regarde ces critères pour JavaScript on a :

- la gratuité avec un cran supplémentaire : complètement libre (pas de Copyright sur le code (normal il n’y a pas de librairie), et à ma connaissance, pas de TradeMark sur le nom)

– le buzz (Web 2.0, HTML 5) (Un gros bémol étant sa mauvaise image auprès des développeurs et son ancienneté)

– la politique : encore plus fort que Java car tout le monde le pousse (Microsoft, Google, Apple, IBM, Yahoo …)

Côté technique, il y a un très bon potentiel mais avec des points faibles : l’outillage et la permissivité.
Dernière phrase d’une présentation de Brendan Eich (le père de JavaScript et actuel CTO de Mozilla) : « JavaScript : the revenge of Smalltalk »
(cf http://brendaneich.com/2010/11/proxy-inception/)

La bataille du socle technique côté client est gagné pour JavaScript, reste à voir si les développeurs coderont en JavaScript où si celui-ci sera généré.

Merci à tous nos auteurs bien malgré eux !
Stéphane Liétard