> A teraz inny przykład:
>
> int g(int x) {
> return x + 2;
> }
>
> Jaką wartość ma wyrażenie g(5)?
> Na to pytanie odpowiesz bez problemu.

Tak.

> Nie będziesz musiał zadawać dodatkowego pytania
> w rodzaju "jaka była poprzednia wartość tego wyrażenia?".

Ale to jest bardzo dobre pytanie w przypadku maszyn stanów, ogólnie. Żeby wiedzieć,
jaki będzie następny stan, trzeba wiedzieć, jaki był poprzedni. Właściwie jest to
pytanie, którego nie da się uniknąć. Albo unikanie tego pytania będzie prowadziło do
niepotrzebnych kosztów i komplikacji systemu.
Świat rzeczywisty bardzo dobrze modeluje się maszynami stanów.

> I to właśnie brak tego rodzaju pytań sprawia, że
> ten model jest prostszy.

Bo problem jest prostszy.
Ale weźmy inny przykład - dowolną implementację funkcji skrótu, np. CRC albo inne
MD5. Choćby takie coś:

https://codereview.stackexchange.com/questions/16387
2/md5-implementation-in-c11

Nie mam pojęcia, czy to jest poprawne ani ile złych nawyków tam jest. Chodzi o coś
innego - o wykorzystanie operacji przypisania jako naturalnego mechanizmu dochodzenia
w wielu etapach (być może iteracjach) do właściwej wartości końcowej. To jest inny
model, niż Twoje wyrażenia gotowe do podstawień, ale jest on częsty w realnych
problemach. Tam w środku po prostu jest maszyna stanów. To jest przykład funkcji,
która jako całość nie korzysta ze stanu globalnego ani statycznego i nie trzeba tam
pytać, jaka była poprzednia wartość. Używając nomenklatury języków funkcjonalnych,
funkcja MD5 jest "czystą funkcją". Czyli taka funkcja spełnia Twoje kryterium
prostszego modelu.

Ale jakoś implementacja takiej funkcji z użyciem operatorów przypisania jest bardziej
naturalna, niż bez nich. Tak bardzo, że implementacji bez operatorów przypisania w
ogóle nigdzie nie znalazłem (nie żebym jakoś mocno szukał[*]).
Czy w celu podparcia swoich dotychczasowych tez podjąłbyś wyzwanie napisania takiej
funkcji bez przypisań?

> Używanie statycznych zmiennych w obrębie funkcji nie jest
> niszowe. W niektórych sytuacjach jest użyteczne.

Więc dlaczego taką możliwość krytykujesz? Czy nie lepiej jest taką możliwość mieć (i
nie korzystać gdy nie jest potrzebna), niż nie mieć?

> > Czy to znaczy, że taki program jest równie dobry, jak program, w którym przypisań
nie ma?
>
> Nie rozumiem pytania.

Krytykujesz operacje przypisania jako zły nawyk albo konstrukcję niepotrzebną i
nadmiarową. Tak przynajmniej rozumiem ten (pod)wątek. Natomiast ja się z taką tezą
nie zgadzam i próbuję wykazać, że model programowania z przypisaniami (ogólnie:
imperatywny) jest nie tylko wartościowy, ale często po prostu optymalny i nie tylko
dlatego, że odzwierciedla działanie komputera, ale dlatego, że właściwie
odzwierciedla postawiony problem. Dlatego oczekuję od języka programowania, że będzie
to wspierał jako podstawową operację i konsekwentnie odrzucam języki, które tego nie
mają, jako niepraktyczne.

[*] No dobra, znalazłem:

http://hackage.haskell.org/package/cryptohash-md5

"The implementation is made in C with a haskell FFI wrapper that hides the C
implementation."

No tak. Tak było chyba *praktyczniej*, prawda?

Ale jest też wersja dla "purystów":

http://hackage.haskell.org/package/pureMD5-2.1.3/src
/Data/Digest/Pure/MD5.hs

Totalna masakra. Nie chcę też nawet pytać, co tam robią słowa "unsafe" i czy z takimi
słowami to na pewno nadal jest "pure".

W skrócie: uciekanie od imperatywności jest sztuczne i szkodzi zdrowiu.

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