anchor.diff:  Un inconvénient potentiel réside dans le fait que ces conversions sont
   implicites, justement, et qu'il peut devenir compliqué de déterminer
   quelle conversion est sélectionnée (pour peu qu'il y en ait un certain
  -nombre dans le même scope). +
  - +
  +nombre dans le même scope).
  +
   
   Scala dans vos équipes
   ^^^^^^^^^^^^^^^^^^^^^^
   
  -Kevin Wright a ensuite pris le relais. +
  +Kevin Wright a ensuite pris le relais.
  +
   Selon lui, un développeur Java doit "parler" XML et coder en Spring, du
  -fait des nombreuses insuffisances du langage Java. +
  +fait des nombreuses insuffisances du langage Java.
  +
   Scala, au contraire, est suffisamment riche et expressif (__literary
   programming__) qu'il permet de se focaliser sur des problématiques
   métier en restant très peu verbeux (vous trouverez un exemple de code
   appuyant ses propos https://gist.github.com/1262988[ici]). +
  - +
  +
  +
   Étant intervenu dernièrement dans 3 entreprises afin de former et mettre
   en place Scala dans les équipes de développement, Kevin nous partage ses
   expériences et prodigue quelques conseils intéressants. +
   Il explique tout d'abord qu'il n'a rencontré que très peu (voire pas du
   tout) de résistance à l'apprentissage de Scala. Partout où il est
  -intervenu, il a procédé ainsi: +
  - +
  +intervenu, il a procédé ainsi :
  +
   
   * écrire les tests en Scala
   * laisser l'enthousiasme se répandre :)
  
positive.code: 
  Je n'ai assisté qu'à une partie de la conférence animée par Stephan
  Colebourne, créateur de http://joda-time.sourceforge.net/[Joda-Time].
  _"Is Fantom light years ahead of Scala?"_ se voulait très provocateur.
  Comme vous l'aurez deviné, Stephen n'aime pas Scala, qu'il trouve
  beaucoup trop complexe. Vous trouverez d'ailleurs
  http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html[une
  récente publication] de sa part où il énumère un certain nombre
  d'arguments et de ressentis qui le pousse à préférer d'autres langages
  que celui-ci. +
   +
  Mais revenons-en à http://fantom.org/[Fantom]. +
  À la fois orienté objet et fonctionnel, Fantom embarque la notion de
  __pod__, a.k.a. modules (prévu en Java pour la release du JDK8, par le
  projet Jigsaw, lequel a fait l'objet d'une conférence à part entière par
  Mark Reinhold). +
   +
  Un _pod_ est : +
  
  * le niveau hiérarchique le plus élevé (un pod contient des _types_ -
  classe ou mixin, un type contient des _slots_ - méthode ou champ) ;
  * l'unité de compilation en Fantom : une classe ne peut se compiler,
  seul le pod auquel elle appartient peut l'être ;
  * le nom d'un _pod_ est globalement unique, comporte le VCS utilisé et
  le numéro de version
  
  Ainsi, pas besoin de librairie tierce "à la Maven", le langage comporte
  déjà tout ce qu'il faut. Contrairement à Kotlin et Ceylon, Fantom est
  
negative.code: ~~~~~~~~~~~~~~~~~~~~~~~
  
  Voici les conférences que ce premier billet va tenter de résumer. +
  
   * _The Groovy Ecosystem_, Andres Almiray
   * _Crash Course into Scala_, Mario Fusco et Kevin Wright
   * _The Kotlin Programming Language_, Andrey Breslav
   * _The Ceylon Programming Language_, Emmanuel Bernard et Stéphane Épardeau
   * _Is Fantom light years ahead of Scala?_, Stephen Colebourne
  
  Il ne s'agit en aucun cas d'un compte rendu exhaustif, mais plutôt des
  points qui m'ont marqués (et dont je me souviens encore :P). +
  
  Scala
  ~~~~~
  