Dans un article précédent, j’ai fait quelques comparaisons entre l’évolution des langages informatiques et les langages naturels. L’une d’entre elles est l’exhaustivité de Turing : les locuteurs natifs expriment tout ce qu’ils veulent avec une boîte à outils limitée de vocabulaire, de sons et de règles syntaxiques qui ne doivent pas être trop difficiles à maîtriser. Un autre parallèle est la nature lente et progressive de l’évolution du langage. Les langues évitent les changements de rupture, étant donné les milliards de lignes d’héritage qui seraient autrement rendues illisibles.
Qu’est-ce que cela signifie pour Java ? Il est logique de rester fidèle à ses racines OO et d’optimiser son potentiel expressif, plutôt que d’introduire des changements de paradigme qui rompent la rétrocompatibilité. Pour rester dans la même langue, de grandes refontes syntaxiques sont peu probables. La mutabilité et les déclarations vides feront toujours partie du langage, malgré l’appétit croissant pour des fonctionnalités de langage plus fonctionnelles. C’est très bien car la plate-forme JVM peut offrir le meilleur des deux mondes. L’interopérabilité du byte code permet aux langages radicalement différents (Frege, Clojure) d’accéder facilement à un écosystème riche et stable. Java n’a pas à être le marteau d’or de la programmation.
Des expressions au lieu d’énoncés
Pendant ce temps, Java n’est pas inconscient de ce qui se passe dans les langages concurrents sur la JVM comme Kotlin et Scala. Les modèles de programmation réactifs et asynchrones (pensez à Akka et Coroutines) favorisent un style de codage fonctionnel. Le style traditionnel et impératif de manipuler les données à l’aide d’instructions explicites est synonyme de changement d’état et entraîne des effets secondaires insolubles lorsqu’il est mal fait. Les méthodes void qui modifient l’état de l’instance dans laquelle elles sont définies (ou pire, ses arguments) sont traitées comme l’odeur du code qu’elles sont.
Java a rattrapé son retard en autorisant les instructions switch en tant qu’expressions. La préférence en faveur des énoncés est claire. Nous pouvons même voir des blocs if-then-else recevoir une transformation similaire. L’immuabilité dans la forme des enregistrements est un autre mouvement, idéal pour le traitement parallèle car il élimine une synchronisation beaucoup plus coûteuse.
Les concurrents sur la JVM peuvent surpasser Java avec des changements plus puissants qui sont difficiles à introduire si vous restez attaché à la compatibilité descendante. Ainsi, de nombreux irritants mineurs ne seront pas résolus et certaines fonctionnalités appréciées ne pourront pas être introduites. L’interface List ne deviendra pas immuable par défaut. Les exceptions cochées sont là pour rester. Java n’obtiendra pas le système de type nullable de Kotlin. Aucun point d’interrogation à ce sujet.
Haskell et Lisp sur la JVM
Que diriez-vous d’un fork vers un surensemble strict, comme Typescript l’a fait avec JavaScript, introduisant un langage plus expressif ? Quels que soient les défis, il n’y a aucun goût pour concevoir un tel sur-ensemble Java++. Nous n’en avons pas besoin car nous avons déjà plusieurs langages JVM matures qui répondent à des paradigmes radicalement différents. Vous pouvez même faire Haskell et Lisp sur la JVM avec Frege et Clojure, respectivement. L’avenir verra plus de projets polyglottes. Dans une architecture avec plusieurs équipes travaillant sur des services faiblement couplés, il est plausible de développer certains services en Scala, Kotlin ou Clojure si cela est plus approprié.
Les concours de popularité des langues basés uniquement sur les statistiques des moteurs de recherche sont des mesures grossières, mais il est juste de dire que les concurrents de JVM n’ont pas encore sérieusement réduit (disons, plus de 10 % de réduction) le nombre de projets qui choisissent toujours Java comme principal Langue. La même plate-forme JVM qui accueille ces alternatives reste également la centrale qui maintient Java en selle. Des cycles de publication plus rapides signifient que vous pouvez profiter des nouvelles fonctionnalités plus rapidement. L’intervalle pour les versions de support de longue durée peut être raccourci à deux ans. Tout cela rend une transition à l’échelle de l’entreprise vers Kotlin ou Scala moins attrayante.
Masse critique
Les langages JVM alternatifs souffrent d’un plus petit bassin d’expertise – agréable pour les développeurs, moins pour leurs employeurs. Leur écosystème d’outillage dédié est souvent plus petit et moins mature. Bien sûr, bon nombre de ces inconvénients sont des douleurs de croissance. Le temps peut en guérir certains, et la concurrence pourrait éventuellement réduire considérablement la popularité de Java. Si un concurrent prend suffisamment d’élan, Java pourrait être perdu à long terme – je mettrais cependant mon argent sur Kotlin, pas sur Scala. Même ainsi, cela ne ferait que rendre la JVM en tant que plate-forme plus attrayante.
Enfin, il ne faut pas trop s’accrocher à l’expressivité supérieure de telle ou telle langue. Juste parce que tu pouvez développer quelque chose en tant que projet d’entreprise Java ne signifie pas que vous devriez le faire. Les exigences non fonctionnelles pour de tels projets (sécurité, évolutivité) ont rendu presque impossible d’être un développeur full stack qui maîtrise également bien Java backend, le framework Web JavaScript. du jour, UX et déploiement cloud.
Le plus gros marteau d’or de tous
Le codage lui-même est peut-être le plus gros marteau d’or de tous. Nous bricolons moins avec le code source et plus avec la configuration. Les plates-formes low-code et no-code offrent une plate-forme de programmation volontairement contrainte pour les problèmes métier génériques, comme antidote à cette surcharge de complexité. Ne les traitez pas comme une balle d’argent ou comme un marteau d’or, remarquez.
Ils sont adaptés aux problématiques métiers vanilles. Et si vous ne pouvez pas cliquer et faire glisser votre chemin hors d’une logique métier non triviale, vous pouvez généralement insérer des extraits de code personnalisé pour y faire face. Écrit en Java, par exemple.