Scala, das Chamäleon: Oderskys Stufen der Komplexität

Hartmut Schlosser

Scala ist ein bisschen wie ein Chamäleon, schreibt Martin Odersky: Einerseits macht es die Lösung vieler Probleme erfrischend einfach, andererseits erlauben die Scala-Konstrukte die Entwicklung wirklich fortgeschrittener typensicherer Bibliotheken. Resultat: Scala-Code kann je nach Programmierweise einfach oder komplex aussehen.

Der immer wieder aufflammenden Diskussion um die „Komplexität von Scala“ begegnet Scala-Erfinder Odersky mit einer didaktischen Kategorisierung der Scala-Sprachkonstrukte nach Schwierigkeitsgraden.

  • Mit den Sprachkonstrukten aus Level A1 sollen sich angehende Scala-Anwendungsentwickler am schnellsten zurechtfinden: Java-artige Anweisungen wie Standard-Operatoren, Methodenaufrufe, Schleifen, class, object, def, val, var, import, package, Infix-Notation für Methodenaufrufe, einfache Closures, Collections mit map, filter, for-Ausdrücke.
  • Auf dem Level A2 finden sich die Konstrukte für fortgeschrittene Anfänger: Pattern Matching, Traits, Endrekursion, XML-Literale
  • Level A3 für die Experten unter den Anwendungsentwicklern versammelt „Fold“-Methoden, Streams und andere „Lazy“-Datenstrukturen, Aktoren sowie Combinator Parser.

Java-Programmierer, fährt Odersky fort, sollten das erste Level A1 eigentlich in einem Tag beherrschen – und damit bereits produktiv mit Scala arbeiten können. A2 soll die Produktivität dann nochmals erhöhen, A3 müsse nicht für jeden interessant sein. Da die Anforderungen an Entwickler von Bibliotheken andere seien, nimmt die Kategorisierung hier folgende veränderte Gestalt an:

  • Level L1: Typen-Parameter, Traits, Lazy vals, Control Abstraction, Currying, By-Name Parameter
  • Level L2: Variance Annotationen, Existential Types, Self Type Annotationen und das Cake Pattern für Dependency Injection, Structural Types (static duck typing), Definition von map/flatmap/withFilter für neue For-Expressions, Extractors
  • Level L3: Early initializers, Abstract types, Implicit definitions, Higher-kinded types

Die Kategorisierung soll beispielsweise Scala-Anfängern bei der Entscheidung helfen, in welcher Reihenfolge bestimmte Sprachkonstrukte erlernt werden sollten.

Kritik

Oderskys Einteilung für Bibliotheken-Entwickler hat mittlerweile zu einem kritischen Kommentar von Tony Morris, Entwickler der Scala-Bibliothek Scalaz, geführt. Für die Entwicklung professioneller Scala-Bibliotheken sei eine weitaus höhere Kompetenz zu veranschlagen, als die in der dritten Stufe L3 gelisteten Sprachkonstrukte andeuten, meint Morris. Einerseits sei die Kenntnis von Sprachkonstrukten allenfalls die Grundvoraussetzung für die Entwicklung professioneller Scala-Bibliotheken. Andererseits sei Scala – und auch Java – gerade im Bereich der Bibliotheken anderen Sprachen wie Haskell dermaßen unterlegen, dass es schlicht gefährlich sei, so niedrige Standard-Anforderungen für Library-Entwickler anzunehmen.

Interessant ist auch die Diskussion auf reddit, in der unter anderem das Problem zur Sprache kommt, dass Oderskys Stufen-Kategorisierung nicht Grundlage für ein Zertifizierungssystem in Scala sein sollte.

Since this came from Martin himself, I foresee Indian-trained programmers, foolish HR folks and inexperienced development managers seeing this as a cut-in-stone way to label Scala programmers. HIBOU

Odersky äußert sich auf reddit folgendermaßen zum Sinn seiner Kategorisierung:

The list is intended to capture modules of understanding for a programmer, be it library or language. Since Scala aims to be scalable from small scripts to very large systems, you would expect that there are quite a few modules of understanding, independently of how many different language concepts there are. Claiming otherwise would be an oversimplification. Odersky

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.