W dniu wtorek, 8 stycznia 2019 10:42:29 UTC+1 użytkownik Maciej Sobczak napisał:
> > > 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.

Mógłbyś wyjaśnić, co masz na myśli, mówiąc 'zbyt sztywny'?
Dyskutowałem kiedyś z jednym gościem na Quorze. Gość pracował kiedyś dla Wolframa i
był chyba w jakimś stopniu entuzjastą Mathematiki (nazywa się Jon Harrop, jeśli to
coś mówi)
Zadałem mu małe wyzwanie związane z tematem, którym się akurat zajmowałem w ramach
pracy magisterskiej.
Temat był raczej niszowy, bo dotyczył konwersji programów z rekurencją do takich, w
których rekurencja się nie pojawiała (zamiast tego używa się tzw. kombinatora punktu
stałego).
Konwersję mam przedstawioną w dodatku do swojej pracy magisterskiej:

https://github.com/panicz/master-thesis/blob/master/
chapters/B.tex

Jon napisał swój odpowiednik w języku Wolframa, i choć nie zdołałem go przekonać do
Lispa, sam określił swoje rozwiązanie mianem bełkotu

https://www.quora.com/Why-is-Haskell-not-homoiconic/
answer/Jon-Harrop-2/comment/31109783

> > 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?).

Nie rozumiem przykładu i nie wiem, skąd bierze się Twój wniosek. Ja mam w tej kwestii
zupełnie inne doświadczenia.
Programowanie funkcyjne polega przede wszystkim na definiowaniu pojęć, przy pomocy
których wyrażasz rozwiązanie problemu.
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, to wówczas trzeba ten aparat rozszerzyć, tzn. podefiniować nowe
pojęcia. Ale nic nie trzeba wyrzucać.

> 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.

Tzn. jaki przykład?

> 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.

Ja nie twierdzę, że programowanie funkcyjne to panaceum na wszystkie problemy. Sam
dużo programuję imperatywnie, i jakoś sobie z tym radzę.
Ja mówię przede wszystkim o uczeniu się programowania: o dostrzeżeniu, że niemożność
analizy programu w terminach podstawień też jest pewnym kosztem (który może czasem
można zamortyzować, a czasem warto ponieść).

> 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ń.

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.

> > 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.

Weź dowolną finansową aplikację. Tam tego typu prostych przekształceń będziesz miał
na pęczki.
Może niekoniecznie sumowanie kwadratów liczb pierwszych, ale na przykład liczenie
bilansu zysków i strat albo kwoty wolnej od podatku.

> > 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

Tylko wtedy mamy dydaktyczny problem zmiany skali.

> > 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.

Moim zdaniem pokazywanie języka to zachowanie na poziomie przedszkolnym.
Dlatego cenię książki Lispowe, o których wspominałem, że w nich język w ogóle nie
jest kwestią, i zamiast na nim i na "językowych ficzerach" można się skupić po prostu
na przykładach użycia języka, czyli na wypowiedziach.
C++ przyzwyczaja pokolenia programistów do "językowych ficzerów".
Natomiast książki pokroju SICP czy PAIP uczą się, że możemy najpierw próbować wyrazić
problem w dogodny dla nas sposób, a dopiero później wykombinować, co z owym
wyrażeniem ma robić komputer.

> > > > 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.

Wydaje mi się, że nie rozumiesz jednej rzeczy.
Ta rzecz jest może trudna do wyjaśnienia, bo jest bardzo abstrakcyjna, wszędobylska,
a przez to trudna do uchwycenia.
Jak ja Ci przedstawiam jakąś nową informację, to ja jej nie tracę, a stare informacje
nie znikają.
Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego.
To, że William Szekspir umarł, nie sprawia, że nie mogę o nim mówić, nie dostając
błędu segmentacji pamięci.
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.
Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i nie
zamazujesz wszystkich swoich notatek.

Trudno to sobie uświadomić, bo to są rzeczy, które się nie dzieją. Jesteśmy
przyzwyczajeni do tego, że się nie dzieją.
Operator przypisania nie ma swojego odpowiednika w świecie językowym czy pojęciowym,
w którym żyjemy na co dzień.
Unikanie go sprawia, że programowanie staje się równie proste i naturalne, co
mówienie.

Właśnie dlatego nie kupuję Twojego argumentu: kiedy ja mówię o niemutowalności, to Ty
mówisz "świat taki nie jest". Ale my nie mówimy teraz o świecie, tylko o języku, i ja
odpowiadam na Twój obraz świata: "język taki nie jest".

Wprowadzenie operatora przypisania rodzi bardzo wiele nieoczywistości w różnych
sytuacjach.
Choćby w Pythonie mamy coś takiego: możemy być przyzwyczajeni traktować zapis "x +=
y" jako skrót dla "x := x + y".
Jest tak na przykład wtedy, kiedy x i y odnoszą się do liczb całkowitych:

>>> x = 5
>>> y = x
>>> y += 2
>>> y
7
>>> x
5

ale jeśli napisalibyśmy
>>> x = [1,2,3]
>>> y = x
>>> y += [4,5]
to oczywiście
>>> y
[1,2,3,4,5]
ale - co już mniej oczywiste
>>> x
[1,2,3,4,5]

Jedni mogą twierdzić, że to jest dobre zachowanie, inni że złe, ale dla mnie to jest
jeden z tych problemów, które wolę obejść, niż rozwiązywać, bo którego nie można
dobrze rozwiązać a priori.

I owszem, jeżeli jesteśmy przyzwyczajeni do tego, że programowanie to "mówienie
komputerowi, co ma robić", to takie programowanie, o którym ja tutaj mówię, można
uznać za iluzję - często trudniej sprawić, żeby efekt działał wydajnie, co - w
zgodzie z tym, co piszesz, można widzieć jako pewien koszt. Prostota, o której ja
piszę, nie jest prostotą implementacyjną, ale prostotą pojęciową, bądź też prostotą
mentalnego modelu programowania.

> > > > 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?

Nie wiem, w jaki oni sposób uczą Pythona, ale podejrzewam, że nadal są pod tym
względem ostrożni.

> > 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?

Właśnie w taki sposób, że na podstawie badań empirycznych wyszło im, że wyjmując
operator przypisania z języka unikają bardzo wielu nieporozumień.