> > Rozumiem. Mamy więc (niezaskakujący) wniosek, że różne języki są właściwe do
różnych problemów.
>
> Pytanie, jaki dalszy wniosek możemy wyciągnąć z tego wniosku.
> Może na przykład taki, że rozsądnie byłoby eksplorować języki,
> które ułatwiają projektowanie języków.

Zgadzam się. Dlatego, jak już wspomniałem, podoba mi się język Wolfram, bo dzięki
swojej umiarkowanej lispowatości świetnie nadaje się do tworzenia tzw.
Domain-Specific Languages. Zastanawiam się nad możliwością użycia tego do opisu
wymagań, które można weryfikować albo z których można generować właściwy kod (albo
testy).
Sam LISP jest przez swój minimalizm zbyt sztywny, żeby był użyteczny dla końcowego
odbiorcy.

> Możesz zerknąć w przykłady programów liczących sumę kwadratów
> początkowych siedmiu liczb pierwszych, które przewinęły się
> przez ten wątek (to było w odpowiedzi na post AK).
> Tam dokładnie pokazałem przykład rozumowania podstawieniowego.

Ależ ja go rozumiem i od początku staram się tu zrobić konfrontację tych koncepcji.
"Przykład rozumowania podstawieniowego" nie pokazuje żadnej przewagi nad tym
imperatywnym oryginałem, z dwóch powodów:

1. Nie widać w nim długoterminowych zalet w aspekcie utrzymania kodu. Wyobraź sobie,
że klient dostał ten program i jest zadowolony, ale przecież jesteśmy agile, więc
klient od razu wpada na nowy pomysł: "a jeszcze tak sobie pomyślałem, że te liczby,
które nie są pierwsze, też by można do siebie dodać".
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?). To jest potencjalnie poważny problem i nie tylko
dlatego, że klient nie zrozumie, dlaczego tak ma się stać.
Ten przykład w całości jest sztuczny (serio: nikt nie rozwiązuje takich problemów),
ale nie wynika z niego, że powyższy problem nie wystąpi w większej (ilościowo albo
czasowo) skali. Ciekawym aspektem do rozważenia jest to, że to, co Ty traktujesz jako
wymagania ("dodaj ... itd.") to nie są jedyne wymagania, z jakimi musi się zmierzyć
inżynier. Niejawnymi wymaganiami są też kwestie wydajności (sam widziałeś) i
utrzymanie projektu w długim terminie. "Paradygmat podstawieniowy" tych problemów sam
z siebie nie adresuje a przez to jest rozwiązaniem nie tylko niekompletnym ale może
być wręcz ograniczającym.

2. Programowanie imperatywne w żaden sposób nie wyklucza analizy podstawieniowej.
Analizatory kodu (np. takie, które sprawdzają statycznie, czy ktoś nie wyjeżdża poza
tablicę albo nie dzieli przez zero) wykonują weryfikację właśnie przez podstawienia i
przez rozwiązywanie równań.

> Większość programistów, jakich znam, nie implementuje swojego MD5.

To samo mogę powiedzieć o każdym zaproponowanym przez Ciebie przykładzie.
A jednak ktoś coś immplementuje, inaczej nie mielibyśmy roboty. Pytanie, w którym
momencie trafię na taki (lub należący do tej klasy) problem.

> Być może z dydaktycznego punktu widzenia lepiej jest, żeby
> programiści najpierw uczyli się języków, które realizują prostsze
> modele obliczeń, a dopiero później (jeśli zajdzie taka potrzeba)
> takich, które pozwalają na ścisłą kontrolę sprzętu.
> (Wiele wskazuje na to, że tak właśnie jest)

Ja bym się nawet z tym zgodził. I tu możemy wrócić do Twojej tezy, że początkujący
programiści powielają nawyki z prostych przykładów w większej skali. A może warto ich
uczyć na językach, których nie da się zastosować w większej skali? Wtedy nie będą
niczego powielać. Scratch, Logomocja, itp. - a potem, jak już się wyszaleją na
piramidkach i ciuchciach, pokazać im prawdziwy język, od razu w dużej skali. Np. C++.
:-D

> Czasem się spotykam z takim sformułowaniem, że dobry
> język powinien robić tak, żeby łatwe rzeczy były w nim
> łatwe, a trudne przynajmniej możliwe.

Zgadzam się. Ale to może być też kwestią ekspozycji - tzn. można pokazywać język
kawałkami, zaczynając od tych łatwych.

> > > Operator przypisania w językach takich jak C czy Python jest
> > > łatwo dostępny, i sprawia wrażenie, że jest prostą operacją.
> >
> > Bo jest. To jest podstawowa operacja.
>
> Podstawowa dla jakiego problemu?

Jak niewiasta chce przemalować włosy to je maluje a nie robi swojego klona z innymi
włosami. Jak mam kapcia w samochodzie to pompuję oponę a nie kupuję nowe napompowane
koło (przepraszam: nowy samochód, bo przecież do starego nie da się nowego koła
założyć). Jak mam gorzką kawę, to ją dosładzam a nie robię nową słodką. A jak chcę
zmienić kolor ściany, to ją maluję a nie buduję nowy dom. I nie zakładam nowego konta
(w nowym banku), żeby móc dostać wypłatę.
Tak ma moje oko, operacja przypisania jest podstawowa w sensie uniwersalnym. To
właśnie udawanie, że tej operacji nie ma, jest dla mnie kosztem.

> Załóżmy, że zmienimy linijkę
>
> if(++dodano==ilu) return suma;
>
> na
>
> if(dodano++==ilu) return suma;
>
> Już mamy błąd.

To jest problem kolejności operacji a nie samego przypisania (w tym przypadku
modyfikacji). Funkcje też można zaaplikować w złej kolejności.

> > > i właśnie z tego powodu w pierwszych dwóch rozdziałach SICP
> >
> > A z jakiego powodu teraz używają Pythona do nauki?
>
> Wyjaśniają w tekście, który podlinkowałeś wcześniej.

Czyli jednak można pokazywać uczniom operację przypisania od samego początku nauki?

> Polecam ten wykład:
> https://www.youtube.com/watch?v=uEFrE6cgVNY

Jak to się ma do ludzi, którzy uczyli się matematyki i nie rozumieją, że x=x+1 to nie
musi być równanie?

Ludzie, którzy zawodowo zajmują się matematyką biegle posługują się narzędziami
takimi jak Mathematica, Matlab, Octave, itp. (zależność kulturowa) i zdumiewająco
wszystkie te trzy są imperatywne i korzystają z pojedynczego znaku "=" jako operacji
przypisania, czyli:

x=5;
x=x+1;

we wszystkich tych narzędziach oznacza to samo.
Czyli najwyraźniej ludzie zajmujący się matematyką nie mają z tym problemu.

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