Déboulonner les mythes de Scala

Question

Quelles sont les idées fausses les plus répandues sur le langage Scala, et quels sont les contre-exemples qui existent ?

UPDATE

Je pensais plutôt à diverses affirmations que j'ai vues, telles que "Scala est typée dynamiquement" et "Scala est un langage de script".

Je reconnais que "Scala est [simple/complexe]" peut être considéré comme un mythe, mais c'est aussi un point de vue qui dépend beaucoup du contexte. Ma conviction personnelle est que c'est le les mêmes caractéristiques qui peuvent faire apparaître Scala comme simple ou complexe selon la personne qui les utilise. En fin de compte, le langage ne fait qu'offrir des abstractions, et c'est la façon dont elles sont utilisées qui façonne les perceptions.

En plus de cela, il a une certaine tendance à enflammer les discussions, et je n'ai pas encore vu quelqu'un changer un point de vue bien ancré sur le sujet...

Answer 1

Mythe : Que Les types "Option" de Scala et "Maybe" de Haskell ne le fera pas vous sauver de la nullité . :-)

Démystifié : Pourquoi les types "Option" de Scala et "Maybe" de Haskell ? sera vous sauver de la nullité par James Iry.

Answer 2

Mythe : Scala supporte la surcharge des opérateurs.

En fait, Scala dispose simplement de règles de dénomination des méthodes très souples et d'une syntaxe infixe pour l'invocation des méthodes, avec des règles spéciales pour déterminer la priorité des méthodes lorsque la syntaxe infixe est utilisée avec des "opérateurs". Cette distinction subtile a des implications cruciales pour l'utilité et le potentiel d'abus de cette caractéristique du langage par rapport à une véritable surcharge d'opérateurs (à la C++), comme expliqué plus en détail dans la réponse de James Iry à la question suivante cette question .

Answer 3

Mythe : les méthodes et les fonctions sont la même chose.

En fait, une fonction est une valeur (une instance de l'un des éléments suivants FunctionN ), alors qu'une méthode ne l'est pas. Jim McBeath explique les différences plus en détail . Les distinctions pratiques les plus importantes sont :

• Seules les méthodes peuvent avoir des paramètres de type
• Seules les méthodes peuvent prendre des arguments implicites
• Seules les méthodes peuvent avoir des paramètres nommés et par défaut
• Lorsqu'on se réfère à une méthode, un trait de soulignement est souvent nécessaire pour distinguer l'invocation d'une méthode de l'application d'une fonction partielle (par ex. str.length est évalué à un nombre, tandis que str.length _ s'évalue à une fonction à zéro argument).

Answer 4

Je ne suis pas d'accord avec l'argument selon lequel Scala est difficile parce que vous pouvez utiliser des fonctionnalités très avancées pour faire des choses difficiles avec lui. L'évolutivité de Scala signifie que vous pouvez écrire des abstractions DSL et des API de haut niveau dans Scala même, qui autrement nécessiteraient une extension du langage. Pour être juste, il faut donc comparer les bibliothèques Scala aux compilateurs d'autres langages. Les gens ne disent pas que le C# est difficile parce que (je suppose, je n'ai pas de connaissance directe à ce sujet) le compilateur C# est assez impénétrable. Pour Scala, c'est tout à fait clair. Mais nous devons arriver à un point où il est clair que la plupart des gens n'ont pas besoin d'écrire du code à ce niveau, et ne devraient pas le faire.

Answer 5

Je pense qu'une idée fausse répandue parmi de nombreux développeurs Scala, ceux de l'EPFL (et vous-même, Kevin) est que "scala est un langage simple" . L'argument est généralement le suivant :

• scala a quelques mots-clés
• scala réutilise le même quelques constructions (par exemple Syntaxe PartialFunction est utilisé comme corps d'un bloc catch)
• scala dispose de quelques règles simples qui vous permettent de créer du code de bibliothèque (qui peut apparaître comme si le langage avait des mots-clés/constructions spéciaux). Je pense ici aux implicites, aux méthodes contenant des deux-points, aux symboles d'identification autorisés, à l'équivalence de X(a, b) y a X b avec des extracteurs. Et ainsi de suite
• de Scala site de déclaration La variance signifie que le système de type s'écarte de votre chemin. Plus de jokers et de ? super T

Mon opinion personnelle est que Cet argument est complètement et totalement faux. . Le système de types de Scala, associé aux implicites, permet d'écrire code franchement impénétrable pour le moyennement développeur . Toute suggestion contraire est tout simplement absurde, indépendamment de ce que les "mesures" ci-dessus pourraient vous faire penser. ( Notez ici que ceux que j'ai vus se moquer de la non-complexité de Java sur Twitter et ailleurs sont des types très intelligents qui, semble-t-il, ont compris les monades, les foncteurs et les flèches avant même d'avoir quitté leur pantalon court. ).

Les arguments évidents contre cela sont (bien sûr) :

1. tu ne le fais pas ont pour écrire un code comme celui-ci
2. vous n'avez pas à vous plier au moyennement développeur

Parmi celles-ci, il me semble que seule la n°2 est valable. Que vous écriviez ou non du code aussi complexe que scalaz Je pense qu'il est tout simplement stupide d'utiliser le langage (et de continuer à l'utiliser) sans avoir une réelle compréhension du système de types. Sinon, comment tirer le meilleur parti de ce langage ?