On 29/04/2013 17:28, Edek wrote:
> Dnia Mon, 29 Apr 2013 08:32:16 -0700 po głębokim namyśle Andrzej Jarzabek
> rzekł:
>
>> W ramach tego, że w C++ nie masz wbudowanych mechanizmów takich jak
>> channel i goroutine, nie jest to bardziej kłopotliwe niż rozwiązanie bez
>> wyjątków.
>
> Ano jest: w sytuacji błędu z sąsiedniego systemu nie wystarczy tylko
> rzucić wyjątek i wyczyścić stan.

Ale wyjątki oprócz rzucenia wyjątku i wyczyszczenia stanu pozwalają
jeszcze obsłużyć wyjątek. A razem z tym to wystarczy.

> Para 'wynik, błąd' jest lepsza.

W czym lepsza?

> Ogólnie lepsze moimn zdaniem jest podejście takie, że logger,
> monitoring, komunikacja, i cała reszta infrastruktury są dokładnie
> takimi samymi modułami jak treść - powiedzmy propagowanie dokumentu
> do działów. Na desktopie nie ma znaczenia czy logowanie jest "doklejone",
> w rozproszonych już jest inaczej.

Ale co tu zmieniają wyjątki? Z klauzuli catch można tak samo odwołać się
do modułu logowania co z klauzuli if err != nil. Wygoda większa, bo nie
musisz tego err propagować po stosie.

>> No więc otóż również uważam, że C jest kiepskim językiem, w którym brak
>> sensownych rozwiązań jest przyczyną dużej ilości problemów.
>
> No więc ja uważam, że w Javie programują dwie grupy ludzi: dzieci
> Javy lubiące ten język i osoby umiejące używać Javy.

Nie masz racji. Jestem jeszcze ja.

>> Ale twój argument dotyczył tego, że defer jest lepsze od sprzątania
>> zasobów niż finally. Może i jest, ale to nie jest argument za tym, że
>> bez wyjątków lepiej, bo przecież istnieje wiele mechanizmów językowych
>> do sprzątania zasobów lepszych niż finally.
>
> Tak, zastrzegałem: tylko mały przykład, fragment całości. Lista jest
> dużo dłuższa.

No to ten przykład zestrzelony, zapodawaj następny.

>> W Groovy na ten przykład, który ma dokładnie takie same wyjątki jak
>> Java, problem zamykania pliku można załatwić w ten sposób:
>>
>> myFile.withWriter { writer ->
>> zapisuj_do_pliku_używając writer
>> }
>
> W Javie, C++, C (!), Pythonie też.

Wiem, ale jest to mniej lub bradziej wygodne/czytelne. W Pythonie to
pewnie nawet się sensownie robi, w C trzeba symulować closure za pomocą
czego - wskaźnika na funkcję i void pointer? To trochę zabija sens tej
zabawy, pewnie nawet lepiej zrobić goto.

> Różnica polega na ujęciu tego
> w języku, w rdzeniu języka. W Go w rdzeniu języka są goroutines.
> Nie ma sensu mówić o jednej cesze (?) języka bez uwzględnienia
> pozostałych.

Co w tym momenciee wnoszą goroutines? W innych językach też można
odpalić asynchronicznie funkcję i przekazywać komunikaty.

> [... oczywista oczywistość ...]
>> Ale dlaczego monolitycznego? Wątki masz takie, jakie sobie napiszesz.
>> Dokładnie tak samo, jak rozumiem, jak goroutines - będzie ich tyle i
>> takie duże, jak sobie programista podzieli program. Mylę się?
>
> Trochę inny jest narzut składni nad treścią,

Jak się używa odpowiednich bibliotek, to różnica akurat w tym względzie
jest kosmetyczna.

>>> To inna architektura,
>>> trzeba przekazać informację o błędzie przez channele a nie tylko w górę
>>> stosu.
>> I czym to się różni od programu wielowątkowego w C++?
>
> Z A.L. właśnie sobie to wyjaśnialiśmy. Trochę tak jak pomiędzy
> systemem plików a dyskiem 2TB.

Nie rozumiem.