Je ne sais pas si j'aurai beaucoup d'occasions de pratiquer - nous avons du Scala chez CloudBees, mais honnêtement je passe plus de temps dans le code de Jenkins ... ce qui est une autre affaire - cependant je voulais vous partager mes impressions :
les plus
- L'inférence de type est impressionnante. On ne déclare jamais un type de variable, un cast ou que sais-je d'inutile. L'évolution "diamond operator" de Java 7 pour simplifier (sic) les génériques fait bien rigoler à côté. J'espère que le compilo Java sera un jour aussi puissant, cela réduit considérablement la pollution du code
- Le plugin IntelliJ pour Scala est excellent.
- Le cours était autant sur l'approche fonctionnelle que sur le langage Scala, étant mon premier langage fonctionnel c'était donc très enrichissant. De mon point de vue c'est un excellent complément à l'impératif, et ça vaut vraiment le coup de s'y pencher. Ce que j'aime c'est que Scala autorise le mix des deux, on a donc le meilleur des deux mondes
- On peut définir des abstractions vraiment puissantes, et encore j'effleure juste le potentiel de Scala, mais c'est plutôt plaisant.
- J'ai apprécié dans le cours que pour présenter un traitement, Martin Odersky propose une syntaxe plus "compacte", plus "fonctionnelle", en précisant que c'est à chacun d'utiliser celle qui lui parle le plus. C'est important à mon avis de ne pas tomber dans le terrorisme fonctionnel qu'on reproche à certains développeurs scala.
- Le plugin IntelliJ pour Scala est excellent. Sérieusement. J'ai fait les premières "semaines" avec vi mon MacBook étant en réparation, et le MacBook Air 2Gb trop léger pour supporter l'IDE. En même temps c'est formateur, mais retrouver un IDE super puissant aide énormément.
les moins
- La syntaxe est parfois déroutante. Elle permet des expressions très compactes, mais du même coup potentiellement obscures. Pour des cas simples ça se justifie, mais on a vite fait de se prendre soi-même au pièges, et je ne parle même pas de bosser avec des scala(f)istes chevronnés. Plus que dans un autre langage amha il faut être très vigilant sur la structuration de son code
- Il faut vraiment réfléchir à ce qu'on fait. C'est con, mais c'est fatigant. Développer un putain d'écran en struts, ça prend 3 jours mais y'a pas trop à se fatiguer la tête ;) Plus sérieusement, quand y'a un truc qui cloche on se creuse bien la tête pour démêler tout ça, il est donc important d'avoir une structuration très propre du code, avec méthodes bien ciblées et tests unitaires. Vous me direz, on fait déjà tous ça en Java, isn't it ?
- Les OOME:PermGen de SBT, c'est tout de même la misère cet outil. Je me demande ce qu'il donne sur un "gros" projet.
- J'ai vraiment eu du mal à me faire à la syntaxe des for {} yield. Au début j'ai préféré écrire les cas simples en Range.map() qui me semblaient plus clair. C'est sans doute une question d'habitude ?
Très content d'avoir pu suivre ce cours, surtout qu'il est vraiment très bien fait (ne manquez pas le hands-on Scala au breizhcamp). J'ai appris une approche différente et apprécié certains aspects de Scala, qui me titillerons probablement dans du futur code Java, comme le fait déjà Groovy quand un peu de "dynamique" m'aiderait bien.
Scala est un bon langage, élégant (comme le montre la photo), puissant, très complet, souple (fonctionnel et impératif), mais je ne crois pas qu'il deviendra un langage mainstream : trop complexe et exigeant. Par contre, croire que Java 8 apportera un équivalent "fonctionnel" avec les lambdas est une vision bien simpliste des choses, cela permettra des choses mais ce sera le fonctionnel du pauvre. Surtout qu'apprendre Java 8 pour un junior aujourd'hui, avec les génériques, lambda, et 250 frameworks ce n'est pas un cadeau.
J'attends donc un (futur) langage, un Scala bridé mais plus accessible, un peu comme Java le fut à l'époque de C++.
3 commentaires:
Par rapport à ta dernière remarque : kotlin pourrait permettre de compenser ce gap entre limitations de java et complexité de scala...
@Nicolas: ton article est très intéressant ! Merci pour ce retour :)
Pour la complexité du langage, je suis d'accord par rapport aux exercices proposés. Mais sur un projet de plus grande envergure, ça me paraît beaucoup plus nécessaire d'avoir un langage qui fait ch*er sur les types. Je veux dire que de devoir réfléchir au préalable pour des fonctionnalités que l'on va mettre en place, c'est mieux que de devoir réfléchir a posteriori pour des bugs qui n'ont pas été vu par le compilateur, non ? Java pèche sur ce point.
Pour le for/yield vs map (voire flatMap/filter/map), c'est clairement une question d'habitude au départ. Mais je pense qu'à terme, la forme for/yield doit prévaloir, car elle apporte un gain en lisibilité important sur des expressions plus complexes.
Sur ces deux points, je te propose de voir les slides de ma sessions à DevoxxFR'13 (en attendant la vidéo) :
http://parleys.com/play/51576a18e4b0ffdd7e058b3a/chapter0/about
Salut Nicolas,
Merci tes comptes-rendus de ton exploration curieuse et enjouée, et pas spécialement trollesques.
Un petit mot sur les scala(f)istes. je vais t'avouer un truc, je trouve la communauté scala plus sympa que la communauté java. Moins de concours de b... , sur la taille du projet, le merdier du legacy etc. moins de positions péremptoires et de domaines à défendre, ça fait moins bistro d'entreprise.
J'ai par hasard rencontré et discuté avec quelques gars dans la commmunauté (mondiale) et j'ai eu la même impression positive qu'avec les gars de la communauté française. Ils étaient jeunes, super détendus, ils ne se la ramenaient pas du tout, étaient à l'écoute de l'autre et étaient pas du tout trollesques ou péremptoires. Et je les ai vu discuter les uns les autres ils étaient juste en train de déconner et de se vanner.
Franchement ce côté détendu et pas prise de tête m'a étonné.
Il y a bien sûr des gens qui se la pêtent, qui ont trouvé dans scala un outil générateur de troll et de fashion qui soit plus mainstream que haskell. Chacun sa vie... Je n'ai aucun goût pour les trolls guerriers, les positions dogmatiques, les luttes de territoires, etc. C'est pour ça que je me suis désinscrit un long moment de la ML des cast codeurs ;)
Pour ce qui est du choix entre for / map, on a la même chose en erlang et mon choix se détermine souvent comme ça : si je dois obtenir une structure de données, une liste de trucs, que je vais utiliser ou afficher, j'utiliserai plutôt le for. Si j'ai une transformation de données qui est un peu un "usinage" de la donnée (je vais un peu transformer la structure de données, et la réutiliser plus tard) (le plus souvent cet usinage sera mis dans un val x=..) 'aime bien le map, qui montre bien qu'on a affaire à un traitement sur des données.
Comme on dit en Perl "there is more than one way to do it" http://en.wikipedia.org/wiki/There's_more_than_one_way_to_do_it
Quoiqu'il en soit je trouve extra qu'un mec qui dirige un langage en plein boum, prenne le temps de donner des cours et de préparer des cours pour coursera (c'est beaucoup beaucoup de travail!).
Si jamais tu veux aller plus loin dans la programmation fonctionnelle et la théorie des langages, j'ai adoré le cours proglang chez coursera. Très complet, bien balaise, le prof est d'enfer. C'est un niveau plus élevé que le cours d'Odersky, il touche aussi à la programmation objet, aux langages dynamiques/statiques...
Au plaisir!
Enregistrer un commentaire