Ist die Scala 2.8-Sammlungsbibliothek ein Fall von "dem längsten Selbstmordbrief in der Geschichte"?

Question

Ich habe gerade erst begonnen, mir die Neuimplementierung der Scala-Sammlungsbibliothek anzuschauen, die mit dem bevorstehenden 2.8-Release kommt. Diejenigen, die mit der Bibliothek aus 2.7 vertraut sind, werden feststellen, dass sich die Bibliothek aus einer Verwendungs-Perspektive wenig geändert hat. Zum Beispiel...

> List("Paris", "London").map(_.length)
res0: List[Int] List(5, 6)

...würde in beiden Versionen funktionieren. Die Bibliothek ist äußerst benutzerfreundlich: tatsächlich ist sie fantastisch. Allerdings müssen sich diejenigen, die früher nicht mit Scala vertraut waren und sich jetzt umsehen, um ein Gefühl für die Sprache zu bekommen, nun mit Methodensignaturen auseinandersetzen wie:

def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That

Für eine so einfache Funktionalität ist dies eine einschüchternde Signatur, bei der ich mich selbst dabei erwische, dass ich Schwierigkeiten habe, sie zu verstehen. Nicht, dass ich glaube, dass Scala jemals wahrscheinlich der nächste Java sein würde (oder /C/C++/C#) - ich glaube nicht, dass seine Schöpfer es auf diesen Markt abgesehen hatten - aber ich denke, dass es sicherlich möglich war/ist, dass Scala der nächste Ruby oder Python wird (d.h. eine bedeutende kommerzielle Benutzerbasis zu gewinnen)

• Wird das Leute davon abhalten, zu Scala zu kommen?
• Wird das Scala einen schlechten Ruf in der kommerziellen Welt als akademische Spielerei geben, die nur dedizierte Doktoranden verstehen können? Werden CTOs und Leiter von Software abgeschreckt?
• War die Neugestaltung der Bibliothek eine vernünftige Idee?
• Wenn Sie Scala kommerziell verwenden, machen Sie sich darüber Sorgen? Planen Sie, sofort auf 2.8 umzusteigen oder abzuwarten, was passiert?

Steve Yegge griff einmal Scala an (meiner Meinung nach fälschlicherweise) für das, was er als sein überkompliziertes Typsystem ansah. Ich befürchte, dass jemand eine Freude daran haben wird, mit dieser API FUD zu verbreiten (ähnlich wie Josh Bloch die JCP davon abhielt, Closures zu Java hinzuzufügen).

Anmerkung - _Ich möchte klarstellen, dass ich zwar glaube, dass Joshua Bloch maßgeblich am Ablehnen des BGGA-Closures-Vorschlags beteiligt war, dies meiner Meinung nach jedoch nichts anderes als seinen aufrichtig überzeugten Überzeugungen zuzuschreiben ist, dass der Vorschlag einen Fehler darstellte._

---

Ungeachtet dessen, was meine Frau und meine Kollegen mir immer wieder sagen, glaube ich nicht, dass ich dumm bin: Ich habe einen guten Abschluss in Mathematik von der Universität Oxford und arbeite seit fast 12 Jahren beruflich als Programmierer und seit etwa einem Jahr (ebenfalls beruflich) in Scala.

_Beachten Sie, dass der provokante Betreff ein Zitat über das Manifest einer britischen politischen Partei aus den frühen 1980er Jahren ist. Diese Frage ist subjektiv, aber es handelt sich um eine ernsthafte Frage, ich habe sie zur Community-Wiki gemacht und würde gerne einige Meinungen dazu hören._

Answer 1

Ein Weg, wie die Scala-Community dazu beitragen kann, die Angst von Programmierern, die neu in Scala sind, zu lindern, besteht darin, sich auf die Praxis zu konzentrieren und durch Beispiel zu lehren - viele Beispiele, die klein beginnen und allmählich größer werden. Hier sind einige Websites, die diesen Ansatz verfolgen:

• Tägliches Scala
• Scala lernen in kleinen Portionen
• Einfach Scala

Nach etwas Zeit auf diesen Websites wird man schnell feststellen, dass Scala und seine Bibliotheken, obwohl möglicherweise schwierig zu entwerfen und zu implementieren sind, insbesondere in den üblichen Fällen nicht so schwer zu verwenden sind.

Answer 2

Ich habe einen Bachelor-Abschluss von einer günstigen "Massenmarkt" -Universität in den USA, also würde ich sagen, dass ich mich im mittleren Bereich der Benutzerintelligenz (oder zumindest Bildung) befinde :) Ich habe erst seit ein paar Monaten mit Scala experimentiert und an zwei oder drei nicht trivialen Apps gearbeitet.

Vor allem jetzt, da IntelliJ ihre hervorragende IDE mit meiner Meinung nach dem derzeit besten Scala-Plugin veröffentlicht hat, ist die Scala-Entwicklung relativ schmerzlos:

• Ich finde ich kann Scala als "Java ohne Semikolons" verwenden, d.h. ich schreibe Code, der ähnlich aussieht wie das, was ich in Java tun würde, und profitiere ein wenig von syntaktischer Kürze, wie sie durch Typinferenz gewonnen wird. Die Fehlerbehandlung, wenn ich sie überhaupt mache, ist bequemer. Die Klassendefinition ist viel weniger umständlich ohne den Getter/Setter-Boilerplate.

• Ab und zu schaffe ich es, eine einzige Zeile zu schreiben, um das Äquivalent von mehreren Zeilen Java zu erreichen. Dort wo es passt, sind Ketten von funktionalen Methoden wie map, fold, collect, filter usw. spaßig zu komponieren und elegant anzusehen.

• Nur selten profitiere ich von den leistungsfähigeren Funktionen von Scala: Closures und teilweise (oder curried) Funktionen, Pattern Matching... so etwas in der Art.

Als Neuling kämpfe ich weiterhin mit der knappen und idiomatischen Syntax. Methodenaufrufe ohne Parameter benötigen keine Klammern, außer wenn sie benötigt werden; Fälle in der Match-Anweisung benötigen einen dicken Pfeil ( => ), aber es gibt auch Stellen, an denen ein dünner Pfeil ( -> ) benötigt wird. Viele Methoden haben kurze, aber eher kryptische Namen wie /: oder \: - Ich bekomme meine Arbeit erledigt, wenn ich genug manuelle Seiten umblättere, aber einiges meines Codes sieht am Ende wie Perl oder Zeilenrauschen aus. Ironischerweise fehlt eine der beliebtesten syntaktischen Abkürzungen: Ich werde immer wieder daran erinnert, dass Int keine ++ Methode definiert.

Dies ist nur meine Meinung: Ich habe das Gefühl, dass Scala die Leistungsfähigkeit von C++ mit der Komplexität und Lesbarkeit von C++ vereint. Die syntaktische Komplexität der Sprache macht die API-Dokumentation auch schwer zu lesen.

Scala ist in vielerlei Hinsicht sehr durchdacht und brillant. Ich vermute, viele Akademiker würden gerne damit programmieren. Es steckt jedoch voller Raffinesse und Tücken, es hat eine viel steilere Lernkurve als Java und ist schwerer lesbar. Wenn ich die Foren durchsuche und sehe, wie viele Entwickler immer noch mit den Feinheiten von Java kämpfen, kann ich mir nicht vorstellen, dass Scala jemals zu einer Mainstream-Sprache wird. Keine Firma wird es rechtfertigen können, ihre Entwickler auf einen 3-wöchigen Scala-Kurs zu schicken, wenn sie zuvor nur einen 1-wöchigen Java-Kurs benötigten.

Answer 3

Ich denke, das Hauptproblem bei dieser Methode ist, dass das (implizite bf : CanBuildFrom[Repr, B,That]) ohne jegliche Erklärung erfolgt. Obwohl ich weiß, was implizite Argumente sind, gibt es nichts, was darauf hinweist, wie sich dies auf den Aufruf auswirkt. Wenn ich das Scaladoc durchsuche, werde ich nur noch verwirrter (wenige der Klassen, die mit CanBuildFrom zusammenhängen, haben überhaupt eine Dokumentation).

Ich denke, ein einfaches "es muss ein implizites Objekt im Gültigkeitsbereich für bf geben, das einen Builder für Objekte vom Typ B in den Rückgabetyp That bereitstellt" würde etwas helfen, aber es ist eine anspruchsvolle Konzept, wenn Sie eigentlich nur A's in B's abbilden möchten. Tatsächlich bin ich mir nicht sicher, ob das richtig ist, weil ich nicht weiß, was der Typ Repr bedeutet und die Dokumentation für Traversable sicherlich überhaupt keinen Hinweis gibt.

Also stehe ich vor zwei nicht angenehmen Optionen:

• Annehmen, dass es genauso funktioniert wie die alte map-Funktion und wie map in den meisten anderen Sprachen funktioniert
• Grabe weiter in den Quellcode

Ich verstehe, dass Scala im Grunde genommen die Funktionsweise dieser Dinge offenlegt und dass dies letztendlich einen Weg bietet, um das zu tun, was oxbow_lakes beschreibt. Aber es lenkt in der Signatur ab.

Answer 4

Ich bin ein Scala-Anfänger und ehrlich gesagt sehe ich kein Problem mit dieser Typsignatur. Der Parameter ist die Funktion zum Abbilden und der implizite Parameter der Erbauer, um die richtige Sammlung zurückzugeben. Klar und lesbar.

Die ganze Sache ist eigentlich ziemlich elegant. Die Builder-Typ-Parameter lassen den Compiler den richtigen Rückgabetyp wählen, während der implizite Parametermechanismus diesen zusätzlichen Parameter vor dem Klassenbenutzer verbirgt. Ich habe das ausprobiert:

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // gibt Map("a" -> 1, "b" -> 2) zurück
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // gibt List("a", "b") zurück

Das ist Polymorphismus, wie er richtig gemacht wird.

Nun, zugegeben, es ist kein Mainstream-Paradigma und es wird viele abschrecken. Aber es wird auch viele anziehen, die seine Ausdrucksstärke und Eleganz schätzen.

Answer 5

Leider ist die Signatur für die Karte, die Sie angegeben haben, eine falsche für die Karte und es gibt tatsächlich legitime Kritik.

Die erste Kritik ist, dass wir durch die Umgehung der Signatur für die Karte etwas haben, das allgemeiner ist. Es ist ein häufiger Fehler zu glauben, dass dies per se ein Vorteil ist. Das ist es nicht. Die Kartenfunktion ist sehr gut definiert als ein kovarianter Funktor Fx -> (x -> y) -> Fy mit Einhaltung der beiden Gesetze für Komposition und Identität. Alles andere, was "Karte" zugeschrieben wird, ist ein Frevel.

Die gegebene Signatur ist etwas anderes, aber es ist nicht die Karte. Was ich vermute, dass es versucht zu sein, ist eine spezialisierte und leicht veränderte Version der "durchqueren" Signatur aus dem Papier Die Essenz des Iterator-Musters. Hier ist die Signatur:

durchqueren :: (Traversable t, Applicative f) => (a -> f b) -> t a -> f (t b)

Ich werde es in Scala umwandeln:

def traverse[A, B](f: A => F[B], a: T[A])(implizites t: Traversable[T], ap: Applicative[F]): F[T[B]

Natürlich scheitert es - es ist nicht allgemein genug! Außerdem ist es etwas anders (beachten Sie, dass Sie die Karte erhalten können, indem Sie traverse durch den Identitätsfunktor laufen lassen). Ich vermute jedoch, dass, wenn die Bibliotheksschreiber sich mehr bewusst wären, von gut dokumentierten Bibliotheksverallgemeinerungen (die Applicative-Programmierung mit Effekten geht dem Genannten voraus), dann würden wir diesen Fehler nicht sehen.

Zweitens ist die Kartenfunktion in Scala ein Sonderfall aufgrund ihrer Verwendung in for-Verständnissen. Das bedeutet leider, dass ein besser ausgestatteter Bibliotheksentwerfer diesen Fehler nicht ignorieren kann, ohne auch den syntaktischen Zucker von Verständnissen aufzugeben. Mit anderen Worten, wenn die Scala-Bibliotheksentwerfer eine Methode zerstören würden, dann könnte diese leicht ignoriert werden, aber bitte nicht map!

Ich hoffe, jemand spricht darüber, denn so wie es ist, wird es schwieriger werden, die Fehler zu umgehen, die Scala scheinbar aus Gründen macht, denen ich stark widerspreche. Das heißt, die Lösung für "die unverantwortlichen Einwände des durchschnittlichen Programmierers (d.h. zu schwer!)" ist nicht "sie besänftigen, um es ihnen leichter zu machen", sondern stattdessen Hinweise und Unterstützung zu geben, um bessere Programmierer zu werden. Meine Ziele und die Ziele von Scala stehen in diesem Punkt in Widerspruch, aber zurück zu Ihrem Punkt.

Sie machten wahrscheinlich Ihren Punkt, indem Sie spezifische Reaktionen von "dem durchschnittlichen Programmierer" voraussahen. Das sind die Leute, die behaupten werden "aber das ist zu kompliziert!" oder ähnliches. Das sind die Yegges oder Blochs, auf die Sie sich beziehen. Meine Reaktion auf diese Vertreter der Anti-Intellektualismus/Pragmatismus-Bewegung ist ziemlich hart, und ich erwarte bereits eine Flut von Reaktionen, daher werde ich darauf verzichten.

Ich hoffe wirklich, dass die Scala-Bibliotheken besser werden, oder zumindest können die Fehler sicher in eine Ecke gesteckt werden. Java ist eine Sprache, in der "versuchen, etwas Nützliches zu tun" so unglaublich teuer ist, dass es oft nicht lohnt, weil die überwältigende Menge an Fehlern einfach nicht vermieden werden kann. Ich bitte Scala, nicht denselben Weg zu gehen.