W dniu czwartek, 27 grudnia 2018 19:20:20 UTC+1 użytkownik Maciej Sobczak napisał:
> > > Jakich złych nawyków?
> >
> > Pewnie teraz nawet sobie nie jestem w stanie tego wszystkiego
> > uświadomić.
>
> Ale chociaż ze dwa przykłady, dla potomności.

Przykłady podałem w linku (i szczerze wątpię, żeby potomność
zechciała kiedykolwiek grzebać na tym śmietnisku).

> > Z rzeczy najbardziej oczywistych byłoby to używanie
> > operatora przypisania tam, gdzie nie jest to konieczne.
>
> Np. gdzie nie jest konieczne?
> I dlaczego to jest zły nawyk?

W większości miejsc nie jest konieczne.
A jest to zły nawyk, ponieważ - mówiąc skrótowo - zwiększa złożoność
środków analizy programów i tworzy "przypadkową złożoność".
Dokładniej jest to wyjaśnione tutaj:
https://mitpress.mit.edu/sites/default/files/sicp/fu
ll-text/book/book-Z-H-20.html#%_sec_3.1.3
ale wyjaśnienie odwołuje się do sekcji 1.1.5.

> > Inna rzecz, to bałaganiarskie podejście do projektowania interfejsów,
> > które wydaje się w środowiskach C++-owych na porządku dziennym.
>
> "Bałaganiarskie", "wydaje się", "w środowiskach"? Brzmi jak słaba propaganda.

To nie jest propaganda, więc nie może to być "słaba propaganda".
Nic nikomu nie sprzedaję.
Pytasz o moje doświadczenia, to Ci mówię.
Jeżeli Cię nie interesują albo masz sobie z nich szydzić,
to nie pytaj.

> > Dużo rzeczy opisałem tutaj:
> > https://www.quora.com/What-are-some-examples-of-bad-
code/answer/Panicz-Godek
>
> Nie czytałem całości, bo na początku artykułu okazało się, że znalazłeś gdzieś w
necie źle napisany kod i postanowiłeś go skrytykować. OK, takie artykuły są
potrzebne, ale nie odpowiadają na moje pytanie o *złe nawyki*. Coś, co jest cechą
języka. Czyli coś, co musi być złe, bo język narzuca to zło użytkownikowi. Niczego
takiego pobieżnie nie zauważyłem w tym artykule.

Nawyki nie są "cechą języka", tylko ludzi.
Języki mogą pomagać wykształcać w ludziach takie czy inne nawyki.
Więcej, wokół języków tworzą się kultury.
Artykuł, który podlinkowałem, to nie jest "po prostu randomowy
kod który znalazłem gdzieś w necie": to jest kod, którym ktoś
się podzielił, żeby inni mogli go czytać. I to jest kod pełen
anty-wzorców, których źródłem są właśnie złe nawyki. To jest kod,
który utrwala w ludziach złe nawyki. I, co znamienne, to jest kod,
który nie jest nietypowy dla programistów C++. Powiedziałbym
(na podstawie swoich doświadczeń), że jest bardzo typowy.
W przeciwnym razie nie zadawałbym sobie trudu, żeby o nim pisać.

Mogę też spróbować sformułować tę myśl inaczej:
postaraj się odpowiedzieć na pytanie, dlaczego
taki "zły kod" powstaje.

(Oczywiście, specyfika C++ odgrywa tutaj pewną istotną rolę:
w C++ trudno się programuje generycznie. Nie twierdzę, że się nie da,
ale w C++ łatwiej się operuje na konkretnych reprezentacjach, niż na
abstrakcyjnych generycznych interfejsach. Podczas pisania artykułu
szukałem różnych generycznych implementacji algorytmu A* w C++,
i żadna z nich nie była dobra. Z kolei w Haskellu jest odwrotnie:
tutaj łatwo napisać jedną ogólną interpretację i ukonkretniać ją
dla poszczególnych problemów, zaś pewne antywzorce, które są w C++
powszechne, takie jak przekazywanie informacji przez zmienne globalne,
są bardzo trudne do wyrażenia)

> Czyli na razie ten artykuł wpada u mnie w kategorię "C++ jest zły, bo znalazłem
kiepski kod w necie". To nie jest odpowiedź na moje pytanie.

Interesujące.
Mogę wskazać wiele quorowych odpowiedzi wyjaśniających, dlaczego
C++ jest zły, ale artykuł, który napisałem, w żadnym stopniu tego
nie dotyczy.

do góry

W dniu czwartek, 27 grudnia 2018 23:53:33 UTC+1 użytkownik g...@g...com
napisał:
> W dniu czwartek, 27 grudnia 2018 19:20:20 UTC+1 użytkownik Maciej Sobczak napisał:
> > > > Jakich złych nawyków?
> > >
> > > Pewnie teraz nawet sobie nie jestem w stanie tego wszystkiego
> > > uświadomić.
> >
> > Ale chociaż ze dwa przykłady, dla potomności.
>
> Przykłady podałem w linku (i szczerze wątpię, żeby potomność
> zechciała kiedykolwiek grzebać na tym śmietnisku).
>
> > > Z rzeczy najbardziej oczywistych byłoby to używanie
> > > operatora przypisania tam, gdzie nie jest to konieczne.
> >
> > Np. gdzie nie jest konieczne?
> > I dlaczego to jest zły nawyk?
>
> W większości miejsc nie jest konieczne.
> A jest to zły nawyk, ponieważ - mówiąc skrótowo - zwiększa złożoność
> środków analizy programów i tworzy "przypadkową złożoność".
> Dokładniej jest to wyjaśnione tutaj:
> https://mitpress.mit.edu/sites/default/files/sicp/fu
ll-text/book/book-Z-H-20.html#%_sec_3.1.3
> ale wyjaśnienie odwołuje się do sekcji 1.1.5.
>
> > > Inna rzecz, to bałaganiarskie podejście do projektowania interfejsów,
> > > które wydaje się w środowiskach C++-owych na porządku dziennym.
> >
> > "Bałaganiarskie", "wydaje się", "w środowiskach"? Brzmi jak słaba propaganda.
>
> To nie jest propaganda, więc nie może to być "słaba propaganda".
> Nic nikomu nie sprzedaję.
> Pytasz o moje doświadczenia, to Ci mówię.
> Jeżeli Cię nie interesują albo masz sobie z nich szydzić,
> to nie pytaj.
>
> > > Dużo rzeczy opisałem tutaj:
> > > https://www.quora.com/What-are-some-examples-of-bad-
code/answer/Panicz-Godek
> >
> > Nie czytałem całości, bo na początku artykułu okazało się, że znalazłeś gdzieś w
necie źle napisany kod i postanowiłeś go skrytykować. OK, takie artykuły są
potrzebne, ale nie odpowiadają na moje pytanie o *złe nawyki*. Coś, co jest cechą
języka. Czyli coś, co musi być złe, bo język narzuca to zło użytkownikowi. Niczego
takiego pobieżnie nie zauważyłem w tym artykule.
>
> Nawyki nie są "cechą języka", tylko ludzi.
> Języki mogą pomagać wykształcać w ludziach takie czy inne nawyki.
> Więcej, wokół języków tworzą się kultury.
> Artykuł, który podlinkowałem, to nie jest "po prostu randomowy
> kod który znalazłem gdzieś w necie": to jest kod, którym ktoś
> się podzielił, żeby inni mogli go czytać. I to jest kod pełen
> anty-wzorców, których źródłem są właśnie złe nawyki. To jest kod,
> który utrwala w ludziach złe nawyki. I, co znamienne, to jest kod,
> który nie jest nietypowy dla programistów C++. Powiedziałbym
> (na podstawie swoich doświadczeń), że jest bardzo typowy.
> W przeciwnym razie nie zadawałbym sobie trudu, żeby o nim pisać.
>
> Mogę też spróbować sformułować tę myśl inaczej:
> postaraj się odpowiedzieć na pytanie, dlaczego
> taki "zły kod" powstaje.
>
> (Oczywiście, specyfika C++ odgrywa tutaj pewną istotną rolę:
> w C++ trudno się programuje generycznie. Nie twierdzę, że się nie da,
> ale w C++ łatwiej się operuje na konkretnych reprezentacjach, niż na
> abstrakcyjnych generycznych interfejsach. Podczas pisania artykułu
> szukałem różnych generycznych implementacji algorytmu A* w C++,
> i żadna z nich nie była dobra. Z kolei w Haskellu jest odwrotnie:
> tutaj łatwo napisać jedną ogólną interpretację i ukonkretniać ją
> dla poszczególnych problemów, zaś pewne antywzorce, które są w C++
> powszechne, takie jak przekazywanie informacji przez zmienne globalne,
> są bardzo trudne do wyrażenia)
>
> > Czyli na razie ten artykuł wpada u mnie w kategorię "C++ jest zły, bo znalazłem
kiepski kod w necie". To nie jest odpowiedź na moje pytanie.
>
> Interesujące.
> Mogę wskazać wiele quorowych odpowiedzi wyjaśniających, dlaczego
> C++ jest zły, ale artykuł, który napisałem, w żadnym stopniu tego
> nie dotyczy.

nie wiem czy w postach wyzej to napisalem (jesli nie to mialem wspomniec ale widac
nie napisalem) ale wg pewnych moich przemyslen (wykonanych calkiem w sumie niedawno)
doszedlem do dosyc prostego wniosku ze w programowaniu jezyki sa porzebne co najmniej
dwa: jest potrzebny taki jezyk jak c,. tj jezyk ktory pozwali dobrze oszczednie
zarzadzac bajtami i cyklami oraz jest tez potrzeby inny jezyk ktory pozwala dobrze
(choc tutaj co znaczy dobrze byc moze nie jest dla mnie tak wyraznie jasne) zarzadzac
czyms innym niz bajty i cykle (bo w pewnych zastosowaniech programistycznych, np
jezyk skryptowy w shellu nie potrzebujesz zarzadzania bajtami i cyklami)

o ile te ustalenia sa prawdziwe (a arczej sa choc jak mowie sa dosyc fragmentaryczne
i tak naprawde nie bardzo wiem w czym ten drugi jezyk powinien byc tak naprawde
dobry) to nie mozna krytykowac takich jezykow jak c realizujacych to zarzadzanie
bajtami i cyklami jako ogolnie niedobrych - sa one w swojej dziedzinie (dosyc
szerokiej) najlepsze i nie ma co do tego raczej kwestii (zieaw)

co do tej drugiej dziedziny albo dziedzin to juz inna kwestia, jak powinien wygladac
jezyk lub jak powinny wygladac jezyki w tej dziedzinie gdzie cykle i bajty sie liczą
ale nie az tak to (ciagle) nie wiem

do góry

> Przykłady podałem w linku (i szczerze wątpię, żeby potomność
> zechciała kiedykolwiek grzebać na tym śmietnisku).

W linku był artykuł o kiepskim kodzie, który znalazłeś w necie. Krytyka języka z tego
żadna. Zwłaszcza w przypadku języka, który jest popularny a przez to używany również
przez tych, którzy uniwersalnie piszą kiepski kod.

[operator przypisania]

> W większości miejsc nie jest konieczne.
> A jest to zły nawyk, ponieważ - mówiąc skrótowo - zwiększa złożoność
> środków analizy programów

Nie, nie zwiększa.

Albo, jeśli faktycznie zwiększa, to jest to problem autorów takich narzędzi a nie
użytkowników języka. Jako użytkownik języka akceptuję ten układ. Ba - ja go nawet
akceptuję jako autor takiego narzędzia.

> Dokładniej jest to wyjaśnione tutaj:
[link do sicp]

Rozumiem - czyli w Scheme zwiększa. Trudno, jest to problem języka Scheme. I autorów
narzędzi analizy tego języka.

Ale dlaczego to ma być zły nawyk w C++ (czy w jakimkolwiek języku imperatywnym, bo
problem jest ogólny), to nadal nie rozumiem.

> Pytasz o moje doświadczenia, to Ci mówię.

Ale jeśli Twoje doświadczenia to kiepski kod znaleziony w necie, to można mieć też
dobre doświadczenia.

> Jeżeli Cię nie interesują albo masz sobie z nich szydzić,
> to nie pytaj.

Pytam, bo zostawiasz swoje posty w stanie niedopowiedzenia ("C++ tworzy złe nawyki,
bo tak"). Potem ktoś to przeczyta i pomyśli, że tak faktycznie jest. Tymczasem, w
przypadku niedopowiedzeń, jest pole do dyskusji i chcę je pokazać.

> Nawyki nie są "cechą języka", tylko ludzi.

Tak. Np. większosć ludzi ma złe nawyki żywieniowe.
Ale to nie jest problem żywności.

> Języki mogą pomagać wykształcać w ludziach takie czy inne nawyki.

Tak. Przykładowo, Ada jest lepsza od C++ pod względem wykształcania nawyków. Nie
zmienia to faktu, że widziałem bardzo dobry kod w C++ i bardzo zły w Adzie.

> Więcej, wokół języków tworzą się kultury.

Tak. A w przypadku jezyków bardzo rozbudowanych i popularnych również subkultury. Coś
jak z żywieniem.
Pytanie teraz, czy trzeba zmienić język, czy wystarczy znaleźć lepszą subkulturę,
żeby podnieść poziom. Na to pytanie nie odpowiemy pisząc po prostu, że C++ wyrabia
złe nawyki.

> Artykuł, który podlinkowałem, to nie jest "po prostu randomowy
> kod który znalazłem gdzieś w necie": to jest kod, którym ktoś
> się podzielił, żeby inni mogli go czytać.

Czyli randomowy. Przecież w necie nie ma innych kodów, niż te, którymi ktoś się
podzielił, żeby inni mogli je czytać. Podobnie jest z filmami na YouTube.

> I to jest kod pełen
> anty-wzorców, których źródłem są właśnie złe nawyki.

Dobrze. To może lepiej pokazać dobre wzorce na dobrym kodzie?

> I, co znamienne, to jest kod,
> który nie jest nietypowy dla programistów C++. Powiedziałbym
> (na podstawie swoich doświadczeń), że jest bardzo typowy.

Nadal nie wiem, czy trzeba zmienić język, żeby pisać lepiej.

> Mogę też spróbować sformułować tę myśl inaczej:
> postaraj się odpowiedzieć na pytanie, dlaczego
> taki "zły kod" powstaje.

To jest bardzo cenne pytanie. Nie wiem, czy znam odpowiedź.
Może dlatego, że ludzie uczą się z przypadkowego kodu znalezionego w necie?
I akurat kodu w C++ jest na tyle dużo, że łatwo znaleźć ten kiepski?
Coś jak z filmami na YT.
Myślę, że pewnym czynnikiem jest też fakt, że nasz gatunek traci powoli zdolność
czytania książek, zadowalając się przypadkowym "contentem z netu". To zjawisko akurat
dotyczy nie tylko programowania.

Nadal nie wiemy, czy należy zmienić język, żeby pisać dobrze.
Albo, wracając do pierwszego pytania, czy C++ jest (nie)dobry do nauki.

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

do góry

> > Nawyki nie są "cechą języka", tylko ludzi.
>
> Tak. Np. większosć ludzi ma złe nawyki żywieniowe.
> Ale to nie jest problem żywności.

Cenna uwaga!

> > I to jest kod pełen
> > anty-wzorców, których źródłem są właśnie złe nawyki.
>
> Dobrze. To może lepiej pokazać dobre wzorce na dobrym kodzie?

Wzorce i antywzorce nie zależą od języka programowania! Podobnie jak wspomniane
nawyki.

> Nadal nie wiemy, czy należy zmienić język, żeby pisać dobrze.
> Albo, wracając do pierwszego pytania, czy C++ jest (nie)dobry do nauki.

Jest dobry:
+ jest prawdziwy (w nim się pisze wszelkie poważne systemy - nawet oprogramowanie do
F-35 napisano w C++ rzucając wcześniej stosowaną Adę np. w F-22 i Euro Fighter 2000)
+ jest kompatybilny (z najważniejszymi językami: Asemblerem i C, a do pozostałych
języków można w nim tworzyć rozszerzenia)
+ produkuje bardzo szybki, natywny kod (nie wymaga żadnej wirtualnej maszyny czy
interpretera)
+ jest dobrze rozwinięty i nadal rozwijany
+ jest dobrze zrozumiany i jest sprawdzony
+ jest wieloplatformowy (jeśli się użyje odpowiednich bibliotek: Stl, Boost, Sdl,
OpenGl czy Qt i jeśli się umiejętnie wydziela wywołania nieprzenośnych funkcji)
+ jest obiektowy
+ wspiera wielodziedziczenie
+ ma możliwość przeładowania operatorów
+ ma wsparcie dla metaprogramowania (szablony)
+ wspiera wyjątki (jako sposób obsługi błędów)
+ wspiera wiele stylów programowania i wiele paradygmatów programowania
+ darmowy
+ ma bardzo dobre BIBLIOTEKI DO WSZYSTKIEGO na liberalnych licencjach
+ jest przyjazny dla ucznia (można go poznawać stopniowo - w miarę potrzeb)
+ jest wiele podręczników (z Opus Magnum Jerzego Grębosza na czele)
+ jest standardem w konkursach dla programistów

Wady:
- koszmarne komunikaty linkera (Gnu g++)
- koszmarne komunikaty kompilatora gdy coś nie gra w użytych szablonach (Gnu g++)
- słaby debuger Gnu gdb lub jego interfejs w Qt Creator (w porównaniu do debugera
Borlanda w C++ Builder).
- ręczne zarządzanie pamięcią
- brak konsekwencji w stosowaniu nazewnictwa między bibliotekami (np. w Stl i Qt) (do
przeżycia)
- wybiórcze stosowanie funkcji języka (np. nie stosowanie wyjątków tylko wartości
zwracanych i nie standaryzowanych funkcji z opisem błędu np. w Qt)

do góry

W dniu piątek, 28 grudnia 2018 23:07:15 UTC+1 użytkownik Maciej Sobczak napisał:
> > Przykłady podałem w linku (i szczerze wątpię, żeby potomność
> > zechciała kiedykolwiek grzebać na tym śmietnisku).
>
> W linku był artykuł o kiepskim kodzie, który znalazłeś w necie. Krytyka języka z
tego żadna. Zwłaszcza w przypadku języka, który jest popularny a przez to używany
również przez tych, którzy uniwersalnie piszą kiepski kod.

Nic dziwnego, że "krytyka języka z tego żadna", bo to nie była
krytyka języka. Twoje pytanie, na ile je zrozumiałem, dotyczyło
złych nawyków.

> [operator przypisania]
>
> > W większości miejsc nie jest konieczne.
> > A jest to zły nawyk, ponieważ - mówiąc skrótowo - zwiększa złożoność
> > środków analizy programów
>
> Nie, nie zwiększa.

Owszem, zwiększa.

> Albo, jeśli faktycznie zwiększa, to jest to problem autorów takich narzędzi a nie
użytkowników języka. Jako użytkownik języka akceptuję ten układ. Ba - ja go nawet
akceptuję jako autor takiego narzędzia.

Otóż to właśnie jest problem użytkowników języka.
Proponuję, żebyś - zamiast zgadywać w ciemno o czym mówię
- spróbował przeczytać tę książkę, i dopiero wtedy się
wypowiedzieć.
To dobra książka, naprawdę. Może na początku wydawać się
"zbyt banalna", zwłaszcza dla kogoś, kto ma już doświadczenie
z programowaniem. Ale owo wrażenie szybko ustępuje.

> > Dokładniej jest to wyjaśnione tutaj:
> [link do sicp]
>
> Rozumiem - czyli w Scheme zwiększa. Trudno, jest to problem języka Scheme. I
autorów narzędzi analizy tego języka.

Jest to w takim samym stopniu "problem języka Scheme",
jak "problem języków" takich jak Erlang, Haskell, Java, C++,
Mathematica, Pascal i wielu innych.

> Ale dlaczego to ma być zły nawyk w C++ (czy w jakimkolwiek języku imperatywnym, bo
problem jest ogólny), to nadal nie rozumiem.

To przeczytaj książkę.

> > Pytasz o moje doświadczenia, to Ci mówię.
>
> Ale jeśli Twoje doświadczenia to kiepski kod znaleziony w necie, to można mieć też
dobre doświadczenia.

Moje doświadczenia są różne.
Swoją wiedzę o C++ czerpałem głównie z ksiązki Stroustrupa "Język C++"
oraz z książki Kernighana i Pike'a "Lekcja programowania".
Jeżeli idzie o inne źródła, z których się uczyłem, to opisałem to
kiedyś tutaj:
https://www.quora.com/What-is-something-you-wish-you
-knew-when-you-first-started-functional-programming/
answer/Panicz-Godek

> > Jeżeli Cię nie interesują albo masz sobie z nich szydzić,
> > to nie pytaj.
>
> Pytam, bo zostawiasz swoje posty w stanie niedopowiedzenia ("C++ tworzy złe nawyki,
bo tak"). Potem ktoś to przeczyta i pomyśli, że tak faktycznie jest. Tymczasem, w
przypadku niedopowiedzeń, jest pole do dyskusji i chcę je pokazać.

Nie napisałem że "C++ tworzy złe nawyki, bo tak". Napisałem
coś takiego:

"ja sam musiałem oduczać się różnych złych nawyków, których
nabrałem, ucząc się programowania poprzez takie języki
jak C czy C++"

Rzeczywiście, nie jest to super szczegółowo dopowiedziane,
ale jest tam wyraźnie powiedziane, że to JA nabrałem złych
nawyków, a nie że "C++ stworzył jakieś nawyki".

> > Nawyki nie są "cechą języka", tylko ludzi.
>
> Tak. Np. większosć ludzi ma złe nawyki żywieniowe.
> Ale to nie jest problem żywności.

Otyłość jest problemem w tzw. krajach rozwiniętych,
w których jest łatwy dostęp do słodyczy i śmieciowego
jedzenia. Jest to problem środowiskowy.

> > Języki mogą pomagać wykształcać w ludziach takie czy inne nawyki.
>
> Tak. Przykładowo, Ada jest lepsza od C++ pod względem wykształcania nawyków. Nie
zmienia to faktu, że widziałem bardzo dobry kod w C++ i bardzo zły w Adzie.

W porządku. W każdym języku można pisać kiepski kod.

> > Więcej, wokół języków tworzą się kultury.
>
> Tak. A w przypadku jezyków bardzo rozbudowanych i popularnych również subkultury.
Coś jak z żywieniem.
> Pytanie teraz, czy trzeba zmienić język, czy wystarczy znaleźć lepszą subkulturę,
żeby podnieść poziom. Na to pytanie nie odpowiemy pisząc po prostu, że C++ wyrabia
złe nawyki.

Zgoda.

> > Artykuł, który podlinkowałem, to nie jest "po prostu randomowy
> > kod który znalazłem gdzieś w necie": to jest kod, którym ktoś
> > się podzielił, żeby inni mogli go czytać.
>
> Czyli randomowy. Przecież w necie nie ma innych kodów, niż te, którymi ktoś się
podzielił, żeby inni mogli je czytać. Podobnie jest z filmami na YouTube.

Są też kody, którymi ktoś się podzielił, bo tego wymagała od niego
licencja. Albo kody, którymi ktoś się "podzielił", bo nie zabezpieczył
repozytorium. Albo kody, którymi ktoś się podzielił, bo serwis hostujący
jego backupy tego wymaga.

> > I to jest kod pełen
> > anty-wzorców, których źródłem są właśnie złe nawyki.
>
> Dobrze. To może lepiej pokazać dobre wzorce na dobrym kodzie?

Te również podałem.

> > I, co znamienne, to jest kod,
> > który nie jest nietypowy dla programistów C++. Powiedziałbym
> > (na podstawie swoich doświadczeń), że jest bardzo typowy.
>
> Nadal nie wiem, czy trzeba zmienić język, żeby pisać lepiej.

Też nie wiem. Ale jeżeli idzie o mnie, to nie umiem pisać
w C++ kodu tak, żeby być z niego zadowolonym.

> > Mogę też spróbować sformułować tę myśl inaczej:
> > postaraj się odpowiedzieć na pytanie, dlaczego
> > taki "zły kod" powstaje.
>
> To jest bardzo cenne pytanie. Nie wiem, czy znam odpowiedź.
> Może dlatego, że ludzie uczą się z przypadkowego kodu znalezionego w necie?
> I akurat kodu w C++ jest na tyle dużo, że łatwo znaleźć ten kiepski?
> Coś jak z filmami na YT.
> Myślę, że pewnym czynnikiem jest też fakt, że nasz gatunek traci powoli zdolność
czytania książek, zadowalając się przypadkowym "contentem z netu". To zjawisko akurat
dotyczy nie tylko programowania.
>
> Nadal nie wiemy, czy należy zmienić język, żeby pisać dobrze.
> Albo, wracając do pierwszego pytania, czy C++ jest (nie)dobry do nauki.

Wydaje mi się, że pytanie "czy C++ jest dobry do nauki"
to trochę mało. Raczej należałoby zapytać, czy dane materiały
dydaktyczne są dobre, albo czy określona metodologia nauczania
jest skuteczna.

do góry

W dniu sobota, 29 grudnia 2018 07:13:22 UTC+1 użytkownik s...@g...com napisał:

> > > I to jest kod pełen
> > > anty-wzorców, których źródłem są właśnie złe nawyki.
> >
> > Dobrze. To może lepiej pokazać dobre wzorce na dobrym kodzie?
>
> Wzorce i antywzorce nie zależą od języka programowania! Podobnie jak wspomniane
nawyki.

Pewne języki stawiają barierę na wyrażanie pewnych rzeczy, i coś,
co w jednych językach może być wyrażone (nazwane) bezpośrednio, w innych
musi pozostać "wzorcem".

> > Nadal nie wiemy, czy należy zmienić język, żeby pisać dobrze.
> > Albo, wracając do pierwszego pytania, czy C++ jest (nie)dobry do nauki.
>
> Jest dobry:
> + jest prawdziwy (w nim się pisze wszelkie poważne systemy - nawet oprogramowanie
do F-35 napisano w C++ rzucając wcześniej stosowaną Adę np. w F-22 i Euro Fighter
2000)

Nawet jeśli tak jest, niekoniecznie czyni to go dobrym do nauki.

> + jest kompatybilny (z najważniejszymi językami: Asemblerem i C, a do pozostałych
języków można w nim tworzyć rozszerzenia)

Prawie każdy używany współcześnie język umożliwia wywoływanie natywnych
funkcji

> + produkuje bardzo szybki, natywny kod (nie wymaga żadnej wirtualnej maszyny czy
interpretera)
> + jest dobrze rozwinięty i nadal rozwijany
> + jest dobrze zrozumiany i jest sprawdzony

Oto przykład na to, jak dobrze jest zrozumiany:
http://flyingfrogblog.blogspot.com/2013/10/herb-sutt
ers-favorite-c-10-liner.html

> + jest wieloplatformowy (jeśli się użyje odpowiednich bibliotek: Stl, Boost, Sdl,
OpenGl czy Qt i jeśli się umiejętnie wydziela wywołania nieprzenośnych funkcji)

Tzn. jest wieloplatformowy, jeśli na każdą platformę pisze się osobny kod?

> + jest obiektowy

A dlaczego to jest dobre?

> + wspiera wielodziedziczenie

A dlaczego to jest dobre?
I czy jesteś w stanie podać przykład jakiegoś problemu,
dla którego wielodziedziczenie byłoby dobrym (albo jedynym sensownym)
rozwiązaniem?

Robiłem ostatnio rozeznanie w temacie, i trafiłem na książkę
"Object Oriented Programming. An evolutionary approach", gdzie
jako przykład podano, że języki z wielodziedziczeniem pozwalają
reprezentować "zabawkową ciężarówkę" jednocześnie jako rodzaj
zabawki, jak i rodzaj ciężarówki.
Firmy logistyczne będą zachwycone.

> + ma możliwość przeładowania operatorów

A dlaczego to jest dobre?

> + ma wsparcie dla metaprogramowania (szablony)

C również ma "wsparcie dla metaprogramowania" (preprocesor).
Są języki, które mają naprawdę o wiele lepsze wsparcie dla
metaprogramowania (Lisp, OCaml, Haskell)

> + wspiera wyjątki (jako sposób obsługi błędów)

A dlaczego to jest dobre?

> + wspiera wiele stylów programowania i wiele paradygmatów programowania

Podobnie jak wiele innych języków.

> + darmowy

Podobnie jak wiele innych języków.

> + ma bardzo dobre BIBLIOTEKI DO WSZYSTKIEGO na liberalnych licencjach

Podobnie jak wiele innych języków.

> + jest przyjazny dla ucznia (można go poznawać stopniowo - w miarę potrzeb)

A znasz jakiś język, którego nie można poznawać stopniowo?

> + jest wiele podręczników (z Opus Magnum Jerzego Grębosza na czele)

Nie czytałem, to się nie wypowiem.
Ale "Język C++" Stroustrupa to w moim odczuciu naprawdę kiepska książka.
Zresztą nawet Scott Meyers, autor książek z serii "Effective C++",
już sobie odpuścił.
https://www.youtube.com/watch?v=KAWA1DuvCnQ&feature=
youtu.be

> + jest standardem w konkursach dla programistów

W jakich konkursach?
Wszystkie, z którymi ja miałem styczność, dawały uczestnikom dużą swobodę
w wyborze języka.

> Wady:
> - koszmarne komunikaty linkera (Gnu g++)
> - koszmarne komunikaty kompilatora gdy coś nie gra w użytych szablonach (Gnu g++)
> - słaby debuger Gnu gdb lub jego interfejs w Qt Creator (w porównaniu do debugera
Borlanda w C++ Builder).

To akurat nie brzmi jak wada C++, tylko jakiegoś tam narzędzia.

> - ręczne zarządzanie pamięcią

Jak to? A unique_ptr i shared_ptr? A BDW GC?

> - brak konsekwencji w stosowaniu nazewnictwa między bibliotekami (np. w Stl i Qt)
(do przeżycia)

Również brak konsekwencji w stosowaniu nazewnictwa w obrębie biblioteki
(STL, zob. prezentację Meyersa).

do góry

On Wed, 26 Dec 2018 15:58:56 -0800 (PST), g...@g...com wrote:

> https://www.quora.com/What-are-some-examples-of-bad-
code/answer/Panicz-Godek

A o co chodzi z tym paniczem, że tak na marginesie podpytam?

--
pozdrawiam
Roman Tyczka

do góry

W dniu 29.12.2018 o 12:51, g...@g...com pisze:
> Ale "Język C++" Stroustrupa to w moim odczuciu naprawdę kiepska książka.

Chodzi o "Język C++. Kompendium wiedzy" - Bjarne Stroustrup?
dlaczego?

Z języka C++ jestem zadowolony i można powiedzieć że ma jedną wadę:
strasznie wolno się kompiluje, gdy mam przebudować jakiś większy
projekt. Pojedyncze pliki C++ długo się kompilują, dlatego że z powodu
includów plik który może mieć 50 kB, w istocie ma 1 MB.
Z niecierpliwością czekam na moduły w C++.

do góry

> > Jest dobry:
> > + jest prawdziwy (w nim się pisze wszelkie poważne systemy - nawet oprogramowanie
do F-35 napisano w C++ rzucając wcześniej stosowaną Adę np. w F-22 i Euro Fighter
2000)
>
> Nawet jeśli tak jest, niekoniecznie czyni to go dobrym do nauki.

Ofszem jest: masz pewność, że nauczysz się czegoś co jest używane, działa i się
rozwija.

> > + jest kompatybilny (z najważniejszymi językami: Asemblerem i C, a do pozostałych
języków można w nim tworzyć rozszerzenia)
>
> Prawie każdy używany współcześnie język umożliwia wywoływanie natywnych
> funkcji

Tak są one pisane w C/C++. O tym właśnie wspominałem.

> > + produkuje bardzo szybki, natywny kod (nie wymaga żadnej wirtualnej maszyny czy
interpretera)
> > + jest dobrze rozwinięty i nadal rozwijany
> > + jest dobrze zrozumiany i jest sprawdzony
>
> Oto przykład na to, jak dobrze jest zrozumiany:
> http://flyingfrogblog.blogspot.com/2013/10/herb-sutt
ers-favorite-c-10-liner.html

Ja mam inną strategię: używam tego podzbioru języka jakiego jestem pewny. Nie gonię
jak idiota za wszystkimi nowościami. Skupiam się na działaniu moich programów i jak
coś jest bardzo przydatne to próbuję ostrożnie to wdrażać. np. for(klasa i :
kontener), albo lambdy, a zamiast konwertować sprytne wskaźniki po prostu używam
QSharedPtr - ale to i tak jest mało przydatne, bo biblioteka Qt nie opiera się na tym
tylko na surowych wskaźnikach.

> > + jest wieloplatformowy (jeśli się użyje odpowiednich bibliotek: Stl, Boost, Sdl,
OpenGl czy Qt i jeśli się umiejętnie wydziela wywołania nieprzenośnych funkcji)
>
> Tzn. jest wieloplatformowy, jeśli na każdą platformę pisze się osobny kod?

Widać, że słaby jesteś w te klocki, bo nie masz pojęcia jakie możliwości mają te
wymienione biblioteki. Ale jestem cierpliwy i miły, więc wyjaśnię: nie wszystkie
możliwe przypadki są przewidziane w bibliotece i wtedy też trzeba sobie poradzić i
C++ umożliwia wybrnięcie z tego co najmniej na 2 sposoby: #ifdef #else #endif lub
kompilacją warunkową (te drugie rozwiązanie jest dużo lepsze i ja je zalecam)

> > + jest obiektowy
>
> A dlaczego to jest dobre?

Bo to odbicie ludzkiego pojmowania świata: obiekty z określonymi funkcjami (w
moralności dostępne funkcje to stopnie swobody - im człowiek jest bardziej wolny to
ma więcej dostępnych obiektów i funkcji - czyli stopni swobody).

> > + wspiera wielodziedziczenie
>
> A dlaczego to jest dobre?
> I czy jesteś w stanie podać przykład jakiegoś problemu,
> dla którego wielodziedziczenie byłoby dobrym (albo jedynym sensownym)
> rozwiązaniem?

Ofszem! Od paru lat piszę kolejne wersje mojego edytora tekstu. Początkowo się
oparłem na własnej implementacji kolorowania składni, jednak odkryłem, że Kde
udostępnia odpowiednią bibliotekę z kolorowaniem ponad 200 języków. QPlainTextEdit ma
coś takiego jak bloki (które normalnie są pojedynczymi liniami) do bloku można
przypisać jeden obiekt dziedziczący po określonej klasie (co jest wadą tego
rozwiązania bo powinno być ich wiele). Problem w tym, że ten syntaxhighlighter z Kde
już używa tej zmiennej/obiekt. Dlatego ja chcąc zaimplementować zakładki muszę
wydziedziczyć po klasie z biblioteki Kde i po mojej klasie LineInfo. By to zadziałało
muszę do mojego edytora dodać callback który będzie tworzył te obiekty. Rozwiązanie
mam zakodowane i skompilowane, jednak problem z dynamicznie ładowanymi pluginami na
razie uniemożliwia mi uruchomienie programu. Jednak wcześniejsza wersja monolityczna
działała na tej samej zasadzie.

> Robiłem ostatnio rozeznanie w temacie, i trafiłem na książkę
> "Object Oriented Programming. An evolutionary approach", gdzie
> jako przykład podano, że języki z wielodziedziczeniem pozwalają
> reprezentować "zabawkową ciężarówkę" jednocześnie jako rodzaj
> zabawki, jak i rodzaj ciężarówki.
> Firmy logistyczne będą zachwycone.

Generalnie wielodziedziczenie umożliwia rzeczy nie możliwe do osiągnięcia w inny
sposób. Tak jak u mnie gdzie musiałem rozszerzyć istniejącą klasę by móc użyć
pojedynczej zmiennej w QPlainTextEdit - głowiłem się nad innym rozwiązaniem ale brak
pełnego dostępu do wnętrza tej klasy uniemożliwia inne podejście.

> > + ma możliwość przeładowania operatorów
>
> A dlaczego to jest dobre?

Np. by móc porównywać złożone typy. Albo by napisać zoptymalizowany menadżer pamięci
w aplikacji jednowątkowej (trochę to trąci myszką w dzisiejszych czasach...).

> > + ma wsparcie dla metaprogramowania (szablony)
>
> C również ma "wsparcie dla metaprogramowania" (preprocesor).
> Są języki, które mają naprawdę o wiele lepsze wsparcie dla
> metaprogramowania (Lisp, OCaml, Haskell)

Możliwe, tylko, że te języki nie istnieją dla pracodawców, ani nawet dla uczelni.

> > + wspiera wyjątki (jako sposób obsługi błędów)
>
> A dlaczego to jest dobre?

Bardziej naturalne podejście i duuużo bardziej niezawodne. Choć w aplikacjach
zdarzeniowych i wielowątkowych robi się upierdliwe, ale i tak jest to lepsze niż
sprawdzanie wartości zwracanej.

> > + wspiera wiele stylów programowania i wiele paradygmatów programowania
>
> Podobnie jak wiele innych języków.

Wiele, ale są też takie które dopuszczają wolność, ale nie w tak szerokim zakresie (w
połączeniu z innymi cechami).

> > + darmowy
>
> Podobnie jak wiele innych języków.

Tu chodziło mi raczej o podkreślenie, że nie generuje dodatkowych kosztów - wystarczą
chęci i samozaparcie.

> > + ma bardzo dobre BIBLIOTEKI DO WSZYSTKIEGO na liberalnych licencjach
>
> Podobnie jak wiele innych języków.

ŻADEN INNY JĘZYK NIE MA TYLE BIBLIOTEK (bo włączyć do repertuaru można biblioteki w
Asemblerze i C a w drugą stronę już słabo).

> > + jest przyjazny dla ucznia (można go poznawać stopniowo - w miarę potrzeb)
>
> A znasz jakiś język, którego nie można poznawać stopniowo?

Nie szukałem... Tą zaletę pamiętam z Symfonii C++ Jerzego Grębosza (chyba miał na
myśli to, że efekty szybko się pojawiają przy jego nauce).

> > + jest wiele podręczników (z Opus Magnum Jerzego Grębosza na czele)
>
> Nie czytałem, to się nie wypowiem.
> Ale "Język C++" Stroustrupa to w moim odczuciu naprawdę kiepska książka.

To bardziej wyrocznia w sprawach nie oczywistych i mało znanych. Jerzy Grębosz pisze
dużo bardziej zrozumiale (może to kwestia tego, że nie wymagało to tłumacza?!?).

> Zresztą nawet Scott Meyers, autor książek z serii "Effective C++",
> już sobie odpuścił.
> https://www.youtube.com/watch?v=KAWA1DuvCnQ&feature=
youtu.be

Nie mam czasu godzinę się męczyć wsłuchując się w monolog po angielsku... I w
zasadzie nie obchodzi mnie to, że woli pisać w D niż w C++. Ja wiem, że D jest do d*
i to nie dlatego, że ma braki składniowe tylko wsparcie jest marginalne (debuger,
środowisko programistyczne i społecznościowe, brak biblioteki graficznej, muzycznej,
profilera) - takimi językami można się podniecać w szkole średniej, ale (najpóźniej)
na studiach powinno przyjść otrzeźwienie - liczą się szczegóły dzięki którym można w
pełni osiągnąć cel a nie co chwila z czegoś rezygnować, bo się nie da... Podobna
uwaga tyczy się wynalazków typu Raspberry - np. teraz nie można skompilować Qt 5.12
na Amd64 kroskompilując na Arm32 bo Raspberry nie zaktualizowało kros kompilatora od
4 lat...

do góry

W dniu sobota, 29 grudnia 2018 14:01:33 UTC+1 użytkownik Borneq napisał:

> > Ale "Język C++" Stroustrupa to w moim odczuciu naprawdę kiepska książka.
>
> Chodzi o "Język C++. Kompendium wiedzy" - Bjarne Stroustrup?

Ta, z której korzystałem, była wydana przez WNT w serii
"Klasyka Informatyki". Z tego co patrzę na stronie Helionu,
ta o której Ty mówisz, jest rozszerzona o C++11, więc to
pewnie zupełnie inny język, i podejrzewam, że w dużym
stopniu inna książka. (Na pewno też inne tłumaczenie)

> dlaczego?

Mówiąc skrótowo, dlatego, że książka nie dotykała prawdziwych
problemów, tylko omawiała "ficzery języka", pod które dopasowywane
były problemy.

Chwaliłem się kiedyś tutaj stosowaniem "algorytmu" std::for_each
zdefiniowanego w nagłówku <algorithm>.

Stroustrup namawiał otóż właśnie do robienia tego rodzaju
rzeczy.

do góry