Conférence : ScalaIO.2017, nos retours

La plus grande conférence française sur Scala et la programmation fonctionnelle a suscité l’engouement chez quelques Xebians, lesquels avaient fait spécialement le voyage à Lyon pour y assister !

Après les retours de la conférence de l’année dernière, voici ce qu’il faut retenir de ces deux journées de conférence qui ont eu lieu les 2 et 3 novembre 2017 !

ScalaIO à Lyon

La conférence a été organisée par une équipe de passionnés, qui s’occupe depuis 3 ans de la conférence, qui a créé une association cette année. L’événement s’est déroulé au CPE de Lyon (École d’Ingénieurs en Chimie et Sciences du Numérique), en plein coeur du campus de la Doua. Les différentes sessions étaient réparties sur quatre salles, dont un grand amphithéâtre, et les lieux étaient très soignés (deux salles de classe peut-être un peu petites pour le nombre de participants). Il y avait de nombreux sponsors cette année, dont Fabernovel Technologies (ex Zengularity), EbizNext qui a proposé un jeu concours chaque jour, Criteo Labs, Lunatech et pleins d’autres… avec leurs lots de goodies, comme à leur habitude. Cette année, pas de Martin Odersky, mais deux keynotes en anglais très intéressantes: l’une par Dean Wampler le jeudi sur le streaming, l’autre par Jamie Allen le vendredi sur l’eventual consistency.

L’ambiance était encore bon enfant et cette année les organisateurs avaient mis la barre haute au niveau des plats, en faisant appel à un traiteur qui s’approvisionnait en produits locaux et offrait plusieurs choix de sandwichs.

Il y a eu une agréable soirée au château de Montchat (peut-être manquant de chaises ;) ), qui fait office de lieu de buffet et de conférences.

Deux journées de conférence

Que retenir ?

Programmation fonctionnelle et effets de bord

En programmation fonctionnelle pure, il n’y a pas d’effets de bord. Cela signifie (entre autres) que tout programme renverra toujours le même résultat qu’importe son contexte d’exécution. Il est donc impossible, dans un tel programme, d’interagir avec le monde extérieur. Haskell répond à cette problématique via la fameuse monade IO (entre autres). Mais qu’en est-il en Scala ? Au premier abord, on peut trouver ce genre de structures superflues, Scala autorisant les effets de bord, notamment pour la lecture et l’écriture de flux. Mais de nombreux intervenants ont voulu nous convaincre de l’utilité et de l’importance d’une bonne gestion des effets en Scala !

Parmi les sessions les plus marquantes, une bataille de bibliothèques par sessions interposées : The Design of the Scalaz 8 Effect System par John A De Goes, a présenté Scalaz 8, en explorant la nouvelle implémentation de la monade IO, bien supérieure à la version précédente et The Making of an IO par Daniel Spiewak, nous a fait découvrir cats-effect, bibliothèque basée sur cats et permettant une meilleure gestion des effets que Scalaz 7.

Durant une autre session, Benoît Lemoine nous a également parlé des effets de bord. Au travers d’un fil conducteur basé sur le code d’un distributeur de soda, Benoît nous a montré comment rendre le code plus fonctionnel. Comment mieux gérer les erreurs. Comment rendre le code moins sujet aux effets de bord en utilisant les bonnes monades face aux bonnes problématiques.

Ce qu’il faut retenir de ces sessions, c’est qu’utiliser des monades IO pour représenter un effet n’est pas qu’un simple exercice de style, comme le souligne John A De Goes dans ce tweet. Cela induit potentiellement de meilleures performances, une meilleure composabilité entre le code fonctionnel et le code dit « impur » et bien sûr, plus de sûreté dans le code.

Du streaming

Le programmation réactive a disposé d’une présentation spécifique, avec des aperçus de Akka, Monix… et même Scalaz. John A De Goes a milité pour de la programmation fonctionnelle pure même pour le traitement des flots de données infinis.

Théorie des catégories

Symboles clés de cette session, les deux conférences sur la théorie des catégories ont permis de vulgariser ce concept mathématique. Avec la pédagogie exceptionnelle de Bartosz Milewski et le pragmatisme au plus proche du développeur pour Daniela Sfregola, la théorie la plus emblématique dans le monde de la programmation fonctionnelle a été démystifiée. Et même plus : les intervenants nous ont fait comprendre en quoi les mathématiques sont importantes pour le code.

Pourquoi des symboles clés ? Avec ces deux présentations, un tout cohérent s’est dégagé : les explications sur la théorie des catégories ont donné des notions importantes telles que les foncteurs et les monades, pour mieux appréhender les autres sujets plus avancés de la conférence.

Vous pouvez retrouvez la conférence de Daniela Sfregola, A pragmatic introduction to Category Theory sur YouTube (laquelle a aussi été jouée à Lambda World 2017) et sur Speaker Deck.

Scala Center FLOSS Spree

Que rêver de mieux que de faire participer développeurs et créateurs de projets open-source ? Tout le vendredi après-midi, on a pu chauffer nos doigts sur le clavier et se lancer sur de nombreux projets open-source. Ceux-ci avaient même parfois été présentés par les intervenants lors de conférences la veille ou le vendredi matin. Le tout était co-organisé avec le Scala Center, une association à but non lucratif créée par l’EPFL de Lausanne l’année dernière pour soutenir Scala sous toutes ses formes !

L’idée principale est de s’occuper d’une issue d’un de ces projets open-source (ceux maintenus par le Scala Center, comme Scastie ou Scaladex, ou par des orateurs comme Hamsters ou Twitter4s) et de soumettre une pull request. En bonus, chacun des participants ayant eu leur pull request intégrée au projet se sont fait remettre un tee-shirt ! Il y a eu une ambiance très bienveillante entre contributeurs et développeurs, et les contributeurs étaient très pédagogues.

Il y a eu clairement du choix dans la liste des projets de ce Scala Center FLOSS Spree !

Les coups de cœur des Xebians

Curry et Bayes sont sur un bateau – Par Samy Zarour (Aurore de Amaral)

Lambda et fonction pure n’étaient pour une fois pas le sujet central ! Elles ont laissé la place à une implémentation d’une mesure de probabilité en Scala, puis l’utilisation de la bibliothèque Figaro. On a ainsi un aperçu de comment déclarer ses données, variables aléatoires et autres éléments pour créer une mesure de probabilité avec et sans Figaro, lequel permet de décrire aussi des lois de probabilités conditionnelles comme le théorème de Bayes.

Je l’ai beaucoup apprécié puisqu’il m’a permis d’avoir un aperçu du langage Scala comme un intermédiaire à l’introduction d’algèbre, de statistique et de probabilité. Et tout cela avec du code. Voici par exemple la représentation d’une mesure de probabilité d’un lancer de dé avec un gain et la bibliothèque Figaro. Les règles sont simples: si le dé est pair, on gagne le gain de la pièce et la valeur du dé, sinon on ne gagne que la pièce. Le but est de connaître les gains finaux.

[scala]sealed trait Piece
case object Pile extends Piece
case object Face extends Piece

//Flip en Figaro pour définir les possibilités de pièce
val piece: Element[Piece] = Flip(0.5).map(b => if (b) Pile else Face)

//Select pour les possibilités de dé
val de: Element[Int] = Select(1.0 -> 1, 1.0 -> 2, 1.0 -> 3, 1.0 -> 4, 1.0 -> 5, 1.0 -> 6)

//Définition du graphe de possibilité pour un lancer de dé/pièce
val gain = for {
p <- piece
d <- de
} yield {
(p, d % 2 == 0) match {
case (Pile, true) => d +1
case (Face, true) => d
case (Pile, _) => 1
case (Face, _) => 0
}
}

//Calcul d’inférence
val alg = BeliefPropagation(10, gain)

alg.start()
val density: Stream[(Double, Int)] = alg.computeDistribution(gain)
//La probabilité d’un gain final supérieur à 5 ?
val prob: Double = alg.probability(gain, (g:Int) => g > 5)
alg.kill()

println(density.toList)[/scala]

Je trouve que cela permet une pente douce à l’apprentissage de ces domaines pour un développeur, mais ne va pas assez loin dans l’utilisation de la programmation fonctionnelle.

Vous pourrez retrouver le code source présenté lors de la conférence sur GitHub.

Next generation Scala builds with CBT – Jan Christopher Vogt (Charles Dufour)

Avant d’entrer dans cette session, j’étais sceptique. Je me demandais ce que pouvait apporter ce nouvel outil de build, face au mastodonte SBT. Pouvait-il apporter la même expressivité ? Et c’est en sortant que j’ai compris que l’avenir des outils de builds Scala était peut-être là.

Pour comprendre, il faut d’abord se demander quels sont aujourd’hui les reproches faits à SBT. On pense immédiatement à 2 choses. Tout d’abord, sa vitesse de lancement. Aussi puissant soit-il, impossible d’utiliser SBT comme un simple outil en ligne de commande. Il prend trop de temps à se lancer, il faut passer par son REPL. Ensuite, la complexité de son DSL. Pour définir les dépendances d’un projet cela ne pose pas de problèmes. C’est lorsqu’on essaye de manipuler des concepts plus avancés que cela devient difficile. C’est notamment sur ces deux points que CBT a montré toute sa force.

Pendant la présentation, Christopher montrait à de nombreuses reprises des exemples de commandes CBT. Sa vitesse était bluffante. Il pouvait s’utiliser comme un outil en ligne de commande.

Concernant le DSL utilisé par CBT pour écrire un fichier de description du projet, c’est simple, il n’y en a pas. CBT utilise tout simplement du Scala pour écrire un tel fichier. Cela permet, en ne connaissant que du Scala pur, d’écrire un projet et son fichier de description associé. Cette simplicité induit une certaine verbosité, mais aussi une plus grande lisibilité du fichier.

Si l’on souhaite par exemple créer un projet basé sur Akka Http, voici ce que nous pourrions faire avec SBT :

[scala gutter= »true » num= »1″]lazy val root = (project in file("."))
.settings(
libraryDependencies += "com.typesafe.akka" %% "akka-http" % "10.0.10"
)[/scala]

Avec CBT :

[scala gutter= »true » num= »1″]class Build(val context: Context) extends BaseBuild {
override def dependencies =
super.dependencies ++
Resolver(mavenCentral).bind(
ScalaDependency("com.typesafe.akka", "akka-http", "10.0.10")
)
}[/scala]

Si la version CBT est plus longue, elle ne nécessite pas la connaissance d’un DSL spécifique, c’est à dire de savoir ce que font les opérateurs %%, +=, in etc.

Son seul défaut, sa jeunesse. Cela se ressent surtout par son manque de plugins, mais il ne demande qu’à évoluer !

Le code source du projet est disponible sur GitHub.

A crash course in Category Theory – Bartosz Milewski (Jonathan Raffre)

Avec brio, Bartosz Milewski a vulgarisé la théorie des catégories d’un point de vue mathématique sans demander de prérequis !

La dissonance entre le langage informatique et humain, la vision micro vs macro, en est un premier constat simple. Ensuite viennent la définition d’un ensemble et l’abstraction du détail, ce qui nous amène progressivement vers un raisonnement par transformation, le cœur de la théorie des catégories.

J’ai adoré son approche progressive de la théorie, détaillant pas à pas les types et les fonctions, le tout illustré. Une première plongée parfaite que je recommande pour qui souhaite se lancer dans la programmation avec les foncteurs et monades !

Vous pouvez retrouver le livre de Bartosz Milewski sur la théorie des catégories sur GitHub.

La thématique « les mathématiques sont finalement utiles au développeur » (Joachim Rousseau)

Pourquoi choisir un coup de cœur ? Je n’en ai pas eu, mais plutôt une révélation tant le programme de Scala.IO était cohérent et bien ficelé.

De la théorie des catégories ré-expliquée par Daniela Sfregola, à Kleisli qui vient à la rescousse des Future par Xavier Bucchiotty et Tristant Sallé, en passant par le dilemme Tagless ou FreeMonad par Adam Warski, j’ai vraiment l’impression d’avoir suivi un parcours logique qui m’a permis de comprendre les buzzwords les plus effrayants de la programmation fonctionnelle.

Pour avoir un éclairage nouveau sur Scala, les bibliothèques, et la programmation fonctionnelle au service du métier, je vous conseillerais d’aller voir les vidéos des conférences qui concernent la théorie des catégories, puis les Freemonads et autres Tagless, pour finir en beauté sur Kleisli.

Conclusion

Perdus ou débutants dans la programmation fonctionnelle, Scala.IO 2017 a été la session à suivre pour nous. Cette dernière a donné de bons arguments pour comprendre en quoi les mathématiques peuvent être une aide précieuse pour développer. Comme l’expliquait Daniela Sfregola « on comprend mieux ce qu’on fait, pourquoi on le fait ». Les « maths » et la « PF » (aka Programmation Fonctionnelle ;-)) peuvent donc être les meilleurs amis des crafts(wo)men.