🚀 go-pugleaf

Sebastian Kaliszewski powiada:

[ciach zmienne globalne - nie używać i tyle]

> Zapisz cały odpowiadający kod a nie kawałek. skąd pochodzą 
> errorAhandler i errorBhandler? Przecież nie z powietrza?

Nazwy procedur. Nie muszą być albo-albo (argumentowane z góry
albo lokalnie zdefiniowane w tym miejscu) tak samo jak wyjątki.
Można np. użyć biblioteki do obsługi błędów.

>> Kilka postingów temu postawiłeś tezę, że używanie kontynuacji 
>> nie ma sensu w językach typowanych dynamicznie.
>
> Nie prawda. Nie postawiłem takiej tezy.

OK, po prostu wyczytałem to z ,,W przypadku języków dynamicznych 
i tak nie bardzo widzę zaletę. To co ma sens w językach statycznie 
typowanych często nie ma już sensu wdynamicznie typowanych.'' 
i stąd polemika - ale skoro doprecyzowujesz to no problemo.

> w językach dynamicznych w których wszelkie podstawowe 
> konstrukcje (wykonanie warunkowe, powtarzanie) są 
> zaimplementowane bez opierania się o kontynuacje, 
> kontynuacje nie mają sensu do obsługi sytuacji wyjątkowych.

Ja widzę taką korzyść: funkcje to podstawowa cegiełka programowania,
z którą można prosto i łatwo zrobić mnóstwo rzeczy gotowymi narzędziami 
(dowolnie je przekazywać, komponować, transformować, agregować, wrzucać
w mapę itd) - choćby wspominanymi przez ciebie metafunkcjami. 
Z tym samym blokiem kodu, ale wrzuconym w specjalną statyczną 
składnię tylko-dla-wyjątków da się bez zamotanego mambodżambo już 
zrobić bardzo niewiele (pominąć albo skleić tylko w jednej możliwej 
kolejności). Dla mnie to jak różnica między programem posługującym
się na stdin i stdout czytelnym formatem tekstowym możliwym do 
obróbki narzędziami shellowymi, a takim który dłubie w pliku z blobem
binarnym, z którym da się zrobić tylko to co z góry przewidziano. 

> Mowa o wiedzy czy coś wypadło z błędem. 

Nie, ja piszę o innym aspekcie - wiedzy czy w danym fragmencie
kodu przewidziano obsługę wszystkich potencjalnych błędów.

> Praktycznie to samo masz ze specyfikacjami wyjątków z głupiej Javy. 
> Nie skompiluje się, jeśli nie ma statycznie zapewnionej (a raczej 
> zamarkowanej) obsługi wszystkich błędów.

Kompilator sprawdzi tylko poprawność formalną.

> kod niby porządny-kontynuacyjny się fatalnie rozwija 
> (do momentu kiedy nie ulegnie degeneracji). Każda zmiana 
> dodająca w jednej głupiej funkcji wymaga dodania nowego 
> parametru w każdym miejscu wołania 

W razie zmiany interfejsu, a nie implementacji. No i bardzo dobrze, 
po takiej zmianie naprawdę trzeba skorygować wszystkie przypadki
użycia - przynajmniej widać czarno na białym, które już poprawiono 
a które jeszcze nie. Jeśli zmienił się kontrakt, a stare wywołania 
są nieodróżnialne od nowych to dopiero jest problem logistyczny 
z przeprowadzeniem całości kodu do nowej wersji.

> Jest tak samo jak ze statycznymi specyfikacjami wyjątków. Albo czas 
> rzetelnego sprawdzenia leci w kosmos albo i tak jest na oko.

Tu jest różnica z brakiem jawnej specyfikacji czegokolwiek
- pewien rodzaj enkapsulacji, uniezależniający od siebie poprawność
odrębnych kawałków programu. Dzięki temu czas sprawdzania właśnie
nie rośnie wykładniczo, bo można to zrobić dla każdej funkcji 
oddzielnie. Więc doceniam wrzucanie wyjątków w sygnaturę (ale to 
jest tylko w javie AFAIK), tylko nie wiem po co wprowadzać wtórny
system [quasi]typów dla argumentów ukrytych składniowo (wyjątków).

> kluczowym ficzerem obsługi błędów przez kontynuację 
> jest przerzucanie obsługi błędów wzwyż.

Mam wrażenie (na podstawie przykładowego kodu), że masz zafiksowany 
w głowie sposób obsługi błędów poprzez wyjątki i każdą alternatywną 
metodę wyobrażasz sobie przez takie jej naginanie żeby innymi środkami 
programować nadal na modłę wyjątków. Nie jest kluczowym ficzerem, 
bo tak się da ale to jednak niekonieczne, można też zupełnie inaczej.

>> Nie wiesz konkretnie które z wywołań zadeklarowanych blokowo 
>> do łapania/przerzucania wyjątków rzuca które z nich,
>
> ??? Podkręć jasność.
>
> except WyjątekA łapie obiekty klasy WyjątekA 
> a except WyjątekB łapie obikety klasy WyjątekB.

Nie wiadomo z którego calla ten wyjątek wyleciał, nie zawsze
wynika to z klasy wyjątku. Przy czym nie chodzi mi o moment łapania 
błędu w runtimie, tylko o czytelność przy uprzednim go sprawdzaniu.

> Zatem gdzie widzisz różnicę między napisaniem:
>
> funkcja(x, y, z, on_a, on_b)
>
> a funkcja(x, y, z) throws a, b

W tym że jedno wywołanie wygląda funkcja(x,y,z,on_a,on_b), a drugie 
funkcja(x,y,z) - chyba oczywiste. W pierwszym wypadku czytając 
takie wywołanie od razu wiem że obsługę błędów przewidziano. 
I ona oczywiście może być niepoprawna, ale to kwestia sprawdzenia 
tamtego kodu, tu na razie jest ok. W drugim nie mogę odfajkować
poprawności właśnie oglądanego kodu dopóki nie sprawdzę w wielu
innych miejscach - w szczególności punktach wołających aktualny
kawałek kodu. Które w trakcie rozwoju programu mogą się jeszcze
pojawiać albo zmieniać, więc tak czy siak zostawiam tykającą bombę. 

>>> Tak samo jest z kontynuacjami. 
>> 
>> Nie tak samo, bo od razu wiem że błąd jest obsłużony,
>
> Jak?

Tak że podano kontynuację dla wyjątkowego przypadku (i jeśli jest 
to onGeneralFailure albo None to od razu to widzę). Z wyjątkami
mogę to wiedzieć na podstawie tego, że wpisano łapanie wyjątku.
Ale. To jest zupełnie gdzie indziej w kodzie. W wielu miejscach.

[wpisywanie śmieci]
> I dlatego odpowiednio ograniczona (choć wystarczająca) 
> forma kontynuacji jaką są wyjątki jest w takiej 
> sytuacji lepsza, bo trudniej wszystko cwaniacko rozwalić. 

Na tej zasadzie to równie dobrze można dla każdego catcha wpisać 
pass. Przecież pisałem od początku o QA, a nie magicznym wzroście 
poprawności jednoosobowo pisanego programu dzięki używaniu silverbullet.
Tak naprawdę to największym zagrożeniem nie jest to, że programista
przewidzi wszystkie błędy i do ich obsługi perfidnie wpisze śmieci.
Tylko że normalny programista z definicji (niezależnej od znajomości
języków programowania) uważa że wszystko pójdzie dobrze, i koncentruje
się na przebiegu algorytmu w poprawnych sytuacjach. A przetykanie kodu 
możliwościami niepowodzeń na każdym kroku jest dla niego upierdliwe.

>> Jak na zachęcanie to strasznie dużo roboty na takie obejście. 
>> A sprawdza się je prosto i tylko raz - w definicji wołanej procedury
>> (sprawdzenie jej jest i tak nie do uniknięcia, więc ta sama robota).
>
> W językach dynamicznych sprawdzenie jest przy użyciu.

Nie piszę o działaniu programu, tylko czytelności.

>> po dopisku throws cośtam jeszcze nie wiadomo czy 
>> tak powinno być czy nie, i gdzie tkwi problem. W drugim przypadku 
>> wszystko co potrzebne do wypatrzenia partactwa jest na miejscu.
>
> No właśnie nie widzę tego na miejscu.

call funkcja(x,y,z, None, onGeneralFailure) //- ja widzę jak na dłoni.

> To, że w różnych rzadko używanych językach zwykle nie widzisz takiego 
> kodu wynika moim zdaniem *tylko i wyłącznie* z faktu że są właśnie 
> rzadko używane, a więc nie są używane przez przeciętną programistyczną 

Kiedy właśnie o to chodzi że widzę. Błędy są zawsze, tylko w języku
czytelnym je o wiele łatwiej dostrzec niż w kryptycznym. A jeszcze 
trudniej z przeoczeniami. Rzeczy opisywane jawnie przy czytaniu widać, 
niejawnych trzeba się domyślać i robić reverse-enginnering.

-----

> conajmniej część tych cech produkcyjnych łapie się w semantykę. 
> No i w ogóle częścią Erlanga są określone np. założenia wydajnościowe 
> (choć można dyskutoweać czy to semantyka czy nie -- w każdym razie 
> są języki gdzie np. specyfikuje się koszt asymptotyczny określonych 
> operacji). 

Dla mnie to raczej kwestia implementacyjna - ale skoro się
zgadzamy co do meritum to nie ma sensu spór o nazewnictwo.

>>>> Zamyka efekty uboczne w piaskownicy, niezły wynik.
[...]
> Dla mnie to to jest sandbox wywrócony na lewą stronę :)

Na prawą: możesz narobić efektów ubocznych, ale tylko wewnątrz
monady, bez zaśmiecenia nimi całego środowiska.

> Wartość niepoznawalna przede wszytskim jest i jest niezmienna. 
> Można się nią normalnie posługiwać poza samym poznaniem. 

Zmienność się modeluje funkcjami.

> Świat (stan zewnętrzny) to nie jest wartość w normalnym 
> rozumieniu tego słowa, jest np. jednorazowy (nie dziwne nie daje się 
> cofnąć ani zatrzymać), itd...

Bo masz rozumienie wartości z ubogich języków. Wartością pierwszego
rzędu może być nie tylko stała, ale również bez problemu funkcja 
(nawet z funkcji w funkcje) - więc świat może być np. ciągiem 
statycznych stopklatek, a ciąg już się bardzo ładnie modeluje.

> Tzn. typ w którym reprezentuję niepoznawalną stałą Chatina jest dla mnie 
> jak najbardziej normalnym typem, jego wartości mogę przypisywać, 
> przekazywać do wywołań, brać jako wyniki, itd. A tu guzik.

Też możesz, od tego m.in. są monady stanowe. Nawet w zapisie
to wygląda podobnie jak używanie zmiennych w komputacji imperatywnej.

> Ogólnie zadania w których pewne akcje zależą od wcześniej 
> wykonanych, od wyników (i błędów) występujących wcześniej. 

No to niech zależą, funkcjami się opisuje właśnie zależności
- wystarczy je wpisać w parametr funkcji. Naprawdę takich nie
widziałeś, np. szkolnego przykładu generatorów kolejnych liczb 
pierwszych, zależnie od tego jaka była ostatnia policzona? 

> Funkcyjnie możesz zapisać stan wewnętrzny, ale ze stanem zewnętrznym 
> (czas systemowy, zewnętrzne źródło danych losowych, etc.) jest gorzej. 
> Albo zamiata się pod dywan tworząc pseudowartości których się nie daje 
> traktować jak wartości i udaje że wszystko ok, 

To jest wewnętrznie sprzeczne - właśnie się da tak traktować, i dlatego
marudzisz że to udawanie, bo jednak działa. Wymyśliłeś jakąś ezoteryczną
kategorię pseudowartości (?), ale tam nie ma żadnego zaszytego w środku
kompilatora hacku - to jest w bibliotece, zamodelowane normalnymi 
mechanizmami języka, dało się zrobić jak wszystkie inne funkcje.


Piotr Sawicki