Dlaczego Python nie jest zbyt dobry do programowania funkcjonalnego? [Zamknięte]

Zawsze myślałem, że programowanie funkcjonalne można wykonać w języku Python. Byłem więc zaskoczony, że Python nie otrzymał wiele wzmianek w tym pytaniu, a kiedy zostało wspomniane, zwykle nie było zbyt pozytywne. Podano jednak niewiele przyczyn (wspomniano o braku dopasowania wzorca i algebraicznych typach danych). Więc moje pytanie brzmi: dlaczego Python nie jest zbyt dobry do programowania funkcjonalnego? Czy istnieje więcej powodów niż brak dopasowania wzorca i algebraiczne typy danych? Czy te koncepcje są tak ważne dla programowania funkcjonalnego, że język, który ich nie obsługuje, może być sklasyfikowany jako funkcjonalny język programowania drugiej klasy? (Należy pamiętać, że moje doświadczenie z programowaniem funkcjonalnym jest dość ograniczone).

Pytanie, do którego się odwołujesz, dotyczy tego, które języki promują zarówno program OO, jak i programowanie funkcjonalne. Python nie promuje programowania funkcjonalnego, chociaż działa dość dobrze.

Najlepszym argumentem przeciwko programowaniu funkcjonalnemu w Pythonie jest to, że przypadki użycia imperative / OO są uważnie rozważane przez Guido, podczas gdy przypadki użycia programowania funkcjonalnego nie są. Kiedy piszę imperatywny Python, jest to jeden z najładniejszych języków, jakie znam. Kiedy piszę funkcjonalnego Pythona, staje się on tak brzydki i nieprzyjemny, jak przeciętny język, który nie ma BDFL .

Nie znaczy to, że jest źle, wystarczy, że będziesz musiał pracować ciężej, niż gdybyś przeszedł na język, który promuje funkcjonalne programowanie lub na pisanie OO Python.

Oto funkcjonalne rzeczy, za którymi tęsknię w Pythonie:

• Dopasowywanie wzorów
• Rekurencja ogona
• Duża biblioteka funkcji listy
• Słownik funkcjonalny
• Automatyczne curry
• Zwięzły sposób komponowania funkcji
• Leniwe listy
• Prosta, potężna składnia wyrażeń (prosta składnia blokowa Pythona uniemożliwia dodanie Guido)

• Brak dopasowania wzorca i brak rekurencji ogona oznacza, że ​​podstawowe algorytmy muszą zostać zapisane bezwzględnie. Rekurencja jest brzydka i powolna w Pythonie.
• Mała biblioteka list i brak funkcjonalnych słowników oznacza, że ​​musisz sam napisać wiele rzeczy.
• Brak składni curry lub kompozycji oznacza, że ​​styl bez punktów jest tak samo pełen interpunkcji, jak jawnie przekazywane argumenty.
• Iteratory zamiast leniwych list oznaczają, że musisz wiedzieć, czy chcesz wydajności, czy wytrwałości, i rozpraszać połączenia, listjeśli chcesz wytrwałości. (Iteratory są jednorazowe)
• Prosta składnia imperatywna Pythona wraz z prostym parserem LL1 oznaczają, że lepsza składnia wyrażeń if i lambda jest w zasadzie niemożliwa. Guido lubi to w ten sposób i myślę, że ma rację.

Guido ma dobre wyjaśnienie tego tutaj . Oto najbardziej odpowiednia część:

Nigdy nie uważałem, że język Python jest pod silnym wpływem języków funkcjonalnych, bez względu na to, co ludzie mówią lub myślą. Byłem znacznie bardziej obeznany z imperatywnymi językami, takimi jak C i Algol 68 i chociaż stworzyłem funkcje obiektów pierwszej klasy, nie widziałem Pythona jako funkcjonalnego języka programowania. Jednak wcześniej było jasne, że użytkownicy chcą zrobić znacznie więcej dzięki listom i funkcjom.

...

Warto również zauważyć, że chociaż nie wyobrażałem sobie Pythona jako języka funkcjonalnego, wprowadzenie zamknięć było przydatne w rozwoju wielu innych zaawansowanych funkcji programowania. Na przykład niektóre aspekty klas w nowym stylu, dekoratorów i innych nowoczesnych funkcji opierają się na tej możliwości.

Wreszcie, mimo że na przestrzeni lat wprowadzono wiele funkcjonalnych funkcji programowania, Python wciąż nie ma pewnych funkcji znalezionych w „prawdziwych” funkcjonalnych językach programowania. Na przykład Python nie wykonuje pewnych rodzajów optymalizacji (np. Rekurencji ogona). Ogólnie rzecz biorąc, ponieważ niezwykle dynamiczna natura Pythona nie jest możliwa do przeprowadzenia w czasie optymalizacji znanym z języków funkcjonalnych, takich jak Haskell lub ML. I w porządku.

Wyciągam z tego dwie rzeczy:

1. Twórca języka tak naprawdę nie uważa Pythona za język funkcjonalny. Dlatego można zobaczyć funkcje „funkcjonalne”, ale jest mało prawdopodobne, aby zobaczyć coś, co jest definitywnie funkcjonalne.
2. Dynamiczna natura Pythona hamuje niektóre optymalizacje widoczne w innych językach funkcjonalnych. To prawda, że ​​Lisp jest tak samo dynamiczny (jeśli nie bardziej dynamiczny) jak Python, więc jest to tylko częściowe wyjaśnienie.

Schemat nie ma algebraicznych typów danych ani dopasowywania wzorców, ale z pewnością jest to język funkcjonalny. Irytujące rzeczy dotyczące Pythona z funkcjonalnego punktu widzenia programowania:

1. Crippled Lambdas. Ponieważ Lambdas może zawierać tylko wyrażenie i nie możesz zrobić wszystkiego tak łatwo w kontekście wyrażenia, oznacza to, że funkcje, które możesz zdefiniować „w locie” są ograniczone.

2. Jeśli są wyrażeniami, a nie wyrażeniami. Oznacza to, między innymi, że nie możesz mieć lambda z If w środku. (Jest to naprawione przez trójskładniki w Pythonie 2.5, ale wygląda brzydko.)

3. Guido grozi usunąć mapę, filtr i zmniejszyć raz na jakiś czas

Z drugiej strony, python ma leksykalne zamknięcia, Lambdas i wyrażenia listowe (które są tak naprawdę „funkcjonalną” koncepcją, niezależnie od tego, czy Guido to dopuszcza). W Pythonie dużo programuję w stylu „funkcjonalnym”, ale nie powiedziałbym, że jest idealny.

Nigdy nie nazwałbym Pythona „funkcjonalnym”, ale za każdym razem, gdy programuję w Pythonie, kod niezmiennie kończy się prawie wyłącznie funkcjonalnym.

Trzeba przyznać, że wynika to głównie z wyjątkowo miłego zrozumienia listy. Niekoniecznie więc sugerowałbym Python jako funkcjonalny język programowania, ale sugerowałbym programowanie funkcjonalne dla każdego, kto używa Pythona.

Pokażę kawałek kodu zaczerpnięty z odpowiedzi na „funkcjonalne” pytanie Pythona dotyczące SO

Pyton:

def grandKids(generation, kidsFunc, val):
  layer = [val]
  for i in xrange(generation):
    layer = itertools.chain.from_iterable(itertools.imap(kidsFunc, layer))
  return layer

Haskell:

grandKids generation kidsFunc val =
  iterate (concatMap kidsFunc) [val] !! generation

Główną różnicą jest to, że biblioteka standardowa Haskell zawiera użyteczne funkcje programowania funkcyjnego: w tym przypadku iterate, concati(!!)

Jedną z rzeczy, która jest naprawdę ważna dla tego pytania (i odpowiedzi) jest: Co to do cholery jest funkcjonalne programowanie i jakie są najważniejsze jego właściwości. Spróbuję przedstawić mój pogląd na to:

Programowanie funkcjonalne przypomina pisanie matematyki na tablicy. Kiedy piszesz równania na tablicy, nie myślisz o poleceniu wykonania. Nie ma (zazwyczaj) mutacji. Nie wrócisz pojutrze i nie spojrzysz na to, a kiedy ponownie wykonasz obliczenia, uzyskasz inny wynik (a może, jeśli napijesz się świeżej kawy :)). Zasadniczo to, co jest na tablicy, a odpowiedź już tam była, kiedy zacząłeś spisywać rzeczy, po prostu nie zdawałeś sobie sprawy, co to jest.

Programowanie funkcjonalne jest bardzo podobne; nie zmieniasz rzeczy, po prostu oceniasz równanie (lub w tym przypadku „program”) i zastanawiasz się, jaka jest odpowiedź. Program jest nadal niezmodyfikowany. To samo z danymi.

Za najważniejsze cechy programowania funkcjonalnego uznałbym: a) przejrzystość referencyjną - jeśli ocenisz to samo zdanie w innym miejscu i czasie, ale przy tych samych wartościach zmiennych, będzie to nadal oznaczać to samo. b) brak efektu ubocznego - bez względu na to, jak długo patrzysz na tablicę, równanie, na które patrzy inny facet, nie zmieni się przypadkowo. c) funkcje też są wartościami. które można przekazywać i stosować z innymi zmiennymi lub do nich. d) składanie funkcji, możesz zrobić h = g · f, a tym samym zdefiniować nową funkcję h (..), która jest równoważna wywołaniu g (f (..)).

Ta lista jest w mojej kolejności według priorytetów, więc przejrzystość referencyjna jest najważniejsza, a po niej nie występują żadne skutki uboczne.

Teraz, jeśli przejdziesz przez python i sprawdzisz, jak dobrze język i biblioteki obsługują i gwarantują te aspekty - jesteś na dobrej drodze, aby odpowiedzieć na swoje własne pytanie.

Python jest prawie językiem funkcjonalnym. To „funkcjonalna lite”.

Ma dodatkowe funkcje, więc dla niektórych nie jest wystarczająco czysty.

Brakuje również niektórych funkcji, więc dla niektórych nie jest wystarczająco kompletny.

Brakujące funkcje są stosunkowo łatwe do napisania. Sprawdź posty jak ten na FP w Pythonie.

Innym powodem nie wymienionym powyżej jest to, że wiele wbudowanych funkcji i metod typów wbudowanych modyfikuje obiekt, ale nie zwraca zmodyfikowanego obiektu. Gdyby te zmodyfikowane obiekty zostały zwrócone, kod funkcjonalny byłby czystszy i bardziej zwięzły. Na przykład, jeśli some_list.append (some_object) zwrócił some_list z dołączonym some_object.

Oprócz innych odpowiedzi, jednym z powodów, dla których Python i większość innych języków z wieloma paradygmatami nie są odpowiednie dla prawdziwego programowania funkcjonalnego, jest to, że ich kompilatory / maszyny wirtualne / czasy działania nie obsługują optymalizacji funkcjonalnej. Tego rodzaju optymalizację osiąga kompilator rozumiejący reguły matematyczne. Na przykład wiele języków programowania obsługuje mapfunkcję lub metodę. Jest to dość standardowa funkcja, która przyjmuje funkcję jako jeden argument, a iterowalną jako drugi argument, a następnie stosuje tę funkcję do każdego elementu w iteracji.

W każdym razie okazuje się, że map( foo() , x ) * map( foo(), y )jest taki sam jak map( foo(), x * y ). Drugi przypadek jest w rzeczywistości szybszy niż pierwszy, ponieważ pierwszy wykonuje dwie kopie, podczas gdy drugi wykonuje jedną.

Lepsze języki funkcjonalne rozpoznają te matematyczne zależności i automatycznie przeprowadzają optymalizację. Języki, które nie są dedykowane do paradygmatu funkcjonalnego, prawdopodobnie się nie zoptymalizują.