Cześć! Mój dzisiejszy gość to doświadczony programista, autor książek „Effective Kotlin”, „JavaScript od Podstaw” oraz współautor „Android Development with Kotlin”. Założyciel Kt. Academy, programuje od dziecka, występuje na Międzynarodowych Konferencjach Programistycznych, posiada w dorobku liczne publikacje, m.in. w magazynie Programista. 

Pasjonat czytania, pisania książek, uczenia się i filozofii. Moim i Waszym gościem jest Marcin Moskała. 

Cześć, Marcin! Bardzo miło mi gościć Cię w podcaście. 

 

Cześć Krzyśku, miło mi być tutaj z Tobą!

 

Marcin, o Tobie najwięcej słyszy się w kontekście JavaScriptu i książki, którą w tym temacie napisałeś. Dziś jednak będę chciał porozmawiać z Tobą o czymś, o czym zresztą już i tak kilka książek popełniłeś. Mianowicie – o języku programowania Kotlin. 

Zanim jednak do tego przejdziemy, to zapytam Cię, jak każdego gościa, czy słuchasz podcastów- jeśli tak to może masz jakieś swoje ulubione. 

 

Wiesz co, nie jestem podcastową osobą, nie słucham podcastów, natomiast bardzo lubię raczej słuchać kursów, prezentacji konferencyjnych, prezentacje znajduję najczęściej na YouTube, natomiast kursy na takich portalach jak Coursera, czasem też na YouTube. EdX, bardziej lub mniej akademickie kursy, często potrafią naprawdę dobrą jakość dostarczyć. A czasem też z innych źródeł kursy zakupione. 

I lubię też słuchać, jeśli o słuchanie chodzi, audiobooków. Choć nie wszystkie się do tego nadają. Nie raz, jak idę pobiegać sobie albo idę na siłownię, to wrzucam jakiś audiobook na słuchawki. 

 

Jasne. Potwierdzam, potwierdzam. Świetnie. To może tak historycznie spróbujmy temat Kotlina potraktować i podejść najpierw do tego, skąd ten język się wziął, kto go stworzył, na jaki problem odpowiada. Gdybyś mógł trochę na temat kulis powstania języka Kotlin odpowiedzieć. 

 

Zdaje się, że Kotlin zaczął powstawać w 2010 roku, co zaskakuje wiele osób, bo to już jest 11-latek. A sporo myśli, że to zupełny młodziak. Wbrew pozorom Kotlin jest dużo starszy od wielu innych języków, które współcześnie się stresuje, np. Swift jest dużo młodszy. Zresztą, wiele rzeczy sugeruje, że Swift wzorował się pod wieloma względami na Kotlinie. 

Kotlin został stworzony przez JetBrains. Z tego co wiem, to JetBrains, jako twórca różnych języków programistycznych bardzo się borykało z problemem, że jest tak dużo różnorodnych języków programowania. One wymagają swoich parserów i gdzieś tam uświadomili sobie, że zarówno mają wiedzę na temat tego, jak i te języki działają, w jaki sposób się z nimi pracuje, jakie mają narzędzia do tego, aby zrobić z tym coś ciekawego. I ponoć była też motywacja, którą nie do końca rozumiem – że chcieli zrobić jeden język, który będzie taki meta językiem, który połączy, zjednoczy inne języki.

 

Kotlin został stworzony przez JetBrains. Z tego co wiem, to JetBrains, jako twórca różnych języków programistycznych bardzo się borykało z problemem, że jest tak dużo różnorodnych języków programowania. One wymagają swoich parserów i gdzieś tam uświadomili sobie, że zarówno mają wiedzę na temat tego, jak i te języki działają, w jaki sposób się z nimi pracuje, jakie mają narzędzia do tego, aby zrobić z tym coś ciekawego. I ponoć była też motywacja, którą nie do końca rozumiem – że chcieli zrobić jeden język, który będzie taki meta językiem, który połączy, zjednoczy inne języki. 

Nie do końca to czuję, bo mam wrażenie, że to jest trochę jak ten stary komiks z żartem, że mamy problem, jest 10 różnych standardów i co mamy z tym zrobić? I ktoś mówi: mam pomysł! Zróbmy 11 standard, który połączy je wszystkie. I następna scena: mamy problem, jest 11 różnych standardów i co mamy z tym zrobić? 

Wydaje mi się, że to bardziej taki był chwyt marketingowy, natomiast fakt jest faktem, że JetBrains miał narzędzia, miał wiedzę i zrobił bardzo dobrą rzecz. Zamiast brać osoby, która się na tworzeniu języka nie znały, poszedł na uczelnię i znaleźli tam Andrey’a Breslava który był akademikiem, zajmującym się konstrukcją języków. Zdaje się, że najpierw odmówił, natomiast potem jednak zgodził się na stworzenie tego języka. Przez kilka lat działał niemalże sam przy wsparciu reszty firmy. I w tym czasie ten język się bardzo zmieniał. Wiele osób nie wie jak bardzo! 

Do Kotlina weszły takie funkcjonalności jak Tuple, potem wyszły, takie jak wielokrotne dziedziczenie, potem wyszła. Różne funkcjonalności tam wchodziły i wychodziły na przestrzeni rozwoju Kotlina, natomiast na koniec ugruntował się jako, powiedzmy, że, lepsza wersja Javy. Mam wrażenie, że Kotlin w tym, na czym stanął, czyli w tym, do czego doszedł w 2016 roku, czyli w momencie, kiedy została oddana pierwsza, stabilna wersja na początku roku – mam wrażenie, że w tym momencie był traktowany przez większość osób jako lepszą Javę, jako to, czym stałaby się Java, gdyby zamiast stanąć w miejscu na wiele lat, gdyby cały czas się rozwijała i podążała za trendami. Zresztą, bardzo zainspirował ten język Javę, bo widać, że od ostatnich kilku lat Java poczuła ten oddech na karku i się zaczęła bardzo szybko rozwijać. I można bardzo wyraźnie dostrzec, że funkcjonalności, które są wprowadzane do Javy, są spóźnionymi funkcjonalnościami, często ograniczonymi, bo ze względu na wsteczną kompatybilność i cały ciężar tej platformy, ale spóźnionymi funkcjonalnościami, które w języku Kotlin już od dawna są. 

To był trochę Kotlin. To była lepsza Java w 2016 roku. Ale na tym się historia Kotlina nie skończyła, bo Kotlin poszedł w trzy, moim zdaniem, najistotniejsze gałęzie. Pierwszą, najistotniejszą gałęzią jest to, o czym teraz piszę książkę. To jest moja kolejna książka – „Kotlin Coroutines Deep Dive”, bardzo zgłębiam temat kotlinowych korutyn. 

Rzeczywiście to, w jaki sposób Kotlin rozwiązał problem Korutyn jest niesamowite. Wprowadził system – nie chodzi tylko o wielowątkowość, bo wielowątkowość to jest tylko peak of an iceberg. Chodzi o potężny model współbieżności, który był wyczekiwany i zapowiadany od lat 70. czy może nawet po części 60., już papery naukowe były pisane o hipotetycznych korutynach gdzieś tam w jakimś Lispie było to opisywane, ale wciąż to było bardzo ograniczone i nie było takie production ready. 

I gdzieś Go, wprowadziło swoje go rutyny. Też bardzo okrojone. Ale gdzieś to jeszcze nie było to. I moim zdaniem naprawdę Kotlin zrobił potężna robotę, bo przy zrobieniu bardzo solidnych kortyn, które jednocześnie są proste w użyciu i rozpinają najistotniejsze use case’y w idealny sposób. Jest to jedna taka fajna, bardzo istotna noga. 

Druga noga jest taka, że Kotlin jest w tym momencie językiem multiplatformowym. Kotlin już nie tylko kompiluje się do JVM-a, tak jak Java, czyli nie tylko chodzi na platformie JVM, ale również Kotlin jest kompilowany do JavaScriptu oraz do kodu natywnego. DLVM-a konkretnie, przez co do dowolnego typu urządzenia. Można pisać w Kotlinie programy na iPhone’a, Maca, na cokolwiek. Na PlayStation, na Raspberry Pi. Cokolwiek! 

I co więcej, można w czystym Kotlinie pisać części wspólne, co znaczy, że jeżeli jesteś twórcą biblioteki, którą chcesz wydać na ileś tam platform, to możesz napisać jedną bibliotekę raz i tylko zapewnić jakieś takie platform specific elementy i masz tę bibliotekę dostępną na JavaScripta, JVM-a, na różne urządzenia, na Pythona, na Rasta i wszędzie jest to natywnie. Wszędzie jest to optymalnie dla danej platformy. Co jest potężną rzeczą, niesamowitą. To jest rzecz, którą C-Sharp próbował zrobić, choć w C-Sharpie jest to na odwrót. Ale już może nie wchodźmy w C-Sharpa, powiedzmy, że już parę różnych technologii próbowało to zrobić. 

I rzeczywiście tutaj też moim zdaniem – jeżeli to jest przyszłość, jeżeli rzeczywiście to jest ten kierunek, że chcemy mieć języki wieloplatformowe, a nie jeden język na wielu platformach, bo to są dwa różne podejścia. To jeżeli tak, to w tym momencie to, co oferuje Kotlin, jest z tego, co wiem najlepszy na rynku. 

A trzecią taką gałęzią Kotlina – to może nie do końca gałąź, ale bardziej taką przyszłością Kotlina jest to, że nie pozwolił sobie na pozostanie w miejscu. Kotlin wprowadził mechanizm – bo tak jak największymi kajdanami Javy i wielu języków Pythona i wielu innych języków, jest też taka kompatybilność. Od samego początku, Kotlin, widać, że był bardzo mocno tworzony z myślą o tym, żeby się tym kajdanom nie dać zniewolić. I od razu były opisane wszystkie rzeczy tak, że na przykład wszystkie funkcje praktycznie z biblioteki standardowej, nie zwracają konkretnych obiektów, tylko zwracają interfejsy. Co czujesz – jest już bardzo uwalniające, bo można podmieniać te konkretne obiekty. A poza tym, sprawiło to, że bardzo łatwo było wprowadzić wieloplatformowość do tego, bo różne obiekty na różnych platformach. Tak długo, jak długo implementują ten sam interfejs wszystko jest w porządku. Natomiast to zostało dużo bardziej pchnięte w wersji 1.31.4, gdzie został wprowadzony pełen system deprykacji oraz testowania nowych ficzerów. 

Jest utworzony system – jeżeli chcą wprowadzić zmiany do języka, to konkretnie. Najpierw ta zmiana jest deprykowana, deplicated, z automatyczną migracją. Że ty możesz samemu to przemigrować, ale też jest wbudowana. Automatyczna migracja w InelliJ-a, nowe funkcjonalności są najpierw oznaczane jako experimental i to wszystko tworzy już taki cykl nie tylko dodawania do języka, ale także zmieniania w języku. Co jest bardzo ważną rzeczą długofalową. 

A drugą ważną rzeczą długofalową, która w tym momencie nie jest jeszcze mocno eksplorowana, chociaż już gdzieś się zaczyna pojawiać, jest tzw. plug-iny do kompilatora. To chodzi o to, że w zasadzie, jeśli brakuje ci jakiejś funkcjonalności w Kotlinie, to jesteś w stanie sobie go samemu napisać i ją dodać jako plug-in. 

 

A drugą ważną rzeczą długofalową, która w tym momencie nie jest jeszcze mocno eksplorowana, chociaż już gdzieś się zaczyna pojawiać, jest tzw. plug-iny do kompilatora. To chodzi o to, że w zasadzie, jeśli brakuje ci jakiejś funkcjonalności w Kotlinie, to jesteś w stanie sobie go samemu napisać i ją dodać jako plug-in. 

 

To jest jeszcze nieudokumentowane, umyślnie – bo twórcy nie chcą tego udostępniać do szerokiej publiki, raczej do twórców bibliotek, z którymi współpracują. Ale już są np. takie środowiska jak Arrow, które tworzy programowanie funkcyjne w Kotlinie i rzeczywiście dodaje własne funkcjonalności do języka, których tam po prostu nie ma i to właśnie działa przy pomocy tego mechanizmu. 

Albo jet pack compose, czyli taka bardzo popularna teraz biblioteka do tworzenia widoków w androidzie, nie tylko w Androidzie – to też jest wieloplatformowa. Można stworzyć widok raz i ten sam widok chodzi tam na front endzie, back endzie, desktopie, wszędzie. Ona również w dużym stopniu wykorzystuje te plug-iny do lepszego zapisu. 

 

Rozumiem. Taka duża plastyczność, mam wrażenie, z tego, co mówisz, wynika z tego języka, ale też ekosystemu. Tak jak mówiłeś, opowiadałeś o historii, to mam wrażenie, że z jednej strony chciano zrobić coś lepiej niż poprzednicy, a z drugiej strony ten język i ekosystem się też, tak mocno nie odcina od całego dorobku w związku z rozwojem języków programowania i też mocno wzoruje się na innych rozwiązaniach. 

Co zresztą wcale mnie nie dziwi, bo obecnie wszystkie te języki programowania, niezależnie które by wziąć, to w dużej mierze gdzieś czerpią z podobnych wzorców, wzajemnie się inspirują. To zresztą też jest pewnie siłą napędową przyspieszonego rozwoju. Może ten oddech, który Java poczuła na karku właśnie powoduje, że ten rozwój miał miejsce. 

Pomyślałem sobie, jak opowiadałeś o tym systemie współbieżności, że to jest jedna z takich ważniejszych obecnie rzeczy, bo mamy procesory, które są wielo corowe, wiele rzeczy może się dać równocześnie, a też nie wszystkie języki w pełni z tego korzystają i tak jak kiedyś, pamiętam taką ankietę, jak badano która część albo jaki typ programowania dla developerów jest najtrudniejsza, a to wszyscy mówili o tym programowaniu współbieżnym, bo to rodzi dodatkowe problemy, ale myślę sobie, że rodzi jest dlatego, że język daje takie, a nie inne mechanizmy, żeby sobie z nimi radzić. 

To tak tytułem skomentowania tego, co powiedziałeś – na końcu mówiłeś o trzech gałęziach, gdzie Kotlin najmocniej się rozwija albo w Twojej opinii to są te gałęzie, które mogą świadczyć o jakimś sukcesie czy mogą przyspieszać ten sukces. Chciałbym Cię zapytać o takie produkcyjne rozwiązania, stosowane faktycznie w rzeczywistych projektach. O takie miejsca, gdzie się Kotlin obecnie wykorzystuje. 

Android jest oczywiście najbardziej flagowym przykładem, ale może będziesz w stanie powiedzieć jeszcze o innych zastosowaniach pertucyjnych języka Kotlin. 

 

Wbrew pozorom Kotlin należy do grupy najczęściej wykorzystywanych języków produkcyjnie w Polsce. w dużym stopniu ze względu na Androida rzeczywiście. W tym momencie podejście twórców Androida jest takie, że wszystkie nowe programy powinny powstawać w Kotlinie, wszystkie stare powstałe programy powinny wykorzystywać Kotlina. W mniejszym lub większym stopniu. Wszystkie biblioteki androidowe są projektowane Kotlin first, czyli jest atmosfera, która sprawia, że bardzo niewiele pozostaje różnych projektów, które są napisane w Javie. Większość z nich albo się przeniosła, albo się przenosi na Kotlina. 

 

Wszystkie biblioteki androidowe są projektowane Kotlin first, czyli jest atmosfera, która sprawia, że bardzo niewiele pozostaje różnych projektów, które są napisane w Javie. Większość z nich albo się przeniosła, albo się przenosi na Kotlina.

 

W dodatku nowe narzędzia androidowe, np. ten Jetpack Compose , który jest wymyślany jako przyszłość tworzenia widoków w Androidzie, on wymaga Kotlina. To nie jest tak, że można to zrobić w Javie. Znaczy – można się uprzeć, ale to nie ma sensu. To praktycznie trzeba zrobić, to trzeba robić w Kotlinie, żeby to miało sens. 

Android – a to jest duża część rynku. Android developerów jest całkiem niemało. Ale wciąż największa część rynku to są back end developerzy. I to też jest taki paradoks, bo z jednej strony w Androidzie ten Kotlin ma dominację, a jednocześnie w back endzie ten Kotlin wydaje się wciąż niszowy, choć nie jest do końca. Ale przez dysproporcję, że jest dużo więcej back end developerów, niż Android developerów, w większości konferencji, spotkać kotlinowych itd., mniej więcej statystyki pokazują, że 50% to są androidowcy, 50% to są backendowcy. 

Można sobie wyobrazić, że tych backendowców tworzących w Kotlinie jest dosyć sporo. Nie ma w tym nic dziwnego. Spring bardzo mocno popiera Kotlina. Jest tam Sébastien Deleuze, który bardzo mocno go pushuje. 

Powstaje dużo bibliotek w Springu. Spring robi wsparcie zresztą dla tych funkcji suspendujących, czyli dla korutyn kotlinowych, też ma natywne wsparcie od jednej z ostatnich wersji. I bardzo dużo firm przenosi się na Kotlina albo już przeniosło. 

Takim flagowym przykładem jest Allegro, w którym pracuję, gdzie większość nowo powstałego kodu back endowego. Jeśli stanowcza większość – szczerze mówiąc też nie mam statystyk, no bo wiadomo, jak tam jest z 1000 programistów, to się widzi tylko swoje otoczenie, natomiast od osób, które wprowadzały u nas onboarding i miały trochę szersza perspektywę na ten temat, słyszałem, że większość powstałego kodu w Allegro powstaje w Kotlinie. 

Jest to wspierane, fajne, lubiane, ludzie po prostu bardzo lubią Kotlina, więc czemu nie. 

 

Pewnie, pewnie. Okej – język to jak gdyby jedna rzecz, natomiast potrzebujemy jeszcze tego całego ekosystemu, toolingu, aby tworzyć jakieś produkcyjne rozwiązania. I teraz właśnie chciałbym cię zapytać o cały ten tooling wokoło Kotlina. 

Tutaj myślę dosyć szeroko – w bibliotekach, frameworkach, IDE, jakie narzędzia, z czego programista może korzystać w przypadku Kotlina? 

 

Można się domyślić, że skoro Kotlin został stworzony przez JetBrains, który to jest twórcą najbardziej popularnych narzędzi, no to ma tutaj bardzo dobre wsparcie, ale nie tylko. JetBrains się od początku starał, żeby nie mieć na to dominacji. I Kotlin to bardzo wspiera – z tego, co wiem, jest jedynym językiem, jaki znam, który nie musi być analizowany przez środowisko, ponieważ plug-in jako taki ma swoje API dla środowiska. 

Jest to dosyć oczywiste – wyobraź sobie, że tworzysz jednocześnie język programowania i tworzysz narzędzie do programowania w tym języku. Jest to chyba oczywiste, że zamiast tworzyć osobno jedno, osobno drugie, no to sobie tak zrobisz ten kompilator tego języka, żeby ten kompilator zarówno potrafił zarówno skompilować kod, jak i odpowiedzieć na pytania dotyczące Twojego IDE. Ale to jest ogromne uproszczenie dla wszystkich twórców narzędzi, ponieważ tam IntelliJ nie musi samemu się domyśleć, jak tam ten kod kotlinowy działa, no bo pyta się o to kompilatora. 

Ale tak samo Eclipse czy inne narzędzia nie muszą się tego domyślać same, tylko się pytają kompilatora. 

Szczerze mówiąc nie wiem, jaki jest w tym momencie status Eclipse’a i innych narzędzi. Przypuszczam, że są inne narzędzia, w których można tworzyć, ale  standardem jest jednak IntelliJ, ma bardzo dobre wsparcie. Kotlin jest oczkiem w głowie InteliiJ-a, więc bardzo dużo idzie tam wysiłku w to wszystko. 

Wiele projektów powstaje w InntelliJ-u w Kotlinie, więc wsparcie tutaj jest bardzo dobre. Jeśli chodzi o biblioteki, to także cała masa bibliotek powstała przez Jetbrains, natomiast cała masa ludzi stworzyła też środowisko. Kotlin cieszył się bardzo dużym hype’em, zwłaszcza w Androidzie. I ten hype sprawiał, że bardzo wiele bibliotek chętnie wprowadzało wsparcie dla Kotlina po to, żeby na ten hype się załapać. Albo dlatego po prostu popierali ten język – tak jak np. – nie wiem, jak bardzo jesteś zaznajomiony ze środowiskiem Androidowym, natomiast bardzo duży wpływ na środowisko androidowe ma taka firma Square, taka amerykańska, natomiast oni robią bardzo dobre biblioteki. Kupa bibliotek – m.in. Retrofit czy Dagger, oryginalnie była tworzona w dużym stopniu przez takiego bardzo znanego celebrytę androidowego, Jake’a Whartona, który był znany z tych bibliotek, znany z tego, że miał bardzo dobre wyczucie jakie biblioteki są potrzebne, a potem potrafił je bardzo dobrze zaimplementować i zrobić do nich dobre API. 

Jake Wharton był jedną z osób, które jako pierwsze w środowisku androidowym mocno poparła Kotlina. stworzył taki dokument, który rozszedł się viralowo w środowisku i cała masa osób, jak się pyta skąd dowiedzieli się o Kotlinie, to cała masa osób właśnie mówi, że z tego dokumentu. Nic dziwnego, że te wszystkie biblioteki bardzo szybko wprowadziły wsparcie dla funkcji suspendujących i dla Kotlina. W większości wsparcie nie było potrzebne, ale dodatkowe, aby jeszcze lepiej Kotlin z nimi współpracował. I środowisko też bardzo pomagało. 

 

Tak, to jest niezbędny element. Dobrze, a pomyślmy czy też zaproponujmy słuchaczom taki eksperyment, żeby spróbować swoją przygodę z Kotlinem -nawet na swoim komputerze ruszyć. Od czego powinni zacząć? Co pobrać, co zainstalować, żeby zacząć nawet ten Hello World stworzyć sobie? 

 

Powiem, że jest wiele fajnych sposobów na to, by rozpocząć. Natomiast jeżeli osobie, której bezpośrednio nie mogę pomóc miałbym coś zasugerować, to bym zasugerował, żeby wpisać sobie w internet Kotlin Koaans. Koansy to jest takie pojęcie w programowaniu mówiące o krótkich wyzwaniach programistycznych. 

I tam w dokumentacji Kotlina łatwo znajdziecie tę stronę Kotlin Koans. Można je wykonywać albo w internecie, albo w IntelliJ Edu Tools. To są wyzwania programistyczne skierowane już – zakładam, że mówimy o osobie, która jest programistą/programistką, która chce się nauczyć nowego języka, więc zakładając taką sytuację, te Koansy powinny być odpowiednie, bo one przeprowadzają cię przez kolejne wyzwania, ale najpierw wprowadzają teorię i potem jeszcze nie zostawiają cię na lodzie, dają ci jakieś tam podpowiedzi i ewentualnie odpowiedź. 

Pobawienie się z tymi wyzwaniami programistycznymi jest chyba bardzo fajnym sposobem na start. Są też oczywiście książki, kursy. Jest bardzo dobry kurs na Courserze, coursera.org, który jest stworzony przez Andrey’a Breslava, czyli twórcę Kotlina oraz Svetlany Isakovej, która m.in. stworzyła Kotlin Koans, jest bardzo znaną ewangelistką Kotlina, zatrudnioną przez JetBrains. 

Oni właśnie stworzyli razem kurs – nie pamiętam, jak się dokładnie nazywał, ale też jest bardzo dobry jakościowo. 

 

Super, dzięki za te materiały. A jeśli mógłbyś porównać Kotlin, jego otoczenie do jakichś innych, dostępnych języków, innych dostępnych technologii, to jest coś, co według Ciebie leży blisko Kotlina? Jest podobne? Czy też różnice są na tyle duże, że ciężko znaleźć podobne rozwiązania?

 

Podobnym rozwiązaniem na pewno jest Swift. Kotlin nigdy tego nie powiedział jawnie, nie wiem ze względu na co, ale moim zdaniem Swift się mocno wzorował na Kotlinie. To wydaje się być widoczne w języku, z drugiej strony Kotlin jest podobny do Scali, bo Kotlin się wzorował na Scali. To akurat Kotlin się do tego przyznawał bardzo dużo. W pewnym momencie przestał, może właśnie dlatego, bo zaczął się robić konkurencją i zaczęła się robić konkurencja między tymi dwoma językami, ale fakt jest faktem, że Kotlin wzorował się na Scali, natomiast bardzo mocno ją ucinał. 

Scala jest strasznie, strasznie potężnym językiem, ciężkim, długo kompilujacym się, dającym ogormne możliwości, a ogromne możliwości to jest też duża odpowiedzialność, której wiele programistów scalowych nie dźwiga, bo często projekty scalowe kończ się po prostu przerostem. 

Oczywiście, to zależy od projektu, ale bardzo powszechnym podejściem wśród speakerów, programistów jest to, że problemem Scali jest to, że daje za dużo możliwości, a ludzie z nich nie potrafią korzystać. Stosują nadmiar jakichś operatorów, jakichś magii itd co jest fajne, jak się ten kod pisze, bo jest krótki, piękny, zgrabny i w ogóle jak jakiś wiersz wygląda albo jak jakieś wzory matematyczne, ale jak ktoś, kto nie jest tak doświadczony się za to zabiera, to się po prostu łapie za głowę i nie jest w stanie nic zrozumieć. 

Pod tym kątem Kotlin jest dużo lepszy. Że Kotlin jednak bardzo, bardzo ukrócił, sprecyzował przypadki użycia i nie popłynął tak bardzo jak Scala. 

 

Rozumiem, rozumiem. Mówiłeś na początku o historii, o tym, jak ten język, jak ten ekosystem powstawał. Kto się do tego przyczyniał, jakie było to całe otoczenie powstawania.

Chciałbym ten temat trochę pociągnąć i zapytać Cię jak obecnie ten ekosystem się rozwija, jak wygląda community. Gdybyś mógł zdradzić taki obecny stan rozwoju Kotlina. 

 

Wiesz, w moim odczuciu – ja bardzo lubiłem community kotlinowe, dopóki nie osiągnęliśmy wersji 1.0. Było naprawdę hipsterskie, fajne, otwarte, wszyscy się lubili, wspierali, w ogóle super. Pamiętam, jak ogłaszali, że Kotlin – nie chodzi o wersję 1.0, chodzi o to, co było niedługo później. Jak Google ogłosiło to, że Kotlin staje się językiem programowania Androida, pamiętam, że siedziałem wtedy ze znajomym. Powiedziałem: „Wow! Otwieramy szampana!”, a on mówi: „Eh, właśnie przestaliśmy być hipsterami”. 

 

Jak Google ogłosiło to, że Kotlin staje się językiem programowania Androida, pamiętam, że siedziałem wtedy ze znajomym. Powiedziałem: „Wow! Otwieramy szampana!”, a on mówi: „Eh, właśnie przestaliśmy być hipsterami”. 

 

Znajomy był trochę bardziej doświadczony ode mnie, nie wiedziałem, o co mu wtedy chodzi, on się niedługo przeniósł w ogóle na blockchain, przestał się interesować Kotlinem. Dopiero po latach zrozumiałem, o co mu wtedy chodziło – że nagły przypływ ludzi z zupełnie innym podejściem sprawił, że to wszystko przestało być takie fajne. W sensie – oczywiście z punktu widzenia biznesowego, więcej osób korzysta, więcej jest tooli, narzędzi, więcej lekcji, więcej osób, które ci z tym pomogą, więc Kotlin stał się dużo bardziej praktycznym językiem pod kątem biznesowym, ale pod kątem takiego community, powiedzmy, że stał się trochę mniej ciekawym i zabawnym światem. 

W tym momencie gdzieś tam na przestrzeni tych lat przechodziliśmy przez tę ścieżkę, gdzie najpierw obserwowałem jak ludzie robią szalone rzeczy na ogromny napływ ludzi, którzy przechodzą z zupełnie innych języków i przerzucają swoje praktyki. Czasem dowiadują się o jakichś ficzerach i wykorzystują je w jakiś zupełnie dziwny sposób, doprowadził do tego, że gdzieś zaczęliśmy mówić o dobrych praktykach, o formatowaniu, o różnych takich rzeczach, więc gdzieś tam zacząłem się w tym udzielać. Napisałem „Effective Kotlin”, żeby tam też trochę to uporządkować. „Effective Kotlin” jest bardzo fajnie odebrane, co mnie cieszy, ale też po tym czasie mam wrażenie, że w „Effective Kotlin” napisałem wszystko, co miałem napisać i też stwierdziłem, że już nie czuję potrzeby, żeby z tym walczyć. Wszystko już napisałem. Gdzie tam poczułem wtedy, że chcę szerzej z tym wszystkim pójść, dlatego też poszedłem do Allegro, zacząłem wykorzystywać Kotlina w sposób, w jaki do tej pory go nie wykorzystywałem. Zacząłem też wykorzystywać inne języki w Allegro, odkryłem, w Allegro dobrze poznałem, tam, gdzie ja pracuję, to wykorzystywałem codziennie niemalże kilka różnych języków. 

Tutaj w Java i Kotlin na back endzie, jakieś testy w Groovim, co rusz jakieś skrypty tu i ów w Scali, w Javie, w Pythonie. Naprawdę – dużo, dużo różnych języków każdego dnia, skrypty MongoDB, skrypty do różnych innych baz danych, co też bardzo tworzyło moją głowę. Też m.in. dlatego wtedy, kiedy zrobiła się pandemia i zastanawiałem się, co zrobić, aby troszkę ludziom pomóc, to zdecydowałem się na książkę o Javascripcie, a nie kolejną o Kotlinie. 

 

Jasne to jest też pytanie, czy takiej ewolucji czy takim zmianom da się w ogóle w jakiś sposób przeciwdziałać? Myślę, że nie, bo to po prostu zawsze tak działa, że na początku jest tam grupa pasjonatów, którzy są faktycznie tym tematem zajawieni, później ten napływ osób, które niekoniecznie muszą być tak oddane językom, natomiast chcą go wykorzystywać po prostu praktycznie, w aplikacjach i ja doskonale wiem, o czym mówisz, bo ja miałem podobnie z Ruby – gdzie też na początku był to mocno hipsterski język, później już wiadomo, jak to bywa. W momencie, kiedy wielkie firmy, duże projekty się pojawiły, to inaczej już i community, i sam rozwój języka wyglądał. To jest chyba nie do uniknięcia w każdym przypadku. 

 

Warto tutaj zwrócić uwagę, bo to są jak takie fale, jak zauważyłeś. Nienaturalna fala. Oczywiście nie wszystkie fale – wiele fali się na pewnym stopniu załamuje i na przykład pamiętam, że dawno, dawno temu jeszcze jak Kotlin był bardzo młody, jeszcze z rok, zanim w ogóle zacząłem z niego skorzystać, a z dwa przynajmniej lata, zanim wyszedł z bety, to był 2014 rok, to właśnie myślałem nad tym, czym się zainteresować i myślałem właśnie o Kotlinie. Już się uczyłem Kotliny, jeszcze nie wykorzystywałem go na produkcji, już się go uczyłem i myślałem jeszcze o drugiej rzeczy, to była taka technologia Robo VM, która była takim pierwszym podejściem do multiplatformowej rzeczy. 

Wiesz, co się z nią stało? Microsoft ją kupił i ubił, ponieważ zagrażała jego Xamarinowi.

Bardzo wiele fal się rozwija na którymś momencie i nigdy nie dociera. Są jeszcze takie community, co przez dziesiątki lat są cały czas pełne pasjonatów i nigdy nic nie wygląda na to, żeby kiedykolwiek się spopularyzowały. Trochę Haskell taki jest. Wciąż jest w grupach wiecznych fanów programowania funkcyjnego itd. Ale nie wygląda na to, żeby kiedyś Haskell zrobił się prawdziwym, popularnym, mainstreamowym językiem. I nie wiem, czy te osoby chciałyby tego, natomiast warto się zastanowić nad motywami. Czego my tak naprawdę szukamy? Bo ostatnio taka dziewczyna – udzielam się w takiej inicjatywie Woman Developer Academy, gdzie daję konsultację, pomagam – dostałem jedną osobę, która konsultuje ze mną swoje artykuły i rozwój. Jako mówca, twórca treści programistycznych i tak dalej. 

I właśnie pytała się mnie o te fale. Mówię, że wszystko zależy, od tego, czego chcesz. I w jej przypadku jakby wypłynąć na tym, żeby gdzieś tam znaleźć tę rozpoznawalność i tak dalej. To wtedy trzeba poszukać takiej fali, która rzeczywiście wzbija się wysoko. I to jest bardzo fajna fala. Wtedy Kotlin taki był, teraz już Kotlin taką falą nie jest, bo jest tą falą stabilną, pełną ludzi. 

Natomiast są też osoby, które tak jak właśnie kolega, z którym wtedy rozmawiałem, które właśnie chcą sobie pływać na falach wznoszących się i przeskakują między językiem a językiem, które są cool i trendy. Nie zarobią na tym pieniędzy, bo to zawsze będzie niszowe i będą zarabiały dużo mniej niż by mogły. Ale będą miały wspaniałą przyjemność życia wśród pasjonatów, którzy robią coś, w co wierzą. 

 

Właśnie. Mam wrażenie, że jesteśmy szczęściarzami, że mamy taką możliwość, żeby sobie zmieniać te fale, jeśli czujemy taką potrzebę. Bo tak jak powiedziałeś – nie każdemu to odpowiada, nie dla każdego to jest historia. 

Okej – powiedziałeś o Haskellu, Haskell bardzo mocno kojarzony jest, bo jest właściwie oprogramowaniem funkcyjnym. 

Kotlin – jak Wikipedia go określa, to język wieloparadygmatowy. Przy czym oczywiście dominujący jest ten paradygmat obiektowy, najbardziej z nim kojarzony, ale jak sobie przeglądałem tak dokumentację, bardzo pobieżnie, to widziałem, że są też tam możliwości, jakieś odniesienia do programowania funkcyjnego. Zresztą, to też, tak jak w innych, popularnych językach, które się obecnie rozwijają, które godzą powiedzmy te różne światy. 

Natomiast to, że coś istnieje w języku, to nie znaczy, że jest później podchwytywanie przez developerów. Nie znaczy, że jest wykorzystywane w produkcyjnych aplikacjach. Czy w Twojej opinii czy z Twojej wiedzy wynika, że faktycznie oprogramowanie funkcyjne jakoś w tych większych aplikacjach się wykorzystuje, czy też jest to raczej ciekawostka z języka?

 

Wszystko zależy co masz na myśli przez pojęcie „programowanie funkcyjne”, bo ja znam przynajmniej trzy różne definicje i podejścia do tego. Pierwszą z nich jest funkcjonalności takie jak typy funkcyjne, funkcje Lambda itd. 

To tak – to jest bardzo silne, rozwinięte, wygodne i w ogóle super w Kotlinie. W Kotlinie bardzo powszechnie wykorzystuje się przetwarzania kolekcji, przetwarzania przy użyciu funkcji Lambda, co bardzo często też się wykorzystuje podejście funkcyjne nawet dla pojedynczych obiektów, żeby robić takie flow dla obiektów przy pomocy takich rzeczy jak let, który jest takim mapowaniem dla pojedynczego obiektu albo also, który jest takim on each dla pojedynczego obiektu. 

Jest tutaj bardzo dużo narzędzi i są one wykorzystywane. Z mojego doświadczenia, bardzo, bardzo powszechnie. Z drugiej strony wiele osób mówi o takich trochę bardziej hardcorowych pojęciach funkcyjnych i tutaj nie – Kotlin nie ma na przykład takich rzeczy jak currying , nie ma jakichś specjalnych, wbudowanych narzędzi do łączenia ze sobą funkcji. To oprogramowanie funkcyjne jest często wykorzystywane, ale jednak na płytkim poziomie. Aczkolwiek tak jak wspomniałem – są biblioteki, które to zmieniają. Arrow tutaj jest takim w sumie największym graczem, który rzeczywiście dodaje bardzo dużo narzędzi i tutaj już się osoby bawią w takie bardzo mocno funkcyjne podejście, natomiast testowaliśmy to. W moim odczuciu jest to umiarkowanie produkcyjnie sensowne, racjonalne. Chociaż fakt jest faktem, że współczesne zarówno aplikacje front endowe, jak i back endowe, ogólnie, bardzo mocno odeszły od typowych wzorców obiektowych.

Dochodzimy do trzeciej rzeczy – o myśleniu funkcyjnym. Jest to ciekawy temat, o którym mam rozgrzebany artykuł. Najpierw myślałem, że go napiszę na szybko, potem mi się zaczął tak rozrastać, że w tym momencie tego całego bałaganu nie jestem w stanie ogarnąć. Filozofia myślenia funkcyjnego jest bardzo rozbudowana. I tak naprawdę sięga jeszcze starożytnych czasów. Można by powiedzieć, że współczesna nauka jest zbudowana na myśleniu obiektowym, bo postrzega świat jako zbiór obiektów o pewnych właściwościach. To zdaje się, że od Arystotelesa pochodzi całe takie myślenie o świecie, który właśnie chciał sklasyfikować cechy obiektów i relacje między tymi obiektami. Na przykład mówił „no, mamy takiego psa, on ma takie i takie cechy, ale dlatego, że jest podtypem z typu ogólnie grupy pies, które mają takie i takie cechy, który jest podtypem z takiego i takiego typu, dajmy na to ssak, które mają takie i takie cechy – biorą mleko od matki itd.” – i w ten sposób kategoryzował cały świat. 

 

Filozofia myślenia funkcyjnego jest bardzo rozbudowana. I tak naprawdę sięga jeszcze starożytnych czasów. Można by powiedzieć, że współczesna nauka jest zbudowana na myśleniu obiektowym, bo postrzega świat jako zbiór obiektów o pewnych właściwościach. To zdaje się, że od Arystotelesa pochodzi całe takie myślenie o świecie, który właśnie chciał sklasyfikować cechy obiektów i relacje między tymi obiektami. 

 

I to jest podstawa do myślenia obiektowego. Z drugiej strony jest myślenie, które zostało bardzo zaniedbane przez myślenie funkcyjne. Dostrzega się go znacznie częściej w myśleniu mitologicznym, czyli myśleniu funkcyjnym. 

Wydaje mi się, że bardzo fajną metaforą, która pokazuje różnice między tymi dwoma rzeczami jest pytanie, czym jest sypialnia. 

Czym jest sypialnia?

 

Tak – z jednej strony pomyślałbym o obiekcie, a z drugiej o funkcji spania! 

 

Tak, dokładnie. Z jednej strony więc sypialnię można postrzegać jako zbiór obiektów, czyli sypialnia to jest miejsce, gdzie jest łóżko, lampka, okno, cokolwiek i to łóżko ma swoją funkcję spania i to jest myślenie obiektowe, ale z drugiej strony jest myślenie funkcyjne. Sypialnia nie musi mieć łóżka, nie musi mieć okna, nie musi mieć lampki. 

Sypialnia to jest miejsce, które służy do tego, żeby tam spać. Może to być puste pomieszczenie. Jest sypialnią tak długo, jak długo ludzie przychodzą tam, żeby spać. Sypialnia jest definiowana przez swoje funkcje. 

Zauważ, że myślenie funkcyjne jest dużo ciężej wyrażalne. Ponoć jest tak, że ludzie postępują przede wszystkim funkcyjnie. Czyli myślą funkcyjnie. Ale komunikujemy się przede wszystkim obiektowo. 

Bo dużo łatwiej się mówi o obiektach i ich właściwościach. I teraz zauważ, że dokładnie tak samo postępują współczesne aplikacje. Pomyśl o tym w ten sposób: mamy bazę danych. Baza danych traktuje rzeczy, powiedzmy, że obiektowo. Myśli o zbiorze obiektów. Ale potem mamy aplikację, która zazwyczaj jest zbiorem funkcji, które ta aplikacja pełni. Ale na koniec ta aplikacja wysyła obiekty przez API. I nasze API jest typowo obiektowe. To jest zbiór obiektów. 

Które potem są interpretowane przez jakąś aplikację, która zazwyczaj myśli o tym funkcyjnie, ale na koniec tworzy widoki – a widoki są obiektami. Te warstwy się przeplatają tak samo, jak w naszym życiu. 

Pod tym kątem wydaje mi się, że tutaj rzeczywiście community kotlinowe bardzo mocno poszło w odejście od klasycznych wzorców obiektowych i pójście w stronę funkcyjnych – nie wiem, czy wszyscy się tu ze mną zgodzą, bo trochę filozofuję, ale chodzi mi o to, że na przykład jak myślimy o aplikacjach w back endzie, to tworzymy jakieś kontrolery, tworzymy serwisy, tworzymy fasady itd. – ktoś powie „no, to są obiekty!”, ale to nie do końca są obiekty. Bo to są zbiory funkcji, a nie jakieś rzeczy reprezentujące obiekty!

Obiekty są tylko po to, żeby wszczepiać do nich zależności. A tak naprawdę są zbiory funkcji. 

I wydaje mi się, że rzeczywiście, jak spojrzymy na współczesne zarówno back endowe, jak i front endowe aplikacje, to poza tymi krawędziami, czyli właśnie API oraz bazy danych, oraz przejścia między warstwami, to jednak dużo, dużo więcej jest w nich myślenia funkcyjnego niż obiektowego.

 

Ciekawe, to ten trend tak ogólnie jest bardziej zauważalny. Teraz, mam wrażenie, że lekka moda na programowanie funkcyjne wróciła. Co ciekawe, to w językach programowania to najpierw raczej myśleliśmy, czy też tworzyliśmy języki programowania, które tak działały, dopiero później programowanie obiektowe gdzieś zdobyło tutaj całość branży. Ale jak gdyby nie wnikajmy w to, bo to długa historia.

Chciałbym Cię zapytać – może niewygodne trochę pytanie, ale o to, czego Tobie brakuje w Kotlinie? Jakie uważasz problemy w tym języku są takie najbardziej jaskrawe na ten moment?

 

Nie wiem, czy to jest rzeczywiście problem, ale powiem, że w ostatnim czasie dosyć sporo siedzę w Type Scripcie oraz Pythonie. Jedna rzecz, która jest jakby w Kotlinie by design, oczywiście, bo takie było myślenie wtedy, ale to, że Kotlin jest statycznie typowany i rzeczywiście jest mocno statycznie typowany.

Typowanie jest na każdym poziomie. Natomiast od jakiegoś czasu odkrywam zalety dynamizmu takiego, jaki jest w TypeScripcie, że z jednej strony skutecznie ogranicza twój zestaw możliwości, ale z drugiej strony pozwala na potężne przekształcanie tych typów.

I może czujesz, że takie rzeczy, jak to, że jeżeli masz obiekt A i obiekt B – i obiekt B ma takie same właściwości co obiekt A, to możesz już po prostu przekazać obiekt B tam, gdzie jest spodziewany obiekt A. To jest jakaś mała wygoda, powiedzmy. Ale na przykład to, że możesz jakby zdefiniować, że dana funkcja zwraca obiekt, który wszedł, ale z dodatkową właściwością. Albo bez danej właściwości.

To są rzeczy, które nie interesują tak bardzo przeciętnego programistę, bo zwariowalibyśmy, gdybyśmy robili takie przekształcenia na co dzień, ale dają bardzo dużą wygodę twórcom bibliotek, twórcom narzędzi i otwierają bardzo dużo ciekawych drzwi. One były chyba we wspomnianym przez Ciebie Ruby po raz pierwszy, choć tam nie było typowania, więc to raczej było takie domyślanie się, ale TypeScript rzeczywiście te drzwi skutecznie otwiera i to jest bardzo, bardzo fajna rzecz, którą w jakiś sposób czuję, że jest kierunkiem, w którym idziemy. Wszystkie języki statycznie typowane siłą rzeczy nie pójdą w tę stronę.

Brakuje mi też pewnych funkcjonalności związanych z typami. Ogólnie – na przykład Union Type. Albo w zależności od nomenklatury można powiedzieć Sun Type albo Intersection Type.

Czyli właśnie coś albo coś. Aczkolwiek ta funkcjonalność już była dyskutowana i mówili twórcy, że chcą ją wprowadzić, więc ona pewnie wejdzie. Ale na razie jej brakuje. Brakuje mi też na przykład rzeczy takich jak collection literals, czyli łatwiejszego sposobu na tworzenie kolekcji. Tak jak w JavaScripcie czy Pythonie, po prostu otwierasz nawias kwadratowy, wrzucasz tam obiekty i masz listę. Albo nawias klamrowy i masz jakiś tam set. A w przypadku Java Scripta obiekt.

W Kotlinie tego nie ma, nie było tego od początku. Zamiast tego mamy funkcję list of, set of itd. Aczkolwiek ta funkcjonalność nawet została zaimplementowana, bo w pewnym momencie było głosowanie na ficzer, ona wygrała na pierwszym miejscu, jako ficzer, który ludzie chcą, żeby wszedł do języka. Już więc została zaimplementowana, już miała wejść, kiedy zaprotestowało kilka bardzo wpływowych osób w community. Chyba najbardziej Jake Wharton wspomniany wcześniej, że to bardzo dyskryminuje inne kolekcje względem wbudowanych kolekcji języka.

I rzeczywiście to zatrzymało wydanie tego ficzera i do tej pory nie został wprowadzony. To było już z dwa lata temu.

 

Rozumiem. To całe bogactwo tych możliwości, o których opowiadasz, może być na początku przytłaczające, przynajmniej! W związku z tym zastanawiam się, czy to jest dobry język tak na start według ciebie?

 

Tak. To jest odwieczny problem. Im więcej funkcjonalności, tym więcej rzeczy trzeba się nauczyć, żeby zacząć. Jeszcze rok czy dwa lata temu mówiłem, że nie, bo przecież Kotlin jest jak Java, tylko trudniejszy, bo ma dużo więcej funkcjonalności. Ale kiedy pisałem tę książkę o JavaScripcie – „JavaScript od podstaw”, którą kierowałem dla osób zupełnie początkujących, nauczyłem się jednej rzeczy. Zauważyłem, że Java Script ma ogromną ilość przestarzałych funkcjonalności, których unikamy. Jakiegoś podwójnego równa się, po prostu unikamy jak ognia.

Albo mamy całą masę rzeczy, które po prostu są uważane za „lepiej tego nie ruszać, nie zbliżać się, nie róbmy tego”. I wtedy sobie trochę uświadomiłem, że jeżeli nauka jest dobrze poprowadzona, to te bardziej zaawansowane języki mogą być dużo prostsze. Bo dajmy na to, że w Javie trzeba było tworzyć – jak tam się tworzyło jakiś obiekt, fieldy, pola, gettery, settery. Było bardzo skomplikowanie!

W Kotlinie to wszystko niby jest wzbudowane, ale esencja jest taka, że człowiek nie musi o tym wiedzieć. Ja tego uczę – ale uczę przede wszystkim osoby, które są programistami Java, więc mówię im w jaki sposób to zmienić, ale nie próbowałem uczyć nikogo Kotlina od podstaw. Ale przypuszczam, że gdybym tak robił – myślałem o tym, żeby napisać książkę o Kotlinie od podstaw, ale przypuszczam, że gdybym tak zrobił, to bym właśnie nie tłumaczył tych getterów i setterów pod spodem. Bym po prostu pokazał: tak się to robi! I to jest proste, fajne, wygodne, intuicyjne. A jak chcesz wykorzystać to i to, to robisz to tak.

I wydaje mi się, że jeżeli dobrze by była poprowadzona książka, to Kotlin mógłby być nawet dużo prostszym językiem od nauki niż Java. Bo jest dużo bardziej uporządkowany. Mimo że ma dużo więcej funkcjonalności, co siłą rzeczy oznacza więcej rzeczy do nauki, ale z drugiej strony te funkcjonalności zasłaniają pewne wzorce, więc już czasem jest prościej wykorzystać je, niż nauczyć się tych wzorców. Nie wiem. Wydaje mi się, że Kotlin może być niezłym językiem na start. Jeżeli ktoś chce programować na platformę Android, to moim zdaniem Kotlin jest najlepszym językiem na start i w tym momencie nie ma zbytnio co gadać. Natomiast przede wszystkim powinno się chyba podejmować decyzje w oparciu o to, co chce się robić. A nie w jakim języku chce się to robić.

 

I wydaje mi się, że jeżeli dobrze by była poprowadzona książka, to Kotlin mógłby być nawet dużo prostszym językiem od nauki niż Java. Bo jest dużo bardziej uporządkowany. Mimo że ma dużo więcej funkcjonalności, co siłą rzeczy oznacza więcej rzeczy do nauki, ale z drugiej strony te funkcjonalności zasłaniają pewne wzorce, więc już czasem jest prościej wykorzystać je, niż nauczyć się tych wzorców. 

 

I łatwo jest zacząć w tym momencie – chyba najłatwiej jest zacząć na robieniu front endu, czyli Java Script oraz na pisaniu różnych skryptów, czy też analiz itd, czyli Python.

 

Pewnie! Czyli jak rozumiem polecasz naukę tego języka i pewnie wszystkich innych po prostu, w praktyce, ale tak, gdybyśmy mogli zebrać powiedzmy w jednej odpowiedzi właśnie te sposoby nauki języka Kotlin, te materiały, które możesz polecić do nauki, to co byś tutaj polecił?

 

Ojejku! Od podstaw? Nie jestem pewien. Musiałbym przejrzeć, jakie są możliwości nauki od podstaw. Zbierałem rzeczywiście materiały do nauki Kotlina dla osób, które już programują. To jest chyba częstszy case.

 

Okej. Wspomniałeś o tym kursie na Courserze – to jest myślę dobre miejsce, do którego można odesłać?

 

Ale on chyba też jest tworzony dla osób, które już programują. To jest zupełnie inna nauka. Uczenie od podstaw… Ale Kotlin jest często wybierany dla osób, które właśnie robią coś innego – czy to back end, czy to właśnie front end i są już trochę znudzone tym, co robią.

I wtedy wybierają sobie nową, cool platformę, czyli Android, która ma fajne narzędzia, bo Android zawsze miał dużo fajnych narzędzi. To też czyni go trochę skomplikowanym, bo miał strasznie dużo tych narzędzi, które uważa się za standard. Fajny język, czyli Kotlin i sobie pisze aplikacje.

To jest więc rzeczywiście częsta ścieżka, jaką widzę, że osoby po prostu troszkę wypalone w back endzie czy front endzie chcą coś zmienić, idą w Android. W Androidzie też się nieźle zarabia generalnie!

 

Jasne – przyszłościowy język! Właśnie, ale mówiąc o przyszłości. Jakie Ty kierunki rozwoju tego języka, tego ekosystemu widzisz, gdybyś mógł tak się zabawić trochę we wróżkę i powiedzieć, jak w Twojej opinii za rok, dwa, może trzy ten ekosystem, ten język będzie wyglądał?

 

Wiesz co, największym problemem mobilek jest to, że trzeba osobno pisać kod na różne platformy. I dlatego taką ważną funkcjonalnością jest programowanie wieloplatformowe w Kotlinie. To sprawia, że można pisać kod w Kotlinie, który będzie chodził zarówno na Androidzie, jak i na RS-ie. W tym momencie jest to głównie wykorzystywane w ten sposób, że się pisze części wspólne – czyli pisze się jakieś części, które są współdzielone, a rzeczy indywidualne pisze się na Androidzie, na RS-ie.

Tylko że tych części wspólnych jest bardzo dużo, wbrew pozorom! Tak naprawdę, jeżeli zespół jest dobrze zorganizowany, to może wyciągnąć jako część wspólną praktycznie wszystko poza widokami. I view modele albo presentery, jak tam kto robi – i repozytoria, to wszystko może być w częściach wspólnych. Są biblioteki multiplatformowe do korzystania z baz danych, do zapytań sieciowych, do niemalże wszystkiego. W tym momencie to jest najistotniejszy kierunek Androida w tę stronę. Wydaje mi się, że już teraz jest to wykorzystywane przez coraz więcej firm, zwłaszcza dużych firm, które kładą dużo kasy na rozwój tych dwóch platform.

Szczerze mówiąc, ja czekam na coś, czego jeszcze nie widzę. Widziałem parę, ale nie takich, na jakie czekam. Jest to idealny potencjał, żeby ktoś zrobił wieloplatformowy framework do programowania na kilka platform all in Kotlin. W zasadzie Jetpack Compose, który służy do tworzenia widoków, jest trochę taką próbą. Jeżeli by się postarać, to można by pewnie tworzyć wszystko wyłącznie w częściach wspólnych. Może w tym momencie jeszcze nie, ale być może już niedługo. Spodziewam się, że w tę stronę będzie to szło. 

Były różne inne eksperymenty, takie jak Flutter. Nie wydaje mi się, żeby był on najbardziej udanym eksperymentem. Ma on bardzo fajne funkcjonalności takie jak hot reload, który rzeczywiście sprawnie działa, co nigdy się nie udało Androidowi. Natomiast jego architektura raczej nadaje się do małych aplikacji, nie jest skalowalna na bardzo duże aplikacje. W dodatku Flutter dostawał przez pewien czas ogromne promocje i finansowanie od Google, co potem się nagle ucięło i zamiast tego Google zaczął promować i finansować Jetpack Compose. 

 

Były różne inne eksperymenty, takie jak Flutter. Nie wydaje mi się, żeby był on najbardziej udanym eksperymentem. Ma on bardzo fajne funkcjonalności takie jak hot reload, który rzeczywiście sprawnie działa, co nigdy się nie udało Androidowi. Natomiast jego architektura raczej nadaje się do małych aplikacji, nie jest skalowalna na bardzo duże aplikacje. 

To jest więc jeden istotny kierunek rozwoju. Wydaje mi się, że korutyny będą rzeczywiście postępowały. Korutyny są też bardzo ważne na back endzie, więc jak już back endy zaczną się przenosić na korutyny, co moim zdaniem jest naprawdę game changerem na back endzie, to już nie będą chciały przechodzić na nic innego. Korutyny więc przywiązują też do Kotlina, bo nie działają na Javie, więc trzeba wejść all in Kotlin. 

Moim zdaniem w tym momencie największą konkurencją dla aplikacji mobilnych czy też tego, w jaki sposób się tworzy aplikacje mobilne, czyli natywnie w tym momencie, nie jest wcale Flutter czy inne technologie, tylko jest to web. Jest to PWA. To, że można stworzyć sobie stronę internetową, którą się instaluje na aplikację, która żyje sobie w trybie offline i korzysta z bazy danych i robi niemal wszystko to, co robi aplikacja normalna, a jednocześnie jest napisana w JavaScript, jest na wszystkie platformy, w jednym miejscu – to jest moim zdaniem duże zagrożenie dla sporej części aplikacji mobilnych. 

Pewnie więc to będzie takie wyzwanie. Tutaj też Kotlin próbuje wejść, bo Kotlin jest skompilowany do JavaScript, też udostępnia i też w Jackpack Compose można tworzyć aplikacje webowe, ale na razie postęp jest bardzo powolny, więc nie wiem, czy to się uda. Być może nagle będzie szok, że zrobi się taki trend, a być może taki trend nigdy nie powstanie i Kotlin po prostu zostanie jako język back endu i aplikacji mobilnych.

 

Nigdy tego nie wiadomo i bardzo ciężko jest to przewidzieć. Jedno jest pewne – ciekawa przyszłość przed nami w tym względzie. 

Marcin Moskała był moim gościem, rozmawialiśmy o języku programowania Kotlin. Marcinie, dzięki bardzo za poświęcony czas, za rozmowę.

 

Dziękuję za zaproszenie mnie.

 

Na końcu powiedz jeszcze, gdzie cię można znaleźć w internecie, jak się z tobą skontaktować, gdzie poczytać twoje materiały.

 

Najwięcej na stronie Kt. Academy, czyli na kt.academy – to już jest cały adres, academy jest poprawną końcówką w internecie. Jeżeli chodzi o newsy z tego, co robimy, to najczęściej na Twitterze można mnie znaleźć – @MarcinMoskalaPL. 

Ostatnio Kasia u nas w Kt. Academy organizuje bardzo fajne akcje, teraz np. organizuje Czwartki z programowaniem – co czwartek w Warszawie organizuje wykład, dotyczący jakiejś innej dziedziny. W ten czwartek będzie o sztucznej inteligencji, a w następnym tygodniu względem nagrywania tego odcinka, bo nie wiem, kiedy będzie opublikowany, będziemy programowali płytki takie jak Raspberry Pi, tylko troszkę prostsze, i będziemy mieli 10 płytek do rozdania dla uczestników, więc warto przyjść. 

 

Oczywiście, że tak. Wszystkie linki oczywiście będą w notatce do odcinka, żeby łatwiej sobie te rzeczy znaleźć. 

Z mojej strony Marcin jeszcze raz bardzo ci dziękuję za poświęcony czas i do usłyszenia, cześć!