Coursera propose
une seconde session de ses cours scala - vous pouvez encore rattrapper le cours, même si vous serez un peu hors délais pour faire un high-score, mais peut importe ça reste très intéressant.
Le principe de ces cours, c'est de proposer des sessions en vidéo et des exercices à réaliser et à soumettre pour validation.
La partie vidéo est génialissime. Très progressives, les "lectures" vous font découvrir peu à peu scala, et surtout la programmation fonctionnelle. On pourra trouver ces présentations excessivement théoriques, formalisées de manière très mathématique - elles restent cependant très didactiques, et j'adore l'option de vitesse de lecture, qui permet de passer en *1,25, *1,5 voir *2 pour des passages qu'on a déjà compris on qu'on trouve trop théoriques (ou bien quand on a pas trop de temps à leur consacrer :P). A quand la même fonctionnalité dans Parleys ?
Par ailleurs, les vidéos présentent les slides avec en filigrane le stylet de Martin Odersky, qui ajouter des schémas ou des petits bouts de code explicatifs.
Bref, coursera, c'est de la balle
La partie exercice est également parfaitement adaptée et bien préparée. On a assez peu de code à produire dans un squelette bien documenté qui nous guide vers la solution, il y a "juste" ce qu'il faut pour apprendre ce que l'exercice vise à nous faire comprendre.
Question temps, il faut compter 3 à 4h environ pour chaque semaine de cours. Pour ce qui me concerne j'ai fait le 1er sur une pause midi, le second "en tâche de fond" sur deux jours et le dernier hier soir, terminé ce matin parce que passé 23h je commençais à faire n'importe quoi.
Clairement, c'est consommateur de temps, mais bon, à étaler sur une semaine ce n'est pas
si méchant que ça quand on considère la qualité du support didactique. Au moins, lors des prochains trolls anti-scala j'aurais de vrais arguments :)
et scala dans tout ça ?
Scala, c'est des fanboys, une armée de contradicteurs qui n'ont jamais regardé plus loin que le mal qu'on leur a dit de scala, et des trolls en pagaille, alors allons y :
Syntaxe
Le premier contact est un peu rugueux : la syntaxe est déconcertante. Pour un langage qui cible la JVM et s'adresse aux développeurs Java voulant gouter à la programmation fonctionnelle, je ne comprend pas certains choix de syntaxe - ils ont sans doute une bonne raison d'être, mais ...
foo(x: Int): Boolean pour une méthode foo qui prend un entier et rends un booléen. Pourquoi donc avoir
inversé l'ordre type / nom par rapport à Java ? A n'en pas douter il y a une bonne raison dans l'inférence de type ou que sais-je, mais c'est un frein à la lisibilité par le développeur Java.
import truc._ plutôt que
import truc.* vous me direz que c'est un détail, mais pourquoi ne pas reprendre la même syntaxe ? Intention délibérée de se démarquer (inutilement) de Java ?
bon, évidemment on s'y fait et arrivée en "semaine 3" on n'y fait plus trop attention.
J'ai eu droit à ma plus belle volée de tweets (record absolu) en signalant mon désaccord sur la non-utilisation du return. Car, en java, pour un algorithme récursif j'aime utiliser return pour marquer la condition de sortie:
public int recurse(int x) {
if (x == 0) return 1;
recurse(x - 1)
}
ce qui peut se traduire en Scala sans soucis, mais les "bonnes pratiques" suggèrent plutôt
public int recurse(int x) {
if (x == 0) 1
else recurse(x - 1)
}
il paraît que c'est plus "fonctionnel", que ça ne brise pas la logique, ... bon on a enlevé un
return pour mettre un
else, perso je ne vois pas en quoi c'est plus élégant. J'ai eu le même genre de débat en java sur le return qui devait être unique dans une méthode, quitte à imbriquer des if en pagaille ... débat sans fin. Je sens que ce billet va avoir quelques commentaires :) Bon ça aussi on s'y fait vite
Slooooooow
Scala, c'est aussi une machine à genoux. Pour lancer le premier tutorial "hello world", j'ai du définir quelques -XX dans mon JAVA_OPTS sous peine de
OutOfMemoryException. Désolé, je n'ai qu'un MacBook Air 2Gb - mon MacBook est en réparation
La réputation de scala de ce côté semble fondée. Idem pour ses lenteurs de compilation : plusieurs longues secondes à attendre pour compiler les 3 classes de l'exercise, je n'ose pas imaginer un projet de grande ampleur. Je suis surtout étonné que le compilo puisse être
lent à ce point. Je n'ai jamais écrit de compilateur, donc je suis mal placé pour me prononcer, mais sur une syntaxe tout de même assez simple et déterministe que peut bien foutre le compilateur à mouliner pendant tout ce temps ? (->
quelques éléments de réponse) A part celui de GWT, je ne vois pas pire...
Ou alors, c'est que scalac est écrit lui-même en scala (attention, #troll inside). Car si la programmation fonctionnelle est une façon intéressante de structurer un programme, avec une approche orthogonale à la programmation impérative, j'ai de grosses interrogations lorsque j'écris un algo sur les performances finales. Immutabilité oblige, mes graphes de données vont être répliqués de nombreuses fois, créant miriades d'objets en mémoire. Ca a de nombreux avantages en termes de structure du code, de logique, de concurrence, mais avec un tel niveau d'abstraction que je ne sais fichtrement pas dire si ce que j'ai écrit à une chance d'être performant - déjà que je ne suis pas forcément sur de pouvoir garantir que mes récursions convergent ...
L'outil de build sbt est aussi ... "
étonnant", il va falloir que je creuse un peu : les projets d'exemple ont tous un répertoire "project" plein de scripts scala. A priori ce sont des "plugins" sbt. Sauf que si on doit les copier coller dans chaque projet, ce ne sont pas des "plugins" au sens maven/eclispe, partagé et réutilisables, mais des "copié-collés" ... ou au mieux des git-submodules comme on le fait avec les cookbooks puppet. A creuser
update : je suis rassuré, il y a de "
vrais" plugins SBT, les exos de coursera ont juste fait "
au plus vite" sur ce point. C'est un peu dommage, ça suggère de mauvaises pratiques du coup
J'attends la suite
Bref, je n'en suis qu'à la semaine 3, avec encore pas mal de boulot, et (j'espère) le temps de continuer parce que c'est vraiment trop bien fait et très intéressant. Je reste cependant encore sceptique. Je vois mal Scala être largement adopté par les développeurs lambda.
D'une part, et vous en avez certainement autour de vous, certains développeurs ont décidé de mettre leur cerveau à la retraite lorsqu'ils ont obtenu leur diplôme d'ingénieur. Ceux là ne pourront pas faire de scala, trop besoin de réfléchir.
De l'autre côté, vous avez les enthousiastes qui - eux au contraire - sont content de pouvoir
enfin se servir de leurs neurones, plutôt que d'écrire 200 lignes de code pour valider un formulaire.
Ces deux populations on les connaissait déjà (avec toute une palette intermédiaire) mais je trouve qu'un langage comme scala exacerbe ces différences. Dans un contexte de start-up avec des équipes réduites et triées sur le volet ça a du sens (
cloudbees a pas mal de code scala pour faire tourner la boutique, cause première de mon inscription sur coursera). Dans un contexte de SSII (pardon ESN), projet au forfait, "resources" pas cher et offshore, j'ai plus de mal à imaginer ce que ça peut donner.
Conclusion
Je suis content d'avoir l'occasion de découvrir un langage fonctionnel, qui apporte une vision nouvelle et me sera certainement profitable, au moins pour bien utiliser les lambdas en Java 8 (9?). J'attends avec impatience la suite des cours. Je souhaite à scala que quelqu'un se penche activement sur son compilateur et son outil de build, pour qu'il ne laissent pas au newbies come moi une sensation étrange de "
wtf ?". 500M de mémoire et 5 secondes pour un hello world ? Même ruby fait mieux
(L'avez vous remarqué, quelques trolls se sont glissés dans ce billet. Si vous les trouvez tous, vous pouvez gagner une place au BreizhCamp)
