Frage Debakeln Scala Mythen [geschlossen]


Was sind die häufigsten Missverständnisse über die Sprache Scala und welche Gegenbeispiele gibt es dazu?

AKTUALISIEREN

Ich habe mehr über verschiedene Behauptungen nachgedacht, wie "Scala ist dynamisch getippt" und "Scala ist eine Skriptsprache".

Ich akzeptiere, dass "Scala ist [einfach / komplex]" als ein Mythos betrachtet werden kann, aber es ist auch ein Standpunkt, der sehr vom Kontext abhängig ist. Meine persönliche Überzeugung ist, dass es das ist sehr ähnliche Eigenschaften Das kann Scala entweder einfach oder komplex erscheinen lassen, je nachdem, wer sie benutzt. Letztendlich bietet die Sprache nur Abstraktionen, und auf diese Weise werden Wahrnehmungen geformt.

Nicht nur das, aber es hat eine gewisse Tendenz, Argumente zu entfachen, und ich habe noch niemanden gesehen, der einen stark vertretenen Standpunkt zu dem Thema geändert hat ...


59


Ursprung


Antworten:


Mythos: Scala unterstützt das Überladen von Operatoren.

Tatsächlich verfügt Scala über sehr flexible Methodenbenennungsregeln und Infixsyntax für den Methodenaufruf, mit speziellen Regeln zur Bestimmung der Methodenpriorität, wenn die Infix-Syntax mit 'Operatoren' verwendet wird. Diese subtile Unterscheidung hat kritische Implikationen für den Nutzen und das Potential für den Missbrauch dieses Sprachmerkmals im Vergleich zu einer echten Operatorüberlastung (a la C ++), wie in James Irys Antwort auf diese ausführlicher erläutert diese Frage.


35



Mythos: Das Scala's "Option" und Haskells "Maybe" -Typen Gewohnheit rette dich von null. :-)

Entlarvt: Warum Scala's "Option" und Haskells "Maybe" -Typen werden rette dich von null von James Iry.


40



Ich stimme nicht mit dem Argument überein, dass Scala schwer ist, weil Sie sehr fortgeschrittene Funktionen verwenden können, um harte Sachen damit zu machen. Die Skalierbarkeit von Scala bedeutet, dass Sie in Scala selbst DSL-Abstraktionen und High-Level-APIs schreiben können, die sonst eine Spracherweiterung benötigen. Um fair zu sein, müssen Sie Scala-Bibliotheken mit anderen Sprachen-Compilern vergleichen. Die Leute sagen nicht, dass C # hart ist, weil (ich nehme an, nicht aus erster Hand Wissen darüber) der C # -Compiler ist ziemlich undurchdringlich. Für Scala ist alles offen. Aber wir müssen zu einem Punkt kommen, an dem wir klarstellen, dass die meisten Menschen auf dieser Ebene keinen Code schreiben müssen und dies auch nicht tun sollten.


32



Ich denke, ein übliches Missverständnis unter vielen Scala-Entwicklern, an der EPFL (und an Ihnen, Kevin) ist das "scala ist eine einfache Sprache". Das Argument geht normalerweise so:

  • Scala hat einige Schlüsselwörter
  • scala verwendet dasselbe einige Konstrukte (z.B. PartialFunction-Syntax wird als Körper eines Fangblocks verwendet)
  • Scala hat ein paar einfache Regeln mit denen Sie einen Bibliothekscode erstellen können (der so aussieht, als hätte die Sprache spezielle Schlüsselwörter / Konstrukte). Ich denke hier an implicits; Methoden, die Doppelpunkte enthalten; erlaubte Bezeichnersymbole; die Äquivalenz von X(a, b) und a X b mit Extraktoren. Und so weiter
  • Scala Deklarationsseite Varianz bedeutet, dass das Typsystem Ihnen nur aus dem Weg geht. Keine Wildcards mehr und ? super T

Meine persönliche Meinung ist das Dieses Argument ist völlig und völlig falsch. Scala's Typsystem zusammen mit implicits ermöglicht es einem zu schreiben Offensichtlich undurchdringlicher Code für die durchschnittlich Entwickler. Jeder Vorschlag ist einfach grotesk, unabhängig davon, was die obigen "Metriken" zum Nachdenken anregen. (Beachten Sie hier, dass diejenigen, die ich über die Unkompliziertheit von Java auf Twitter und anderswo gespottet habe, übertrieben schlaue Typen sind, die, wie es manchmal scheint, Monaden, Funktoren und Pfeile im Griff hatten, bevor sie keine kurzen Hosen hatten).

Die offensichtlichen Argumente dagegen sind (natürlich):

  1. du nicht haben Code so schreiben
  2. Sie müssen nicht zu den durchschnittlich Entwickler

Von diesen scheint mir nur Nummer 2 gültig zu sein. Ob Sie Code so komplex wie schreiben oder nicht ScalazIch denke, es ist einfach albern, die Sprache zu benutzen (und sie weiterhin zu benutzen), ohne das Typsystem wirklich zu verstehen. Wie sonst kann man das Beste aus der Sprache herausholen?


28



Mythos: Methoden und Funktionen sind das Gleiche.

Tatsächlich ist eine Funktion ein Wert (eine Instanz eines der FunctionN Klassen), während dies bei einer Methode nicht der Fall ist. Jim McBeath erklärt die Unterschiede genauer. Die wichtigsten praktischen Unterschiede sind:

  • Nur Methoden können Typparameter haben
  • Nur Methoden können implizite Argumente annehmen
  • Nur Methoden können benannte und Standardparameter haben
  • Wenn auf eine Methode Bezug genommen wird, ist häufig eine Unterstreichung erforderlich, um den Methodenaufruf von einer Teilfunktionsanwendung (z. str.length bewertet zu einer Zahl, während str.length _ wird zu einer Null-Argument-Funktion ausgewertet).

24



Es gibt einen Mythos, dass Scala schwierig ist, weil Scala eine komplexe Sprache ist.

Das ist falsch - Scala ist mit einer Vielzahl von Metriken nicht komplexer als Java. (Größe der Grammatik, Codezeilen oder Anzahl der Klassen oder Anzahl der Methoden in der Standard-API, etc ..)

Aber es ist unbestreitbar, dass Scala-Code ungeheuer schwer zu verstehen ist. Wie kann das sein, wenn Scala keine komplexe Sprache ist?

Die Antwort ist, dass Scala eine ist mächtig Sprache. Im Gegensatz zu Java, das viele spezielle Konstrukte (wie Enums) besitzt, die eine bestimmte Sache erfüllen - und erfordert, dass Sie spezialisierte Syntax lernen, die nur für diese eine Sache gilt, hat Scala eine Vielzahl von sehr allgemeinen Konstrukten. Durch Mischen und Anpassen dieser Konstrukte kann man sehr komplexe Ideen mit sehr wenig Code ausdrücken. Und wenn jemand kommt, der nicht die gleiche komplexe Idee hatte und versucht, herauszufinden, was Sie mit diesem sehr kompakten Code machen, werden sie es vielleicht entmutigend finden - sogar noch entmutigender, als wenn sie ein Paar sehen würden von Code-Seiten, um das Gleiche zu tun, denn dann würden sie zumindest erkennen, wie viel konzeptionelles Zeug es zu verstehen gab!

Es gibt auch eine Frage, ob die Dinge komplexer sind, als sie wirklich sein müssen. Zum Beispiel machen einige der Art Gymnastik in der Sammlung Bibliothek die Sammlungen eine Freude zu bedienen, aber verblüffend zu implementieren oder zu erweitern. Das Tore Hier sind nicht besonders kompliziert (z. B. Unterklassen sollten ihre eigenen Typen zurückgeben), aber die Methoden benötigt (höher-kinded Typen, implizite Builder, etc.) sind komplex. (So ​​komplex, dass Java einfach aufgibt und es nicht versucht, anstatt es "richtig" wie in Scala zu tun. Auch gibt es im Prinzip die Hoffnung, dass sich dies in Zukunft verbessern wird, da sich die Methode weiterentwickeln kann um das Ziel besser zu erreichen.) In anderen Fällen, die Tore sind komplex; list.filter(_<5).sorted.grouped(10).flatMap(_.tail.headOption) ist ein bisschen ein Durcheinander, aber wenn Sie wirklich alle Zahlen kleiner als 5 nehmen möchten, und dann jede zweite Zahl von 10 in der verbleibenden Liste nehmen, nun, das ist nur eine etwas komplizierte Idee, und der Code sagt ziemlich was es tut, wenn Sie die grundlegenden Sammlungen Operationen kennen.

Zusammenfassung: Scala ist nicht komplex, aber Sie können komplexe Ideen kompakt ausdrücken. Der kompakte Ausdruck komplexer Ideen kann entmutigend sein.


Es gibt einen Mythos, dass Scala nicht einsetzbar ist, während eine breite Palette von Java-Bibliotheken von Drittanbietern ohne weiteres eingesetzt werden kann.

In dem Maße, wie dieser Mythos existiert, vermute ich, dass er unter Menschen existiert, die es nicht gewohnt sind, eine virtuelle Maschine und ein API von einer Sprache und einem Compiler zu trennen. Wenn Sie Java == javac == Java API im Kopf haben, werden Sie vielleicht etwas nervös, wenn jemand Scalac anstelle von javac vorschlägt, weil Sie sehen, wie gut Ihre JVM läuft.

Scala endet als JVM-Bytecode plus seiner eigenen benutzerdefinierten Bibliothek. Es gibt keinen Grund, sich mehr Sorgen darüber zu machen, Scala im kleinen Maßstab oder als Teil eines anderen großen Projekts zu implementieren, da eine beliebige andere Bibliothek bereitgestellt wird, die mit der von Ihnen bevorzugten JVM kompatibel ist oder auch nicht. Zugegeben, das Scala-Entwicklungsteam wird nicht so stark unterstützt wie die Google-Sammlungen oder Apache Commons, aber es hat mindestens genauso viel Gewicht hinter sich wie Dinge wie das Java Advanced Imaging-Projekt.


20



Mythos:

def foo() = "something"

und

def bar = "something"

ist dasselbe.

Es ist nicht; Du kannst anrufen foo(), aber bar() versucht, die Methode apply von StringLike ohne Argumente aufzurufen (führt zu einem Fehler).


15



Einige häufige Missverständnisse bezüglich der Actors-Bibliothek:

  • Akteure behandeln eingehende Nachrichten parallel, in mehreren Threads / gegen einen Thread-Pool (die Behandlung von Nachrichten in mehreren Threads steht im Gegensatz zum Aktor-Konzept und kann zu Rennbedingungen führen - alle Nachrichten werden sequentiell in einem Thread behandelt (Thread-basiert) Akteure verwenden einen Thread sowohl für die Postfachverarbeitung als auch für die Ausführung, Event-basierte Akteure können sich einen VM-Thread für die Ausführung teilen, wobei ein Multithread-Executor zur Planung der Postfachverarbeitung verwendet wird)
  • Nicht erfasste Ausnahmen ändern nicht das Verhalten / Status des Akteurs (alle nicht abgefangenen Ausnahmen beenden den Akteur)

14



Mythos: Sie können eine Falte durch eine Reduzierung ersetzen, wenn Sie etwas wie eine Summe von Null berechnen.

Dies ist ein häufiger Fehler / Missverständnis bei neuen Benutzern von Scala, insbesondere solchen ohne vorherige funktionale Programmiererfahrung. Die folgenden Ausdrücke sind nicht gleichwertig:

seq.foldLeft(0)(_+_)

seq.reduceLeft(_+_)

Die beiden Ausdrücke unterscheiden sich darin, wie sie mit der leeren Sequenz umgehen: Die Faltung erzeugt ein gültiges Ergebnis (0), während das Reduzieren eine Ausnahme auslöst.


14



Mythos: Pattern-Matching passt nicht gut zum OO-Paradigma.

Entlarvt Hier von Martin Odersky selbst. (Siehe auch dieses Papier - Objekte mit Mustern abgleichen - von Odersky et al.)


12



Mythos: this.type bezieht sich auf den gleichen Typ, der durch this.getClass.

Als Beispiel für dieses Missverständnis könnte man annehmen, dass im folgenden Code der Typ von v.me ist B:

trait A { val me: this.type = this }

class B extends A

val v = new B

In Wirklichkeit, this.type bezieht sich auf den Typ, dessen einzige Instanz ist this. Im Algemeinen, x.type ist der Singleton-Typ, dessen einzige Instanz ist x. Also im obigen Beispiel der Typ von v.me ist v.type. Die folgende Sitzung demonstriert das Prinzip:

scala> val s = "a string"
s: java.lang.String = a string

scala> var v: s.type = s
v: s.type = a string

scala> v = "another string"
<console>:7: error: type mismatch;
 found   : java.lang.String("another string")
 required: s.type
       v = "another string"

9