Au niveau des sources traitant de Scala, il faut rajouter « Lambda the ultimate » qui a une section dédiée à Scala depuis assez longtemps (http://lambda-the-ultimate.org/taxonomy/term/32), et de très nombreux blogs dont par exemple Beautifull Language qui a fait une série d’article intéressants (http://langexplr.blogspot.com/search/label/scala) et celui de Tony Morris, qui traite beaucoup de Scala (http://blog.tmorris.net/).

@Nicolas Delsaux:

Le côté fonctionnel de Scala est beaucoup plus marqué que dans Rubis, même si ca ne se voit pas au premier coup d’oeil. Cela peut se remarquer en particulier par l’accent qui est mis sur les méthodes non mutables. Par exemple, le type List (pas celui présenté) est non mutable : les modifications sur une List se font en créant de nouvelle List. Scala possède aussi des « val », comme présenté ici, qui sont des variables non ré-assignable.
Ensuite, Scala possède des fermetures (closures) qui sont utilisées par exemple pour la création de nouveau opérateurs.
Scala permet de faire du pattern matching sur les classes (et rien que pour cela, ca vaut le coup de regarder Scala !). Scala permet définir des méthodes sous forme Curryfiée (ce qui est tout simplement géniale pour définir des API).
Enfin, le côté fonctionnel transparaît par les API proposées : on est encouragé à manipuler des listes pour toutes les opérations de bases. Par exemple, il n’y pas de « for » en Scala, son remplaçant étant une closure sur des listes (sur laquelle on peut appliquer toutes les opérations fonctionnelles standards, telles que filtres, map, etc)

Bref, là où Rubis a introduit quelques notions fonctionnelles, Scala a été construit dès le début pour être un merge la plus profond possible entre paradigme Objet et paradigme fonctionnel. Pour le côté Objet, c’est plutôt très bien réussi, pour le côté fonctionnel, on est pas encore à Haskell, ni même OCaml.

Mais surtout, surtout, la plus grande différence entre Scala et Rubis est que Scala est un langage typé statiquement, ce qui est bien, alors que Rubis est typé dynamiquement (non non, ma préférence ne transparait pas

Pour ce qui est du « Array[String](4), là où Java nous propose le String[4]« , c’est tout simplement dans un soucis d’homogénéité du langage (ca se verra plus si un article présente les « génériques » façon Scala). Là construction « Array[String](4) » est tout simplement un objet Array, paramétré par le type String, pour lequel on appelle le constructeur (int length) qui construit le tableau de longueur donnée.
On retrouve se soucis d’homogénéité du langage à de très nombreux endroits : les opérateurs ne sont pas des éléments spéciaux du langage mais de simples méthodes (ce qui facilite vraiment la vie pour définir ses propres API avec ses opérateurs, l’exemple des Actors Scala est frappant pour cela), *tout* est objets (pas de types primitifs), etc…)

@Gabriel
Jette un oeil à Tapestry 5 ( http://tapestry.apache.org/tapestry5/ ), tu pourrais être bluffé (mon rêve : lift, avec la vision de Howard pour l’archi. Ce mec est une brute comme j’en ai rarement vue).

Voilà voilà, merci Xebia pour ce blog

Francois

Bon, il y a quand même des idées curieuses (genre le Array[String](4), là où Java nous propose le String[4]), mais j’imagine qu’il s’agit seulement d’une n-ième d’itération de « mon herbe est plus verte que la tienne ».