W dniu środa, 9 stycznia 2019 08:46:07 UTC+1 użytkownik Maciej Sobczak napisał:
> > > 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ć.

Programiści Lispa często wpadają na świetny pomysł dodania infiksowej składni dla
operatorów arytmetycznych do Lispa. To jest proste zadanie.
Później uświadamiają sobie, że mogą z łatwością dodać do Lispa taką składnię, jaką
sobie tylko wymarzą. (Trudno sobie wymyślić bardziej elastyczny język programowania)
Później - niektórzy - uświadamiają sobie, że inni też mogą łatwo wymyślać, i że tak
naprawdę żaden z tych pomysłów nie dodaje niczego, co by miało obiektywną wartość, i
że ich pomysły wyrażają tylko ich przesądy i dodają do języka przypadkową złożoność
(która np. jest trudna do objaśnienia 7-letnim dziewczynkom).
Richard Gabriel i Guy Steele nazwali ten proces "rytuałem przejścia".

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

Stephen Wolfram też ma za sobą rytuał przejścia.

> Jest to ważne zwłaszcza wtedy, gdy chcemy w języku wyrazić coś nowego, np.
wymagania albo zbiór danych.

Potrzebowałbym przykładu. Ale według moich doświadczeń jest niepotrzebne.

Tutaj mam np. "język dziedzinowy", w którym opisuję zasady gry w szachy:
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/schess/rules/ches
s.ss?at=default&fileviewer=file-view-default
a tutaj używam tego samego języka do opisania zasad wariantu wikingowskiej gry
planszowej "Hnevatafl":
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/schess/rules/ard-
ri.ss?at=default&fileviewer=file-view-default

Tutaj mam plik w swoim formacie do reprezentowania obiektów 3d:
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/art/3d/cube.3d?at
=default&fileviewer=file-view-default

a tutaj plik w formacie do opisywania układów fizycznych połączonych więzami,
reprezentujący robota humanoidalnego:
https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad
9d34a98a636d771e3875496f2d69/demos/art/rigs/rob.rig?
at=default&fileviewer=file-view-default

Wszystkie te języki są oparte na Lispowych s-wyrażeniach.
Sprawia to, że parsowanie wszystkich tych formatów jest trywialne
(wystarczy do tego funkcja "read"), i do ich przetwarzania mogę
korzystać ze standardowych narzędzi, których używam też do swojego
języka programowania.

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

Nie jestem pewien, czy rozumiem, ale jak dla mnie to "prawdziwość" tego stwierdzenia
mocno zależy od tego, jakie to konkretne będą wymagania.
Toteż chyba zamiast kodu będziesz się musiał zadowolić śmiesznym obrazkiem:
https://xkcd.com/1425/

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

Bynajmniej nie jest oczywiste. To wszystko zależy od wymagania.
Czasem może trochę tak jest, że można wprowadzić zmiany w programie,
bez aktualizacji naszego aparatu pojęciowego. Niektórzy nazywają
to "wzorcem projektowym" "big ball of mud", a inni "długiem
technologicznym".

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

To nie jest "zmiana wymagania".
To jest inny program
(ale części zdefiniowanych na potrzeby poprzedniego programu
pojęć będzie można użyć ponownie)

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

Na przykład, jaki ten program da wynik dla argumentu "7".

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

Nie wydaje mi się, żeby było bardzo proste pojęciowo.
Ale zgodzę się, że sformułowanie jest bliskie naszemu codziennemu
doświadczeniu. I zgodzę się, że można znaleźć odpowiedni język
do rozwiązania tego problemu, i że niekoniecznie będzie to programowanie
funkcyjne.

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

Nie wiem. Nie bardzo rozumiem sformułowanie "a to coś nie spełniało
warunku, to cośtam".
Ale wydaje mi się, że z tego samego rodzaju problemami zmagają się
prawnicy - oni też nieraz próbują ująć złożoną rzeczywistość w prostych
słowach, i też im to nie zawsze wychodzi.
Cała afera z "dopalaczami" opierała się właśnie na tym, że dla
każdego sformułowania sprzedawcy tych substancji wyszukiwali wyjątki
z list substancji zakazanych.

> > 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 SICP wychodzi właśnie z takiego założenia,
że ich celem jest właśnie nauka "zarządzaniem złożonością".
Właśnie dlatego pierwsze dwa rozdziały poświęcone są w całości
zasadom abstrakcji, bo to abstrakcja - a nie algorytmy czy
struktury danych - są najbardziej podstawowym narzędziem do radzenia
sobie ze złożonością.

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

To i tak możesz do nich wrócić.

> > Jak piszę nowego posta na usenecie, to nie kasuję poprzedniego.
>
> Ale możesz edytować tego nowego, gdy się pomylisz.

Sądzę, że to kwestia definicji. "Post" jest czymś, co zostało
"zapostowane".

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

Właśnie ten jest najbardziej esencjonalny.

> > Nawet w szkole, jak nauczyciel zmazuje tablicę, to Ty nie bierzesz korektora, i
nie zamazujesz wszystkich swoich notatek.
>
> A jeśli piszę na tablecie?

To chyba też nie kasujesz swoich notatek?

> > Trudno to sobie uświadomić,
>
> Znowu mnie nie przekonałeś?

Jak mówię, nie spodziewałem się, że ten przekaz zostanie zrozumiany.
Nie wiem, jak to lepiej wyjaśnić.

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

Zgodnie z czyją intuicją?
Bo spotkałem osoby, które uznawały własnie takie zachowanie za pożądane.

> Np. Wolfram. W C++ analogiczny przykład na kontenerach też zadziała poprawnie.

"Poprawnie", czyli tak, jak Ty uważasz, że jest 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.

Ja bym raczej powiedział, że jest to pewien model, który jest prosty do nauki i
pozwala na unikniecie wielu błędów, ale który jest też ograniczony funkcjonalnie.

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

Ja też nie mam.
Ale składnia języka naturalnego moim zdaniem niezbyt dobrze nadaje się do
programowania.
Formalne notacje są dużo precyzyjniejsze (i właściwie po to zostały wymyślone)