Il y a 12 ans -
Temps de lecture 3 minutes
Devoxx – Kotlin
Depuis quelques mois, Kotlin fait parler de lui. Rien de tel qu’une conférence comme Devoxx pour prendre la température de ce nouveau langage.
Lors de cette session, Andrey Breslav nous a expliqué d’abord les motivations qui ont poussé JetBrains à investir dans le développement de Kotlin :
- se détacher des limitations du langage Java dues à la compatibilité ascendante,
- avoir un outillage performant. Notamment, une intégration de qualité dans les IDE, un debugger et un compilateur au moins aussi rapide que celui de Java. Pour garantir cela, JetBrains développe en parallèle du langage et du compilateur, un plugin pour l’intégration dans leur IDE IntelliJ ainsi qu’un plugin simple pour Eclipse,
- avoir une syntaxe plus expressive.
Ensuite, il nous a expliqué les choix de design du langage :
- entièrement compatible avec java,
- code concis,
- statiquement typé.
Ces choix ont été fait de manière à limiter les erreurs à l’exécution de l’application.
Pour cela, ils ont implémenté différentes fonctionnalités.
Pour les plus classiques :
- Closure,
- Pattern matching,
- Inférence de type,
- Simplification des accesseurs sur les propriétés,
- Les Traits.
Et pour les plus innovantes :
- Extensions Function,
- Casting ‘intelligent’,
- Static null safety guarantees,
- Inline function,
- Reified Generics,
- Build infrastructure.
Andrey nous a montré ensuite un grand nombre d’exemples notamment :
- Hello world avec le parcours d’une itération :
namespace demo fun main(args : Array<String>) { for (name in args) println("Hello, $name!") }
- Extensions Function qui peut notamment permettre d’étendre les fonctions d’une classe. Ici, on ajoute la fonction plusAssign que l’on peut appeler par + ou += à StringBuilder :
namespace demo fun main(args : Array<String>) { val names = new StringBuilder() for (i in args.indices) { names += args[i] if(i+1 < args.size) { names += "," } } println("Hello, $name!") } fun StringBuilder.plusAssign(s : String) { this.append(s) }
- Smart Cast pour ne pas caster l’objet si le type est déjà testé. Il peut être aussi utilisé dans un pattern matching comme dans l’exemple suivant :
namespace demo fun foo(obj : Any?) { if(obj is String) { obj.substring(2) } when (obj) { is String => obj[0] is Int => obj + 1 !is Boolean => null else => ... } }
- Le pattern matching accepte des expressions ou un ensemble de valeurs :
fun bar(x : Int) { when (x) { 0 => "Zero" 1, 2, 3 => "1, 2 or 3" x + 1 => "Really strange" in 10...100 => "In range" !in 100...1000 => "Out of range" } }
Cerise sur le gâteau, Andrey nous a montré le compilateur et le debuggeur sous IntelliJ parfaitement fonctionnels.
Cette session était surtout participative avec pas mal de questions dans la salle. À chaque fois, Andrey répondait à ces dernières de manière pertinente et nous avons constaté que l’équipe JetBrains a bien réfléchi pour faire un langage simple. Kotlin possède une syntaxe proche de celle de Java et de Scala, tout en les allégeant.
Kotlin est encore en phase de développement et les discussions sont encore vives sur les choix de conception du langage. Pour preuve, la page de Kotlin contient énormément de commentaires sur les améliorations ou évolutions à lui apporter. Un langage de plus à surveiller de près.
Commentaire
7 réponses pour " Devoxx – Kotlin "
Published by Raf , Il y a 12 ans
L’une des motivations de la création de Kotlin serait d’avoir un outillage d’aussi bonne qualité que celui de Java. Motivation récursive ?
Published by Dominique De Vito , Il y a 12 ans
Pour la majorité des plus classiques innovations, on peut constater qu’ils sont en ligne avec les développeurs de Xtend:
* Closure,
* Inférence de type,
* Simplification des accesseurs sur les propriétés,
* Les Traits.
Espérons dès lors que ces innovations parmi les + classiques vont finir par arriver dans Java dans un futur raisonnable… Bon, en fait, j’en doute un peu, en matière de futur raisonnable…
Par contre, je ne comprends pas du tout l’intérêt d’inverser la déclaration du type des arguments d’une méthode.
Est-ce que JetBrains en a précisé la valeur ajoutée ? Ou s’agit-il du gout et des couleurs de JetBrains ?
Merci
Published by Nicolas , Il y a 12 ans
Bonjour,
Andrey nous a expliqué que JetBrain a fait le choix d’inverser la déclaration du type car cela leur permettait d’être plus efficace dans l’interprétation par le compilateur.
Nicolas (Xebia)
Published by n!co , Il y a 12 ans
Beaucoup trop de sucre syntaxique a mon gout !
L’important pour moi n’est pas que d’écrire du code vite et le plus concis possible.
Il faut le faire en s’assurant qu’il reste lisible, pour les autres et par soi même.
Aussi, je pense qu’il faut créer un langage pour les développeurs et pas pour le compilateur.
Ce sont les forces de java !
En tout cas merci pour ces détails
Published by Dominique De Vito , Il y a 12 ans
@Nicolas
Pfff, en gros, JetBrains préfèrent faire bosser des humains (pour s’adapter au changement de syntaxe) là où une machine pourrait faciliter le boulot aisément…
JetBrains serait du genre à ne pas inventer la pelleteuse, et ne laisser aux humains que l’usage de pelles, pour la simple raison que c’est chiant de mettre sur papier les plans de fabrication d’une pelleteuse…
Published by Francois Armand , Il y a 12 ans
@Dominique De Vito : cette façon de déclarer les types est aussi plus naturelle dans les langages qui offrent une inférence sur les types.
* avec de l’inférence, on est quasi-obligé d’avoir une mot clé pour la définition (val dans Kotlin), sinon on ne peut pas différencier définition, assignation, redéfinition, etc (en Java, le type sert à rendre non ambigue)
* il est plus naturelle de laisser tomber la fin de la définition que le début.
Published by Dominique De Vito , Il y a 12 ans
@Francois
« cette façon de déclarer les types est aussi plus naturelle dans les langages qui offrent une inférence sur les types » : oui et non.
Par exemple, ce n’est pas le cas (IMHO) pour les langage à assignation unique. Si je prends Caml/OCaml, je déclare un entier comme suit:
let i = 3;
Avec un langage sans inférence de type (Java-like), on déclare :
int i = 3;
Donc, j’ai (i.e. j’avais) tendance à imaginer jusqu’à présent qu’il s’agit plus de remplacer le début de la définition, plutôt que de laisser tomber la fin ; ceci était renforcé, qui plus est, par le fait que je vois plus le futur à travers un langage qui tendrait à s’inspirer de Caml/OCaml que de JavaScript (vu le foutoir de JS actuel et les tentatives en cours visant à l’améliorer).
Ceci étant, oui, effectivement, si on prend un langage comme JS, il s’agit plus de laisser tomber la fin que le début…