Podróż z JavaScript’u do Scali

Podróż z JavaScript’u do Scali

Bym mógł pisać dalej z czystym sumieniem muszę przyznać się, że to nie ja wybrałem Scalę – to Scala wybrała mnie! Dokładniej mówiąc dołączyłem do małego projektu, start-up’u, jako JavaScript developer i długo nie nacieszyłem się urokami używania JS’a w projekcie (dokładnie Meteor.js). Ilość produkowanego kodu postępowała wykładniczo, a jak to często bywa więcej kodu == więcej możliwych błędów. Tak więc po kilku miesiącach pracy jako JS developer usłyszałem Przechodzimy na Scalę! – od tak, ahoj przygodo!

Scala language logo
Na początku nie polubiłem się ze Scalą, a to dlatego, że Scala i JavaScript reprezentują dwa różne sposoby myślenia. JavaScript to taki dobry wujek, który na wszystko Ci pozwala, dodawanie false + 8.23? Nie ma problemu. Ba! Nawet nie zwróci Ci uwagi, że coś może się nie zgadzać. Scala natomiast to taka ciotka, która uwzięła się na Ciebie i wytyka każde potknięcie, nie pozwala na głupoty, ogólnie wszystko musi się zgadzać. Z takim wujkiem fajnie spędza się weekend jednak nie jest dobrym towarzyszem na dłuższy czas – czasami warto mieć kogoś kto nam powie, że żonglowanie dynamitem to nie jest najlepszy pomysł.

W tym miejscu odpowiem na pytanie, które mogło kogoś dręczyć…

O czym Ty piszesz?! Przecież nie możesz całkowicie zrezygnować z JavaScript’u na rzecz Scali! W Scali nie napiszesz części klienta aplikacji!

Odpowiem szybko i zwięźle: Na pomoc przychodzi Scala.js – cudowne narzędzie, które pozwala kompilować kod Scala do kodu JavaScript. Dzięki Scala.js możemy zapomnieć nawet o pisaniu suchych tagów HTML’a i korzystać z komponentów Reacta! Twórcy tego kompilatora doskonale zdawali sobie sprawę, że zarówno Scala i JavaScript to potężne narzędzia i zastąpienie JavaScript’u nie jest obecnie możliwe. O samym Scala.js napisze więcej innym razem.

Na marginesie: Pisząc „JavaScript” nie mam na myśli czystego JavaScript’u zagnieżdżonego w tagach <script> Moje doświadczenie opieram na Node.js i Meteor.js.

Jak to jest z tym typowaniem?

Mocne typowanie statyczne to pierwsza, moim zdaniem wielka zaleta Scali. Spotkałem się z opiniami, że dynamiczne typowanie JavaScriptu to zaleta a typowanie statyczne Scali – wada i ograniczenie. Jeżeli tworzymy coś na szybko, mały serwis albo projekt na zaliczenie to JavaScript szybciej pozwoli nam zobaczyć pierwsze efekty. Jednak cała radość z szybkiego pisania rozwiązań znika wraz z pojawieniem się cannot read property 'id' of undefined i innych podobnych, trudnych do zlokalizowania błędów. Scala natomiast jest językiem typowanym statycznie, to oznacza, że każda zmienna ma przypisany do siebie typ i jeśli próbujemy przypisać wartość "tekst" do zmiennej typu Boolean czy Int nasz program nie skompiluje się. Język typowany dynamicznie nie zwróci na to uwagi, ewentualny błąd, może wystąpić w trakcie działania programu.
funny meme javascript refactoring
Wadą typowania statycznego może być wpisywanie dużej ilości zbędnego kodu opisującego typy zmiennych, jednak i tutaj Scala pozytywnie zaskakuje! A to dlatego, że posiada inferencję typów. Oznacza to tyle, że możemy pominąć pewne informacje o typach ponieważ kompilator sam jest w stanie je wydedukować. Nie ma więc potrzeby pisania val foo: Int = 5, inferencja typów zapewnia, że val foo = 5 zostanie zinterpretowane jako typ Int.

W używaniu Meteor.js i ogólnie JavaScript’u niezmiernie bolało mnie to, jak łatwo można było wysadzić program w powietrze przez chwilę nieuwagi. To mogło się zdarzyć przez omyłkowe nadpisanie wartości zmiennych lub dostęp do wartości, które nie powinny być dostępna w danym miejscu. Jeśli ceną za uniknięcie tego typu błędów jest korzystanie z typowania statycznego to biorę to w ciemno!

W moim odczuciu korzystanie ze statycznego typowania sprawia, że kod wydaje się zorganizowany, uporządkowany i znacznie bardziej odporny na błędy.

Mix obiektowo-funkcyjny​

Scala język obiektowo-funkcyjny, pawscode.

Scala jest językiem obiektowo-funkcyjnym a więc jemy pizze i mamy pizze. W scali nie musimy rezygnować z dziedziczenia, enkapsulacji czy polimorfizmu na rzecz niezmienności wartości (immutable) lub dla kompozycji funkcji – mamy pełen pakiet.

Przyjmuje się, że pisząc w Scali nie modyfikujemy zadeklarowanych wartości – chociaż mamy taką możliwość (bliżej więc Scali do języka funkcyjnego). Zmienna zdefiniowana poprzez val jest immutable – nie możemy zmienić jej wartości zaś zmienna zdefiniowana przez var może być modyfikowana (muttable). Nie spotkałem się jeszcze, by ktoś pisząc w Scali chętnie używał „var’ów”, jednak czasami, w ostateczności, nie ma innego wyjścia.

Dla tych, co używają na co dzień Javy też mam dobrą wiadomość! Przenosząc się na Scalę nie przenosimy się na małą wyspę gdzie od nowa powstaje flora i fauna programistycznych rozwiązań. Scala tak jak i Java kompiluje się do JVM (Java Virtual Machine) i stworzona jest w taki sposób by całkowicie naturalnie można było używać bibliotek Javy.

Zalet Scali jest znacznie więcej! Pattern matching, case class’y, for comprehensions i inne… Uroki tego języka poznaje się z czasem a z niektórych rozwiązań gdy już zacznie się je stosować ciężko jest zrezygnować. Dla osób zainteresowanych polecam swój post na temat for comprehensions: For comprehensions – o Scali ciąg dalszy. Zachęcam również do zapoznania się z oficjalną dokumentacją Scali na https://docs.scala-lang.org/

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Powrót do góry