🚀 go-pugleaf

W dniu środa, 11 marca 2020 18:37:11 UTC+1 użytkownik heby napisał:
> On 11/03/2020 07:42, Maciek Godek wrote:
> >>> Abstrakcje w C są dobrze dobrane do zadań, do których używa się C.
> >> C nie ma abstrakcji poza void*.
> > Mechanizmy abstrakcji w C:
[...]
> Natomaist C++ dodaje Ci masę innych rzeczy to tych pseudo abstrakcji. 
> Między innymi dodaje prawdziwe abstrakcje takie jak szablony.
> 
> Można oczywiście bredzić o tym że funkcja to taki rodzaj abstrakcji.

"Bredzić"?
Funkcja i abstrakcja to w zasadzie synonimy.
(Inna rzecz, że funkcje w C - i za nim C++ - są "koślawymi abstrakcjami", podobnie jak enumy i unie. Ale w C są koślawe z uzasadnieniem)

> >, który będzie udowadniał innym, że technologia, której używają, jest zacofana, bo nie jest technologią, której on używa.
> 
> Wiadomo, Twój punkt widzenia jest bardziej obiektywny bo jest bardziej 
> subiektywny, najmojszy.

Nie jest. To nie ja wyskakuję ze stwierdzeniami typu "po co używać C, jak jest C++" albo "używanie C w obliczu istnienia C++ może mieć wyłącznie podłoże religijne".

Jak mówię, jeśli lubisz, to sobie pisz w C++.
Ja zaprezentowałem coś tam dla języka C. To są różne języki.

> > A jak mu wykażą, że ta ich technologia jest adekwatna do problemów, które rozwiązują
> 
> Ale ty dopiero po solidnym pieprzenięciu w głowę argumentacją wymyśliłeś 
> sobie że to ma zastosowanie w jakimś marginalnym, niszowym embedded

?

Rozwiązanie wymyśliłem właśnie w kontekście systemu embedded, i problemu, jaki tam miałem. I w tamtym kontekście sprawdza się wystarczająco dobrze.


> Masz straszne parcie na udowodnienie światu że te dziadowskie korutyny 
> mają sens. Sorry, nie mają, tak ogólnie.

Nie mam żadnego parcia. W tym temacie powiedziałem wszystko, co miałem do powiedzenia. To Ty się na tym jakoś zafiksowałeś.

> > I tyle z opowieści. Język C nie miał "nic zastępować", tylko miał służyć pewnemu konkretnemu celowi.
> 
> Nie, nie masz chyba jednak pojęcia po co męczono się z BCPL, B i C. 
> Męczono się bo pisanie kernela w asm przestało mieć sens.
> 
> https://en.wikipedia.org/wiki/C_(programming_language)

Łał, umiesz wklejać linki do Wikipedii.

> Ich jedynym zadaniem było przeportowanie kernela. W tym celu zrobili 
> sobie lepszy asembler wysokiego poziomu bo inny asembler (BCPL) był 
> idiotyczny z uwagi na absurdalne ograniczenia.

?

Nie wiem, skąd sobie wyssałeś taką teorię.

> > Cóż, w moim doświadczeniu C++ łączy raczej wady pisania niskopoziomowego (segmentation fault i undefined behavior)
> 
> Których używasz w C.

Który przynajmniej nie udaje, że jest czymś więcej, niż jest.

> > z nieergonomicznymi interfejsami biblioteki standardowej
> 
> Których nie musisz używać.

Otóż to jest sedno wszystkiego. Nie muszę i nie używam.


> > i semantyką (glvalue reference? prvalue reference? xvalue reference? poważnie?).
> 
> Widzisz, one wszystkie powstają po to aby udoskonalić jakość kodu

One powstają dlatego, że czasem coś się komuś przywidzi, i będzie bił pianę dostatecznie energicznie, żeby weszło do standardu.

> > No, ale to tylko moje doświadczenie.
> 
> Idę o zakłąd że nie masz nawet śladu doświadczenia z C++.

Ktoś mnie kiedyś o to zapytał, i opisałem:
https://www.quora.com/What-is-your-experience-related-to-learning-C/answer/Panicz-Godek

(a Ty przegrałeś zakład)

> > Jak lubisz, to sobie używaj.
> 
> Nie mam wyjścia. Jeśli mam bilardy lini kodu to wole je mieć w C++ niż w 
> asm, pardon, C. Wolałbym mieć je w czym innym, ale to nie ode mnie już 
> zależy.

Dlaczego nie od Ciebie?

> >>> To twierdzenie jest o tyle głupie że C++ ma takie same abstrakcjie jak
> >>> duże języki (klasy, obiekty, interfejsy) i jednoczesnie kontrole
> >>> niskopopziomową z C. Połaczono zalety pisania niskopoziomowego z
> >>> abstrakcją w jednym jezyku. Niczego istotnego z C nie zabrano, więc jest
> >>> równie dobry jak C + dodatkowe zalety.
> > Trochę też można to porównać do Ferrari, na siedzeniu którego leży gówno.
> 
> Nie, to raczej porównanie do Malucha. C++ to taki Maluch opakowany w 
> masę poduszek i domalowany na zewnątrz jak Ferrari.

To nie miała być metafora, tylko analogia, która pokazuje, że rozumowanie postaci "Y ma wszystko to samo, co X plus coś jeszcze, więc jest co najmniej równie dobre jak X" jest wadliwe.

Jeżeli C albo C++ byłoby Maluchem, to nie wiem, czym miałoby być owo Ferrari.

> > Jednak, jeżeli idzie o mnie, raczej bym wolał wariant bez gówna.
> 
> Niezupełnie, Twój warian to własne gówno w postaci korutyn, bez stosu, 
> na makrach. Prawda jest taka, drogi misiaczku, że NAWET doświadczony 
> programista C pogonił by Cie za to kijem na code review. Wiem, bo 
> pytałem. Nawet programiści C kreślą pewną granicę dziadostwa której nie 
> przekraczają.

A ci programiści, których pytałeś, to jakie systemy zbudowali?

I jakie alternatywy proponowali dla rozwiązania tego problemu?

Zresztą programowanie jednak ma to do siebie, że jest mocno subiektywne, i różni ludzie mają różne style. Na przykład gość, który określił to rozwiązanie "worst piece of C hackery", sam zastosował je w swoim kodzie.

Bo najwidoczniej alternatywy były jeszcze gorsze.

> Masz hiper ważny powód aby obronić te makra.

Jaki niby mam powód?

> On 11/03/2020 15:00, Mateusz Viste wrote:
> >Tak czy siak - nikt nikogo tu nie przekona.
> 
> Dyskusja o C++ to tylko taki wabik. Tak naprawdę Maćkowi chodzi o to aby 
> ktoś w końcu te makra przytulił, pogłaskał i powiedział "już, już 
> dobrze, Ci źli hejterzy się przyczepili tylko, jesteście śliczne". 

Jest dokładnie przeciwnie. Rozwiązanie zostało już skrytykowane, nawet przeze mnie samego, i nie mam w tym temacie już nic więcej do dodania.

To Ty twierdzisz, że jeżeli ktoś preferuje C nad C++ to jego powody są natury religijnej. Ja tak nie uważam. Może w dużej mierze jest to kwestia osobistych preferencji - i pod tym względem zgadzam się z Mateuszem.
Tym niemniej, C++ jest obiektywnie bardziej skomplikowany niż C. Istnieją języki, które są mniej komplikowane od C++ i jednocześnie potężniejsze od niego (chociażby Scheme). Ale to nie znaczy, że do wszystkiego nadają się lepiej.

W każdym razie zgadzam się ze stwierdzeniem JDX, że jeżeli ktoś miałby brać bezpieczeństwo swojego kodu na serio, to raczej powinien się zastanowić nad Rustem, niż nad C++ (w którym można zrobić każdą tę samą głupotę, co w C, plus jeszcze sporo nowych głupot).