Frage Ist die Scala 2.8 Bibliothek ein Fall von "dem längsten Abschiedsbrief in der Geschichte"? [geschlossen]


Ich habe gerade angefangen, mir die Scala Sammlungsbibliothek Re-Implementierung was im kommenden kommt 2.8 Freisetzung. Diejenigen, die mit der Bibliothek von 2.7 vertraut sind, werden feststellen, dass sich die Bibliothek aus der Sicht der Nutzung wenig verändert hat. Beispielsweise...

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

... würde in beiden Versionen funktionieren. Die Bibliothek ist hervorragend nutzbar: In der Tat ist es fantastisch. Diejenigen jedoch, die mit Scala und herumstochern, um ein Gefühl für die Sprache zu bekommen müssen nun Methodensignaturen wie:

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

Für solch einfache Funktionalität ist dies eine abschreckende Signatur und eine, die ich selbst nicht verstehen kann. Nicht dass ich glaube, dass Scala jemals der nächste Java sein würde (oder / C / C ++ / C #) - Ich glaube nicht, dass seine Schöpfer es auf diesen Markt zielen - aber ich denke, es ist / war Scala sicher möglich, der nächste Ruby oder Python zu werden (dh einen bedeutenden kommerziellen Nutzer zu gewinnen) -Base)

  • Wird das Leute dazu bringen, nach Scala zu kommen?
  • Wird das Scala in der kommerziellen Welt einen schlechten Ruf geben? akademisches Spielzeug das können nur engagierte Doktoranden verstehen? Sind CTOs und die Köpfe der Software werden verängstigt?
  • War die Bibliothek eine vernünftige Idee?
  • Wenn Sie Scala kommerziell nutzen, machen Sie sich darüber Sorgen? Planen Sie, 2.8 sofort zu übernehmen oder abzuwarten, was passiert?

Steve Yegge  einmal angegriffen Scala (fälschlicherweise meiner Meinung nach) für das, was er als sein kompliziertes Typsystem ansah. Ich mache mir Sorgen, dass sich jemand einen Feldtag ausbreiten wird FUD mit dieser API (ähnlich wie Josh Bloch die JCP aus dem Hinzufügen von Schließungen zu Java).

Hinweis - Ich sollte mir das klar machen, obwohl ich das glaube Joshua Bloch war einflussreich in der Ablehnung der BGGA Schließungen Vorschlag, ich schreibe dies nicht anders als seine ehrlich gehaltene Überzeugungen, dass der Vorschlag einen Fehler darstellt.


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

Beachten Sie, dass der Titel des entzündlichen Subjekts a lautet Zitat über das Manifest einer britischen politischen Partei in den frühen 1980er Jahren. Diese Frage ist subjektiv, aber es ist eine echte Frage, ich habe es in CW gemacht, und ich hätte gerne einige Meinungen dazu.


809


Ursprung


Antworten:


Ich hoffe, es ist kein "Abschiedsbrief", aber ich kann Ihren Standpunkt sehen. Sie treffen auf, was gleichzeitig eine Stärke und ein Problem von Scala ist: sein Erweiterbarkeit. Dadurch können wir die meisten Hauptfunktionen in Bibliotheken implementieren. In einigen anderen Sprachen, Sequenzen mit etwas wie mapoder collect würde eingebaut werden, und niemand muss alle Reifen sehen, die der Compiler durchlaufen muss, damit sie reibungslos funktionieren. In Scala ist alles in einer Bibliothek und deshalb draußen.

In der Tat die Funktionalität von map das wird durch seinen komplizierten Typ unterstützt, ist 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 bekommen? Wenn Sie eine Karte erstellen Ints zu Ints bekommst du wieder ein BitSet, aber wenn du mietest Ints zu Strings, du bekommst einen General Set. Sowohl der statische Typ als auch die Laufzeitdarstellung des Ergebnisses einer Map hängen vom Ergebnistyp der Funktion ab, die an sie übergeben wird. Und das funktioniert auch, wenn das Set leer ist, also wird die Funktion nie angewendet! Soweit ich weiß, gibt es kein anderes Sammel-Framework mit einer entsprechenden Funktionalität. Aus Sicht der Benutzer sind dies jedoch die Dinge soll arbeiten.

Das Problem, das wir haben, ist, dass all die clevere Technologie, die das ermöglicht, in die Typensignaturen mündet, die groß und beängstigend werden. Aber vielleicht sollte ein Benutzer nicht standardmäßig die vollständige Typ-Signatur von angezeigt werden map? Wie wäre es, wenn sie aufschaut? map im BitSet Sie hat:

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

Die Dokumente würden in diesem Fall nicht liegen, weil aus der Sicht eines Benutzers tatsächlich Karte den Typ hat (Int => Int) => BitSet. Aber map hat auch einen allgemeineren Typ, der durch Klicken auf einen anderen Link überprüft werden kann.

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


828



Ich habe weder einen Doktortitel noch irgendeinen anderen Abschluss, weder in Mathematik noch in irgendeinem anderen Bereich. Ich habe keine Erfahrung mit Scala oder einer anderen ähnlichen Sprache. Ich habe keine Erfahrung mit auch nur annähernd vergleichbaren Typsystemen. In der Tat, die einzige Sprache, die ich mehr als nur eine oberflächliche Kenntnis davon habe hat Ein Typsystem ist Pascal, nicht gerade für sein ausgeklügeltes Typsystem bekannt. (Obwohl es tut Habe Range types, die AFAIK so ziemlich 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 sogar ein Typsystem hat.

Und doch verstehe ich die Signatur der map Funktion, die du gepostet hast. Es sieht für mich fast genauso aus wie das map hat in jeder anderen Sprache, die ich je gesehen habe. Der Unterschied ist, dass diese Version generischer ist. Es sieht eher aus wie eine C ++ - STL-Sache als, sagen wir, Haskell. Insbesondere abstrahiert sie von der konkreten Sammlungsart, indem sie lediglich die Argumentation verlangt IterableLikeund abstrahiert auch vom konkreten Rückgabetyp, indem nur eine implizite Konvertierungsfunktion benötigt wird, die aufgebaut werden kann etwas aus dieser Sammlung von Ergebniswerten. Ja, das ist ziemlich komplex, aber es ist wirklich nur ein Ausdruck des allgemeinen Paradigmas der generischen Programmierung: Nimm nichts an, was du nicht wirklich tun musst.

In diesem Fall, map eigentlich nicht brauchen die Sammlung als Liste oder als Sortierung oder Sortierung oder ähnliches. Das einzige, das map Es geht darum, dass man alle Elemente der Sammlung nacheinander aufrufen kann, aber nicht in einer bestimmten Reihenfolge. Und es muss nicht wissen, was die resultierende Sammlung ist, es muss nur wissen, wie es gebaut wird. Das ist es, was seine Typ-Signatur erfordert.

Also, statt

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

Das ist die traditionelle Art Unterschrift für mapEs wird verallgemeinert, keinen Beton zu benötigen List sondern nur ein IterableLike Datenstruktur

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

Dies wird dann weiter verallgemeinert, indem nur gefordert wird, dass eine Funktion existiert, die dies kann Konvertieren das Ergebnis zu welcher Datenstruktur der Benutzer will:

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

Ich gebe zu, dass die Syntax ein wenig klirrender ist, aber die Semantik ist die gleiche. Grundsätzlich beginnt es von

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

Das ist die traditionelle Unterschrift für map. (Beachten Sie, dass aufgrund der objektorientierten Natur von Scala der Parameter der Eingabeliste verschwindet, weil er jetzt der implizite Empfängerparameter ist, den jede Methode in einem OSSystem mit einem einzigen Versand hat.) Dann wird er aus einem konkreten verallgemeinert List zu einem allgemeineren IterableLike

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

Jetzt ersetzt es die IterableLike Ergebnissammlung mit einer Funktion, die produziertNun, wirklich, einfach über alles.

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

Was ich wirklich glaube ist nicht Das schwer zu verstehen. Es gibt wirklich nur ein paar intellektuelle Werkzeuge, die du brauchst:

  1. Sie müssen (grob) was wissen map ist. Wenn du gibst nur die Typensignatur ohne den Namen der Methode, ich gebe zu, es wäre viel schwieriger herauszufinden, was vor sich geht. Aber seit du schon kennt Was map Eigentlich sollte es so sein, und Sie wissen, was seine Typus-Signatur sein soll. Sie können die Signatur schnell scannen und sich auf die Anomalien konzentrieren, wie "warum tut das das?" map Nimm zwei Funktionen als Argumente, nicht einen? "
  2. Sie müssen es tatsächlich können lesen die Typ-Signatur. Aber selbst wenn Sie Scala noch nie zuvor gesehen haben, sollte dies ziemlich einfach sein, da es sich nur um eine Mischung aus Typensyntaxen handelt, die Sie bereits aus anderen Sprachen kennen: VB.NET verwendet eckige Klammern für parametrischen Polymorphismus und mit einem Pfeil den Rückgabetyp und ein Doppelpunkt, um Name und Typ zu trennen, ist eigentlich die Norm.
  3. Sie müssen ungefähr wissen, was generische Programmierung bedeutet. (Was nicht ist Das schwer zu verstehen, da es im Grunde alles im Namen buchstabiert ist: es ist buchstäblich nur in einer generischen Art und Weise zu programmieren).

Keines dieser drei Dinge sollte professionellen oder sogar Hobby-Programmierern ernsthafte Kopfschmerzen bereiten. map In fast jeder Sprache, die in den letzten 50 Jahren entworfen wurde, war die Standardfunktion eine Standardfunktion. Die Tatsache, dass verschiedene Sprachen unterschiedliche Syntax haben, sollte für jeden offensichtlich sein, der eine Website mit HTML und CSS entworfen hat verwandte Mailingliste ohne irgendeinen nervigen C ++ Fanboy aus der Kirche von St. Stepanov, der die Tugenden der generischen Programmierung erklärt.

Ja, Scala ist Komplex. Ja, Scala verfügt über eines der ausgeklügeltsten Systemtypen, das den Menschen bekannt ist. Es konkurriert und übertrifft sogar Sprachen wie Haskell, Miranda, Clean oder Cyclone. 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 sehr wahrscheinlich nicht erfolgreich sein wird, aber die Tatsache, dass Programmierer sich nicht die Mühe machen können, ihren Kopf einzuschalten, bevor sie sich vor die Tastatur setzen, wird wahrscheinlich nicht die wichtigste sein.


206



Das Gleiche gilt für 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;
}

163



Nun, ich kann deinen Schmerz verstehen, aber, ehrlich gesagt, 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 diese Art Signatur nicht mögen, weil Sie werden sie nie sehen! Sie lesen keine Dokumentation.

So lange sie ein Beispiel dafür sahen, wie der Code funktioniert, und der Code scheitert nicht daran, das Ergebnis zu erzeugen erwarten von, sie werden niemals die Dokumentation anschauen. Wenn das fehlschlägt, sehen sie sich die Dokumentation an und erwarten zu sehen Anwendungsbeispiele oben.

Mit diesen Dingen denke ich, dass:

  1. Jeder (wie in den meisten Menschen), der jemals diese Typus-Signatur antrifft, wird Scala bis zum Ende durchspielen, wenn sie sich dagegen aussprechen, und wird es als ein Symbol für Scalas Macht betrachten, wenn sie Scala mögen.

  2. Wenn die Dokumentation nicht erweitert wurde, um Anwendungsbeispiele zu liefern und klar zu erklären, wofür eine Methode geeignet ist und wie sie verwendet wird, kann dies die Verwendung von Scala ein wenig beeinträchtigen.

  3. Auf lange Sicht wird es nichts ausmachen. Diese Scala kann Solche Sachen machen Bibliotheken für Scala viel mächtiger und sicherer zu benutzen. Diese Bibliotheken und Frameworks werden Programmierer zu leistungsfähigen Werkzeugen anlocken.

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

Leider haben Java-Programmierer viel mit Elektrowerkzeugen zu tun. Daher habe ich gerade meine Erwartungen bezüglich der Einführung von Scala im Allgemeinen geändert. Ich habe keinen Zweifel, dass Scala eine Mainstream-Sprache wird. Nicht C-Mainstream, aber vielleicht Perl-Mainstream oder PHP-Mainstream.

Apropos Java, hast du jemals den Klassenlader ersetzt? Hast du jemals darüber nachgedacht, was damit verbunden ist? Java kann beängstigend sein, wenn man sich die Orte ansieht, die Schreiber schreiben. Es ist nur so, dass die meisten Leute das nicht tun. Dasselbe gilt für Scala, IMHO, aber die ersten Anwender neigen dazu, unter jeden Stein zu schauen, um zu sehen, ob sich dort etwas versteckt.


67



Wird das Leute dazu bringen, nach Scala zu kommen?

Ja, aber es wird auch verhindern, dass Menschen aufgehalten werden. Ich habe das Fehlen von Sammlungen, die höher verwandte Typen verwenden, als eine große Schwäche angesehen, seit Scala Unterstützung für höher verwandte Typen erhalten hat. Es macht die API-Dokumentation komplizierter, aber es macht die Verwendung natürlicher.

Wird dies Scala in der kommerziellen Welt einen schlechten Ruf geben als ein akademisches Spielzeug, das nur engagierte Doktoranden verstehen können? Werden CTOs und Softwareköpfe abschrecken?

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

War die Bibliothek eine vernünftige Idee?

Absolut. Es passt Sammlungen viel besser mit dem Rest der Sprache und dem Typsystem, auch wenn es noch einige Ecken und Kanten hat.

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

Ich benutze es nicht kommerziell. Ich werde wahrscheinlich warten, bis zumindest ein paar in die 2.8.x-Serie übergeht, bevor ich sogar versuche, sie einzuführen, damit die Fehler beseitigt werden können. Ich werde auch abwarten, um zu sehen, wie viel Erfolg die EPFL bei der Entwicklung eines Release-Prozesses hat. Was ich sehe, sieht hoffnungsvoll aus, aber ich arbeite für eine konservative Firma.

Ein allgemeines Thema von "Ist Scala für Mainstream-Entwickler zu kompliziert?" ...

Die meisten Entwickler, Mainstream oder andere, pflegen oder erweitern bestehende Systeme. Dies bedeutet, dass das meiste von dem, 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 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 heute erfolgreichsten Entwicklern neuer Anwendungen verwendet wird.


52



Eine Möglichkeit, mit der die Scala-Gemeinschaft die Angst vor neuen Scala-Programmierern lindern kann, besteht darin, sich auf die Praxis zu konzentrieren und mit gutem Beispiel zu lehren - viele Beispiele, die klein anfangen und allmählich größer werden. Hier sind einige Websites, die diesen Ansatz verfolgen:

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


46



Ich habe einen Bachelor-Abschluss von einer billigen "Massenmarkt" US-Universität, also würde ich sagen, dass ich in die Mitte der Benutzerintelligenz (oder zumindest der Bildung) stürze :) Ich habe mit Scala für nur ein paar Monate getüftelt und habe an zwei oder drei nicht-trivialen Apps gearbeitet.

Vor allem jetzt, da IntelliJ ihre gute IDE mit dem derzeit besten Scala-Plugin von IMHO veröffentlicht hat, ist die Scala-Entwicklung relativ schmerzlos:

  • Ich finde, dass ich Scala als "Java ohne Semikolons" verwenden kann, d. H. Ich schreibe ähnlich aussehenden Code wie ich in Java, und ein wenig von syntaktischer Kürze, wie sie durch Typinferenz gewonnen wird. Ausnahme-Handling, wenn ich es überhaupt mache, ist bequemer. Die Klassendefinition ist viel weniger ausführlich ohne die Getter / Setter-Boilerplate.

  • Hin und wieder schaffe ich es, eine einzige Zeile zu schreiben, um das Äquivalent von mehreren Java-Zeilen zu erreichen. Wo anwendbar, sind Ketten funktionaler Methoden wie Karten, Falten, Sammeln, Filtern usw. Spaß beim Komponieren und elegant anzusehen.

  • Nur selten finde ich, dass ich von den leistungsstärkeren Funktionen von Scala profitiere: Verschlüsse und teilweise (oder Curry-) Funktionen, Mustervergleich ... das ist etwas.

Als Neuling habe ich weiterhin mit der knappen und idiomatischen Syntax zu kämpfen. Methodenaufrufe ohne Parameter benötigen keine Klammern, außer dort, wo sie es tun. Fälle in der Übereinstimmungserklärung benötigen einen dicken Pfeil ( => ), aber es gibt auch Orte, wo du einen dünnen Pfeil brauchst ( -> ). Viele Methoden haben kurze aber eher kryptische Namen wie /:oder \: - Ich kann meine Sachen erledigen, wenn ich genug manuelle Seiten blättere, aber ein Teil meines Codes sieht aus wie Perl oder Zeilenrauschen. Ironischerweise fehlt eine der populärsten Bits der syntaktischen Kurzschrift in Aktion: Ich werde immer wieder von der Tatsache gebissen, dass Int definiert nicht a ++ Methode.

Das ist nur meine Meinung: Ich habe das Gefühl, dass Scala die Macht von C ++ in Verbindung mit der Komplexität und Lesbarkeit von C ++ hat. Die syntaktische Komplexität der Sprache macht auch die API-Dokumentation schwer lesbar.

Scala ist sehr gut durchdacht und in vielerlei Hinsicht brillant. Ich vermute, viele Akademiker würden gerne darin programmieren. Es ist aber auch voller Klugheit und Fehler, es hat eine viel höhere Lernkurve als Java und ist schwerer zu lesen. Wenn ich die Foren scanne und sehe, wie viele Entwickler noch mit den Feinheiten von Java kämpfen, Ich kann mir nicht vorstellen, dass Scala jemals eine Mainstream-Sprache wird. Kein Unternehmen wird es rechtfertigen können, seine Entwickler auf einen 3-wöchigen Scala-Kurs zu schicken, wenn sie früher nur einen 1-wöchigen Java-Kurs benötigten.


40



Ich denke, das primäre Problem bei dieser Methode ist, dass die (implicit bf : CanBuildFrom[Repr, B, That]) geht ohne Erklärung. Obwohl ich weiß, welche impliziten Argumente es gibt, gibt es nichts, was anzeigt, wie sich dies auf den Anruf auswirkt. Jagen durch die Scaladoc lässt mich nur verwirrter (nur wenige der damit verbundenen Klassen) CanBuildFrom habe sogar Dokumentation).

Ich denke, ein einfaches "da muss ein implizites Objekt im Umfang sein bf Dies bietet einen Builder für Objekte des Typs B in den Rückgabetyp That"würde etwas helfen, aber es ist eine Art berauschende Konzept, wenn alles, was Sie wirklich tun möchten, ist Karte Aist es Bist es. In der Tat, ich bin mir nicht sicher, ob das stimmt, weil ich nicht weiß, was der Typ ist Repr bedeutet, und die Dokumentation für Traversable gibt sicher keine Ahnung.

Ich habe also zwei Möglichkeiten, die beide nicht angenehm sind:

  • Angenommen, es funktioniert nur, wie die alte Karte funktioniert und wie die Karte in den meisten anderen Sprachen funktioniert
  • Grabe mehr in den Quellcode ein

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


32



Ich bin ein Scala-Anfänger und ich sehe ehrlich gesagt kein Problem mit dieser Typ-Signatur. Der Parameter ist die zuzuordnende Funktion und der implizite Parameter der Builder, um die korrekte Sammlung zurückzugeben. Klar und lesbar.

Das Ganze ist eigentlich sehr elegant. Mit den Parametern des Builder-Typs kann der Compiler den richtigen Rückgabetyp auswählen, während der implizite Parametermechanismus diesen zusätzlichen Parameter vor dem Klassenbenutzer versteckt. 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 richtiger Polymorphismus.

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


22



Leider ist die Karte, die du angegeben hast, falsch für die Karte und es gibt tatsächlich berechtigte Kritik.

Der erste Kritikpunkt ist, dass wir durch Subversion der Signatur für die Karte etwas allgemeineres haben. Es ist ein häufiger Fehler zu glauben, dass dies eine Tugend ist. Es ist nicht. Die Kartenfunktion ist sehr gut als kovarianter Funktor Fx -> (x -> y) -> Fy unter Einhaltung der beiden Gesetze der Komposition und Identität definiert. Alles andere, was man "Karte" zuschreibt, ist eine Travestie.

Die angegebene Signatur ist etwas anderes, aber es ist keine Karte. Was ich vermute, dass es versucht zu sein, ist eine spezialisierte und leicht veränderte Version der "Traverse" -Signatur aus der Zeitung 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 in Scala umwandeln:

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 Identity Funktor durchlaufen). Ich vermute jedoch, dass, wenn die Bibliotheksverfasser mehr über gut dokumentierte Verallgemeinerungen der Bibliothek wüssten (Applicative Programming with Effects geht dem oben genannten voraus), dann würden wir diesen Fehler nicht sehen.

Zweitens ist die Kartenfunktion in Scala ein Sonderfall wegen ihrer Verwendung in For-Comprehensions. Dies bedeutet leider, dass ein Bibliotheksdesigner, der besser ausgestattet ist, diesen Fehler nicht ignorieren kann, ohne auch den syntaktischen Zucker der Verständlichkeit zu opfern. Mit anderen Worten, wenn die Designer der Scala-Bibliothek eine Methode zerstören sollten, dann wird dies leicht ignoriert, aber bitte nicht zuordnen!

Ich hoffe, dass jemand darüber spricht, denn so wie es ist, wird es 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!)" Ist nicht "beschwichtigen sie, um es ihnen leichter zu machen", sondern bietet stattdessen Hinweise und Unterstützung, um bessere Programmierer zu werden. Ich und Scala Ziele sind in dieser Frage, aber zurück zu Ihrem Punkt.

Sie haben wahrscheinlich Ihren Standpunkt klargemacht und bestimmte Antworten von "dem durchschnittlichen Programmierer" vorhergesagt. Das heißt, die Leute, die behaupten werden "aber es ist zu kompliziert!" oder einige solcher. Dies sind die Yegges oder Blochs, auf die du dich beziehst. Meine Reaktion auf diese Leute der Anti-Intellektualismus / Pragmatismus-Bewegung ist ziemlich hart und ich erwarte bereits eine Flut von Reaktionen, also werde ich es auslassen.

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


20