Skip to content

Instantly share code, notes, and snippets.

@addinquy addinquy/odersky-devoxx.md
Last active Dec 20, 2015

Embed
What would you like to do?
Post sur la BOF de Martin Odersky sur Scala 2.10

#What's new in Scala 2.10 ? avec Martin Odersky Comme l'année dernière, Devoxx proposait cette année des "BOF" dont l'accès était libre moyennant une inscription préalable. J'ai vite arrêté mon choix sur celle de Martin Odersky. Scala est un sujet d'actualité pour moi, je suis au milieu du cours Functionnal Programming in Scala sur Coursera par le créateur du language !

Autant l'avouer tout de suite, ce n'est donc pas spécifiquement les nouveautés 2.10 qui m'intéressaient ici. J'espérais aussi grapiller un peu des "pourquoi" qui ont présidé aux options du language.

MartinOdersky01

Ca commence plutôt bien en ce sens.

##Pourquoi Scala ? Scala se veut un langage à usage général, permettant de traiter les problèmes de manière complexe (souvent avec une grande efficience de formulation) comme de manière simple. Mais la manière simple est souvent la meilleure. Le langage ne se veut ni directif, ni restrictif: il met une boite à outil à disposition du développeur, à lui d'en faire bon usage.

Du point de vue de cette philosophie, il se rapproche plus de C++ que de Java. Il va bien sûr porter le flanc à critique (comme C++) sur les aspects complexes et la difficulté, voir le danger, de mettre ce type d'outil à disposition du développeur moyen. Il ne recèle toutefois pas les comportements bizarres du C++. Pour ma part, ce type de positionnement me va bien. Et "si tu ne sais pas, tu ne vas pas", comme on dit…

L'évolution du langage Scala est aujourd'hui conduite par le SIP, le Scala Improvement Process. C'est l'équivalent du JCR Java en Scala, mais il parait plus participatif. En fait, n'importe qui peut proposer un SIP !

##Scala 2.10 C'est pour parler des nouveautés de la version 2.10 que Martin Odersky proposait cette session. Donc allons-y !

###String interpolations Cette évolution est décrite dans la SIP 11. L'interpolation de chaine permet le remplacement d'éléments d'une chaine de caractère par la valeur de variables. Par exemple :

val name = "World"
val message = s"Hello $name"

Donnera comme résultat "Hello World" dans la variable message. La magie de cette interpolation s'appuie sur une classe StringContext implémentant une méthode s (mais aussi d'autres). De nouveaux types de parsing peuvent aussi être injectés à StringContext via des wrappers implicites !

###Implicit sur les classes Cette nouvelle fonctionnalité de Scala fait partie de la SIP 13. Dans le cas qui nous intéresse, on souhaiterait pouvoir, pour parser du XML, écrire quelque chose du genre :

xml"<body>...</body>"

Le wrapper à écrire devrait ressembler à quelque chose du genre :

implicit class XMLinterpolation(s: StringContext) = {
   object xml {
      ...
   }
}

Une classe implicite prends en paramètre une classe qu'elle wrappe. On invoque directement la méthode qui y est définie, la construction de l'instance de classe étant alors implicite. Je vous le fais court, mais en gros, c'est l'idée !

###Value classes Cette SIP 15 propose le support de classes ayant une empreinte minimale en terme de performance et de mémoire. En fait, ces classes doivent pouvoir être complètement mises inlines ! L'objectif est de permettre la création de types de bas niveau pouvant se substituer aux types de bases de Scala, mais permettant un meilleur typage et le support intégré de certains fonctions de bases afférentes à ces types. Pour être value class, un type doit :

  • Etendre AnyVal
  • Avoir un constructeur avec exactement un paramètre, le type sous-jacent du value class. Voici une évolution que je me réjouis de voir apparaitre pour ma part, d'autant qu'elle ne nécessite pas de construction particulière.

Voici une évolution que je me réjouis de voir apparaitre pour ma part, d'autant qu'elle ne nécessite pas de construction particulière.

Par ailleurs, en utilisant conjointement une classe implicite et une value classe, on peut même rendre transparente la construction d'une value classe particulière depuis un type sous-jacent.

###Zinc On ne parle plus langage ici. Zinc ( http://typesafe.com/blog/zinc-and-incremental-compilation ), c'est le compilateur incrémental qui faisait partie de SBT. Il a été individualisé de manière a être intégré dans l'IDE Scala 3.0 (bien qu'il ne semble que ce ne soit finalement pas le cas).

##Vers l'infini et au-delà…

###Scala 2.11 Pas de gros changements en vue pour cette version de Scala. On a plutôt des objectifs de stabilité et de performance. Toutefois, il faut noter que les acteurs Scala sont maintenant dépréciés au profit de ceux de la librairie Akka. Et il n'y a pas non plus de compatibilité binaire entre 2.10 et 2.11, donc attendez-vous à galérer encore un peu de ce côté… Comme j'ai beaucoup tardé pour ce post, vous aurez sans doute remarqué que les "nouveautés" n'en sont plus guère, et que l'on en est déjà à la M3 pour la version 2.11 ...

###Quid de Java 7 ? Déception de ce côté. S'adosser au compilateur Java 7, et plus pratiquement utiliser inkedDynamic ne fait pas partie des plans de Scala à court terme. La raison invoquée est le souhait de ne pas maintenir deux versions de compilateur (Java 6, Java 7). Je pense que ce sont de mauvaises raisons. Le compilateur Java 7 a maintenant un peu de bouteille, et les utilisateurs de Scala ne sont pas particulièrement conservateurs. Cela ne me choquerait pas d'avoir un Scala 2.11 exigeant Java 7 pour fonctionner ! En fait aujourd'hui ma crainte serait plutôt de devoir faire face à des dysfonctionnement avec Java 7 ! En bref, c'est plutôt à moi de maintenir deux JDK sur ma machine, et exclusivement à cause de Scala !

###Ca pointe à l'horizon… Curieusement Martin Odersky prétend que Scala ne changera de version majeure que pour des évolutions brisant la compatibilité ascendante. Je ne sais pas trop ce que cela veut dire, car chaque version a peu ou prou cassé cette compatibilité. En tout cas elle n'existe pas au niveau binaire sur toutes ces versions, ce qui cause un casse-tête au niveau de la gestion des dépendances...

Martin Odersky voit comme grosse fonctionnalité pour Scala 3, la possibilité de fonctionner sur d'autres machines virtuelles. Il pense essentiellement à la VM Javascript (qui est d'ailleurs plutôt un runtime). Cela ressemble furieusement à ce que Ceylon tente de faire ! D'ailleurs la featur list de la 2.11 () fait état d'un back-end expérimental pour .NET qui a été repoussé à plus tard.

Pour un futur peut-être moins éloigné, le créateur de Scala évoque un compilateur incrémental plus performant, moins conservateur que l'implémentation actuelle.

##En conclusion Scala a encore une belle roadmap devant elle. Attention toutefois ! Si le langage veut quitter sa communauté de passionnés pour atteindre l'early majority, il va devoir se civiliser un peu et notamment prendre au sérieux la compatibilité ascendante et la compatibilité binaire. Je pense que dès à présent, ce sont des choses que l'on ne devrait plus traiter à la légère !

Lorsque lui parle de framework web, Martin Odersky réponds en terme de modèle. Pour lui, l'avenir des architectures applicatives Web, c'est d'être réactives et asynchrones sur les traitements. Ca tombe bien, c'est le modèle de Play !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.