> 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