Programowanie Funkcyjne (dyskusja)...

Hej,
rzucam kolejny temat, tak ogólnie... Generalnie trochę liznąłem programowania funkcyjnego: ML, Dr Racket, Oz, Haskell, i podoba mi się tego typu kodowanie... i myślałem, że to bardzo niszowe dopóki nie natknąłem się na Scalę... Mam parę pytań, aby ułatwić dyskusję (wymianę opinii może lepiej)...

1. Czy macie jakieś "funkcyjne" doświadczenia ? Jeżeli tak, to jakie i co o tym sądzicie ?
2. W jakim celu tworzy się języki programowania, które okazują się niszowe... ?
3. Jak widzicie przyszłość tego programowania ?
4. Co sądzicie o Scali ? (opcjonalnie, bo już gdzieniegdzie wyczytałem na ten temat)... :)

Pozdrawiam... :)

1. Tak, obecnie w pracy Elixir a tak hobbystycznie to trochę lispów, Haskell i programowanie funkcyjne tam gdzie można było (i.e. Rust).
2. Z tego samego powodu, dla którego tworzy się języki, które nie okazują się niszowe: potrzebujesz rozwiązać problem i wychodzi na to, że lepiej wyjdzie napisać cały język, który to obsłuży. Przecież nikt na etapie projektowania języka nie wie czy język będzie niszowy czy nie.
3. Programowanie funkcyjne ma dużą przyszłość, bo oferuje praktycznie za darmo rzeczy, które są przynajmniej ciężkie w innych językach, głównie chodzi tutaj o zrównoleglenie obliczeń. Jak masz język, gdzie wszystko jest czystą funkcją i nie masz mutowalnych danych, to bardzo łatwo można rozproszyć wszystkie obliczenia, bo masz pewność, że dane nie będą musiały być synchronizowane między sobą.

Czy macie jakieś "funkcyjne" doświadczenia ? Jeżeli tak, to jakie i co o tym sądzicie ?

Mam sporo doświadczenia w Scali. OOP wymieszany z FP, ale bez skrajnego FP jak w scalaz/cats. Co sądzę? Funkcyjne kolekcje, niemutowalne klasy wartościowe itp itd są mega spoko. Ułatwiają pisanie czytelnego i testowalnego kodu, którego nie trzeba mockować na każdym kroku.

W jakim celu tworzy się języki programowania, które okazują się niszowe... ?

Jak ktoś nie ma tyle hajsu co Google, Sun (przejęty przez Oracle) czy Microsoft to ciężko będzie mu wypromować swój język. Niszowe języki są zwykle tworzone przez entuzjastów bez tony hajsu. Chociaż z drugiej strony Scala cały czas pnie się w górę.

Jak widzicie przyszłość tego programowania ?

Programowanie funkcyjne wchodzi nawet małymi krokami do Javy (vide vavr.io). Podstawowe elementy programowania funkcyjnego jak funkcyjne kolekcje i niemutowalne klasy już się popularyzują. Rzeczy typu monady IO pewnie nie wydostaną się z niszy, ale to już jest takie trochę bardziej zaawansowane (a nawet powiedział bym skrajne) programowanie funkcyjne. Jak ktoś chce w to iść to i tak najpierw pasuje opanować podstawy (tzn mieć z nimi obycie), czyli kolekcje funkcyjne i niemutowalne klasy.

Co sądzicie o Scali ? (opcjonalnie, bo już gdzieniegdzie wyczytałem na ten temat)... :)

Programuję komercyjnie w Scali od 2014 roku i sobie chwalę :) Składnia prosta nie jest, ale składnia takiego C++ czy Rusta też nie jest prosta. Z tym, że zaawansowane konstrukcje składniowe Scali często wykorzystuje się do implementowania biznesowych funkcjonalności podczas gdy w C++ zaawansowana składnia służy do oszczędzania taktów i bajtów, a w Ruście jest sporo ceremonii z opanowaniem borrow checkera i jego kontroli poprawności wskaźników (co też nie pomaga implementować funkcjonalności biznesowych, a raczej w łapaniu błędów). JVM (używany przez Scalę) ma garbage collectora, który rozwiązuje z automatu wszelakie problemy ze wskaźnikami, które w Ruście czy C++ trzeba ceremonialnie ogarniać ręcznie.

Ja o programowaniu funkcyjnym coś zacząłem słyszeć 2 lata temu, zacząłem się na serio interesować rok temu. Generalnie wraz z OOP stanowia "zabójczy duet" - stosuje typowe dla OOP mechanizmy typu klasy, polimorfizm, enkapsulacje + korzystam z elementów FP - głównie niemutowalne obiekty(w tym kolekcje) + monady. Trochę musiałem się przyzwyczaić ale moim zdaniem w miarę optymalnie łącze OOP i FP :)
A jak wspomniał @Wibowit pewne elementy FP są coraz bardziej popularne, np. w Kotlinie data classy są niemutowalne ;)

1. co prawda obecnie pisze glownie w javie, c i pythonie ale niezaleznie od jezyka robie to funkcyjnie jesli tylko moge (tzn nie ogranicza mnie np wydajnosc albo zwyczajna wygoda), jesli moge do uzywam (mozliwie czysto) funkcyjnych jezykow, chocby do pobocznych projektow
2. a w jakim celu robi sie nieoplacalne biznesy? :)
3. mysle ze fanatyczna funkcyjnosc pozostanie na konferencjach i innych uniwersytetach, jesli chodzi o bardziej praktyczna to np taka scala jest dobra opcja, przynajmniej w sektorze finansowym, na ta chwile ciezko mi wymienic duzy bank ktory jej nie uzywa, w morgan stanley czy hsbc strategiczne projekty sa tworzone wlasnie w scali, na razie zeby sie zalapac wystarczy dobra java i chec uczenia sie scali ale wydaje mi sie ze przyszlosc moze zmienic ta sytuacje na korzysc scali
4. na moj gust niepotrzebnie skomplikowana i za bardzo pozwalajaca na kodowanie po javowemu

1. Kodzę w Scali, jarałem się Haskellem, wgryzałem się w catsy, monady, kategorie, Idrisa.
2. Łączenie FB z OOP i resztą wydaje się lepszym połączeniem, niż dogmatyczne trzymanie się samego FP.
3. Lubię ją, bo nie traktuje programisty jak tumana i nie ogranicza go na każdym kroku.

ad 1. Ło panie.... (zacząłem gdzieś w 98 od SML, ale długo myślałem, że to tylko for fun. Z tym, że w miedzyczasie opanowałem programowanie bieda-funkcyjne w C++ i w Javie - nawet przed przesławnymi lambdami).
ad 2. Nie wiem - spytaj Goslinga. Pamiętam, jak Java była niszowa i wszyscy z niej się śmialiśmy.
ad 3. Jestem zryty - rozdzielam programowanie na Funkcyjne i Dysfunkcyjne - przyszłości dla tego drugiego w poważnym biznesie nie widze (jakieś skrypciki, może)
ad 4. Przyszłość Scali jest niepewna - Ci którzy chcą nieco lepszej Javy z nieco lepszym wsparciem dla FP - mają kotlina. Ci którzy chcą ostrego FP - mają Haskella (i jest odpływ głownych kontrybutorów do Haskella - np. https://medium.com/@fommil/scala-3-considered-as-a-new-programming-language-a335ff67e075) . Zobaczymy co się stanie po wejściu Scala 3 / Dotty.

ad 4. Przyszłość Scali jest niepewna - Ci którzy chcą nieco lepszej Javy z nieco lepszym wsparciem dla FP - mają kotlina. Ci którzy chcą ostrego FP - mają Haskella (i jest odpływ głownych kontrybutorów do Haskella - np. https://medium.com/@fommil/sc[...]ramming-language-a335ff67e075) . Zobaczymy co się stanie po wejściu Scala 3 / Dotty.

Do Haskella odpływają ludzie ze scalaz, a więc biblioteki, która odstrasza początkujących Scalowców. Stąd nie jest oczywiste czy ten powolny odpływ jest zjawiskiem negatywnym czy też nie.

Jeżeli kogoś interesują zagadnienia związane z programowaniem funkcyjnym to proponuję trzy kursy (kiedyś był jeden): Programming Languages A, B, C (coursera). Są to kursy z podstaw trzech języków: ML, Dr Racket, Ruby (wkrótce ruszają). Jest to jeden z fajniejszych kursów jakie robiłem, kiedyś tam, i zamierzam powtórzyć. Chyba jest możliwość zrobienia kursów za free, o ile ktoś nie potrzebuje certyfikatu. Niektóre zadanka nie są banalne, i trzeba trochę pogłówkować. Tym, że są to języki niszowe ja bym się bardzo nie przejmował, są nawiązania nawet do bardziej popularnych języków jak Java, Scala, itp. Kursy są dla średnio ogarniętych ;)

Czy macie jakieś "funkcyjne" doświadczenia ? Jeżeli tak, to jakie i co o tym sądzicie ?

Uczyłem się na własną rękę Elixira, a przy tym trochę Erlanga. Po paru miesiącach okazało się w ówczesnej pracy, że będzie projekt w Elixirze, więc zgłosiłem się do niego na ochotnika. Odpowiadałem za backend przez nieco ponad rok, a potem projekt został ubity, bo nie przynosił zakładanych zysków. Dla mnie założenia projektu były hmm wątpliwe, chciałem w nim być dla języka, a zdobyłem znacznie więcej :)

W jakim celu tworzy się języki programowania, które okazują się niszowe... ?

Niekiedy takie języki są lepsze do konkretnych zastosowań. Zdarza się też, że ich twórcy chcą mieć swój język - rozwiązania, których brakowało im w języku X, a są w Y, ale nie lubią w Y tego czy owego.

Jak widzicie przyszłość tego programowania ?

<yoda>Mglista przyszłość tego chłopca jest.</yoda>

Co sądzicie o Scali ? (opcjonalnie, bo już gdzieniegdzie wyczytałem na ten temat)... :)

Scala to pomost między programowaniem funkcyjnym a obiektowym. Sprawdzałem sobie czytając "Siedem języków..." i ogólnie wrażenia mam dość pozytywne, jeżeli ktoś już miał jakąkolwiek styczność z Javą, bo wtedy widać różnicę :) Generalnie połączenie tych dwóch paradygmatów jest czymś naturalnym i jest wzajemnie korzystne (wujek Bob myśli tak samo :) ) i to jest na plus Scali. Minusy? Wydaje się być dość wolna i ogólnie jakaś taka kobyła wielka, ale to może moje mylne pierwsze i n-te wrażenie.

1. uczyłem się Lispa (lata 90)
   Potem długo pracowałem w Pascalu.
   Po dwudziestu latach okazało się że część rzeczy w tym Pascalu robiłem funkcyjnie (podobnie jak @katelx), tyle że nieświadomie - po prostu czyste funkcje wydawały mi się przyjemniejsze w interpretacji.
   Od TP 6.0 (1990) z tego co pamiętam weszły typy proceduralne, czyli takie dzisiejsze lambdy - w linku pokazane jak można było je definiować wewnątrz funkcji.
   Ze strukturami funkcyjnymi miałem mało do czynienia.

2. żeby uczyć jakichś koncepcji (Logo), robić wyspecjalizowane czynności (SQL, Prolog, Fortran), spełniać konkretne wymagania (COBOL, Ada, Rust).

3. taka sama jak OOP (soft w 100% w jednym paradygmacie będzie rzadki).
   Większość języków będzie miała opisane funkcyjne możliwości, te które będą się nadal rozwijały będą miały dodawane możliwości funkcyjne.
   Języki ściśle wymagające FP pozostaną niszowe.

4. na razie nic nie sądzę. Może powinienem się zainteresować, ale mam inne rzeczy na głowie.

1. Tak. XSLT -> dzieki temu wiem jak na pewno programowanie funkcyjne nie powinno wygladac.
2. Dla zabawy/funu/cwiczenia/sprawdzenia sie/rozwiazania konkretnego problemu czy grupy problemow
3. Przejmie kawalek tortu, czesc nowych projektow bedzie tak robiona, ale lwia czesc softu bedzie robiona jak teraz, czyli z grubsza obiektowo. Raczej bedzie powolna ewolucja niz rewolucja.
4. Wydaje sie fajna ale dopiero sie wgryzam w temat w wolnym czasie.

Mam doświadczenia z książek "Little Schemer" i "How to Design Programs". Wiele osób chyba myśli, że programowanie funkcyjne da im wolność i nie będą już musieli używać tych paskudnych obiektów i klas tylko łatwych do zrozumienia funkcji. Oczywiście można programować w taki najbardziej naiwny sposób w stylu (fold(map(filter x))) tylko czym to się różni od pradawnego programowania proceduralnego z funkcjami. Te dwie książki, o których pisałem są przeznaczone dla początkujących ale żeby je zrozumieć trzeba poświęcić dużo czasu. Przekazywanie rekurencyjne funkcji która kolekcjonuje wartości, reprezentacja obiektów za pomocą lambd, jakieś nieoczywiste abstrakcje Y-combinatory. To wszystko nadaje się na uczelnie/ do zabawy a nie do problemów prawdziwego życia. Programiści mają programować a nie uczyć się matematycznych teorii, rachunku lambda czy czego tam jeszcze.

Srebrny Wąż napisał(a):

Mam doświadczenia z książek "Little Schemer" i "How to Design Programs". Wiele osób chyba myśli, że programowanie funkcyjne da im wolność i nie będą już musieli używać tych paskudnych obiektów i klas tylko łatwych do zrozumienia funkcji. Oczywiście można programować w taki najbardziej naiwny sposób w stylu (fold(map(filter x))) tylko czym to się różni od pradawnego programowania proceduralnego z funkcjami. Te dwie książki, o których pisałem są przeznaczone dla początkujących ale żeby je zrozumieć trzeba poświęcić dużo czasu. Przekazywanie rekurencyjne funkcji która kolekcjonuje wartości, reprezentacja obiektów za pomocą lambd, jakieś nieoczywiste abstrakcje Y-combinatory. To wszystko nadaje się na uczelnie/ do zabawy a nie do problemów prawdziwego życia. Programiści mają programować a nie uczyć się matematycznych teorii, rachunku lambda czy czego tam jeszcze.

Czyli tak de facto nie masz żadnego doświadczenia komercyjnego związanego z programowaniem funkcyjnym, a jednocześnie bezpośrednio uderzasz w cały paradygmat mówiąc, że nadaje się jedynie na uczelnie/do zabawy. Ma sens, weźmy na przykład takiego Netflix'a - jak powszechnie wiadomo, mała firemka skierowana głównie na marnowanie swoich zasobów poprzez wprowadzanie języków korzystających z paradygmatu, który do niczego się nie nadaje.

Wyprowadzając Cię z błędu, wiele osób nie myśli, że programowanie funkcyjne da im wolność i nie będą musieli używać obiektów i klas. Przykładowo taka Scala łączy oba paradygmaty i na rynku trzyma się całkiem dobrze, a wręcz ostatnimi czasy umacnia. Jedne problemy da się łatwiej rozwiązać w jednym paradygmacie, inne w drugim, nie ma na to reguły i złotego środka. Wiadomo za to, że nie bez powodu niektóre koncepty z programowania funkcyjnego przenikają do języków czysto obiektowych, na przykład Javy.

Lambdy są już dostępne w większości mainstreamowych językach, nie musisz stosować żadnych "nieoczywistych abstrakcji Y-combinatory", nie musisz znać żadnej matematycznej teorii czy "czego tam jeszcze". Można wykorzystywać Monady, Funktory czy inne Monoidy nie mając żadnych podstaw matematycznych. Inną kwestią jest to, że nie bez powodu mówi się, że programy napisane czysto funkcyjnie są łatwiejsze do utrzymania i rozwoju, oczywiście ten aspekt ma związek z tym, że duża część powstającego kodu obiektowego jest po prostu słaba jakościowo.

Paradygmat funkcyjny można rozwinąć w absurdalnym kierunku, ale jednocześnie to samo można zrobić z paradygmatem obiektowym, np: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

Jaki jest sens wygrzebywania najbardziej absurdalnych przykładów dla danego paradygmatu i skreślania go na ich podstawie?

vpiotr - Normalnie. Czytam książkę, rozwiązuję zadania przedstawionymi metodami i doświadczam różnicy między podejściem funkcyjnym a niefunkcyjnym. Myślę, że to lepsze niż branie przykładu z osób którym tylko się wydaje, że piszą funkcyjnie....

1. Użyłem słowa doświadczenie bo tak było sformułowane pytanie "czy macie jakieś funkcyjne doświadczenia..."
2. Tak czasami myślę jak by to było być księdzem.
3. Nie biorę narkotyków.