it-swarm.com.de

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

Ich habe gerade angefangen, mir die Neuimplementierung der Scala-Sammlungsbibliothek anzuschauen, die in Kürze verfügbar sein wird 2.8 Freisetzung. Diejenigen, die mit der Bibliothek ab 2.7 vertraut sind, werden feststellen, dass sich die Bibliothek aus Sicht der Nutzung kaum verändert hat. Zum Beispiel...

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

... würde in beiden Versionen funktionieren. Die Bibliothek ist hervorragend nutzbar : Tatsächlich ist es fantastisch. Allerdings müssen diejenigen, die bisher nicht mit Scala und herumstöbern, um ein Gefühl für die Sprache zu bekommen vertraut waren, jetzt Methodensignaturen wie:

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

Für solch einfache Funktionen ist dies eine entmutigende Unterschrift, die ich nur schwer verstehen kann. Ich glaube nicht, dass Scala war jemals wahrscheinlich das nächste Java (oder/C/C++/C #) - Ich glaube nicht, dass seine Schöpfer es auf diesen Markt abzielten - aber ich denke, es ist/war mit Sicherheit machbar, dass Scala= zum nächsten Ruby oder = Python (dh um eine signifikante kommerzielle Nutzerbasis zu erlangen)

  • Wird das die Leute davon abhalten, nach Scala zu kommen?
  • Wird dies Scala ein schlechter Name in der Geschäftswelt als akademisches Spielzeug, das nur engagierte Doktoranden verstehen können? Werden [~ # ~] cto [~ # ~] und Software-Köpfe Angst bekommen?
  • War die Neugestaltung der Bibliothek eine vernünftige Idee?
  • Wenn Sie Scala kommerziell verwenden, machen Sie sich darüber Sorgen? Planen Sie die sofortige Einführung von 2.8 oder warten Sie ab, was passiert?

Steve Yeggegriff Scala einmal an (fälschlicherweise meiner Meinung nach) für das, was er als sein überkompliziertes Typensystem ansah. Ich mache mir Sorgen, dass jemand mit dieser API einen Feldtag haben wird, der [~ # ~] fud [~ # ~] verbreitet (ähnlich wie Josh Bloch die [~ # ~] jcp [~ # ~] aus dem Hinzufügen von Closures zu Java).

Anmerkung - Ich sollte das klarstellen, obwohl ich glaube, dass Joshua Bloch einflussreich war Bei der Ablehnung des BGGA-Schließungsvorschlags schreibe ich dies nur seiner aufrichtigen Überzeugung zu, dass der Vorschlag einen Fehler darstellte.


Trotz allem, was meine Frau und meine Kollegen mir immer wieder erzählen, glaube ich nicht, dass ich ein Idiot bin: Ich habe einen guten Abschluss in Mathematik von der University of Oxford und ich habe programmiere seit fast 12 Jahren kommerziell und in Scala seit ungefähr einem Jahr (auch kommerziell).

Beachten Sie, dass der Titel des entzündlichen Themas ein Zitat über das Manifest einer britischen politischen Partei in den frühen 1980er Jahren ist. Diese Frage ist subjektiv, aber es ist eine echte Frage, ich habe es CW gemacht und ich möchte einige Meinungen zu dieser Angelegenheit.

860
oxbow_lakes

Ich hoffe, es ist kein "Abschiedsbrief", aber ich kann Ihren Standpunkt verstehen. Sie treffen auf 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 werden Sequenzen mit so etwas wie map oder collect eingebaut, und niemand muss alle Rahmen sehen, die der Compiler durchlaufen muss, damit sie reibungslos funktionieren. In Scala ist alles in einer Bibliothek und daher im Freien.

Tatsächlich ist die Funktionalität von map, die von seinem komplizierten Typ unterstützt wird, ziemlich fortgeschritten. Bedenken Sie:

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!)

Sehen Sie, wie Sie immer den bestmöglichen Typ erhalten? Wenn Sie Ints auf Ints abbilden, erhalten Sie erneut ein BitSet, aber wenn Sie Ints auf Strings abbilden, erhalten Sie ein allgemeines Set. Sowohl der statische Typ als auch die Laufzeitdarstellung des Map-Ergebnisses hängen vom Ergebnistyp der Funktion ab, die an die Map übergeben wird. Und das funktioniert auch, wenn das Set leer ist, so dass die Funktion niemals angewendet wird! Soweit mir bekannt ist, gibt es kein anderes Collection-Framework mit einer vergleichbaren Funktionalität. Aus der Sicht der Benutzer ist dies jedoch die Vorgehensweise .

Das Problem, das wir haben, ist, dass all die clevere Technologie, die dies ermöglicht, in die Typensignaturen gelangt, die groß und beängstigend werden. Aber vielleicht sollte einem Benutzer nicht standardmäßig die vollständige Typensignatur von map angezeigt werden? Wie wäre es, wenn sie map in BitSet nachschauen würde?

map(f: Int => Int): BitSet     (click here for more general type)

Die docs würden in diesem Fall nicht lügen, denn aus Nutzersicht hat die Map ja den Typ (Int => Int) => BitSet. Aber map hat auch einen allgemeineren Typ, der durch Klicken auf einen anderen Link eingesehen werden kann.

Solche Funktionen haben wir in unseren Tools noch nicht implementiert. Aber ich glaube, wir müssen das tun, um die Leute nicht abzuschrecken und um mehr nützliche Informationen zu geben. Mit solchen Tools werden intelligente Frameworks und Bibliotheken hoffentlich nicht zu Selbstmordnotizen.

879
Martin Odersky

Ich habe weder einen Doktortitel noch einen anderen Abschluss, weder in CS noch in Mathematik, noch in irgendeinem anderen Bereich. Ich habe keine Vorkenntnisse mit Scala oder einer ähnlichen Sprache. Ich habe keine Erfahrung mit auch nur aus der Ferne vergleichbaren Typsystemen. Tatsächlich ist Pascal die einzige Sprache, über die ich mehr als nur oberflächliche Kenntnisse verfüge, von denen sogarein Typensystem besitzt. Pascal ist nicht gerade für sein ausgeklügeltes Typensystem bekannt. (Obwohl esgibtRange-Typen, die AFAIK 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 keines ein Typensystem hat.

Und dennoch habe ich keinerlei Probleme, die Signatur der von Ihnen geposteten map -Funktion zu verstehen. Es scheint mir so ziemlich die gleiche Signatur zu sein, die map in jeder anderen Sprache hat, die ich je gesehen habe. Der Unterschied ist, dass diese Version allgemeiner ist. Es sieht eher nach C++ STL aus als etwa nach Haskell. Insbesondere wird vom konkreten Auflistungstyp nur dann abstrahiert, wenn das Argument IterableLike lautet, und es wird auch vom konkreten Rückgabetyp abstrahiert, wenn nur eine implizite Konvertierungsfunktion vorhanden ist, diesomethingaus dieser Sammlung von Ergebniswerten. Ja, das ist recht komplex, aber es ist wirklich nur ein Ausdruck des allgemeinen Paradigmas der generischen Programmierung: Nehmen Sie nichts an, was Sie eigentlich nicht müssen.

In diesem Fall benötigt map nichtdie Sammlung, um eine Liste zu sein, oder um geordnet oder sortierbar zu sein oder ähnliches. Das einzige, was map interessiert, ist, dass es nacheinander, aber in keiner bestimmten Reihenfolge, auf alle Elemente der Sammlung zugreifen kann. Und es muss nicht wissen, was die resultierende Sammlung ist, es muss nur wissen, wie man sie erstellt. Das ist also, was seine Typensignatur erfordert.

Also statt

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

dies ist die herkömmliche Typensignatur für map. Es wird verallgemeinert, dass keine konkrete List, sondern nur eine IterableLike Datenstruktur erforderlich ist

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

dies wird weiter verallgemeinert, indem nur eine Funktion benötigt wird, diekonvertieren kanndas Ergebnis in die vom Benutzer gewünschte Datenstruktur:

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

Ich gebe zu, dass die Syntax etwas komplizierter ist, aber die Semantik ist dieselbe. Grundsätzlich geht es ab

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

das ist die traditionelle Signatur für map. (Beachten Sie, wie aufgrund der objektorientierten Natur von Scala der Parameter der Eingabeliste verschwindet, da es sich nun um den impliziten Empfängerparameter handelt, über den jede Methode in einem Single-Dispatch-System OO verfügt.) List zu einem allgemeineren IterableLike

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

Jetzt wird die IterableLike -Ergebnissammlung durch eine Funktion ersetzt, dieerzeugt, na ja, eigentlich so ziemlich alles.

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

Was ich wirklich glaube, ist nichtdassschwer 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 Sieonlydie Typensignatur ohne den Namen der Methode geben würden, würde es viel schwieriger sein, herauszufinden, was los ist. Aber da Sie bereitswissenwas map tun soll und wissen, wie die Typensignatur lauten soll, können Sie die Signatur schnell scannen und Konzentrieren Sie sich auf die Anomalien wie "Warum übernimmt dieses map zwei Funktionen als Argumente, nicht eine?"
  2. Sie müssen in der Lage sein,die Typensignatur zu lesen. Aber selbst wenn Sie noch nie Scala gesehen haben, sollte dies recht einfach sein, da es sich tatsächlich nur um eine Mischung von Typensyntaxen handelt, die Sie bereits aus anderen Sprachen kennen: VB.NET verwendet eckige Klammern für den parametrischen Polymorphismus und verwendet eine Pfeil zur Bezeichnung des Rückgabetyps und ein Doppelpunkt zur Trennung von Name und Typ sind eigentlich die Norm.
  3. Sie müssen ungefähr wissen, worum es bei der generischen Programmierung geht. (Was ist nichtdasschwer herauszufinden, da es im Grunde alles im Namen geschrieben ist: Es ist buchstäblich nur eine generische Programmierung).

Keiner dieser drei Faktoren sollte einem professionellen Programmierer oder sogar einem Hobby-Programmierer ernsthafte Kopfschmerzen bereiten. map war eine Standardfunktion in nahezu jeder Sprache, die in den letzten 50 Jahren entwickelt wurde. Die Tatsache, dass verschiedene Sprachen unterschiedliche Syntax haben, sollte für jeden offensichtlich sein, der eine Website mit HTML und CSS erstellt hat, und das können Sie nicht Abonnieren Sie eine Mailingliste für die Fernprogrammierung, ohne einen nervigen C++ - Fan von der Kirche St. Stepanov, der die Vorzüge der allgemeinen Programmierung erklärt.

Ja, Scalaistkomplex. Ja, Scala verfügt über eines der fortschrittlichsten Systeme, die dem Menschen bekannt sind und mit Sprachen wie Haskell, Miranda, Clean oder Cyclone konkurrieren und diese sogar übertreffen. Aber wenn Komplexität ein Argument gegen den Erfolg einer Programmiersprache wäre, wäre C++ längst gestorben und wir würden alle Scheme schreiben. Es gibt viele Gründe, warum Scala höchstwahrscheinlich nicht erfolgreich sein wird, aber die Tatsache, dass sich Programmierer nicht die Mühe machen müssen, ihren Verstand einzuschalten, bevor sie sich vor die Tastatur setzen, wird wahrscheinlich nicht die Hauptursache sein .

223
Jörg W Mittag

Dasselbe in C++:

template <template <class, class> class C,
          class T,
          class A,
          class T_return,
          class T_arg
              >
C<T_return, typename A::rebind<T_return>::other>
map(C<T, A> &c,T_return(*func)(T_arg) )
{
    C<T_return, typename A::rebind<T_return>::other> res;
    for ( C<T,A>::iterator it=c.begin() ; it != c.end(); it++ ){
        res.Push_back(func(*it));
    }
    return res;
}
172
skyde

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

Was ich damit meine ist, dass ... die meisten Programmierer sich nicht für diese Typensignatur interessieren, weil sie sie niemals sehen werden ! Sie lesen keine Dokumentation.

Solange sie ein Beispiel dafür gesehen haben, wie der Code funktioniert, und der Code nicht fehlschlägt, um das Ergebnis zu erzielen, das sie erwarten , werden sie es nicht tun schau dir mal die dokumentation an. Wenn dies fehlschlägt, sehen sie sich die Dokumentation an und erwarten, dass Verwendungsbeispiele oben angezeigt werden.

In Anbetracht dieser Dinge denke ich, dass:

  1. Jeder (wie die meisten Leute), der jemals auf diese Art von Signatur stößt, wird sich über Scala lustig machen, wenn er dazu bereit ist, und es als Symbol für Scalas Macht betrachten, wenn er Scala mag.

  2. Wenn die Dokumentation nicht erweitert wird, um Verwendungsbeispiele bereitzustellen und klar zu erläutern, wozu eine Methode dient und wie sie verwendet wird, kann dies die Scala - Übernahme ein wenig beeinträchtigen.

  3. Auf lange Sicht wird es keine Rolle spielen. Dass Scala solche Dinge kann , macht Bibliotheken, die für Scala geschrieben wurden, viel leistungsfähiger und sicherer. Diese Bibliotheken und Frameworks werden Programmierer anziehen, die sich mit leistungsstarken Werkzeugen auskennen.

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

Leider sind Java Programmierer sehr angetan von Elektrowerkzeugen. Als Antwort darauf habe ich gerade meine Erwartung einer Mainstream-Adoption Scala revidiert. Ich habe überhaupt keinen Zweifel daran, dass Scala eine Mainstream-Sprache werden wird. Nicht C-Mainstream, sondern vielleicht Perl-Mainstream oder PHP-Mainstream.

Apropos Java, haben Sie jemals den Klassenlader ersetzt? Haben Sie jemals untersucht, worum es geht? Java kann beängstigend sein, wenn man sich die Stellen ansieht, an denen Framework-Autoren arbeiten. Es ist nur so, dass die meisten Leute es nicht tun. Dasselbe gilt für Scala, IMHO, aber Early Adopters tendieren dazu, unter jeden Felsen zu schauen, auf den sie stoßen, um zu sehen, ob sich dort etwas versteckt.

71

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

Ja, aber es wird auch verhindern, dass Menschen abgesetzt werden. Ich habe das Fehlen von Sammlungen, die höherwertige Typen verwenden, als eine große Schwäche angesehen, seit Scala Unterstützung für höherwertige Typen erlangt hat. Dadurch werden die API-Dokumente komplizierter, die Verwendung wird jedoch natürlicher.

Wird dies scala in der Geschäftswelt einen schlechten Ruf als akademisches Spielzeug verleihen, das nur engagierte Doktoranden verstehen können? Werden CTOs und Softwarechefs Angst bekommen?

Einige werden es wahrscheinlich tun. Ich glaube nicht, dass Scala vielen "professionellen" Entwicklern zugänglich ist, teilweise aufgrund der Komplexität von Scala und teilweise aufgrund der mangelnden Lernbereitschaft vieler Entwickler. Die CTOs, die solche Entwickler beschäftigen, werden zu Recht abgeschreckt sein.

War die Neugestaltung der Bibliothek eine vernünftige Idee?

Absolut. Dadurch passen Sammlungen viel besser zur restlichen Sprache und zum Typensystem, auch wenn sie noch einige Ecken und Kanten haben.

Wenn Sie scala kommerziell verwenden, machen Sie sich darüber Sorgen? Planen Sie die sofortige Übernahme von 2.8 oder warten Sie ab, was passiert?

Ich benutze es nicht kommerziell. Ich werde wahrscheinlich warten, bis mindestens ein paar Umdrehungen in der 2.8.x-Serie gemacht sind, bevor ich überhaupt versuche, sie einzuführen, damit die Fehler beseitigt werden können. Ich werde auch abwarten, wie viel Erfolg die EPFL bei der Verbesserung ihrer Entwicklungs- und Freigabeprozesse hat. Was ich sehe, sieht hoffnungsvoll aus, aber ich arbeite für ein konservatives Unternehmen.

Eines der allgemeineren Themen von "Ist Scala für Mainstream-Entwickler zu kompliziert?" ...

Die meisten Mainstream- oder sonstigen Entwickler warten oder erweitern vorhandene Systeme. Dies bedeutet, dass das meiste, was sie verwenden, von Entscheidungen bestimmt wird, die vor langer Zeit getroffen wurden. Es gibt immer noch viele Leute, die COBOL schreiben.

Der Mainstream-Entwickler von morgen wird daran arbeiten, die Anwendungen, die heute erstellt werden, zu warten und zu erweitern. Viele dieser Anwendungen werden nicht von Mainstream-Entwicklern erstellt. Die Mainstream-Entwickler von morgen werden die Sprache verwenden, die von den erfolgreichsten Entwicklern neuer Anwendungen von heute verwendet wird.

55
Erik Engbrecht

Eine Möglichkeit für die Scala Community, die Angst vor Programmierern zu lindern, die neu in Scala) sind, besteht darin, sich auf das Üben zu konzentrieren und anhand von Beispielen zu lehren - viele Beispiele Diese fangen klein an und werden allmählich größer. Hier sind einige Websites, die diesen Ansatz verfolgen:

Nachdem man einige Zeit auf diesen Sites verbracht hat, stellt man schnell fest, dass Scala und seine Bibliotheken, obwohl vielleicht schwierig zu entwerfen und zu implementieren, nicht so schwierig zu benutzen sind, besonders in den üblichen Fällen.

46
Derek Mahar

Ich habe einen Bachelor-Abschluss von einer billigen "Massenmarkt" -Universität in den USA, also würde ich sagen, dass ich in die Mitte der User-Intelligence-Skala (oder zumindest der Bildungsskala) falle :) Ich habe mich mit Scala für nur ein paar Monate und haben an zwei oder drei nicht-trivialen Apps gearbeitet.

Vor allem jetzt, wo IntelliJ seine Geldstrafe veröffentlicht hat, ist IDE mit dem derzeit besten IMHO Scala Plugin, Scala Entwicklung ist relativ schmerzlos:

  • Ich finde, ich kann Scala als "Java ohne Semikolon" verwenden, dh ich schreibe ähnlich aussehenden Code wie in Java und profitiere ein wenig von einer solchen syntaktischen Kürze Die Behandlung von Ausnahmen ist bequemer, wenn ich das überhaupt mache. Die Klassendefinition ist ohne Getter/Setter-Boilerplate viel weniger ausführlich.

  • Hin und wieder schaffe ich es, eine einzelne Zeile zu schreiben, um das Äquivalent mehrerer Java-Zeilen zu erreichen. Gegebenenfalls sind Funktionsketten wie Karten, Falzen, Sammeln, Filtern usw. unterhaltsam zu komponieren und elegant anzusehen.

  • Nur selten profitiere ich von den leistungsstärkeren Funktionen von Scala: Schließen und Teiloder Curry-) Funktionen, Pattern Matching ... so etwas.

Als Neuling kämpfe ich weiterhin mit der knappen und idiomatischen Syntax. Methodenaufrufe ohne Parameter benötigen keine Klammern, es sei denn, sie tun dies. Fälle in der match-Anweisung benötigen einen fetten Pfeil (=>), aber es gibt auch Stellen, an denen Sie einen dünnen Pfeil (->) benötigen. Viele Methoden haben kurze, aber eher kryptische Namen wie /: Oder \: - Ich kann meine Arbeit erledigen, wenn ich genügend Manualpages umblättere, aber ein Teil meines Codes sieht aus wie Perl oder Zeilenrauschen. Ironischerweise fehlt eine der beliebtesten syntaktischen Abkürzungen in der Handlung: Ich werde immer wieder von der Tatsache gebissen, 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++ kombiniert. Die syntaktische Komplexität der Sprache macht es auch schwierig, die API-Dokumentation zu lesen.

Scala ist sehr durchdacht und in vielerlei Hinsicht brillant. Ich vermute, dass viele Akademiker gerne darin programmieren würden. Es ist jedoch auch voller Cleverness und Fallstricke, es hat eine viel höhere Lernkurve als Java und ist schwerer zu lesen. Wenn ich die Foren durchsuche und sehe, wie viele Entwickler immer noch mit den Feinheiten kämpfen Punkte von Java, --- (Ich kann mir nicht vorstellen, dass Scala jemals eine Mainstream-Sprache wird. Kein Unternehmen wird in der Lage sein, zu rechtfertigen, seine Entwickler auf eine 3-wöchige Scala Kurs, als sie früher nur 1 Woche brauchten Java Kurs.

43
Carl Smotricz

Ich denke, das Hauptproblem bei dieser Methode ist, dass die (implicit bf : CanBuildFrom[Repr, B, That]) geht ohne Erklärung. Auch wenn ich weiß, welche impliziten Argumente vorliegen, gibt es keinen Hinweis darauf, wie sich dies auf den Aufruf auswirkt. Das Durchsuchen des scaladoc lässt mich nur verwirrter werden (nur wenige der Klassen, die mit CanBuildFrom zusammenhängen, haben sogar Dokumentation).

Ich denke, ein einfaches "es muss ein implizites Objekt im Bereich für bf geben, das einen Builder für Objekte vom Typ B in den Rückgabetyp That liefert" würde etwas helfen, aber Es ist eine Art berauschendes Konzept, wenn Sie nur A auf B 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 gibt sicherlich überhaupt keinen Hinweis.

Ich habe also zwei Möglichkeiten, von denen keine angenehm ist:

  • Angenommen, es funktioniert nur, wie die alte Karte funktioniert und wie die Karte in den meisten anderen Sprachen funktioniert
  • Stöbern Sie noch ein wenig im Quellcode

Ich verstehe, dass Scala im Wesentlichen den Mut zeigt, wie diese Dinge funktionieren, und dass dies letztendlich eine Möglichkeit ist, das zu tun, was oxbow_lakes beschreibt. Aber es ist eine Ablenkung in der Signatur.

32
davetron5000

Ich bin ein Scala Anfänger, und ich sehe ehrlich gesagt kein Problem mit dieser Typensignatur. Der Parameter ist die zuzuordnende Funktion und der implizite Parameter der Builder, um die richtige Auflistung zurückzugeben lesbar.

Eigentlich ist das Ganze ziemlich elegant. Mit den Builder-Typparametern kann der Compiler den richtigen Rückgabetyp auswählen, während der implizite Parametermechanismus diesen zusätzlichen Parameter vor dem Klassenbenutzer verbirgt. Ich habe es versucht:

Map(1 -> "a", 2 -> "b").map((t) => (t._2) -> (t._1)) // returns Map("a" -> 1, "b" -> 2)
Map(1 -> "a", 2 -> "b").map((t) =>  t._2)            // returns List("a", "b")

Das ist richtig gemachter Polymorphismus.

Nun, zugegeben, es ist kein Mainstream-Paradigma und es wird viele abschrecken. Aber es wird auch viele anziehen, die Wert auf Ausdruckskraft und Eleganz legen.

22
Thomas Heywood

Leider ist die Signatur für die Karte, die Sie angegeben haben, für die Karte falsch und es gibt in der Tat berechtigte Kritik.

Der erste Kritikpunkt ist, dass wir durch das Umkehren der Signatur für die Karte etwas Allgemeineres haben. Es ist ein verbreiteter Irrtum zu glauben, dass dies standardmäßig eine Tugend ist. Ist es nicht. Die Kartenfunktion ist sehr gut definiert als kovarianter Funktor Fx -> (x -> y) -> Fy unter Einhaltung der beiden Gesetze von Zusammensetzung und Identität. Alles andere, was "map" zugeschrieben wird, ist eine Travestie.

Die angegebene Signatur ist etwas anderes, aber keine Karte. Was ich vermute, ist eine spezialisierte und leicht veränderte Version der "Traverse" -Signatur aus dem Papier "The Essence of the Iterator Pattern". Hier ist seine Unterschrift:

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

Ich werde es nach Scala konvertieren:

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

Natürlich scheitert es - es ist nicht allgemein genug! Es ist auch etwas anders (beachten Sie, dass Sie die Karte erhalten können, indem Sie den Identitätsfunktor durchlaufen). Ich vermute jedoch, dass wir diesen Fehler nicht sehen würden, wenn die Bibliotheksschreiber besser über gut dokumentierte Verallgemeinerungen informiert wären (Anwendungsprogrammierung mit Effekten steht vor dem oben genannten).

Zweitens ist die Kartenfunktion in Scala ein Sonderfall, da sie in For-Comprehensions verwendet wird. Dies bedeutet leider, dass ein besser ausgestatteter Bibliotheksdesigner diesen Fehler nicht ignorieren kann, ohne auch den syntaktischen Zucker des Verstehens zu opfern. Mit anderen Worten, wenn die Scala Bibliotheksdesigner eine Methode zerstören, wird dies leicht ignoriert, aber bitte nicht abbilden!

Ich hoffe, jemand spricht darüber, denn es wird schwieriger, die Fehler zu umgehen, auf die Scala besteht, anscheinend aus Gründen, gegen die ich starke Einwände habe. Das heißt, die Lösung für "die unverantwortlichen Einwände des durchschnittlichen Programmierers (d. H. Zu hart!)" Besteht nicht darin, "sie zu beschwichtigen, um es ihnen leichter zu machen", sondern stattdessen Hinweise und Hilfestellung zu geben, um bessere Programmierer zu werden. Ich selbst und Scalas Ziele sind in dieser Frage umstritten, aber zurück zu Ihrem Standpunkt.

Sie haben Ihren Standpunkt wahrscheinlich klargestellt und bestimmte Antworten vom "durchschnittlichen Programmierer" vorhergesagt. Das heißt, die Leute, die behaupten, "aber es ist zu kompliziert!" oder so etwas. Dies sind die Yegges oder Blochs, auf die Sie sich beziehen. Meine Reaktion auf diese Menschen der Anti-Intellektualismus/Pragmatismus-Bewegung ist ziemlich hart und ich erwarte bereits eine Flut von Antworten, daher werde ich sie weglassen.

Ich hoffe wirklich, dass sich die Scala Bibliotheken verbessern, oder zumindest, dass sich die Fehler sicher in einer Ecke verstecken lassen. Java ist eine Sprache, in der der Versuch, etwas Nützliches zu tun, so unglaublich kostspielig ist, dass er sich oft nicht lohnt, da die überwältigende Menge an Fehlern einfach nicht vermieden werden kann. Ich flehe Scala an, nicht denselben Weg zu gehen.

20
Tony Morris

Ich stimme sowohl der Frage als auch Martins Antwort voll und ganz zu :). Selbst in Java ist das Lesen von Javadoc mit Generika aufgrund des zusätzlichen Rauschens viel schwieriger als es sein sollte. Dies setzt sich zusammen aus Scala, wobei implizite Parameter wie im Beispielcode der Fragen verwendet werden (während die Impliziten sehr nützliche Dinge zum Verwandeln von Sammlungen tun).

Ich denke nicht, dass es ein Problem mit der Sprache an sich ist - ich denke, es ist eher ein Werkzeugproblem. Und obwohl ich mit Jörg W. Mittag einverstanden bin, denke ich, dass ein Blick auf scaladoc (oder die Dokumentation eines Typs in Ihrer IDE) so wenig Gehirnleistung wie möglich erfordern sollte, um herauszufinden, was eine Methode ist, was sie braucht und was sie zurückgibt. Es sollte nicht nötig sein, ein bisschen Algebra auf ein bisschen Papier zu hacken, um es zu bekommen :)

Sicherlich brauchen IDEs eine nette Methode, um alle Methoden für jede Variable/Ausdruck/Typ anzuzeigen (wie in Martins Beispiel können alle Generika so eingezeichnet sein, dass es nett und leicht zu verstehen ist). Ich mag Martins Idee, die Implikationen auch standardmäßig zu verbergen.

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, möchte ich, dass der generische Block [B, That] standardmäßig ausgeblendet wird, sowie den impliziten Parameter (möglicherweise wird er angezeigt, wenn Sie mit der Maus über ein kleines Symbol schweben) - als zusätzliches Kram Lesen, was normalerweise nicht so relevant ist. z.B. stell dir vor, wie das aussah ...

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

Schön und klar und offensichtlich, was es tut. Sie fragen sich vielleicht, was das ist. Wenn Sie mit der Maus darüber fahren oder darauf klicken, wird möglicherweise der Text [B, That] eingeblendet, der beispielsweise das "That" hervorhebt.

Vielleicht könnte ein kleines Symbol für die [] -Deklaration und den (impliziten ...) Block verwendet werden, damit klar ist, dass kleine Teile der Anweisung zusammengebrochen sind. Es ist schwer, einen Token dafür zu benutzen, aber ich werde einen benutzen. zur Zeit...

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

Standardmäßig ist das 'Rauschen' des Typensystems vor den Hauptzielen verborgen, auf die die Leute achten müssen - der Methodenname, seine Parametertypen und sein Rückgabetyp auf einfache, übersichtliche Art und Weise - mit wenig erweiterbaren Links zum Detail wenn es dich wirklich so interessiert.

Die meisten Leute lesen scaladoc, um herauszufinden, welche Methoden sie für einen Typ aufrufen können und welche Parameter sie übergeben können. Wir überladen die Nutzer ein bisschen mit viel zu vielen Details, genau wie IMHO.

Hier ist ein weiteres Beispiel ...

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

Wenn wir nun die Generika-Erklärung verstecken, ist sie leichter zu lesen

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

Wenn dann Leute über A1 schweben, könnten wir die Deklaration von A1 als A1 <: A zeigen. Kovariante und kontravariante Typen in Generika fügen ebenfalls viel Rauschen hinzu, das für Benutzer meiner Meinung nach viel einfacher zu rendern ist.

15
James Strachan

Ich weiß nicht, wie ich es Ihnen erklären soll, aber ich habe einen Doktortitel aus Cambridge und ich benutze 2.8 ganz gut.

Im Ernst, ich habe kaum Zeit mit 2.7 verbracht (es funktioniert nicht mit einer von mir verwendeten Java Bibliothek)) und habe angefangen, Scala gerade vorbei) zu verwenden vor einem Monat. Ich habe einige Erfahrungen mit Haskell (nicht viel), habe aber die Dinge, um die Sie sich Sorgen machen, einfach ignoriert und nach Methoden gesucht, die mit meinen Erfahrungen mit Java (die ich für ein Leben).

Also: Ich bin ein "neuer Benutzer" und habe mich nicht abschrecken lassen - die Tatsache, dass es wie Java funktioniert, gab mir genug Selbstvertrauen, um die Teile zu ignorieren, die ich nicht verstand.

(Der Grund, warum ich mich mit Scala beschäftigte, war zum Teil, ob ich es bei der Arbeit pushen sollte, und ich werde es noch nicht tun. Eine weniger einschüchternde Dokumentation zu machen, würde sicherlich helfen, aber Was mich überrascht hat, ist, wie sehr es sich noch verändert und weiterentwickelt (um fair zu sein, was mich am meisten überrascht hat, wie großartig es ist, aber die Änderungen kamen eine knappe Sekunde später) Die begrenzten Ressourcen wurden verwendet, um einen endgültigen Zustand zu erreichen. Ich glaube nicht, dass sie damit rechnen, so bald so beliebt zu sein.)

11
andrew cooke

Weiß nicht Scala allerdings vor ein paar Wochen konnte ich Clojure nicht lesen. Jetzt kann ich das meiste lesen, kann aber noch nichts weiter schreiben als das einfachste Beispiele Ich vermute Scala ist nicht anders. Sie brauchen ein gutes Buch oder einen guten Kurs, je nachdem, wie Sie lernen. Lesen Sie einfach die - map Erklärung oben, ich habe vielleicht 1/3 davon.

Ich glaube, die größeren Probleme liegen nicht in der Syntax dieser Sprachen, sondern in der Übernahme und Internalisierung der Paradigmen , die sie für den alltäglichen Produktionscode brauchbar machen. Für mich war Java war kein großer Sprung von C++, das war kein großer Sprung von C, das war überhaupt kein Sprung von Pascal, noch Basic etc ... Aber Codierung in einem funktionalen Sprache wie Clojure ist ein großer Sprung (für mich jedenfalls). Ich schätze in Scala Sie können in Java Stil oder = codieren Scala style. Aber in Clojure werden Sie ein ziemliches Durcheinander schaffen, indem Sie versuchen, Ihre imperativen Gewohnheiten vor Java zu schützen.

10
Jeff G

Scala hat eine Menge verrückter Funktionen (insbesondere, wenn es um implizite Parameter geht), die sehr kompliziert und akademisch aussehen, aber die Bedienung vereinfachen sollen. Die nützlichsten erhalten syntaktischen Zucker (wie [A <% B] was bedeutet, dass ein Objekt vom Typ A eine implizite Konvertierung in ein Objekt vom Typ B) und eine gut dokumentierte Erklärung dessen hat, was sie tun. Meistens können Sie als Client dieser Bibliotheken die impliziten Parameter ignorieren und darauf vertrauen, dass sie das Richtige tun.

7
Ken Bloom

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

Ich glaube nicht, dass dies der Hauptfaktor ist, der die Beliebtheit von Scala beeinflusst, da Scala eine Menge Leistung hat und die Syntax Java/C++ nicht so fremd ist/PHP Programmierer wie Haskell, OCaml, SML, Lisps, etc ..

Aber ich denke, dass Scalas Popularität weniger hoch sein wird als heute, wo Java ist, weil ich auch denke, dass die nächste Mainstream-Sprache stark vereinfacht werden muss und der einzige Weg, den ich sehe, um dorthin zu gelangen, reine Unveränderlichkeit ist, dh deklarativ wie HTML, aber Turing komplett. Ich bin jedoch voreingenommen, weil ich eine solche Sprache entwickle, aber ich habe dies erst getan, nachdem ich ein mehrmonatiges Studium ausgeschlossen hatte, dass Scala für das, was ich brauchte, nicht ausreichen konnte.

Wird dies Scala in der Geschäftswelt einen schlechten Ruf als akademisches Spielzeug verleihen, das nur engagierte Doktoranden verstehen können? Werden CTOs und Softwarechefs Angst bekommen?

Ich glaube nicht, dass Scalas Ruf unter dem Haskell-Komplex leiden wird. Aber ich denke, einige werden es aufschieben, es zu lernen, denn für die meisten Programmierer sehe ich noch keinen Anwendungsfall, der sie dazu zwingt, Scala zu benutzen, und sie werden es zögern, etwas darüber zu lernen. Vielleicht ist die hoch skalierbare Serverseite der überzeugendste Anwendungsfall.

Und für den Mainstream-Markt ist das erste Lernen von Scala kein "Hauch frischer Luft", bei dem man sofort Programme schreibt, beispielsweise zuerst mit HTML oder Python. Scala neigt dazu, an dir zu wachsen, nachdem man alle Details gelernt hat, über die man von Anfang an stolpert. Wenn ich jedoch von Anfang an Programmieren in Scala gelesen hätte, wären meine Erfahrungen und meine Meinung zur Lernkurve anders gewesen.

War die Neugestaltung der Bibliothek eine vernünftige Idee?

Bestimmt.

Wenn Sie Scala kommerziell verwenden, machen Sie sich darüber Sorgen? Planen Sie die sofortige Übernahme von 2.8 oder warten Sie ab, was passiert?

Ich verwende Scala als erste Plattform meiner neuen Sprache. Ich würde wahrscheinlich keinen Code für die Scala-Auflistungsbibliothek erstellen, wenn ich Scala nicht kommerziell verwenden würde. Ich würde meine eigene kategorietheoretische Bibliothek erstellen, da ich Scalaz 'Typensignaturen beim ersten Mal noch ausführlicher und unhandlicher fand als Scalas Sammlungsbibliothek. Ein Teil dieses Problems ist vielleicht Scalas Art, Typklassen zu implementieren, und das ist ein kleiner Grund, warum ich meine eigene Sprache erstelle.


Ich habe mich dazu entschlossen, diese Antwort zu schreiben, weil ich mich dazu zwingen wollte, das Design der Scala-Sammlungsklasse mit dem zu vergleichen, das ich für meine Sprache mache. Könnte auch meinen Denkprozess teilen.

Die 2.8 Scala Sammlungen, die eine Builder-Abstraktion verwenden, sind ein solides Entwurfsprinzip. Ich möchte im Folgenden zwei Design-Kompromisse untersuchen.

  1. NUR-SCHREIB-CODE: Nachdem ich diesen Abschnitt geschrieben habe, lese ich Carl Smotriczs Kommentar , was mit dem übereinstimmt, was ich als Kompromiss erwarte. Die Kommentare von James Strachan und davetron5000 stimmen darin überein, dass die Bedeutung von That (es ist nicht einmal That [B]) und der Mechanismus des Impliziten nicht einfach intuitiv zu erfassen sind. Siehe meine Verwendung von Monoid in Ausgabe 2 unten, die meiner Meinung nach viel expliziter ist. In Derek Mahars Kommentar geht es um das Schreiben von Scala, aber wie steht es mit dem Lesen der Scala anderer, die nicht "in den üblichen Fällen" vorkommen?.

    Eine Kritik, die ich über Scala gelesen habe, ist, dass es einfacher ist, sie zu schreiben, als den Code zu lesen, den andere geschrieben haben. Und ich finde, dass dies gelegentlich aus verschiedenen Gründen zutrifft (z. B. viele Möglichkeiten zum Schreiben einer Funktion, automatische Schließungen, Einheit für DSLs usw.), aber ich bin unschlüssig, ob dies ein wichtiger Faktor ist. Hier hat die Verwendung impliziter Funktionsparameter Vor- und Nachteile. Auf der positiven Seite wird die Ausführlichkeit reduziert und die Auswahl des Builder-Objekts automatisiert. In Oderskys Beispiel ist die Konvertierung von einem BitSet, d. H. Set [Int], in ein Set [String] implizit. Der unbekannte Leser des Codes weiß möglicherweise nicht ohne Weiteres, um welchen Auflistungstyp es sich handelt, es sei denn, er kann die potenziellen unsichtbaren Kandidaten für implizite Builder, die im aktuellen Paketbereich vorhanden sein können, gut beurteilen. Natürlich wissen der erfahrene Programmierer und der Schreiber des Codes, dass BitSet auf Int beschränkt ist. Daher muss eine Zuordnung zu String in einen anderen Auflistungstyp konvertiert werden. Aber welche Sammlungsart? Es wird nicht explizit angegeben.

  2. AD-HOC-KOLLEKTIONSDESIGN: Nachdem ich diesen Abschnitt geschrieben hatte, las ich Tony Morris 'Kommentar und stellte fest, dass ich fast den gleichen Punkt anspreche. Vielleicht wird meine ausführlichere Darlegung den Punkt klarer machen.

    In "Fighting Bit Rot with Types" von Odersky & Moors werden zwei Anwendungsfälle vorgestellt. Dies ist die Einschränkung von BitSet auf Int-Elemente und Map auf Pair-Tuple-Elemente und der Grund dafür, dass die allgemeine Elementzuordnungsfunktion A => B in der Lage sein muss, alternative Zielsammlungstypen zu erstellen. Dies ist jedoch aus kategorietheoretischer Sicht mangelhaft. Um in der Kategorietheorie konsistent zu sein und somit Eckfälle zu vermeiden, sind diese Auflistungstypen Funktoren, bei denen jeder Morphismus A => B zwischen Objekten in derselben Funktorkategorie, Liste [A] => Liste [B], BitSet, abgebildet werden muss [A] => BitSet [B]. Eine Option ist beispielsweise ein Funktor, der als eine Sammlung von Mengen von Some (Objekt) und None (Keine) angesehen werden kann. Es gibt keine Übersichtskarte von Options None oder List's Nil zu anderen Funktoren, die keinen "leeren" Zustand haben.

    Hier wird eine Kompromissentwurfsauswahl getroffen. In der Design for Collections-Bibliothek meiner neuen Sprache habe ich mich dafür entschieden, alles zu einem Funktor zu machen. Wenn ich also ein BitSet implementiere, muss es alle Elementtypen unterstützen, indem eine interne Nicht-Bit-Felddarstellung verwendet wird, wenn es mit einem Nicht-Bit-Feld dargestellt wird. Parameter vom Typ Ganzzahl, und diese Funktionalität ist bereits in der Menge enthalten, von der sie in Scala erbt. Außerdem muss Map in meinem Design nur seine Werte abbilden, und es kann eine separate Nicht-Funktionsmethode zum Abbilden seiner Paartupel (Schlüssel, Wert) bereitgestellt werden. Ein Vorteil ist, dass jeder Funktor dann in der Regel auch ein Applikativer und vielleicht auch eine Monade ist. Somit sind alle Funktionen zwischen Elementtypen, z. A => B => C => D => ... werden automatisch zu den Funktionen zwischen angehobenen anwendbaren Typen angehoben, z. Liste [A] => Liste [B] => Liste [C] => Liste [D] => .... Für die Zuordnung von einem Funktor zu einer anderen Sammlungsklasse biete ich eine Kartenüberladung an, die ein Monoid, z. Nil, None, 0, "", Array () usw. Die Builder-Abstraktionsfunktion ist also die Append-Methode eines Monoids und wird explizit als erforderlicher Eingabeparameter angegeben, also ohne unsichtbare implizite Konvertierungen. (Tangens: Mit diesem Eingabeparameter können Sie auch an nicht leere Monoide anhängen, was Scalas Kartendesign nicht kann.) Solche Konvertierungen sind eine Karte und eine Falte in demselben Iterationsdurchlauf. Außerdem biete ich die Kategorie "Anwendungsprogrammierung mit Effekten" an, mit der McBride & Patterson in einem einzigen Iterationsdurchgang das Map + Fold-Verfahren von jeder überquerbaren zu jeder anwendbaren Klasse ermöglicht, bei der fast jede Sammlungsklasse beides ist. Auch die Staatsmonade ist ein Anwendungsfall und somit eine vollständig verallgemeinerte Erbauerabstraktion von jedem Durchquerbaren.

    Daher ist die Sammlung Scala "ad-hoc" in dem Sinne, dass sie nicht auf Kategorietheorie beruht, und Kategorietheorie ist der Kern der Denotationssemantik auf höherer Ebene. Obwohl die impliziten Builder von Scala auf den ersten Blick "verallgemeinerter" sind als ein Funktionsmodell + Monoid-Builder + überquerbar -> anwendbar, ist bekannt, dass sie keiner Kategorie entsprechen, weshalb wir nicht wissen, nach welchen Regeln sie sich richten Ganz allgemein und was die Eckfälle angeht, dürfen sie keinem Kategoriemodell gehorchen. Es ist einfach nicht wahr, dass das Hinzufügen von mehr Variablen etwas allgemeiner macht, und dies war einer der großen Vorteile der Kategorietheorie, da Regeln bereitgestellt werden, mit denen die Allgemeinheit aufrechterhalten werden kann, während zu einer höheren Semantik übergegangen wird. Eine Sammlung ist eine Kategorie.

    Ich habe irgendwo gelesen, ich glaube, es war Odersky, als eine weitere Rechtfertigung für das Bibliotheksdesign, dass das Programmieren in einem rein funktionalen Stil die Kosten einer begrenzten Rekursion und Geschwindigkeit verursacht, wenn keine Schwanzrekursion verwendet wird. Ich habe es nicht schwierig gefunden, in jedem Fall, dem ich bisher begegnet bin, eine Schwanzrekursion anzuwenden.


Außerdem habe ich eine unvollständige Vorstellung davon, dass einige der Kompromisse von Scala darauf zurückzuführen sind, dass versucht wird, sowohl eine veränderbare als auch eine unveränderliche Sprache zu sein, anders als zum Beispiel Haskell oder die Sprache, die ich entwickle. Dies stimmt mit Tony Morris 'Kommentar zum Verständnis überein. In meiner Sprache gibt es keine Schleifen und keine veränderlichen Konstrukte. Meine Sprache wird (vorerst) über Scala stehen und hat viel zu verdanken, und dies wäre nicht möglich, wenn Scala nicht das allgemeine Typsystem und die allgemeine Veränderlichkeit hätte. Dies mag jedoch nicht zutreffen, da ich denke, dass Odersky & Moors ("Fighting Bit Rot with Types") falsch ist, um zu behaupten, dass Scala die einzige OOP Sprache mit höheren Arten ist. weil ich (mich selbst und über Bob Harper) überprüft habe, dass Standard ML sie hat. Außerdem scheint das Typensystem von SML (seit den 1980er Jahren) möglicherweise äquivalent flexibel zu sein, was möglicherweise nicht ohne Weiteres gewürdigt werden kann, da die Syntax Java (und C++/PHP) weniger ähnlich ist als Scala. Auf jeden Fall ist dies keine Kritik an Scala, sondern ein Versuch, eine unvollständige Analyse der Kompromisse vorzulegen, was meiner Meinung nach für die Frage von Belang ist. Scala und SML leiden nicht unter Haskells Unfähigkeit Mehrfachvererbung von Diamanten , was kritisch ist und ich verstehe, warum so viele Funktionen im Haskell-Präludium für verschiedene Typen wiederholt werden.

6

Es scheint notwendig, hier einen Abschluss anzugeben: B.A. in Politikwissenschaft und B.ed in Informatik.

Auf den Punkt gebracht:

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

Scala ist schwierig, weil das zugrunde liegende Programmierparadigma schwierig ist. Funktionale Programmierung macht vielen Menschen Angst. Es ist möglich, Closures in PHP zu erstellen, aber die Leute tun dies selten. Also nein, nicht diese Signatur, sondern der ganze Rest wird die Leute abschrecken, wenn sie nicht die spezifische Ausbildung haben, die sie dazu bringt, das zu schätzen Macht des zugrunde liegenden Paradigmas.

Wenn diese Ausbildung verfügbar ist, kann es jeder machen. Letztes Jahr habe ich mit ein paar Schulkindern in SCALA einen Schachcomputer gebaut! Sie hatten ihre Probleme, aber sie haben es am Ende gut gemacht.

Wenn Sie Scala kommerziell verwenden, machen Sie sich darüber Sorgen? Planen Sie die sofortige Einführung von 2.8 oder warten Sie ab, was passiert?

Ich würde mir keine Sorgen machen.

5
Julian Dehne

Ich habe auch einen Mathematik-Abschluss in Oxford! Ich habe eine Weile gebraucht, um die neuen Kollektionen zu besorgen. Aber ich mag es jetzt sehr, dass ich es tue. Tatsächlich war die Eingabe von 'map' eines der ersten großen Probleme, die mich in 2.7 störten (vielleicht, seit ich als erstes eine der Sammlungsklassen untergeordnet habe).

Das Lesen von Martins Abhandlung über die neuen 2.8-Sammlungen hat die Verwendung von Implicits wirklich erklärt, aber ja, die Dokumentation selbst muss definitiv besser die Rolle verschiedener Implicits innerhalb der Methodensignaturen von Kern-APIs erklären.

Mein Hauptanliegen ist eher folgendes: Wann wird 2.8 veröffentlicht? Wann werden die Fehlerberichte aufhören, dafür einzutreten? Haben scala Team mehr abgebissen, als sie mit 2.8 kauen können/versucht, zu viel auf einmal zu ändern?

Ich würde es wirklich begrüßen, wenn 2.8 als Priorität für die Veröffentlichung stabilisiert würde, bevor ich überhaupt etwas Neues hinzufüge, und mich (während ich von der Seitenlinie aus beobachte) frage, ob einige Verbesserungen an der Art und Weise vorgenommen werden könnten, wie die Entwicklungs-Roadmap für scala Compiler wird verwaltet.

4
Matt