Points Clés
- Java est toujours un excellent langage, mais Kotlin est une alternative incrémentielle à développement plus rapide, tandis que Scala pousse la programmation fonctionnelle à l'extrême.
- James préfère les langages qui lui permettent d'écrire un code plus correct grâce à un haut niveau de validation au moment de la compilation.
- Grâce à Scala, James a trouvé des paradigmes de programmation et des expériences qui ont modifié sa façon de penser.
- La mutabilité par défaut en Java est une "erreur à mille milliards de dollars" car elle rend difficile de raisonner sur ce que fait le code.
- L'approche du projet Loom change la donne car elle supprime la surcharge cognitive de la programmation réactive.
James Ward est un Java Champion et Kotlin Product Manager chez Google. Il anime le podcast "Happy Path Programming" avec Bruce "Thinking in Java" Eckel. Dans un épisode, Bruce Eckel a parlé de "personnes qui sont toujours piégées dans le monde Java". James Ward a accepté et a appelé la mutabilité par défaut en Java "l'erreur à mille milliards de dollars" (faisant référence à "l'erreur à milliard de dollars" des NullPointerExceptions
). InfoQ s'est intéressé au point de vue de ce Java Champion sur Java et a posé quelques questions à James Ward. Voici les réponses.
InfoQ : Quel est le rôle du Kotlin Product Manager chez Google ? Quelles sont vos responsabilités quotidiennes ?
James Ward : il y a deux facettes au travail de Kotlin PM. Je travaille avec nos équipes Android et JetBrains sur les améliorations et la croissance du langage Kotlin. Je travaille également avec de nombreuses équipes d'ingénieurs au sein de Google pour les aider à réussir leurs migrations côté serveur et Android de Java vers Kotlin.
InfoQ : Quel est l'état des langages sur la JVM en 2022 ?
James Ward : j'ai commencé à utiliser le langage de programmation Java il y a 25 ans et je pense que c'est toujours un excellent langage. Mais j'ai également pu travailler avec des langages sur la JVM plus modernes au cours des dix dernières années, notamment Scala et Kotlin. Scala est idéal pour les développeurs qui souhaitent pousser la programmation fonctionnelle à l'extrême. Kotlin est plus une étape incrémentielle pour les développeurs Java existants ayant un bon support pour certains paradigmes fonctionnels tels que l'immuabilité et les somme de types, mais manquant de certaines des fonctionnalités "monadiques" de Scala. Kotlin et Scala ont tous deux une grande interopérabilité avec Java, permettant le partage de l'écosystème. Les développeurs sur la JVM disposent de nombreuses options pour de grands langages et de nombreux chevauchements d'outils (outils de construction, IDE, outils de production/introspection, etc.). C'est formidable que sur la JVM, dans un grand écosystème, il y ait un tel éventail d'options linguistiques.
InfoQ : Combien de développements back-end sur la JVM ont lieu avec Kotlin actuellement ? Et comment pensez-vous que Kotlin pourrait devenir plus populaire dans ce secteur ?
James Ward : dans l'ensemble, la part de Kotlin sur des serveurs avec JVM est assez faible, mais elle augmente rapidement. Google, par exemple, a connu une croissance significative de l'utilisation de Kotlin pour le développement côté serveur. Les développeurs qui sont passés de Java ou qui viennent d'autres langages se disent très satisfaits de l'expérience. Null safety, les coroutines et l'expressivité sont souvent considérées comme des raisons importantes pour lesquelles Kotlin est plus productif et amusant à utiliser.
Kotlin continuera certainement à se développer côté serveur. Spring, Quarkus et Micronaut ont fait beaucoup de travail pour rendre leurs expériences Kotlin géniales (comme l'interopérabilité des coroutines pour Reactive). Les entreprises évoluent généralement assez lentement avec les nouvelles technologies. Pourtant, pour beaucoup, le passage à Kotlin (sur la JVM) est un changement beaucoup moins risqué et perturbateur que le passage à Rust (par exemple). De plus, l'interopérabilité de Kotlin avec Java permet aux migrations de code d'être incrémentielles au lieu de réécritures. De nombreuses équipes avec lesquelles j'ai travaillé ajoutent simplement du nouveau code dans Kotlin à une base de code Java existante.
InfoQ : Comment les langages sur la JVM se comparent-ils aux autres langages de programmation, en particulier dans le cloud ? Python et JavaScript sont plus populaires que Java dans une recherche Google et d'autres questions sur Stack Overflow.
James Ward : si je concevais un langage de programmation, mon objectif serait d'avoir moins de recherches et de questions posées sur mon langage. ;) Ayant été programmeur pendant plus de 30 ans, je penche plus vers les langages qui me permettent d'écrire du code plus "correct", testable et réutilisable. Je n'aime pas les surprises en production, et je veux pouvoir refactoriser sans crainte. Avoir un compilateur capable d'effectuer un haut niveau de validation sur mon programme est une fonctionnalité essentielle. Bien sûr, je ne serais peut-être pas capable d'écrire du code brut aussi vite que d'autres, mais j'écris du code qui est peu susceptible d'avoir des bugs en production. Si vous envisagez de corriger les bugs de production dans le cadre du cycle de développement, l'utilisation de langages modernes sur la JVM offre probablement la productivité la plus élevée possible pour de nombreux domaines problématiques.
InfoQ : GraalVM produit des applications Java natives qui démarrent plus rapidement et utilisent moins de mémoire. Comment cela affectera-t-il la position concurrentielle des langages sur la JVM dans le cloud ?
James Ward : le démarrage et la surcharge de mémoire ont définitivement entravé l'adoption des technologies sur la JVM dans certains espaces problématiques (serverless, CLI, opérateurs Kubernetes, etc.). GraalVM Native Image, Kotlin/Native et Scala Native aident à amener ces langages là où les langages généralement interprétés ou natifs convenaient mieux. Maintenant, nous pouvons avoir notre part du gâteau (démarrage rapide et surcharge de mémoire minimale) et le manger aussi (langages modernes de haut niveau). J'ai récemment créé un serveur avec la bibliothèque Kotlin Ktor, que je peux exécuter sur la JVM ou compiler en natif avec Kotlin/Native et GraalVM Native Image. Dans le cas natif, le temps de démarrage était d'environ 2 ms, l'utilisation de la mémoire était de 11 Mo et le binaire était compacté à 700 Ko. Pour de nombreux cas d'utilisation, nous n'avons plus besoin de faire des compromis entre les langages natifs et les langages modernes/de haut niveau.
InfoQ : Qu'est-ce qui rend Scala si attrayant pour vous ?
James Ward : Scala a une longue courbe d'apprentissage. Après plus de dix ans avec le langage, je me sens toujours comme un novice. Ce qui est formidable pour moi car j'aime apprendre de nouveaux langages de programmation et j'aime relever des défis. J'ai aussi vraiment adhéré à de nombreux principes de la programmation fonctionnelle, mais je ne les ai pas encore suivis jusqu'à Haskell, donc Scala est un bon endroit pour être un peu à l'aise avec la FP basée sur la JVM. Je suis actuellement en train d'écrire un livre avec Bruce Eckel et Bill Frasure sur la programmation orientée effets dans Scala 3 et ZIO 2. Les Effets Fonctionnels représentent un concept qui fait une différence significative dans la qualité des logiciels que nous créons mais qui n'est pas encore bien pris en charge par Java ou Kotlin. Il existe de nombreuses raisons de choisir Java ou Kotlin, mais des concepts tels que les Effets ne figurent pas sur cette liste.
InfoQ : Pour quelles applications ou problèmes Scala convient-il parfaitement ? Où pas du tout ?
James Ward : de nombreux facteurs déterminent l'adéquation de la technologie. J'ai récemment travaillé sur des projets où la structure de l'équipe impliquait que Java et Spring Boot étaient les mieux adaptés à l'environnement. L'un des facteurs les plus importants à "adapter" est la technologie que l'équipe souhaite utiliser. Je pense que cela correspond à mes objectifs de travail d'un Kotlin PM qui consistent à aider à faire de Kotlin une technologie que les développeurs souhaitent utiliser.
InfoQ : JetBrains affirme que Kotlin est un "meilleur Java", mais Java reste 5 à 12 fois plus populaire. Où voyez-vous le rôle de Kotlin aujourd'hui ? Et quel sera son rôle à l'avenir ?
James Ward : le langage Java a évolué au fil du temps. Mais comme le décrit l'architecte du langage (Brian Goetz), il a un "avantage au dernier arrivé", qui dans de nombreux cas est le bon choix. Si les startups vivent selon le slogan "avancer vite et casser les choses", alors les entreprises vivent selon le slogan "avancer lentement et ne rien casser", ce qui est assez cohérent avec l'évolution du langage Java au cours des 20 dernières années environ. Pour moi, j'aime aller plus vite que ne le permettent les organisations d'entreprise typiques (pour des raisons de conformité, de sécurité, de réglementation et autres). Alors oui, Kotlin est à certains égards un "meilleur Java", mais "meilleur" pour moi n'est peut-être pas "meilleur" pour tout le monde, et ce n'est pas grave. La JVM et Android prennent en charge à la fois Java et Kotlin - et c'est une bonne chose.
InfoQ : dans l'l'épisode 51 de votre Podcast Happy Path Programming, Bruce Eckel a parlé de "personnes qui sont encore piégées dans le monde Java" (vers 33:15). Vous étiez d'accord. Pouvez vous expliquer à nos lecteurs pourquoi vous et Bruce ressentez cela.
James Ward : il y a 25 ans, j'écrivais mon Java comme j'écrivais mon Perl. "Thinking in Java" de Bruce a transformé ma façon de penser à la programmation. Maintenant, Bruce et moi avons trouvé des paradigmes de programmation et des expériences qui ont eu le même effet, modifiant totalement notre façon de penser les choses. Bruce et moi n'avons pas connu ces chanboulements via Java (le langage) mais via d'autres langages. Je crois que ce que Bruce et moi mettions en évidence dans cet épisode n'était pas un coup contre Java (le langage) mais un espoir que les programmeurs apprennent continuellement et trouvent des moyens de se développer, tout comme Bruce et moi l'avons fait.
InfoQ : Comme décrit par Tony Hoare, les NullPointerExceptions
sont l'"erreur à un milliard de dollars." La null safety dans un langage est la solution. Kotlin l'a, et Dart et Swift ont même une sorte de null safety. Java ne l'a pas et ne semble pas obtenir la null safety de si tôt. Qu'en pensez-vous ?
James Ward : en Java, TOUT ce qui n'est pas une valeur primitive est nullable. Et cela nécessiterait une refonte massive de l'ensemble du langage et de la bibliothèque standard pour changer cela. De nombreux langages modernes ont un principe fondamental selon lequel la nullabilité doit être exprimée via le système de types. Il est simplement très difficile, voire impossible, d'y arriver plus tard. Comme décrit précédemment, mon objectif est d'écrire des programmes qui sont corrects de manière plus vérifiable au moment de la compilation, et la nullabilité explicite est une façon de le faire. L'une des raisons pour lesquelles je n'utilise plus beaucoup le langage Java est qu'il est difficile d'exprimer la nullité d'une manière vérifiée par le compilateur.
InfoQ : Vous avez dit que l'ajout d'une null safety est « très difficile, voire impossible, à mettre en place ultérieurement ». Google Dart y est parvenu en ajoutant une null safety pour les applications et les bibliothèques sept ans après la version 1.0. ;-) Quoi qu'il en soit, quel est votre conseil aux développeurs Java qui souhaitent avoir moins de NullPointerExceptions
?
James Ward : le plus difficile n'est pas la fonctionnalité dans le langage. C'est toutes les API. Selon le système de type, tout dans la bibliothèque standard Java et presque tout dans l'écosystème de la bibliothèque Java est nullable. Pour que la null safety soit utile et non gigantesque à gérer, tous les types sous-jacents doivent exprimer correctement leur nullabilité. C'est ce changement qui est très difficile ou impossible à faire.
InfoQ : Dans le même épisode "Happy Path Programming", vous avez appelé la mutabilité par défaut en Java "l'erreur à mille milliards de dollars" (vers 35:05). Pouvez vous expliquer pourquoi vous pensez que c'est le cas.
James Ward : j'ai été confronté trop de fois avec des problèmes de production où il était très difficile de comprendre la cause parce que je n'étais pas en mesure de "raisonner" sur le code en question. Vous voyez cela lorsque les gens publient le genre de puzzler "à quoi sert ce code" sur Twitter. La plupart du temps, c'est un puzzler parce que la mutabilité fait que mon cerveau simple ne peut pas raisonner sur ce qui se passe. Vous ne voyez jamais des gens publier les mêmes types de défis sous une forme purement immuable, car les valeurs immuables et les fonctions pures sont quelque chose que mon cerveau peut comprendre. Je suis certain que plus nos programmes peuvent être de fonctions et valeurs pures, moins il y aura de bugs dans ce que nous construisons.
InfoQ : Dans quelle mesure pensez-vous que la prise en charge des outils (tels que les IDE et les outils de compilation) est importante pour le succès d'un langage de programmation ?
James Ward : j'avais l'habitude d'écrire beaucoup de code sans l'aide d'un IDE (vim — battez-moi, s'il vous plaît), mais maintenant l'IDE est une partie essentielle de ma productivité. L'une des raisons pour lesquelles j'aime les langages de programmation avec d'excellents systèmes de type est que l'IDE fournit de bien meilleures indications lorsque j'écris du code. Lorsque je dois écrire du code dans des langages dynamiques, je me demande comment quelqu'un peut faire quoi que ce soit sans un million de recherches sur l'API de référence, car je ne peux rien faire sans que mon IDE complète toutes les options après les points.
InfoQ : En parlant d'outils : Visual Studio Code avait 14 millions d'utilisateurs en février 2021 et était le deuxième IDE le plus apprécié dans "l'enquête auprès des développeurs 2022" de Stack Overflow (neovim était numéro un). Supposons que Visual Studio Code devienne l'IDE gratuit par défaut pour tous les développeurs, prenant en charge tous les langages de programmation et frameworks pertinents. Comment cela changerait-il le développement logiciel ?
James Ward : VS Code est un excellent outil et, pour de nombreux développeurs, il représente un énorme pas en avant par rapport à "Sublime Text", vim ou emacs. Mais pour moi, c'est toujours nettement moins utile qu'IntelliJ (pour les trucs sur la JVM), surtout en ce qui concerne la refactorisation. Je ne l'utilise donc pas beaucoup, mais je comprends que c'est peut-être le meilleur éditeur de code que les développeurs aient utilisé (en supposant qu'ils ne les aient pas tous utilisés).
InfoQ : les compilateurs révèlent des erreurs de code. Analyseurs statiques, tels que Error Prone, Spotbugs, ou PMD, affichent encore plus d'erreurs, y compris les redoutables NullPointerExceptions
. Pourquoi ces analyseurs statiques ne sont-ils pas alors plus largement utilisés ?
James Ward : En général, j'aime garder ma chaîne d'outils aussi condensée que possible. Que ce soit pour des raisons de performances, de simplicité ou de collaboration, je préfère mettre autant de logique de validation que possible dans quelque chose que le compilateur peut valider (c'est-à-dire le système de type). Pour moi, les linters et les outils d'analyse de code statique sont le signe de quelque chose qui devrait juste être validé dans le compilateur. Pourtant, il y a probablement des contraintes linguistiques qui empêchent cela. Ces outils sont bons pour améliorer la qualité du code, mais aussi un signal fort aux concepteurs de langages sur ce qu'ils devraient essayer de passer de la méta-programmation à la simple programmation.
InfoQ : Vous avez dit que vous "préférez mettre autant de logique de validation que possible dans quelque chose que le compilateur peut valider". Le compilateur Java ne valide pas la null safety, les branches else
vides, etc. Mais les analyseurs statiques comme Error Prone de Google le font. Comment voyez-vous les avantages de l'ajout de ces analyseurs à Java par rapport aux inconvénients de compliquer votre chaîne d'outils ?
James Ward : les linters et autres outils d'analyse de code statique expriment des limitations avec le système de type et les vérifications du compilateur. Ces limitations existeront toujours, donc les outils ne disparaîtront pas de si tôt. Mais j'espère qu'ils aideront les modèles de programmation et les compilateurs à évoluer, couvrant davantage de choses possibles au fil du temps.
InfoQ : le framework d'interface utilisateur multiplateforme de Google Flutter prend moins d'une seconde pour compiler une modification et mettre à jour l'application. Pourquoi la compilation et la mise à jour des applications JVM sont-elles toujours aussi lentes ?
James Ward : plus un compilateur en fait pour valider l'exactitude de quelque chose, plus cela prendra de temps. Je ne connais aucun moyen de contourner cela. Je peux faire une compilation zéro sur quelque chose, l'exécuter en production, puis obtenir des erreurs d'exécution en conséquence. Ce n'est pas la façon dont je veux développer des logiciels. Donc, pour moi, les jugements sur le temps de compilation doivent être équilibrés avec la valeur du compilateur. Cependant, j'exécute souvent des compilateurs Java, Kotlin et Scala de manière incrémentielle avec un rechargement à chaud en moins d'une seconde (merci, bonne mise en cache). Ce débat doit passer à "combien de temps faut-il pour arriver à corriger ou sans bug" au lieu de "combien de temps faut-il pour obtenir quelque chose avec une quantité indéterminée de pannes en production."
InfoQ : Dans mon projet Spring Boot, les échecs fréquents de rechargement de classe annulent ma vitesse de compilation rapide. Et en ce qui concerne votre commentaire "obtenir quelque chose avec une quantité indéterminée de rupture en production" : je pense que la complexité de la compilation pour Dart (le langage de Flutter) peut être dans le jiron de base de Java. Pourtant, Flutter se recompile et se redéploie sur mobile en une seconde la plupart du temps. La plupart des projets Java ne le font pas. Désormais, Flutter possède toute sa chaîne d'outils (langage, compilateur, runtime, framework et outil de construction). Java ne le fait pas (par exemple, outil de construction et framework applicatif). Pour la productivité des développeurs, dans quelle mesure est-il important que les langages sur la JVM possèdent l'intégralité de leurs chaînes d'outils ?
James Ward : rien n'empêche des temps de cycle de développement interne similaires sur la JVM d'être aussi rapides. Une nouvelle fonctionnalité d'Android Studio appelée Live Edit met à jour presque instantanément l'interface utilisateur pour les applications Jetpack Compose, basées sur un changement de code, dans un émulateur ou sur un appareil. Play Framework avait des rechargements de serveur inférieurs à la seconde sur la JVM il y a dix ans, en utilisant quelques astuces de classloader sophistiquées. Le défi consiste principalement à investir du temps d'ingénierie pour rendre cette expérience rapide et géniale. Mais pour une raison quelconque, cela n'a pas été une grande priorité dans l'écosystème JVM. Pour les frameworks de serveur, Quarkus a fait le meilleur travail d'optimisation, et je suis sûr qu'ils pourraient encore faire plus.
InfoQ : Comment définiriez-vous et mesureriez-vous le succès d'un langage de programmation ? Par exemple, vous pourriez dire que Scala est un succès car il a rendu la programmation fonctionnelle plus courante. Vous pourriez également dire que Scala ne réussit plus parce qu'il a perdu la deuxième place du langage JVM au profit de Kotlin.
James Ward : les objectifs sont importants, et chacun a des objectifs différents. Pour moi, c'est une question d'alignement des valeurs. J'apprécie vraiment que le langage de programmation Flix ait écrit ses objectifs/principes.
Flix est un langage de programmation incroyablement réussi car il a fait un travail incroyable en réalisant ses objectifs. Si Flix se fixait pour objectif d'avoir 10 millions de développeurs actifs, ils échoueraient certainement sur celui-là (mais j'aimerais quand même parce que je suis d'accord avec les principes du langage). Aimer un langagee est différent du succès d'une langue. En tant que PM Kotlin, l'un de mes objectifs pour le langage est de permettre aux développeurs de créer plus facilement des logiciels corrects (c'est-à-dire moins de bugs en production). Il a déjà été démontré que le langage réduit les plantages d'applications Android de 20 %, ce qui est un grand succès. J'aimerais aller plus loin et continuer à aider à réduire les erreurs côté application et côté serveur grâce à des améliorations du langage et des outils.
InfoQ : L'histoire du développement de logiciels est une histoire de niveaux accrus d'abstractions. Mais des innovations comme l'orientation objet et la programmation fonctionnelle ont plus de 50 ans. Comment pensez-vous que le niveau d'abstraction a augmenté au cours des 20 dernières années ? Et comment le voyez-vous augmenter dans les 20 prochaines années ?
James Ward : Jusqu'à récemment, de nombreuses idées issues de la programmation fonctionnelle étaient cantonnées dans des technologies destinées aux passionnés de mathématiques (dont j'aspire à faire partie un jour). Maintenant, grâce à Scala (et à d'autres), nous commençons à voir une fusion de OO et FP qui rend FP accessible aux masses qui ne sont peut-être pas des geeks en mathématiques. Cette fusion continuera à se dérouler pendant un certain temps, contribuant à rendre notre code plus testable et réutilisable. Kotlin en est un excellent exemple, étant un pont pour de nombreux développeurs Java OO vers "lite-FP", qui ne nécessite pas de diplôme en théorie des catégories. La prochaine phase de cette transition comprendra l'adoption de l'idée des "Effets" (séparer les fonctions pures des petites parties qui parlent au monde extérieur / ne sont pas référentiellement transparentes). De nombreux nouveaux langages de programmation ont déjà ce concept intégré : Flix, Unison, Roc, etc. Au-delà des effets, un concept que nous verrons probablement émerger est quelque chose comme Datalog - un langage de requête intégré au langage à usage général. J'ai d'abord vu cette idée avec Linq, puis avec Flix. Les requêtes sont un besoin assez universel, que ce soit pour les bases de données, les lenses (mise à jour de structures de données immuables), GraphQL, etc. Avoir un moyen intégré et vérifié par le compilateur d'écrire des requêtes est donc un avantage significatif.
InfoQ : Quel langage de programmation a le mieux évolué ?
James Ward : cela dépend certainement de la définition de "meilleur". Si nous considérons cela d'un point de vue purement académique, je pense que par plusieurs ordres de grandeur, Scala a reçu plus de recherches doctorales que n'importe quelle langage que je connais. De nombreuses fonctionnalités du langage Scala se retrouvent dans d'autres langues, ce qui est idéal pour tout le monde. Python a fait un travail incroyable en étant un langage généralement accessible. J'ai entendu dire que de nombreux professionnels orientés données ne peuvent pas résoudre la plupart des problèmes de programmation typiques, mais peuvent écrire le code Python qui représente un algorithme mathématique complexe ou traite un ensemble de données volumineux à l'aide de bibliothèques telles que Pandas, NumPy, etc. Kotlin est un langage moderne avec l'interopérabilité Java et la capacité multiplateforme. Donc, ce qui est "meilleur" dépend de nombreux facteurs.
InfoQ : Quelle fonctionnalité à venir d'un langage sur la JVM vous passionne le plus ?
James Ward : Du côté de la JVM, Loom change la donne. Pour la plupart des développeurs Java / JVM, La programmation "Réactive" a été une bonne idée mais ne vaut pas la surcharge cognitive et de complexité. Les Coroutines de Kotlin ont permis une idée similaire de coût cognitif nul pour les opérations asynchrones qui semblent impératives. Pourtant, pour de nombreux développeurs sur la JVM, la programmation réactive restera probablement une fonctionnalité "agréable" jusqu'à ce que Loom soit disponible dans leur organisation. Compte tenu de ce délai, de nombreux développeurs sur la JVM utiliseront des abstractions de concurrence comme Kotlin Coroutines et Scala ZIO Effects sur le JDK 8 avant cela. Compte tenu des défis liés au calendrier de Loom et de la disponibilité actuelle d'alternatives, je dois dire que la fonctionnalité à venir qui me passionne le plus dans n'importe quel langage sur la JVM est la syntaxe sans accolades de Scala qui est à moitié présente dans Scala 3.0 et peut atteindre son achèvement dans Scala 3.3. J'aime le peu de bruit visuel qu'il y a dans mon code par rapport au problème que je résous. Je sais que cela semble idiot que le simple fait de retirer les accolades puisse avoir un tel impact. Mais Python nous montre que les surcoûts cognitifs peuvent généralement être le coût le plus élevé dans la plupart des organisations. La partie la plus difficile/la plus coûteuse de l'écriture d'un programme correct n'est pas la transformation du texte en bytecode/code machine. C'est le coût de la représentation et de la lecture correctes des idées humaines sous une forme compréhensible par les ordinateurs. Cela semble idiot, mais les accolades dans la plupart des codes détournent mon cerveau de l'intention humaine du code.
InfoQ : Si vous pouviez apporter un changement à chaque langage sur la JVM, quels seraient ces changements ?
James Ward : Java : il y a beaucoup de changements que j'aimerais apporter, et cela ressemble à un acte d'accusation. Mais ce n'est pas parce que sur la JVM, on peut soit choisir un autre langage, soit accepter que les choses avancent lentement, et c'est tant mieux. Si je devais choisir une chose à changer, ce serait probablement un meilleur support pour l'immuabilité. La mutabilité par défaut est une recette pour les programmes non déterministes.
Kotlin : lorsque je programme en Kotlin, ce qui me manque le plus de Scala, c'est une belle syntaxe pour le chaînage monadique (appelée "do notation" en Haskell et la compréhension for en Scala). Comme les coroutines Kotlin, cela donne l'impression que le code est impératif alors qu'il s'agit en réalité d'appels de fonction chaînés. Je n'ai aucune idée de comment ce genre de chose devrait être ajouté à Kotlin, mais si c'est bien fait, je pense que ce serait génial.
Scala : la chose la plus difficile à propos de Scala est qu'il existe de nombreuses façons de faire à peu près la même chose. Par exemple, il existe au moins trois façons dans Scala 3 de faire quelque chose qui est essentiellement une somme de type (sealed, enum et OR logique). Je ne sais pas comment vous enlevez des choses dans un langage de programmation. Pourtant, la complexité de Scala est un problème, et avoir plusieurs façons de faire la plupart des choses est un problème pour le langage.
InfoQ : COBOL a plus de 60 ans et est toujours utilisé activement. Pensez-vous que les développeurs écriront encore de nouvelles applications Java lorsque Java aura 60 ans en 2056 ?
James Ward : Bien sûr ! Java est un élément essentiel de tant de systèmes que nous utilisons tous les jours. Il ne disparaît pas et, avec des améliorations lentes mais progressives, il continue de s'améliorer (contrairement à COBOL). L'écosystème Java plus large (y compris Kotlin, Scala, Clojure, Groovy, etc.) continue également de croître. Dans son ensemble, il s'agit probablement du plus grand écosystème de développeurs au monde. De nouveaux langages sur la JVM continuent d'émerger comme Flix, montrant que le cycle de l'innovation ne s'arrête pas de sitôt. Des technologies innovantes et révolutionnaires telles que Testcontainers, GraalVM et Kalix continuent d'émerger de l'écosystème Java, illustrant la force de continuer à croître et à s'améliorer pendant encore 35 ans (au moins).
InfoQ : Pouvez vous partager vos dernières réflexions sur les langages JVM en 2022.
James Ward : C'est une période passionnante pour travailler avec Java, Kotlin et Scala ! Les outils et les langages permettent la productivité de développeur la plus élevée que j'aie jamais connue. Des téléphones aux serveurs, les technologies Java sont à l'origine de la grande majorité des systèmes critiques que nous utilisons au quotidien. Et pour moi, c'est tellement agréable de pouvoir choisir parmi de nombreux langages différents sur une seule plate-forme.
InfoQ : James, nous vous remercions pour cette interview.
Conclusion
James Ward a bien expliqué les remarques du podcast : quand Bruce Eckel a parlé de "personnes qui sont encore piégées dans le monde Java", il faisait référence aux développeurs utilisant ce que lui et James considèrent comme d'anciens paradigmes en Java, tels que la programmation procédurale et orientée objet. En revanche, Bruce Eckel et James Ward ont adopté des concepts de programmation fonctionnelle dans Scala qui ne sont pas disponibles dans le langage Java. Et le code mutable rend plus difficile pour Ward de raisonner sur ce code et produit finalement plus de bugs, contrairement aux fonctions et valeurs pures qui sont immuables.