siloam

Programowanie funkcyjne jest fajne. Kod jest krótszy i naturalnie modułowy. Ale ma też wady. Np. Clojure jest sporo wolniejsze od Javy. Ba, Stream API jest wolniejsze od klasycznego javowego for'a. Jest tak dlatego, że procesory działają w sposób imperatywny. Ilość przekształceń danych jest mniejsza, więc taki kod jest szybszy. Cóż... nie można zjeść ciastko i mieć ciastko.

Michał Kuliński

@siloam Zabawne jest to, że odpalone pod JVM trochę żabkuje, a odpalone pod ClojureScript w przeglądarce śmiga, aż miło.

jarekr000000

@siloam: prawda. A do krowa jest rośliną, bo je trawę.

siloam

@jarekr000000: Tutaj, tutaj, tutaj, tutaj Ogólnie problem jest znany od dłuższego czasu.

jarekr000000

@siloam nie myl streamów lambd i javy z programowaniem funkcyjnym. Jak popatrzysz w komentarze to i tak te testy były trochę zrypane (np. ten https://blog.overops.com/benc[...]ake-your-code-5-times-slower/) . Dodatkowo - porównujesz różne rzeczy. Np. w kodzie biznesowym dodanie jednego elementu do Listy niemutowalnej (vavr) jest de fakto szybsze niż do mutowalnej :-) (bo w tej drugiej i tak musieliśmy robić ciągle defensive copying w każdym wielososobowym projekcie się w koncu człowiek tego uczył) - po przejściu na vavr (wczesniej guave) można było defensive wyrzucić. TLDR nie mówię, że fp jest też szybsze - to inny styl kodowania i ma inne własności. A procesor może jest imperatywny, ale javy też nie umi zarózno tej imperatywnej jak i pseudofunkcyjnej.

siloam

@jarekr000000: I jeszcze tutaj i tutaj. Kod imperatywny łatwiej jednak przenosić na instrukcje procesora, co przyznają nawet twórcy Ocaml'a. > to inny styl kodowania i ma inne własności
Nie twierdzę, że nie. W 95% przypadków to lepszy styl, bo kod jest krótszy, bardziej przenośny i modułowy. Zostaje te 5%, gdy liczy się bardzo wysoka wydajność, ale kompilatory języków funkcyjnych są co raz lepsze, więc w przyszłości może nawet i to nie będzie problemem.

jarekr000000

@siloam: problemem jest to, że w językach typu Java i nawet Scala kompilator musi odpuścić dość dużo optymalizacji. Z różnych powodów. Miedzy innymi, dlatego że są by design imperatywne i np. kompilator nie może zrobić memoizacji, wywalić części zbędnych wyrażeń itd. Bo nie do końca wiadomo, gdzie są efekty uboczne. W ScaliJS zrobiono dość dużą optymalizację kodu wynikowego (głównie rozmiar) po prostej decyzji o wywaleniu runtime refleksji.