niedziela, 28 lutego 2016

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.

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!

niedziela, 14 lutego 2016

Plan wspólnej edukacji

Na początek miała być jakaś złota myśl o potrzebie stworzenia solidnych fundamentów wiedzy ale poniższy obrazek, który ktoś wrzucił na twittera będzie znacznie lepszy

Jeśli ktoś jeszcze nie czytał niesamowitej książki zatytułowanej Antifragile to bardzo polecam. Pośród wielu arcyciekawych konceptów jeden jest niezwykle istotny z punktu widzenia tego artykułu . Przewidywany cykl życia idei! Ów koncept może być dla czytelnika z początku mało intuicyjny bo cała mechanika działa inaczej niż z ludźmi jako takim - zoba te bulletpointy:

  • Im dłużej żyje tym mniej życia mu zostało.
  • Im Idea żyje dłużej tym więcej życia jej zostało!

Wytłumaczenie jest niezwykle proste. Idea jako Idea nie rdzewieje fizycznie, nie działają na nie wolne rodniki czy inne takie paskudztwa. Natomiast „Idea” umiera gdy "nosniki" przestają ją „przenosić” czyli konkretnie gdy ludzie przestają w daną Idea wierzyć. A wierzyć przestają gdy się z jakiegoś powodu nie sprawdza.

No i teraz mamy takie programowanie funkcyjne nie jako „język z lambdami” ale jako „Koncepcje przeprowadzenia obliczeń” - i ta koncepcja ma 100 lat prawie! To nie jest byle co ku*wa - 100 lat! I jest respawn teraz globalny! I jak ludzie do tego teraz wracają to znaczy, że ta „idea” przetrwała i coś w sobie ma. (dla porównania ludzie nie wracają do idei "woda posiada inteligencje", za którą ktoś tam kiedyś dostał IG Nobla)

No i np. pierwszy warsztat z Javy 8 za tydzień -> Java 8 warsztat meetup (Taka technika marketingowa niby, że se pisze bloga a podrzucam link). Lambda jako lambda w javie8 to prosta – interfejs z jedną metodą – ale co i gdzie można z tym zrobić to „ooo panie” i to „ooooo panie” jest dosyć uniwersalne – to się chyba mów „language agnostic”. Oczywiście kolejną istotną sprawą jest warsztat języka i jeśli jest za dużo ceremoniału by stworzyć coś „lambdopodobnego” (patrz java 7) to podejście staje się nieproduktywne i ludzie zwyczajnie go nie używają (Idea umiera nim się narodzi).

Za chwilę omówię pewien plan edukacji, który być może uda się zrealizować w tym roku na łódzkim JUGu poczynając od wiosny. Jakkolwiek wcześniej trochę Ideologii by zbudować fundamenty.

Teoria i praktyka

Co jakiś czas na różnych forach informatycznych pojawia się temat „czy tego a tego języka można nauczyć się głównie z książki?” No oczywiście, że nie można bo rzadko kiedy książka potrafi zasymulować skalę wyzwań rzeczywistego projektu. Ale jest pewne ALE. Bo tak z drugiej strony – czy języka/technologii można się nauczyć tylko z pracy w projekcie? Z tego co zauważyłem to jest szalenie niebezpieczne podejście! Dlaczego? Gdyż kiedy ludzie używają narzędzia a nie do końca rozumieją jak ono działa – to generują własne wytłumaczenia symboliczne dla zjawisk, które obserwują.

I tak np. osoba używająca mavena w tzw. „projektach komercyjnych” będzie znała wiele myków, które zaskoczą osobę ze znajomością teoretyczną ale być może ta sama osoba nie rozumie koncepcji mavena jako takiej! Zna strone na stackoverflow , z której trzeba przekleić kod by mieć wbudowane jetty ale jednocześnie nie rozumie jak ten wklejony kawałek ma się do koncepcji systemu budowania projektu.

I np. widziałem ludzi, którzy pisali w języku programowania, wiedzieli jak skompilować , jak uruchomić, jak coś wyświetlić. Ale proces tworzenia był niezwykle symboliczny „może tutaj jak wstawię ifa to zadziała, a może tam trzeba ifa, a tutaj jeszcze nie próbowałem”. Rozwińmy ten temat gdyż jest on niezwykle ciekawy w kontekście tego co dzieje się w informatyce.

Od myślenia magicznego do myślenia analitycznego

Na przykład mamy Hibernate - to dobry przykład bo popularny i sam go kaleczyłem. No i jest sobie ten Hibernate i można go użyć na dwa sposoby.

Raz, że się pozna odpowiednio relacyjne bazy danych, pozna się obiektowe mechanizmy Javy - dojdzie się do wniosku, ze trzeba jedno na drugie zmapować i poszuka czy nie ma przydatnego do tego zadania narzędzia. To będzie podejście takie nazwijmy to pragmatyczno-analityczne.
Dwa - można po prostu użyć Hibernate...no bo jak się czyta baze w Javie to przez Hibernate co nie? No tka przeca mówią na forach co nie?. To możemy nazwać myśleniem magicznym. Zastosowanie narzędzia rośnie tutaj do rangi symbolu uproszczonego poprzez sztuczną redukcję niewygodnych detali.

Albo Spring. Sam, żem kiedyś jebnął tzw. "open session in view". Działało. Psuło wiele rzeczy ale nie wiedziałem tego bo działało. Ostatnio znowu słyszałem o rozsypce przez radosne wrzucanie różnych annotacji tu i tam. Chcemy mieć transakcję - to @Transactional i hejnał!!!

Czy coś mniej oldskulowego - Apache Spark. Widziałem - ludzie używają Dataframe bez większej refleksji, że oto operują abstrakcją nad potencjalnie olbrzymim rozproszonym zbiorze danych. No przeca się wyświetla mój hello world to w czym problem? Tudzież ktoś rozpakowuje zipa ze sparkiem 1.6 gdzies w katalogu temp i ogłasza, że dokonał migracji do sparka 1.6. Cluster sruster - kompiluje się przeca!

A tak klasycznie myślenie magiczne to było np. przekonanie, że kwiaty nie rosną (skutek) bo pada deszcz (przyczyna) ale, ze istnieje siła nadprzyrodzona, która widząc kwiaty (przyczyna) sprawia, że pada deszcz (skutek). Czyli na odwyrtkę i na wysokim poziomie abstrakcji ---> więcej tutaj https://en.wikipedia.org/wiki/Magical_thinking

Także reasumując może warto spróbować podejść „teoria poparta praktyką projektową” lub „praktyka poparta zapleczem teoretycznym” ?

Cel Nauki

Na jesieni miał miejsce ciekawy kurs „programowanie funkcyjne w OCAML” i Na 90% raczej nic w życiu w OCAMLu nie napiszę (chociaż kto wie) - po co więc poświęcać czas na naukę? No bo niczego nie trzeba się w tym przypadku oduczać! Jak uczysz się programowania funkcyjnego w Javie, w której piszesz już kilka lat - to chcesz czy nie - przez swoje doświadczenie będziesz widział lambdy jako konstrukcje Javy na JVM – co samo w sobie jest dobre dla praktyki ale niekoniecznie dla edukacji.

A taki OCAML to było dla mnie wszystko nowe! No i się uczyłem. To było bardzo ciekawe gdyż konstrukcje na zmiennych „mutable”, które w Javie są codziennością (i niestety dla wielu jedynym sposobem rozwiązywania problemów) pojawiły się dopiero w tygodniu 5! Tak dopiero w tygodniu piątym! I jest miejsce na te rozwiązania i zapewne zgadujesz dobrze – zazwyczaj kiedy chodzi o wydajność.

Także to nie jest tak, że mutable jest złe i nie należy tego używać. Mutable jest za to szalenie niebezpieczne i trzeba zrozumieć cenę jaką się płaci za korzystanie z tej techniki. Tak – należy do tego podejść jak do techniki, która się używa gdy jest to potrzebne i płaci się cenę. W Ocaml jeśli dorbze pamiętam obszar minowy "mutable" jest ładnie ogrodzony klamerkami tak by było wiadomo, że zły krok i urwie nogę.

No i jeśli chodiz o optymalizację to poza wydajnością pojawia się też pojęcie zajętości. Czuli O(1) może się tyczyć zarówno szybkości jak i tego ile pamięci zajmują struktury danych. I jak masz mieć zajętość O(1) czyli stałą to nie ma siły – masz ograniczony obszar pamięci niezależny od wejściowego n i coś tam musisz w tym obszarze mutować.

Także absolutnie nie jest tak, że Functional Programming,Fanfary i świętujemy. ale może lepsze zrozumienie teorii pozwoli lepiej zrozumieć kiedy iść w stronę łatwego w zrozumieniu programowania deklaratywnego a kiedy poparte doświadczeniem programisty zanurkowanie w w podejście imperatywne przyniesie więcej pożytku niż szkody. I takie podejmowanie decyzji zdaje się nazywa „bycie inżynierem” :)

W biznesie z tego co zaobserwowałem normą dzienną są pytania „czy naprawdę potrzeba w poczekalni kanapy ze skóry aligatora za 20000 złotych czy może coś za 400 z meblowego na rogu będzie ok”. Czas może by i programiści zaczęli się zastanawiać czy mają obliczeniowy hajs na daną technikę czy nie.

Warsztaty jako edukacyjny proces społecznościowy

Dlaczego forma nauki w postaci warsztatów wydaje się według mnie najlepsza? Chociaż sam często mam potrzebę zredukowania bodźców oraz praca na ogromnych szwalniach „openspacowych” - gdzie w tle otacza nas ogromny szum – jest momentami dosyć denerwująca (i nieproduktywna - zwłaszcza jak codziennie o 16 wdzwania się "biurowy Tenor", który swoim głosem przebija nawet niemieckie techno w słuchawkach i przez 30 minut rozmawia o formatowaniu tabelek w excelu - idzie się po prostu zabić) to jednak ludzie jako ludzie żyli w gromadach od tysiącleci i ogólnie kontakty między ludzkie jak są robione dobrze to są fajne i motywujące.

No i generalnie czasem jak się siedzi tak samemu przy kompie gdzie fejsy,lajki i tweety są w odległości jednego kliknięcia by ukraść nasz cenny czas, który przeznaczmy sobie na naukę to nie idzie za wiele zrobić.A Warsztat pozwala nam uczestniczyć w wydarzeniu społecznym, które poza grupową motywacją do nauki zmniejsza tzw. „barierę wejścia w temat” bo dookoła mamy wiele osób zainteresowanych daną technologią, które mogą nam pomóc (+ do pomocy zawsze skromny prowadzący).

No i na sam koniec badania, które nie wiem czy są prawdziwe ale do pewnego stopnia potwierdzone empirycznie – że jak tylko słuchamy zapamiętamy 20-40% materiału a jak robimy to 90% (procenty pewnie wzięte z dupy). No i osobiście zawsze staram się umieścić cały materiał z ćwiczeniami praktycznymi w łatwo dostępnej formie online aby nikt się nie stresował, że jak czegoś nie zrozumie na warsztacie to już nie nadąży. Zawsze można sobie zrobić ćwiczenia na spokojnie w swoim tempie po warsztacie.

Problem systemowy - Jajko i Kura

"Szukam pracy aby zdobyć doświadczenie ale nikt nie chce dać mi pracy bo nie mam doświadczenia". Czyli standardowy problem - mamy nowy stos technologiczny - a ludzie niestety są nauczeni Javy a nie programowania. Sam to odkryłem u siebie na początku 2013 co mnie przeraziło "ja tak naprawdę umiem tylko Jave a nie Inżynierię programowania". Jakim było dla mnie szokiem gdy się okazało, że polimorfizm to nie jest dziedziczenie/interfejsy i tym podobne "odkrycia".

No i bez solidnych podstaw teoretycznych przejście od jednego paradygmatu do drugiego wymaga kolosalnej pracy. To już nie jest kwestia nauki nowego frameworka - trzeba zrozumieć koncepcje teoretyczne, które z kolei pozwolą zrozumieć pewien kontekst - co z kolei pozwoli zrozumieć np. publiczne pola to nie jest zło (a kiedy jest) oraz dlaczego izolacja operacji od danych raz jest dobra raz jest zła. I paradoksalnie widziałem, że nauka Scali na JVM idzie znacznie lepiej programistą .NET bo oni mieli te konstrukcje dużo wcześniej, te strzałki i monady nazywane u nich LINQ zdaje się.

I znowu wracamy do tego punktu "Teoria i praktyka" - jak kogoś poprostu rzucimy na projekt to może dojść do standardowego StackOverflow-Driven-Development - "Wkleję kawałek kodu z dokumentacji/stack overflow i tutaj teraz mi zadziałało. Dalsze konsekwencję? Skąd mam wiedzieć? Zobaczy się, Hejnał!!!" . Po raz kolejny uważam, że praktyka musi być uzupełniona/poprzedzona budowaniem solidnych podstaw teoretycznych.

No i to własnie będziemy to robić - wspólne budowanie fundamentów teoretycznych uzupełnione ćwiczeniami, które z jednej strony dadzą trochę praktyki małej skali ale na pewno nie zastąpią praktyki dużej skali, która można tylko zdobyć w projekcie. No ale przynajmniej skupimy się na tej cześć na którą mamy bezpośredni wpływ czyli na nas samych.

Plan Nauki

Programowanie funkcyjne

Ponieważ ludzie bardzo chcieli Javy bo na co dzień używają Javy to zaczynamy od Javy8 - Java 8 warsztat 1 (znowu przekaz podprogowy) i faktycznie chcą javy bo 60 osób się zapisało i jest mi z tego powodu naprawdę miło, że ludzie wkładają tyle zaufania w edukacje i te warsztaty.

Jednocześnie bardzo chcę równolegle prowadzić zajęcia z FP w Scali gdyż naprawdę ten język daje dużo większe możliwości jeśli chodzi o tworzenie przeróżnych konstrukcji z programowania funkcyjnego. Na początku materiał Scali i Javy będzie podobny a później w Scali zanurkujemy w bardziej zaawansowane rejony. Generalnie ludzie sobie wybiorą co im bardziej będzie pasować :)

Taka ciekawa historia. „Functional programming in Java” na początku było pisane przez tych samych autorów co „Functional programming in Scala” - później autorzy się zmienili i treść zaczęła stała się bardziej pisana „pod programistów javy”.

I do tego są zakupione dwie książki :



oraz

Pozycja do nauki scali jest znana :




Plus na bardziej zaawansowanych zajęciach wchodizmy w ScalaZ i cats

Gdyby to sobie zwizualizować na rysunku to mamy :

Po czym pojawia się kolejna ciekawa książka do nauki :

To jest o tyle ciekawe, że koleś tam już nie bawi się w rozwiązywanie problemów klasy "posortuje listę" ale próboje w duchu DDD rozwiazać problem domeny bankowej przy użyciu konstrukcji FP na poziomie scalaz czy cats.

Co daje

Czyli by jeszcze raz podkreślić – to nie nauka Scali czy Javy8 ale nauka Programowania Funkcyjnego – koncepcji mającej prawie 100 lat - przy pomocy Javy8 (bo ludzie chcieli) i NIEZALEŻNIE w Scali (bo widzę w niej niesamowity potencjał).

Programowanie Reaktywne

I podobne podejście : nauka koncepcji przy pomocy narzędzia. A tutaj mamy następującą literaturę :




I znowu to jest specjalnie tak wypisane by skoncentrować się na podejściu a w drugiej kolejności na narzędziu.

I teraz mamy

I na koniec temat, o którym mam teraz małe pojęcie czyli "reactive streams" - a że mam pojęcie małe to będziemy się uczyć razem i teraz za dużo nie napiszę

I jak do tego dołożymy typowanych aktorów z tej książki "functional and reactive modeling" to teraz

Typy i „Calculusy”

To jest dla mnie coś nowego i niezwykle fascynującego. O ile w FP pojawia się fraza „function as a first class citizen” tak dalej możemy wyjść z czymś bardziej egzotycznym – co jeśli typ zwracany też można wykorzystać jako wartość? Wtedy pojawia się „type as a first class citizen”. I oto przed nami TDD jako Type Driven Development.

Jest to o tyle ciekawe, że w tej chwili twórcy Scali pracuje nad czymś nowym zwanym „Dotty” https://github.com/lampepfl/dotty. Dotty to chyba scala 3.0 , która uwzględnia coś co nazywa się „DOT Calculus” (DOT - Dependant Object Types). Calculus to „rachunek” i mniej więcej oznacza, że ktoś coś przemyślał i jest jakaś nauka ścisła za rozwiązaniem. Inna Calculus, o którym słyszałem to lambda calculus i to to mówi np. dokładnie kiedy Funktor to Funktor (są konkretne mierzalne warunki do spełnienia) - w OOP nie spotkałem podobnego podejścia - tutaj można dyskutować godzinami czy faktura to intefejs czy klasa abstrakcyjna czy coś tam innego cytując blogi sławnych ludzi. Czasem przyjemnie to się czyta jak ludzie się kłócą ale zazwyczaj wynik jest niemeirzalny i a proces trudny do zautomatyzowania. A w takim ScalaZ w zasadzie są gotowe testy by wrzucić tam naszą customową klaskę i albo jest to Funktor albo nie jest (tak - nie wyolbrzymiam - to jest tak proste).

Haskell

Od Haskella jest Artur Czajka : https://www.gitbook.com/book/tr00per/haskell-101/details. Bardzo dobra edukacja FP.

Inne

Dlaczeo Scala a nie np. Groovy? Jak ktoś chce niech robi ale w epoce kultury masowej konsumpcji mało komu chce się cokolwiek "wytwarzać" (wklejanie cudzych demotów się nie liczy) :) 3 lata temu jak zaczynałem warsztaty ze scali w firmie to pamiętam jak taki ziom narzekał "Scali nie chce ale bym się Clojure pouczył" - Clojure nie znałem to zaproponowałem by sam zrobił warsztat i temat się uciął. Także jak ktoś chce robić Groovy niech się zgłosi i doradzimy w sprawach logistyki i takich tam. Niejaki RobertB chce robić warsztaty z Go bo podobno to tak zajebisty język, że ślina leci. Jak już się spręży to będzie okazja zobaczyć.

Podsumowanie

Zdolnych programistów podobno brakuje. I firmy chcą zatrudniać dobrych programistów i dobrzy programiści chcą pracować z dobrymi programistami. Powyżej to jest własnie taki plan by było wincyj jeszcze wincyj zdolnych programistów - na razie zainteresowanie jest. Będziemy adaptować na bieżąco - jak ktoś chce pomóc niech śmiało się zgłasza.