Écrire des CSS en Kotlin. Pas mal pour avoir un mono langage et des TU sur les CSS #Paranoïa

Une appli écrite en 4 fois en :

• Java
• Groovy
• Kotlin
• Scala

La comparaison du readme est très appréciée.

Très bon article expliquant :

• La différence entre un type et une classe.
• La variance et la covariance.
• L'invariance et la contravariance.

Ce qui permet de comprendre le fonctionnement complet des génériques en Java et Kotlin, ainsi que les mots clefs in et out de Kotlin.

Pour Chlouchoutte. Toutes les petites annotations existantes en Kotlin et qui produisent un code Java-friendly. L'autre point intéressant de l'article est qu'il montre le code Java produit à partir du code Kotlin.

Je copie-colle l'explication courte (suffisante pour comprendre l'idée ou pour un mémo) :

abstract, open, final, sealed, override: drive inheritance, obviously affect the language
enum: alters the syntax of the declaration (allows enum entry list)
annotation: alters the syntax: annotation classes have no bodies
inner: alters scoping: members of outer class are accessible
private, public, internal, protected: regulate visibility, affect name/overload resolution
out, in: affect subtyping
vararg: affects use-site syntax, types and overload resolution
companion: affects both use-site and declaration-site syntax
lateinit: affects the syntax: initializer is forbidden, no definite-assignment checks are performed
inline, noinline, crossinline: affect possible usages of local returns etc
reified: affects possible arguments and uses of a type parameter inside
tailrec: affects allowed contents of a function
external: affects syntax: non-abstract function with no body
data: affects the set of members of a class, inheritance rules etc

Un bon résumé des éléments pratiques dans le langage Kotlin. Je vous invite à en juger par vous-même.

Je ressors ce post qui date d'il y a 3 ans (septembre 2014) et il faut l'avouer, la communauté Scala semble être vraiment d'une mauvaise foi redoutable !

Qu'est-ce qui me permet de dire cela ? Regardez cet extrait (et il n'est pas le seul) :

// Java:
List<Integer> ints = new ArrayList<Integer>();
for (String s : list) {
    ints.add(Integer.parseInt(s));
}

// Scala:
val ints = list.map(s => s.toInt)

Pour rappel, Java 8 est sorti en MARS 2014, soit près de 6 mois AVANT cet article. Le mec compare encore Java 6 qui passait en support étendu à Scala et non Java 8 qui était ce que le langage savait faire de mieux.

Deux remarques :
1) Le code Java présenté est falacieux puisque le mec instancie sa liste en Java mais pas en Scala histoire de gratter quelques lignes.

2) Que pense-t-il de ce code Java 8:

// En considérant que la variable ints existe, sinon il faut ajouter List<Integer> devant :
ints = list.map((s) -> parseInt(s));

Bref, de la pure mauvaise foi. Cela fait quelques semaines que je me suis mise à Scala et non seulement les arguments de la communauté Scala par rapport à Java 8 ne tiennent pas debout, mais l'ensemble des outils, des libs, des éditeurs, bref l'ensemble de l'éco-système Scala est misérable à côté de Java. Les temps de build sont atrocement longs (et je pèse mes mots, passer de Java 8 à Scala multiplie littéralement vos temps de build par 300 ; de quelques secondes à quelques quarts d'heure). Pis encore, vos libs ne seront plus compatibles d'une version du compilateur à une autre (seriously, un langage ose encore péter la compatibilité du bytecode en 2017 , dafuq les mecs !???)

Enfin, au vu des features de Java 8, il n'y a aucune raison valable de passer de Java 8 à Scala SAUF, si vous êtes un aficionados de la programmation fonctionnelle pure (qui reste une immense connerie d'académiciens AMHA).

En parallèle je suis en train de me mettre à Kotlin, et par rapport à Scala, c'est le jour et la nuit.

La syntaxe est meilleure que Java ET Scala (toujours de mon point de vue, peu de symboles obscur mais des mots-clefs simples et clairs, le paradigme Objet domine mais laisse place de manière pragmatique au paradigme Fonctionnel, les temps de builds sont semblables à ceux de Java 8, la compatibilité avec les versions plus anciennes de Kotlin est garantie et les binaires générés depuis un code Kotlin peuvent être utilisez de Java 6 à Java 8 et vice et versa ; sans parler de l'écosystème, de la doc et des IDE, des outils de build qui sont les mêmes qu'en Java 8.

Bref, je maintiens, Scala est un langage d'académiciens fait par des académiciens pour des académiciens, il est particulièrement difficile de couvrir des besoins industriels sérieusement avec quelque chose d'aussi peu mature.

En espérant en avoir aidé certains et agacé d'autres.