Pourquoi Kotlin est génial, mais vous resterez quand même avec Java

Quel que soit le groupe auquel vous appartenez, il y a une raison pour laquelle vous restez avec Java. Et je ne vous blâme pas. Elle possède sans doute l'écosystème le plus développé, le plus universel et le plus complet de toute l'Europe. entreprise monde. Le langage dispose d'un ensemble de fonctionnalités bien adaptées, quelque part dans la bonne zone entre le trop et le pas assez. De plus, de nouvelles fonctionnalités sont ajoutées lentement mais régulièrement, ce qui lui permet de rester à jour par rapport aux nouvelles tendances du monde de la programmation.

Connaissez-vous Lombok mais ? Si ce n'est pas le cas, je vous recommande vivement d'essayer. Si vous l'aimez, j'ai quelque chose à vous proposer. Un tout nouveau langage qui, par ses caractéristiques, rend le lombok obsolète. Il s'appelle Kotlin.

Kotlin ? Vous voulez dire le langage Android ?

Kotlin sur Android a été béni par Google lui-même au point de devenir le langage de choix de facto pour la plateforme. Ce n'est pas l'objet de cet article, mais c'est bien sur Android que j'ai rencontré Kotlin pour la première fois.

Mon collègue de travail était en train de développer une application pour une projetIl s'est débrouillé tout seul. Les échéances approchaient à grands pas et j'ai donc été chargé de l'aider à les respecter. Permettez-moi de remonter le temps jusqu'à ce moment-là. Aaaand... YUCK ! Pourquoi utilise-t-il un langage bizarre qui ressemble à un marque de ketchup! ? C'est affreux !

Pourquoi le mot "fun" est-il écrit avant chaque fonction ? Comme si je ne savais pas déjà ce que c'est. De plus, j'ai déjà amusant avec Java Quoi qu'il en soit. Et où se trouve le type de retour ? À la fin ? Tu es fou ? Qu'est-ce que c'est, vous assignez quelque chose à une fonction ? Cela n'a aucun sens ! Tout cela ressemble à Java avec des étapes supplémentaires ! Attendez, où est la classe à laquelle appartient cette méthode ? Où l'as-tu cachée, espèce de ketchup, Java imitation d'un langage de programmation ? Oh non. Oh non, vous ne l'avez pas fait. C'EST UNE FONCTION GLOBALE ? C'est ça, j'ai fini, j'appelle la police.

Alerte au spoiler : je n'ai pas appelé les forces de l'ordre. Que cela me plaise ou non, j'ai dû adapter ma mentalité centrée sur Java pour m'adapter à un autre langage. Mais ce n'est pas si grave, n'est-ce pas ? Il s'agit toujours d'un langage JVM, c'est sûrement juste un langage différent. Java. Peut-être même avec des fonctions supplémentaires intéressantes ? À contrecœur, j'ai commencé à travailler sur le projet.

Java avec étapes supplémentaires

Si Java est si génial, pourquoi n'y a-t-il pas de Java 2 ? Blague à part, c'est ce que je me suis dit. Je vais faire comme si Kotlin était Java 2. Une nouvelle syntaxe et tout le reste, mais il faut juste que j'en apprenne assez pour terminer le projet. J'avais tort.

Après l'avoir essayé pendant un jour ou deux, je me suis rapidement rendu compte que Kotlin et Java ne sont pas très élastiques. Essayer de les plier l'un vers l'autre aboutit inévitablement à ce que l'un d'entre eux se brise en deux. Il est devenu évident que Kotlin est une chose à part, et que le fait qu'il fonctionne sur une JVM ne signifie presque rien du point de vue du programmeur. (Pour l'anecdote, Kotlin peut aussi transpiler en JavaScriptou être compilé en un binaire natif).

Plan B alors. En fait, apprenez à connaître le langage. La lecture de la documentation pour la première fois donne des frissons à un programmeur Java chevronné. Par exemple :
- le niveau supérieur mentionné plus haut, c'est-à-dire le contexte global
- les types de paramètres et de retours de fonctions spécifiés à la fin

fun sum(a : Int, b : Int) : Int {
   return a + b
}

le corps de la fonction peut être une expression (en utilisant le signe d'égalité)

 fun sum(a : Int, b : Int) = a + b

l'énoncé "if" peut fournir un résultat

 val y = if (x == 1) {
 "un"
 } else if (x == 2) {
 "deux"
 } else {
 "autre"
 }

Ok, je vais devoir m'y habituer. C'est juste une syntaxe différente. Qu'avez-vous d'autre à offrir, monsieur Kotlin ?

 value ?.method() // exécuter si non nul

Oh ok, se débarrasser de si (valeur == null)un point pour vous. Qu'avez-vous d'autre ?

fun check(list : List, alternative : Boolean) = when {
 list is LinkedList -> print("linked")
 alternative -> print("alternative")
 list.size > 50 -> print("big")
 else -> print("other")
 }

Hmm sympa, ça pourrait être pratique pour éviter les blocages, mais ça reste un gadget.

 object SingularObject : Counter() {
 var a = 14
 fun test() = if (a > 10) "plus" else "moins"
 }

Ok, celui-là a l'air vraiment utile, je l'aime bien ! D'un autre côté, je peux aussi créer un singleton en Java. Ce ne sera peut-être pas aussi élégant, mais ce n'est pas vraiment nouveau. Vous avez des atouts dans votre manche ? De vrais poids lourds ?

 var s : String = null // ne compile pas, type non nul

Attendez... quoi ?

L'erreur d'un milliard de dollars

Imaginez une base de code dans laquelle vous n'avez pas besoin de vous préoccuper de la sécurité des nullités. Imaginez que vous preniez pour acquis que chaque référence contient réellement quelque chose de significatif. Imaginez que vous soyez sûr que chaque problème lié à la nullité est traité à l'avance.
N'imaginez plus rien. Toutes les références en Kotlin ne sont pas nullables par défaut. Si vous voulez les rendre nullables, vous devez consciemment prendre cette décision, et explicitement l'énoncer dans le code:

 var s : String ? = null

Je comprends que vous puissiez être sceptique quant à cette idée à ce stade. Vous avez l'habitude des références nullables. Vous les gardez à l'esprit lorsque vous codez. Vous avez appris où vous devez être prudent. C'est exactement ce que je pense. Venant de JavaAu début, cela m'a semblé bizarre. Quel est l'intérêt ? Cela ne va pas faire disparaître comme par magie tous les problèmes qui y sont liés. Je vais devoir ajouter des " ?" partout, ce qui semble être une corvée.

Mais j'ai décidé de me plonger dans la langue, n'est-ce pas ? C'est à vous de jouer, monsieur Kotlin. J'ai commencé à m'efforcer d'éliminer autant de variables, de champs et de paramètres nullables que possible. Petit à petit, j'ai appris à utiliser les caractéristiques du langage qui facilitaient l'élimination des références nullables, par exemple l'opérateur safe call " ?.", l'opérateur elvis "? :", les propriétés déléguées, la méthode "let", et bien d'autres encore.

Au fil du temps, j'ai réussi à faire en sorte que certaines classes ne contiennent que des champs et des paramètres de méthode non nuls. En fait, je savais que si une classe était instanciée avec succès, je pouvais presque oublier la nullité dans le corps des méthodes. C'était un vrai bonheur. Avec le temps, je l'ai apprécié de plus en plus. En fin de compte, je ne l'ai pas considéré comme une fonction essentielle, Java se sentait encore chez lui. Jusqu'à ce que...

Le retour

Le projet touchait à sa fin. J'ai appris à connaître Kotlin de plus en plus, et grâce à ces connaissances, le code est devenu de plus en plus ordonné, lisible et concis. Les améliorations étaient visibles à l'œil nu dans l'historique des livraisons. Le moment est enfin venu. Avec des souvenirs inattendus du nouveau langage, il était temps de dire au revoir et de retourner dans la douce zone de confort de Java. C'est du moins ce que je pensais.

Connaissez-vous ce sentiment lorsque vous commencez à apprécier quelque chose au moment même où il disparaît ? Quand vous ne réalisez pas à quel point vous dépendez de quelque chose jusqu'à ce que vous ne puissiez plus l'utiliser ? C'est le meilleur exemple de ce sentiment que j'ai probablement connu dans ma vie.

Lorsque j'ai recommencé à écrire le code dans JavaJ'étais presque terrifié par l'absence de certaines fonctionnalités. C'était comme si mon cerveau avait inconsciemment et à tort réadapté les fonctionnalités de Kotlin à Java. J'ai vécu des situations où j'ai commencé à implémenter quelque chose pour me rendre compte que cela ne fonctionnerait pas dans ce langage. Dans le meilleur des cas, je pourrais l'écrire à la manière de Kotlin, mais ce serait encombrant, illisible et/ou nécessiterait trop de gabarits.

La sécurité contre les nullités était bien sûr la caractéristique qui me manquait le plus. Mais j'ai été surpris par le nombre de petites choses qui sont devenues naturelles pour moi : les paramètres nommés, les propriétés au lieu des getters et setters, "==" comme égalité et "===" comme égalité référentielle, "this" qualifié, les fonctions d'extension, le paramètre lambda singulier implicite, "_" pour les paramètres lambda non utilisés, les classes de données, les fonctions scope, les autres fonctions stdlib de Kotlin, les opérateurs et bien plus encore. Et la façon dont tout cela s'imbrique agréablement. En comparaison, Java semblait... primitif.

En fait, je me sentais tellement mal que j'ai commencé à envisager de passer complètement à Kotlin. Théoriquement, il est totalement interopérable avec Java, il suffit d'ajouter le support Kotlin à un projet existant et de commencer à écrire de nouvelles classes. Le côté Kotlin sait comment "parler" à Java, et le côté Java ne sait même pas qu'il "parle" avec un autre langage. Et après la compilation en bytecode, cela ne fait pas vraiment de différence pour la JVM.

L'épreuve de vérité

Qu'attendez-vous donc ? Si le langage est aussi bon que vous le dites, utilisez-le ! Peut-être pas dans les projets existants cependant, je sais qu'il devrait être interopérable, mais mélanger deux langages différents de cette façon semble moche.

Ok, donc pour les nouveaux modules - c'est Kotlin. Ou bien est-ce le cas ? Vous travaillez dans un équipe. Vous devez les consulter et les convaincre de la grandeur de cette nouvelle langue. Qu'est-ce que cela signifie ? Ils ne l'aiment pas ? On dirait qu'ils ne veulent pas faire l'effort de l'apprendre. Vous ne pouvez pas leur en vouloir, vous étiez vous aussi sceptique au début.

Le chef de projet ! Oui ! Il comprendra sûrement la grande valeur que Kotlin apportera à notre équipe. Oh, la grandeur qui vient !
-Non
-Attendez, pourquoi ?
-L'équipe ne le sait pas.
-Ils apprendront !
-Ils ne veulent pas apprendre.
-Vous pouvez les faire !
-Ils n'ont pas besoin d'apprendre.
-C'est vrai, mais pensez aux possibilités !
-Oui, et si vous pensiez d'abord aux problèmes ?

La légende dit qu'il existe un projet. Un projet qui est grand et complexe, mais qui est bien écrit dans toutes ses parties. Un projet où tous les développeurs sont à l'unisson sur les solutions utilisées. Où les nouvelles fonctionnalités sortent tout naturellement des claviers des programmeurs. Où les bogues sont rares et faciles à corriger.

Avez-vous déjà vu un tel projet ? Je n'en ai pas vu. Certains s'en sont approchés, mais la plupart d'entre eux sont un énorme gâchis de code hérité. Et s'ils ne le sont pas, ils le deviendront probablement à un moment ou à un autre. Imaginez maintenant que l'on ajoute un autre langage au mélange. Il introduit de nouvelles façons de commettre des erreurs. Les développeurs doivent savoir ce qu'ils font. C'est un risque, c'est le moins que l'on puisse dire.

Il faut également tenir compte de la rotation des développeurs. Les gens vont et viennent. Allez-vous demander à chaque nouveau développeur d'apprendre un tout nouveau langage ? Non, c'est contre-productif. Allez-vous embaucher des développeurs Kotlin dès le départ ? Bonne chance, embaucher un bon développeur Java est déjà assez difficile.

Des gens ont essayé. Je dois dire que je ne suis pas d'accord avec la plupart des allégations de cet article. Il y a des critiques valables, mais je pense qu'ils n'ont pas assez utilisé Kotlin pour comprendre "la manière Kotlin". De nombreux commentateurs de cet article semblent penser la même chose.

Mais cela n'a pas d'importance. Je parie que cela se produirait également dans votre projet. "J'ai essayé, je n'ai pas aimé". Vous ne leur ferez pas passer plus de temps dessus. Vous ne les obligerez pas à réessayer. Vous ne l'obligerez pas à donner une autre chance. Et d'un point de vue pratique, ils ont peut-être raison. Java est tellement populaire que toute autre utilisation de la JVM semble superflue.

Pourquoi cet article alors ?

Vous venez de passer un temps considérable à écrire un article qui semble n'avoir aucun intérêt. Pourquoi essaierais-je d'apprendre une langue, si vous dites que c'est inutile de toute façon ?

Je ne pense pas que ce soit inutile. Je pense toujours que Kotlin est génial. J'ai toujours envie de l'utiliser (et c'est d'ailleurs ce que je fais pour mes projets privés). Si je le pouvais, je passerais à Kotlin et j'oublierais les limitations de Java. Mais la réalité actuelle dit que je ne peux pas. Et je veux essayer de changer cela.

Mon intention pour vous, cher lecteur, est d'envisager au moins la possibilité de sortir de la zone de confort confortable de Java. Car peut-être, juste peut-être, aimerez-vous Kotlin autant que moi. Et si c'est le cas, cela fera un développeur connaissant Kotlin de plus sur le site Web de l marché.

En savoir plus :

Le meilleur type de projets pour Java

3 défis communs au développement de produits logiciels pour les startups

La bonne façon de trouver les meilleurs développeurs Java