Dnia Mon, 29 Apr 2013 04:29:20 -0700 po głębokim namyśle Andrzej Jarzabek
rzekł:

> On Apr 29, 12:02 am, Edek <e...@g...com> wrote:
>> Dnia Sun, 28 Apr 2013 20:04:00 +0100 po głębokim namyśle Andrzej
>> Jarzabek rzekł:
>> > On 28/04/2013 01:21, Edek wrote:
> [...]
>> Nie, nie było bez związku. Zacznę od drobnego framentu: wyjątki. Co już
>> A.L. uznał za opary absurdu, w rozproszonym procesie o błędzie trzeba
>> czasami powiadomić kilka innych Procesów [1]. I tu jest
>
> No ale wyjątki (takie jak w Javie czy C++) nie służą do powiadamniania
> procesów. Jeśli trzeba powiadomić procesy, to kod, który to robi możesz
> mieć w catch.

Tylko że to jest strasznie niewygodne. Działa ok w c++ dla prostych
rzeczy, typu odczytaj dokument z bazki, przetwórz, zapisz, ale mając
nie jeden wątek tylko masę i bilioteki w setkach tysięcy linii kodu
nawet RAII robi się kłopotliwe gdy dołączona jest reakcja
zewnętrznych systemów. C++11 ma lepsze rozwiązania ale nie
mam praktyki, o Javie może lepiej się nie wypowiem.

Dopiero małe goroutines z mniejszym stosem są światełkiem
w tunelu. Zamiast olbrzymiego stosu przez który leci wyjątek ma
się niewielkie procedury połączone kanałami. Widzę, że niedługo
powiemy, że BASIC też działał.

>> idealny przykład dlaczego Go jest dostosowane do systemów
>> rozproszonych: ma defer, panic, recover.
>>
>> Różnica ze względu na rozproszoną architekturę jest taka, że wyjątek
>> łapie się w jednym miejscu, a defer-panic-recover pozwalają ręcznie
>> przekazać informację o błędzie w wielu kierunkach. Oprócz tego panic()
>> jest jak throw, recover() jak catch(), a defer()
>> jak finally; tylko dużo elegantsze. Panic() zwija stos jak throw.
>
> W takim razie przepraszam bardzo. Moja teza była taka, że wyjątki są
> przydatne, a nie że Go jest be, bo nie ma wyjątków. Doczytałem o panic i
> recover i jak dla mnie są to po prostu wyjątki, tylko troszeczkę inaczej
> zrobione. Z tego co przeczytałem jest to ficzer dodany do języka w
> późniejszym etapie i sądzę, że narzekanie, że nie ma wyjątków raczej
> pochodzi z czasu, kiedy nie było.

Hmm. Ja żyję tu i teraz, ale może źle robię ;)

> Jeśli chodzi o to, co panic/recover wnoszą do rozproszonej architektury,
> to przykro mi, ale nie widzę różnicy. W dodatku z wykorzytsaniem w
> kontekście współieżności nie wydają się wnosić zbyt wiele w stosunku do
> wyjątków, bo z tego co wyczytałem to wyjście z goroutine w stanie
> spanikowanym wywala cały program.

Tu nie ma żadenj różnicy, wyjątki też trzeba łapać. Mi nie jest przykro
że rozmówca się nie zgadza, wręcz przeciwnie.

> Interesującą różnicą między tradycyjnymi wyjątkami a panic/recover jest
> "dynamiczny" charakter tych drugich. Jak rozumiem defer/recover można
> rejestrować np. warunkowo w klauzuli if. Czy to dobrze czy źle,
> nie mam szczególnie zdania: widzę potencjalne problemy z czytelnością,
> łatwością wnioskowania p programie, wykrywaniem błędów i refaktoryzacją,
> w dodatku "tradycyjne" podejście oparte o zakresy wydaje mi się
> elegantsze. Być może natomiast panic/defer/recover mają jakieś ciekawe
> idiomatyczne sposoby stosowania, które może nawet jeszcze nie są
> odkryte. Po prostu nie wiem.

Może najpierw "doczytam i wiem" a potem sugerowanie problemów? Podobny
cleanup stosuje się w C, tylko bez automatycznego zwijania stosu. Z tymi
znienawidzonymi goto.

> Niepokojące natomiast są argumenty ze strony projektantów języka typu
> "tak, wiemy, że (cośtam w) panic/recover jest kijowe. Specjalnie
> zrobiliśmy kijowe, żebyście nie używali panic."

No tak, bo panic to wszyscy lubią. Ech... . Go ma taką filozofię:
pozwlamy pisać ryzykowny kod, ale oferujemy bezpieczne metody
pisania.

>> Znowu tylko fragment: finally-clause vs. defer. Defer mnie się bardziej
>
> Ach, ale akurat to, czy wyjątki są dobre, czy niedobre to jest oddzielny
> temat od tego, czy sprzątanie zasobów przez finally jest dobre czy
> niedobre. Są języki, które mają inne rozwiązania rtego problemu, i nawet
> w samej Javie da się stworzyć (i tworzy się)
> odpowiednie wrappery.

Ja podałęm konkretny przykład i nic nie mówiłem o tym, czy finally
jest "dobre" czy "niedobre". Mając RAII używa się RAII, mając finally
używa się finally, mając goto w C używa się goto. Mówimy o braku
wyjątków w Go i z czym to się je w porównaniu do innych języków.

>> Potem, w Go switch + przekazanie błędu kanałem pozwala w kilku
>> linijkach propagować błędy pomiędzy Procesami, co w przypadku wyjątków
>> _zawsze i wszędzie_ jest kłopotliwe, nawet w C++11.
>
> Takie rozwiązanie, jak daje ci go, czyli złapać wyjątek w wątku, który
> go rzucił i przekazać jako wynic coroutine to z grubsza tak samo możesz
> zrobić w C++ przy pomocy future, try/catch, i pair.

Ano nie. To znaczy da się, ale praktyka zupełnie inaczej wygląda. W BASICu
też się da pisać.

> [...]
>> jedynie w postaci haseł. W zasadzie rozwinąłem się tu tylko o wyjątkach
>> - "dlaczego niby miałyby być potrzebne i w którą stronę ma wyjątek
>> polecieć, jeżeli jest kilka kanałów?". A że może
>
> No więc dokładnie w taką stronę, w jaką mu exception handler każe
> polecieć. Dokładnie tak jak z panic w Go.

Ano nie. Chociażby kod podzielnoy jest na goroutines, a nie na
jeden monolityczny wątek ze stoma ramkami stosu. To inna architektura,
trzeba przekazać informację o błędzie przez channele a nie tylko w górę
stosu.

Panic nie jest "dokładnie tak samo", tylko właśnie "zupełnie
inaczej", choć ma wspólne cechy, bo służy do tego samego celu.

>> Z generykami jest jeszcze lepiej, zwłaszcza tymi z Javy.
>
> Po przyjrzeniu się wygląda trochę tak, jakby w Go interfejsy dawały
> generyczność - przynajmniej taką jak w Javie, a może nawet trochę
> mocniejszą. Nie mam racji?

Oj, j.w., doczytajmy może najpierw. Bo ja już nie wiem, czy brakuje
generyków czy są generyki, zdecydujmy się na zajęcie jakiejś
pozycji w argumentacji, pogubiłem się ;)

--
Edek