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)
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)
11 commentaires:
Hello,
Je vais essayer d'apporter quelques réponses, sans tomber dans le troll.
Sur la syntaxe d'abord
De mes lectures, l'inversion du type dans la signature permet d'avoir une grammaire régulière c'est également la raison pour val/var. Ca simplifie le travail du moteur d'inférence de type. Ca a déja été beaucoup critiqué et discuté (http://blog.joda.org/2011/07/reversed-type-declarations_4524.html)
L'import _ au lieu de * : scala essaye d'avoir un nombre de mots et de caractères réservés aussi petit que possible. le _ est utilisé comme wildcard dans tout le langage. * étant un opérateur mathématique très utilisé, avec du sens dans beaucoup de contextes, ils ont préféré le remplacer par _ Sans surprise la place des mathématique et des mathématiciens est assez importante dans la communauté d'un langage fonctionnel :)
En ce qui concerne scalac : Oui il est lent, je suis d'accord et ça me rends triste. Ceci au fur et a mesure de l'apprentissage du langage, quand on voit tout ce que le compilateur fait pour nous, on commence a comprendre que ça puisse être lent. Typesafe est conscient du problème et travaille dessus (pas mal d'optimisations prévues pour la 2.11)
En ce qui concerne le Xmx j'avoue que je ne comprends pas j'arrive a faire fonctionner des applications web REST incluant des connections à la base de donnée avec un Xmx à 32m donc je ne comprends pas qu'il aie fallu un Xmx512m pour un hello world. A mon avis il y a autre chose. J'aimerai voir le détail du projet.
En ce qui concerne SBT je pense qu'ils n'ont juste pas pris le temps de pacakger le plugin. Car évidement il n'y a pas besoin de copier d'un projet à l'autre, on peut l'ajouter comme dépendance au projet. Il y a déjà des dizaines de plugins pour SBT ( play2 inclut le sien, sbt-idea pour generer des projets intellij https://github.com/mpeltonen/sbt-idea formatage automatique avec scalariform https://github.com/mdr/scalariform etc)
@Jean il s'agit de l'exemple 1 du cours coursera, ce n'est pas lié au runtime scala (dans ton cas) mais aux outils de build sbt + scalac
C'est vrai que SBT est gourmand,je ne le défendrai pas trop je n'en suis pas un fan inconditionnel ... on peut tout a fait utiliser maven ou gradle pour builder des projets scala.
J'ai connu Coursera cet été et je confirme... c'est de la balle :)
Je suis moi aussi en train de suivre le cours de Scala, quoi que je pense que je ne pourrai pas le terminer comme il faut. Je me contente de regarder les vidéos dans le métro.
Juste une remarque. Quand tu dis "Immutabilité oblige, mes graphes de données vont être répliqués de nombreuses fois, créant myriades d'objets en mémoire" c'est pas complètement correct.
Scala devrait utiliser des "persistent data structures" qui permettent d'avoir de l'immutabilité en limitant la copie des données (et parfois de l’éviter complètement)
Utilisant quotidiennement Scala au boulot (mais depuis peu), je cherche à faire la part entre ce que Scala me fait gagner et ce qu'il me fait perdre.
Ce que me fait perdre Scala, c'est le temps qui est pris pour compiler les fichiers. Il paraît que Scala fait une dizaine de passes par fichier pour l'inférence de type, la résolutions des sucres syntaxiques, la résolution des types et la vérification de leur cohérence (il y a un système à la Prolog pour ça) et les divers optims. Mais en fait, ça veut aussi dire que Scala m'aide aussi à exprimer plus de chose et va m'aider à vérifier la cohérence de ce que j'écris avant même de lancer les tests unitaires !
En fait, ça se ressent dans le fait que je vois plus facilement les aspects métiers dans le code que je produis. Et je le vois plus facilement qu'en utilisant Java. En ça, Scala me fait gagner beaucoup de temps. Bien entendu, on est d'accord sur le fait que cela implique que le code en suivant une approche pragmatique, hein !
Sur ce propos, la vidéo de ma conf à Devoxx devrait paraître sous peu. Sinon, si tu passes à Paris, j'ai un ou deux BBL sur le sujet ;)
En effet cette formation Coursera est excellente. Si je peux donner un petit conseil, prévoir un peu plus de temps pour les exercices à parir de la week 4 :)
La syntaxe du return demandée par coursera n'est sans doute là que pour nous dire "Attention, tu peux faire un return sans le mot clé".
Dans la pratique, http://twitter.github.io/effectivescala/#Control structures-Returns est tout à fait en accord avec ta remarque.
Enregistrer un commentaire