-
Data: 2013-04-29 18:28:27
Temat: Re: Co sie tu dzieje?...
Od: Edek <e...@g...com> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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
Następne wpisy z tego wątku
- 29.04.13 19:07 Edek
- 29.04.13 19:26 M.M.
- 29.04.13 19:47 Adam Przybyla
- 29.04.13 20:01 A.L.
- 29.04.13 20:03 A.L.
- 29.04.13 20:03 A.L.
- 29.04.13 20:05 A.L.
- 29.04.13 20:05 A.L.
- 29.04.13 20:09 A.L.
- 29.04.13 22:32 Andrzej Jarzabek
- 30.04.13 00:00 Andrzej Jarzabek
- 30.04.13 02:54 A.L.
- 30.04.13 08:56 Andrzej Jarzabek
- 30.04.13 11:14 Edek
- 01.05.13 12:42 firr kenobi
Najnowsze wątki z tej grupy
- Popr. 14. Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- Arch. Prog. Nieuprzywilejowanych w pełnej wer. na nowej s. WWW energokod.pl
- 7. Raport Totaliztyczny: Sprawa Qt Group wer. 424
- TCL - problem z escape ostatniego \ w nawiasach {}
- Nauka i Praca Programisty C++ w III Rzeczy (pospolitej)
- testy-wyd-sort - Podsumowanie
- Tworzenie Programów Nieuprzywilejowanych Opartych Na Wtyczkach
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
Najnowsze wątki
- 2025-02-06 PROGRAM DOPŁAT DO AUT ELEKTRYCZNYCH TO ABSURD. ZA ŚRODKI Z KPO KUPIMY NIEMIECKIE I CHIŃSKIE AUTA
- 2025-02-05 ceny OC
- 2025-02-05 Re: ceny OC
- 2025-02-05 Re: ceny OC
- 2025-02-07 Smar do video
- 2025-02-06 Litowe baterie AA Li/FeS2 a alkaliczne
- 2025-02-07 Gliwice => Business Development Manager - Network and Network Security
- 2025-02-07 Warszawa => System Architect (Java background) <=
- 2025-02-07 Warszawa => System Architect (background deweloperski w Java) <=
- 2025-02-07 Warszawa => Solution Architect (Java background) <=
- 2025-02-07 Gliwice => Ekspert IT (obszar systemów sieciowych) <=
- 2025-02-07 Lublin => Programista Delphi <=
- 2025-02-07 Warszawa => Architekt rozwiązań (doświadczenie w obszarze Java, AWS
- 2025-02-07 Dęblin => Node.js / Fullstack Developer <=
- 2025-02-07 Bieruń => Spedytor Międzynarodowy (handel ładunkami/prowadzenie flo