W dniu wtorek, 15 stycznia 2019 08:03:18 UTC+1 użytkownik Maciej Sobczak napisał:
> > W Haskellu jest (z grubsza) podobnie.
> > Tzn. tam wszystko jest funkcją, ale procedury są emulowane za pomocą typu IO,
który ma inne reguły kompozycji, niż zwykłe funkcje.
>
> Obrzydliwość. "Procedury są emulowane" - fuj. Ani odrobinę nie jest to lepsze od
funkcji, która zwraca obrzydliwy pół-typ void, który tu i ówdzie też ma inne reguły.

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.
Albo pod takim, że stosunkowo łatwo wyabstrahować od konkretnego świata i dostarczyć
mockową implementację zachowania skutków ubocznych na potrzeby testów.
Albo pod takim, że owe "inne reguły" są mimo wszystko podporządkowane pewnemu
prostemu matematycznemu rygorowi.

> To również pokazuje, że funkcjonalność jest paradygmatem sztucznym i nie
odzwierciedla potrzeb i szkodzi zdrowiu. Skoro krytykujesz C i C++ za to, że nadużyły
pojęcia funkcji do niewłaściwych celów, to konsekwentnie powinieneś też krytykować
Haskella za to samo. :-)

Robię to. Tzn. mnie haskellowe rozwiązanie nie przekonuje, i traktuję je najwyżej
jako ciekawostkę akademicką.
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.
Rozwiązanie z Ady uważam za naturalniejsze - tym bardziej, że nawet sami twórcy
Haskella używają na określenie działania typu IO słowa "magic".

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

> > > Język tego nie wymusza, ale naturalnie łatwiej wtedy o konwencję, że funkcje
robi się "czyste" a procedury zostawia się na te okazje, kiedy efekty uboczne są
celowe.
> >
> > A dlaczego to jest dobre? ;]
>
> Efekty uboczne? Bo świat ma efekty uboczne, już o tym pisaliśmy.

Nie o to pytam. Pytam dlaczego podział na czyste funkcje i dokonujące efektów
procedury jest dobry.