Notes from Kraków Lambda Lounge meetup [PL]

lambda_lounge_notatki.md

Notatki z Lambda Lounge meetup

Ogólnie:

• immutability
• higher-order functions
• first-class functions
• stan przekazywany explicit w argumentach, a nie przechowywany gdzieś tam i zmieniany w miejscu przez nie wiadomo kogo
• referential transparency - funkcja dostając dane argumenty zawsze zwróci tą samą wartość
• nie ma rozróżnienia na == vs. equals
• primitive obsession
• czytelniejszy kod, prostsze testowanie i debugowanie
• łatwiejsza współbieżność
• nowy punkt widzenia, stymulacja mózgu ;)
• podobny sposób myślenia jak w matematyce
• znajomość języków funkcyjnych pozwala pisać lepszy kod w językach imperatywnych/obiektowych
• może być trudno znaleźć ludzi do pracy i pracę (języki dla samotnych wilków)
• kod napisany przez jednego wymiatacza może być niezrozumiały dla innego

Ocaml

• jakaś firma w USA pisze w tym soft do gry na giełdzie
• poza tym mało kto tego używa

Lisp

• można w nim napisać wszystko
• Paul Graham w nim napisał Yahoo Store
• kod traktowany tak samo jak dane
• mało kto tego używa, przynajmniej w Polsce

Clojure

• współpraca z JVM
• kod traktowany tak samo jak dane
• trochę bardziej popularny niż zwykły Lisp
• niektórzy z Ruby/Rails community się przenoszą, są biblioteki do web development
• jakiś startup w Krakowie

Erlang

• dobrze rozwiązana współbieżność
• nacisk bardziej na współbieżność niż funkcyjność
• jest trochę dużych firm które tego używają

Haskell

• bardziej “true” niż reszta
• mało popularny

Scala

• współpraca z JVM
• multi-paradigm, więc łatwiej się przerzucić i łatwiej przekonać team lub znaleźć ludzi
• ale też łatwiej iść na łatwiznę i nie pisać całkiem funkcyjnie
• jeszcze za szybko się zmienia żeby była enterprise-ready
• Twitter, Yammer, jest parę firm w Krakowie

Do listy "Ogólnych"

• Pierwsze pięć punktów z listy ogólnie były punktami takiej jakby listy filarów funkcyjnego programowania.
• referential transparency = referencyjna transparentność, albo idempotencja funkcji
• dobra znajomość języków funkcyjnych; zrozumienie ich, pozwala na pisanie lepszego kodu imperatywnego / obiektowego. Zapoznanie się z nimi - niekoniecznie (vide "a co było nie tak z pętlą for?").
• czytelniejszy kod, prostszy w odpluskwianiu czy testowaniu - bierze się to z braku stanu, zatem będzie taki, o ile nie będziemy pisać w językach funkcyjnych imperatywnie... Bo da się tak pisać.

Obiecane linki

• Paul Graham i Yahoo Store
• Wikipedia w temacie
• C2Wiki o Paulu i Yahoo
• Dla wilków vs Dla owiec
• http://c2.com/cgi/wiki?LispIsTooPowerful
• Yammer odchodzi od Scali

Powody dla których się chcemy uczyć FP

• coś nowego
• nie mogę zrobić czegoś w imperatywnym języku, sięgam po funkcyjny
• chcę być poliglotą
• inne spojrzenie na świat
• było dużo innych, niemała część jest w sekcji Ogólnie w punktach Kuby

Inne

Cytat niedokładny:

Nie mówmy o programowaniu obiektowym. Ono jest trudne i wielu, jak o nim mówi, nie rozumie go i mówi tak naprawdę o programowaniu imperatywnym.

"referential transparency = referencyjna transparentność, albo idempotencja funkcji"

referential transparency to co innego niż indempotency:
http://en.wikipedia.org/wiki/Idempotence
http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)