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 hoffe, es handelt sich nicht um einen "Abschiedsbrief", aber ich verstehe deinen Standpunkt. Du triffst damit genau das, was gleichzeitig eine Stärke und ein Problem von Scala ist: seine Erweiterbarkeit. Dadurch können wir die meisten wichtigen Funktionen in Bibliotheken implementieren. In einigen anderen Sprachen wären Sequenzen mit ähnlicher Funktionalität wie map oder collect bereits integriert, und niemand müsste alle Hürden sehen, die der Compiler nehmen muss, um sie reibungslos funktionieren zu lassen. In Scala ist alles in einer Bibliothek und daher offen einsehbar.

Tatsächlich ist die Funktionalität von map, die durch seinen komplexen Typ unterstützt wird, ziemlich fortgeschritten. Betrachte dies:

scala> import collection.immutable.BitSet
import collection.immutable.BitSet

scala> val bits = BitSet(1, 2, 3)
bits: scala.collection.immutable.BitSet = BitSet(1, 2, 3)

scala> val shifted = bits map { _ + 1 }
shifted: scala.collection.immutable.BitSet = BitSet(2, 3, 4)

scala> val displayed = bits map { _.toString + "!" }
displayed: scala.collection.immutable.Set[java.lang.String] = Set(1!, 2!, 3!)

Siehst du, wie du immer den bestmöglichen Typ erhältst? Wenn du Ints in Ints umwandelst, bekommst du wieder ein BitSet, aber wenn du Ints in Strings umwandelst, bekommst du eine generelle Set. Sowohl der statische Typ als auch die Laufzeitdarstellung des Ergebnisses von map hängen vom Ergebnistyp der übergebenen Funktion ab. Und das funktioniert sogar, wenn das Set leer ist, so dass die Funktion nie angewendet wird! Soweit ich weiß, gibt es kein anderes Collection-Framework mit einer äquivalenten Funktionalität. Doch aus Benutzersicht ist dies so, wie es funktionieren soll.

Das Problem, das wir haben, ist, dass die ganzen cleveren Technologien, die dies möglich machen, in die Typsignaturen durchsickern, die groß und beängstigend werden. Aber vielleicht sollte einem Benutzer standardmäßig nicht die vollständige Typsignatur von map angezeigt werden? Wie wäre es, wenn sie nachschlagen würde, was map in BitSet bedeutet:

map(f: Int => Int): BitSet     (hier klicken für allgemeineren Typ)

In diesem Fall würden die Dokumentationen nicht lügen, denn aus Benutzersicht hat map tatsächlich den Typ (Int => Int) => BitSet. Doch map hat auch einen allgemeineren Typ, der durch Klicken auf einen anderen Link inspiziert werden kann.

Wir haben eine solche Funktionalität noch nicht in unseren Tools implementiert. Aber ich glaube, dass wir dies tun sollten, um die Leute nicht abzuschrecken und um nützlichere Informationen zu liefern. Mit solchen Tools sollten hoffentlich intelligente Frameworks und Bibliotheken nicht zu Abschiedsbriefen werden.

Answer 2

Ich habe keinen Doktortitel, noch irgendeine andere Art von Abschluss weder in Informatik noch in Mathematik, noch in der Tat in einem anderen Bereich. Ich habe keine Vorerfahrung mit Scala oder einer ähnlichen Sprache. Ich habe keine Erfahrung mit auch nur annähernd vergleichbaren Typsystemen. Tatsächlich ist die einzige Sprache, von der ich mehr als oberflächliche Kenntnisse habe und die überhaupt ein Typsystem hat, Pascal, das nicht gerade für sein ausgeklügeltes Typsystem bekannt ist. (Obwohl es Bereichstypen hat, die meines Wissens so gut wie keine andere Sprache hat, aber das ist hier nicht wirklich relevant.) Die anderen drei Sprachen, die ich kenne, sind BASIC, Smalltalk und Ruby, von denen keine ein Typsystem hat.

Und dennoch habe ich überhaupt kein Problem damit, die Signatur der map-Funktion zu verstehen, die Sie gepostet haben. Es sieht für mich aus wie so ziemlich die gleiche Signatur, die map in jeder anderen Sprache hat, die ich je gesehen habe. Der Unterschied ist, dass diese Version allgemeiner ist. Es sieht mehr wie eine C++ STL-Sache aus als, sagen wir, Haskell. Insbesondere abstrahiert es von der konkreten Sammlungstyp, indem es nur erfordert, dass das Argument 'IterableLike' ist, und abstrahiert auch von der konkreten Rückgabetyp, indem es nur erfordert, dass eine implizite Konvertierungsfunktion existiert, die 'etwas' aus dieser Sammlung von Ergebniswerten erstellen kann. Ja, das ist ziemlich komplex, aber es ist wirklich nur ein Ausdruck des allgemeinen Paradigmas der generischen Programmierung: gehen Sie nicht von etwas aus, was Sie nicht wirklich müssen.

In diesem Fall braucht map die Sammlung nicht tatsächlich, um eine Liste zu sein, geordnet zu sein oder sortierbar zu sein oder so etwas. Das einzige, worauf es map ankommt, ist, dass es Zugriff auf alle Elemente der Sammlung erhalten kann, eines nach dem anderen, aber in keiner bestimmten Reihenfolge. Und es muss nicht wissen, um welche Art von resultierender Sammlung es sich handelt, es muss nur wissen, wie man sie erstellt. Das ist also das, was seine Typsignatur erfordert.

Also anstelle von

map :: (a  b)  [a]  [b]

was die traditionelle Typsignatur für map ist, ist es verallgemeinert, um nicht eine konkrete List zu erfordern, sondern eher eine 'IterableLike'-Datenstruktur

map :: (IterableLike i, IterableLike j)  (a  b)  i  j

was dann weiter verallgemeinert wird, indem nur eine Funktion erforderlich ist, die das Ergebnis in die gewünschte Datenstruktur umwandeln kann:

map :: IterableLike i  (a  b)  i  ([b]  c)  c

Ich gebe zu, die Syntax ist etwas sperrig, aber die Semantik ist die gleiche. Im Grunde genommen beginnt es von

def map[B](f: (A)  B): List[B]

was die traditionelle Signatur für map ist. (Beachten Sie, wie aufgrund der objektorientierten Natur von Scala der Eingabelistenparameter verschwindet, da es nun der implizite Empfängerparameter ist, den jede Methode in einem Einzelaufruf-OO-System hat.) Dann verallgemeinert es von einer konkreten 'Liste' zu einem allgemeineren 'IterableLike'

def map[B](f: (A)  B): IterableLike[B]

Jetzt ersetzt es die 'IterableLike'-Ergebnissammlung durch eine Funktion, die 'produziert', nun ja, so ziemlich alles.

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

Was ich wirklich glaube, ist nicht so schwer zu verstehen. Es gibt wirklich nur ein paar intellektuelle Werkzeuge, die Sie benötigen:

1. Sie müssen (ungefähr) wissen, was 'map' ist. Wenn Sie nur die Typsignatur ohne den Namen der Methode gegeben hätten, gebe ich zu, es wäre viel schwieriger herauszufinden, was los ist. Aber da Sie bereits wissen, was 'map' tun soll, und Sie wissen, wie die Typsignatur aussehen soll, können Sie schnell die Signatur durchsuchen und sich auf Anomalien konzentrieren, wie "warum nimmt dieses 'map' zwei Funktionen als Argumente, nicht eine?"
2. Sie müssen in der Lage sein, die Typsignatur tatsächlich zu 'lesen'. Aber selbst wenn Sie noch nie zuvor Scala gesehen haben, sollte dies recht einfach sein, da es wirklich nur eine Mischung aus Typsyntaxen ist, die Sie bereits aus anderen Sprachen kennen: VB.NET verwendet eckige Klammern für den parametrischen Polymorphismus und verwendet einen Pfeil, um den Rückgabetyp anzugeben, und ein Doppelpunkt trennt Namen und Typ, was eigentlich die Norm ist.
3. Sie müssen ungefähr wissen, worum es bei der generischen Programmierung geht. (Was nicht so schwer zu verstehen ist, da es im Grunde genommen alles im Namen steht: Es ist buchstäblich nur das Programmieren auf generische Weise).

Keines dieser drei sollte einem professionellen Programmierer oder auch nur einem Hobbyprogrammierer ernsthafte Kopfschmerzen bereiten. 'map' ist eine Standardfunktion in so gut wie jeder Sprache, die in den letzten 50 Jahren entworfen wurde, die Tatsache, dass verschiedene Sprachen eine unterschiedliche Syntax haben, sollte für jeden offensichtlich sein, der eine Website mit HTML und CSS entworfen hat, und Sie können sich nicht für eine auch nur entfernt programmbezogene Mailingliste anmelden, ohne dass Ihnen irgend so ein nerviger C++-Fanboy von der Kirche des hl. Stepanov die Vorzüge der generischen Programmierung erklärt.

Ja, Scala ist komplex. Ja, Scala hat eines der anspruchsvollsten Typsysteme, die dem Menschen bekannt sind, die sogar Sprachen wie Haskell, Miranda, Clean oder Cyclone übertreffen. Aber wenn Komplexität ein Argument gegen den Erfolg einer Programmiersprache wäre, wäre C++ schon lange tot, und wir würden alle Scheme schreiben. Es gibt viele Gründe, warum Scala höchstwahrscheinlich nicht erfolgreich sein wird, aber die Tatsache, dass Programmierer sich nicht die Mühe machen wollen, ihre Gehirne einzuschalten, bevor sie sich vor die Tastatur setzen, wird wahrscheinlich nicht der Hauptgrund sein.

Answer 3

Dasselbe in C++:

template

Answer 4

Nun, ich kann deinen Schmerz verstehen, aber ganz ehrlich, Leute wie du und ich - oder so ziemlich jeder normale Stack Overflow Benutzer - sind nicht die Regel.

Was ich damit meine ist, dass... die meisten Programmierer sich nicht um diese Art von Typ-Signatur kümmern werden, weil sie sie nie sehen werden! Sie lesen keine Dokumentation.

Solange sie ein Beispiel davon gesehen haben, wie der Code funktioniert, und der Code sie nicht im Erzeugen des erwarteten Ergebnisses enttäuscht, werden sie niemals die Dokumentation ansehen. Wenn das scheitert, werden sie die Dokumentation überprüfen und erwarten, Beispielnutzungen oben zu sehen.

Unter Berücksichtigung dieser Dinge denke ich, dass:

1. Jeder (das heißt, die meisten Leute), der jemals auf diese Typ-Signatur stößt, wird Scala ohne Ende verspotten, wenn sie bereits gegen Scala voreingenommen sind, und werden es als ein Symbol für die Stärke von Scala betrachten, wenn sie Scala mögen.

2. Wenn die Dokumentation nicht verbessert wird, um Beispiele zur Nutzung zu bieten und klar zu erklären, wofür eine Methode gedacht ist und wie man sie benutzt, kann dies der Verbreitung von Scala ein wenig abträglich sein.

3. Auf lange Sicht wird es keine Rolle spielen. Dass Scala so etwas kann, wird Bibliotheken, die für Scala geschrieben sind, viel leistungsfähiger und sicherer machen. Diese Bibliotheken und Frameworks werden Programmierer anziehen, die leistungsfähige Werkzeuge bevorzugen.

4. Programmierer, die Einfachheit und Direktheit mögen, werden weiterhin PHP oder ähnliche Sprachen nutzen.

Ach ja, Java-Programmierer stehen sehr auf leistungsfähige Werkzeuge, daher habe ich gerade meine Erwartung in Bezug auf die Verbreitung von Scala in der breiten Masse überarbeitet. Ich habe überhaupt keine Zweifel daran, dass Scala eine Mainstream-Sprache werden wird. Nicht C-Mainstream, aber vielleicht Perl-Mainstream oder PHP-Mainstream.

Übrigens, hast du jemals den Klassenloader in Java ersetzt? Hast du jemals recherchiert, was das bedeutet? Java kann beängstigend sein, wenn man sich ansieht, was Framework-Entwickler tun. Es ist nur so, dass die meisten Leute das nicht tun. Das Gleiche trifft meiner Meinung nach auf Scala zu, aber Frühannahmende haben die Tendenz, jeden Stein umzudrehen, dem sie begegnen, um zu sehen, ob dort etwas versteckt ist.

Answer 5

Wird dies die Leute davon abhalten, nach Scala zu kommen?

Ja, aber es wird auch verhindern, dass die Leute abgeschreckt werden. Ich habe den Mangel an Kollektionen, die höherwertige Typen verwenden, seit Scala die Unterstützung für höherwertige Typen erhalten hat, als eine wesentliche Schwäche betrachtet. Es macht die API-Dokumentation komplizierter, aber es macht die Verwendung wirklich natürlicher.

Wird dies Scala in der kommerziellen Welt einen schlechten Ruf als eine akademische Spielerei geben, die nur dedizierte Doktoranden verstehen können? Werden sich CTOs und Softwareleiter abschrecken lassen?

Einige werden es wahrscheinlich tun. Ich glaube nicht, dass Scala für viele "professionelle" Entwickler zugänglich ist, teilweise aufgrund der Komplexität von Scala und teilweise aufgrund der Unwilligkeit vieler Entwickler zu lernen. Die CTOs, die solche Entwickler beschäftigen, werden zu Recht abgeschreckt sein.

War die Neugestaltung der Bibliothek eine vernünftige Idee?

Auf jeden Fall. Es lässt die Kollektionen viel besser mit dem Rest der Sprache und dem Typsystem zusammenpassen, auch wenn es noch einige raue Kanten hat.

Wenn Sie Scala kommerziell nutzen, machen Sie sich Sorgen darüber? Planen Sie, 2.8 sofort zu übernehmen oder abzuwarten, was passiert?

Ich benutze es nicht kommerziell. Ich werde wahrscheinlich warten, bis mindestens ein paar Versionen der 2.8.x-Serie herausgekommen sind, bevor ich überhaupt versuche, es einzuführen, damit die Fehler behoben werden können. Ich werde auch abwarten, wie erfolgreich EPFL in der Verbesserung seiner Entwicklung und Release-Prozesse ist. Was ich sehe, sieht hoffnungsvoll aus, aber ich arbeite für ein konservatives Unternehmen.

Zum allgemeineren Thema "Ist Scala zu kompliziert für Mainstream-Entwickler?"...

Die meisten Entwickler, mainstream oder nicht, warten bestehende Systeme oder erweitern sie. Das bedeutet, dass das meiste, was sie verwenden, durch Entscheidungen bestimmt wird, die vor langer Zeit getroffen wurden. Es gibt immer noch viele Leute, die COBOL schreiben.

Der Mainstream-Entwickler von morgen wird damit beschäftigt sein, die Anwendungen zu warten und zu erweitern, die heute gebaut werden. Viele dieser Anwendungen werden nicht von Mainstream-Entwicklern gebaut. Die Mainstream-Entwickler von morgen werden die Sprache verwenden, die von den erfolgreichsten Entwicklern der heute neuen Anwendungen verwendet wird.