🚀 go-pugleaf

On 30/01/2020 04:40, M.M. wrote:
>> Ten przykład nie tłumaczy problemów w C++ tylko w białku.
> W jakim białku?

Problemy z C++ to głównie problemy białkowe:
a) muszę używać new bo inaczej się nie da
b) szwagra kumpla zięcia ciotka to miała taki przypadek że zainkudowała 
coś i exec zrobił się bilin razy większy
c) void* jest czytelniejsze niż Foo*
d) po C++ krowy mleka nie dają
e) ten sam asembler, ale jest wolniejszy bo szwagier sprawdzał
f) "mam swoje powody"

>> W sensie że jest bardziej restrykcyjny? Słyszałme kiedyś że to wada. Do
>> dzisiaj nie wiem dlaczego.
> Podałem przykład, ale Ty na to coś o jakimś białku.

Bo wszystkie problemy jakie padły w tym wątku sa białkowe.

>> Napisałem Ci że nic nie musisz szkolić poza "chłopaki, od dzisiaj w
>> każdym przerwaniu na arma na początku ma stać scoped_interrupt_disable
>> sid(); i h...". A jak któryś podskoczy to w łeb. Koniec szkolenia. Po
>> roku nie dadzą sobie tego siła odebrać.
> To faktycznie nie rozmawiamy o C++, tylko o czymś w rodzaju co napisałeś
> "wystarczy jeden ficzer z C++". Co dobrego z takiej rozmowy wyniknie?

Być może komuś uratuje dupę jak zampomni postawić sei() przy returnie "w 
przerwaniu ARMa".

Jeden mały ficzer ratujący dupę wydaje się być całkiem sensowny jak za 0zł.

Ale nie, bo "mam swoje powody".

>> Kiedyś ludzie uważali BCPL za spełenienie marzeń. Sam się kompiluje,
>> można zrobić bootstrap na dziwnym systemie, architektura wręcz zdjęta z
>> tablicy uczelni, *uproszczona* składnia.
> Niestety nie miałem przyjemności z BCPL.

Śladowe ilości można było odszukać, najbliżej, w Amidze; w okolicy 
połowy lat 80. DOSa miała napisanego w BCPLu. Skutkiem ubocznym 
wszystkie pointery API DOSa wymagały arytmetyki >>2 <<2. H... wie po co :D

> Nie wiem jak używasz określenia białko.

Jako decydowanie o technologii na podstawie pozaracjonalnych doświadczeń 
przez ludzie składających się z białka z domieszką uprzedzeń. Jedną z 
najbardziej zdumiewających rzeczy jakie zrozumiałem o porogramistach 
jest to że to ludzie bardziej uprzedzeni do wszystkiego niż przeciętny 
wyborca konserwatystów.

>> Mam takie a takie doświadczenia, widziałem to i tamto, wnioskuje z tego
>> to i owo.
> Nie wiem w czym problem.

W tym że podejście racjonalne polega na czymś zgoła odmiennym.

>> A na koniec okazuje się że programy w C++ nie dość że są czytelniejsze
>> od tych w C, to często są szybsze, łatwiejsze w analizie i refaktoringu.
> Sekundę. Programy w C++ mogą być czytelniejsze od tych w C i to mogą być
> znacznie czytelniejsze, tak samo jak mogą być łatwiejsze w analizie i
> refaktoringu.

Nie, one *zazwyczaj* są. Pozawalają wyrazić algorytm bez pieprzenia się 
z pisaniem go w asemblerze, do którego w gruncie rzeczy sprowadza się C, 
a szczególnie taki poprzetykany void*.

> Ale jeśli są mocno zoptymalizowane pod kątem szybkości
> działania, to na pewno nie są ani czytelne, ani łatwe w analizie, a już w
> ogóle są fatalne w rozbudowie i refaktoringu.

Obawiam się że w programowaniu ważniejsza jest złożoność algorytmiczna 
nad hackerskie optymalizacje kodu. Tym zajmuje się kompilator.

I uwaga: wszystkie sztuczki z C++ z szablonami generują równie szybki i 
równie hackerski kod co C. Tyle że łatwiej to czytać, rozumieć i 
refaktorować niż sieczkę kwadratowych kół w C.

>> I co to ma w ogóle do dyskusji o tym że zmiana z gcc na g++ dodaje od
>> razu za darmo masę możliwosci które w C wymagają pisania kwadratowych kół?
> Już pisałem jaka jest analogia i nie przeczyłem możliwościom C++. Nie można
> jednej technologii ulepszać bez końca, a już na pewno nie można stałym
> nakładem kosztów/pracy ulepszać o stałą wartość, efekty stają się coraz
> mniejsze, a języki programowania są ulepszane od dawna. Dopóki  nie
> będzie jakiegoś przełomu w technologiach wytwarzania oprogramowania, to
> nie należy się już spodziewać, że taki czy inny zestaw nowych ficzerów
> znacząco udoskonali technologię. W moim przypadku dobre biblioteki najbardziej
> przyspieszają tworzenie oprogramowania.

Na 99% masz do nich dostęp w C++. Nastepny pusty argument.

> Bajeranckie cechy języka... to
> nawet spowalniają, bo programista myśli czego lepiej użyć.

Odwrotnie. Programista nie myśli jak jest zbudowany std::container, 
używa move i ma najszybszą z możliwych implementację. Pisanie w C++ 
opiera się na pewnych obietnicach: napisz co chcesz a my zrobimy to tak 
dobrze jak się da, albo przynajmniej najlepiej jak potrafimy.

Bibliteki nie są doskonałe. Ale są coraz doskonalsze a lata 90 słusznie 
mineły.

> Bez kontekstu nie wiem jak się o to spierać. Templates można porównywać do
> błędogennych makrodefinicji i void*.

Nijak się nie da. Templates nadają sens wskaźnikom. void* odbiera ten 
sens. To tak jak byś pisał we wspomnianym BCPLu. Wszystko jest "wordem" 
i sam se zgaduj co dostałeś jako argument. No wiec masa programistów C 
pisze właśnie w takim BCPLu. Wszystko jest void* i tylko cicha modlitwa 
pozwala upewnić się że to jest jednak Foo*.

>> Tylko że ja się o to nie spieram. Ja tylko protestuje przeciwko
>> bredzeniu o tym że zmiana z gcc na g++ jest niemozliwa, bezsensowna
>> i
>> korutyny nie muszą mieć stosu a programiści muszą się szkolić z używania
>> prymitywnego RAII.
> Nie wiem, moje korutyny mają stos i są odporne na wątki - chyba że to co
> ja mam jeszcze nie nazywa się korutyną.

Korutyna ma mieć stos. Piszą to w pierwszym zdaniu o korutynach na wiki.

Ale Maciek ma inny internet, inzynierię i wszechświat. U nie go nie 
muszą. Stąd cała dyskusja, która tradycyjnie już odpłyneła w kierunku 
nastepnego nudnego flame starych dziadków. Przypuszcalnie za 30 lat 
będziemy się spierać w sanatoriach waląc się laskami po łbach.

>> Wieć programowanie w C++ to programowanie z dowolnym ficzerem dostępnym
>> w g++ a niedostepnym w gcc. Na przykłd z użyciem RAII, które to jest
>> swoją drogą krytycznie potrzebne w embedded i jednoczesnie skandalicznie
>> olewane przez embedded. Bo kwadratowe koła łatwiej się produkuje niż
>> kupuje okrągłe. 
> A wyżej napisałeś że spieramy się o wyższość języka C nad C++ lub odwrotnie.

Bo tak wyszło. Pierowtny temat to napisanie kilku mark w celu emulacji 
czegoś czego autor nie pojmuje jak ma działać.

> Język to nie jeden ficzer, a w praktyce nawet spór o cały język jest jałowy, bo
> co komu nawet z najlepszego języka jak nie ma do niego narzędzi?

Do C++ jest całkiem sporo narzędzi. Nie narzekałbym.

>>>> Użycie składni obiektowej (struct/class) nie oznacza że używa się
>>>> obiektowości.
>>> Dlaczego?
>> Bo obiektowośc wymaga *OBIEKTÓW* a nie klas.
> Nie wiem, a co z tego rozgraniczenia dobrego dla Ciebie i dla mnie?

To dośc istotne przycięcie powoduje że ludzie przestają widzieć C++ jako 
"coś gdzie obowiązkowo używa się new".

>> Że traits< int >::max to nie jest programowanie obiektowe, natomiast to
>> jest programowanie w C++.
> Też nie wiem co z tego dobrego dla mnie i dla Ciebie.

Dla innych może wynikać. Na przykład mogą w swoim zdumieniu zobaczyć że 
powyższa linijka nie kompiluje się do milairda megabajtów. Ona się 
kompiluje do ... niczego.

Zazwyczaj programiści C właśnie tak widzą C++: dużo pisania więc 
wolniej. Nie przychdozi im do głowy że to pisanie jest po to aby 
kompilator sprawdzał typy a nie generował kod.

>> Nie, znalezienie bładu w szablonach który ujawnia się w runtime jest
>> naprawdę wyższą szkoła jazdy. Zrobienie błedu w void* który ujawnia się
>> w runtime to trywializm.
> Programowałem i z użyciem szablonów i z void*. Tyle że szablonów zwykle używam
> do poprawy wydajności. Swoją osobistą statystykę mam zdecydowanie na korzyść
> void* - w sensie że mniej błędów popełniałem. Ale powtarzam, ja czasami używam
> szablonów zupełnie inaczej niż 90% programistów.

Mam doświadczenia dokładnie odwrotne. W dodatku moje są zbliżone do 
obserwacji ludzi zajmujacych się teorią programowania - silne typy są 
bezpieczniejsze niż uniwersalne dane. U mnie liczy się jakość, nie 
wygoda pisania.

>> I w tym momencie zamieniasz gcc na g++. Znalazłeś jeden powód aby użyć
>> C++ to go używasz, jest za darmo.
> Nie rozumiem w jakim momencie, gcc szablonów nie kompiluje, a rozmawialiśmy w
> tym akapicie o szablonach.

"gcc" to tylko taki koncept kompilatora C. Jak się uprzesz to oczywiście 
za pomocą gcc skopilujesz plik .cpp (z pewnymi detalami, ale pal sześć). 
Tu chodzi o metaforę: zamień swój kompilator z C na C++, to jest za darmo.

>>> gdy jeden szablon jest parametryzowany kilkoma innymi szablonami
>> Poniżej promila z promila zastosowań szablonów wymaga takich wygibasów.
> Jeśli podajemy jawnie wydajność jako zaletę templates, to zwykle używa
> się tego typu wygibasów.

*W* środku biblitek. U klienta? Nie, raczej nie. Tam się to kończy 
std::shared_ptr< Foo > a to że w środku ktoś sprawdza trywialnosc 
konstruktora wielopoziomowymi szablonami to nie jest ani istotne ani 
widoczne.

>> Ale dla user końcowego jest wręcz bajecznie prosta.
> Tak, o to właśnie chodzi. Moje mikro-biblioteki też są w jakimś stopniu proste,
> ale są wierzchołkiem góry lodowej. Niewidoczna część pod wodą stanowi
> pierdylion eksperymentów z szablonami, makrami, opcjami kompilatora, z
> oczekiwaniem na koniec pracy kompilatora, z uganianiem się za syntax error w
> innym pliku niż pokazał kompilator....

Sprawdź co oferuje clang w kwesti przejrzystości błedów. gcc już od 
dawna nie ma nic wspólnego z wygodą kompilowania. Da się? Da.

>> Te szablony w szablonach to taka Baba Jaga dla niegrzecznych
>> programistów C. Straszy się nią i jak widać skutecznie.
> Nie wiem do czego nawiązujesz.

Do bredzenia o tym że cośtam powiększa aplikacje o magabajty "bo trzeba 
rozwijać szablony". Łomatko. Rozwijam szablony i raz mam 0 bajtów a raz 
gigabajty. Na tego typu opinie nalezy natychmiast mówić "Stop". Generują 
tylko atmosere podobną do antyszczepionkowców. Podobno użycie RAII 
powoduje autyzm.

>>> pozbawionego błędów. Tak się mówi że szablony stanowią antidotum na błędy, bo
>>> porównuje się je zwykle do najbardziej błędogennych konstrukcji języka, jak
>>> wlaśnie do makr, albo do rzutowania na void*.
>> Stanowią warstwę chroniącą przed pewną klasą problemów. Akurat tych
>> upierdliwych, bo w runtime.
> Może tak naprawdę spieramy się o to, że Ty uważasz iż szablony bardzo
> usprawniają technologię oprogramowania, a ja że usprawniają ją w mniejszym
> stopniu?

To zdajnie powyżej to nawet nie do końca się do szablonów odnosi. 
Bardziej do silnych typów. Tak silnych że drą japę na kompilacji, czego 
void* nie potrafi.

> Nie zgadzam się też, że trudno popełnić błąd w runtime programując z
> wykorzystaniem szablonów.

Kawestia oceny. Przypadki kiedy typ nie pasuje są u mnie zredukowane do 
prawie 0.

> Nie wiem, trudno mi się wypowiedzieć, bo od wielu lat void* zdarza mi
> się użyć może raz na rok. Może z 15 lat temu używałem regularnie, też
> dawałem radę. I nie chcę powiedzieć po prostu że kiedyś bez papieru
> dawali radę, ale że jak dawali radę, to ten papier toaletowy nie jest aż
> takim panaceum, tylko jakimś kolejnym małym ulepszeniem.

I jest za darmo. Znaczy nie papier tylko C++.

>> Myśle że 90% konstrukcji z boosta jest trywialna.
> Pisałeś też że się napracowali przy booście, czy miałeś na myśli że
> napracowali się przy pozostałych 10ciu procentach?

Nie jest istotne kto się naprawcował *przy* booscie. Istotne jest ile 
napracuje się klient tego API. No więc niewiele. O wiele mniej niż 
straszy się młodych studentów oferujac im w zamian łupanie kamieni void*.

>>> Gdy każde jeszcze ma jakieś parametry i
>>> typy - to naprawdę zazwyczaj dostawałem oczopląsu gdy analizowałem swój własny
>>> kod po krótkim czasie. Myślę że każdy programista uznałby za łatwiejszy w
>>> analizie kod np. Javy.
>> Więc masz kiepskie doświadczenia wynikające z kiespkiego doboru przykładów.
> Czysta złośliwość czy kryje sie za tym coś konstruktywnego? Co to są
> kiepskie doświadczenia?

Kiepskie przykład to na przykład analiza closures w boost::spirit. Tam 
jest cieżko. I jestem pewny że jeśli ktoś chciałby mi złośliwie wykazać 
że boost jest trudny to wyjmie przykłąd z okolicy boost::spirit, mpl czy 
fusion. To są złe doświadczenia. Przy uzywaniu takim jak na początku 
watku, czyli "małych kawałeczków C++ usprawniajacych pracę" takie 
kobylaste szablony nie tylko się nie trafiają ale i sensu nie mają. 
Przyjdzie czas to ktoś to doceni. Na razie wolałbym aby embedowcy 
zauważyli że ktoś w zeszłym wieku wymyślił RAII. To już by było naprawdę 
miłe.

>> Używam C++. W tym szablonów. Szablony są od dziesiątek lat coraz lepiej
>> wspierane przez kompialtory (komunikaty błedów) i debuggery (pokazywanie
>> zawartości). Nijak nie wiem czemu foo<int> miało by być bardzie
>> skomplikowane do debugu. Jedyna przeszkoda to czasem dłuższe nazwy
>> typów. Tylko że tam się zagląda raz na rok.
> Na razie rozumiem, że dobre doświadczenia są wtedy gdy się tam zagląda
> raz na rok, a gdy ktoś akurat nad tym pracuje, to nabiera kiepskich
> doświadczeń.

Nie, to oznacza że kłopoty z debugiem kodu szablonowego praktycznie nie 
wystepują w praktyce. Czasem się tam zagląda, w 50% przypadków brakuje 
const albo miał być pointer a jest referencja. Ale to widać od razu, bez 
debugowania. Ostatni raz rozwijałem mapę stl jakieś 2 lata temu szukając 
dlaczego nie działa. Kodu biblitecznego stl/boost praktycznie sie nie 
debuguje mimo że mój kod jest nimi przesiąknięty na wylot.

> Miałem na myśl nie nie tylko śledzenie linia po linii wykonania kodu w
> programie do debugowania, tyko generalnie usuwanie błędów. Gdy oglądam
> kod z 'wirtualnym typem' który dopiero w trakcie kompilacji będzie na
> kilka sposobów konkretyzowany, to wcale nie jestem bardziej pewny jego
> bezbłędności, niż gdy patrzę na kod zwykłej procedury. W zasadzie to
> chyba mam odwrotnie, co do zwykłych procedur szybciej nabieram przekonania
> że są poprawne. A swoją drogą w programach do debugowania też było
> sporo błędów i gorzej sobie radziły na szablonach.

Znowu chciałem przypomnieć że lata 90 słusznie mineły.

>>> nie mam z nimi problemów. Ale gdy np. cały algorytm genetyczny parametryzuję
>>> kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
>>> edytor nie wie jakie metody będą miał parametry.
>> Masz zły edytor.
> Może, a jaki Ty masz?

Np. VS + Visual Assist. Visual assist poniekąd potrafi domyślać się 
detali związanych z szablonami, i prawidłowo podpowiadać. I gubi się 
czasem, tak. Trudny język, ciężko o dobry edytor, ale nie jest tak że 
nie ma *nic*.

>> Mam młotek, ale lepiej wbijać gwoździe lutownicą.
>> Mam szablony, ale przecież void* to tylko kilka wad z którymi da sie żyć.
> Nie, nie to chciałem powiedzieć. Mam szablony, używam szablonów, ale jestem
> świadomy że z void* też działało, więc te szablony to nie żadne panaceum, ale
> jakieś kolejne ulepszenie.

Tu jest zupełnie inaczej. Silne typy są lepsze niż void*, mniej więcej 
zawsze. Mimo to ludzie używający void*, czasami wymieniając ich wady, 
dalej nie widzą sensu zmieny na silne typy. Problemem jest brak 
logicznego argumentu dlaczego. W dodatku wielu reaguje skrajnie 
alergicznie na pytanie "Dlaczego używasz void* skoro silne typy są za 
darmo". To jest religia białkowa.

>> Ja rozumiem jeszcze jak by za używanie szblonów trzeba było płacić.
> Bo trzeba, nic nie jest za darmo. Tą opłatą była/jest:
>   - konieczność szkolenia personelu,

Używają int, float. Nagle muszą użyć Foo. To jakaś katastrofa?

>   - konieczność nabrania doświadczenia przez personel,

Mieli na to ostatnie 40 lat.

>   - wiele lat implementacji w kompilatorach,

Które od wielu lat je mają.

>   - problemy bo kompilatory różnie to wspierały,

Zaznaczam po raz kolejny że lata 90 słusznie mineły.

>   - targi o to jak powinny wyglądać w standardzie,

Zakończone standardem.

>   - próby łamania standardu przez niektóre firmy,

Które nie wpływają na 99.9% kodu pisanego w C++ najmniejszym stopniu 
oraz identyczne problemy występują w każdym, dowlnym języku i kompilatorze.

>   - o wydłużonym czasie kompilacji, zwiększonym rozmiarze kodu i słabym

Atari 65XE słabo się sprawdza jako ciągła integracja, podobnie klikanie 
w "rebuild".

>     pokazywaniu właściwej linii z syntax error - już pisałem.

To dobrze, bo w clangu też to zauważyli

>   - o tym jak to wygląda z punktu widzenia kogoś kto przygotowuje
>     wygodny szablon - też już pisałem.

Ale to nikogo nie obchodzi po stronie klienta.

>> Szablony rozwiazują dobrze kreśloną klasę problemów z jakością kodu.
> Zgoda, ale wprowadzają też inne problemy.

Nie. Ich naduzywanie może generować problemy. Zastapienie void* silnym 
typem nie tylko jest oczywistym rozwiązaniem problemów z jakoscią kodu 
ale wręcz zmusza do poprawy jego jakości podczas pisania.

Perwsze słyszę aby silne typy miał jakieś wady vs void*.

Na marginesie: void* to nie brak typu. To typ. Coś jak by pisać w javie 
kastujac wszystko do Object i spowrtoem za każdym razem. Po h.. ?

> Choć podsumowanie dziś wypada na
> korzyść szablonów, to po odjęciu wad, to podsumowanie nie jest rewelacyjne.

Stosujesz typową metodę dyskutowania: będę wyważony, to będę brzmiał 
mądrze. Tylko że te "nie jest rewelacyjne" jest troche smutne w 
zderzeniu z faktem że szablony są <division by zero exception> razy 
lepsze od void*.

>> W C nie ma nic co mogło by to zastapić poza modlitwą.
> Zewnętrzne programy narzędziowe pełny rolę generyków, sam jeden większy
> generator napisałem do generowania sieci neuronowych. No i był void* i
> makra ;-)

Kto komu broni generować kod z void*. Pisanie void* z palca jest porażką 
a nie generowanie.

>> Jesteś pewien że masz wszystko dobrze że masz potrzebę pełnej rekompilacji?
> Bym musiał napisać (i potem pilnować) specjalne pliki make, które uwzględniają
> kompilację warunkową.

I robisz to co 30 sekund? Czy może robi to ciągła integracja?

> Nie wiem co gorsze, modlić się czy nie mam błędu w
> pliku make, czy czekać te 30 sekund.

To nie ty czekasz. To ciągła integracja czeka. Ty popijasz kawę, albo 
robisz coś innego.

>> Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny że
>> nie powinien być uważany za reprezentacyjny.
> Nie wiem czy kiepski przypadek, sam przyznałeś że ludzie od boosta
> się napracowali ciężko...

Nie widzę związku.

Zmieniasz globalnego define. Wymaga to rekompilacji wszystkiego. 
Argument że wtedy jest wolno jest taki sam w C jak i w C++.

>> Z faktu że ktoś kiedyś robił kupę bez papieru nie wynika że papier jest
>> zbędny obecnie.
> No nie, mamy papier, żyje się trochę lepiej, ale musimy za niego zapłacić,
> go produkować, oczyszczać [...]

Niekiedy daleko idace analogie są błedne.

C++ jest za friko.

Napisanie Foo* zamiast void* jest za friko.

RAII jest za friko.

W ogóle wszystko jest za friko.

Upierdiwy profesor powie że plik kompiluje się 1.7ms dłużej. I będzie 
miał rację. Ten 3-ci rodzaj racji. Coś jak uszczędzanie na plastikowych 
słomkach w prywatnych samolotach.

>>>> Na patrz, a ja miałem Amigę z 2MB pamięci chip i na tej konfiguracji
>>>> poganiałem SaSC w trybie C++ pisząc obiektowe programy GUIowe. Może to
>>>> czary?
>>> Może czary, a może to (w jakimś stopniu) dzięki void* ?
>> Nie, C++ z szablonami. SaSC miał translator z C++ na generowany C.
> Tak. Były generyki i w C, tylko na poziomie narzędzi a nie języka.

Nie rozumiesz. SasC to był również normalny C++. To że w środku 
konwertował to na C i kompilował, to detal. Nieistotny. Niewidoczny.

Miałem więc kompilator C++ na 2MB RAMu bez swapa i dało się w tym pisać 
obiektowe i okienkowe aplikacje o przyzwoitej wydajnosci. Ba, o 
wydajności zbliżonej do tej z C. Róznica była głównie w tym że ten 
konwerter był *bardzo* kiepski.

>> Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z
>> wyborem języka C czy C++. Ma związek jedynie z kiepskimi programistami,
>> przyrostem danych i rozbudową OSów.
> Też mi jest trudno się wypowiedzieć, w sumie nie biorę udziału w
> programach których kod wynikowy nie mieści się na DVD. Myślę jednak
> że zdublowanie kodu ma największy wpływ.

Całe szczęscie C++ nie dubluje kodu sam z siebie jesli ludzie nie piszą 
byle jak.