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:
>> Dnia Sat, 27 Apr 2013 23:58:31 +0100 po głębokim namyśle Andrzej
>> Jarzabek rzekł:
>>>>> Doświadczenie uczy, że generykii wyjątki są przydatne w kodowaniu
>>>>> problemów w językach imperatywnych/OO, więc to samo będzie raczej
>>>>> dotyczyć kodu realizującego to samo zadanie, tylko chodzącego w
>>>>> ramach aplikacji współbieżnej i równoległej.
>>>>
>>>> Architektury procesów rozproszonych nie tworzy się tak, że mamy
>>>> wersję desktopową i "tylko ją rozproszymy".
>>>
>>> Języki programowania (ogólnego zastosowania) nie służą do opisywania
>>> architektury systemu, tylko do pisania programów.
>>
>> A to było do mnie? Ja gdzieś twierdziłem, że "do opisywania"?
>
> Napisałeś zdanie, które się zaczynało od "Architektury..."
> Wyglądało, jakbyś odpowiadał na to, co było powyżej. Jeśli to było takie
> stwierdzenie bez związku z czymkolwiek to przepraszam bardzo, piękną
> mamy pogodę.

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

Znowu tylko fragment: finally-clause vs. defer. Defer mnie się bardziej
podoba, bo defer() używa się w miejscu inicjalizacji zasobu, trochę
zastępuje "goto cleanup2;" z C, ale działa podczas unwind, i nie
ma cech finally z Javy:
con = ...;
stmtFoo = ...;
stmtBar = ...;
... stronę niżej ...
finally {
if (con != null) con.close();
if (stmtFoo != null) {
stmtFoo.bar(); // ojej, a czy to nie rzuci wyjątku? TODO FIXME
smtmFoo.close(); // TODO owinąć kolejnym finally, podpisano
// deweloper O'Hara
}
itd.

Ten styl z Javy jest fatalny. Dodatkowo, Java jest tu niespójna,
bo nie można zadeklarować "final stmtFoo" - bo będzie niezainicjalizowane
w finally. Defer() pozwala dodawać elementy czyszczenia w miarę
inicjalizowania elementów, mniej więcej tak, że po stworzeniu
"con" dodaje się "defer(con.close())" itd.

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.

To wszystko jest bardzo fajnie przemyślane moim zdaniemi i jest
lepsze niż wyjątki. Wbrew twierdzeniu że "nie mam pojęcia o
czym mówię" mogę podać przykłady już konkretne tego, o czym mówiłem
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
być ich wiele wykłada się na I roku studiów.

Z generykami jest jeszcze lepiej, zwłaszcza tymi z Javy.

Może tak będzie łatwiej, zamist posługiwać się abstrakcyjnym poziomem
dyskusji mówić o konkretach w Go i np. Javie.

[1] W sensie goroutinges, czu dowolnego innego jednowątkowego algorytmu

--
Edek