Modele mentalne lub rzeczywiste metafory programowania funkcjonalnego

Czy ktoś ma dobry model mentalny lub metaforę programowania funkcjonalnego, która odwołuje się do czegoś w prawdziwym świecie?

Intuicyjne programowanie obiektowe ma dla mnie sens. Są rzeczy, które mają właściwości, a czasem mogą także wykonywać różne czynności lub wykonywać obliczenia dotyczące ich właściwości (metod). (Np .: samochód, kształt, kot).

Noszę programowanie funkcjonalne, które nie jest złe i nie jestem zainteresowany debatą na temat zalet tych dwóch. Potrzebuję tylko metafory lub modelu mentalnego do pracy, tak jak w przypadku programowania obiektowego.

Jakie są dobre modele mentalne lub metafory świata rzeczywistego do programowania w funkcjonalnym paradygmacie? Jest coś w funkcjach składających się z funkcji przetwarzających funkcje, które pozostawiają jedną bez mocnego miejsca, aby stać i zastanawiać się.

Programowanie funkcjonalne polega na sklejeniu mniejszych funkcji, aby osiągnąć swoje wyniki. Przyzwoity model mentalny (przynajmniej dla mnie) to linia montażowa. Każda funkcja, która się skomponuje, to kolejny krok w procesie montażu. Rozważ tę funkcję tutaj:

smallest  = head . sort

W Haskell ta funkcja zwróci najmniejszy element na liście. Linia montażowa najpierw sortuje dane wejściowe, a następnie zwraca pierwszy element (zakładając, że jest on posortowany od najmniejszej do największej). Jeśli chcielibyśmy uzyskać tylko najmniejszą parzystą wartość, możemy zmienić linię montażową, aby wyglądała następująco:

smallestEven = head . sort . filter even

To tylko jeden krok na przenośniku taśmowym.

W skrócie, funkcje opisują tylko kroki podjęte w celu przekształcenia surowego wejścia (części) w przetworzony towar (wynik).

Czy ktoś ma dobry model mentalny do programowania funkcjonalnego?

Matematyka. Programowanie funkcjonalne jest inspirowane matematyką i wzorowane na niej. Funkcje matematyczne nie mają stanu, nie mają skutków ubocznych itp., Tak samo jest z FP. Jeśli myślisz o FP w kategoriach funkcji matematycznych, a nie w stylu „OO”, jak mam to zrobić, to będziesz w dobrej formie. Jeśli jednak spróbujesz zwiększyć wrażliwość OO na FP, będziesz pływać pod prąd.

Co powiesz na flipbook ?

W flipcharcie każda strona przedstawia świat taki, jaki istnieje w danym momencie. W naszym programie świat jest reprezentowany jako pewna złożona struktura danych (np. Mamy banana, który jest w ręku goryla, który jest na drzewie w dżungli). Każda kolejna strona rozwija historię, nieznacznie modyfikując poprzednią reprezentację. W FP trwałe struktury danych zostały zaprojektowane w celu efektywnego ponownego wykorzystania poprzednich struktur, dzięki czemu zmiana zapewnia tylko różnicę, a nie całkowicie nową wersję.

To, co może nie być oczywiste, to to, że strona w naszej książce również reprezentowałaby wartości niematerialne. Na przykład, jeśli goryl upuści banana, możemy zacząć oddziaływać grawitacją na jego przyzwoitość i przyspieszenie w kierunku podłogi dżungli. Aby to uwzględnić, przypisujemy do banana takie atrybuty, jak prędkość i trajektoria.

W naszym programie istniałaby funkcja, która przyjmuje jako stronę argument strony z książką (zwany też stanem świata) i daje nową stronę . W ten sposób nasza historia jest opowiedziana bez zmiany stanu istniejących obiektów. Po prostu zastępujemy każdą stronę nowszą, używając efektywnego obliczenia.

Relacje.

Przyjaciel: Biorąc pod uwagę dwie osoby, związek z przyjacielem jest zgodny z tymi ogólnymi prawami

1. Miejcie dobrą wolę wobec siebie
2. Myślą, że są dla nich przyjacielem (więc obaj członkowie muszą przestrzegać praw w tym związku)
3. Lubi spędzać czas ze sobą

Monoid: Biorąc pod uwagę wiele przedmiotów i funkcję, która przyjmuje 2 przedmioty i zwraca 1, związek monoidalny jest zgodny z tymi ogólnymi prawami

1. Jest jeden z tych elementów (tylko jeden, zwany tożsamością), który przekazano do funkcji z dowolnym innym elementem, zapewni, że funkcja zawsze zwróci drugi element (0 + 1 = 1, zatem 0 to tożsamość, gdy elementy są liczbami, a funkcja jest dodatkiem)
2. Funkcja nie może działać na elementach spoza zestawu, z którymi ma związek monoidalny, ani na nie zwracać
3. Funkcja jest asocjacyjna i może być używana z elementami w sposób nieco niezależny od porządku, co oznacza a * (b * c) = (a * b) * c, co oznacza, że ​​możesz pomnożyć a przez wynik b * c lub c przez wynik a * b, a wynik będzie taki sam, niezależnie od tego, co zrobisz najpierw.

Programowanie funkcjonalne polega na uogólnianiu, przyjaciel jest bardzo ogólną relacją, którą można zaobserwować w wielu scenariuszach, ale we wszystkich różnych formatach ogólnie jest zgodny z powyższymi prawami.

Uznając prawa rządzące relacjami między rzeczami, możesz tworzyć ogólne implementacje, które działają na dowolnym formacie rzeczy, które mają ten rodzaj relacji. W programowaniu funkcjonalnym próbujesz zidentyfikować relacje między rzeczami, aby można je było ogólnie klasyfikować i traktować.

Chcesz metaforę z prawdziwego świata? Spójrz, jak rzeczy są powiązane i spróbuj zidentyfikować ogólne prawa (jak w przypadku wielu scenariuszy, w których rzeczy inne niż przepisy mogą się różnić). Istnieje związek między urzędnikiem rejestrującym a klientem w sklepie, ma on pewne ogólne prawa, opracowano oprogramowanie ułatwiające osiągnięcie celów ludzi w tym ogólnym związku na drodze systemów POS. Podobnie, gdy zaczniesz widzieć te ogólne prawa dyktujące, jak rzeczy są powiązane, możesz zacząć polegać na prawach tych relacji podczas pisania oprogramowania, a nie na konkretnych szczegółach wystąpienia relacji.

Wszystko jest wartością, a Ty stosujesz funkcje do wartości (które mogą być funkcjami), aby tworzyć nowe wartości, najlepiej bez żadnych skutków ubocznych.

Kluczową rzeczą do zrealizowania w programowaniu funkcjonalnym jest to, że wszystko jest wartością - nawet sam kod to „wartości”.

Najlepszym przykładem prostego funkcjonalnego środowiska programistycznego jest ulubione narzędzie biznesowe każdego użytkownika - arkusz kalkulacyjny. Każda komórka w arkuszu kalkulacyjnym to albo dane, albo wynik funkcji. Co więcej, ta funkcja nie może się wyłączyć i zmodyfikować innej komórki.

Kiedy jeden przenosi się do języków funkcyjnych, zamiast w kartezjańskim grid of A1a B42funkcje mają nazwy. To wszystko, czym tak naprawdę jest.

Są jeszcze inne aspekty, które można dodać poza tym ... ale to funkcjonalne programowanie u jego podstaw. Nie trzeba się martwić o strukturę list lub grupowanie rzeczy. Programowanie funkcjonalne polega na przekazywaniu wartości do funkcji i odzyskiwaniu wartości bez konieczności szukania gdzie indziej w pamięci.

Otóż ​​to. Programowanie funkcjonalne to arkusz kalkulacyjny z nazwami, a nie siatka.

Możesz myśleć o programowaniu funkcjonalnym jak o zachowaniach . Program to opis zachowania, które ma zostać wprowadzone w komputerze. Funkcje są podstawową jednostką zachowania, a ich składanie jest jednym ze sposobów budowania większych zachowań z mniejszych.

W OOP obiekt kodowy ma być stanem obiektu w domenie problemowej; zmienia się w czasie, aby odzwierciedlić zmiany w tym obiekcie domeny. W FP wartość reprezentuje stan obiektu domeny; nigdy się nie zmienia, po prostu tworzysz różne wartości reprezentujące różne stany.

Uważam, że model funkcjonalny jest nieco bardziej uczciwy w kwestii tego, co faktycznie robią komputery - reprezentując. W końcu nie mogę po prostu wyczarować new Tesla()powietrza. :)

Zdania są bardziej funkcjonalne niż zorientowane obiektowo, zakładając, że je rozbicie mniej więcej w następujący sposób ...

The brown cow is in the meadow across the deep river.

Musimy więc znaleźć frazy, a następnie resztę:

The cow (brown)
the meadow (across)
the river (deep)

Za jednym razem:

sentence: The cow ((the meadow (the river (deep)) (across)) brown)

Przetwarzaj drzewo:

|                     sentence
|                      /         
|                  The cow
|                 /       \
|            the meadow   brown
|            /         \
|      the river      across
|              \
|              deep

Parsimony infekuje myślenie funkcjonalne;

Czapki z głów przed Gottlieb Frege 1890, Alan Turing (entschiedungsprobleme) 1930, Noam Chomsky (1960).