Wstęp do FP - Scala i Java - porównanie warsztatów

Na samym początku ważne są dwa zdjęcia. Pierwsze, że warsztat się w ogóle odbył i średnia wiedzy programistycznej świata się podniosła

A drugie ważne zdjęcie to zdjęcie sponsora bo salki same się nie wynajmują i pizza sama się nie zamawia - także nieważne w jakim języku programujesz podstawy ekonomi znać musisz :) (no chyba, ze programujesz szyby naftowe w Kuwejcie to wtedy może jakoś inaczej to działa)

Obydwa zdjęcia powyżej są od CezaregoD. - ktoś może mi dać wskazówkę dlaczego 90% moich zdjęć jest zawsze rozmazanych? Łapy raczej mi się aż tak nie trzęsą. Zdjęcia robię samsungiem S5.

Poczucie bliskości wartości edukacyjnej

Ogólnie ludzie są bardziej zainteresowani Javą8 (w sumie z 80 chętnych na kilka tur?) niż scalą (około 45) i generalnie trudno się dziwić bo Java jest na co dzień w pracy - czasem nawet i ta ósemka. Scala już się tu i ówdzie pojawia ale cały czas jest to taka "inwestycja edukacyjna" gdzieś tam na przyszłość.

Mam także jednak teorie, że z każdym krokiem w kierunku opanowania Javy8 i Scala będzie stawała się bliższa bo czy taka strzałka -> czy taka => to już bez większej różnicy. W sumie jak tak patrze z perspektywy to sam zacząłem i porzuciłem naukę Haskella w połowie 2014 bo w sumie po co uczyć się kilka rzeczy jak można skoncentrować się na jednej. I znowu z subiektywnej obserwacji widzę, że po osiągnięciu pewnego poziomu trzeba "zmienić plan treningowy" i otworzyć się na inne perspektywy bo w przeciwnym przypadku zaczynamy za bardzo koncentrować się na jakiejś drobnicy.

No to zerknijmy na materiał

By nauka szła wspaniale na trzy części ją rozwalę

Mamy :

• kod zoptymalizowany pod prędkość wykonania
• kod zoptymalizowany pod rozszerzenie
• kod zoptymalizowany pod ...edukację!

I tutaj nas interesuje ten ostatni punkt.

Generalnie jako pierwszy przykład na warsztat idzie coś co z jednej strony pokaże, że "to co tutaj robimy do czegoś w życiu się przyda" a z drugiej nie może być zbyt złożone by nikt nie odleciał. Dlatego też każdy element rozwiązania jest odwzorowany symbolicznie. I tka mamy zajebiście duża dwuelementową mapę udająca bazę danych, jest i miejsce na Optional oraz kompozycje dwóch funkcji gdzie jedna jest domenowa a druga jakaś taka niezależna i bardzo matematycznie abstrakcyjne. I jest reusedż.

Tutaj także jest założenie, że dla większości uczestników to może być pierwszy kontakt z pewnymi konstrukcjami z Javy8 i generalnie jak np. ktoś sobie zakłada, ze musi ale to MUSI zrozumieć wszystko perfekcyjnie to może niepotrzebnie pojawić się frustracja - i niepotrzebnie bo to nauce nie służy (w ogóle takie czasy są, ze musi być wszystko zajebiście i w ogóle masa lajków). Dlatego też tutaj kilka razy podkreślam, żeby się zluzować i podejść do tego jak do demonstracji - takie coś jest możliwe, tego będziemy się uczyć i za jakiś czas każdy będzie w tym wymiatał. Nauka to funkcja czasu i trzeba na ten czas poprawkę wziąć.

No i teraz mamy pierwsza istotną różnicę pomiędzy warsztatem Javowym i Scalowym - w Scali od razu jedziemy z Property Based Testing. W Javie by było 100% javowo to są zwykłe JUnity. Ale tak czy inaczej to co uczestnicy zaobserwują to, że

Poznawanie składni

Generalnie z tłumaczeniem przez kogoś kto już ma wiedzę w kierunku kogoś kto wiedzy nie ma jest ten problem jak np. z wczuwaniem się co czuje głodna osoba gdy sami jesteśmy najedzeni. Albo jak już ktoś ze 20000km przejedzie to zapomina, ze kiedyś musiał sobie ściągę do zmiany biegów rysować.

No i praktyka pokazała, że ta składnia ze strzałkami stanowi na początku problem dla osób, które znają tylko składnie Java7lubmniej. Dlatego i po to sa te krótkie ćwiczenia by sobie powtarzac i powtarzać i tworza się nowe połączenia nerwowe i kroczek po kroczku lambdy stają się naturalnym zapisem

No i trzeba zwracać uwagę na wszelakie powiązania jak np. to, że ile razy w typie wystąpi słowo Function tyle zazwyczaj strzałek musi się w ciele pojawić

W Scali tego problemu nie ma bo są aliasy ale za to w Scali jeszcze niema invoke dynamic (ale już zara ma być) także częścią warsztatów będzie badanie syntetyków.

A na sam koniec - kiedy już pojawia się jakieś zmęczenie - zostaje teoria bo praktyka bez teorii to takie działanie na czuja. na pierwszym warsztacie było (a jak!) Referential Transparency. I znowu ćwiczenia będą się troszeczkę różnić pomiędzy Java a Scalą tak by weń uwzględnić ograniczenia i ficzery każdego z języków.

Czy dwa języki mogą pomóc w nauce?

Według tego artykułu chyba tak --> https://www.washingtonpost.com/news/wonk/wp/2016/02/12/how-to-learn-new-skills-twice-as-fast/

Powtórki i kolejne odcinki

Będą. Na razie w planach powtórka pierwszego warsztatu z Java8 i pierwszy warsztat ze Scali.

• Programowanie Funkcyjne w Java8 - warsztat 1 - tura 2
• Scala - Programowanie Funkcyjne - warsztat 1

Co na druga część?

Poważną zaletą dzielenia się opinią przez uczestników jest dzielenie się opinią przez uczestników. Toteż w trakcie smaltoków i ankiety po warsztatowej ludzie napisali, że fajnie by było trochę praktycznego kontekstu pokazać dla tych mechanizmów.

Pomysł na razie mam taki - że będzie sobie jakiś plik CSV z danymi (ileś tam kolumn). i stopniowo będzie my budować silnik do analizy tych danych krok po kroku tworząc funkcyjne abstrakcje, które ułatwią testowanie i ponowne wykorzystanie kodu (może od razu wykorzystamy to w drugim kontekście). A jak będzie otwieranie pliku to i zaimplementuje się loan pattern czy też w javowej nomenklaturze pykniemy sobie customowe try-with-resources tak jakby to była bułka z masłem (bo z FP jest!).

Także fidbeki są dobre bo wtedy można mówić, ze rozwiązanie jest "field tested" czyli ktoś użył i już wiadomo co i jak. Zestaw to teraz w kontrast z dyskusjami na meetingach o tym "jak robić zanim ktoś zrobi".

Czy logowanie do log4j to efekt uboczny?

Padło takie pytanko. Generalnie jakby chcieć być bardzo ścisłym to wszystko co się robi na kompie jest efektem ubocznym bo jak ze Stringa tworzysz Email to np. pamięć może się skończyć. A mimo to tak mentalnie zakładamy typ String=>Email a nie String=>Try[Email] (chociaż jak się skończy pamięć to i tak chyba wszystko jebnie)

I z logowaniem to może być też o tyle ciekawy przykład, że możemy pogłówkować gdzie to założenie ma jeszcze sens. I tak np. jak mamy taki staromodny springowy kontroler i tam używamy sobie funkcji, która ma wbudowane logowanie to można chyba założyć, ze jest ok i tagedyi nie ma.

option.map(f)

Ale co jeśli tę samą funkcje wywołamy na sparku i trzepnie nam ona 2GB logów?

rdd.map(f)

I niech teraz mamy druga funkcje f2, która tez loguje - robimy f1.andThen(f2) i nagle mamy 4GB logów. No trochę ku*wa moim skromnym zdaniem jakiś efekt uboczny to już jest. Ja wiem, że dyski tanieją ale nie aż tak szybko.

Takie rozwiązanie nasuwa mi się na myśl. Jeśli funkcja jest dosyć generyczna aż do tego stopnia, ze jest biblioteczna to zrobić ją bez logowania i łatwo można dodać funkcje dekorującą z logowaniem. Wtedy to użytkownik znający kontekst dokona właściwego (oby wyboru)

val f:Int=>Int=x=>x+1

def withLogging[A,B](f:A=>B): A=>B = a=>{
    log(s"param : $a")
    f(a)
}

withLogging(f)(5)
//INFO : param : 5
//res0: Int = 6

A jak wstawię null?

- pojawiało się pytanie "A co się stanie jak tam wstawię null".
To się stanie

Inni też robią!

• w połowie kwietnia zapowiedział się Damian Warszawski z warsztatem o "Lazy" (i zrozumiałem, że nie ma nic przeciwko, iż wspomnę o nim z imienia :))
• i jeszcze tam dwóch kolegów się przygotowuje aby coś o Scali porobić

Generalnie jak ktoś chce coś robić to niech śmiało daje znać. Generalnie już widziałem ten schemat n razy. Najpierw ludzie się boją, że publika zada trudne pytania a problemem jest zazwyczaj, że nikt nie zadaje pytań :) Po pierwszym udanym warsztacie zazwyczaj mózg już przestaje sobie wkręcać, że za ścianą czekają lwy i dalsze spotkania robi się dużo prościej. Jeśli chodzi o formę to tez kilka osób ma już doświadczenie także do dzieła!