W dniu piątek, 4 stycznia 2019 08:15:55 UTC+1 użytkownik Maciej Sobczak napisał:

> > Co w takim razie wnoszą referencje w C++? (oprócz niepotrzebnej komplikacji)
>
> Uwaga: dopiero co usiłowałeś udowodnić, że operator przypisania jest niepotrzebny.

Tak?
W którym miejscu próbowałem "udowodnić coś takiego"?

Ogólnie wydaje mi się, że gdybyś odnosił się do rzeczy,
które napisałem, zamiast do tych, które wydaje Ci się,
że napisałem, obaj byśmy na tym skorzystali.

> Uwaga na dwie różne rzeczy. Referencje same w sobie to aliasy i służą właśnie do
tego, żeby upraszczać zapis (o tym pisał AK) a nie żeby cokolwiek komplikować.

A jednak coś komplikują.

> Drugie zastosowanie referencji to przekazywanie argumentów bez konieczności ich
kopiowania. Służą wydajności i są czytelniejsze, niż wskaźniki a pozwalają nie
kombinować z dodatkowymi "trybami" czy innymi "modami" parametrów podprogramów.

Kwestia tego, czy występuje "konieczność kopiowania" argumentów, ma
sens tylko w kontekście, w którym dokonujemy modyfikacji argumentów.

> > Co takiego staje się możliwe dzięki nim, co nie było możliwe bez nich?
>
> Pisanie bardziej czytelnego kodu. Widać to bardzo dobrze gdy porówna się API
bibliotek mających osobne wersje dla C i C++.

Dzięki. Lubię konkrety, a w szczególności obiektywne sformułowania
w rodzaju "bardziej czytelny kod".

> > > W tym wypadku wartością dodaną jest możliwość korzystania z jakieś ograniczonej
formy lambdy, bez konieczności posiadania garbage collectora.
> >
> > Pierwszy kompilator języka Scheme, ORBIT, dawał ograniczoną
> > formę lambdy i nie potrzebował garbage collectora.
>
> W jaki sposób realizował upward-closure?

Używając garbage collectora napisanego w Schemie bez upward-closure.

> > > Inaczej - istnieje pewna klasa projektów, w których nikt[*] nie ma lepszej
oferty.
> >
> > Jeśli pominiemy takie języki jak np. Rust.
>
> Ciekawe:
>
> https://doc.rust-lang.org/1.1.0/book/closures.html
>
> "So if we returned this closure, the function call would be over, the stack frame
would go away, and our closure is capturing an environment of garbage memory!"
>
> Jest podane rozwiązanie tego problemu, ale nie wiem, czy ten mechanizm jest
stosowalny tak samo wygodnie dla różnych przypadków, które można sobie wyobrazić. W
C++ po prostu dano użytkownikom narzędzie i obowiązek do samodzielnego rozstrzygania
takich problemów. W tym przypadku problem nie jest trudny do rozstrzygnięcia i nie
wiem, czy chcę mieć aż tak dużą dodatkową komplikację na poziomie języka, żeby ten
problem rozwiązać.
> Tzn. potrafię nie mieć problemu z wiszącymi referencjami w C++ przy składni
prostszej, niż oferuje Rust, więc w tym konkretnym przypadku Rust jest dla mnie
niepotrzebnym kosztem.
>
> Rust jest ciekawym pomysłem (ogólnie w aspekcie zarządzania czasem życia obiektów),
ale potrzeba jeszcze czasu, żeby ocenić jego przydatność w praktyce.
> Pod pojęciem praktyki rozumiem np. system, dla którego istnieje kompilator C++ a
dla którego nie istnieje kompilator Rust. Praktyka to również dostępne narzędzia
pomocnicze w rodzaju analizatorów statycznych. Być może Rust zyska sympatię
użytkowników i stanie się popularny, nie potrafię tego jeszcze rozstrzygnąć.
>
> > Standard GNU C
>
> To tak jakbyś napisał "Standard Visual C".

Być może. Takie użycie sugeruje sam komplikator, do którego podaje się
flagę -std=gnu99 (zamiast np. -std=c99).

do góry

> Ogólnie wydaje mi się, że gdybyś odnosił się do rzeczy,
> które napisałem, zamiast do tych, które wydaje Ci się,
> że napisałem, obaj byśmy na tym skorzystali.

Przecież się nie da. Muszę odnosić się do tego, co mi się wydaje. Potem Ty musisz się
denerwować tym, co Ci się wydaje, że ja się odniosłem. Żeby było śmieszniej, żaden z
nas nie jest w stanie udowodnić, że tego nie robi. Taka już nasza niedoskonałość.

> Kwestia tego, czy występuje "konieczność kopiowania" argumentów, ma
> sens tylko w kontekście, w którym dokonujemy modyfikacji argumentów.

Nie, to jest też kwestia miejsca wywołania (nie wszystko co wołający chciałby
przekazać można przekazać przez referencję), wydajności, semantyki wyjątków oraz
wielowątkowości. W C++ te rzeczy są ważne. Oczywiście, są też języki, gdzie te rzeczy
nie są ważne.

> > > Co takiego staje się możliwe dzięki nim, co nie było możliwe bez nich?

Nic, czego by się nie dało zrobić maszyną Turinga. Ale ludzie jednak wolą to mieć,
niż nie mieć.

> Dzięki. Lubię konkrety, a w szczególności obiektywne sformułowania
> w rodzaju "bardziej czytelny kod".

Ja nie mam żadnego problemu z subiektynymi sformułowaniami. Zwłaszcza po Twojej
deklaracji z innego postu, że przedstawiasz tutaj swoje wrażenia i opinie nt. C++.

> > > > W tym wypadku wartością dodaną jest możliwość korzystania z jakieś
ograniczonej formy lambdy, bez konieczności posiadania garbage collectora.
> > >
> > > Pierwszy kompilator języka Scheme, ORBIT, dawał ograniczoną
> > > formę lambdy i nie potrzebował garbage collectora.
> >
> > W jaki sposób realizował upward-closure?
>
> Używając garbage collectora napisanego w Schemie bez upward-closure.

Rozumiem. W C++ też nie ma garbage-collectora właśnie po to, żeby można było go sobie
samemu napisać.

> > > Standard GNU C
> >
> > To tak jakbyś napisał "Standard Visual C".
>
> Być może. Takie użycie sugeruje sam komplikator, do którego podaje się
> flagę -std=gnu99 (zamiast np. -std=c99).

Ja trochę inaczej rozumiem słowo "standard". Subiektywnie, oczywiście.

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu poniedziałek, 7 stycznia 2019 07:59:29 UTC+1 użytkownik Maciej Sobczak
napisał:
> > Ogólnie wydaje mi się, że gdybyś odnosił się do rzeczy,
> > które napisałem, zamiast do tych, które wydaje Ci się,
> > że napisałem, obaj byśmy na tym skorzystali.
>
> Przecież się nie da. Muszę odnosić się do tego, co mi się wydaje. Potem Ty musisz
się denerwować tym, co Ci się wydaje, że ja się odniosłem. Żeby było śmieszniej,
żaden z nas nie jest w stanie udowodnić, że tego nie robi. Taka już nasza
niedoskonałość.

Pomijając może ekstremalne filozoficzne eksperymenty myślowe w rodzaju
"demona Kartezjusza" czy sceptycyzmu Berkeleya, w tzw.
"zdroworozsądkowej" metafizyce nie ma powodów, żeby uznać,
że nie masz całkowitego wglądu w to, co napisałem.

Możesz nie mieć wglądu w to, co miałem na myśli (a właściwie
to według mojej wiedzy raczej nie możesz mieć w to wglądu),
ale to, co napisałem, jest raczej obiektywnie (bądź co najmniej
intersubiektywnie) weryfikowalne.

I tak na przykład, pisałem, żeby unikać operacji przypisania tam,
gdzie to nie jest konieczne. Możesz to sprawdzić, przeglądając
historię naszej rozmowy.
Możesz też sprawdzić (ponieważ dziedzina naszej rozmowy jest
skończona), że nigdzie tam nie pisałem, że "operator
przypisania jest niepotrzebny".

Oczywiście nie chodzi o to, żeby być obsesyjnym formalistą
w komunikacji: każdy ma przecież prawo do wyciągania swoich
własnych wniosków z tego, co mówię i tego, co mówią inni.

Ale w takiej sytuacji, jeżeli wyciągasz jakiś własny wniosek
z czyjejś wypowiedzi, i ten wniosek jest dość daleki od
oryginalnych słów, to zamiast atakować rozmówcę w oparciu
o ten wniosek, możesz powiedzieć coś w rodzaju:

"Powiedziałeś X. Z mojego rozumowania wynika, że pociąga to za sobą Y,
ale być może wplatam w to jeszcze jakieś swoje dodatkowe przesłanki.
Czy zgodziłbyś się ze stwierdzeniem, że Y?"

Ja domniemywam, że po żadnej ze stron nie ma złej woli.
Mam też wrażenie, że "zimność" komunikacji internetowej mocno
zaburza przekaz emocjonalny (czasem nawet jak rozmawiam ze swoimi
bliskimi znajomymi na czacie internetowym, to przekaz emocjonalny
tak się zniekształca, jakbyśmy byli najgorszymi wrogami, którzy
chcą się pozabijać)

Ale moja percepcja Twoich słów jest taka, że nie wypowiadasz
ich po to, żeby dowiedzieć się, co mam na myśli, tylko po to,
żeby udowodnić mi, że nie mam racji.
Może Twoja prawdziwa motywacja jest inna - to akurat wiesz
tylko Ty - ale ja nie mam ani czasu, ani siły, ani ochoty do tego,
żeby bronić się przed atakami, bo nie przyszedłem tutaj
po to, żeby walczyć, tylko po to, żeby wymieniać się
doświadczeniami.

Jeżeli zarzuciłbyś mi, że wypowiadam się nieprecyzyjnie, to
oczywiście musiałbym się z tym zarzutem zgodzić. Mam wrażenie,
że nieprecyzyjność jest naturalną cechą języka naturalnego,
i próby używania go w sposób hiper-precyzyjny są skazane na porażkę
(między innymi dlatego cenię sobie języki programowania, bo
pozwalają się komunikować w sposób hiper precyzyjny bez żadnego
miejsca na niejednoznaczność)

do góry

> I tak na przykład, pisałem, żeby unikać operacji przypisania tam,
> gdzie to nie jest konieczne.

I od samego początku ta teza nie została poparta żadnym przykładem. Zmienne statyczne
omówiliśmy, ale czy ich przykładowe nadużycie jest jedynym takim miejscem? Gdzie
jeszcze nie jest konieczne?

> nigdzie tam nie pisałem, że "operator
> przypisania jest niepotrzebny".

Przepraszam za skrót myślowy. Łączę tą kwestię z ogólną niechęcią zwolenników
programowania funkcjonalnego do modyfikowalnego stanu.

> Ale moja percepcja Twoich słów jest taka, że nie wypowiadasz
> ich po to, żeby dowiedzieć się, co mam na myśli, tylko po to,
> żeby udowodnić mi, że nie mam racji.

Inaczej: mając wrażenie, że dowiedziałem się już, co masz na myśli, udowadniam, że
nie masz racji. :-) Jest bardzo możliwe, że gdzieś się mijamy w naszych wrażeniach,
ale ponieważ dziedzina jest techniczna, to zawsze staram się odwoływać do przykładów
(albo prosić o przykłady) z kodem.

> (między innymi dlatego cenię sobie języki programowania, bo
> pozwalają się komunikować w sposób hiper precyzyjny bez żadnego
> miejsca na niejednoznaczność)

Właśnie.

A skoro i tak weszliśly już w tym podwątku na poziom miękki, to pozwolę sobie na
drobne wyjaśnienie. Być może masz wrażenie, że się Ciebie czepiam dla samego
czepiania, ale moja perspektywa jest inna. Otóż padło tutaj w dyskusji N zarzutów
wobec różnych rzeczy (książki, języka, paradygmatu, itd.) cieszących się w miarę
szerokim poważaniem i wśród tych zarzutów jest M, z którymi się nie zgadzam. A
ponieważ na tej grupie jest bardzo mało okazji do dyskusji, więc korzystam z tych M.
Gdyby te N zarzutów było napisanych przez N różnych grupowiczów, to również wtedy nie
zgodziłbym się z M z nich i odniósłbym się do nich (z grubsza) w taki sam sposób.
Tymczasem zupełnym przypadkiem te M dyskusyjnych kwestii pochodzi od jednego
grupowicza. Tak, jesteś jedyną osobą, która w ostatnim czasie konsekwentnie forsuje
tutaj pewien nurt techniczny, który z racji swojej dzisiejszej niszowości jest
kontrowersyjny (co nie znaczy, że nowatorski a przez to nieznany). Inaczej mówiąc,
fakt, że spada na Ciebie cały ogień obrony jest z mojego punktu widzenia wyłącznie
przypadkiem, jeśli nie Twoją winą, skoro jesteś jedynym atakującym. :-)

To rzekłszy, dawno temu był tu grupowicz podpisujący się jako Qrczak. Forsował mniej
więcej te same poglądy a nawet popełnił własny język programowania o nazwie Kogut
(http://kokogut.sourceforge.net/kogut.html). Nie wykluczam, że go znasz. Niestety nie
zagląda już tutaj, ale jestem przekonany, że świetnie byście się dogadali, na pewno z
korzyścią dla grupy.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 2019-01-08 09:46, Maciej Sobczak wrote:

>> nigdzie tam nie pisałem, że "operator
>> przypisania jest niepotrzebny".
>
> Przepraszam za skrót myślowy. Łączę tą kwestię z ogólną niechęcią zwolenników
> programowania funkcjonalnego

Rozumiem, ze do C++ ?
To prawda. Z prostego powodu.
Jezyk C++ na pewno jezykiem funcjonalnym nie jest.

AK

do góry

On 2019-01-08 09:51, AK wrote:
> On 2019-01-08 09:46, Maciej Sobczak wrote:
>
>>> nigdzie tam nie pisałem, że "operator
>>> przypisania jest niepotrzebny".

... taki Python (w ogolnosci - wylaczajac prymitywy) nie posiada
operatora przypisania i ma sie bardzo dobrze. Java (w ogolnosci -
wylaczajac prymitywy) tez nie ma "wartosciowego" operatora przypisania
i co ? Jakos z tego powodu nie umiera.
A stan? Do stanu jako takiego nic nie mam, ale ustawiczne (w wiekszosci
niejawne) tworzenie nowego stanu/stanow "defaultowo" (jak to sie dzieje
C++) bylo chore, jest chore i bedzie chore czysie to Szanownym
Ayatollahom C++ podoba czy nie.
PS: Dlatego cenie (a nawet kiedys lubilem) Qt bo likwiduje w duzym
stopniu ta "wspaniala ceche" jezyka zwanego C++.
PS0: ciekawy bylby ranking czestosci uzycia instrukcji movsb/movcw/movsd
w C++ i w innych jezykach programowania.
C++ to taki "unnecessary copying of memory/bytes" driven language :)

AK

do góry

> ... taki Python (w ogolnosci - wylaczajac prymitywy) nie posiada
> operatora przypisania i ma sie bardzo dobrze. Java (w ogolnosci -
> wylaczajac prymitywy) tez nie ma "wartosciowego" operatora przypisania
> i co ?

No, jak wyłączymy z rozważań te miejsca, gdzie operacja przypisania jest, to
faktycznie będzie wyglądać tak, jakby jej nie było.

Ale jednak jest.

> C++ to taki "unnecessary copying of memory/bytes" driven language :)

Ale wiesz, dlaczego zrezygnowano z optymalizacji COW (Copy On Write) w niektórych
implementacjach biblioteki standardowej? Tzn. tam, gdzie np. przypisanie stringów
robione było przez współdzielenie wartości, aż do najbliższej modyfikacji jednego z
obiektów?
Bo okazało się, że na współczesnych CPU szybciej się kopiuje bajty (tak do paru kB,
co jest najczęstszym przypadkiem), niż robi barierę pamięci.

Nie jest łatwo być dobrym krytykiem C++, nie chciałbym mieć takiego hobby. :-)

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu wtorek, 8 stycznia 2019 09:46:50 UTC+1 użytkownik Maciej Sobczak napisał:
> > I tak na przykład, pisałem, żeby unikać operacji przypisania tam,
> > gdzie to nie jest konieczne.
>
> I od samego początku ta teza nie została poparta żadnym przykładem. Zmienne
statyczne omówiliśmy, ale czy ich przykładowe nadużycie jest jedynym takim miejscem?
Gdzie jeszcze nie jest konieczne?

Gwoli ścisłości: to nie było "przykładowe nadużycie".
To był najprostszy możliwy przykład użycia zmiennej
statycznej. I to nie był przykład na zły styl w programowaniu
- czasem konstrukcje tego typu mogą mieć sens.
To był przykład na to, w jaki sposób "mutowalny stan"
komplikuje nasze środki analizy programu.
I nie chodzi o to, że programy, które używają "mutowalnego
stanu" są "gorsze" od takich, które go nie używają. Ja tak
nie twierdzę. Twierdzę, że są - co do zasady - trudniejsze
do zrozumienia, co - jak sądzę - zobrazowałem programem
liczącym sumę kwadratów początkowych siedmiu liczb pierwszych,
który się gdzieś w tym wątku przewinął.

> > nigdzie tam nie pisałem, że "operator
> > przypisania jest niepotrzebny".
>
> Przepraszam za skrót myślowy. Łączę tą kwestię z ogólną niechęcią zwolenników
programowania funkcjonalnego do modyfikowalnego stanu.

No ja się czasem spotykam z ludźmi, którzy twierdzą, że "programy
funkcyjne są lepsze, bo są lepsze", albo "są lepsze, bo są
przejrzyste odniesieniowo", i którzy robią rzeczy prawdziwie
kuriozalne. Uważam, że to głupota.

Ale też uważam, że warto dobierać najprostsze środki do realizacji
danego celu. Jeżeli coś można zrobić bez przypisania, bo pojęcie
stanu nie jest istotnym składnikiem rozwiązywanego problemu, to
lepiej to tak zrobić. I są pewne konkretne powody ku temu
- mianowicie to, że zyskujemy możliwość analizy kodu w terminach
podstawień, a nie w terminach przepływu sterowania, który w wielu
sytuacjach jest dla nas nieinteresujący (a nawet ograniczający)

> > Ale moja percepcja Twoich słów jest taka, że nie wypowiadasz
> > ich po to, żeby dowiedzieć się, co mam na myśli, tylko po to,
> > żeby udowodnić mi, że nie mam racji.
>
> Inaczej: mając wrażenie, że dowiedziałem się już, co masz na myśli, udowadniam, że
nie masz racji. :-) Jest bardzo możliwe, że gdzieś się mijamy w naszych wrażeniach,
ale ponieważ dziedzina jest techniczna, to zawsze staram się odwoływać do przykładów
(albo prosić o przykłady) z kodem.

Ja też. Nawet w dziedzinach nietechnicznych
Jeżeli ktoś nie jest w stanie podać przykładów
na rzecz swoich twierdzeń, to jest to dla mnie
silna przesłanka za tym, żeby uznać, że nie wie,
co mówi (albo że tak sobie po prostu gada)

> > (między innymi dlatego cenię sobie języki programowania, bo
> > pozwalają się komunikować w sposób hiper precyzyjny bez żadnego
> > miejsca na niejednoznaczność)
>
> Właśnie.
>
> A skoro i tak weszliśly już w tym podwątku na poziom miękki, to pozwolę sobie na
drobne wyjaśnienie. Być może masz wrażenie, że się Ciebie czepiam dla samego
czepiania, ale moja perspektywa jest inna. Otóż padło tutaj w dyskusji N zarzutów
wobec różnych rzeczy (książki, języka, paradygmatu, itd.) cieszących się w miarę
szerokim poważaniem i wśród tych zarzutów jest M, z którymi się nie zgadzam. A
ponieważ na tej grupie jest bardzo mało okazji do dyskusji, więc korzystam z tych M.
Gdyby te N zarzutów było napisanych przez N różnych grupowiczów, to również wtedy nie
zgodziłbym się z M z nich i odniósłbym się do nich (z grubsza) w taki sam sposób.
> Tymczasem zupełnym przypadkiem te M dyskusyjnych kwestii pochodzi od jednego
grupowicza. Tak, jesteś jedyną osobą, która w ostatnim czasie konsekwentnie forsuje
tutaj pewien nurt techniczny, który z racji swojej dzisiejszej niszowości jest
kontrowersyjny (co nie znaczy, że nowatorski a przez to nieznany). Inaczej mówiąc,
fakt, że spada na Ciebie cały ogień obrony jest z mojego punktu widzenia wyłącznie
przypadkiem, jeśli nie Twoją winą, skoro jesteś jedynym atakującym. :-)

Rozumiem.
Choć nie zgodzę się z tym, że cokolwiek forsuję. Może "promuję"
byłoby lepszym słowem.

> To rzekłszy, dawno temu był tu grupowicz podpisujący się jako Qrczak. Forsował
mniej więcej te same poglądy a nawet popełnił własny język programowania o nazwie
Kogut (http://kokogut.sourceforge.net/kogut.html). Nie wykluczam, że go znasz.
Niestety nie zagląda już tutaj, ale jestem przekonany, że świetnie byście się
dogadali, na pewno z korzyścią dla grupy.

Kojarzę go, choć może raz z nim rozmawiałem, ale rzeczywiście
było to dawno.
Ciekawostką jest, że ostatnio upvote'ował dwie moje odpowiedzi
na Quorze, w tym jedną, którą wkleiłem na początku naszej rozmowy,
i drugą, w której krytykowałem C++, skąd dowiedziałem się, że też ma
profil na Quorze:
https://www.quora.com/profile/Marcin-Kowalczyk-11

do góry

On 2019-01-08 10:51, Maciej Sobczak wrote:
> Ale wiesz, dlaczego zrezygnowano z optymalizacji COW (Copy On Write) w niektórych
implementacjach biblioteki standardowej? Tzn. tam, gdzie np. przypisanie stringów
robione było przez współdzielenie wartości, aż do najbliższej modyfikacji jednego z
obiektów?
> Bo okazało się, że na współczesnych CPU szybciej się kopiuje bajty (tak do paru kB,
co jest najczęstszym przypadkiem), niż robi barierę pamięci.

Hehe. Typowe dorabianie teorii do wlasnego "widzimisie".
Otoz "widzi Ci sie".
Zrezygnowano dlatego ze CoW po prostu nie jest thread-safe.
Sam na poczatku lat 2000 chcac nie chcac bylem "zanurzony" w
implementacji stl (zwanej tsl), ktora musiala byc napisana
"from scratch" z powodu niethreadowatosci std::string (i nie tylko)
co skutkowalo"wypadami" w srodowisk wielowatkowym.
PS: STLPort-a albo jeszcze nie byo albo nie mozna go bylo
uzyc z innych powodow (nie pamietam).

> Nie jest łatwo być dobrym krytykiem C++, nie chciałbym mieć takiego
hobby.

Jest bardzo latwo. Zwlaszcza gdy sie go uzywa produkcyjnie 32+ lata.

PS: Kiedys sam bylem propagatorem C++ (bo na slabenkich XT/AT nic
sensownego nie bylo. Te czasy jednak(i bardzo dobrze) juz daaaawno
minely, wiec wciaz mnie "dziw bierze" ze dzisiejsza "Nowoczesna"
Mlodziez tak bardzo lubui grzebac sie w starociach :)
PS: Moze ona tan naprawde bardziej skostniala/zapyzala niz
mysli/nic sa dinozaury ? :)

AK

do góry