W dniu czwartek, 5 października 2017 01:37:44 UTC+2 użytkownik Maciej Sobczak
napisał:
> > Można sobie pomyśleć program, który oblicza wartość jakiegoś programu
> > czysto funkcyjnego
>
> Ale nie ustaliliśmy jeszcze, co to znaczy, że program jest czysto funkcyjny.

Z tego co patrzę na historię tej rozmowy, ustaliliśmy to na dość
wczesnym etapie.

> > To, czy liczba jest pseudolosowa, czy nie jest, czy pochodzi z wejścia,
> > czy z kosmosu, nie ma znaczenia dla *ISTOTY* danego programu.
>
> I właśnie tej istoty szukamy. Jeżeli istotą jest przetwarzanie wejścia na wyjście,
to wszystkie programy w istocie takie są. Natomiast jeśli jest nią generowanie
efektów ubocznych, to też wszystkie takie są.

Otóż właśnie nie, na co również dawałem przykłady.

> > Dałem kilka kontrprzykładów. Systemy kolejkowe czasu rzeczywistego
> > nie są deterministyczną funkcją input->output. Być może mają komponenty,
> > które można w taki sposób analizować, ale ich istotą jest działanie
> > w czasie rzeczywistym, i reagowanie na zdarzenia w zależności od
> > jakiegoś ich wewnętrznego stanu.
>
> No to robimy ćwiczenie na wyobraźnię:
>
> 1. *Narysuj* zdarzenia w środowisku i otoczeniu programu, w ich rozciągłości
czasowej. Oś czasu, od lewej do prawej, z zaznaczonymi zdarzeniami, wartościami, itd.
> 2. Zrób z tego obrazka plik, np. w formacie PNG. Czyli *jedną wartość*.
> 3. Podobnie narysuj na osi czasu odpowiedź systemu na taką stymulację. Znowu, z
odpowiednią skalą czasu, wartościami (tak, żeby po złożeniu tych dwóch obrazków
powstał opis działania programu w czasie), itd.
> 4. Z tego drugiego obrazka też zrób plik.
>
> Otóż okazuje się, że Twój "system czasu rzeczywistego" przetwarza pliki graficzne.
Czyli przetwarza pojedyncze wartości. To, czy wczyta od razu cały plik z wejścia i
wypluje cały plik na wyjściu, czy też będzie je przetwarzał po jednym pikselowym
pasku wzdłuż jednego boku obrazka (czyli np. wzdłuż osi czasu, co odpowiada naszej
percepcji działania w kontekście upływającego czasu) nie ma znaczenia dla istoty tego
programu, którą jest transformacja jednego obrazka w drugi.

Problem polega na tym, że mylisz w tej chwili istotę programu ze środkami
analizy. Owszem, każdy program można analizować przy pomocy pojęcia funkcji,
albo przy pomocy pojęcia maszyny stanu, albo czegoś jeszcze innego.
Ale to nie znaczy, że te środki analizy zawsze pokrywają się z istotą programu.
W szczególności, na przykład, częścią opisu maszyny stanu jest funkcja
przejścia w inny stan -- toteż używamy pojęcia funkcji pomocniczo do
opisania maszyny stanów. Ale diagram przejść stanu jest czymś istotnie
różnym od pojęcia funkcji.

> I teraz ten cały podział nie dotyczy istoty działania programu (bo ta istota jest
zawsze taka sama), tylko sposobu, w jaki my, ludzie, danego programu użyjemy. Możemy
odpalić program jednym strzałem albo też delektować się powolnym budowaniem wyniku,
ale to jest ten sam program. Czyli dotyczy naszej percepcji a nie jest fundamentalnym
atrybutem problemu, który dany program rozwiązuje. Bo problem jest zawsze ten sam.

Problem nie jest zawsze ten sam. Projektanci kompilatorów muszą zwracać
uwagę na zupełnie inne rzeczy, niż projektanci gier komputerowych albo
stron internetowych, po w pierwszym przypadku kluczowy jest wynik, a w
pozostałych -- interakcja.
Rzeczywiście, istniał kiedyś np. program do dowodzenia twierdzeń autorstwa
Boyera-Moore'a NQTHM, który dawał użytkownikom możliwość "delektowania się
powolnym budowaniem wyniku", ale to nie należało do jego istoty.