Des amateurs de Scala ? - Page 2

et le plus secure.

Scala n'est pas une surcouche de Java, il fournit un binaire compatible au niveau binaire (histoire de pouvoir réutiliser l'écosystème logiciel).
Mais du coup, on retrouve un certain nombre de défauts de Java…

./29 > Parce que c'est pas une surcouche de Java. C'est un autre langage (plus moderne, dira-t-on) qui compile vers le même bytecode que Java, et donc dont les programmes sont exécutés par la JVM. Mais d'après ce que j'ai compris, les concepteurs de Scala en chient méchamment pour implémenter certaines fonctionnalités à cause de ça. ^^

Il est indéniable que Scala est plus pratique que Java, mais je trouve qu'on ne peut pas vraiment faire du Scala sans connaître Java avant.

Comme je l'ai dit, on a les héritages suivants :
* int -> AnyVal -> Any,
* String -> AnyRef -> Any.

Maintenant, on tente les choses suivantes :

val src = Array("1", "2", "3", "4")
val casted = src.asInstanceOf[Array[Any]]

=> Ça compile, et ça fonctionne

val src = Array(1, 2, 3, 4)
val casted = src.asInstanceOf[Array[Any]]

=> Ça compile, mais ça ne fonctionne pas (erreur à l'exécution ! dire que quand on fait du Scala, on nous dit tout le temps que grâce à la magie du typage, si ça compile, ça fonctionne…)

Hmm mais ça, ça pourrait jamais fonctionner avec le même genre de modèle que celui sur lequel fonctionne Java.
Le fait que ça marche dans un cas vient d'un truc qui est parfois considéré comme une erreur de design du Java (qu'on se traine en .NET pour des raisons de compatibilité), le fait que les tableaux soient covariants:
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29#Covariant_arrays_in_Java_and_C.23
http://c2.com/cgi/wiki?JavaArraysBreakTypeSafety
En fait, un langage/runtime bien conçu devrait interdire d'utiliser un tableau de X comme un tableau de Y dans tous les cas.
Scala te reflète le comportement de Java ici, mais ils auraient aussi pu interdire d'utiliser la covariance des tableaux pour être plus consistants. Par contre c'est pas certain que tout le monde en aurait été content.

GoldenCrystal (./35) :
En fait, un langage/runtime bien conçu devrait interdire d'utiliser un tableau de X comme un tableau de Y dans tous les cas.

Pas forcément tous les cas : si le tableau est en lecture seule, pourquoi ne pourrait-il pas être covariant ?

(il doit bien avoir que sur yN qu'on parle de tableaux covariants un 25 décembre au soir )

./36 > Oui, en effet, dans ce cas, ça ne poserait pas de problème

GoldenCrystal (./35) :
Hmm mais ça, ça pourrait jamais fonctionner avec le même genre de modèle que celui sur lequel fonctionne Java.
Le fait que ça marche dans un cas vient d'un truc qui est parfois considéré comme une erreur de design du Java (qu'on se traine en .NET pour des raisons de compatibilité), le fait que les tableaux soient covariants:
http://en.wikipedia.org/wiki/Covariance_and_contravariance_%28computer_science%29#Covariant_arrays_in_Java_and_C.23
http://c2.com/cgi/wiki?JavaArraysBreakTypeSafety
En fait, un langage/runtime bien conçu devrait interdire d'utiliser un tableau de X comme un tableau de Y dans tous les cas.
Scala te reflète le comportement de Java ici, mais ils auraient aussi pu interdire d'utiliser la covariance des tableaux pour être plus consistants. Par contre c'est pas certain que tout le monde en aurait été content.

Oui, je connais le problème de la covariance, mais dans mon cas, je ne vois vraiment pas comment je peux faire autrement ^^
Le point que je mettais en avant, c'est que j'ai un problème purement Scala qui ne peut être compris qu'en connaissant Java (alors que j'ai même pas 10 jours de Scala derrière moi, on ne peut pas dire que je sois allé très loin).

Je n'ai jamais eu de problème Java, CAML, PHP ou Python demandant de connaître le C/C++ pour être compris.

Bon, j'ai trouvé une autre blague avec Scala :
il y a manifestement des différences entre Scala 2.10 et Scala 2.11. Jusqu'à là, ce n'est pas trop grave.
Ce qu'il y a de rigolo, ce que les dépendances sont écrites ainsi dans le fichier de build (on a par exemple dans Maven spark_2.10-1.2.0 et spark_2.11-1.2.0). Si je veux avoir un code qui donne un binaire 2.10 et un binaire 2.11, j'ai besoin de deux fichiers build.sbt.

Par exemple, dans les sources de Spark, il y a un script permettant de compiler en 2.11 (par défaut il compile en 2.10), qui va chercher tous les fichiers pom.xml et pour remplacer brutalement 2.10 par 2.11 #propre#

> publish-local
[info] Packaging /Users/XXXXXXXXXXXXXXXXXX-1.0.3-sources.jar ...
[info] Done packaging.
[info] Wrote /Users/XXXXXXXXXXXXXXXXXX-1.0.3.pom
[info] :: delivering :: XXXXXXXXX#XXXXXXX;1.0.3 :: 1.0.3 :: release :: Sun Jan 04 13:04:33 CET 2015
[info] 	delivering ivy file to /Users/XXXXXXXXXXXXXXXXXX-ivy-1.0.3.xml
[info] Main Scala API documentation to /Users/XXXXXXXXXXXXXXXXXX-/target/api...
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: PermGen space

Le système de package (même pas la compilation !) fait un OOM Je sais que je n'ai que 4Go de RAM, mais quand même…

ouch ^^ Tu génères un package qui devrait faire à peu près quelle taille ?

10 Mo (mais normalement, il n'a qu'à recopier des fichiers existants)

flanker (./34) :
si ça compile, ça fonctionne…)

Le débile qui a osé écrire cela, n'a jamais écrit de programme de sa vie ca c'est sur !!



GT Planté !

flanker (./41) :
Le système de package (même pas la compilation !) fait un OOM Je sais que je n'ai que 4Go de RAM, mais quand même…

Par défaut une Jvm ne dépasse pas 512Mo, si tu veux plus il faut le préciser dans la ligne de commande. Et pour le Pergem comme dans ton cas, c'est encore bien moins : 64Mo.

Ça reste énorme pour une simple de fichiers (il n'y a aucun calcul !)

Le permgem ne contient pas la mémoire qui sert a faire les traitement mais tout le code (définitions des classes, méthodes, ...) donc vu le bordel surchargé de classes que tu as décris, ça ne me surprend pas vraiment. Si tu veux augmenter le permgen c'est -XX:MaxPermSize=128m (pour 128Mo par exemple)

je pense qu'en pratique, il y a pas mal de classes : on est poussé à utiliser les lambda, et chaque lambda donnera une classe…
Merci pour l'info

http://stackoverflow.com/questions/10375633/understanding-implicit-in-scala?answertab=active#tab-top

Pour moi qui préfère largement l'explicite à l'implicite, (même si je trouve l'idée pas mal)

Bon, je n'ai pas encore fait de Scala mais j'en ai un peu lu ces derniers temps et ça ne m'a pas donné envie du tout. OK, c'est beaucoup plus concis que Java (pas difficile), mais c'est un peu poussé à l'extrême je trouve. Il y a plein de raccourcis d'écriture qui permettent de gratter quelques caractères mais qui je trouve ont deux gros défauts :

- Ils rendent la lecture plus difficile
- À cause d'eux, il y a très souvent deux, trois ou davantage de façons d'écrire la même chose en Scala

Par exemple le caractère "_" qui sert tantôt de nom court pour les tuples (t._1, t._2, etc), tantôt d'opérateur magique pour transformer une méthode en fonction ( cette différence d'ailleurs), ou encore de nom de paramètre par défaut histoire de gagner 4 caractères quand on écrit une lambda. De même, je trouve que le mécanisme de paramètres implicites qu'a déjà expliqué Flanker est une catastrophe, quand on lit du code en-dehors d'une IDE capable de comprendre le Scala (et le langage est tellement ambigu qu'il n'y a pas beaucoup d'IDE qui s'en sortent) c'est un enfer, impossible de savoir ce que fait un appel de fonction auquel il manque un paramètre (à supposer qu'on se rende compte qu'il manque un paramètre) : il peut venir de n'importe où, y compris d'un autre fichier. Pour faire des revues de code c'est un vrai bonheur.

Je n'ai encore expérience dans ce langage mais j'ai l'impression qu'ils ont tellement essayé d'y coller toutes les features d'autres langages, aussi bien fonctionnels que procéduraux, que ça en fait un mélange beaucoup trop complexe à maitriser et dans lequel il y a toujours 50 solutions à un même problème. Pas convaincu.

Copaing !

Pour la concision, ce n'est pas toujours le cas : une bonne partie de la stdlib Scala est en fait la stdlib java, donc on se retrouve avec quelque chose de verbeux.
Pour les implicites, je trouve qu'il y a un autre problème : les imports automatiques fonctionnent super mal. L'IDE est incapable de savoir quel module il faut importer pour que l'objet récupère la bonne méthode (et c'est super pénible).

Oh y'a pas que ça, je suis tombé sur des comportements amusants : imaginons que tu as une fonction "toto(a: A, b: B)(implicit c: C, d: D)". Puis à un moment tu as envie de spécifier explicitement tous les paramètres, donc tu l'appelles comme ça :toto(appel_qui_renvoie_un_A(), appel_qui_renvoie_un_B())(appel_qui_renvoie_un_C(), appel_qui_renvoie_un_D())
Bon, ça fait quand même une ligne un peu longue, donc tu es tenté de la couper en deux :toto(appel_qui_renvoie_un_A(), appel_qui_renvoie_un_B()) (appel_qui_renvoie_un_C(), appel_qui_renvoie_un_D())
Manque de bol, il y avait deux objets de type "C" et "D" qui trainaient dans le scope actuel, tu as donc perdu : sans t'en rendre compte, ton appel (qui était tout à fait valide) vient de se transformer en deux statements distincts, le premier étant l'appel d'une fonction qui prend tes deux paramètres explicites + les deux paramètres implicites trouvés dans le scope, le second étant un tuple de deux objets "C" et "D" qui n'a aucun effet mais reste valide. Ça compile, aucune erreur n'est détectée, par contre à l'exécution ça risque de ne pas faire exactement ce qui était prévu.

Ça parait un peu tiré par les cheveux, mais on a déjà eu ce cas de figure qui est arrivé dans du vrai code

Perso je fais du coffeescript au boulot et la concision ajoute des tas et des tas de fautes possibles, parce que syntaxiquement tout est valable, mais l'effet après…
Par exemple tu peux supprimer les parenthèses pour les appels de fonction, et en admettant que tu as 2 fonctions add(a, b, callback) et sub(a, b), si tu écris ceci :

a = add 10, 20, (err, result)->
    console.log result

Ca marche bien, mais maintenant chaînes-y une opération sans faire gaffe :

a = add 10, sub 20, 10, (err, result)->
    console.log result

Ca va compiler mais potentiellement péter au runtime (en fait t'en sais rien parce que le javascript est super permissif, mais t'auras pas le bon résultat en tous cas) puisque le callback est passé à sub. Là ça paraît assez évident, mais c'est en pratique facile de l'oublier, et si tu n'as pas 100% de test coverage tu mettras vraiment de la merde en prod (ce n'est pas rare d'avoir 3+ bugs graves -- genre ça te pète le process en cours de traitement d'une requête HTTP à cause d'une exception imprévue -- par ligne de code coffeescript !).

C'est exactement pour ça que j'évite coffeescript comme le cancer. Et tout langage qui n'a pas une syntaxe stricte. Je ne dis pas que c'est mauvais, mais je sais que je ferais des erreurs.

./52 > C'est gerbant ton exemple (Mais c'est du CoffeeScript, c'est pas de ta faute… J'avais lu la page d'accueil de leur site, ça m'avait dissuadé à vie d'y toucher)
En plus la concision, la concision… Si le code devient imprécis, ça ne sert à rien. (C'est tout pareil que les if sans accolade en C & dérivés. C'est bien, mais sans discipline, on fait très facilement de la merde.)

Honnêtement, pour avoir fait pas mal de VB dans le temps, langage qui a une gestion des parenthèses "originale", ça marchait très bien parce que la règle était définie de manière sensée: parenthèse obligatoire pour un appel type fonction (dont on utilise la valeur de retour), parenthèse interdite pour un appel type instruction (la valeur de retour part à la poubelle s'il y en avait une), et en plus de ça, on ne pouvait pas séparer une ligne en deux n'importe comment.
Et pourtant, c'était vraiment chiant, parce que c'est pas consistant.

À mon sens, la consistance est au moins aussi importante que la concision. Ça permet de réfléchir un peu moins avant d'écrire un truc et surtout un peu moins en lisant. (Visualisez un langage où la priorité des opérateurs ne serait pas la même entre une condition et la partie droite d'un opérateur d'affectation… Vous ne voudriez pas de ça.)

./51 > Scala n'utilise pas de terminateur de lignes ? C'est moche

GoldenCrystal (./54) :
./51 > Scala n'utilise pas de terminateur de lignes ? C'est moche

Je trouve que ça se défend, il y a plein de langages où la syntaxe ne nécessite pas de terminateur de ligne (tant qu'elle n'est pas ambiguë)

Oui et non, c'est justifié quand c'est bien fait et sans ambiguïté (Python,), mais là c'est une invitation à se tirer une balle dans le pied je trouve.

AMHA, il faut absolument soit un terminateur de lignes (par exemple le ';' du C), soit au contraire un continueur de lignes (par exemple le '_' du BASIC). Le compilateur ne peut pas deviner!

Quel est le problème avec Python alors ?

En effet python utilise une troisième possibilité pour faire ça sans risque d'ambiguïté : l'indentation significative, ce que personnellement, je n'aime pas du tout.

Je ne connais qu'un seul langage qui permet vraiment de se passer de séparateur de lignes (sans compromis), et c'est le T-SQL. Microsoft conseille malgré tout de terminer ses lignes par ; et c'est obligatoire pour toutes les instructions nouvellement ajoutées à leur implémentation. (Ce n'est pas le cas de Sybase qui au dernières nouvelles ne reconnaissait pas le ; )

En fait, le réel compromis c'est que cest le bordel à parser. On peut difficilement se placer au milieu d'une requete et déterminer algorithmiquement où débute l'instruction et où elle se termine. (Pas sans écrire un parser complet tout du moins)