> > Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla
końcowego odbiorcy.
>
> Mógłbyś wyjaśnić, co masz na myśli, mówiąc 'zbyt sztywny'?

Np. to, że jego składnia jest ukłonem w stronę parserów a nie w stronę użytkowników.
Ja naprawdę wolę napisać a*b+c, niż (+ (* a b) c), i nie cieszy mnie kończenie
wyrażeń serią nawiasów tak długą, że nie sposób ich policzyć. Wolfram jest o tyle
ciekawy, że ma dwie albo trzy wewnętrznie równoważne składnie i pozwala posłużyć się
taką, jaka jest w danym miejscu odpowiednia. Jest to ważne zwłaszcza wtedy, gdy
chcemy w języku wyrazić coś nowego, np. wymagania albo zbiór danych.

[o przykładzie z dodawaniem kwadratów liczb pierwszych]

> > Z punktu widzenia klienta to nie jest zmiana wymagań, tylko *nowe*, *dodatkowe*
wymaganie (bo logicznie tak właśnie jest). A skoro tak, to klient będzie oczekiwał,
że ten drobny dodatek będzie zrealizowany przez drobny dodatek w kodzie. W wersji
imperatywnej (tej syfiastej, brzydkiej i naiwnej) *faktycznie* wystarczy coś dodać,
bez modyfikacji istniejącego kodu. W wersji funkcjonalnej trzeba wywalić cały program
i napisać go od nowa (pokażesz?).
>
> Nie rozumiem przykładu

Przykład pokazuje, że Twoja metoda funkcyjno-podstawieniowa tworzy zamknięty ciąg,
którego nie da się rozwijać. Poprosiłem o implementację nowego wymagania w tym samym
"projekcie". Pokażesz? Przecież stwierdziliśmy, że kod jest lepszy od słów.

> Ja mam w tej kwestii zupełnie inne doświadczenia.

Poproszę o implementację nowego wymagania w istniejącym projekcie.
W wersji imperatywnej jest to oczywiste - dodatkowa zmienna, być może gałąź else. Jak
to będzie w Twojej wersji?

> Pojęcia reprezentują nasze rozumienie składników rozwiązania. Jeżeli do wymagań
klienta dochodzi coś nowego, co nie jest wyrażalne przy pomocy dotychczasowego
aparatu pojęciowego

Ale właśnie jest. "Te liczby, które nie są pierwsze, też można by do siebie dodać".
Co tu jest pojęciowo nowego? Liczby pierwsze, dodawanie - te pojęcia już masz, bo już
ich używałeś w programie. Teraz odwołując się do tych istniejących pojęć ja chcę mieć
też dodane do siebie te liczby, które nie były pierwsze.

> Ale nic nie trzeba wyrzucać.

Pokaż.

> > 2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej.
>
> Ok, w takim razie weź kod fira, który przekleiłem do swojej odpowiedzi, i pokaż
nam, jak by dla niego taka analiza podstawieniowa wyglądała.

A na jakie pytanie chciałbyś taką analizą odpowiedzieć?

> Weź dowolną finansową aplikację. Tam tego typu prostych przekształceń będziesz miał
na pęczki.

Weź dowolny system, który czegoś pilnuje albo czymś steruje.
Jeszcze nie mówiliśmy o wymaganiach czasowych. Np. "woda w kranie w toalecie ma
przestać lecieć po 5s od ostatniej aktywacji czujnika zbliżeniowego". To wymaganie
jest pojęciowo bardzo proste.

> Może niekoniecznie sumowanie kwadratów liczb pierwszych, ale na przykład liczenie
bilansu zysków i strat albo kwoty wolnej od podatku.

Ale nawet w takim systemie wyobrażam sobie nowe wymaganie typu "a to coś co nie
spełniało warunku, to coś tam". I mam ten sam problem co z sumowaniem kwadratów.

> A może warto ich uczyć na językach, których nie da się zastosować w większej skali?
>
> Tylko wtedy mamy dydaktyczny problem zmiany skali.

A może to nie jest problem nauki języka, tylko nauki inżynierii programowania? Może
właśnie tego brakuje adeptom powielającym złe nawyki z prostych przykładów? Ale język
jest wtedy drugorzędny.
Przecież ten sam problem wystąpi w każdej innej dziedzinie - nie można oczekiwać, że
się nauczy kogoś architektury albo budownictwa na klockach. Tymczasem tak właśnie
ludzie podchodzą do nauki programowania - biorą książkę "Python w 24h" i jazda.

> Wydaje mi się, że nie rozumiesz jednej rzeczy.

> Jak ja Ci przedstawiam jakąś nową informację, to ja jej nie tracę, a stare
informacje nie znikają.

A jeśli są wyświetlane na ekranie smartfona? Stare muszą zniknąć, bo rozmiar ekranu
jest ograniczony.

> Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego.

Ale możesz edytować tego nowego, gdy się pomylisz.

> To, że William Szekspir umarł, nie sprawia, że nie mogę o nim mówić, nie dostając
błędu segmentacji pamięci.

Ale żółwika z nim nie przybijesz.

> Jeżeli od jakiegoś momentu postanowimy, żeby słowem "jabłko" określać konia, nie
sprawi to, że nagle wszystkie jabłka staną się końmi, ani że wszystkie dotychczasowe
użycia słowa "jabłko" będą dla wszystkich oznaczać konie.

Ten przykład jest dla mnie za trudny.

> Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i nie
zamazujesz wszystkich swoich notatek.

A jeśli piszę na tablecie?

> Trudno to sobie uświadomić,

Znowu mnie nie przekonałeś?

> Choćby w Pythonie mamy coś takiego:
[...]

Tak, Python jest źle zaprojektowany. Ale to nie jest przykład na problem z operacją
przypisania. Są języki, gdzie ten sam przykład zadziała prawidłowo i zgodnie z
intuicją. Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała
poprawnie.

> Prostota, o której ja piszę, nie jest prostotą implementacyjną, ale prostotą
pojęciową

I to jest dobre określenie. Podoba mi się i zgadzam się z nim. Za wyjątkiem
oczywiście tego, że pomijanie aspektów implementacyjnych jest zwykle krótkowzroczne i
sprawdza się tylko w prostych albo jednorazowych (często te cechy są razem)
przykładach.
Zgodzę się jednak, że prostota pojęciowa to dobry cel w wielu zastosowaniach. Myślę
jednak, że proponowane przez Ciebie rozwiązania zostaną kiedyś zastąpione przez coś w
rodzaju asystentów AI, jak Wolfram Alpha:

https://www.wolframalpha.com/input/?i=sum+of+first+s
even+prime+numbers

Jest prostota pojęciowa? Jest. Właściwie prościej się nie da.
Pozostaje zastosować to w większej skali, np. systemu finansowego. Nie mam
wątpliwości, że taki jest właśnie kierunek rozwoju.

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