Currently viewing the tag: "Scala"

Followup to the last article: Bill Venners has a thoughtful introduction to Stackable Traits which is a design pattern in Scala. I used Stackable Traits in the example to demonstrate the usefulness of Mixins.

· Tags: , ·

In his article “Composition over Mixins“ Eric Meyer makes the case why Mixins should not be used, because a Mixin is

 a violation of the SRP by definition.

On the hand, he is right. By using Mixins, different functionality is integrated into one class or object. At least at run time. On the other hand, Mixins actually help to separate responsibilities to different parts at the source code level and thus, at compile time.

For example, the following excerpt from a log processor in Scala consists of an interface LogProcess (line 1) and two implementations LogDumper (line 12) and LogHBaseAdder (line 19). The first just prints the log entry to the console (line 14) and the second adds it to an HBase table (line 21). These two implementations are mixed into the default implementation of the interface creating a single object (lines 28-29) that supports both, printing and adding.

abstract class LogProcessor( val filename: String ) {

  def process() : Unit = {
    Source.fromFile( filename ).
      getLines.map.( line => 
        processEntry( LogEntry(line) ) )
  }

  protected def processEntry( logEntry: LogEntry ) : Unit = {}
}

trait LogDumper extends LogProcessor {
  abstract override protected def processEntry( logEntry: LogEntry ) : Unit = {
    println( logEntry.toString )
    super processLogEntry logEntry
  }
}

trait LogHBaseAdder extends LogProcessor {
  abstract override protected def processEntry( logEntry: LogEntry ) : Unit = {
    htable put logEntry.createPut( family )
    super processLogEntry logEntry
  }
}

object Runner {
  def main( args: Array[String] ) {
    val lp = new LogProcessor( args(0) ) 
      with LogDumper with LogHBaseAdder
    lp.process
  }
}

Of course, this is also possible using composition. But using Mixins, both, LogDumper and LogHBaseAdder, are not aware of each other. Even the interface does not need to know about this. So we do achieve a separation of responsibility and only wire the functionality together when creating the object.

So maybe Mixins are not that bad at all.

· Tags: , , ·

Graham Tackley, Web Platform Team Lead bei guardian.co.uk, spricht in How We (Mostly) Moved from Java to Scala über die Migration der Guardian Webseite von Java zu Scala.

Ab Minute 27 kommt er auf den Vorwurf zu sprechen, Scala sei zu komplex:

One of the expectations people have when coming [to Scala] is to go to a tutorial and be able to understand every single line of Scala code.

Was natürlich bei keiner Programmiersprache geht.

But really, it actually comes down to 4 things that fundamentally change the way you write code and that petrify Java developers. […] And they can be explained on 4 slides.

Und das gelingt ihm auch sehr gut.

Ein spannender Vortrag, der darüber hinaus erklärt, warum sich
der Guardian für Scala + Lift + Apache Solr und gegen Django + Python
bzw. Java + Spring entschieden hat. Must see!

· Tags: ·

Julio Faerman vergleicht in Scala or Java? Exploring myths and facts Scala mit Java. Dabei zeichnet er das Bild, wie Scalas Mächtigkeit Programmierer überfordert. Einzig bleibt die Feststellung, dass Scala zu komplex sei, wenn man die Konzepte der Sprache nicht verinnerliche:

The same features that can make Scala more productive can also make it unreadable.

In der Grundschule wurde mir erklärt, dass 2 * 21 = 42 ist. Das genügt bereits für die meisten Rechnungen im täglichen Leben. Im Studium lernte ich, dass hinter dieser simplen Rechnung Körperaxiome, Vektorräume, die Kantorsche Mengenlehre und schlussendlich die Peanoaxiome stecken.

Diese mathematischen Konzepte muss ich aber nicht anwenden, um rechnen zu können. Ich muss nicht alle Konzepte von Scala einsetzen, um erfolgreich zu programmieren. Ich nutze nur diejenigen, die ich wirklich verstanden habe.

Der wahre Grund für die Überforderung

Es ist die Erfahrung der Programmier; und die ist sprachunabhängig. Verständlicher Code hängt allein vom Programmierer ab, der den Code schreibt. Gerade das ist die wesentliche Aussage von Clean Code. Man kann in jeder Programmiersprache sauber und für andere verständlich programmieren.

Sauber zu programmieren ist die Fähigkeit, die wir erlenen müssen; Sprachkonzepte folgen von allein.

· Tags: , ·

Rúnar Bjarnason hat das Buch ”Functional Programming in Scalaangekündigt. Rúnar ist im Scala Bereich bekannt für seinen Blog Apocalisp. Das Buch entsteht zusammen mit Tony Morris, der ebenfalls ein fester Bestandteil der Scala Community ist. Im kostenlosen Einleitungskapitel versprechen die beiden, das Buch würde allgemein von Funktionaler Programmierung handeln. Lediglich die Beispiele würden in Scala vorgestellt.

Ich freue mich auf das Buch und habe es bereits vorbestellt. Die Funktionale Programmierung gewinnt zunehmend an Fahrt und die beiden Autoren sind genau die richtigen, um an Hand von Scala in dieses Gebiet einzuführen.

· Tags: , , ·