Читать книгу JavaScript funkcyjnie. Zrównoważone, pragmatyczne programowanie funkcyjne w JavaScript - Kyle Simpson - Страница 6
ОглавлениеMonada jest tylko monoidem w kategorii endofunktorów.
Czy nie straciłem właśnie czytelników? Nie martwcie się, ja też byłbym zagubiony! Wszystkie te terminy, które znaczą coś tylko dla osób wprowadzonych w programowanie funkcyjne (FP), mogą brzmieć jak bełkot dla pozostałych osób.
Z tej książki nie dowiecie się, co te słowa znaczą. Jeśli ktoś tego szuka, niech szuka dalej. W istocie jest wiele książek, które od razu uczą nas FP, od początku do końca. Te słowa mają istotne znaczenie i przy formalnej szczegółowej nauce FP, każdy z pewnością je pozna.
Ale ta książka całkiem inaczej podchodzi do tematu. Zaprezentuję tu najbardziej podstawowe pojęcia FP od początku do końca, z mniejszą liczbą specjalnych lub nieintuicyjnych terminów, które pojawiają się w innych książkach o FP. Próbuję przyjąć praktyczne podejście do każdej zasady, zamiast spojrzenia czysto akademickiego. Bez wątpienia będzie tu terminologia. Ale jej wprowadzanie będzie ostrożne i celowe, z wytłumaczeniem, po co one są, i dlaczego są ważne.
Niestety nie jestem posiadaczem karty członkowskiej FP Cool Kids Club. Nigdy nikt formalnie nie uczył mnie, jak programować w FP. I choć mam za sobą studia wyższe i niezłą wiedzę matematyczną, zapis matematyczny nie jest w zgodzie z rozumieniem programowania przez mój mózg. Nigdy nie napisałem ani jednego wiersza programu w języku Scheme, Clojure czy w Haskelu. I nie jestem ze starej szkoły programistów Lispa.
Brałem udział w dyskusjach na wielu konferencjach na temat FP, przy każdej mając desperacką nadzieję, że tym razem wreszcie zrozumiem, o co chodzi w tym całym mistycyzmie związanym z programowaniem funkcyjnym. I za każdym razem odchodziłem sfrustrowany, wszystkie te nowe terminy mieszały mi się w głowie, a ja nie miałem pojęcia, czy i czego się nauczyłem. A najdłużej nie mogłem dojść, o co w tym wszystkim chodzi.
Mając te wszystkie doświadczenia, powoli zbierałem kawałki ważnych pojęć, które wydawały się zbyt naturalne dla formalisty w zakresie FP.
Uczyłem się powoli, pragmatycznie i doświadczalnie, a nie w sposób akademicki z właściwą terminologia. Pewnie każdemu z was zdarzyło się znać jakiś temat przez długi czas, a potem dowiedzieć się, że ma on jakąś nazwę, której wcale nie znaliście!
Może jesteście podobni do mnie. Słyszałem od lat określenia takie jak „map-reduce” czy „big data” w różnych branżach, nie wiedząc, czy są one naprawdę. W rezultacie nauczyłem się co robi funkcja map(..) – na długo przed tym, zanim dowiedziałem się, że działania na listach są jednym z fundamentów na ścieżce programisty funkcyjnego i dlaczego są takie ważne. Wiedziałem czym jest odwzorowanie (map) na długo przed tym, zanim dowiedziałem się, że nazywa się map(..).
W końcu zacząłem zbierać okruchy zrozumienia w zbiór, który nazywam FLP (Functional-Light Programming, „programowanie lekko funkcyjne”).
Ale dlaczego tak ważna jest nauka programowania funkcyjnego, nawet w lekkiej postaci?
Zacząłem w coś wierzyć w ostatnich latach tak głęboko, że jest to niemal wiara religijna. Wierzę, że programowanie dotyczy ludzi, a nie kodu. Wierzę, że kod jest pierwszym i podstawowym środkiem komunikacji między ludźmi, a to, że instruuje także komputer, jest tylko efektem ubocznym (można tu usłyszeć mój stłumiony chichot).
Widzę to tak, że programowanie funkcyjne dotyczy w istocie stosowania w kodzie dobrze znanych, zrozumiałych i sprawdzonych wzorców, aby unikać błędów, które sprawiają, że kod jest trudniejszy do zrozumienia. Z tego punktu widzenia FP – lub też FLP! – może być jednym z najważniejszych zestawów narzędzi, jakie może pozyskać deweloper.
Przekleństwem monady jest, że – gdy się ją zrozumie – traci się zdolność do wytłumaczenia jej komukolwiek innemu.
Douglas Crockford 2012 „Monads and Gonads” https://www.youtube.com/watch?v=dkZFtimgAcM)
Mam nadzieję, że ta książka „być może” (ang. Maybe – gra słów z wzorcem FP) przełamie ducha tego przekleństwa, choć nie będę tu wspominał o „monadach”, aż do samych dodatków końcowych.
Formalne podejście programisty FP często zakłada, że prawdziwa wartość FP polega na stosowaniu w zasadzie w 100% podejścia wszystko-albo-nic. Wierzy się, że jeśli używamy FP w części swojego programu, a w innej części nie, to cały program jest zanieczyszczony przez rzeczy spoza FP, więc traci tyle, że nie warto stosować FP.
Mówię wyraźnie: jest to absolutnie fałszywe. Głupotą jest dla mnie sugerowanie, że ta książka może być dobra tylko wtedy, jeśli w całej użyję idealnej gramatyki i strony czynnej. Jeśli popełnię jakieś błędy, to zniszczę jakość całej książki. To nonsens.
Im więcej piszę jasnym, spójnym przekazem, tym lepsze będą efekty dla czytelników. Ale nie jestem idealnym autorem. Niektóre fragmenty są napisane lepiej od innych. Ale części, które mógłbym poprawić, nie deprecjonują innych części książki, które są użyteczne.
I podobnie jest z kodem. Im więcej zastosujemy tych zasad w większej części naszego kodu, tym lepszy będzie kod. Używajmy ich przez 25% czasu i otrzymamy pewne korzyści. Używajmy przez 80% czasu, a zobaczymy więcej korzyści. Zapewne z pewnymi wyjątkami, gdyż nie ma w tym tekście stwierdzeń bezwzględnych. Zamiast tego jest mowa o aspiracjach, celach i zasadach, do których trzeba dążyć. Będzie mowa o pragmatyzmie i kompromisach.
Zapraszam w podróż do najbardziej użytecznych i praktycznych podstaw FP. Wszyscy możemy się wiele nauczyć!
