Je précise déjà que je ne t'attaquais pas personnellement, je précisais juste que je doute qu'un programmeur soit par nature fainéant et que ce soit ça qui motive son désir de changer ou non de langage: Surtout quand on voit à quelle vitesse l'informatique change, moi j'ai commencé en 1980. Sinon on peut trouver l'excuse de la paresse pour n'importe quel point de vue, c'est ce que j'ai voulu montrer.C'est le côté "changer pour changer" qui m'embête... et encore... si un client voulait une application en ADA, je l'apprendrais volontiers
Changer pour changer, c'est logique que ça t'embête, mais le fait est que Kotlin apporte un grand plus au niveau rigueur de programmation (notamment avec les nullables), du moins pour les versions antérieures de Java, qui sont celles utilisées dans Android (j'ai répondu au sondage posté dans le forum "Android"). En outre c'est un langage très agréable à utiliser (c'est un C# en mieux). Sa syntaxe est plus "moderne" que Java et moins permissive. Les infix permettent d'étendre le langage à sa convenance (comme linq de C# mais en plus puissant et en paramétrable) et apportent des mécanismes très utiles dans Android, comme les déclarations tardives (mais c'est évidemment un avantage spécifique à la façon dont Android travaille).
C'est un choix qui en vaut un autre, mais, personnellement, j'ai peu développé en Java (je ne fais pas de web) car je travaille beaucoup en bas niveau sur microcontrôleurs et en C# sous Windows, mon domaine étant principalement la communication entre des logiciels embarqués et des PC. Je n'utilise Java que pour Android et là j'ai vu de suite l'intérêt de Kotlin et le gain de confort. Le tout sans rien perdre puisque Kotlin produit au final du byte-code Java et donc les librairies Java restent fonctionnelles, sachant qu'on peut même mélanger du code java avec du code Kotlin dans la même application. Il y a même un copié/collé dans Android Studio qui permet de copier un code Java et de le coller en Kotlin, avec conversion automatique.Moi, je préfère "perdre mon temps" à approfondir mes connaissances sur des technologies éprouvées (comme JEE)
En outre, Kotlin n'est pas "un langage" parmi d'autre, c'est un des deux langages officiels reconnus par Google pour Android: Il est intégré nativement à Android Studio. Et donc, pour Android c'est un maître choix parfaitement justifié. Sans compter que (j'ignore si c'est déjà opérationnel) Kotlin est prévu pour générer du code compatible i-pad et même du code natif en direct.
Bref, pour Android, je pense que la migration est le bon choix, à partir du moment où on n'est pas contraint de conserver Java (boulot etc).
Pour du développement autre qu'Android, je n'ai pas d'avis, mais, comme je le précisais, ce sondage a été publié dans la section "Android", j'ai donc répondu sur cette base.
Pour ne prendre que trois exemples simples:En quoi Kotlin permet de détecter plus d'erreurs que Java à la compilation ?
- La gestion des nullables: Si tu acceptes la valeur "null" pour une variable, alors tu ne peux pas accéder à ses propriétés sans tester "null". Il y a des syntaxes explicites pour t'éviter de le faire MAIS qui n'entraînent pas un plantage de l'application, et en outre tu peux chaîner les syntaxes. Par exemple si tu as un nom "name" qui peut être null, alors il t'est interdit de demander "name.lenght" par exemple: C'est refusé à la compilation et donc tu n'auras pas une erreur "pointeur null" à l'exécution. Mieux, si tu as un pointeur pouvant être null qui pointe sur une fonction pouvant renvoyer null, elle-même utilisant la valeur de retour pour une troisième fonction, tu peux tout écrire sans jamais tester les "null" explicitement (pas de if null à perte de vue) tout en conservant l'impossibilité de plantage en cas de valeur null. Et, évidemment, il t'est impossible de compiler le code si tu n'as pas utilisé cette syntaxe sécuritaire ou que tu n'as pas testé "null" à chaque étape. En Java le moindre oubli et c'est plantage à l'exécution.
- La gestion des lazy et autres méthodes de déclarations tardives. Si tu déclares des variables globales, par exemple, et que tu ignores leur valeur définitive plus loin dans le code (exemple simple: tu définis une variable "monBouton" qui devra pointer sur un contrôle "button"). Alors en Java tu dois initialiser monBouton à "null" et ensuite soit devoir faire des tests partout pour vérifier que c'est non nul, soit prendre le risque d'utiliser sans tester (risque de pointeur nullable). En Kotlin tu peux déclarer ta valeur globale en lui disant soit que tu l'initialiseras plus tard (auquel cas le compilateur vérifie que tu l'as bien initialisée) soit en lui précisant comment il devra l'initialiser lorsque tu l'utiliseras la première fois (tu renseignes la méthode d'initialisation mais vu que tu n'as pas encore le contexte ça n'initialise pas). Dans ton code, une fois que tu utilises "monbouton" pour la première fois, la méthode d'initialisation renseignée est exécutée à ce moment là. Du coup tu as une variable qui est déclarée et non initialisée mais qu'il t'est impossible d'utiliser sans qu'elle ne soit initialisée. En Java, si tu oublies d'initialiser l'erreur sera à l'exécution.
- La gestion des variables read-only: En Kotlin tu as le type "val" et le type "var", la distinction te permet des actions différentes en fonction du type et le compilateur vérifie que tu n'utilises pas des méthodes interdite, comme de changer l'affectation de "monbouton" vers un autre "Button" en cours de route, par exemple.
Et je passe sur les listes modifiables ou pas etc.
Bref, objectivement ce langage est plus sécuritaire et détecte plus de choses à la compilation et donc moins de plantages à l'exécution.
Kotlin ne se base pas sur l'IDE, et du reste l'IDE ne permet pas de tout éviter.car un bon IDE permet de ne pas écrire une partie du code verbeux
Si tu prends "linq" sous C#, par exemple, c'est un plus du langage, pas de l'IDE. Et bien tu as l'équivalent en mieux sous Kotlin. Trier les éléments d'un tableau en faire le tri selon deux critères spécifiques et renvoyer les 3 premiers éléments, ça se fait en une ligne sous Kotlin, sans boucle et sans code inutile. En outre, sous Kotlin ton "linq" devient paramétrable puisque tu peux lui ajouter de nouvelles fonctionnalités.
C'est encore une souplesse supplémentaire.Ce qui semble intéressant pour l'écriture de code asynchrone: les coroutines
Je pense que pour pouvoir comprendre les avantages de Kotlin, il faut au moins vérifier une fois ses spécificités, sinon on en reste à se demander "quel intérêt?".
Une petite (c'est relatif) présentation en Français sur Youtube permet déjà de dégrossir ce langage:
Répondre avec citation
Partager