Ort: Car2Go (Große Elbstraße 273)
Zeit: 22.08.2017 18:30 Uhr
Vortragsfolien: speakerdeck
Kategorie: Programmiersprachen
Beschreibung:
Der Vortrag teilte sich in 3 Abschnitte von verschiedenen Vortragenden:
Als Einleitung wurden die Teilnehmer auf eine Zeitreise von Kotlin mitgenommen: Von der "Geburt" Kotlins 2010, über den ersten Internetartikel über Kotlin 2011 und dem Schritt zu Open Source sowie der ersten Veröffentlichung 2012, dem Android Studio Support 2013, der zugehörigen Website 2014, zum Release 1.0 2016 bis zum Statement von Google 2017, Kotlin für Android offiziell zu unterstützen.
Der Mittelteil erläuterte das Sprachkonstrukt algebraischer Datentypen (ADT - Algebraic Data Type). Ein algebraischer Datentyp ist ein Typ, der aus verschiedenen weiteren repräsentiert wird. Ein einfaches Beispiel einer ADT, die man bspw. auch in Java kennt, sind Enums. Dies ist ein Typ, der sich aus verschiedenen konkreten Enum-Werten zusammensetzt. Sobald man in Java jedoch den einzelnen Werten unterschiedliche Attribute zuweisen möchte, ist dies in Java nicht sehr sprechend umsetzbar - mit Kotlin gibt es hier elegantere Lösungen:
Am Beispiel eines Verabeitungsstatus war dies gut veranschaulicht. Der Verarbeitungsstatus konnte die Werte "In Verarbeitung", "Erfolgreich" oder "Fehlerhaft" einnehmen. Falls man nun die Attribute "Fortschritt in Prozent" für den Status "In Verarbeitung" oder auch "Fehlermeldung" für den Status "Fehlerhaft" einführen möchte, ist dies über Attribute des Enums möglich. Allerdings wären die Attribute für jeden Status verfügbar, auch wenn bei der Definition bereits fest steht, dass sie nur für bestimmte Werte gültig sind. Für die weiteren Werte sind die Attribute sinnlos und verbleiben somit uninitialisiert.
In Kotlin lassen sich die Attribute sehr elegant über das Schlüsselwort der "data class" einem bestimmten Enumwert zuweisen. Durch das Sprach-Feature der "Smart Casts" und einem Pattern Matchings mittels der Syntax für "when", kann direkt auf die Attribute des Enumwertes zugegriffen werden. Aufgrund des Sprachkonstrukts der "sealed class" in Verbindung mit einem "return" in der Methode in der das Enum verwendet wird, stellt der Kompiler sicher, dass alle Werte des Enums in der Logik berücksichtigt wurden. Wird das Enum bspw. einmal erweitert, zeigt der Kompiler so bereits alle Stellen auf, in der der neue Enum-Wert noch berücksichtigt werden muss (ein konkreteres Beispiel befindet sich im verlinkten Foliensatz "Kotlin and ADT")
Danach sprachen drei Entwickler, die Kotlin produktiv in ihren jeweiligen Projekten einsetzen, über ihre bisherigen Erfahrungen. Alle empfinden den Schritt zu Kotlin - direkt von Anfang an oder aus einer Migration aus Java heraus - als die richtige Entscheidung. Die klare Prägnanz der Sprache ließe wieder insbesondere mehr Spaß an Code Reviews. Außerdem gäbe es für viele Problemstellungen die passenden Annotationen, die von Kotlin bereit gestellt würden. Die neuen Sprachmöglichkeiten (hier wurde insbesondere auf "late init" verwiesen), würden neue Architekturmöglichkeiten. erlauben.
Allerdings wurden auch folgende Punkte herausgestellt, an denen die Macher von Kotlin (Jetbrains) noch etwas arbeiten müssten: Die Build-Zeiten scheinen länger zu sein, als dies bei Java der Fall ist. Man scheint als Entwickler teilweise in Schwierigkeiten zu geraten, die mit dem Kotlin Annotation Processor (kapt) zusammenhängen. Man müsse sich außerdem bewusst sein, dass die Interoperabilität zwischen Kotlin und Java nicht 100 prozentig abgebildet werden konnte: Beispielsweise gibt es in Kotlin zwar keine NullPointerExceptions mehr (sofern man dies dem Compiler nicht explizit erlaubt), aber insbesondere durch den Einsatz von late init könne man auf UninitializedPropertyAccessExceptions stoßen.
Aus der Diskussion mit den Teilnehmern heraus ergab sich außerdem ein eher mäßiges Bild für den Transpiler, der automatisiert Java-Code in Kotlin übersetzen kann. Die generierten Klassen seien zwar funktionsfähig aber in den meisten Fällen schlecht lesbar, so dass man im Nachhinein nochmals manuell Hand anlegen müsse. Dadurch wird eine Java-Klasse in vielen Fällen von Anfang an manuell nach Kotlin übersetzt. Eine weitere praktikable Möglichkeit scheint es zu sein, eine Kotlin-Klasse mit den zugehörigen Methodenrümpfen anzulegen, stückchenweise (pro Methode oder auch nur einzelne Zeilen) den Code transpilieren zu lassen und diesen Teil manuell nachzubearbeiten.
Die Möglichkeit Kotlin in JavaScript zu übersezten sei ebenfalls noch sehr verbesserungswürdig.
Für Interessierte meines letzten Abschnitts könnten folgende Seiten aus der Kotlin-Dokumentation hlifreich sein, auf die ich beim Schreiben dieses Artikels aufmerksam geworden bin: Null-Safety, Interoperabilität
Allen Kotlin-Interessierten sei außerdem der zugehörige Slack-Channel empfohlen.