Troll Java/Scala quand tu nous tiens!

Ca trolle sévère sur la mailing liste de Cast Codeurs concernant le code de Scalaz.

Troll

Qu’il est difficile de comparer, Java, un langage conçu pour aider les développeurs à évoluer dans un monde pas trop dangereux pour lui-même et Scala, un langage conçu pour donner les pleins pouvoirs au développeur quitte à ce que l’arme lui pète entre les mains.

Cela est d’autant plus difficile que paradoxalement Java n’a pas atteint son objectif de protection du développeur (cf. Java Puzzlers) et Scala offre aussi une protection par son système de typage.

Et la lisibilité du code ?

La lisibilité des deux langages entre aussi en jeu dans la comparaison. Chaque langage porte ses contradictions:

  • Java a une syntaxe redondante, lourde mais rassurante pour le lecteur.
  • Scala a une syntaxe ultra ramassée et un système de typage très verbeux pour qui cherche le maximum de protection à la compilation.

OO versus FP

Et puis il y a la programmation fonctionnelle qui fait grincer les dents. Ceux qui ont pratiqué aiment, les autres n’arrivent souvent pas à lire le code, faute d’habitude. Pour shématiser, on passe du mode ‘une opération par ligne’ facile à lire au one-liner ‘un concept par ligne’ rapidement trop ramassé. Ceci étant dit, j’aime la programmation fonctionnelle. Que de contradictions.

L’effet DSL

Enfin, la mode des DSLs obscurcit elle aussi le débat Java/Scala. Je m’explique:

  • En Java, on n’écrit pas de DSL ou alors ultra rudimentaire. Mockito ou FestAssert par exemple.
  • En Scala (ou Groovy ou Lisp), on écrit des DSL un peu partout.

Or, le code derrière un DSL est toujours plus difficile à lire que le code utilisant le dit DSL. Peu importe l’outillage ou le langage, un “interpréteur” est plus abstrait, plus exhaustif, plus précis que le code utilisateur.
Tout ca pour dire que comparer la lisibilité d’un code métier Java avec du code implémentant un DSL en Scala est un non sens. Allez lire le code derrière Mockito et riez à l’idée du peu de code nécessaire pour coder ça en Lisp (et sans doute en Scala).

L’effet humain

Bien sur il est humainement possible d’écrire du code métier Java moins expressif qu’une implémentation de DSL en Scala. Ca aussi ça brouille les cartes !

Les lenteurs de l’âge

Personnellement, je suis très bloqué dans mon adoption de Scala par la lenteur de compilation. Pourtant javac 1.0 était beaucoup beaucoup plus lent et je me suis jeté dessus. Trop vieux pour ce genre de conneries…

Sur ce, je retourne faire du Ruby!

3 thoughts on “Troll Java/Scala quand tu nous tiens!”

  1. David

    Tu ne peux pas dire “je suis trop vieux pour apprendre Scala”.
    Franchement c’est un peu de travail mais ce n’est rien dans une vie de développeur.
    Quant à la lenteur de compilation, ce n’est plus vrai avec la dernière version de Scala. On parle de quelques mois… Quand tu vois que Java fête ses 17 ans… Et que tu en fais encore… Moi je crois à Scala.

  2. Quelques mois ?! Je faisais déjà dû Scala il y a plus de 5 ans. Mais le langage évolue trop vite que pour arriver à devenir “mainstream”. Autant je trouve l’obsession de backwards compatibility de java tourne au ridicule, autant Scala abuse dans l’autre sens.
    Enfin. De manière générale, je trouve que la commuté java à tendance à être de plus en plus conservatrice et nombrilliste. L’un des example les plus frappant étant sans doute l’aversion au courant Javascript parce qu’il n’adopte pas le même paradigme objet.

Comments are closed.