Scala Exchange 2014

English

Ich war am 8. und 9. Dezember 2014 auf der Konferenz Scala Exchange ( #scalaX ) in London.

Von mir besuchte Vorträge waren etwa folgende:

The Binary Compatibility Challenge

Martin Odersky

Es gibt Beispiele von allen vier Kombinationen von Sourcecode- und Binärkompatibilität.
Man wünscht sich von beidem mehr, Schwerpunkt heute aber Binärkompatibilität.
Konflikt für Scala: Innovation vs. Kompatibilität. Java hat den einen Extrempfad gewählt, Kompatibilität über alles, hat es aber auch leichter gehabt, weil Java die JVM mit „kontrolliert“. Clojure, Ruby, JRuby, Perl,… haben alle kein Problem mit Binärkompatibilität, weil sie in der Regel „just in time“ compiliert werden, also nur Quelltexte herumgereicht werden.
Reproduzierbare Builds sind in Scala schwierig, man denke alleine an die viele Build-Tools (ivy, gradle, maven, sbt,…)
Idee: nach etwa 10 der etwa 30 Schritte des Kompilierens den Baum des Programms in einem cleveren Binärformat speichern. Dieses Format ist ein bessere Kompromiss und von dort kann man leichter fertig-kompilieren.

REST on Akka: Connect to the world

Mathias Doenitz

Akka-http ist quasi Spray 2.0 oder Nachfolger für Spray.
Das sollte wegen der reactive Streams in Akka sein.
Verwende TCP-Flow-Control für „Backpressure“.

Bootstrapping the Scala.js Ecosystem

Haoyi Li

Scala wird nach Javascript statt JVM compiliert. Target ist eindeutig der Browser, weniger serverseitiges JS, wo man ja die JVM meist einsetzen kann.
Vorteil für Web-Applikationen: selbe Tag-Generierung, Validierung etc. auf Browser- und Serverseite. Eleganter als zwei Sprachen.
Einschränkungen: Libraries zu übertragen ist schwierig, da sie groß sind.
Keine Reflection auf scala.js verfügbar. Damit geht vieles nicht, aber es bleibt genug, was geht. Serialisierung eine Herausforderung, aber gelöst.
Testing riesige Herausforderung, gelöst halbwegs mit Teilmenge von scalatest.
Integer-Typen sind ein bisschen ein Gebastel, weil JS nur double kennt, was 53 bit entspricht. Long muss also mit zwei doubles nachgebildet werden.

Introduction to Lambda Calculus

Maciek Makowski

Sehr theoretischer Vortrag. Lambdacalculus wie Programmiersprache, Berechenbarkeitstheorie etc. Viele schöne Beweise möglich. Die theoretische Essenz der funktionalen Programmierung ist das. Stichworte: „Church Rosser Theorem“, „Programmierung mit Lambda-Kalkül“, „Zahlen als Lambda-Ausdrücke“ (church encoding), „y combinator“, „fixed point combinator“, „lambda cube“, „vierte Dimension für Subtypen“, ….
Sehr kleine Sprache, toll für Beweise, nicht für die Praxis brauchbar.

State of the Typelevel

Lars Hupel

Typelevel ist von Haskell inspiriert. Bibliotheken u.a. scalaz, shapeless, spire, scalaz-stream, monocle,….
Wir sollten anstreben, korrekte Programme zu schreiben und optimieren wenn nötig.
Die JVM-Integer-Typen sind nicht gut. Fließkommazahlen sind gut für numerische Mathematiker und in dem Bereich gebildete Wissenschaftler, die sich mit Fehlerfortpflanzung auskennen.
Natürlich behandeln wir Zahlen als Funktionen, z.B.
x=f(.) mit \bigwedge_{n \in \Bbb N: n>0} \frac{f(n)-1}{n} < x < \frac{f(n)+1}{n}
Gleichheit von Reelen Zahlen ist nicht in endlicher Zeit entscheidbar.
Was ist „Costate command coalgebra“? Monocle behandelt „lenses“ und ähnliche Dinge, die man aus Haskell kennt…
Gute binäre Serialisierungsformate sind in der JVM-Welt rar.
Wie geht man mit der Angst vor scalaZ und Monaden um?

Slick: Bringing Scala’s Powerful Features to Your Database Access

Rebecca Grenier

Slick ist eine Library, die SQL-Queries generiert und dann ausführt. Die konzeptionellen Schwächen von JPA werden geschickt umgangen.
Hat Treiber für die fünf großen DBs und einige kleinere. Aber für Oracle, DB2 und MS-SQL-Server nicht frei.
Innere und äußere Joins sind verfügbar und elegant zu schreiben. Slick kann mit dem Datenbank-Dictionary sogar Code generieren.

Upcoming in Slick 2.2

Jan Christopher Vogt

Monaden kommen auch hier vor. Zeit das endlich zu lernen. Ich werde einen Vortrag in der Ruby-on-Rails-Usergroup darüber halten, dann muss ich es lernen.
Monadische Sessions…
Sessions in Kombination mit Futures gibt lustige Albträume.
Wenigstens ist Slick theoretisch korrekt, im Gegensatz zu JPA.
Mehrere Statements kombinieren mit andThen oder for. Achtung, default verschiedene Sessions.
Threads sind teuer, Reactiveness ist wichtig. Futures und Threadpools, geht aber schief beim „blocking“.
JDBC kann nicht assynchron. Workaround oberhalb von JDBC scheint aber ausreichend zu sein und nur ein paar mehr Threads zu brauchen als die richtige Lösung, also verantwortbar.
Statisch gechecktes SQL?

No more Regular Expressions

Phil Wills

Ich mag Regex in Perl sehr. Warum also so etwas aufgeben?
Nun, man gibt es nicht wirklich auf, ändert nur die Schreibweise.
Die Schreibweise als String ist in Perl natürlich, in Scala ein Fremdkörper.
Daher typische programmatische Schreibweise angemessener, aber auch robuster bei Fehlern.
Verwende org-paraboiled2
Capture lieder positionell, tut aber viel weniger weh als bei klassischen regex.

Scala eXchange – Q&A Panel

Jon Pretty, Kingsley Davies, Lars Hupel, Martin Odersky, and Miles Sabin

Einige interessante Diskussionen…

Why Scala is Taking Over the Big Data World

Dean Wampler

Zitat (übersetzt): ‚“Hadoop“ ist das „EJB“ unserer Zeit.‘
MapReduce ist konzeptionell eigentlich schon funktionales Programmieren. Warum also Java und nicht Scala??
Stichwörter: „Scalding“, „Storm“, „Summing bird“, „Spark“.
Scala kann performanter als Python sein, das hier beliebt ist. Aber nicht überstürzt ablösen.

Case classes a la carte with shapeless, now!

Miles Sabin

Beispiel: Baum mit Rücklinks. Schwierig mit konsequenter Immutability. Shapeless hilft.

Reactive Programming with Algebra

André Van Delft

Algebra kann Spaß machen und nützlich für die Programmierung sein. Algebraische Interpretation eingeführt.
Webseite subscript-lang.org.
Algebra der kommunizierenden Prozesse. Sehr mächtig, auch für andere Gebiete anwendbar, etwa Betrieb von Bahnsystemen.
Jedes Programm, das Eingaben behandelt, ist auf eine Art ein Parser, also Ideen von yacc und bison interessant auch hier.

High Performance Linear Algebra in Scala

Sam Halliday

Lineare Algebra ist sehr gut gelöst, also sollte man das Rad nicht neu erfinden.
TL;D, Netflix und Breeze. Anwendungsbeispiel: Kalman Filter.
netlib hat Referenzimplementierung in Fortran. Wie bringt man das in die Scala-Welt?
Fortran mit C-Wrapper versehen, für JNI erreichbar. (cblas)
Fortran nach Java kompilieren. Ja.
Alternative Implementierung mit derselben Testsuite in C.
High-Performance geht nicht nur um Geschwindigkeit per se, sondern immer unter dem Aspekt der Korrektheit, Genauigkeit und Stabilität.
Hardware ist interessant: Die CPU-Hersteller reden mit dem netlib-Team.
Kann man GPU benutzen? Ja, aber Transfer der Daten schwierig.
FPGA? Vielleicht bald?
Oder sowas wie GPU, aber ohne echte Grafik und mit dem normalen RAM?

An invitation to functional programming

Rúnar Bjarnason

Referenzielle Transparenz, etwa die Kompatibilität mit dem Memoize-Pattern.
Pure Functions…
Parallelisierung
Verständlichkeit ist das ewige Versprechen. Warum wird es diesmal gehalten?
Funktionale Programmierung ist nicht gut für die „Schützengräben“ der reellen Aufgaben.
Aber gut, um aus den Schützengräben rauszukommen in vernünftigere Welten… So der Anspruch…

Building a Secure Distributed Social Web using Scala & Scala-JS

Henry Story

Spargl ist wie SQL für das „semantic web“.
Entwickelt mit Unterstützung von Oracle.
Wir können Relativität der Wahrheit haben, während wir die absolute Wahrheit aufrechterhalten. Der Vortrag war recht philosophisch.
Graphen können isomorph sein, aber verschieden hohes Vertrauen genießen, je nachdem, wo sie liegen.
Linked Data Protocol kommt ins Spiel
Wie verhindert man Spam und Missbrauch? WebID?
Hier geht es nicht um „Big Data“, sondern um massiv verteilte und parallele „small data“.

TableDiff – a library for showing the difference between the data in 2 tables

Sue Carter

Was ist für ein Diff die richtige Semantik?
Was will man sehen? Wie werden Zahlen und Zeichenketten in den Feldern verglichen?

Evolving Identifiers and Total Maps

Patrick Premont

Idee ganz kurz: eine Map, deren Get immer etwas zurückgibt. Durch geschickte Typ-Konzepte wird verhindert, dass ein Aufruf, der ins Leere greifen würde, überhaupt compiliert.
Interessante Idee, finde sie aber eher theoretisch nützlich.

Share Button

Chemnitzer Linuxtage

Es gibt diese Veranstaltung nun schon seit 16 Jahren und ich war noch nie da…
Aber es muss gut sein:

Chemnitzer Linuxtage 2015

Share Button

Scala Days in Berlin

English

Am 16., 17. und 18. Juni 2014 war ich bei der Konferenz „Scala Days“ in Berlin. Wie so oft bei diesen Veranstaltungen gibt es einen Haufen Vorträge, in diesem Fall bis auf die jeweilige „Keynote“ jeweils vier gleichzeitig. Das Veranstaltungslokal war wie bei der Devoxx in Antwerpen ein Kino, allerdings in diesem Fall schon lange umgewidmet für andere Zwecke, aber gute Projektoren gab es noch. Große Themen waren Fragen des Compilerbaus und wie man mit der richtigen funktionalen Perspektive aus der relativ einfachen Aufgabe, einen Interpreter zu schreiben, zu der schwierigen Aufgabe kommt, einen Compiler zu schreiben. Das hilft sicher, Sprachkonstrukte in Scala zu verstehen, aber die Idee wurde auch auf andere Felder angewendet, etwa um SQL-Queries zu kompilieren und zu optimieren oder um mit einem aus Compilercode gebauten Programm Quelltexte zu analysieren.

Ein anderes großes Thema waren „Streams“, die für Webservices nützlich sein sollen. Im Gegensatz zu klassischen Webservices, bei denen man den ganzen Request erstmal in Empfang nimmt, wurden auch Konzepte behandelt, um sehr große oder quasi unbegrenzte Requests zu verarbeiten. Dazu muss man diese natürlich schon verarbeiten, sobald eine gewisse nutzbare Datenmenge angekommen ist.

Ein kleines, aber interessantes Thema war die Entwicklung von Android-Apps mit Scala. Bekannt ist als Ansatz dafür natürlich Scaloid, aber hier wurde Macroid, ein alternativer Ansatz vorgestellt. Es sah vielversprechend aus, dass man mit weniger Code gute Android-Apps schreiben kann. Eine große Sorge ist, dass diese Scala-Apps den Speicher sprengen. Weil sie zusätzlich zu den vorinstallierten Java-Libraries noch Scala-Libraries brauchen, die etwa 5 MB groß sind, vergeht einem schnell der Appetit, außer man setzt gerootete Android-Devices voraus, auf denen die Scala-Libraries vorinstalliert sind. Das Thema verliert aber ein bißchen seinen Schrecken, weil der Build-Prozess einen Schritt enthält, in dem unnötige Klassen aussortiert werden, so dass am Ende nur das installiert wird, was man wirklich braucht. Wenn man so weit geht, Akka auf dem Mobiltelefon laufen zu lassen, wird das aber spannend, weil Akka viel Reflection und damit sehr viel fehleranfällige Konfiguration für diesen Optimierungsschritt benötigt.

Interessant war auch das Thema API-Design. Vieles war deckungsgleich mit Dingen, die ich bei einer API-Design-Schulung für Perl von Damian Conway vor ein paar Jahren gehört hatte, aber es gibt natürlich Scala-spezifische Themen, die auch interessant sind. Es ist erstaunlisch schwierig, Binärkompatibilität von Klassen zu erzielen und zwingt auch zu unschönen Kompromissen. Aber die gehören wohl auch in der Scala-Welt zum Leben.

Share Button

Besuch bei ScalaX

English

Gleich ein paar Wochen nach der Devoxx habe ich noch so eine Konferenz besucht, diesmal nur zwei Tage und unter dem Namen „Scala Exchange“ oder kurz #scalaX.
Es ging hauptsächlich um funktionale Programmierung und Architektur und das wiederum meistens recht „Scala-lastig“.
Die Vorträge waren um einiges anspruchsvoller als bei der Devoxx, aber das machte vielleicht auch den speziellen Reiz aus.

Interessante Vorträge waren unter anderem:

Share Button

neo4j

Da ich in dieser Woche einen Vortrag darüber gehört habe, schreibe ich mal einen kurzen Beitrag dazu.

Sicher haben viele schon von „NoSQL“-Datenbanken gehört.

In den guten alten Zeiten kam so etwa alle 10 Jahre ein neues Datenbank-Paradigma auf, bis die relationalen Datenbanken kamen. So etwa Mitte der 90er Jahre wäre nach diesem 10-Jahres-Rhytmus wieder etwas neues fällig gewesen und die objektorientierten Datenbanken waren ein recht offensichtlicher Kandidat. Letztlich blieben sie aber Nischenprodukte, ebenso wie einige andere Ideen, wie XML-Datenbanken.

Die relationalen Datenbanken und vor allem SQL waren zu gut oder zu gut etabliert und zu gut verstanden und statt objektorientierte Datenbanken einzusetzen verliebte man sich in verschiedene Technologien, um objektorientierte Software mit relationalen Datenbanken zu verbinden, zum Beispiel OR-Mapping wie Hibernate, JDO oder Eclipselink in der Java-Welt oder ActiveRecord in der Ruby-Welt. Diese Technologien, ihre Vor- und Nachteile und auch die grundsätzlichen konzeptionellen Fragen dazu sind sicher noch Stoff für viele Blog-Artikel in der Zukunft…

Letztlich scheint jetzt das Thema „NoSQL“-Datenbanken neben den weiterhin starken relationalen Datenbanken seinen Platz einzunehmen. Dabei steht „NoSQL“ angeblich für „not only SQL“. Letztlich sind es aber zwei Aspekte, an denen man schraubt. Die gängigen SQL-Datenbanken sind relational (oder zumindest unterstützen sie das relationale Modell) und transaktional. Das Thema Transaktionen ist sicher auch interessant genug für viele Blog-Beiträge und man kann problemlos allein darüber ein Buch von mehreren 100 Seiten schreiben, das nicht langweilig wird, wenn man sich mit verteilten Transaktionen und der Implementierung dieser Konzepte und der theoretischen und praktischen Zuverlässigkeit solcher Implementierungen gemessen an den Ansprüchen beschäftigt. Es gibt gegen Einwurf vieler großer Münzen mehrere gute Monographien dazu im Buchhandel.

Eine wichtige Motivation für die Entwicklung und Verbreitung der noSQL-Datenbanken war „Big Data“, also die Verarbeitung riesiger Datenmengen, die den Rahmen traditioneller relationaler transaktionaler Datenbanken wie Oracle, DB2, PostgreQL u.s.w. sprengen. Solche Fragestellungen findet man unter anderem bei Webapplikationen wie sie Google oder Facebook betreiben. Es gibt aber auch Fragestellungen mit Datenmengen, die noch gut für relationale Datenbanken handhabbar sind, die sich aber von ihrer Struktur nicht so gut für das relationale Modell eignen.

Nun muß eine SQL-Datenbank nicht transaktional sein. Zum Beispiel war es mySQL lange Zeit nicht und heute ist die für Data-Warhouses spezialisierte Datenbank Teradata unterstützt Transaktionen nur eingeschränkt.

NoSQL-Datenbanken weichen aber das relationale Prinzip auf und je nach Einzelfall eventuell außerdem die Transaktionalität. Es gibt verschiedene Arten von NoSQL-Datenbanken, zum Beispiel Key-Value-Stores wie Riak oder dokumentenorientierte Datenbanken wie MongoDB oder CouchDB, die sich eignen, wenn man eine gewisse Struktur der Daten kennt, aber die einzelnen Datensätze doch von Zeile zu Zeile (oder hier von Dokument zu Dokument) zu stark varieren oder zu stark strukturiert sind, um gut in eine normalisierte relationale Datenbank zu passen.

Graphendatenbanken speichern Daten in der Struktur eines Graphen. Man hat also Knoten mit gewissen Eigenschaften (Daten) und Verbindungen zwischen diesen Knoten mit gewissen Eigenschaften. Ein Beispiel ist eine IT-Landschaft, in der man Hardware, virtuelle Server, Basis-Software, Applikationen, Businessprozesse u.s.w. hat, zwischen denen verschiedene Arten von Abhängigkeiten bestehen können. Das war das Beispiel, das in dem Vortrag gebracht wurde. Das läßt sich eigentlich gut im relationalen Modell abbilden, ist aber in der Praxis sehr schwerfällig zu gebrauchen, weil die Queries um einen Teilgraphen zu laden, sehr schwerfällig sind und weil man letztlich durch fortgesetztes Verfolgen von Abhängigkeiten sehr schnell einen großen Teil des Systems im Speicher hat. Mit einer Graphendatenbank kann man diese Struktur allerdings ganz natürlich und direkt modellieren. neo4j ist zum Beispiel eine solche Graphendatenbank, die als Opensource-Software verfügbar ist. Sie enthält auch praktischerweise gleich noch Implementierungen einiger gängiger Graphenalgorithmen, die man direkt auf dem gespeicherten Graphen operieren lassen kann. So lassen sich gewisse Aufgabenstellungen sehr elegant lösen, die mit einer relationalen Datenbank zwar theoretisch korrekt, aber nicht praxistauglich umsetzbar sind, sobald der zu speichernde Graph eine gewisse Größe und Komplexität erreicht. Zur Aufweichung des Transaktionsprinzip ist noch zu sagen, daß neo4j transaktional ist.

Share Button

Devoxx

English

Vom 14. November bis 16. November 2012 (2012-11-14 bis 2012-11-16 im ISO-Datumsformat 😉 ) war ich auf der Devoxx-Konferenz in Antwerpen. Das war sehr interessant und ich hoffe, da im nächsten Jahr wieder teilzunehmen.

Eine kleine Hürde tat sich bereits bei der Anreise auf, weil die belgische Bahn ausgerechnet in dieser Woche von Streiks betroffen war. Dies ließ sich aber umschiffen, denn ich konnte von Düsseldorf nach Antwerpen und später wieder zurück nach Deutschland mit dem Fahrrad fahren.

Als Konferenzlokal hat man einen Teil eines Kinokomplexes verwendet und die Kinosäle waren mit Digitalprojektorenm großen Leinwänden und vor allem vielen bequemen Sitzen bestens für den Zweck geeignet.

Die Devoxx ist eigentlich eine Java-Konferenz, war aber sehr viel vielfältiger als das. Es gab interessante Vorträge über andere Programmiersprachen als Java in der JVM-Welt (Groovy, Scala, Clojure, Ceylon, …), über Softwarearchitektur, über Security, über Entwicklungsprozesse und vieles andere in dem Umfeld. Die meisten Vorträge waren sehr gut gemacht und haben in der Stunde einen kleinen Einblick in das Thema gegeben.

Gute Vorträge waren zum Beispiel

Vielleicht werde ich zu den einzelnen Themen irgendwann einmal noch mehr schreiben.

Share Button