> Nie wiem. Być może pod jakimiś względami jest lepsze.
> Choćby pod takim, że jeżeli funkcja może potencjalnie mieć efekt uboczny, to
informacja o tym musi być zawarta w jej typie.

To jest pomysł z dobrymi intencjami, ale bardzo trudno się go praktykuje w większej
skali. W SPARKu jest tak:

http://docs.adacore.com/spark2014-docs/html/lrm/subp
rograms.html#global-aspects

Dalej dokładamy do tego komplikację z kierunkami (czy coś jest czytane czy pisane a
może oba, itd.) i zanim się orientujemy mamy tego więcej, niż właściwego kodu
aplikacji - czyli skupiamy się na młotku.
Jest to bardzo wysoka cena za niejasną wartość dodaną.
Dlatego rozwiązaniem może być automatyczna inferencja takich zależności.

> Albo pod takim, że stosunkowo łatwo wyabstrahować od konkretnego świata i
dostarczyć mockową implementację zachowania skutków ubocznych na potrzeby testów.

To też dobry pomysł. Ale bez przesady z tym abstrahowaniem - przecież nie jest tak,
że progam fizycznie czymś macha albo kręci. Program w najlepszym razie modyfikuje
jakieś zmienne - a to, czy te zmienne są do czegoś przyczepione (np. do rejestrów
I/O) to już jest inna warstwa, i to właśnie w tej innej warstwie można sobie dowolnie
abstrahować. Czyli cudowanie z osobnymi typami I/O nie jest potrzebne do tego, żeby
skutecznie zrobić mocka do testów.

> Albo pod takim, że owe "inne reguły" są mimo wszystko podporządkowane pewnemu
prostemu matematycznemu rygorowi.

Żadna pociecha. To tak, jakbyś się cieszył, że coś się równo podarło. Nadal jest
słabo.

> Chciałem jedynie zwrócić uwagę, że zarówno Haskell jak i Ada uważa ten podział za
istotny i oferuje jakieś środki do wyrażania go.

Tak. Programistom C/C++ pozostaje jedynie przyjąc konwencję, że jak coś ma skutki
uboczne, to jest to "funkcja" zwracająca void, w przeciwnym razie jest to czysta
funkcja zwracająca cośtam. Próbowałem tą konwencję stosować, nawet się sprawdza.

> (Tym niemniej, spotykam czasem ludzi, którzy uważają, że imperatywny program
napisany w Haskellu jest lepszy, bo... no bo tak)

A ja potem spotykam ich twórczość w postaci np. implementacji MD5...

> Pytam dlaczego podział na czyste funkcje i dokonujące efektów procedury jest dobry.

Bo, jak każda inna konwencja, również ta jest dodatkowym kanałem komunikacji między
autorem a czytelnikiem kodu. Co więcej, w odróżnieniu od komentarzy, taka konwencja
może być też zrozumiała dla automatów analizujących kod.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 2019-01-16 11:13, Maciej Sobczak wrote:
>> Naucz sie wreszcie normalnej/prawidlowej nomenklatury,
>> bo troche wstyd...
>> Jak juz to _funkcyjnosc_, a nie funcjonalnosc.
>
> Ale o analizie funkcjonalnej pewnie słyszałeś, co?
>
> Functional Analysis == Analiza funkcjonalna

Tak. Tu się przyjela w matematyce ta terminilogia

> Functional Programming == Programowanie funkcjonalne

Tu nie. Nie błaźnij się.
PS: Moze jeszcze "ucze się Algol-a czy Fortra-na" ?

> I tak żadne z tych słów nie jest polskie, ale przynajmniej jest konsekwentnie.

Tak, ale poprawne tłumaczenie to: funkcyjne
Funkcjonalny (spełniający swą funkcję, przydatny) to może być jakiś
przyrząd, a jezyk programowaia równiez ale w zupełnie inym znaczeniu
- spełniający pokładane nadzieje, użyteczny.

PS: C++ może byc funkcjonalny, ale funkcyjny juz na pewno nie :).

AK

do góry

On 2019-01-16 12:01, g...@g...com wrote:
> Prawdopodobnie, od słowa "funkcjonał" pochodzi nazwa "analiza funkcjonalna"[...].

Dokladnie tak!

AK

do góry

On 2019-01-16 12:01, g...@g...com wrote:
> Bardziej interesuje mnie, dlaczego według Ciebie podział na czyste funkcje i
dokonujące efektów procedury jest dobry.

Sprawa jest prosta. Takie funcje to moga byc "czyste funkcje" (dla tych
samych argumentow daja te same wyniki). Szerokie pole do optymalizacji.
I to nei tylko narzedziami jezykow funkcyjnych (chociaz tez: jestem jak
najbardzie za!) ale tez innych/zwyklych typu cachowanie wynikow, lazy
itp). Czyli jest tojak najbardzie cenne i wcale nei psuje
"imperatwnosci" jezyka.

AK

do góry

> > Functional Analysis == Analiza funkcjonalna
>
> Słowo funkcjonał pochodzi z rachunku wariacyjnego, gdzie oznacza funkcję, której
argument jest funkcją

Czyli mamy funkcje wyższego rzędu.

> > Functional Programming == Programowanie funkcjonalne
>
> Programowanie funkcyjne - filozofia i metodyka programowania będąca odmianą
programowania deklaratywnego, w której funkcje należą do wartości podstawowych

Czyli mamy funkcje wyższego rzędu.

To jest ten wspólny mianownik.

> Raczej nie posiłkowałbym się w tych sprawach terminologią angielską,

W ogóle tego nie robię. Wskazuję tylko, że wygodnie mieć podobne relacje
terminologiczne. Może powinienem przedstawić je inaczej:

Functional Analysis -> Functional Programming
Analiza funkcjonalna -> Programowanie funkcjonalne

Nie widzę powodu, żeby tą wygodną analogię burzyć, ale nie narzucam nikomu tego
rozumowania.

> zważywszy na wkład, jaki Polacy mieli w rozwój analizy funkcjonalnej.

Zgadza się.

> Jak byłem mały, to kiedyś tata zabrał mnie do Warszawy, gdzie kupił mi hot-doga w
budzie o nazwie "Dania Fast Food".
> Przez długi czas naprawdę myślałem, że to był duński hot-dog.

Racjonalnie.

--
Maciej Sobczak * http://www.inspirel.com

do góry

> PS: Moze jeszcze "ucze się Algol-a czy Fortra-na" ?

Ja nie wnikam, czego się uczysz. :-)

> Tak, ale poprawne tłumaczenie to: funkcyjne

Poprawne według kogo?

> Funkcjonalny (spełniający swą funkcję, przydatny) to może być jakiś
> przyrząd

Masz rację - w języku angielskim tak właśnie jest. Np. it's a very functional device.
Z jakiegoś powodu postanowili jednak nie ograniczać użycia tego słowa tylko w tym
znaczeniu i postanowili mieć tez functional programming.
Nie rozumiem, dlaczego my musimy mieć "lepiej".

> PS: C++ może byc funkcjonalny,

Łomatko! AK napisał coś dobrego o C++. Ten post przejdzie do historii. :-D

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu środa, 16 stycznia 2019 13:15:53 UTC+1 użytkownik Maciej Sobczak napisał:
> > > Functional Analysis == Analiza funkcjonalna
> >
> > Słowo funkcjonał pochodzi z rachunku wariacyjnego, gdzie oznacza funkcję, której
argument jest funkcją
>
> Czyli mamy funkcje wyższego rzędu.

Pewien rodzaj funkcji wyższego rzędu, których dziedziną są funkcje rzeczywiste, a
przeciwdziedziną - liczby rzeczywiste. Na przykład całka oznaczona.

> > > Functional Programming == Programowanie funkcjonalne
> >
> > Programowanie funkcyjne - filozofia i metodyka programowania będąca odmianą
programowania deklaratywnego, w której funkcje należą do wartości podstawowych
>
> Czyli mamy funkcje wyższego rzędu.

Dowolne (obliczalne) funkcje wyższego rzędu.

> To jest ten wspólny mianownik.

Gdyby to był "wspólny mianownik", należałoby mówić "analiza funkcyjna".
Ale nie. Analiza funkcjonalna dotyczy funkcjonałów. Programowanie funkcyjne dotyczy
funkcji.

> > Raczej nie posiłkowałbym się w tych sprawach terminologią angielską,
>
> W ogóle tego nie robię. Wskazuję tylko, że wygodnie mieć podobne relacje
terminologiczne. Może powinienem przedstawić je inaczej:
>
> Functional Analysis -> Functional Programming
> Analiza funkcjonalna -> Programowanie funkcjonalne

Problem z językiem angielskim (i z tego co sprawdziłem, również francuskim), jest
taki, że słowo "functional" jest homonimem, który może funkcjonować (!) jako
przymiotnik (funkcyjny/funkcjonalny) oraz jako rzeczownik (funkcjonał).

W języku polskim nie ma tego problemu.

Nie upieram się przy tej interpretacji, bo rzeczywiście ktoś mógłby chcieć uzasadnić,
że gdyby anglosasi chcieli powiedzeć "funkcyjny", to zrobiliby sobie słowo "functive"
(choć wtedy my moglibyśmy to sobie tłumaczyć jako "funktywny". I bądź tu mądry)

Wydaje się, że "programowanie funkcyjne" powoli bardziej się uciera w języku (o czym
świadczy np. istnienie artykułu na Wikipedii), i bardziej nadaje się do tłumaczenia
złośliwych gierek słownych (disfunctional -> dysfunkcyjny), ale to raczej kwestia
historycznego przypadku, niż jakiejś głębokiej prawdy o świecie.

Dlatego nie zamierzam poświęcać temu zagadnieniu ani jednego słowa więcej.

do góry

On 2019-01-16 13:27, Maciej Sobczak wrote:
>> PS: C++ może byc funkcjonalny,
> Łomatko! AK napisał coś dobrego o C++. Ten post przejdzie do historii.:-D

..."może byc". - to nie znaczy, że jest ! :)

AK

do góry

On 2019-01-16 13:27, Maciej Sobczak wrote:
>> PS: Moze jeszcze "ucze się Algol-a czy Fortra-na" ?
>
> Ja nie wnikam, czego się uczysz. :-)
>
>> Tak, ale poprawne tłumaczenie to: funkcyjne
>
> Poprawne według kogo?

W/g slownika jezyka polskiego i w/g polonistow.

>> Funkcjonalny (spełniający swą funkcję, przydatny) to może być jakiś
>> przyrząd
>
> Masz rację - w języku angielskim tak właśnie jest.

Niewazne jak, jest w angielskim!.
Wazne, ze w jezyku polskim "funkcjonalny/ne" _jest juz zarezerowane
dla zgola innego znaczenia_ (i to dlugo przed jezykami programowania).

"funkcjonalny
1. <<dobrze spełniający swoją funkcję>>
"

Dlatego (dla odroznienia) nalezy uzywac "jezyk funkcyjny" (i tak bylo
od lat 50tych i powinno byc dalej):

- "Assembler jest jezykiem funkcjonalnym" (prawda - np. do pisania
driverow).
- "Assembler jest jezykiem funkcyjnym" (nieprawda).

AK

do góry

On 2019-01-16 13:37, g...@g...com wrote:
> W dniu środa, 16 stycznia 2019 13:15:53 UTC+1 użytkownik Maciej Sobczak napisał:
>> Czyli mamy funkcje wyższego rzędu.
>
> Pewien rodzaj funkcji wyższego rzędu, których dziedziną są funkcje rzeczywiste,
a przeciwdziedziną - liczby rzeczywiste. Na przykład całka oznaczona.

A nie jest tak, że przeciwdziedziną, też są funkcje?
Pytam bo nie pamietam, ale np. splot funkcji (np. w analizie Fouriera)
to funkcjonał, którego wynikiem jest funkcja/je właśnie.

AK

do góry