🚀 go-pugleaf

Seweryn Habdank-Wojewódzki wrote:
>>>> Ułatwić, czyli skrócić czas powstawania aplikacji a jak wiadomo czas to
>>>> pieniądź.
>>>
>>> O tak to ma sens, ale wszystko w ten sam sposób moge sprowadzić do
>>> pieniędzy. Co więcej teorię przeciwną również.
>> 
>> Ale po co sobie utrudniac życie, dla frajdy?
> 
> Dla ustalenia uwagi. Nie mam nic przeciwko SGCL ani Śmieciuchowi, ani
> innemu GC dla C++ i C.
> 
> Podkreślę moje stanowisko.
> 
> Zarówno Ty jak i Pan Karpierz oraz wszyscy lokalni Ajatollahowie GC :-)
> znają i umieją pisać w C, C++ lub innych brzydkich językach !!!
> 
> Mając to w pamięci. Kiedy mówisz o zasobach w językach z GC używasz wzorca
> projektowego "język C", czyli jezeli coś ma być napisane
> alokując/zwalniając zasoby inne niż RAM mówisz: "Piszemy jak w C!".
> To jest użycie wzorca projektowego "język C".

Nonsens.

Piszemy jak w każdym normalnym języku. Zasoby istotne się po sobie zwalnia i
są do tego narzędzia właściwe (czyli with / using, try finally, itd).

Destruktory z C++ są rozwiązaniem cienkim. Cienkim z jednego, prozaicznego,
ale kluczowego(!), powodu. Z poziomu destruktora nie da się poinformować o
błędzie (poza wywaleniem całego programu, jakże wychwalanemu przez
astronautów i ajatollachów C++, ale w Rzeczywistym Świecie(tm) zazwyczaj
Kompletnie Do Dupy(tm)).

> Teraz postaw się w sytuacji (która mnie dotknęła) wytłumacz to
> przeciętnemu koderowi języka z GC (i tylko jednego języka, bo tacy
> jednojęzykowcy są tanii).
> 
> Co mu powiesz?

Powiem mu, że jak plik otworzył, to musi dopilnować jego zamknięcia. Cała
filozofia.


>>>> Biorąc pod uwagę rosnącą w ostatnim czasie, popularność języków z
>>>> wbudowanym systemem GC, jest coraz mniej obszarów w których pamięć aż
>>>> tak bardzo trzeba szanować.
>>>
>>> A tą ilość/liczbę jak określasz? W liniach kodu, w sztukach sprzedanych
>>> instalacji.
>> 
>> W ilościach nowych projektów tworzonych w języku C++. Od kilka lat,
>> procentowo ta ilość systematycznie spada.
> 
> Aha. No ja na to patrzę przez inny pryzmat.
> 
> Metryka używalności:
> 
>         max ( liczba użytkowników, liczba instalacji )
> 

Słaba to metryka. Co z tego, że coś ma miliard użytkowników, skoro żyje z
tego jeden człowiek (zostało napisane raz i już sobie jest). Dużo ciekawsza
jest metryka w czym większy procent ludzi pisze. A tu C++ jedzie w dół,
coraz ostrzej.

BTW. W 6 na 7 podanych przez ciebie przypadkach mowa jest o C a nie C++.
Z tego wynika jedno -- o ile C zostanie, bo zapotrzebowanie na "przenośny
assembler" jest i w przewidywalnej przyszłości będzie, to C++ nie ma
takiej "z góry upatrzonej pozycji na którą może się wycofać".


>> To że istnieją niekompetentni programiści, nie jest w żadnym stopniu winą
>> istnienia systemów GC.
> 
> NIE! Nie jest winą GC.
> 
> GC dla ludzi znających C, C++ i języki bez GC jest istotnie obniżeniem
> kosztów w sytuacji kiedy tego trzeba. Miałem osobiście przypadki kiedy
> powodowało wzrost kosztów.

Te przypadki są statystycznie nieisotne.

> Dla ludzi, nie mających pojęcia o tym, może powodować drastyczny wzrost
> kosztów w projektach korzystających z zasobów innych niż RAM na skutek nie
> przewidzianych katastrof.

Jakież to katastrofy są nieprzewidziane? Brak close łatwo zauważyć.


> Podsumowując -- wiem, że są sytuacje kiedy GC może być wygodne, ale GC to
> jest bardzo rozleniwiająca brzytwa -- generalnie goli elegancko, ale słabo
> obeznani potrafią poderżnąc sobie i innym gardło. A nalezy pamiętać, że
> określony kod jest uzywany zazwyczaj w zakresie 10 - 1000 razy większym
> podwzględem zasobów niż przewidziane przez koderów obciążenie.

To też nie jest prawda.


pzdr
\SK
-- 
"Never underestimate the power of human stupidity" -- L. Lang