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

> On Apr 29, 2:32 pm, Edek <e...@g...com> wrote:
>> Dnia Mon, 29 Apr 2013 04:29:20 -0700 po głębokim namyśle Andrzej
>> Jarzabek rzekł:

>> 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.
>
> 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. Para 'wynik, błąd' jest 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.

[... objawienie istnienia futures i przekazywania wyjątków ...]

[... 'nic to nie zmienia' bez pokrycia i jak to jest w Erlangu... ]

[snip...]

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

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

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

[... 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ą, inne debugowanie,
inne automatyczne detekcje, itd. itp.

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

> Moja pozycja jest taka: w językach statycznie typowanych generyki w
> takiej czy innej formie są przydatne. Również, a może nawet przede
> wszystkim przy pisaniu złożonych systemów serwerowych, również w
> przypadku, kiedy są one współbieżne czy rozproszone.

Generyki Javy owszem, są przydatne, ale nie mam zamiaru o nich mówić,
bo nie warto. O programowaniu generycznym już mogę.

> W temacie czy Go ma generyki, wyjątki i tak dalej nie mam żadnego
> szczególnego stanowiska - tak czy inaczej raczej używać nie będę. Na
> podstawie tego, co widzę pobieżnie się przyglądając, Go ma wyjątki i
> generyki. Jeśli chcesz mi wyłumaczyć, dlaczego panic/recover nie są
> wyjątkami w takim sensie, jak exceptions z Javy czy C++, albo dlaczego
> interfejsy nie są typami generycznymi w takim sensie, jak w Javowych
> generics, to chętnie przeczytam i ewentualnie podyskutuję. Nie chce ci
> się - też dobrze, możemy w takim razie chyba zakończyć dyskusję na tym,
> że nasza rozbieżność zdań co do przydatności generyków i wyjątków bierze
> się stąd, że inaczej rozumiemy te pojęcia.

No bo o 'generykach Javy' mogę powiedzieć tyle, że są
- niespójne z systemem typów. Matematycy robią listy floatów,
mapy int na boolean, itd., generując kod.
- nie pozwalają pisać kodu zależnego od T
- w zasadzie to syntaktyczny cukier na zbędne classcasty wynikające
z braków w systemie typów Javy, nic więcej

O tym czy są przydatne już mówiliśmy.

--
Edek