Warum Kotlin großartig ist, Sie aber trotzdem bei Java bleiben werden

Unabhängig davon, welcher Gruppe Sie angehören, gibt es einen Grund, warum Sie bei Java. Und ich mache Ihnen keine Vorwürfe. Sie hat das wohl am weitesten entwickelte, universellste und vollständigste Ökosystem der gesamten Welt. Unternehmen Welt. Die Sprache verfügt über einen gut zugeschnittenen Satz von Fähigkeiten, irgendwo in der richtigen Zone zwischen zu viel und zu wenig. Und neue Funktionen werden langsam, aber stetig hinzugefügt, so dass sie mit den neuesten Trends in der Welt der Programmierung Schritt halten kann.

Kennen Sie Lombok aber? Wenn nicht, empfehle ich Ihnen, es auszuprobieren. Wenn es Ihnen gefällt, dann habe ich etwas für Sie, das Sie unbedingt ausprobieren sollten. Eine ganz neue Sprache, die durch ihre Eigenschaften Lombok überflüssig macht. Sie heißt Kotlin.

Kotlin? Sie meinen die Android-Sprache?

Kotlin auf Android wurde von Google selbst so weit abgesegnet, dass es die de-facto Sprache der Wahl für die Plattform wurde. Darauf werde ich mich in diesem Artikel nicht konzentrieren, aber Android ist tatsächlich der Ort, an dem ich Kotlin zum ersten Mal getroffen habe.

Mein Arbeitskollege entwickelte gerade eine App für ein damals aktuelles Projektauf eigene Faust. Die Fristen rückten jedoch schnell näher, und so wurde ich beauftragt, ihm bei der Einhaltung dieser Fristen zu helfen. Ich versetze mich jetzt in die Zeit zurück. Aaaund... Igitt! Warum benutzt er so eine komische Sprache, die sich anhört wie ein Ketchup-Marke!? Es sieht furchtbar aus!

Warum steht vor jeder Funktion "fun"? Als ob ich nicht schon wüsste, was das ist. Außerdem habe ich bereits Spaß mit Java wie auch immer. Und wo ist der Rückgabetyp? Am Ende? Sind Sie verrückt? Was ist das? Weisen Sie einer Funktion etwas zu? Das macht doch keinen Sinn! Es sieht einfach aus wie Java mit zusätzlichen Schritten! Moment, wo ist die Klasse, zu der diese Methode gehört? Wo hast du sie versteckt, du Ketchup-klingender, Java nachahmende Ausrede einer Programmiersprache? Oh nein. Oh nein, das hast du nicht. IST DAS EINE GLOBALE FUNKTION? Das war's, ich bin fertig, ich rufe die Polizei.

Spoiler-Alarm: Ich habe die Strafverfolgungsbehörden nicht angerufen. Ob es mir nun gefällt oder nicht, ich musste meine Java-zentrierte Denkweise anpassen, um mich auf eine andere Sprache einzustellen. Aber so schlimm wird es doch nicht sein, oder? Es ist immer noch eine JVM-Sprache, sicherlich nur eine andere Java. Vielleicht sogar mit ein paar coolen Zusatzfunktionen? Widerstrebend begann ich mit der Arbeit an dem Projekt.

Java mit zusätzlichen Schritten

Wenn Java so großartig ist, warum gibt es dann kein Java 2? Scherz beiseite, das habe ich mir auch gedacht. Ich werde einfach so tun, als wäre Kotlin Java 2. Neue Syntax und so, aber ich muss nur genug davon lernen, um das Projekt zu beenden. Junge, Junge, ich habe mich geirrt.

Nachdem ich es nur ein oder zwei Tage lang ausprobiert hatte, wurde mir schnell klar, dass sowohl Kotlin als auch Java sind nicht sehr elastisch. Der Versuch, sie zueinander zu biegen, endet unweigerlich damit, dass einer von ihnen in der Mitte zerbricht. Es wurde offensichtlich, dass Kotlin eine Sache für sich ist, und die Tatsache, dass es auf einer JVM funktioniert, bedeutet aus der Sicht eines Programmierers fast genau nichts. (Nebenbei bemerkt, es kann auch nach JavaScriptoder zu einer nativen Binärdatei kompiliert werden).

Dann Plan B. Machen Sie sich mit der Sprache vertraut. Wenn man die Dokumentation zum ersten Mal liest, läuft einem erfahrenen Java-Programmierer ein Schauer über den Rücken. Zum Beispiel:
- die bereits erwähnte oberste Ebene bzw. der globale Kontext
- die am Ende angegebenen Typen der Parameter und Funktionsrückgaben

fun sum(a: Int, b: Int): Int {
   return a + b
}

Funktionskörper kann ein Ausdruck sein (mit Gleichheitszeichen)

 fun sum(a: Int, b: Int) = a + b

if-Anweisung kann ein Ergebnis liefern

 val y = if (x == 1) {
 "1"
 } else if (x == 2) {
 "zwei"
 } else {
 "andere"
 }

Ok, ich muss mich nur daran gewöhnen. Nur eine andere Syntax. Was haben Sie sonst noch zu bieten, Mister Kotlin?

 wert?.methode() // ausführen, wenn nicht null

Oh ok, loswerden wenn (Wert == Null)einen Punkt für Sie. Was haben Sie noch?

fun check(list: List, alternative: Boolean) = when {
 list ist LinkedList -> print("linked")
 alternativ -> print("alternativ")
 list.size > 50 -> print("groß")
 else -> print("andere")
 }

Hmm, nett, könnte praktisch sein, um zu vermeiden, wenn sonst blockiert, scheint immer noch wie ein Gimmick obwohl.

 object SingularObject: Counter() {
 var a = 14
 fun test() = if (a > 10) "mehr" else "weniger"
 }

Ok, das sieht tatsächlich nützlich aus, das gefällt mir! Andererseits kann ich auch in Java ein Singleton erstellen. Vielleicht wird es nicht so elegant sein, aber es ist nichts wirklich Neues. Haben Sie irgendwelche Asse im Ärmel? Echte Knüller?

 var s: String = null // lässt sich nicht kompilieren, Nicht-Null-Typ

Moment... was?

Der milliardenschwere Irrtum

Stellen Sie sich eine Codebasis vor, in der Sie sich keine Gedanken über Nullsicherheit machen müssen. Stellen Sie sich vor, dass Sie einfach davon ausgehen können, dass jeder Verweis tatsächlich etwas Sinnvolles enthält. Stellen Sie sich vor, Sie wären sicher, dass jedes Null-Problem im Voraus gelöst wird.
Stellen Sie sich nichts mehr vor. Alle Referenzen in Kotlin sind standardmäßig nicht löschbar. Wenn Sie sie nullbar machen wollen, müssen Sie Bewusst diese Entscheidung zu treffen, und ausdrücklich es in der Code:

 var s: String? = null

Ich verstehe, dass Sie zu diesem Zeitpunkt skeptisch gegenüber der ganzen Idee sein könnten. Sie sind an nullbare Referenzen gewöhnt. Sie haben sie beim Programmieren im Hinterkopf. Sie haben gelernt, wo Sie vorsichtig sein müssen. Das sind genau meine Gedanken. Ich komme von Javafühlte es sich anfangs tatsächlich seltsam an. Was soll das bringen? Es wird nicht auf magische Weise alle damit verbundenen Probleme verschwinden lassen. Ich werde einfach überall "?" hinzufügen müssen, das klingt nach einer lästigen Pflicht.

Aber ich habe beschlossen, tief in die Sprache einzutauchen, nicht wahr? Wie Sie wollen, Mister Kotlin. Ich begann, mich zu bemühen, so viele nullbare Variablen, Felder und Parameter wie möglich zu eliminieren. Schritt für Schritt lernte ich, Sprachfunktionen zu verwenden, die es einfacher machten, nullbare Referenzen zu eliminieren, z. B. den Safe Call "?."-Operator, den Elvis "?:"-Operator, delegierte Eigenschaften, die "let"-Methode und mehr.

Mit der Zeit gelang es mir, einige Klassen dazu zu bringen, nur Felder und Methodenparameter zu enthalten, die nicht null sind. Im Grunde wusste ich, dass ich, wenn eine Klasse erfolgreich instanziiert wurde, die Nullbarkeit in Methodenkörpern fast vergessen konnte. Das war ein Glücksfall. Mit der Zeit wusste ich dies immer mehr zu schätzen. Letztendlich habe ich es aber nicht als Killer-Feature betrachtet, Java fühlte sich immer noch wie zu Hause an. Bis...

Das Comeback

Das Projekt neigte sich dem Ende zu. Ich lernte Kotlin immer besser kennen, und mit diesem Wissen wurde der Code immer aufgeräumter, lesbarer und prägnanter. Man konnte die Verbesserungen mit bloßem Auge in der Commit-Historie sehen. Doch nun ist es endlich soweit. Mit unerwartet schönen Erinnerungen an die neue Sprache war es an der Zeit, sich zu verabschieden und in die süße Komfortzone von Kotlin zurückzukehren. Java. Das dachte ich zumindest.

Kennen Sie das Gefühl, wenn Sie etwas in dem Moment zu schätzen beginnen, in dem es nicht mehr da ist? Wenn man erst merkt, wie sehr man sich auf etwas verlässt, wenn man es nicht mehr gebrauchen kann? Das war das beste Beispiel für dieses Gefühl, das ich wahrscheinlich jemals in meinem Leben erlebt habe.

Als ich wieder anfing, den Code in JavaIch war fast erschrocken über das Fehlen einiger Funktionen. Es war, als ob mein Gehirn unbewusst Kotlin-Funktionen fälschlicherweise in Java nachrüstete. Ich erlebte Situationen, in denen ich tatsächlich etwas zu implementieren begann, nur um festzustellen, dass es in dieser Sprache nicht funktionieren würde. Im besten Fall könnte ich es wie Kotlin schreiben, aber es wäre unhandlich, unlesbar und/oder würde zu viel Boilerplate erfordern.

Die Nullsicherheit war natürlich die Funktion, die ich am meisten vermisst habe. Aber ich war überrascht, wie viele kleinere Dinge für mich selbstverständlich wurden: benannte Parameter, Eigenschaften statt Getter und Setter, "==" als Gleichheitszeichen und "===" als referenzielle Gleichheit, qualifiziertes "this", Erweiterungsfunktionen, implizite singuläre Lambda-Parameter, "_" für nicht verwendete Lambda-Parameter, Datenklassen, Scope-Funktionen, andere Kotlin-Stdlib-Funktionen, Operatoren und mehr. Und die Art und Weise, wie das alles schön zusammenpasst. Im Vergleich dazu fühlte sich Java... primitiv an.

Ich habe mich so schlecht gefühlt, dass ich überlegt habe, ganz auf Kotlin umzusteigen. Theoretisch ist Kotlin vollständig interoperabel mit Java, man kann einfach Kotlin-Unterstützung zu einem bestehenden Projekt hinzufügen und neue Klassen schreiben. Die Kotlin-Seite weiß, wie man mit Java "spricht", und die Java-Seite weiß nicht einmal, dass sie mit einer anderen Sprache "spricht". Und nach der Kompilierung in Bytecode macht es für die JVM eigentlich keinen Unterschied mehr.

Realitätsprüfung

Worauf warten Sie also noch? Wenn die Sprache so gut ist, wie Sie sagen, dann verwenden Sie sie einfach! Vielleicht nicht in bestehenden Projekten, aber ich weiß, dass sie interoperabel sein sollte, aber zwei verschiedene Sprachen auf diese Weise zu mischen, klingt hässlich.

Ok, also für neue Module - Kotlin ist es. Oder doch nicht? Sie arbeiten in einem Team. Sie müssen sie konsultieren und sie von der Großartigkeit dieser neuen Sprache überzeugen. Was ist? Sie mögen sie nicht? Klingt so, als wollten sie sich einfach nicht die Mühe machen, sie zu lernen. Sie können es ihnen aber nicht verübeln, denn Sie waren anfangs auch skeptisch.

Der Projektleiter! Ja! Er wird sicher verstehen, welchen großen Wert Kotlin für unser Team hat. Oh, wie großartig das sein wird!
-Nein
-Warte, warum?
-Die Mannschaft weiß es nicht.
-Sie werden es lernen!
-sie wollen nicht lernen.
-Du kannst sie machen!
-sie brauchen nicht zu lernen.
-Ich meine, das ist wahr, aber denken Sie an die Möglichkeiten!
-Ja, wie wäre es, wenn Sie zuerst über die Probleme nachdenken.

Die Legende besagt, dass es ein Projekt gibt. Ein Projekt, das groß und komplex ist, aber in jedem Teil schön geschrieben. Ein Projekt, bei dem sich alle Entwickler über die verwendeten Lösungen einig sind. Wo neue Funktionen einfach aus den Tastaturen der Programmierer fließen. Wo Fehler selten und leicht zu beheben sind.

Haben Sie so ein Projekt schon einmal gesehen? Nein, habe ich nicht. Einige waren nahe dran, aber die meisten von ihnen sind ein großes Legacy-Code-Durcheinander. Und wenn sie es nicht sind, werden sie es wahrscheinlich irgendwann in der Zukunft werden. Stellen Sie sich nun vor, Sie würden eine weitere Sprache in den Mix werfen. Das eröffnet neue Möglichkeiten, Fehler zu machen. Es verlangt von den Entwicklern, dass sie wissen, was sie tun. Das ist, gelinde gesagt, ein Risiko.

Bedenken Sie auch die Rotation der Entwickler. Leute kommen und gehen. Werden Sie jeden neuen Entwickler dazu bringen, eine völlig neue Sprache zu lernen? Nein, das ist kontraproduktiv. Werden Sie überhaupt Kotlin-Entwickler einstellen? Viel Glück dabei, es ist schon schwer genug, einen guten Java-Entwickler zu finden.

Die Menschen haben es versucht. Ich muss sagen, dass ich mit den meisten Behauptungen in diesem Artikel nicht einverstanden bin. Es gibt einige berechtigte Kritikpunkte, aber ich denke, sie haben Kotlin nicht genug benutzt, um "den Kotlin-Weg" wirklich zu verstehen. Viele Kommentatoren unter diesem Artikel scheinen ähnlich zu denken.

Das spielt aber keine Rolle. Ich wette, das würde auch bei Ihrem Projekt passieren. "Ausprobiert, hat nicht gefallen". Sie werden sie nicht dazu bringen, mehr Zeit darauf zu verwenden. Sie werden sie nicht zwingen, es noch einmal zu versuchen. Sie werden sie nicht dazu bringen, der Sache eine weitere Chance zu geben. Und vom praktischen Standpunkt aus betrachtet, könnten sie Recht haben. Java ist einfach so populär, dass die Verwendung von etwas anderem auf der JVM überflüssig erscheint.

Warum dann dieser Artikel?

Sie haben gerade eine beträchtliche Zeit damit verbracht, einen Artikel zu schreiben, der anscheinend keinen Sinn hat. Warum sollte ich versuchen, eine Sprache zu lernen, wenn Sie sagen, dass es sowieso sinnlos ist?

Nun, ich denke nicht, dass es sinnlos ist. Ich denke immer noch, dass Kotlin großartig ist. Ich möchte es immer noch benutzen (und tue es auch für meine privaten Projekte). Wenn ich könnte, würde ich einfach zu Kotlin wechseln und die Einschränkungen von Java vergessen. Aber die aktuelle Realität sagt, dass ich das nicht kann. Und ich möchte versuchen, das zu ändern.

Meine Absicht für Sie, lieber Leser, ist es, zumindest die Möglichkeit zu erwägen, aus der gemütlichen Java-Komfortzone herauszukommen. Denn vielleicht, nur vielleicht, werden Sie Kotlin genauso lieben wie ich. Und wenn Sie das tun, dann ist ein Kotlin-kundiger Entwickler mehr auf der Markt.

Lesen Sie mehr:

Die beste Art von Projekten für Java

3 Gemeinsame Herausforderungen bei der Software-Produktentwicklung für Startups

Der richtige Weg, um Top-Java-Entwickler zu finden