InterruptedException
2019-01-07 01:48

#Haskell #FP Aktualnie pracuję w teamie uzywającym mocno functional programming. Również Haskell obok Ocaml, F#. Zauważyłem i cieszy mnie to niezmiernie, że niektórzy z was zadeklarowali chęć nauki Haskella jako technologię do opanowanie w 2019. Haskell pojawił się więcej niż raz. Super.

Od siebie moge zaproponować kurs https://github.com/data61/fp-course. W mojej aktualnej firmie jest on obowiązkowy jako onboarding dla nowych pracowników. Polecam również kanał Briana który rozwiązuje ten kurs live: https://www.youtube.com/channel/UCHqC8N7FMMRRNIo-hUNtiQA

DisQ

Z materiałów ogólnie dostępnych można polecić: http://learnyouahaskell.com/, a z książek np. HaskellBook

lion137

" W mojej aktualnej firmie jest on obowiązkowy jako onboarding dla nowych pracowników" Po prostu serce roście!:)

Alag

Co to za firma? Ciężko znaleźć firmy z takim stosem...

siloam

Tworzycie oprogranowanie w Haskell'u? Jeżeli nie to lepszym wyborem imho będzie https://mostly-adequate.gitbo[...]ostly-adequate-guide/content/

DisQ

@siloam: z czystej ciekawości, czemu uważasz, że JS będzie lepszym wyborem?

siloam

Ponieważ znajomość pisania w JS jest ogólnie przydatna. Masa ofert pracy na froncie. Bez JS ani rusz, a Haskell to mimo wszystko bardzo niszowy język.

n0name_l

Lol. A po co ktoś miałby robić proteze FP w javascriptcie? Żeby stracić jedna z najważniejszych rzeczy - Type checking? :D

vpiotr

Nauka FP w każdym języku (może poza COBOLem) może być ciekawa. Niekoniecznie praktyczna. Do JS jest przecież już n nakładek: ScalaJs, GHCJS, Haste, Elm, ReasonML, ClojureScript... A poza tym w zasadzie większość wiodących języków ma swoje pozycje literackie dotyczące programowania funkcyjnego (w tym C++ i PHP). W gołym JS to pewnie trzeba sobie więcej wyobrażać niż jest w składni (podobnie jak OOP), ale nie rozumiem hejtu na ten język. Może za mało w nim robię. Te auto-konwersje którymi straszą rzeczywiście dają do myślenia.

DisQ

@siloam: znajomość jest ważna ale uważam (może się mylę, nie siedzę w froncie) że gdyby napisać kod JS'owy w stylu funkcyjnym tak jak przedstawione w książce która podlinkowales to nie przeszedłby on 99,9% code review. Trzeba pamiętać że kod się pisze głównie dla innych programistów, a nie dla wyższego celu używania tego czy tamtego

lion137

Kwestia jest bardziej podstawowa, po co w ogóle pisać kod JS, mało go już jest?:)

vpiotr

@lion137: dokładnie, npm install left-pad i robota jakoś idzie.

Hispano-Suiza

@lion137: To jest lenistwo albo ograniczenie umyslowe :D Mam dwoch ze studiow i obaj prezentuja fanatyzm pisania w tym wszystkiego. Bo jeden jezyk do wszystkiego i tyle. Nie przemowisz do rozsadku :P

vpiotr

@Hispano-Suiza: niestety od czasu gdy na rynku są WebAssembly i TensorFlowJs to w wielu zastosowaniach mogą mieć rację. Kiedyś to były czasy.

siloam

@DisQ: a kto będzie robić ten cr? Jeżeli osoba mająca jakiekolwiek pojęcie o współczesnym JS (ES6 i wyżej) to kod zaakceptuje z pocałowaniem ręki. Funkcyjnie w JS pisze się całkiem przyjemnie. Nie musisz korzystać z funkcyjnego paradygmatu cały czas, ale takie koncepcje jak higher order functions czy funkcje lambda ułatwiają znacznie pisanie kodu. Poza tym sprawdzanie błędów jest prostsze, bo funkcja powinna Ci zwracać nowy stan aplikacji. Kod masz modułowy, łatwo coś wymienić bez straty czasu. W pracy korzystam z FP w JS bardzo często..

Hispano-Suiza

@vpiotr: WebAssembly litości. Pytam teraz poważnie - używałeś gdzieś na produkcji? Znasz kogoś kto używał? Swoje projekty się nie liczą. Mam tych JSowców trochę w okół i żaden w pracy nawet się o WA nie otarł. TensorFlow inna sprawa. @siloam Dlaczego zatem nie TS?

vpiotr

@Hispano-Suiza: co jest nie tak z WebAssembly?

Hispano-Suiza

@vpiotr: Dla mnie? Wszystko okej. Tylko jeszcze nie widziałem żeby ktoś gdzieś jej używał. Tutoriale i artykuły się nie liczą.

vpiotr

@Hispano-Suiza: jakbyśmy wszyscy myśleli w tych kategoriach to COBOL jeszcze długo byłby na topie.

siloam

@Hispano-Suiza: Nie wiem jak teraz, ale kiedyś kod JS wypluty przez kompilator TS czy CoffeScript nie należał ani do zbyt optymalnych ani zwięzłych.

InterruptedException

@Alag @lubububu firma to https://www.ansarada.com/. W haskellu robimy moduł powiedzmy to dumnie nazwany AI.

jarekr000000

@siloam z tym mało optymalny, TypeScriptem to mega dziwne. Bo w zasadzie wywalane sątypy i już masz kod JS. Niektóre konstrukcje (np enum) kompilują sie do NICZEGO.
Dla mnie ten TS jest zbyt prymitywny własnie - ciągle za barzo wyłazi spod spodu JS (by design niestety). Ale raczej nieoptymalność względem JS to jakaś kolejna legenda. (Może jest jakaś specyficzna konstrukcja, słabo kompilowana, ale nie wiem, nie kojarze).

siloam

@jarekr000000: Widziałeś jakiś biznesowy kod JS wytworzony przez kompilator TS? Zobacz sobie np. https://github.com/surveyjs/surveyjs/releases otwórz wersję niezminifikowaną (np projektu dla vue) i potem sobie wmawiaj, że to legenda.

n0name_l

Ja widziałem. Nawet kilkanaście. Nie spotkałem się natomiast nigdy, żeby był problem z wydajnością z powodu używania TS...

siloam

@n0name_l: Wydajność kodu JS w tych projektach nie była pewnie jakiś głównym celem. Produkowany kod jest rozwlekły, z licznymi helperami mającymi np. upodobnić JS do języków działających w oparciu o klasy. To co normalnie zajmuje w JS kilka kinijek kodu po napisaniu w TS i kompilacji zajmuje kilkanaście/kilkadziesiąt.

jarekr000000

@siloam: pracuje z TS i wiem mniej więcej jak działa. Nie jestem miłośnikiem TS (ale JS nielubię jeszcze bardziej). Moim zdaniem powielasz bzdurne legendy (znowu) i przykład, który podałeś to pokazuje. Projekt ma około 1 MB źródłowego TS. Przy czym fakt, że wlicza się w to wszystkie frameworki (wrappery), ale trudno wydzielić na szybko co jest czemu potrzebne (np. wrapper do angulara zajmuje tylko kilka ( 8) kilobajtów). Przyjmijmy, że baza + vue to około 900k (źródłowego ts).
Wynikowy JS to 3MB mniej więcej. O matko jak rozwlekle... z tego prawie 2 MB to dołączony .map (Abyś mógł debugować). Można ten .map wywalić - co zresztą się robi. Btw. plik wynikowy nadal jest w sensie znaków dłuższy, bo czasem ts generuje rozwlekłe nazwy... (__WEBPACK_IMPORTED_MODULE_0__localization_english__ ) ale to raczeje kodu wynikowego nie spowalnia:-). Btw. , żeby zobaczyć jak mniej wiecej TS kompiluje wejdź na http://www.typescriptlang.org/play/ - building raytracer. TS dołącza Ci też przeważnie różne polyfille, które też możesz wyłączyć. Zasadniczo prawda, że kompilator TS nie generuje zbyt optymalnego i zwięzłego kodu, bo on w zasadzie wprost przepisuje to co klepiesz jako źródła i niewiele zmienia (nie poprawia). Jakkolwiek, w niczym nie jest gorszy od JS pod tym względem.

siloam

@jarekr000000: Ale o czym Ty do mnie piszesz? Przecież nie pisałem o pilkach .map ani o zmiennych używanych przez webpacka. TS robi kilka rzeczy czy trzeba czy nie trzeba np. dorzuca metody sprawdzające typy, dorzuca metody do emulacji systemu klas z których potem korzysta. Robi to niezależnie czy ktoś tego potrzebuje czy nie.

jarekr000000

@siloam: dorzuca metody sprawdzające typy to ciekawe. Może metody dorzuca, ale raczej prawie nigdy tego sprawdzania nie robi ( z tego co pamiętam). Nie znam wszystkich opcji TS, ale generalnie brak sprawdzania typów w runtime czasem do niezłych błędów prowadzi. TS robi kilka sprawdzeń przy konstrukcji klas. Ale to chyba tyle. Na wydajność nadal nie ma wpływu.

siloam

Co do typów to pewnie masz rację, bo notacja type guardów to w sumie syntactic sugar dla wstawiania metod sprawdzających właściwości w obiektach. Myślę, jednak że każdy dodatkowo wykonujący się kod ma wpływ na wydajność. Model klas w Pythonie ma na nią wpływ i podejrzewam, że podobnie jest też w innych językach. Tylko, że w prostych skryptach tego nie widać.

n0name_l

TS by design nie sprawdza typów w runtime, a klasy zwykłe (w sensie te znane z Javy) masz od es6 w górę.. A Ty widziałeś w ogóle jakiś kod, w którym samo użycie TS było bottle-neckiem? Ewentualnie cokolwiek gdzie problemem wydajnościowym był mało zwięzły kod, a nie zaimplementowany algorytm? Bo mi to szczerze mówiąc nawet ciężko sobie wyobrazić sytuację, w której nie użycie TS rozwiązuje jakikolwiek problem z wydajnością.