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

Ich stimme sowohl der Frage als auch der Antwort von Martin voll und ganz zu :). Selbst in Java ist es viel schwieriger, die Javadoc mit Generics zu lesen, als es sein sollte, aufgrund des zusätzlichen Rauschens. Dies wird in Scala verstärkt, wo implizite Parameter wie im Beispielcode der Frage verwendet werden (während die Impliziten sehr nützliche Dinge zur Collection-Morphung machen).

Ich denke nicht, dass es sich um ein Problem der Sprache an sich handelt - ich denke, es handelt sich mehr um ein Tooling-Problem. Und obwohl ich dem zustimme, was Jörg W Mittag sagt, denke ich, dass es beim Betrachten von Scaladoc (oder der Dokumentation eines Typs in Ihrer IDE) so wenig Gehirnleistung wie möglich erfordern sollte, um zu verstehen, was eine Methode tut, was sie annimmt und zurückgibt. Es sollte keine Notwendigkeit sein, auf einem Stück Papier ein bisschen Algebra zu hacken, um es zu verstehen :)

Sicherlich benötigen IDEs eine einfache Möglichkeit, alle Methoden für jede Variable / Ausdruck / Typ anzuzeigen (was, wie im Beispiel von Martin, alle Generics inline haben kann, damit es schön und einfach zu verstehen ist). Mir gefällt auch die Idee von Martin, die Impliziten standardmäßig auszublenden.

Um das Beispiel in Scaladoc zu nehmen...

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

Wenn ich mir das in Scaladoc anschaue, würde ich gerne sehen, dass der Generics-Block [B, That] standardmäßig ausgeblendet ist, sowie der implizite Parameter (vielleicht wird er angezeigt, wenn Sie mit der Maus über einem kleinen Symbol hovern) - da es zusätzliche Informationen sind, die beim Lesen normalerweise nicht relevant sind. Stellen Sie sich vor, wenn dies so aussehen würde...

def map(f: A => B): That

Schön und klar und offensichtlich, was es tut. Man könnte sich fragen, was 'That' ist, wenn man mit der Maus darüber fährt oder darauf klickt, könnte der Text [B, That] erweitert werden, wobei 'That' beispielsweise hervorgehoben wird.

Vielleicht könnte ein kleines Symbol für die []-Deklaration und den (impliziten...) Block verwendet werden, damit klar wird, dass kleine Teile der Aussage zusammengeklappt sind? Es ist schwer, ein Symbol dafür zu verwenden, aber ich verwende jetzt ein . ...

def map.(f: A => B).: That

Standardmäßig wird der 'Lärm' des Typsystems für die Hauptnutzung erledigt - der Methodenname, die Parametertypen und der Rücgebenetyp auf einfache und prägnante Weise - mit kleinen erweiterbaren Links zu Details, wenn es Sie wirklich interessiert.

Die meisten Leute lesen Scaladoc, um herauszufinden, welche Methoden sie auf einen Typ anrufen können und welche Parameter sie übergeben können. Meiner Meinung nach überlasten wir Benutzer derzeit mit viel zu vielen Details.

Hier ist ein weiteres Beispiel...

def orElse[A1 <: A, B1 >: B](that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

Wenn wir die Generics-Deklaration ausblenden, ist es einfacher zu lesen

def orElse(that: PartialFunction[A1, B1]): PartialFunction[A1, B1]

Dann könnten wir, wenn die Leute z.B. über A1 schweben, die Deklaration von A1 zeigen, die A1 <: A ist. Kovariante und kontravariante Typen in Generics fügen ebenfalls viel Rauschen hinzu, das in einer für Benutzer einfacher zu verstehenden Weise dargestellt werden kann, denke ich.

Answer 2

Ich weiß nicht, wie ich es dir sagen soll, aber ich habe einen Doktortitel von Cambridge und benutze 2.8 problemlos.

Ernsthafter, ich habe kaum Zeit mit 2.7 verbracht (es funktioniert nicht mit einer Java-Bibliothek, die ich benutze) und habe vor etwas mehr als einem Monat angefangen, Scala zu benutzen. Ich habe etwas Erfahrung mit Haskell (nicht viel), aber habe die Dinge, die dich besorgt haben, einfach ignoriert und nach Methoden gesucht, die meiner Erfahrung mit Java entsprachen (das ich beruflich verwende).

Also: Ich bin ein "neuer Benutzer" und wurde nicht abgeschreckt - die Tatsache, dass es sich wie Java verhält, hat mir genug Selbstvertrauen gegeben, um die Teile zu ignorieren, die ich nicht verstanden habe.

(Jedoch war einer der Gründe, warum ich mir Scala angesehen habe, teilweise zu sehen, ob ich es bei der Arbeit fördern sollte, und das werde ich vorerst nicht tun. Eine weniger einschüchternde Dokumentation würde sicherlich helfen, aber was mich überrascht hat, ist, wie sehr es sich immer noch ändert und weiterentwickelt wird (um fair zu sein, was mich am meisten überrascht hat, war, wie großartig es ist, aber die Veränderungen kamen knapp dahinter). Also denke ich, dass ich es bevorzugen würde, dass die begrenzten Ressourcen darauf verwendet werden, es in einen endgültigen Zustand zu bringen - ich denke nicht, dass sie erwartet hatten, so schnell so beliebt zu werden.)

Answer 3

Ich kenne Scala überhaupt nicht, aber vor ein paar Wochen konnte ich kein Clojure lesen. Jetzt kann ich den Großteil davon lesen, aber kann bis jetzt noch nichts schreiben, das über die simplisten Beispiele hinausgeht. Ich vermute, dass es bei Scala nicht anders ist. Du brauchst ein gutes Buch oder einen Kurs, abhängig davon, wie du lernst. Nur durch das Lesen der obigen map-Deklaration habe ich vielleicht ein Drittel verstanden.

Ich glaube, die größeren Probleme sind nicht die Syntax dieser Sprachen, sondern das Akzeptieren und Verinnerlichen der Paradigmen, die sie in der täglichen Produktionsumgebung nutzbar machen. Für mich war Java kein riesiger Sprung von C++, was wiederum kein riesiger Sprung von C war, der wiederum kein Sprung von Pascal oder Basic war usw... Aber das Programmieren in einer funktionalen Sprache wie Clojure ist für mich ein großer Schritt (jedenfalls für mich). Ich denke, in Scala kannst du im Java-Stil oder im Scala-Stil programmieren. Aber in Clojure wirst du versuchen, deine imperativen Gewohnheiten aus Java beizubehalten, was ein ziemliches Durcheinander verursachen wird.

Answer 4

Scala hat viele verrückte Funktionen (insbesondere im Zusammenhang mit impliziten Parametern), die sehr kompliziert und akademisch aussehen, aber darauf ausgelegt sind, die Verwendung zu vereinfachen. Die nützlichsten erhalten syntaktischen Zucker (wie [A <% B], was bedeutet, dass ein Objekt des Typs A eine implizite Konvertierung zu einem Objekt des Typs B hat) und eine gut dokumentierte Erklärung dessen, was sie tun. Aber meistens können Sie als Anwender dieser Bibliotheken die impliziten Parameter ignorieren und darauf vertrauen, dass sie das Richtige tun.

Answer 5

Ich habe auch einen Mathematik-Abschluss von Oxford! Es hat eine Weile gedauert, bis ich den neuen Collections-Kram 'verstanden' habe. Aber jetzt mag ich es sehr gerne. Tatsächlich hat mich schon früh das Tippen von 'map' in 2.7 gestört (vielleicht weil das erste, was ich gemacht habe, war, eine der Collection-Klassen zu unterordnen).

Das Lesen von Martins Papier über die neuen 2.8 Collections hat wirklich geholfen, die Verwendung von Impliziten zu erklären, aber ja, die Dokumentation selbst muss definitiv besser erklären, welche Rolle verschiedene Arten von Impliziten innerhalb von Methodensignaturen von Kern-APIs spielen.

Meine Hauptbedenken sind eher: wann wird 2.8 veröffentlicht? Wann hören die Fehlerberichte auf? Hat das Scala-Team mit 2.8 mehr versprochen, als sie halten können / versucht, zu viel auf einmal zu ändern?

Ich würde wirklich gerne sehen, dass 2.8 stabilisiert wird, bevor überhaupt etwas Neues hinzugefügt wird, und frage mich (während ich vom Spielfeldrand aus zuschaue), ob einige Verbesserungen am Weg, wie der Entwicklungs-Roadmap für den Scala-Compiler verwaltet wird, vorgenommen werden könnten.