🚀 go-pugleaf

Sebastian Kaliszewski powiada:

>> Tylko że taki kod może poprawnie obsługiwać błędy mimo braku 
>> w danym miejscu try/except.
>
> Tak samo kontynuacja zapisana gdzieś globalnie może być poprawną obsługą 
> błędu, mimo braku w danym miejscu jej jawnego przekazania. 

Przyznam że kompletnie nie chwytam o co Ci chodzi. Jakiś przykład kodu?

>> Nadal nie wyczajam argumentu, musiałbyś skonkretyzować 
>> tok rozumowania (są bez sensu - kontrprzykłady że z sensem
>> - ale tam są podstawowe - omgwtf).
>
> One mają sens gdy stosowane są do uzyskania rzeczy które w pozostałych 
> językach są kluczowe, tj podstawowe konstrukcje sterujące.

No ale są tam stosowane również przy obsłudze sytuacji wyjątkowych. 
Bezsensownie?

>> No właśnie nie - w przypadku obsługi błędów zwykłymi if-errcode
>> widać na pierwszy rzut oka czy kod był napisany już z obsługą
>> błędów czy jeszcze bez (i czy wszystkie są pokryte, w jaki sposób).
>
> Tego ostatniego nie widać bez znajomości semantyki wołanej funkcji.

To czy wszystkie (kwantyfikatorowo) to bez znajomości: errcode<>success.

>> w miejscu wywołania funkcji wiem co się stanie po powrocie.
>
> Tzn albo pójdzie normalnie, albo poleci w stornę sprawdzenia 
> błedu -- tak samo jest przy wyjątkach.

Nie tak samo, bo jest napisane czarno na białym jaka to strona.
A z exceptionami hgw gdzie poleci, trzeba sprawdzać cały program.

>> Chyba rozumiem - myślałeś że chodzi mi o metodę javową sprawdzania
>> wyjątków automatycznie. No więc nie, o czytelność kodu.
>
> Co do czytelności kodu, to i tak nie widzisz lokalnie, 
> jakie błędy dana funkcja rzuca tylko jakie są obsługiwane

A to akurat jest najmniejszy problem, żeby to sprawdzić 
wystarczy zajrzeć w jeden wskazany nazwą procedury fragment
kodu - to można mieć w ide pod klikiem. Żeby sprawdzić jaka
będzie obsługa wyjątku trzeba przeczytać zylion miejsc
kodu które mogą wywoływać aktualnie czytany kawałek.

> BTW. zrobiono w swoim czasie badania co wpływa na liczbę 
> błędów w kodzie programów pisanych w różnych językach. 

Jak znam życie to nie robili eksperymentów tylko pomiary.
W szczególności niewykrycie innych korelacji mogło wynikać 
nie z ich braku, a z przyjęcia złych hipotez badawczych.

>> Dowolny fragment kodu z licznymi wywołaniami procedur/funkcji.
>> Jeśli to jest napisane z wyjątkami to mam trzy możliwości:
>> 1) sprawdzanie wyjątku jest przy każdym wywołaniu,
>> 2) przy żadnym,
>> 3) przy niektórych.
>> W 1) wyjątki są redundante z ifami; w 2) nie wiem czy obsługa
>> błędów była przewidziana czy nie, a w dodatku przebieg sterowania
>> robi się zupełnie nieoczywisty (bo każdy call jest potencjalnym
>> exit pointem);
>
> Zupełnie jak przy kontynuacjach. 

Niezupełnie, bo wiem że może skoczyć i gdzie. I to każdy 
poszczególny call, a nie cały obleczony try-catchem blok.

> Jeśli masz statyczne specyfikacje wyjątków, to albo obsługa 
> jest na końcu funkcji (w catch / except czy jak tam autorzy 
> języka nazwali) albo w sygnaturze funkcji jest jawnie napisane, 
> że leci dalej. 

To akurat nie jest złe - ale to słabsza cecha (w sensie matematycznym).

> W przypadku kontynuacji albo masz ogólny skok 
> do miejsca gdzieś w ciele funkcji z której wołasz, 
> albo kontynuacja była parametrem 

Albo wskazujesz inny fragment kodu - continuation passing style da się
stosować nawet przy użyciu zwykłych procedur (tyle że to mało wygodne).

> tej funkcji i wiesz tyle że leci dalej. W Rumym i podobnych 
> masz jeszcze opcję, że kontynuacja była zapisana gdzieś 
> i jawnie do wołanej funkcji nigdy przekazywana nie była 
> a funkcja sobie i tak wyskoczyła.

Nie wiem jak wygląda implementacja kontynuacji w Rubym, 
więc mogę się zgodzić że ją spartaczono skoro tak twierdzisz.

> W przypadku wyjątków Każda wołana funkcja też ma swoją sygnaturę -- 
> wystarczy znać tę sygnaturę by wiedzieć jakie wyjątki wypuszcza.

Ale nie kto je łapie.

>> w 3) sprawdzenie poprawności jest pracochłonne
>> (trzeba rekursywnie sprawdzać kto ten kod wywołuje i które wyjątki 
>> łapie).
>
> Przy statycznej kontroli jak w Javie nie trzeba, bo jak nie jest 
> obsłużone to się nie skompiluje. Podobnie jak z jawnie przekazywanymi 
> kontynuacjami.

Jeśli sygnatura mówi o przerzucaniu wyjątku wyżej to nadal 
nie wiem, czy to właściwa obsługa błędów, czy wpisana na odwal 
się, aby skompilowało - trzeba sprawdzać gdzie indziej.
Całe to rozwiązanie zachęca do robienia stubów które zbiorczo
łapią wszystko jak popadnie, kontynuacji nie ma sensu tak 
odbębniać (bo trzeba je wpisać w każdym miejscu).
 
> Tzn. tyle mówi teoria -- i tu i tu można zrobić obsługę wszystkiego w 
> jednym punkcie. W przypadku wyjątkiem jedno catch / except w "programie 
> głównym" w przypadku kontynuacji -- jedna kontynuacja wzięta też z 
> programu głównego. I jak mówi praktyka tak się dzieje dużo dużo częściej 
> niż byłoby to uzasadnione (dopuszczam przypadki, że to jest 
> uzasadnione). 

Zgoda, programowanie to nie smażenie hamburgerów 
- zawsze można spartaczyć i nie ma co szukać silver bullet.
Za to różnica jest w łatwości wykrycia takiego partactwa:
jak trzeba je jawnie wpisywać to widać, a jak nie trzeba 
(i dobry kod może wyglądać tak samo jak zły) to nie.

>> Istotnie lepsze jest przelecenie kodu pagedownem i patrzenie
>> czy każdy call ma jawnie wpisaną obsługę błędów, mając pewność
>> że albo sterowanie przejdzie linijkę dalej, albo (w razie sytuacji
>> wyjątkowej) przesunie się do wskazanego miejsca - bo z wyjątkami
>> to nie bardzo wiadomo gdzie to przeskoczy, okaże się w runtimie.
>
> A we wskazanym miejscu będzie dispatch do kolejnej kontynuacji 
> przekazanej z wyższego wołania. 

Tego się nie da nie zauważyć - bo jest jawne.
 
>>> W Javie masz jawny przepływ sterowania -- wyjątki są częścią sygnatur 
>> 
>> No pliz, to jest tylko wstępna deklaracja jakie w ogóle wyjątki mogą 
>> zostać rzucone do góry przez cały hektar kodu z niejawnymi wyskokami.
>
> Hektar? Jak ktoś napisał funkcję na 1000 wierszy to sam sobie jest 
> winien. Ta wstępna deklaracja musi pasować do wszystkich wywołań w 
> połączeniu z obsługą wyjątków w kodzie tą wstępną deklaracją objętym.

No właśnie musi pasować do wszystkich razem a nie każdego oddzielnie.

>>> Erlang jest nieco bardziej "praktyczny" w użyciu. 
>> 
>> ,,Praktyczny'' to nie jest ficzer ani składni ani semantyki.
>> Po prostu przyczyny leżą poza językiem, choćby wsparcie
>> silnego koncernu - gdzie byłaby java bez suna.
>
> Nie porównujmy Javy z Erlangiem.
>
> Właśnie uważam że istotne znaczenie ma tu semantyka, w połączeniu z 
> występowaniem w skłądni i w standardowej bibliotece tego, co potrzeba. 

I które to są te kluczowe różnice w składni i semantyce między 
Erlangiem a innymi funkcyjnymi? Bo dla mnie jest przede wszystkim mniej
czytelny, a plusy widzę głównie w maszynie wirtualnej (czy jak to zwać).

> Zaś Java to miał być język do programowania "inteligentnmych" kuchenek 
> mikrofalowych. Do zadań do których został zaprzęgnięty przez Suna 
> nadawał się słabo. Na tyle słabo że się kiepsko przyjął -- postawiono mu 
> więc, po konkretnej rozbudowie (głównie) bibliotek inne zadania, w 
> których wreszcie się przyjął, częściowo, zresztą, wracając do 
> oryginalnego pomysłu (J2ME). Bez potężnego popychania przez Suna to by 
> wszystko się rozlazło.

To właśnie mój punkt (przyczyny powodzenia są pozalingwistyczne).

>>>>> No właśnie coraz więcej różnych kolesi metaprogramuje w C++. 
>>>>> Zobacz sobie boost::lambda [...] a zwłaszcza boost::mpl 
>>>> Zaraz zaraz, używanie lambd czy foralli to nie jest metaprogramowanie.
>>> Ale ich napisanie w języku w których ich nie ma już jest :)
>> 
>> E tam, to jest użycie biblioteki, co za różnica jak zaimplementowanej.
>
> No ale użycie mpl już jest -- bo to w zasadzie jedyne zadanie tej 
> biblioteki.

Lambdy, funkcje wyższych rzędów, częściowa ewaluacja i leniwość 
to cechy w dobrych językach dostępne out of the box, bez żadnego 
metaprogramowania. Po prostu C++ jest tak biedne, że inaczej niż 
metaprogramowaniem nie dało się tego doimplementować. Co jeszcze 
nie znaczy, że używając lambdy pisze się program tworzący programy 
(fakt że to kwestia definicji MP, ja wysoko stawiam poprzeczkę).

> BTW. nigdy nie podobało mi się użycie monad (plus dziwacznych typów 
> reprezentujących stan świata) do uzyskiwania prawie-imperatywizmu. 
> Dla mnie to jest intelektualny hack.

Zamyka efekty uboczne w piaskownicy, niezły wynik.

> Usiłowanie (niby) czysto funkcyjnej realizacji zadań które 
> nie dają się sprowadzić do podania argumentów przy wywołaniu 
> i poczekania na wynik 

Wszystkie się dają, kwestia czytelności i łatwości napisania.

> Funcyjność nie jest interaktywna, może być 
> interaktywnie użyta niejako z zewnątrz.

Nie mam pojęcia, co masz na myśli.

>> Za to nie ma żadnej
>> gotowej dystrybucji całego środowiska, a dostępnych programistów 
>> jest za mało żeby ryzykować powodzenie projektu od ich dyspozycji.
>
> Niby tak. Ale wiele innych języków też zaczynało od zera i nie miało 
> wsparcia wielkiej korporacji. A mimo to trafiło do pierwszej 10. 
> najczęściej używanych i znanych przez prgramistów języku -- wśród nich 
> jest zarówno język którego dotyczy ta grupa jak i język którego dotyczy 
> spora część pyskówki w niniejszym wątku. 

Batteries included; learning curve.


Piotr Sawicki