Je pensais avoir déjà abordé le sujet sur le forum, mais après une rapide petite recherche, il semble qu'aucun message ne contienne "Kotlin" en ces lieux

Je suppose qu'une bonne partie d'entre vous connait Kotlin, au moins de nom ? Pour la petite piqure de rappel : il s'agit d'un langage bâti sur Java, développé et intégré par les développeurs à la base de l'excellent IntelliJ (un IDE pour Java, une sorte de concurrent sérieux à Eclipse, NetBeans, etc.).

Je m'y suis intéressé il y a un peu plus d'un an, quand j'avais voulu me remettre à Java (parce que j'avais besoin d'un support pour du typage statique, chose dont je ne dispose pas dans Python, et d'une approche OO très rigide - chose dont je ne dispose pas non plus dans Python ). Depuis, le langage a encore évolué et il est sorti en version 1 il y a à peine quelques mois.

Dans les grandes lignes, Kotlin modifie la syntaxe de Java pour autoriser tout un tas de trucs et contourner tout un tas de problèmes (à commencer par le classique null-safety-check, les fonctions d'ordre supérieur, etc.). Il est parfaitement intégrable à Java (dans les deux sens). Par contre, si tout le monde semble vanter sa syntaxe "élégante et concise", j'ai toujours du mal à lire du code Kotlin à cause du nombre important de constructions possibles avec une même et unique syntaxe. Mais bon, je n'ai pas été bien loin dans mes tentatives pour surmonter ça.


Si je fais un topic, c'est surtout pour savoir s'il y en a parmi vous qui ont une expérience avec Kotlin, ou connaissance de quelqu'un ayant une expérience en Kotlin, et qui pourrait faire un petit retour à ce sujet. Notamment, est-ce que ça rend "vraiment" la programmation plus agréable (pas dur ) qu'en Java, plus simple (surtout dans les cas où on manipule du "vrai" Java derrière, est-ce que ça change quelque chose ?) et le code plus élégant ?

De ce que je lis à gauche et à droite, il y a de plus en plus de boîtes qui sont parties vers ce langage et les retours semblent enthousiastes, mais je n'ai pas l'impression que ça change "fondamentalement" les choses, on finit de toute façon par concevoir des classes à tout va, avec 50 couches pour faire une opération (parce qu'il faut un Builder, 2 Factory, 3 interfaces et une douzaine de classes abstraites, une bonne dose d'annotations et de design pattern, ...)

Pour ceux qui désirent en savoir un peu plus :
objectpartners.com/2016/…

Je reste mitigé sur la syntaxe, par contre

C'est quoi Java?
Ca existe encore?

Ça doit encore être le langage le plus utilisé, non ? C#, et .net en général, sont trop ancrés Windows pour percer pereinement comme "langage universel".

J'en avais entendu parler. Le truc qui me botte vraiment c'est l'opérateur Elvis, hérité de Groovy (l'opérateur ?.)
Je trouve ça tellement pénible quand on doit gérer une grande série de getter (toto.getProfil().getLocalisation().getVille().getCodePostal()) de devoir vérifier la nullité des propriétés à chaque niveau. Et de tomber sur des NullPointerException en production parce qu'une vérification à été oublié.

C'est un problème majeur en Java et Kotlin visiblement l'adresse, ce qui est plutôt bon signe.
Moi, le monde Java m'ennuie un peu en ce moment et je m'essaye à ES6 ou Node sous Visual studio code. Un truc que j'aime vraiment en JS c'est de pouvoir créer un objet anonyme à la volée. C'est ce que j'aimerais pouvoir faire en Java.

La gestion des null par Kotlin est certainement le premier argument que l'on retrouve dans les présentations à propos de Kotlin. Je n'ai pas un énorme background en Java (je n'ai d'ailleurs pas touché à Java depuis au moins 3 ou 4 ans), mais les chaines d'appels que tu donnes en exemple est quelque chose de finalement très courant en Java, et la possibilité de pouvoir stopper les appels en cas de null (x?.getMachin()?.getBidule()?.getTruc()) est vraiment pratique.

L'opérateur Elvis, c'est surtout pour un test ternaire implicite. Dans le cas de ces longues chaines, cela permet de retourner autre chose que null : x?.getMachin().?getBidule()?: 1 (si un élément est null, la ligne retourne 1 au lieu de null)).

J'avoue que, parfois, j'aimerai avoir une construction identique en Python... On utilise couramment getattr(x, 'y', 1) pour un check implicite, mais ce n'est pas pareil (notamment parce que ça marche pas trop avec les callables, et que ça ne se chaîne pas facilement). Roidelapluie a peut-être une idée ?

Il y avait une PEP (Python Enhancement Proposal) en lien avec ce genre de choses, et qui suggérait d'étendre la syntaxe x = a if b else c aux exceptions : x = try a else b dont la sémantique est : essaie d'exécuter a et en cas d'exception, passe à b. Malheureusement, ça a été rejeté (car ça ajoute encore un élément syntaxique supplémentaire). Au final, je ne sais pas trop comment on peut checker facilement a().b().c().d() en Python sans encadrer le tout d'un try ... except).