WEBVTT 00:00.000 --> 00:18.800 So, jawohl, nach der kurzen Kaffeepause geht es jetzt mit dem spannenden Thema ganz neu, für mich auch war es zumindest Kotlin, the next generation Java, das uns Herr Burg von Novatec jetzt näher bringen wird. Dankeschön. 00:18.800 --> 00:29.220 Hallo auch von meiner Seite. Ich freue mich hier zu sein und über eins meiner Lieblingsthemen zu sprechen und das ist die Sprache Kotlin. 00:32.460 --> 00:37.400 Mein Name ist Philipp Burg, wie schon gerade erwähnt von der Novatec Consulting GmbH. 00:37.400 --> 00:43.500 und ich bin selber Softwareentwickler im Java, meistens im Java-Umfeld, 00:43.920 --> 00:50.840 von damals Swing über JEE, EJB, JSF und mittlerweile im Android gelandet. 00:52.020 --> 00:57.020 Ich habe aber auch Sprachen gesehen wie Objective-C, wenn man iOS-Apps schreiben möchte, 00:57.020 --> 00:58.540 oder mittlerweile Swift. 00:58.540 --> 01:08.980 Ich möchte gleich mal mit ein paar Fakten anfangen über Kotlin. 01:12.320 --> 01:19.180 Das erste ist, es ist wie eigentlich Java, es ist eine objektorientierte Sprache und sie ist statisch typisiert, 01:19.480 --> 01:22.300 also nichts Neues für den Java-Entwickler. 01:22.300 --> 01:25.380 wenn man Kotlin-Klassen 01:25.380 --> 01:27.060 kompiliert, kommt 01:27.060 --> 01:28.700 Java Bytecode raus, also 01:28.700 --> 01:31.500 wenn man den Bildordner 01:31.500 --> 01:33.620 nachschaut, findet man diese Class-Files 01:33.620 --> 01:33.960 wieder 01:33.960 --> 01:37.780 und es ist kompatibel 01:37.780 --> 01:39.420 bis jetzt 01:39.420 --> 01:41.640 habe ich noch keine Java-Library gefunden 01:41.640 --> 01:43.440 die es irgendwie nicht kompatibel ist, die ich nicht 01:43.440 --> 01:45.760 aufrufen kann, ich weiß es nicht wie es aussieht 01:45.760 --> 01:47.500 wenn man solche Libraries verwendet 01:47.500 --> 01:49.420 die so ein bisschen den Bytecode manipulieren 01:49.420 --> 01:51.760 sowas wie PowerMock oder so weiter 01:51.760 --> 01:54.840 Aber bis jetzt habe ich selber auch noch keine Probleme gefunden. 01:55.480 --> 02:01.400 Und vielleicht auch noch ein Fakt, es ist nicht nur auf Android begrenzt. 02:02.260 --> 02:10.180 Warum habe ich das hier aufgeschrieben, ist, die Community von Android hypt gerade so ein bisschen das Thema Kotlin. 02:10.860 --> 02:19.080 Für mich stellt sich der Grund einfach da heraus, die Android-Entwicklung sprachtechnisch ist auf Java 5 oder 6 stehen geblieben. 02:19.080 --> 02:25.400 und die ganzen schönen Java 8 Features findet man eigentlich nicht in der klassischen Android-Entwicklung wieder. 02:28.680 --> 02:44.860 Für den Start möchte ich eigentlich ein klassisches Java-Klasse mal nehmen 02:44.860 --> 02:47.200 und sie mal ein bisschen transformieren in Kotlin-Code. 02:47.200 --> 02:52.540 und dann schauen wir uns mal an, wie sich das verhält mit Kotlin-Code. 02:53.080 --> 02:57.160 Ich habe so ein bisschen den Satz unten hin geschrieben, 02:57.880 --> 03:01.880 ich möchte ein paar nicht so tolle Zeichen loswerden, 03:02.500 --> 03:09.040 also vielleicht am Anfang Semikolon, also jeder tut heutzutage sein Code formatieren 03:09.040 --> 03:12.220 und was brauche ich das Semikolon-IDEs zu tun? 03:12.300 --> 03:14.340 Klassischerweise das immer gleich hinten her generieren, 03:14.340 --> 03:17.920 Also von der Kotlin-Sprache her braucht man es einfach nicht. 03:18.080 --> 03:18.920 Lass es einfach weg. 03:19.660 --> 03:21.480 Braucht man weniger lesen, weniger schreiben. 03:21.740 --> 03:22.580 Schon mal was gewonnen. 03:24.960 --> 03:30.340 Der nächste Punkt ist, das Signalwort new bei der Objekterzeugung. 03:31.700 --> 03:35.180 Ich sage auch, man schreibt es immer hin, aber eigentlich hat es keinen Nutzen. 03:36.080 --> 03:38.020 Kann der Compiler eigentlich auch selber erkennen. 03:39.080 --> 03:40.660 Wenn wir dann so ein bisschen weiter gehen. 03:40.660 --> 03:44.540 so ein langes Wort wie Extents 03:44.540 --> 03:46.600 kürzt man in Kotlin einfach mit so einem 03:46.600 --> 03:47.680 Doppelpunkt ab 03:47.680 --> 03:49.840 das ist auch damit getan 03:49.840 --> 03:52.460 und 03:52.460 --> 03:56.000 in Java 03:56.000 --> 03:58.720 ich behaupte mal die Sichtbarkeit 03:58.720 --> 03:59.820 von Objekten 03:59.820 --> 04:02.400 von Variablen 04:02.400 --> 04:04.680 und von Klassen ist das an erster Stelle 04:04.680 --> 04:06.660 Public, dann kommt irgendwann so Private 04:06.660 --> 04:08.020 und dann kann man sich jetzt drum streiten 04:08.020 --> 04:10.360 ob Package Protected kommt oder Protected 04:10.840 --> 04:13.520 aber das Häufigste, was man verwendet, ist Public. 04:14.140 --> 04:16.220 In Kottling hat man sich darüber auch Gedanken gemacht und gesagt, 04:16.600 --> 04:19.380 na gut, wenn Public das meistverwendete ist, 04:19.420 --> 04:22.120 dann ist das auch mal der Default einfach mal von der Sichtbarkeit her. 04:22.120 --> 04:25.120 Also mal weniger Code zum Lesen. 04:30.080 --> 04:31.900 Wenn wir jetzt mal so weiterschauen. 04:36.980 --> 04:38.780 Das Signalwort Void. 04:38.780 --> 04:44.040 damit ich möchte signalisieren, dass ich nichts zurückgebe. 04:45.080 --> 04:47.780 Warum muss ich dafür ein Wort nehmen, um das zu signalisieren? 04:48.120 --> 04:49.980 Ich schreibe doch einfach mal nichts hin, 04:50.600 --> 04:51.980 und damit ist es einfach schon getan. 04:54.880 --> 04:56.260 Gehen wir nochmal ein bisschen weiter, 04:56.340 --> 04:58.000 was können wir denn noch so alles rauswerfen? 05:03.020 --> 05:05.360 Wir werfen nichts raus, wir lernen, 05:05.360 --> 05:07.420 der Return-Type wird 05:07.420 --> 05:09.920 hinter der Methode angegeben. 05:10.980 --> 05:12.100 Wenn ich Code lese, 05:12.620 --> 05:14.040 fange ich vorne an zu lesen, 05:14.200 --> 05:15.720 interessiert mich als erstes als Entwickler 05:15.720 --> 05:17.540 an der Methode, was sie returnt 05:17.540 --> 05:18.520 oder was sie eigentlich 05:18.520 --> 05:21.580 für einen Namen hat und was sie eigentlich 05:21.580 --> 05:23.120 tun möchte, tun soll. 05:24.380 --> 05:25.040 Dann sage ich, 05:25.560 --> 05:27.460 der Return-Type interessiert mich erstmal nicht, 05:27.600 --> 05:29.900 also erstmal der Methodenname. 05:31.680 --> 05:33.040 Gehen wir noch ein bisschen weiter. 05:33.700 --> 05:35.200 Was man hier oben auch schön sieht, 05:35.360 --> 05:45.120 ist eine Retundanz von dem Klassenname, einmal in der Deklaration und einmal in der Initialisierung. 05:45.480 --> 05:46.680 Man muss das wiederholen. 05:48.500 --> 05:51.860 Warum muss ich immer alles wiederholen in der Sprache Java? 05:52.740 --> 05:54.180 Schmeißen wir das doch einfach mal weg. 05:54.720 --> 05:58.880 Was der Signalwort Val bedeutet, werde ich noch später zeigen. 05:59.940 --> 06:01.560 Hat auch eine Funktion. 06:01.560 --> 06:06.240 So, gehen wir nochmal weiter. 06:10.000 --> 06:11.080 Hakt ein bisschen. 06:17.240 --> 06:21.440 Wir drehen den variablen Namen und den variablen Typ um 06:21.440 --> 06:23.960 und müssen leider noch einen Doppelpunkt dazwischen schreiben. 06:24.940 --> 06:26.780 Okay, warum Doppelpunkt? 06:27.060 --> 06:28.780 Das müssen wir jetzt auch nicht unbedingt haben. 06:28.780 --> 06:31.940 kommen wir dann zum nächsten Schritt, 06:32.060 --> 06:34.280 größeren Schritt. Jede Java-Klasse 06:34.280 --> 06:36.000 hat mindestens einen 06:36.000 --> 06:36.800 Konstruktor. 06:37.740 --> 06:39.840 Manchmal sieht man ihn nicht, weil der Default-Konstruktor 06:39.840 --> 06:41.080 manchmal selber generiert wird. 06:41.840 --> 06:43.840 Aber das ist eine Tatsache, dass jede 06:43.840 --> 06:45.460 Java-Klasse einen Konstruktor hat. 06:46.620 --> 06:48.040 Diese Tatsache hat sich 06:48.040 --> 06:48.400 Kotlin 06:48.400 --> 06:51.660 hergenommen und hat gesagt, 06:51.820 --> 06:53.560 okay, wenn es so ist, 06:54.200 --> 06:55.460 dann deklariere ich 06:55.460 --> 06:57.360 den ersten Konstruktor 06:57.360 --> 06:58.040 Immer. 06:59.200 --> 07:00.840 Nach dem Klassenname. 07:02.120 --> 07:08.420 Und ich deklariere, welchen Superkonstruktor ich gleich noch aufrufen möchte. 07:10.260 --> 07:14.740 Also all das, was ich hier unten in vielen Zeilen habe, einfach mal hier drin. 07:14.740 --> 07:18.280 Und ja, man kann auch in Kotlin mehr als einen Konstruktor haben. 07:18.600 --> 07:20.460 Den deklariert man aber dann innerhalb der Klasse wieder. 07:20.460 --> 07:23.840 jetzt noch 07:23.840 --> 07:27.100 eine Feinheit, um mal lieben Kotlin-Code 07:27.100 --> 07:27.860 herzustellen. 07:28.860 --> 07:31.100 Fun ist nicht für Spaß, 07:31.520 --> 07:32.720 sondern steht für Function. 07:34.360 --> 07:35.280 Ich finde es auch ein bisschen 07:35.280 --> 07:37.700 blöd, 07:38.260 --> 07:40.340 weil jetzt muss man schon wieder mehr schreiben. 07:40.340 --> 07:42.260 Warum will ich denn wieder mehr schreiben? 07:42.400 --> 07:43.560 Aber es ist jetzt so eine Tatsache, 07:43.920 --> 07:44.980 ein Kotlin einfach. 07:46.280 --> 07:48.480 Jetzt haben wir das erste Mal mal lieben Kotlin-Code. 07:50.460 --> 07:53.600 Kotlin hat noch so ein bisschen syntaktischen Zucker. 07:54.180 --> 07:57.300 Bei einzeiligen Methoden, die wir hier beide haben, 07:58.000 --> 08:01.640 ist es erlaubt, diese Methoden innerhalb einer Zeile zu schreiben. 08:07.100 --> 08:08.580 Was returnt die Methode? 08:09.260 --> 08:14.640 Die Methode returnt das, was die aufgerufenen Code zurückgeben. 08:14.880 --> 08:17.380 Also ich muss es nicht wiederholen, was sie returnt, 08:17.380 --> 08:20.800 sondern der Compiler weiß, okay, get gibt mir ein String, 08:20.920 --> 08:23.580 deswegen ist das der Return-Time auch wieder ein String. 08:23.700 --> 08:26.480 Muss ich nicht alles nochmal neu beschreiben und neu beschreiben, 08:27.000 --> 08:33.300 sondern die Sprache oder der Compiler erkennt es selber, was es zu bedeuten hat. 08:34.000 --> 08:36.280 Ich habe hier mal ein paar Zahlenbeispiele aufgeschrieben. 08:37.900 --> 08:40.700 Also man kommt von 18 Zeilen Java-Code in diesem Beispiel, 08:41.600 --> 08:45.340 von 16 Zeilen Java-Code auf 8 Zeilen Kotlin-Code 08:45.340 --> 08:47.040 und die Zeichen sieht man hier daneben. 08:47.380 --> 08:49.700 was die Zahlen eigentlich nur zeigen sollen, 08:49.840 --> 08:51.760 ist, was mit dem Code passiert, 08:52.400 --> 08:54.360 wenn man von Java auf Kotlin wechselt. 08:54.760 --> 08:56.260 Und was passiert mit dem Code? 08:56.340 --> 08:57.480 Er wird wesentlich kompakter, 08:58.280 --> 08:58.920 was man macht. 09:00.560 --> 09:02.060 So, jetzt haben wir mal gelernt, 09:02.160 --> 09:03.380 wie so ein bisschen Kotlin-Code aussieht, 09:03.440 --> 09:04.360 wie die Syntax ist. 09:05.060 --> 09:05.900 Und jetzt kommen wir eigentlich 09:05.900 --> 09:08.240 zu den richtig spannenden Themen in meinen Augen. 09:11.640 --> 09:12.360 Ich hoffe, 09:12.360 --> 09:14.580 ihr schreibt auch immer Unit-Tests fleißig. 09:14.580 --> 09:17.940 und warum sollte ich 09:17.940 --> 09:18.980 Getter und Setter 09:18.980 --> 09:20.420 testen? 09:21.660 --> 09:23.800 Die IDE's generieren wir die automatisch, 09:24.140 --> 09:25.560 viele Entwickler ignorieren die, 09:26.040 --> 09:27.700 weil sie haben eh nur immer, geben wir die 09:27.700 --> 09:29.780 Properties zurück, eigentlich mehr 09:29.780 --> 09:31.200 oder weniger Boilerplate-Code. 09:31.860 --> 09:33.780 Und wenn man der Klassiker 09:33.780 --> 09:35.520 ist immer, man tut die Variable 09:35.520 --> 09:37.560 umbenennen, aber die Getter und Setter nicht, dann heißt 09:37.560 --> 09:39.480 der Getter und Setter anders als wieder 09:39.480 --> 09:41.040 die Variable. Also 09:41.040 --> 09:41.740 immer 09:41.740 --> 09:44.840 Fehler, die man einbauen kann, 09:44.900 --> 09:46.140 die man eigentlich nicht haben möchte. 09:47.880 --> 09:48.860 Deswegen komme ich jetzt nochmal 09:48.860 --> 09:49.980 zurück auf den 09:49.980 --> 09:52.400 Begriff war und weil. 09:55.980 --> 09:57.180 In Kotlin 09:57.180 --> 09:59.020 bedeutet war, 09:59.740 --> 10:01.200 dass ich sie 10:01.200 --> 10:03.880 setzen und bekommen kann, 10:04.040 --> 10:05.040 also set and get, 10:05.500 --> 10:07.040 und weil ich kann sie nur bekommen 10:07.040 --> 10:08.420 von außen. 10:09.520 --> 10:09.840 Und 10:09.840 --> 10:13.540 ich muss keine Getter und Setter schreiben 10:13.540 --> 10:14.680 sondern 10:14.680 --> 10:17.780 anhand der Deklaration sage ich 10:17.780 --> 10:20.020 ob es Getter und Setter gibt 10:20.020 --> 10:22.480 das heißt 10:22.480 --> 10:25.700 wenn ich hier zum Beispiel 10:25.700 --> 10:27.260 mir dieses Objekt hole 10:27.260 --> 10:30.580 was zwei Variablen hat 10:30.580 --> 10:31.760 eine die ich nur 10:31.760 --> 10:35.540 lesen kann 10:35.540 --> 10:37.580 und eine die ich lesen und setzen kann 10:37.580 --> 10:39.620 dann kann ich hier weiter unten 10:39.620 --> 10:41.740 wenn ich mir die Variable, die ich nur lesen kann, 10:41.840 --> 10:42.900 probiere zu setzen, 10:43.280 --> 10:45.140 sage ich mit dem Compiler, du machst gerade etwas falsch. 10:48.740 --> 10:51.080 Also ich brauche keine Getter und Setter, 10:51.180 --> 10:53.420 weil ich durch die Deklaration, 10:53.740 --> 10:56.620 wie ich eigentlich normalerweise in Java Code Properties aufrufe, 10:58.000 --> 11:01.080 die Getter und Setter aufrufen. 11:01.660 --> 11:03.740 Wenn ich jetzt zum Beispiel in Kotlin Code 11:03.740 --> 11:05.580 Java Getter aufrufen möchte, 11:06.280 --> 11:07.580 dann sieht es genau so aus. 11:07.880 --> 11:09.360 Der wandelt mir das gleich um. 11:09.360 --> 11:11.340 ich sehe es nicht mehr, dass es ein Getter 11:11.340 --> 11:12.660 oder ein Setter dahinter steckt. 11:18.600 --> 11:19.500 Auch ein, 11:19.840 --> 11:21.280 da habe ich viele Diskussionen 11:21.280 --> 11:23.080 schon gehalten über Singletons, 11:24.220 --> 11:25.380 was ist das beste 11:25.380 --> 11:26.840 Singleton, wenn ich jetzt hier 11:26.840 --> 11:28.420 in meiner Java-Anwendung 11:28.420 --> 11:30.900 fange ich immer so an mit dem 11:30.900 --> 11:33.020 einfachsten Singleton-Implementierung, 11:34.100 --> 11:35.060 ein Igor-Singleton, was 11:35.060 --> 11:36.540 sofort initialisiert ist. 11:37.760 --> 11:39.140 Also ich halte 11:39.140 --> 11:40.880 ich mache erstmal den Konstruktor 11:40.880 --> 11:43.820 von der Klasse mehr private, damit kein anderer das aufrufen darf 11:43.820 --> 11:45.780 und ich halte mir 11:45.780 --> 11:46.360 intern 11:46.360 --> 11:49.260 eine Instanz statisch 11:49.260 --> 11:51.980 und biete eine Methode 11:51.980 --> 11:53.700 meistens heißt es immer getInstance 11:53.700 --> 11:55.740 und biete die an, um sie zu bekommen 11:55.740 --> 11:58.020 unter Last 11:58.020 --> 11:59.220 oder nicht 11:59.220 --> 12:00.340 das ist nicht unter Last 12:00.340 --> 12:02.980 aber das ist ein Ego-Singleton 12:02.980 --> 12:05.500 und immer beim Applikationsstart wird das initialisiert 12:05.500 --> 12:06.040 und häufig 12:06.040 --> 12:07.540 manchmal 12:07.540 --> 12:15.440 Manchmal verbrauchen solche Initialisierungen von Singleton CPU-Zeit, Speicher, wie auch immer, 12:16.140 --> 12:19.200 wenn man sie nutzt oder auch nicht, als sie verbrauchen. 12:19.200 --> 12:22.660 Deswegen gibt es auch intelligentere Singleton-Implementierungen in Java. 12:23.740 --> 12:24.860 So ein Lazy Singleton. 12:25.920 --> 12:29.720 Da wird es erst erzeugt, wenn ich es das erste Mal aufrufe. 12:30.480 --> 12:33.080 Aber was hat hier einen Nachteil der Implementierung? 12:33.080 --> 12:35.020 hier ist, dass 12:35.020 --> 12:37.360 das If-Statement der Erzeugung 12:37.360 --> 12:39.080 des Singletons 12:39.080 --> 12:41.080 innerhalb eines Synchronized-Blocks ist. 12:41.780 --> 12:42.820 Bei hohem Last 12:42.820 --> 12:46.620 ist das dann hier ein Bottleneck. 12:47.320 --> 12:49.160 Also in klassischen Serveranwendungen sollte man 12:49.160 --> 12:50.340 sowas nicht implementieren. 12:51.460 --> 12:53.060 Deswegen kann man noch ein bisschen mehr Code 12:53.060 --> 12:56.700 hinzufügen, 12:57.540 --> 12:59.160 so ein Double-Checked-Singleton 12:59.160 --> 12:59.760 zu bauen. 13:00.540 --> 13:03.060 Man tut es einmal vor dem Synchronized-Block machen. 13:03.080 --> 13:07.260 Nach dem Synchronized Block immer mehr Code. 13:08.380 --> 13:11.860 Meine Lieblingsimplementierung in Java für Singleton, 13:12.560 --> 13:14.720 was auch eigentlich nur in Java funktioniert, 13:15.260 --> 13:18.080 ist dieses Singleton-Holder-Pattern. 13:20.260 --> 13:22.400 Das ist eine Eigenschaft von dem Java Classloader, 13:22.520 --> 13:26.320 dass innere Klassen erst geladen werden, 13:26.960 --> 13:28.720 wenn es das erste Mal darauf zugegriffen wird. 13:30.260 --> 13:32.320 Da habe ich das mit den ganzen Synchronized Blocks 13:32.320 --> 13:34.820 habe ich die nicht, aber dafür eine innere Klasse, 13:35.020 --> 13:36.700 aber auch wieder eine Menge Code. 13:37.300 --> 13:38.480 Aber kommen wir mal wieder zurück. 13:39.380 --> 13:39.820 Kotlin. 13:42.300 --> 13:43.160 Das ist eine einfache 13:43.160 --> 13:43.780 Kotlin-Klasse. 13:45.240 --> 13:46.720 So ist auch Kotlin kompilierfähig. 13:47.240 --> 13:48.920 Ich brauche hier da hinten nicht solche magischen 13:48.920 --> 13:50.900 Geschweifen, Runden, was auch immer für Klammern. 13:50.960 --> 13:51.800 Das ist schon mal Vaniden. 13:53.660 --> 13:54.820 Aber was hilft mir 13:54.820 --> 13:56.560 Kotlin 13:56.560 --> 13:58.460 dabei? 13:59.460 --> 14:00.640 Wir achten jetzt mal auf das Wort 14:00.640 --> 14:02.580 Class. Und in Kotlin 14:02.580 --> 14:04.460 schreibe ich einfach Object 14:04.460 --> 14:06.360 davor. Und jetzt habe ich ein 14:06.360 --> 14:08.500 Objekt, das 14:08.500 --> 14:09.500 heißt Lazy Singleton. 14:10.280 --> 14:12.500 Ein Objekt. Und das war's. 14:13.380 --> 14:14.560 Was wir alles jetzt davor gesehen 14:14.560 --> 14:16.320 haben mit den ganzen vielen mächtigen 14:16.320 --> 14:18.300 Code, ist eigentlich 14:18.300 --> 14:19.940 in einer Zeile Kotlin. Und 14:19.940 --> 14:22.280 diese Implementierung in Kotlin ist natürlich auch 14:22.280 --> 14:22.600 Lazy. 14:30.640 --> 14:36.840 So besser? 14:38.760 --> 14:39.080 Okay. 14:47.080 --> 14:49.720 Kommen wir zu Bildern in Java. 14:51.100 --> 14:52.860 Warum hat man Bilder in Java? 14:54.360 --> 14:58.480 Man steht häufig vor dem Problem in Java. 14:58.480 --> 15:00.480 man hat ein Objekt 15:00.480 --> 15:03.200 das hat eine Menge Parameter 15:03.200 --> 15:05.640 und ich habe einen Konstrukt, der hat auch eine Menge Parameter 15:05.640 --> 15:07.640 und wenn ich immer dieses Objekt erzeugen möchte 15:07.640 --> 15:11.800 dann weiß ich nicht, was war nochmal der dritte Parameter 15:11.800 --> 15:13.060 was setze ich da jetzt vor 15:13.060 --> 15:14.640 ich habe eigentlich keine Ahnung 15:14.640 --> 15:17.500 deswegen geht man her 15:17.500 --> 15:19.460 in Java und baut sich solche Bilder 15:19.460 --> 15:23.620 wir haben dann immer solche Methoden 15:23.620 --> 15:25.880 ich habe das jetzt mal abgekürzt, weil der ganze Code 15:25.880 --> 15:27.240 gar nicht auf die Folie passt 15:27.240 --> 15:29.460 aber man beispielsweise für withOne 15:29.460 --> 15:33.460 und gibt sich immer eine Selbstreferenz des Bildes wieder zurück 15:33.460 --> 15:34.800 und dann kann man das so schreiben, 15:35.480 --> 15:36.720 also ich baue mir ein Objekt, 15:37.320 --> 15:41.800 wo One true ist, Two true und so weiter und so fort. 15:42.460 --> 15:44.080 Was hat man jetzt für einen Vorteil erreicht? 15:44.260 --> 15:46.640 Man kann jetzt lesen, wie ich mein Objekt erzeuge, 15:47.400 --> 15:49.720 aber was ist der Nachteil? Ich habe ganz viel Code. 15:52.760 --> 15:56.660 Schauen wir uns mal das Gleiche in Kotlin an. 15:57.240 --> 16:03.320 Jetzt sagt ja jeder, ich habe ja wieder dasselbe Problem. 16:04.960 --> 16:07.040 Ich weiß ja nicht, was ist denn der dritte Parameter jetzt? 16:07.860 --> 16:19.040 In Kotlin ist es erlaubt, die Parameter zu labeln, wie sie auch deklariert worden sind. 16:19.840 --> 16:21.460 Was ich jetzt schon erreicht habe, ist, 16:23.100 --> 16:27.480 ich kann sehen, wie free gesetzt wurde. 16:28.700 --> 16:30.980 Aber jetzt habe ich ja noch den Nachteil, 16:31.940 --> 16:34.800 ich kann die Reihenfolge dessen nicht drehen 16:34.800 --> 16:37.000 oder so machen, wie ich es gerade haben möchte. 16:37.760 --> 16:39.740 Und ich kann auch nicht Parameter weglassen, 16:40.020 --> 16:41.380 wie beim Builder-Pattern in Java. 16:43.400 --> 16:46.620 Wenn ich in Kotlin Default-Werte setze, 16:47.260 --> 16:48.040 hier oben, 16:49.040 --> 16:56.200 dann ist es mir erlaubt, von der Sprache her, sie wegzulassen, 16:57.720 --> 17:02.600 weil sie werden dann defaultmäßig so gesetzt, wie sie definiert sind. 17:03.160 --> 17:07.800 Und ich kann die Reihenfolge der Parameter auch drehen, weil sie sind gelabelt. 17:09.460 --> 17:12.500 Also man hat keinen Grund mehr, in Kotlin Bilder zu bauen 17:12.500 --> 17:16.340 oder sich manchmal vielleicht mit Lombok zu generieren zu lassen, 17:16.340 --> 17:19.280 weil die Sprache das einfach für einen schon erledigt. 17:24.060 --> 17:30.680 Wer mag Delegationsmethoden schreiben? 17:30.900 --> 17:35.880 Also man kennt es klassisch her von dem Decorator-Pattern. 17:38.320 --> 17:41.320 Man hält immer eine Instanz innerhalb. 17:41.320 --> 17:46.580 man hält eine Instanz 17:46.580 --> 17:48.000 sich in der Klasse 17:48.000 --> 17:52.460 und dekoriert dann die Methoden 17:52.460 --> 17:53.660 die man überschreibt 17:53.660 --> 17:56.120 oh Gott 17:56.120 --> 17:58.200 schwierig, nein 17:58.200 --> 18:01.100 und muss in Java 18:01.100 --> 18:02.580 also man hat 18:02.580 --> 18:04.840 ein Interface, was hier List ist 18:04.840 --> 18:06.580 sollte jedem was sagen 18:06.580 --> 18:09.000 und dekoriert jetzt 18:09.000 --> 18:10.180 das Interface 18:10.180 --> 18:13.680 zum Beispiel die Methode 18:13.680 --> 18:15.940 size, indem man 18:15.940 --> 18:17.880 eine Instanz oder eine 18:17.880 --> 18:19.640 Implementierung innerhalb hält 18:19.640 --> 18:22.160 der Klasse, sie überschreibt, 18:22.320 --> 18:23.620 irgendwas Tolles macht und 18:23.620 --> 18:25.680 in Java muss man jetzt für das 18:25.680 --> 18:27.720 Interface List alle anderen Methoden 18:27.720 --> 18:29.260 definieren 18:29.260 --> 18:31.200 und weiter delegieren. 18:31.900 --> 18:33.080 Ziemlich dumme Logik. 18:34.220 --> 18:34.820 In Kotlin 18:34.820 --> 18:37.780 hilft uns da das Wort 18:37.780 --> 18:38.620 y weiter. 18:40.180 --> 18:46.000 das Wort by deklariert, also wir haben hier eine Klasse, 18:47.200 --> 18:52.720 wir haben eine Variable der Klasse und sagen, 18:53.720 --> 19:05.940 das Interface List, die ganzen Methoden werden von dem Objekt List bearbeitet oder entgegengenommen. 19:05.940 --> 19:09.540 Und so muss ich sie nicht nochmal neu schreiben oder weiter deklarieren. 19:09.540 --> 19:11.560 und wenn ich jetzt noch Lust dazu habe, 19:12.040 --> 19:15.300 kann ich sie überschreiben mit Override, die Methode 19:15.300 --> 19:18.300 und dann spaßhalber irgendwas machen, was ich möchte. 19:21.680 --> 19:24.800 Kommen wir mal zu einem bisschen reelleren Beispiel. 19:26.560 --> 19:29.300 REST-Interfaces schreiben, da gibt es viele Frameworks. 19:29.440 --> 19:31.780 Ich habe hier ein Retrofit-Beispiel. 19:32.340 --> 19:35.560 Das gibt es aber auch in Backend-Anwendungen, 19:35.620 --> 19:36.680 wenn man REST-Clients beschreibt, 19:36.680 --> 19:39.100 da tut man häufig nur noch ein Interface deklarieren. 19:39.540 --> 19:41.540 mit der Restmethode, 19:41.640 --> 19:42.260 das ist ein Get, 19:43.100 --> 19:44.240 hat diesen Pfad 19:44.240 --> 19:47.260 und hat die Query-Parameter und so weiter, 19:47.340 --> 19:48.520 aber das ist ja nur ein Interface, 19:49.400 --> 19:49.860 weil 19:49.860 --> 19:53.340 Retrofit, 19:53.540 --> 19:55.420 man gibt Retrofit das Interface rein 19:55.420 --> 19:56.900 und es erzeugt uns jetzt ein Objekt 19:56.900 --> 19:57.640 dessen. 19:59.560 --> 20:01.320 Und jetzt habe ich hier ein paar Sachen kombiniert. 20:01.860 --> 20:03.260 Ich sage, ich habe einen Singleton, 20:03.740 --> 20:04.640 der heißt Client 20:04.640 --> 20:07.300 und das Interface, 20:07.500 --> 20:09.040 implementiert das Interface 20:09.040 --> 20:11.360 und das Interface wird von dem Objekt erzeugt, 20:11.400 --> 20:13.260 was mir der Retrofit 20:13.260 --> 20:15.800 mir für ein Objekt erzeugt, 20:15.800 --> 20:16.920 anhand des Interfaces. 20:19.380 --> 20:20.480 Und so habe ich mir ganz schnell 20:20.480 --> 20:23.440 eine Möglichkeit geschafft, 20:23.500 --> 20:24.820 in meinem Code, jetzt kann ich überall 20:24.820 --> 20:25.800 einen kleinen Punkt, 20:26.400 --> 20:28.740 PetroStations aufrufen 20:28.740 --> 20:30.580 und eine Restanfrage machen. 20:31.880 --> 20:32.920 Das ist eigentlich der Code, 20:32.980 --> 20:33.820 den ich dafür brauche. 20:39.040 --> 20:47.900 In Java ist es für mich ein ziemliches, nicht beliebtes Thema, Optionals. 20:50.900 --> 20:54.680 Machen wir mal ein kleines Beispiel in Java für Optionals. 20:55.900 --> 21:00.920 Also, wir haben eine Methode, die gibt uns ein Optionals von einem String zurück. 21:01.780 --> 21:03.140 Und was macht die? 21:03.140 --> 21:05.060 zufallsmäßig 21:05.060 --> 21:07.120 tut die uns einmal einen Wert 21:07.120 --> 21:07.820 zurückgeben 21:07.820 --> 21:10.700 oder einmal keinen Wert zurückgeben 21:10.700 --> 21:13.140 und jetzt oh Wunder, wir geben einfach mal 21:13.140 --> 21:13.820 einen Null zurück. 21:15.040 --> 21:16.220 Der Compiler sagt hier nichts. 21:17.720 --> 21:18.960 Wenn wir hier unten jetzt 21:18.960 --> 21:20.460 die Methode aufrufen 21:20.460 --> 21:22.960 und aller Wahrscheinlichkeit 21:22.960 --> 21:24.980 aller dreimal, wenn wir das aufrufen, 21:24.980 --> 21:26.000 kriegen wir einen Nullpointer. 21:28.020 --> 21:29.040 Und was wir auch 21:29.040 --> 21:31.320 noch brauchen ist, wir müssen 21:31.320 --> 21:33.760 um ein Optional darzustellen, 21:34.440 --> 21:36.040 brauchen wir immer ein Wrapper-Objekt 21:36.040 --> 21:37.960 um den eigentlichen Wert. 21:41.320 --> 21:42.540 Auch eine Menge Code. 21:42.700 --> 21:43.560 Schauen wir mal an, 21:45.020 --> 21:46.460 wie das in Kotlin gelöst ist. 21:47.700 --> 21:48.600 Also ich halte nochmal fest, 21:48.660 --> 21:50.020 wir haben keine Compile-Sicherheit 21:50.020 --> 21:51.740 und wir brauchen ein Wrapper-Objekt. 21:55.380 --> 21:56.440 In Kotlin 21:56.440 --> 21:59.360 gibt es ganz einfach 21:59.360 --> 22:01.600 das Zeichen 22:01.600 --> 22:03.560 Fragezeichen. 22:04.260 --> 22:05.400 Das symbolisiert, 22:05.840 --> 22:07.680 dass der Return-Type 22:07.680 --> 22:08.480 ein Optional ist. 22:09.640 --> 22:11.400 Das kann ich auch bei Parametern angeben, 22:11.480 --> 22:13.540 in der Methodensignatur, mache ich ein Fragezeichen 22:13.540 --> 22:15.580 da hinten. Und was ich jetzt erreicht 22:15.580 --> 22:17.560 habe ist, ich darf null 22:17.560 --> 22:19.780 return. Wenn ich das Fragezeichen 22:19.780 --> 22:21.660 hier rausnehme, sagt der Compiler hier schon, 22:22.280 --> 22:23.200 ist nicht erlaubt. 22:23.760 --> 22:25.700 Das löst uns eigentlich schon der Compiler. 22:28.480 --> 22:28.960 Und 22:28.960 --> 22:35.500 Es gibt dann noch so ein bisschen, ich nenne es immer syntaktischen Zucker. 22:36.420 --> 22:42.260 Also wenn ich jetzt die Methode getOptional hier aufrufe, was meinen optional zurückgibt, 22:42.620 --> 22:48.620 und es ist jetzt nicht gesetzt, dann nehme ich diesen Wert und trimme ihn. 22:49.360 --> 22:55.020 Ich komme hier kein Nullpointer, ich habe kein Wrapper-Objekt, alles mal wieder kompakter gemacht. 22:55.020 --> 22:57.600 was es auch noch gibt in Kotlin 22:57.600 --> 23:00.280 ist diese Syntax 23:00.280 --> 23:02.160 also ich rufe auf dem 23:02.160 --> 23:03.980 Objekt 23:03.980 --> 23:05.920 was ich hier zurückbekomme 23:05.920 --> 23:08.060 von der Methode einfach drin direkt auf 23:08.060 --> 23:10.040 aber es wird nur aufgerufen 23:10.040 --> 23:11.620 falls es nicht null ist 23:11.620 --> 23:14.260 also auch mal eine Kurzform 23:14.260 --> 23:15.800 um zu programmieren 23:15.800 --> 23:25.620 Kennt ihr das, so eine Utils-Klasse 23:25.620 --> 23:26.420 in Java Code? 23:27.240 --> 23:28.400 Hat er eben schon mal so geschrieben. 23:28.880 --> 23:31.460 Eine Utility-Klasse, die irgendwas 23:31.460 --> 23:32.220 tut für einen. 23:33.500 --> 23:35.360 Die irgendwie einen String noch mit irgendwas 23:35.360 --> 23:36.620 macht, wie auch immer. 23:38.480 --> 23:39.080 Und irgendwie macht das 23:39.080 --> 23:41.440 keinen Spaß, ist auch nicht objektorientiert, nicht wirklich. 23:42.620 --> 23:43.520 In Kotlin 23:43.520 --> 23:44.980 gibt es Extensions. 23:45.800 --> 23:49.820 Man kann vorhandene Klassen und Funktionen erweitern. 23:50.480 --> 23:56.340 Also ich sage, von der Klasse String füge ich noch eine Methode hinzu, 23:56.460 --> 23:57.660 ich nenne sie jetzt einfach mal AddRandom, 23:57.860 --> 24:01.980 und nimmt sich selber und tut hinten dran nochmal einen Zufallswert hinzufügen. 24:02.480 --> 24:06.060 Und dann kann ich auf den beliebigen String die Methode einfach aufrufen. 24:07.580 --> 24:11.300 Ich brauche keine Utes-Klassen und ich muss die auch nicht selber rappen, 24:11.400 --> 24:13.080 irgendwie einen String-Rapper mit mir bauen, 24:13.080 --> 24:18.080 sondern ich kann vorhandene Klassen einfach erweitern und funktionieren. 24:24.700 --> 24:29.200 Ah, das ist auch noch ein schöner Grund, Boilerplate-Code. 24:34.500 --> 24:37.060 Hat jemand schon mal falsch geschrieben, 24:37.200 --> 24:39.440 toString, equals und HashCode-Methoden gesehen? 24:40.760 --> 24:41.460 Keiner hier? 24:43.080 --> 24:45.720 Ich sehe sie mittlerweile auch nicht mehr so häufig. 24:49.360 --> 24:51.260 Aber sie sind auch immer nervig zu schreiben. 24:51.680 --> 24:54.920 Man kann dann immer so Guava oder man kann Apache Commons nehmen. 24:54.980 --> 24:59.860 Die haben so Bilder-Dinger, mit denen man sich diese Methoden sauberer schreiben kann. 24:59.980 --> 25:01.900 Man kann Lombok nehmen, um sich die zu generieren. 25:04.660 --> 25:05.820 Was bietet uns Kotlin? 25:05.820 --> 25:16.260 Also, hier haben wir natürlich auch eine Klasse, die hat irgendwelche Variablen gesetzt. 25:16.260 --> 25:21.780 Und ich habe jetzt eigentlich wirklich keine Lust, diese Methoden mir nochmal zu schreiben. 25:21.780 --> 25:25.380 Also, man schreibt immer wieder dasselbe, immer denselben Müll. 25:25.380 --> 25:32.440 In Kotlin schreibt man einfach Data davor und die sind einfach da. 25:32.440 --> 25:37.220 Wenn ich jetzt ein ToString auf diese Klasse aufrufe, dann ist es sauber formatiert. 25:37.580 --> 25:41.640 Man hat keinen Hashcode für die Referenz im Speicher und was auch immer. 25:42.520 --> 25:44.540 Man schreibt einfach Data davor, das ist einfach da. 25:45.160 --> 25:48.900 Ich muss dafür nichts tun, muss nicht Code generieren, nicht selber schreiben. 25:49.720 --> 25:50.720 Das ist eigentlich alles. 25:55.500 --> 25:57.580 Also was löse ich eigentlich mit Kotlin? 25:57.580 --> 26:01.940 Ich tue eigentlich viel Boilerplate-Code, den ich eigentlich gar nicht so schreiben möchte, 26:02.040 --> 26:03.220 wo mir immer Fehler passieren. 26:04.260 --> 26:06.000 Den vermeide ich einfach mit Kotlin. 26:07.040 --> 26:09.940 Und jetzt komme ich eigentlich zu meiner letzten Frage. 26:12.340 --> 26:13.680 Was sagt ihr über Kotlin? 26:16.520 --> 26:17.100 Lügt ihr es? 26:20.960 --> 26:21.960 Lügt ihr es nicht? 26:21.960 --> 26:39.620 Also wenn ich mir das so angucke, jetzt bis auf die Basis-Syntax, das schreit in großen Teilen schon ziemlich nach C-Sharp. Also da wurde wohl einiges klaut. Also gerade die Optional-Geschichte, diese Extension-Methods, die es gibt. 26:40.460 --> 26:41.960 Wobei bei denen frage ich mich dann schon, 26:41.960 --> 26:46.460 also die löst eigentlich ein Problem, das man gar nicht haben müsste, 26:46.600 --> 26:50.240 wenn man nicht gezwungen wäre, objektorientiert zu programmieren. 26:50.440 --> 26:53.100 Wenn ich da einfach eine freie Funktion machen könnte, 26:53.220 --> 26:56.380 die als erster Parameter dann diesen String kriegt, 26:57.380 --> 27:00.620 dann wird das auch funktionieren, hat früher zumindest funktioniert. 27:01.280 --> 27:04.780 Und wenn ich dann noch vielleicht so eine Unified Function Calling Syntax habe, 27:04.780 --> 27:07.020 mit der ich mir raussuchen kann, ob ich 27:07.020 --> 27:09.200 erster Parameter Punkt 27:09.200 --> 27:11.280 Funktionsname schreibe oder 27:11.280 --> 27:13.420 die freie Funktion so schreibe, 27:14.080 --> 27:15.340 dann kann ich 27:15.340 --> 27:16.960 das eigentlich auch haben und 27:16.960 --> 27:19.000 bin da noch ein bisschen genereller 27:19.000 --> 27:19.720 aufgestellt. 27:22.260 --> 27:23.240 Also irgendwie 27:23.240 --> 27:24.760 das ist so ein bisschen 27:24.760 --> 27:26.460 Bugfixing von Java. 27:27.120 --> 27:27.400 Ja. 27:29.400 --> 27:31.260 Aber man ist häufig ja auf Java, 27:31.260 --> 27:33.260 also wenn man 27:33.260 --> 27:44.220 also wenn man Software für große Unternehmen schreibt und die großen Frameworks, die da genommen werden, Spring, also JEE ist ja wieder im Abklingen, dann sind die alle Java-basiert. 27:45.960 --> 27:52.740 Und Spring hat jetzt zum Beispiel auch neuen Hype bekommen, weil viel von Netflix gekommen ist, viel Code. 27:53.900 --> 27:58.660 Und also viele Komponenten von Netflix werden in Java geschrieben. 27:58.660 --> 28:13.300 Also es gibt viele Java-Anwickler und man hat sich natürlich gedacht, Java ist mir irgendwie die, wenn man sich mal vorstellt, was passiert ist von Java 5 auf Java 7, ist eigentlich syntaktisch oder von der Sprache her hat sich fast nichts getan. 28:14.300 --> 28:23.160 Und dieser, jetzt hat man Java 8, da hat sich mal ein bisschen mehr getan und wenn ich mir jetzt Kotlin anschaue, es ist nochmal ein wesentlich mächtiger Sprung. 28:23.160 --> 28:30.340 Was halt Java ausmacht, ist, dass man viele Frameworks hat, die einen tun. 28:30.500 --> 28:33.940 Und das fehlt bei anderen Sprachen, diese mächtigen Frameworks einfach. 28:37.680 --> 28:42.260 Ja, vielleicht von der Java-Fraktion noch ein paar Kommentare. 28:43.200 --> 28:44.040 Wie sieht es aus? 28:48.040 --> 28:50.080 Entsteht der Drang, morgen steige ich um? 28:50.080 --> 28:52.900 Ich kann ja weiterhin mit meiner JVM arbeiten. 28:52.900 --> 29:04.120 Es ist ja kein Verlust sozusagen. Oder wenn wir sagen, ja, ich brauche es vielleicht doch nicht so die Features oder ich lebe auch mit dem längeren Code noch. Wie sind die Meinungen? 29:04.120 --> 29:34.100 Noch ein bisschen. 29:34.120 --> 29:36.180 springen, sondern kann eigentlich 29:36.180 --> 29:38.260 sich so ein bisschen von Java wegbewegen 29:38.260 --> 29:38.880 mit Kotlin. 29:41.240 --> 29:42.540 Oder ganz weit weg 29:42.540 --> 29:44.200 könnte man natürlich dann gleich zu Clojure gehen, 29:44.280 --> 29:45.600 das sieht dann komplett anders aus. 29:46.700 --> 29:48.240 Ja, Kotlin ist 29:48.240 --> 29:49.980 nicht zwangsweise auf Java 29:49.980 --> 29:50.820 gebunden. 29:52.000 --> 29:53.840 Kotlin wird auch verwendet um Gradle 29:53.840 --> 29:56.180 zum Beispiel. Man kann Gradle, also das 29:56.180 --> 29:57.920 Bildsystem, auch in Kotlin schreiben. 30:01.220 --> 30:02.320 Auch JavaScript 30:02.320 --> 30:04.660 lässt sich innerhalb von Kotlin schreiben. 30:04.740 --> 30:05.980 Ich habe es selber noch nie ausprobiert, 30:07.220 --> 30:07.520 aber 30:07.520 --> 30:10.420 es ist eigentlich unabhängig. 30:10.960 --> 30:12.120 Aber man kann es dazu nutzen, auch 30:12.120 --> 30:13.740 Java zu schreiben, 30:14.680 --> 30:15.660 aber auch andere Dinge. 30:17.060 --> 30:18.680 Das wäre nämlich meine Frage gewesen. 30:18.800 --> 30:20.340 Ich habe mich gefragt, ist Kotlin 30:20.340 --> 30:22.480 eigentlich ein Source-to-Source-Compiler? 30:22.760 --> 30:24.480 Das heißt, dass er Kotlin nimmt und 30:24.480 --> 30:26.740 Java erzeugt und dann kompiliert in Bytecode 30:26.740 --> 30:27.400 ganz klassisch? 30:27.400 --> 30:28.240 Es geht gleich direkt in Bytecode. 30:30.660 --> 30:31.220 Kotlin 30:31.220 --> 30:33.340 kompiliert sofort in Bytecode. 30:33.760 --> 30:34.380 Alles klar. 30:34.720 --> 30:36.980 Was ich jetzt an den Features gesehen habe, wäre 30:36.980 --> 30:39.180 natürlich auch, wie wir es aus der JavaScript-Welt 30:39.180 --> 30:42.100 kennen, ein Source-to-Source-Compile- 30:42.100 --> 30:43.220 Möglichkeit. Da gab es ja einige 30:43.220 --> 30:45.240 Verbesserungen. Also das hat mich 30:45.240 --> 30:47.320 auch ein bisschen daran erinnert, es gab ja etliche Ansätze 30:47.320 --> 30:47.900 in JavaScript, 30:48.940 --> 30:50.660 die hässlichen Dinge dort, 30:50.940 --> 30:51.740 zum Beispiel eben 30:51.740 --> 30:55.240 der globale Namespace und all diese Dinge, 30:55.520 --> 30:56.200 dass man die mit 30:56.200 --> 30:59.220 Sprachverbesserungen, die natürlich inkompatibel 30:59.220 --> 31:01.120 sind, ich habe den Namen vergessen, wie hießen 31:01.120 --> 31:01.680 die in Java. 31:02.640 --> 31:04.360 Hilft mir einer auf die Sprünge, diese 31:04.360 --> 31:06.320 Metasprachen für das JavaScript. 31:07.480 --> 31:08.040 TypeScript? 31:09.080 --> 31:10.360 Ja, es gab 31:10.360 --> 31:12.560 noch ein paar andere, die 31:12.560 --> 31:14.780 praktisch einfach so Fehler 31:14.780 --> 31:16.680 in JavaScript versucht haben, 31:17.020 --> 31:18.760 mit doch eine neue Syntax zu vermeiden, 31:19.040 --> 31:21.020 die dann aber dann kompiliert wurden 31:21.020 --> 31:22.300 ins normale JavaScript, 31:22.960 --> 31:25.000 um eben richtig ausgeführt zu werden. 31:25.340 --> 31:26.840 Das war so mein erstes Gefühl, ob das 31:26.840 --> 31:28.580 so funktioniert, aber es ist offensichtlich richtig, 31:28.580 --> 31:29.660 gleich in Bytecode. 31:31.120 --> 31:37.360 Was ich ein bisschen problematisch sehe oder einschränkend ist, 31:38.120 --> 31:42.780 also man backt hier einfach manche Patterns in die Sprache rein, 31:42.900 --> 31:44.840 also in die Syntax der Sprache rein, 31:44.840 --> 31:48.060 um dann es angenehmer zu machen, zu programmieren. 31:48.640 --> 31:51.480 Ich finde, dass es dann irgendwie hübsch abdeckt hat, 31:52.080 --> 31:54.160 solche Patterns zu implementieren. 31:54.440 --> 31:56.420 Also dann automatisch die drei Methoden, 31:56.420 --> 32:13.420 sondern dass ich beispielsweise über Metaprogrammierung die Möglichkeit habe, über eine Annotation zu sagen, gut, ich habe irgendwo meine Library, die mir die drei Methoden dann für eine beliebige Klasse generiert. 32:20.360 --> 32:24.800 Aber bis man das immer wieder in seinen Buildscript einbaut und das ganze Zeug. 32:24.800 --> 32:29.400 Ja, aber deshalb sollte die Möglichkeit in der Sprache drin sein. 32:29.480 --> 32:35.320 Dann brauche ich das nicht ins Bildsystem reinbauen, sondern habe ich das einfach als Library wie jede andere auch. 32:36.560 --> 32:38.600 Vielleicht auch in einer Standardbibliothek drin. 32:38.680 --> 32:44.340 Dann habe ich immer noch die Möglichkeit, wenn ich jetzt selber irgendwie für mich vielleicht für eine bestimmte Domäne einen Pattern entdecke, 32:44.680 --> 32:49.520 das oft auftritt, dass ich mir dadurch für eine Library schreibe, die mir hübsche Syntax macht. 32:49.520 --> 32:58.860 Ich finde es eigentlich ganz gut, dass die Sprache mir für diese unangenehmen Stellen, 32:58.860 --> 33:03.580 die ich persönlich auch immer in meinem Entwicklerleben habe, eine Lösung bietet, 33:03.580 --> 33:12.380 die Sprache. Und was in der Zukunft ist, weiß ich immer nie. Aber die Content-Entwicklung ist 33:12.380 --> 33:17.600 viel, viel schneller als die der Java-Entwicklung. Und man kann da selber Vorschläge einreichen, 33:17.600 --> 33:23.360 Zum Beispiel habe ich in einem Chat gelesen, ich möchte Multiple Return Parameters haben. 33:24.720 --> 33:33.240 Und was du auch möchtest, du kannst es einbringen, wenn sie es aufnehmen, ist für dich gut. 33:34.060 --> 33:39.060 Aber ich kann es nicht selber bauen als Library, das ist das Problem, das ich sehe. 33:39.060 --> 33:49.200 Ich muss halt warten, bis irgendjemand, der sich in dem Sprachkomitee dafür entscheidet, das einzubauen, das halt dann einbaut. 33:50.520 --> 33:52.500 Welche Sprache bietet man denn, diese Flüchtlinge? 33:52.580 --> 33:56.060 Also C++ bietet... 33:57.520 --> 33:58.800 Eine ganze Menge anderer Nachteile? 33:58.800 --> 34:03.580 Eine ganze Menge Nachteile ja, aber zum Beispiel ist ziemlich viel gebaut worden. 34:05.040 --> 34:13.500 C++ hatte Lampdas, die dann im ersten Schritt nur über Libraries gebaut worden sind. 34:13.500 --> 34:16.400 Also da bauen Leute Libraries, die Probleme lösen. 34:16.800 --> 34:23.360 Die sind in manchen Bereichen vielleicht ein kleines bisschen hässlicher, als wäre es in der Sprache drin. 34:23.720 --> 34:28.720 Aber man hat halt trotzdem die Möglichkeit, um Probleme rumzuarbeiten, elegante Lösungen zu bauen. 34:28.800 --> 34:31.260 und muss nicht die Sprache anfassen. 34:31.360 --> 34:34.020 Da gibt es sicherlich Sprachen, die das viel besser können als C++, 34:34.700 --> 34:37.800 aber eigentlich ist die Sprache meiner Ansicht nach die Möglichkeit, 34:37.980 --> 34:41.020 also Werkzeuge bieten, mit denen man die Sprache erweitern kann, 34:41.020 --> 34:46.020 anstatt ein großes Subset einfach fest in die Sprache reinzubacken. 34:47.520 --> 34:51.320 Ja, also Lisp würde das Ganze ins Extreme bringen. 34:51.440 --> 34:55.220 Da kann man ja Syntax bauen mit Parser-Makros. 34:55.760 --> 34:57.760 Also das wäre so das extreme Ende davon. 34:58.800 --> 35:04.500 Jetzt haben wir so richtig schon die ganze Brandbreite da. 35:04.760 --> 35:09.220 Wir haben angefangen mit einem extrem nicht generellen Ansatz, 35:09.320 --> 35:12.960 sondern zugeschnitten auf eine Domäne mit wahnsinniger Mächtigkeit eingebaut. 35:13.280 --> 35:15.620 Aber was die nicht einbauen, das hat der Entwickler da nicht. 35:15.740 --> 35:16.460 Das ist ganz klar. 35:16.820 --> 35:20.140 Jetzt haben wir hier gesehen, Kotlin geht so einen Zwischenweg, 35:20.140 --> 35:23.660 baut so manches, was man als unangenehm empfindet, in die Sprache ein, 35:23.740 --> 35:25.420 um zu sagen, einfach ist praktisch. 35:25.840 --> 35:27.860 Und jetzt haben wir hier die Puristenseite, 35:27.860 --> 35:31.720 die immer von C und C++ hochgehalten wurde und gesagt, 35:32.000 --> 35:36.420 bau bloß nichts rein und sowas, was quasi in diesem Kern, 35:36.840 --> 35:39.860 was nachher vielleicht sogar als Problem auftritt, 35:40.460 --> 35:42.500 was mich behindert in der Performance oder sowas. 35:42.800 --> 35:46.240 Das berühmte End-to-End-Argument im Verteilungssystem sagt ja auch, 35:46.480 --> 35:50.060 sei sehr vorsichtig, je tiefer du eine Funktionalität einbaust, 35:50.120 --> 35:54.040 denn du bestrafst alle die, die sie nicht wollen, damit die da durch müssen. 35:54.420 --> 35:55.580 Das verstehe ich genauso. 35:55.580 --> 36:04.980 Da ist der Puristenansatz, der sagt, wenn du sowas Dinge reinbaust, baue sie so rein in die Sprache, dass man sie auch A weglassen kann oder B erweitern und selber reinbauen kann wieder quasi. 36:05.120 --> 36:08.580 Da haben wir jetzt die gesamte Bandbreite an Sprachdenken. 36:09.580 --> 36:24.140 Von hochgradig speziell über so einen Mittelweg, der sagt, ja aber von der Usability, der dann auch eine Usability reinzieht und so an die Entwickler denkt, bis hin zum puristischen Ansatz, der sagt, ich nehme auch Unbequemlichkeiten in Kauf für die volle, totale Mächtigkeit, die ich möchte. 36:24.740 --> 36:26.940 Da sagt der eine in der Mitte wiederum, die brauche ich gar nicht. 36:27.220 --> 36:28.980 Der andere sagt, das kommt für mich sowieso nicht in Frage. 36:29.040 --> 36:34.680 Also man sieht einfach die verschiedenen Anwendungsmöglichkeiten, wie die zu verschiedenen Lösungen tendieren. 36:36.240 --> 36:37.420 Ich habe noch was anderes. 36:37.760 --> 36:40.420 Also jetzt ist ja auch noch ein politisches Thema angeklungen. 36:41.080 --> 36:44.620 Er hat nämlich gesagt, naja, wenn ich was will in Kotlin, dann reiche ich es ein. 36:44.740 --> 36:49.340 Und mit dem großen Vertrauen, das da durchgeklungen ist, ich habe das dann auch bald. 36:49.340 --> 37:07.460 Und ich glaube, da kommt jetzt eben wirklich dann was, was man vielleicht auch mal nochmal reflektieren sollte. Der Entwicklungsprozess von Java, der wird mittlerweile ja von Oracle kontrolliert und da gibt es wohl Stöhnen, wie jetzt die Entwicklung von Java durch die Community schwer zu beeinflussen ist. 37:07.460 --> 37:13.220 Das ist wahrscheinlich ein Grund, warum jetzt diese Bemerkung gefallen ist, in Kotlin, dann mache ich das halt rein. 37:13.560 --> 37:19.160 Anscheinend geht das viel leichter. Also das wäre vielleicht noch eine Frage, wer kontrolliert das, wie gut läuft das? 37:19.280 --> 37:24.000 Und in C++, da hat man dann ja auch ein ordentliches Komitee, um das zu steuern. 37:24.220 --> 37:26.440 Also ich denke, das ist auch noch ein ganz interessanter Aspekt. 37:26.960 --> 37:29.860 Wie kriegt man so eine Sprache weiterentwickelt? Wer kontrolliert das? 37:29.860 --> 37:35.520 Wer kontrolliert das? Das ist Chatbrains. Wir entwickeln die Sprache hauptsächlich. 37:37.460 --> 37:50.140 Ja, man sieht, es gibt keinen, wie soll ich sagen, der goldene Weg ist schwer zu finden an dieser Stelle. 37:50.140 --> 37:53.220 Das geht mit Sicherheit relativ schnell auf Kurz-Zuruf erstmal. 37:53.320 --> 37:56.400 Das kommt natürlich darauf an, wie Kotlin sich weiterentwickelt. 37:56.800 --> 38:00.980 Im Ausmaß von Java und C++, klar, da haben wir ganze Industriekomitees, 38:00.980 --> 38:06.020 Weil was dort entschieden wird, das hat für Firmen enorme Effekte natürlich. 38:06.480 --> 38:08.920 Entsprechend zäher läuft der Prozess auch ab. 38:09.220 --> 38:13.600 Da ist es halt nicht mehr der getan mit ich baue es mal schnell rein oder so. 38:15.340 --> 38:18.860 Wobei, wie gesagt, je generischer die Sprache ist, kann ich es auch selber machen. 38:18.940 --> 38:21.740 Im anderen Fall bin ich tatsächlich darauf angewiesen. 38:22.280 --> 38:27.240 Tja, jetzt haben Sie die Möglichkeit, sich das auszusuchen, was Sie wollen. 38:27.240 --> 38:30.160 Mir gefällt weniger Syntax immer. 38:30.160 --> 38:35.760 Ja, Java wird ja schon ein bisschen bloatware vorgeworfen, ein bisschen geschwätzig. 38:36.100 --> 38:38.340 Mir gefällt es, wenn es weniger ist, sehr gut. 38:38.760 --> 38:44.340 Ob ich das, was ich gesehen habe jetzt, ob mich das jetzt sofort ins Lager von Kotlin treibt, 38:45.080 --> 38:46.160 ich werde es überlegen. 38:46.480 --> 38:49.360 Ich bin mir noch nicht so hundertprozentig sicher. 38:49.660 --> 38:52.040 Wir sind auch erstaunlich konservativ für Sprachleute. 38:52.600 --> 38:57.040 An dem, was man kennt, hängt man schon auch ein bisschen aus Bequemlichkeit, 38:57.760 --> 38:59.040 weil man sich halt auch umstellen muss. 38:59.040 --> 39:02.580 Genau, ich gehe auch eine Zeit lang an Java. 39:04.500 --> 39:07.160 Was es mir sehr einfach gemacht hat, ich hatte mit Android angefangen. 39:08.640 --> 39:14.380 Und es hat vier Klicks gedauert, dann hatte ich mein Java-Android-Projekt umgestellt auf Kotlin-Projekt. 39:15.480 --> 39:20.340 Und was es natürlich auch noch ziemlich einfach macht, in Android Studio oder in IntelliJ, das Plugin, 39:21.000 --> 39:24.460 ich kann vorhandene Java-Klassen mir einfach konvertieren lassen. 39:24.660 --> 39:27.320 Shortcut, ist eine Kotlin-Klasse draus geworden. 39:27.320 --> 39:36.420 Und was es noch geht, ist, ich kann aus Java-Klassen einen Code kopieren und sie in Kotlin-Code reinpasten und es wird Kotlin-Code. 39:37.920 --> 39:46.880 Also die IDEs, die halt auch von Chatbrains gepflegt werden, wie IntelliJ und Android Studio, bieten da eigentlich super Support. 39:46.880 --> 39:59.180 Ich durfte ja auch beim Workshop bei Novatex sehen, dass also gerade IntelliJ enorme Verbreitung gefunden hat, jetzt in der Gemeinde. 39:59.180 --> 40:24.080 Ja, es gibt noch ein paar, die noch NetBeans machen und Eclipse ist mehr oder weniger tot. Ich hatte damit in meinen Studienzeiten auch angefangen, aber man flucht halt im Entwicklerleben zwar alle zwei Tage einmal über Eclipse und bei IntelliJ reduziert sich das vielleicht alle zwei Wochen einmal. 40:24.080 --> 40:29.060 stehen auch wir vor der Entscheidung mittlerweile, wie geht es weiter. 40:29.160 --> 40:33.200 Wir kriegen immer mehr Plug-in-Probleme, wir kriegen also wirklich Stabilitätsprobleme mit Eclipse. 40:34.260 --> 40:38.120 Es ist ja kein Geheimnis, Herr Goik und ich und andere diskutieren ja auch schon, 40:39.000 --> 40:42.800 ob wir nicht jetzt generell umsteigen, zum Beispiel auf IntelliJ für den Studiengang, 40:42.900 --> 40:44.960 weil wir eben weiter mit Java machen. 40:45.340 --> 40:47.820 Also das sind so Sachen, wenn Sie sich da beteiligen wollen übrigens, 40:47.820 --> 40:50.940 Input liefern, Meinungen, einfach auf mich zukommen. 40:51.320 --> 40:53.160 Ich bin froh um jedes Ding. 40:53.160 --> 40:57.860 Wir haben nächste Woche Stammtisch, da gibt es die super Gelegenheit, das Thema mal aufzunehmen. 40:58.140 --> 41:00.600 Würde mich sehr interessieren, was der Studiengang dazu meint. 41:00.800 --> 41:05.620 Wir haben es halt einfach mal jetzt mal praktisch gesehen, dass wir einfach schon Stabilitätsprobleme haben damit. 41:06.060 --> 41:08.220 Und immer wieder Kompatibilitätsprobleme. 41:08.480 --> 41:11.900 Und insofern bin ich für Input in der Richtung dankbar. 41:14.300 --> 41:19.200 Tja, ich glaube, es ist Zeit für ein großes Dankeschön für den schönen Vortrag. 41:23.160 --> 41:31.480 Und das hat, ja, wie gesagt, ich war sehr neugierig, nachdem Josh Long ja hier ein paar Mal Kotlin vor zwei Wochen erwähnt hatte. 41:31.960 --> 41:34.380 Und jetzt habe ich es gesehen. Sehr interessante Geschichte. 41:35.380 --> 41:38.660 Ich würde vorschlagen, wir machen eine ganz kurze Kaffeepause und dann...