🚀 go-pugleaf

wtorek, 17 listopada 2020 o 20:45:52 UTC+1 jawors...@adres.pl napisał(a):
> Cześć! 
> 
> Dodanie wielu nowych koncepcji. Doprecyzowanie wcześniejszych myśli. Udoskonalenie układu całego dokumentu (pogrupowanie akapitów w logiczne grupy). 
> 
> https://gitlab.com/energokoder/sztuka-kodowania 
> 
> Zapraszam do lektury i dyskusji! 
> Energo koder

No to od początku.

"Nie jestem zdania, że: „Miliardy much nie mogą się mylić”, jednak:
Fakty są takie, że „wszyscy wielcy” w programowaniu kodują w C++."

"Wszyscy wielcy", czyli kto?

Bo wśród "słynnych programistów", których kojarzę, to
albo mają do C++ stosunek raczej neutralny (np. John Carmack,
który wszystkie Quake engine'y pisał w C), albo go otwarcie
hejtują (np. Linus Torvalds, Ken Thompson)

poniedziałek, 23 listopada 2020 o 09:28:43 UTC+1 Maciek Godek napisał(a):
> wtorek, 17 listopada 2020 o 20:45:52 UTC+1 jawors...@adres.pl napisał(a): 
> > Cześć! 
> > 
> > Dodanie wielu nowych koncepcji. Doprecyzowanie wcześniejszych myśli. Udoskonalenie układu całego dokumentu (pogrupowanie akapitów w logiczne grupy). 
> > 
> > https://gitlab.com/energokoder/sztuka-kodowania 
> > 
> > Zapraszam do lektury i dyskusji! 
> > Energo koder
> No to od początku. 

A teraz od końca:

"13 Dodatek 1: Czy uczyć się innych języków niż C++?
13.1 Generalnie odpowiedź brzmi: NIE!!!
Wynika to z faktu, że sam język jest jedynie narzędziem w jakim wykonuje się rozwiązanie (program)."

Ja bym powiedział, że zdecydowanie warto uczyć się języków
(i że jak ktoś twierdzi, że jest "jeden słuszny język", to po prostu
 promuje "kibolskie" nastawienie do programowania).

Język też nie jest "narzędziem w jakim wykonuje się program".
To komputer jest narzędziem, które wykonuje programy.

Na komputerze zaś instaluje się narzędzia, które pozwalają
przekonwertować programy wyrażone w języku zrozumiałym
dla człowieka do postaci, która pozwala komputerowi wykonywać
je w wydajny sposób. W każdym razie "język" nie "wykonuje programu",
tylko "pozwala wyrazić rozwiązanie problemu".

I czy Tobie się to podoba, czy nie, języków programowania zawsze
będzie dużo, i zawsze będą takie, których warto się uczyć.

(A moim zdaniem C++ jest akurat jednym z gorszych)

poniedziałek, 23 listopada 2020 o 10:47:11 UTC+1 heby napisał(a):
> On 23/11/2020 10:26, Maciek Godek wrote: 
> > (A moim zdaniem C++ jest akurat jednym z gorszych)
> Doceniam potrzebę zrobienia flame, ale jestem troche senny, tak że pass, 
> sorry.

Nie bardzo rozumiem sens Twojego posta. Nie odpowiada Ci, że moje zdanie jest odmienne od Twojego?
Czy chcesz się po prostu pochwalić, że nie masz nic do powiedzenia?

Jakiś czas temu natrafiłem na konto na twitterze, 
na którym są prezentowane "cute C++ tricks of the day":

https://twitter.com/The_Whole_Daisy

Jak ktoś jest fanem C++, to może mu się spodobać.
Ja jak widzę takie rzeczy to zbiera mi się na wymioty.

On 23/11/2020 10:26, Maciek Godek wrote:
> (A moim zdaniem C++ jest akurat jednym z gorszych)

Doceniam potrzebę zrobienia flame, ale jestem troche senny, tak że pass,
sorry.

poniedziałek, 23 listopada 2020 o 23:52:39 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup 
> dyskusyjnych:260447d4-3f4a-469f...@googlegroups.com...
> wtorek, 17 listopada 2020 o 20:45:52 UTC+1 jawors...@adres.pl napisał(a): 
> 
> >"Wszyscy wielcy", czyli kto? 
> 
> >Bo wśród "słynnych programistów", których kojarzę, to 
> >albo mają do C++ stosunek raczej neutralny (np. John Carmack, 
> >który wszystkie Quake engine'y pisał w C), albo go otwarcie 
> >hejtują (np. Linus Torvalds, Ken Thompson)
> A w czym oni wielcy?

To jest ogólnie dobre pytanie.

Ja bym powiedział, że Thompson dlatego, że stworzył UNIXa.
Carmack tworzył w swoim czasie przełomowe technologie, od grafiki 3d po statki kosmiczne.
Torvalds nie wiem, że wyznaczył nowe standardy pracy nad oprogramowaniem (choć to bardziej rewolucja kulturowa, niż technologiczna, ale udało się mu jej dokonać dwukrotnie).

Ale jak nie oni, to kto?

Użytkownik "Maciek Godek"  napisał w wiadomości grup
dyskusyjnych:260447d4-3f4a-469f-855a-21349679cc68n@googlegroups.com...

wtorek, 17 listopada 2020 o 20:45:52 UTC+1 jawors...@adres.pl napisał(a):

>"Wszyscy wielcy", czyli kto?

>Bo wśród "słynnych programistów", których kojarzę, to
>albo mają do C++ stosunek raczej neutralny (np. John Carmack,
>który wszystkie Quake engine'y pisał w C), albo go otwarcie
>hejtują (np. Linus Torvalds, Ken Thompson)

A w czym oni wielcy?

wtorek, 24 listopada 2020 o 06:46:41 UTC+1 Ghost napisał(a):

> >Ale jak nie oni, to kto?
> Wydalaloby mi sie, ze wypadaloby raczej szukac ludzi majcych udokumentowane 
> sukcesy w analizie oprogramowania etc. nizli kolesi ktorym udalo sie po 
> prostu wyplynac na rynku/spolecznosci z roznych wzgledow.

Ale masz jakieś przykłady?

Użytkownik "Maciek Godek"  napisał w wiadomości grup
dyskusyjnych:d0a75e60-4c6c-423a-b9c4-35617b6e9175n@googlegroups.com...

poniedziałek, 23 listopada 2020 o 23:52:39 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup
> dyskusyjnych:260447d4-3f4a-469f...@googlegroups.com...
> wtorek, 17 listopada 2020 o 20:45:52 UTC+1 jawors...@adres.pl napisał(a):
>
>> >"Wszyscy wielcy", czyli kto?
>
>> >Bo wśród "słynnych programistów", których kojarzę, to
>> >albo mają do C++ stosunek raczej neutralny (np. John Carmack,
>> >który wszystkie Quake engine'y pisał w C), albo go otwarcie
>> >hejtują (np. Linus Torvalds, Ken Thompson)
>> A w czym oni wielcy?

>To jest ogólnie dobre pytanie.

>Ja bym powiedział, że Thompson dlatego, że stworzył UNIXa.
>Carmack tworzył w swoim czasie przełomowe technologie, od grafiki 3d po
>statki kosmiczne.
>Torvalds nie wiem, że wyznaczył nowe standardy pracy nad oprogramowaniem
>(choć to bardziej rewolucja kulturowa, niż technologiczna, ale udało się mu
>jej dokonać dwukrotnie).

>Ale jak nie oni, to kto?

Wydalaloby mi sie, ze wypadaloby raczej szukac ludzi majcych udokumentowane
sukcesy w analizie oprogramowania etc. nizli kolesi ktorym udalo sie po
prostu wyplynac na rynku/spolecznosci z roznych wzgledow.

wtorek, 24 listopada 2020 o 16:08:21 UTC+1 Ghost napisał(a):

> >Ale masz jakieś przykłady?
> Nie. Wiec poki co trzymam sie wlasnej opinii.

Sądzę, że każdy trzyma się swojej opinii.
Nie zmienia to jednak tego, że OP stwierdził, że
"Fakty są takie, że „wszyscy wielcy” w programowaniu kodują w C++"
i dlatego interesuje mnie, jacy "wielcy w programowaniu kodują w C++".
Może chodziło mu o "wielkie korporacje", jak Microsoft czy Adobe czy Apple.
Ale nie wiem, dlaczego to miałby być dla mnie jakiś wyznacznik.

Użytkownik "Maciek Godek"  napisał w wiadomości grup
dyskusyjnych:98a54638-6152-4a80-a372-f820e61f4491n@googlegroups.com...

wtorek, 24 listopada 2020 o 06:46:41 UTC+1 Ghost napisał(a):

>> >Ale jak nie oni, to kto?

>> Wydalaloby mi sie, ze wypadaloby raczej szukac ludzi majcych
>> udokumentowane
>> sukcesy w analizie oprogramowania etc. nizli kolesi ktorym udalo sie po
>> prostu wyplynac na rynku/spolecznosci z roznych wzgledow.

>Ale masz jakieś przykłady?

Nie. Wiec poki co trzymam sie wlasnej opinii.

środa, 25 listopada 2020 o 15:17:50 UTC+1 Arnold Ziffel napisał(a):
> Maciek Godek <godek....@gmail.com> wrote: 
> 
> > Sądzę, że każdy trzyma się swojej opinii.
> Tylko idioci. 
> 
> Człowiek rozsądny, w obliczu faktów przeczących jego opinii, zmieni 
> opinię. Idiota stwierdzi, że to tym gorzej dla faktów. 

W mojej opinii wszyscy ludzie to idioci, i jakoś jeszcze nie spotkałem się z faktem, który zdołałby tę opinię podważyć ;]

A tak serio: jasne, ludziom zdarza się zmienić opinię.
Ale podobno pewne eksperymenty z psychologii społecznej pokazują, że są takie obszary, w których - jeśli przedstawi się nam fakty przeczące naszym przekonaniom, to zamiast osłabiać te przekonania, owe sprzeczne fakty wydają się je wzmacniać.

Była swego czasu bardzo dobra prezentacja na ten temat, i kiedyś chyba się nią tu nawet dzieliłem.

Dan Saks, "extern c: Talking to C programmers about C++"
https://www.youtube.com/watch?v=D7Sd8A6_fYU

Wracając do tematu:

> https://gitlab.com/energokoder/sztuka-kodowania 

Takie 2 pyt.:
1. Czy podzielacie opinię osób z 4programmers.net, że przedstawiam zalecenia słabo uargumentowane i mocno podszyte emocjami?
2. Czy znacie lepszy język programowania od C++? Lepszy ale: kompilowany, wieloplatformowy (Linux, Android, WinDos), obiektowy z wielodziedziczeniem i z sensowną biblioteką standardową?
Sensowna biblioteka standardowa powinna mieć obsługę: napisów, wątków, sieci i grafy.

Te 2 sprawy są dla mnie kluczowe, bo:
ad 1.: Jeśli tak, to postaram się rozwinąć moje myśli. Operowałem trochę skrótami w myśl zasady: "Mądrej głowie dość w dwie słowie.".
ad 2.: Jak jest taki język to może się go nauczę.

> Sensowna biblioteka standardowa powinna mieć obsługę: napisów, wątków, sieci i grafy. 

oraz baz danych...

Maciek Godek <godek.maciek@gmail.com> wrote:

> S±dzê, ¿e ka¿dy trzyma siê swojej opinii.

Tylko idioci.

Cz³owiek rozs±dny, w obliczu faktów przecz±cych jego opinii, zmieni
opiniê. Idiota stwierdzi, ¿e to tym gorzej dla faktów.

--
Pacjent mówi do lekarza:
- Ugryz³ mnie pies.
Lekarz odpowiada.
- Gdzie?
- Na rogu, ko³o szko³y.

środa, 25 listopada 2020 o 20:50:32 UTC+1 jawors...@adres.pl napisał(a):
> Wracając do tematu: 
> 
> > https://gitlab.com/energokoder/sztuka-kodowania 
> 
> Takie 2 pyt.: 
> 1. Czy podzielacie opinię osób z 4programmers.net, że przedstawiam zalecenia słabo uargumentowane i mocno podszyte emocjami? 

Nie przeglądałem dogłębnie, ale dla mnie to wygląda bardziej jak cienka zajawkowa broszurka, niż poważny tekst.

Kiedyś napisałem na Quorze taką odpowiedź:

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

Prezentuje źle napisany kod (akurat w C++), i pomysły, jak go poprawić.
Sądzę, że poważna literatura programistyczna powinna zajmować się rzeczywistym kodem, a nie ogólnikowymi wytycznymi, które przez różne osoby mogą być różnorako interpretowane.

(Wydaje mi się, że w dziedzinie "zasad używania C++" dobrym autorem jest Scott Meyers)

> 2. Czy znacie lepszy język programowania od C++? 
Pytanie sprawia wrażenie "szczenięcego".
Lepszy do czego?
Do pisania sterowników dla Linuxa? C.
Do obliczeń symbolicznych? Lisp.
Do oskryptowywania stron internetowych? JavaScript.
Do tworzenia aplikacji webowych? Na przykład F#, ClojureScript.

Jakiś czas temu chciałem skorzystać z Bluetooth na Windowsie. Okazało się, że jest to możliwe tylko z poziomu czegoś, co się nazywa Universal Windows Platform. Można na to pisać w C# albo w C++. Wybrałem C++, ale dość szybko okazało się, że to był zły wybór, bo wsparcie dla C# było zrobione lepiej, a zysku z korzystania z C++ nie było wcale.

> Lepszy ale: kompilowany, wieloplatformowy (Linux, Android, WinDos), obiektowy z wielodziedziczeniem i z sensowną biblioteką standardową? 
> Sensowna biblioteka standardowa powinna mieć obsługę: napisów, wątków, sieci i grafy. 

Praktycznie każdy poważny język daje Ci dostęp do tzw. FFI, czyli Foreign Function Interface. Czyli możesz wołać kod z dllek w każdym "dużym" języku.
Dlaczego komuś miałoby zależeć na wielodziedziczeniu, tego nie jestem w stanie pojąć.
Tutaj swego czasu widziałem dobrą krytykę:

https://www.quora.com/Is-inheritance-bad-practice-in-OOP-Many-places-that-teach-design-patterns-say-to-opt-for-composition-over-inheritance-but-what-about-when-multiple-classes-share-logic-from-an-abstract-class-such-as-in-the-Template-Method-design-pattern/answer/Curtis-Poe

Jeżeli zależy Ci na obiektowości i statycznych systemach typów, to może OCaml jest takim językiem (jeżeli chcesz uniknąć korzystania z maszyn wirtualnych), albo F#, albo Scala (jeżeli nie chcesz tego robić).

> Te 2 sprawy są dla mnie kluczowe, bo: 
> ad 1.: Jeśli tak, to postaram się rozwinąć moje myśli. Operowałem trochę skrótami w myśl zasady: "Mądrej głowie dość w dwie słowie.". 

A ja bym raczej powiedział, że nie zdefiniowałeś sobie, dla kogo ma być ten tekst przeznaczony.

> ad 2.: Jak jest taki język to może się go nauczę.

Jeżeli chcesz wydawać kategoryczne osądy o tym, że ten-a-ten język jest najlepszym językiem programowania znając tylko ten jeden język programowania, to sorry, ale Twój osąd będzie mało wiarygodny.

Jeżeli na poważnie wnikniesz w przynajmniej te główne kluczowe języki dla swoich paradygmatów (Lisp, Prolog, Smalltalk, APL/J/K, Erlang/Elixir, Forth/Joy) i będziesz przynajmniej w stanie napisać kompilator dla używanego przez siebie języka, to wtedy będziemy mogli zacząć rozmowę.

W dniu 25-11-2020 o 20:50, Jacek Jaworski pisze:
> Wracając do tematu:
>
>> https://gitlab.com/energokoder/sztuka-kodowania
>
> Takie 2 pyt.:
> 1. Czy podzielacie opinię osób z 4programmers.net, że przedstawiam zalecenia słabo uargumentowane i mocno podszyte emocjami?

Raczej widziałem tam rozsądne podpowiedzi i uwagi, ale cóż niektórych
nie przekonasz, że białe jest białe, a czarne jest czarne

--
http://kaczus.ppa.pl

niedziela, 29 listopada 2020 o 13:34:04 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup
> dyskusyjnych:8a19af2f-f829-4980...@googlegroups.com...
> środa, 25 listopada 2020 o 15:17:50 UTC+1 Arnold Ziffel napisał(a): 
> > Maciek Godek <godek....@gmail.com> wrote: 
> > 
> >> > Sądzę, że każdy trzyma się swojej opinii. 
> >> Tylko idioci. 
> > 
> >> Człowiek rozsądny, w obliczu faktów przeczących jego opinii, zmieni 
> >> opinię. Idiota stwierdzi, że to tym gorzej dla faktów. 
> 
> >W mojej opinii wszyscy ludzie to idioci, i jakoś jeszcze nie spotkałem się 
> >z faktem, który zdołałby tę opinię podważyć ;]
> Kwestia definicji idioty.

Raczej nie.
Dla starożytnych słowo "idiota" reczywiście oznaczało tyle, co "człowiek, który zajmuje się tylko swoimi własnymi (idios) sprawami i nie poświęca czasu na uczestnictwo w życiu publicznym".

Ale współcześnie słowo "idiota" to po prostu zwykła inwektywa, mająca na celu podkreślenie pogardliwego stosunku osoby, która używa tego określenia wobec tego, do kogo to określenie stosuje. Raczej nie ma tu co dzielić włosa na czworo.

U¿ytkownik "Arnold Ziffel"  napisa³ w wiadomo¶ci grup
dyskusyjnych:445b019a-d727-45f9-994f-6474d3ec0094@hooterville.invalid...

Maciek Godek <godek.maciek@gmail.com> wrote:

>> S±dzê, ¿e ka¿dy trzyma siê swojej opinii.

>Tylko idioci.

Tylko idiota robi wbrew wlasnemu przekonaniu.

>Cz³owiek rozs±dny, w obliczu faktów przecz±cych jego opinii, zmieni
>opiniê.

I nadal trzyma sie swojej opinii. Tej nowej.

>Idiota stwierdzi, ¿e to tym gorzej dla faktów.

A to zupelnie niezalezna kwestia.

Użytkownik "Maciek Godek"  napisał w wiadomości grup
dyskusyjnych:8a19af2f-f829-4980-9770-8c05e693ae8bn@googlegroups.com...

środa, 25 listopada 2020 o 15:17:50 UTC+1 Arnold Ziffel napisał(a):
> Maciek Godek <godek....@gmail.com> wrote:
>
>> > Sądzę, że każdy trzyma się swojej opinii.
>> Tylko idioci.
>
>> Człowiek rozsądny, w obliczu faktów przeczących jego opinii, zmieni
>> opinię. Idiota stwierdzi, że to tym gorzej dla faktów.

>W mojej opinii wszyscy ludzie to idioci, i jakoś jeszcze nie spotkałem się
>z faktem, który zdołałby tę opinię podważyć ;]

Kwestia definicji idioty.

>A tak serio: jasne, ludziom zdarza się zmienić opinię.
>Ale podobno pewne eksperymenty z psychologii społecznej pokazują, że są
>takie obszary, w których - jeśli przedstawi się nam fakty przeczące naszym
>przekonaniom, to zamiast osłabiać te przekonania, owe sprzeczne fakty
>wydają się je wzmacniać.

To jest cala kupa bledow poznawczych. Nie wynikaja z idiotyzmu, a raczej z
ewolucji i "rozsadnego" gospodarowania zasobami.

poniedziałek, 30 listopada 2020 o 06:35:03 UTC+1 Ghost napisał(a):

> >> Kwestia definicji idioty. 
> 
> >Raczej nie.
> Absolutnie tak.
> >Ale współcześnie słowo "idiota" to po prostu zwykła inwektywa, mająca na 
> >celu podkreślenie pogardliwego stosunku osoby, która używa tego określenia 
> >wobec tego, do kogo to określenie stosuje.
> No wiec, Ty to widziesz inaczej niz ja i spora czesc reszty ludnosci.

W takim razie nie mogę nie zapytać: jak Ty to widzisz?

poniedziałek, 30 listopada 2020 o 08:23:31 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup
> dyskusyjnych:c7af5423-49fd-472b...@googlegroups.com...
> poniedziałek, 30 listopada 2020 o 06:35:03 UTC+1 Ghost napisał(a): 
> 
> >> >> Kwestia definicji idioty. 
> > 
> >> >Raczej nie. 
> >> Absolutnie tak. 
> >> >Ale współcześnie słowo "idiota" to po prostu zwykła inwektywa, mająca na 
> >> >celu podkreślenie pogardliwego stosunku osoby, która używa tego 
> >> >określenia 
> >> >wobec tego, do kogo to określenie stosuje. 
> >> No wiec, Ty to widziesz inaczej niz ja i spora czesc reszty ludnosci. 
> 
> >W takim razie nie mogę nie zapytać: jak Ty to widzisz?
> Idiota to człowiek z pewnymi niedomaganiami intelektualnymi.

No, to z tej definicji wynika niestety to, co napisałem wcześniej: że wszyscy ludzie to idioci

poniedziałek, 30 listopada 2020 o 09:56:53 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup
> dyskusyjnych:b3dd3fc2-96ea-4127...@googlegroups.com...
> poniedziałek, 30 listopada 2020 o 08:23:31 UTC+1 Ghost napisał(a): 
> > Użytkownik "Maciek Godek" napisał w wiadomości grup 
> > dyskusyjnych:c7af5423-49fd-472b...@googlegroups.com... 
> > poniedziałek, 30 listopada 2020 o 06:35:03 UTC+1 Ghost napisał(a): 
> > 
> >> >> >> Kwestia definicji idioty. 
> > > 
> >> >> >Raczej nie. 
> >> >> Absolutnie tak. 
> >> >> >Ale współcześnie słowo "idiota" to po prostu zwykła inwektywa, mająca 
> >> >> >na 
> >> >> >celu podkreślenie pogardliwego stosunku osoby, która używa tego 
> >> >> >określenia 
> >> >> >wobec tego, do kogo to określenie stosuje. 
> >> >> No wiec, Ty to widziesz inaczej niz ja i spora czesc reszty ludnosci. 
> > 
> >> >W takim razie nie mogę nie zapytać: jak Ty to widzisz? 
> >> Idiota to człowiek z pewnymi niedomaganiami intelektualnymi. 
> 
> >No, to z tej definicji wynika niestety to, co napisałem wcześniej: że 
> >wszyscy ludzie to idioci
> Bo?

Bo każdy ma pewne niedomagania intelektualne.

Użytkownik "Maciek Godek"  napisał w wiadomości grup
dyskusyjnych:e11100b4-ba1d-4957-82cd-0446afadeb74n@googlegroups.com...

niedziela, 29 listopada 2020 o 13:34:04 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup
> dyskusyjnych:8a19af2f-f829-4980...@googlegroups.com...
> środa, 25 listopada 2020 o 15:17:50 UTC+1 Arnold Ziffel napisał(a):
> > Maciek Godek <godek....@gmail.com> wrote:
> >
>> >> > Sądzę, że każdy trzyma się swojej opinii.
>> >> Tylko idioci.
> >
>> >> Człowiek rozsądny, w obliczu faktów przeczących jego opinii, zmieni
>> >> opinię. Idiota stwierdzi, że to tym gorzej dla faktów.
>
>> >W mojej opinii wszyscy ludzie to idioci, i jakoś jeszcze nie spotkałem
>> >się
>> >z faktem, który zdołałby tę opinię podważyć ;]
>> Kwestia definicji idioty.

>Raczej nie.

Absolutnie tak.

>Ale współcześnie słowo "idiota" to po prostu zwykła inwektywa, mająca na
>celu podkreślenie pogardliwego stosunku osoby, która używa tego określenia
>wobec tego, do kogo to określenie stosuje.

No wiec, Ty to widziesz inaczej niz ja i spora czesc reszty ludnosci.

Użytkownik "Maciek Godek"  napisał w wiadomości grup
dyskusyjnych:c7af5423-49fd-472b-baad-3ad11f5f543an@googlegroups.com...

poniedziałek, 30 listopada 2020 o 06:35:03 UTC+1 Ghost napisał(a):

>> >> Kwestia definicji idioty.
>
>> >Raczej nie.
>> Absolutnie tak.
>> >Ale współcześnie słowo "idiota" to po prostu zwykła inwektywa, mająca na
>> >celu podkreślenie pogardliwego stosunku osoby, która używa tego
>> >określenia
>> >wobec tego, do kogo to określenie stosuje.
>> No wiec, Ty to widziesz inaczej niz ja i spora czesc reszty ludnosci.

>W takim razie nie mogę nie zapytać: jak Ty to widzisz?

Idiota to człowiek z pewnymi niedomaganiami intelektualnymi.

Użytkownik "Maciek Godek"  napisał w wiadomości grup
dyskusyjnych:b3dd3fc2-96ea-4127-b8d0-7a644b44309fn@googlegroups.com...

poniedziałek, 30 listopada 2020 o 08:23:31 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup
> dyskusyjnych:c7af5423-49fd-472b...@googlegroups.com...
> poniedziałek, 30 listopada 2020 o 06:35:03 UTC+1 Ghost napisał(a):
>
>> >> >> Kwestia definicji idioty.
> >
>> >> >Raczej nie.
>> >> Absolutnie tak.
>> >> >Ale współcześnie słowo "idiota" to po prostu zwykła inwektywa, mająca
>> >> >na
>> >> >celu podkreślenie pogardliwego stosunku osoby, która używa tego
>> >> >określenia
>> >> >wobec tego, do kogo to określenie stosuje.
>> >> No wiec, Ty to widziesz inaczej niz ja i spora czesc reszty ludnosci.
>
>> >W takim razie nie mogę nie zapytać: jak Ty to widzisz?
>> Idiota to człowiek z pewnymi niedomaganiami intelektualnymi.

>No, to z tej definicji wynika niestety to, co napisałem wcześniej: że
>wszyscy ludzie to idioci

Bo?

wtorek, 1 grudnia 2020 o 00:59:57 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup
> dyskusyjnych:f832fa0c-fa5a-4a0d...@googlegroups.com...
> poniedziałek, 30 listopada 2020 o 09:56:53 UTC+1 Ghost napisał(a): 
> > Użytkownik "Maciek Godek" napisał w wiadomości grup
> >> >> Idiota to człowiek z pewnymi niedomaganiami intelektualnymi. 
> > 
> >> >No, to z tej definicji wynika niestety to, co napisałem wcześniej: że 
> >> >wszyscy ludzie to idioci 
> 
> >> Bo? 
> 
> >Bo każdy ma pewne niedomagania intelektualne.
> Smiala teza. 

Nieszczególnie. Sądzę, że człowiek z definicji jest istotą skończoną.
'Niedomaganie' to tylko kwestia wyboru punktu odniesienia.

> Poza tym, nie napisalem, ze kazde, a pewne.

Napisałeś co napisałeś. Język jest wieloznaczny.
Dwie możliwe interpretacje samych kwantyfikatorów:
1. 'idiota to człowiek, który ma jakiekolwiek niedomagania intelektualne'
2. 'idiota to człowiek, który ma pewne konkretne niedomagania intelektualne'

Wybrałem interpretację 1, bo interpretacja 2 pociągałaby za sobą konieczność dookreślenia
o jakie niedomagania chodzi, a wcześniej pisałeś o 'sporej części reszty ludności'.
Nie sądzę, że gdybyś przepytał ową ludność, to uzyskałbyś odpowiedź zbieżną z tym,
co sam byś powiedział. (Pewnie 'Arnold Ziffel' by powiedział, że 'idiota to ktoś, kto nie zmienia
opinii w obliczu faktów'. Z tą definicją też są problemy, bo pewnie z jednej strony dla każdego
człowieka można znaleźć taki zbiór jego opinii, dla której będą istniały fakty, które te opinie
zmienią, oraz inny zbiór opinii, których żadne fakty nie zdołają zmienić)

Zresztą gdyby ten zbiór niedomagań był istotny, podałbyś od razu konkretną listę, bo zasadniczo
do tego służą definicje.


Inna rzecz, czy to, o czym teraz rozmawiamy, ma w ogóle jakąś wartość.
Dla mnie to raczej dygresja od dygresji.
Ja tam bym wolał rozmawiać o programowaniu, niechby i nawet o tym 'bryku' 'Energo Kodera'.
Albo o tej prezentacji, do której podlinkowałem.

Użytkownik "Maciek Godek"  napisał w wiadomości grup
dyskusyjnych:f832fa0c-fa5a-4a0d-9e2f-71aff9c82297n@googlegroups.com...

poniedziałek, 30 listopada 2020 o 09:56:53 UTC+1 Ghost napisał(a):
> Użytkownik "Maciek Godek" napisał w wiadomości grup

>> >> Idiota to człowiek z pewnymi niedomaganiami intelektualnymi.
>
>> >No, to z tej definicji wynika niestety to, co napisałem wcześniej: że
>> >wszyscy ludzie to idioci

>> Bo?

>Bo każdy ma pewne niedomagania intelektualne.

Smiala teza. Poza tym, nie napisalem, ze kazde, a pewne.

On Tuesday, November 17, 2020 at 8:45:52 PM UTC+1, jawors...@adres.pl wrote:
> Cześć! 
> 
> Dodanie wielu nowych koncepcji. Doprecyzowanie wcześniejszych myśli. Udoskonalenie układu całego dokumentu (pogrupowanie akapitów w logiczne grupy). 
> 
> https://gitlab.com/energokoder/sztuka-kodowania 

Przede wszystkim dystrybuowanie tego w formacie .odt to słaby pomysł. Rozważ przejście np. na markdown, który jest elegancko renderowany na gitlabie. Nie mówiąc, że masz wtedy sensowne zarządzanie wersjami swojego tekstu. Popracuj nad błędami językowymi też, pisownia łączna kuleje.

Co do koncepcji, to w ogółach masz rację i zasadniczo promujesz dość przyzwoite zasady, a do szczegółów zawsze można się doczepić (ja np. nie przepuszczam na review "using namespace" będące na poziomie jednostki kompilacji, bo to utrudnia zrozumienie kodu). Nadużywasz słów "zawsze" i "nigdy".

Razi styl C++ fanboja, przekręcanie nazw języków itp. Mało to profesjonalne i nie zachęca do poważnego potratowania.

w.

niedziela, 6 grudnia 2020 o 21:37:36 UTC+1 Wojciech Muła napisał(a):
> On Tuesday, November 17, 2020 at 8:45:52 PM UTC+1, jawors...@adres.pl wrote: 
> > Cześć! 
> > 
> > Dodanie wielu nowych koncepcji. Doprecyzowanie wcześniejszych myśli. Udoskonalenie układu całego dokumentu (pogrupowanie akapitów w logiczne grupy). 
> > 
> > https://gitlab.com/energokoder/sztuka-kodowania 
> 
> Przede wszystkim dystrybuowanie tego w formacie .odt to słaby pomysł. Rozważ przejście np. na markdown, który jest elegancko renderowany na gitlabie. Nie mówiąc, że masz wtedy sensowne zarządzanie wersjami swojego tekstu.

 W pełni świadomie nie używam zbyt często "markdown". Wynika to z faktu, że Libre Office nadaje się do składu dokumentów i go opanowałem zadowalająco. Jednak głównym powodem by nie używać md jest fakt fatalnej symboliki w Polsce: markdown tłumaczy się na "ma dałn", co jest analogią do "ma dałna".

> Popracuj nad błędami językowymi też, pisownia łączna kuleje. 

Staram się uważać na pisanie nie z przymiotnikami. Ale przede wszystkim skupiam się na treści.
 https://4programmers.net/Forum/Inne/346577-jaki_jezyk_jest_lepszy_od_c
> Co do koncepcji, to w ogółach masz rację i zasadniczo promujesz dość przyzwoite zasady

Dzięki za dobre słowo!

> , a do szczegółów zawsze można się doczepić (ja np. nie przepuszczam na review "using namespace" będące na poziomie jednostki kompilacji, bo to utrudnia zrozumienie kodu).

Jest to chyba problem w większej skali. W projektach w jakich brałem i biorę udział nie miałem z tym problemu. Zwłaszcza gdy zintegrowane środowisko umożliwia kontekstowe nawigowanie po kodzie.

> Nadużywasz słów "zawsze" i "nigdy". 

W poradniku to raczej normalne...
 
> Razi styl C++ fanboja, przekręcanie nazw języków itp. Mało to profesjonalne i nie zachęca do poważnego potratowania. 

Zadałem tu: https://4programmers.net/Forum/Inne/346577-jaki_jezyk_jest_lepszy_od_c pytanie: Czy ktoś zna język mający wszystkie najważniejsze zalety C++? I był przy tym lepszy od C++. Poziom odpowiedzi był żenująco niski.
Nawet nie wiedzieli tam jaki inny język wspiera wielodziedziczenie.
Tak więc puki co będę entuzjastą C++.
Jeśli chodzi o pozostałe języki, to wspomniałem o Basz, Java Skrypt i C Szarp.
Basz potrafi doprowadzić każdego do rozstroju nerwowego. Dlatego zalecam trzymać się od niego z daleka.
Java Skrypt ponoć ma takie ficzery jak: 1+1 = 3 (opinia programisty serwisów www). 
C Szarp klasyczne nowotwory z M$ (wiem to bo pisałem ostatnio coś na zaliczenie semestru).

poniedziałek, 7 grudnia 2020 o 16:32:37 UTC+1 jawors...@adres.pl napisał(a):
> niedziela, 6 grudnia 2020 o 21:37:36 UTC+1 Wojciech Muła napisał(a): 
> > On Tuesday, November 17, 2020 at 8:45:52 PM UTC+1, jawors...@adres.pl wrote: 
> > > Cześć! 
> > > 
> > > Dodanie wielu nowych koncepcji. Doprecyzowanie wcześniejszych myśli. Udoskonalenie układu całego dokumentu (pogrupowanie akapitów w logiczne grupy). 
> > > 
> > > https://gitlab.com/energokoder/sztuka-kodowania 
> > 
> > Przede wszystkim dystrybuowanie tego w formacie .odt to słaby pomysł. Rozważ przejście np. na markdown, który jest elegancko renderowany na gitlabie. Nie mówiąc, że masz wtedy sensowne zarządzanie wersjami swojego tekstu.
> W pełni świadomie nie używam zbyt często "markdown". Wynika to z faktu, że Libre Office nadaje się do składu dokumentów i go opanowałem zadowalająco. Jednak głównym powodem by nie używać md jest fakt fatalnej symboliki w Polsce: markdown tłumaczy się na "ma dałn", co jest analogią do "ma dałna".

Rozumiem to.

Ja z podobnych względów nie udzielam korepetycji.
Korepetycje to inaczej "korki", jak "korki taczer".
(Nie poruszam się też samochodem, bo strach byłoby utknąć w korku)

W razie czego alternatywą do markdowna jest org mode:
https://orgmode.org/

> (Nie poruszam się też samochodem, bo strach byłoby utknąć w korku) 

Jest na to sposób: wstawanie przed 5:00, jazda do pracy na 6:00 i powrót o 14:00.

> https://gitlab.com/energokoder/sztuka-kodowania 
> 
> Zapraszam do lektury i dyskusji! 

Fajnie, że przeczytaliście ten tekst. Fajnie się też dyskutuje.
Jednak poziom dyskusji jest mizerny. Gdyż brak konkretów.
Dlatego zadam pytanie pomocnicze:

Co byście dodali do tego tekstu?

Nie chodzi mi o przepisywanie Szap-owskich książek, tylko pytam o to bez czego nie ma mowy o profesjonalnym programowaniu w C++.
Wszelkie celne uwagi (dotychczasowe i te które podacie w odpowiedzi na pyt. pomocnicze) postaram się uwzględnić w kolejnej wersji.
Jednak najprawdopodobniej powstanie ona dopiero po sesji zimowej 2021.
Wszelkie wykorzystane koncepcje pochodzące od osób dyskutujących na grupie i na forum opatrzę notką z podziękowaniami.

On Monday, December 7, 2020 at 4:32:37 PM UTC+1, jawors...@adres.pl wrote:
> > Nadużywasz słów "zawsze" i "nigdy".
> W poradniku to raczej normalne...

Może w poradniku dla sapera. :)

> > Razi styl C++ fanboja, przekręcanie nazw języków itp. Mało to profesjonalne i nie zachęca do poważnego potratowania.
> Zadałem tu: https://4programmers.net/Forum/Inne/346577-jaki_jezyk_jest_lepszy_od_c pytanie: Czy ktoś zna język mający wszystkie najważniejsze zalety C++? I był przy tym lepszy od C++. Poziom odpowiedzi był żenująco niski. 
> Nawet nie wiedzieli tam jaki inny język wspiera wielodziedziczenie. 
> Tak więc puki co będę entuzjastą C++. 

Czepiłeś się tego wielodziedziczenia, jakby to był jakiś cud natury, a ta cecha jest marginalna, używana tak naprawdę sporadycznie (no i oczywiście w klasyczny dla C++ sposób skopana, patrz dziedziczenie wirtualne). Ludzkość bowiem dość dawno temu zauważała, że skomplikowanych systemów nie da się łatwo modelować grafami acyklicznymi, że bardziej praktyczna jest kompozycja typów.

C++ trochę nadrabia ostatnio, ale przez dekady nie dorobił się systemu modułów. W równoległym wszechświecie koncepcja modułów istniej od pół wieku, doczekała nawet wariantu parametryzowanego (w Ocamlu, SML-u, Adzie). C++ nie ma spójnego systemu budowania. Nie ma systemu dystrybucji paczek, wersjonowania pakietów, słowem niczego co jest normą w innych językach i co jest oczekiwane przez programistów. Z powodu tych bolączek powstał cały ruch bibliotek "include only", bo po prostu łatwiej skopiować plik i teoretycznie gotowe. Ale to obejście, a nie rozwiązanie systemowe.

Wspomniałeś w poprzednim poście o obsłudze napisów. Przecież C++ w 2020 roku nawet nie wie co to Unicode. Nie zna pojęcia "znaku", utożsamiając go z losowym kodem znaku. Weźmy np. static_cast<char>(250) -- co to jest? Weźmiesz kodowanie extended ASCII? A może to pierwszy bajt z UTF-8? A może to przyszło z programu pana Zenka, który w 1983 zastosował kodowanie Mazovia, czy jak to się tam zwało. A może z maszyny sterowanej Windowsem'95 i tam będzie Windows-1251?

W ogóle klasa std::string to jest piękny przykład nagromadzenia antypatternów, coś potwornego. Do tego mało praktyczna, bo jak ktoś poużywał stringów np. w Pythonie i musi wrócić do C++, to fizycznie boli. Wyrażenia regularne z C++11? Są jak żona komisarza Ryby --- pomyłką. API z lat '90, niewyobrażalnie koślawe, żeby jeszcze implementacje były wydajne... no nie są.

Piszę w tym języku od wielu lat i mógłbym wymieniać więcej kwiatków, np. poznęcać się nad "metaprogramowaniem", które pojawiło się w C++ przez przypadek i tak też działa. Ale, z całym szacunkiem, nie chce mi się, bo jest to po prostu nudne. Ten język nie umrze łatwo, za dużo w nim kodu napisano. Jest nawet niezerowa szansa, że nie podzieli losu COBOLA.

w.

2020-12-07 o 08:30 -0800, Maciek Godek napisał:
> W razie czego alternatywą do markdowna jest org mode:
> https://orgmode.org/

Lub ew. textile: https://textile-lang.com/
Albo HTML. Albo pliki txt z jakąś swoją składnią i autorskim
generatorem.

Mateusz

poniedziałek, 7 grudnia 2020 o 21:53:05 UTC+1 Wojciech Muła napisał(a):

> Czepiłeś się tego wielodziedziczenia, jakby to był jakiś cud natury, a ta cecha jest marginalna, używana tak naprawdę sporadycznie (no i oczywiście w klasyczny dla C++ sposób skopana, patrz dziedziczenie wirtualne). Ludzkość bowiem dość dawno temu zauważała, że skomplikowanych systemów nie da się łatwo modelować grafami acyklicznymi, że bardziej praktyczna jest kompozycja typów. 

Z tego co rozumiem, wielodziedziczenie umożliwia właśnie tworzenie cyklicznych grafów. (natomiast hierarchie wynikające z kompozycji typów będą zawsze acykliczne)

Raz tylko spotkałem się z kimś, kto próbował uzasadnić potrzebę wielodziedziczenia, tutaj:
https://www.quora.com/Do-C-developers-find-multiple-inheritance-a-useful-feature-Do-Java-developers-ever-find-themselves-wishing-Java-supported-it/answer/Mario-Galindo-Queralt

jednak, jak zwróciłem uwagę w komentarzu, ten sam cel mógłby lepiej osiągnąć za pomocą zwykłej kompozycji.

Swego czasu szukałem historycznego uzasadnienia dla wielodziedziczenia, i jedyne, co znalazłem, to przykład z książki Coxa i Novobilskiego "Object Oriented Programming: An Evolutionary Approach", gdzie dla uzasadnienia wielodziedziczenia posługują się przykładem "zabawkowego samochodu" ("czy jest to rodzaj zabawki, czy rodzaj samochodu?", pytają, odpowiadając sobie, że dzięki wielodziedziczeniu może być "i jednym, i drugim")

Trochę swego czasu mówiłem o tym tutaj:
https://youtu.be/apCBEpjPi_Y?t=2881

> Piszę w tym języku od wielu lat i mógłbym wymieniać więcej kwiatków, np. poznęcać się nad "metaprogramowaniem", które pojawiło się w C++ przez przypadek i tak też działa. Ale, z całym szacunkiem, nie chce mi się, bo jest to po prostu nudne.

Ja uważam, że rzetelna krytyka jest zawsze wartościowa.
Inna rzecz, że programiści często odbierają krytykę narzędzi jak atak personalny, albo gloryfikują je jakby były nie wiadomo czym.

poniedziałek, 7 grudnia 2020 o 19:31:17 UTC+1 jawors...@adres.pl napisał(a):
> > https://gitlab.com/energokoder/sztuka-kodowania 
> > 
> > Zapraszam do lektury i dyskusji! 
> 
> Fajnie, że przeczytaliście ten tekst. Fajnie się też dyskutuje. 
> Jednak poziom dyskusji jest mizerny. Gdyż brak konkretów. 

Jezus opowiedział uczniom przypowieść: Czy może niewidomy prowadzić niewidomego? Czy nie wpadną w dół obydwaj? Uczeń nie przewyższa nauczyciela. Lecz każdy, dopiero w pełni wykształcony, będzie jak jego nauczyciel. Czemu to widzisz drzazgę w oku swego brata, a belki we własnym oku nie dostrzegasz? Jak możesz mówić swemu bratu: Bracie, pozwól, że usunę drzazgę, która jest w twoim oku, gdy sam belki w swoim oku nie widzisz? Obłudniku, wyrzuć najpierw belkę ze swego oka, a wtedy przejrzysz, ażeby usunąć drzazgę z oka swego brata.

On Tuesday, December 8, 2020 at 11:35:59 AM UTC+1, godek....@gmail.com wrote:
> poniedziałek, 7 grudnia 2020 o 21:53:05 UTC+1 Wojciech Muła napisał(a): 
> 
> > Czepiłeś się tego wielodziedziczenia, jakby to był jakiś cud natury, a ta cecha jest marginalna, używana tak naprawdę sporadycznie (no i oczywiście w klasyczny dla C++ sposób skopana, patrz dziedziczenie wirtualne). Ludzkość bowiem dość dawno temu zauważała, że skomplikowanych systemów nie da się łatwo modelować grafami acyklicznymi, że bardziej praktyczna jest kompozycja typów.
> Z tego co rozumiem, wielodziedziczenie umożliwia właśnie tworzenie cyklicznych grafów. (natomiast hierarchie wynikające z kompozycji typów będą zawsze acykliczne) 

Nie. Pojedyncze dziedziczenie daje Ci drzewiastą hierarchię, a wielodziedziczenie grafy skierowane acykliczne.
W hierarchii typów nie możesz mieć cyklu. Przynajmniej ja nie potrafię sobie tego wyobrazić.

> Raz tylko spotkałem się z kimś, kto próbował uzasadnić potrzebę wielodziedziczenia, tutaj: 
> https://www.quora.com/Do-C-developers-find-multiple-inheritance-a-useful-feature-Do-Java-developers-ever-find-themselves-wishing-Java-supported-it/answer/Mario-Galindo-Queralt 
> 
> jednak, jak zwróciłem uwagę w komentarzu, ten sam cel mógłby lepiej osiągnąć za pomocą zwykłej kompozycji. 

Używałem wielodziedzenia jako środka technicznego, bo było wygodniej coś zrobić, ale nie
kojarzę ani jednego użycia na poziomie koncepcyjnym. Tak samo używałem pokręconego
wzorca CRTP, żeby coś było szybciej. Tylko te przypadki policzę na placach jednej ręki.

> > Piszę w tym języku od wielu lat i mógłbym wymieniać więcej kwiatków, np. poznęcać się nad "metaprogramowaniem", które pojawiło się w C++ przez przypadek i tak też działa. Ale, z całym szacunkiem, nie chce mi się, bo jest to po prostu nudne.
> Ja uważam, że rzetelna krytyka jest zawsze wartościowa. 

Produkowanie się tutaj, jeszcze po polsku, to strata czasu. W ogóle krytykowanie C++, nawet
konstruktywne, to strata czasu. Realnie to by trzeba składać proposale, przechodzić przez
całą biurokrację itd. Przykład biblioteki fmt: istnieje od 8 lat, jest powszechnie używana,
jej standaryzacja zajęła rok albo dwa i to będzie dopiero w C++20. Dobre dla kogoś kto ma dużo
wolnego czasu, albo jestoddelegowany w firmie i robi to w godzinach pracy.

> Inna rzecz, że programiści często odbierają krytykę narzędzi jak atak personalny, albo gloryfikują je jakby były nie wiadomo czym.

To kwestia wieku, młodzi się zwykle bardzo przejmują. Z wiekiem i doświadczeniem
uczysz się, że wzruszenie ramionami to często i tak zbyt gwałtowna reakcja. :)

w.

> > Inna rzecz, że programiści często odbierają krytykę narzędzi jak atak personalny, albo gloryfikują je jakby były nie wiadomo czym.
> To kwestia wieku, młodzi się zwykle bardzo przejmują. Z wiekiem i doświadczeniem 
> uczysz się, że wzruszenie ramionami to często i tak zbyt gwałtowna reakcja. :) 

Ja nad sprawami zasadniczymi (praca i zainteresowania) nie mogę przejść obojętnie wzruszając jedynie ramionami i akceptując narzucone kompromisy.
Bo:
1. Mam ambicje pracować jak najwydajniej (zawodowo i w ramach hobby).
2. Mam ambicje pracować racjonalnie: używać do programowania sprzętu i oprogramowania takiego jakie ma sens: Które jest technicznym dziełem sztuki a nie spartaczonym kompromisem politycznym.
3. Mam ambicje tworzyć techniczne dzieła sztuki jakie przetrwają próbę czasu.

Dlatego wciąż pytam się Was o to czy wiecie coś o "lepszym C++" do programowania wieloplatfromowych programów użytkowych i bazodanowych.
Bo jak będzie miał najważniejsze zalety C++, to jestem gotów się przesiąść (przynajmniej prywatnie).
Ale jak na razie nic takiego nie widzę.

środa, 9 grudnia 2020 o 16:10:39 UTC+1 jawors...@adres.pl napisał(a):
> > > Inna rzecz, że programiści często odbierają krytykę narzędzi jak atak personalny, albo gloryfikują je jakby były nie wiadomo czym. 
> > To kwestia wieku, młodzi się zwykle bardzo przejmują. Z wiekiem i doświadczeniem 
> > uczysz się, że wzruszenie ramionami to często i tak zbyt gwałtowna reakcja. :)
> Ja nad sprawami zasadniczymi (praca i zainteresowania) nie mogę przejść obojętnie wzruszając jedynie ramionami i akceptując narzucone kompromisy. 
> Bo: 
> 1. Mam ambicje pracować jak najwydajniej (zawodowo i w ramach hobby). 
> 2. Mam ambicje pracować racjonalnie: używać do programowania sprzętu i oprogramowania takiego jakie ma sens: Które jest technicznym dziełem sztuki a nie spartaczonym kompromisem politycznym. 
> 3. Mam ambicje tworzyć techniczne dzieła sztuki jakie przetrwają próbę czasu. 
> 
> Dlatego wciąż pytam się Was o to czy wiecie coś o "lepszym C++" do programowania wieloplatfromowych programów użytkowych i bazodanowych. 
> Bo jak będzie miał najważniejsze zalety C++, to jestem gotów się przesiąść (przynajmniej prywatnie). 
> Ale jak na razie nic takiego nie widzę.

Co do mnie, mogę opowiedzieć, dlaczego nie lubię C++, a dlaczego lubię Lispa.
Otóż rzecz ma się tak, że C++ to język, nad którym ktoś inny ma kontrolę, natomiast Lisp to język, nad którym ja mam kontrolę.

Jak mi się coś nie podoba w C++ (a dużo rzeczy mi się nie podoba), to mogę najwyżej załamać ręce i westchnąć.
A jak mi się coś nie podoba w Lispie, to mogę to samemu zmienić. 
Dzięki temu mam poczucie ulgi, że rzeczy są takie, jakie chcę, żeby były.

Albo mówiąc inaczej, C++ to taka trochę Castorama, a Lisp to taka drukarka 3D.
Jeżeli robię typowe rzeczy, którymi zajmują się developerzy, to asortyment Castoramy raczej wystarczy.
I wtedy pewnie też będzie efektywniejszy, bo nie będę musiał tracić czasu na drukowanie potrzebnych mi narzędzi.
I pewnie też znajdę społeczność, w której będę sobie mógł ponarzekać na niedociągnięcia w narzędziach, i lepiej się od nich nauczę, jak sobie z nimi radzić.

Ale język C++ jest tak samo "doskonały" jak asortyment w Castoramie. Tzn. ani nie jest, ani nie ma być.
Ma się nadawać do typowych rzeczy.

No, ale wybierając narzędzia w Castoramie, uzależniam się też od dostawców narzędzi.
I nie odkryję raczej nowych technologii budowlanych.

Nie wiem, czy to jest dobra metafora, ale to jest jakaś metafora.

Jak piszę swoje hobbystyczne programy, to moim priorytetem jest przede wszystkim czytelność.
Lisp daje mi narzędzia do tego, żebym mógł pisać czytelne programy.
C++ zmusza mnie w tych kwestiach do kompromisu.
(zresztą prawie każdy inny język by zmuszał)

> Swego czasu szukałem historycznego uzasadnienia dla wielodziedziczenia, i jedyne, co znalazłem, to przykład z książki Coxa i Novobilskiego "Object Oriented Programming: An Evolutionary Approach", gdzie dla uzasadnienia wielodziedziczenia posługują się przykładem "zabawkowego samochodu" ("czy jest to rodzaj zabawki, czy rodzaj samochodu?", pytają, odpowiadając sobie, że dzięki wielodziedziczeniu może być "i jednym, i drugim") 

Takie "uzasadnienie" jest dla dzieci. Bo w praktyce zaczynamy od pojęcia zabawki. Wynika to z przypadku użycia w którym głównym aktorem jest dziecko. Kolejne zabawki dziedziczymy z tej klasy. Nie dziedziczymy po klasie samochód, bo żaden prawdziwy samochód nie jest zabawką dla dziecka. Zabawki nie są rodzajem samochodu. Samochodziki są rodzajem zabawki. Tak samo jak dziecko nie jest typem pochodnym od Lalka (dziecko bawi się laką ale nie innym dzieckiem).
Hierarchia klas w tym przypadku jest: class Zabawka {...}; class Samochodzik : public Zabawka {...}; I dalej: class Lalka : public Zabawka {...};
To tyle o tym bez sensownym przykładzie.

Podam za to prawdziwy przykład z mojego projektu. Ten problem jaki rozwiązuje wielodziedziczenie jest fundamentalny i (pomijając chamskie kopiowanie kodu w każdej klasie) jest nierozwiązywalny w inny sposób (nawet przez kompozycję).

Problem:
Dostajemy bibliotekę Qt. Chcemy z niej korzystać w projekcie. Nie chcemy jej zmieniać, w myśl inżynierskiej zasady: "Zamknięte na modyfikacje: otwarte na rozszerzanie." Zakładamy (fałszywie), że Qt spełnia w pełni tą zasadę.
Mamy klasę QWidget która jest przodkiem okien i kontrolek Qt.
I teraz: chcemy kontrolki Qt sobie dostosować. Zauważamy przy tym, że część funkcjonalności jest wspólna i powinna być w klasie QWidget. Ale tej klasy nie możemy ruszyć (powyższa zasada inżynierii oprogramowania).

Rozwiązanie:
By nie kopiować kodu w każdej naszej klasie kontrolki musimy zrobić klasę po której dziedziczą wszystkie kontrolki używane przez nas w projekcie.

Czyli mamy klasy:
class MojaKontrolka {...};
class Etykieta : public QLabel, public MojaKontrolka {...};
class EdycjaWLini : public QLineEdit, public MojaKontrolka {...};
class Edycja : public QTextEdit, public MojaKontrolka {...};
class ListaRozwijana : public QComboBox, public MojaKontrolka {...};
I tak dalej...

Ten problem dotyczy każdej większej biblioteki jaką chcemy używać w nietrywialny sposób.

On Wednesday, December 9, 2020 at 11:01:25 AM UTC-5, heby wrote:
> On 09/12/2020 16:35, Jacek Jaworski wrote: 
> > Czyli mamy klasy: 
> > class MojaKontrolka {...}; 
> > class Etykieta : public QLabel, public MojaKontrolka {...};
> A czemu to nie może być MojaKontrolka< QLabel >, gdzie MojaKontrolka 
> wyglada tak: 
> 
> template < _T > 
> class MojaKontrolka : public _T

To zadziala ale twoj template musi akumulowac kod aby obsluzyc wszystkie sytuacje gdzie zachodzi interakcja pomiedzy twoim kodem a klasami QTw przypadku dziedziczenia wielobazowego MojaKontrolka ma tylko podstawowy kod a caly "glue code" idzie do implementacji poszczegolnych klas - nie musisz pisac kody na wszystkie mozliwe klasy QT ale tylko na te ktor ci sa potrzebebne i tylko wtedy kiedy ci sa potrzebne. Zreszta uzywanie dzieciczenia wielobazowego przy pracy z QT to standard - ponizszy przyklad z kodu na produkcji:

#ifndef __DSPINVENTORYAVAILABILITYBYSOSHIPPINGDATE__
#define __DSPINVENTORYAVAILABILITYBYSOSHIPPINGDATE__

#include "guiclient.h"
#include "display.h"
#include <parameter.h>

#include "ui_dspInventoryAvailabilityBySoShippingDate.h"

class dspInventoryAvailabilityBySoShippingDate : public display, public Ui::dspInventoryAvailabilityBySoShippingDate
{
	Q_OBJECT
public:
	dspInventoryAvailabilityBySoShippingDate(QWidget* parent = 0, const char* name = 0 , Qt::WindowFlags fl = Qt::Window);

    virtual bool setParams(ParameterList & params);
    

public slots:
    virtual SetResponse set(const ParameterList & pParams );
    virtual void sFillList();
    virtual void sFilterSetSaved(int filterId);
    virtual void sFilterUpdated(int filterId);
    virtual void sClearFilter();
    virtual void closeEvent( QCloseEvent * pEvent );

protected slots:
    virtual void languageChange();

private:
	int _lastFilterId;
	int _runSequence;
	int _lastSearchGroup;
	int _lastLookAheadDays;
	QString getCheckBoxFilters();
	void removeTempResults(int runSeq);
	int prepareNewTempResults(const ParameterList & params);
    
};



#endif // __DSPINVENTORYAVAILABILITYBYSOSHIPPINGDATE__

środa, 9 grudnia 2020 o 17:01:25 UTC+1 heby napisał(a):
> On 09/12/2020 16:35, Jacek Jaworski wrote: 
> > Czyli mamy klasy: 
> > class MojaKontrolka {...}; 
> > class Etykieta : public QLabel, public MojaKontrolka {...};
> A czemu to nie może być MojaKontrolka< QLabel >, gdzie MojaKontrolka 
> wyglada tak: 
> 
> template < _T > 
> class MojaKontrolka : public _T

W brew temu co pisze Adam to nie zadziała, bo klasa dziedzicząca po QObject nie może być szablonem (qmoc lub asercja w czasie kompilacji to wykrywa). Tak samo jak nie można dziedziczyć po wielu klasach wywiedzionych od QObject.

On Wednesday, December 9, 2020 at 12:58:29 PM UTC-5, heby wrote:
> On 09/12/2020 18:47, Jacek Jaworski wrote: 
> >> template < _T > 
> >> class MojaKontrolka : public _T 
> > W brew temu co pisze Adam to nie zadziała, bo klasa dziedzicząca po QObject nie może być szablonem
> To bardzo interesujace. 
> 
> template< typename _T> 
> class Foo : public _T 
> { 
> }; 
> 
> class Bar : public Foo< QWidget > 
> { 
> Q_OBJECT 
> 
> Q_SIGNALS 
> ... 
> } 
> 
> I się kompiluje zarówno C++ jak i MOCem. W mocu znajdziesz: 
> Foo<QWidget>::staticMetaObject i inne ciekawoski z mocowania Qt. Qt w 
> wersji 5 coś. 
> 
> Innymi słowy, sprawdź sam. 
> 
> Rozwiązanie z mixinem jest dokładnie tym co potrzebujesz, nie wymaga 
> wielodziedziczenia i nie zawiera wad o których bym wiedział na podstawie 
> Twojego opisu używania na produkcji. Innymi słowy możesz już dzisiaj 
> zmienić wszystko na mixiny.
Czesciowo zgodze sie z kolege - to bedzie dzialac i nawet mi sie to podoba  - ma tylko jedna bardzo paskudna wade - koncowy kod puchnie przez template - w moim przypadku klasa display ma okol 1000 lini a w zrodle jest ponad 150 klas dziedziczacych po display (nie liczac innego "paskudztwa") - nawet nie chce myslec jak koncowy kod by wygladal :-(

środa, 9 grudnia 2020 o 18:58:29 UTC+1 heby napisał(a):
> On 09/12/2020 18:47, Jacek Jaworski wrote: 
> >> template < _T > 
> >> class MojaKontrolka : public _T 
> > W brew temu co pisze Adam to nie zadziała, bo klasa dziedzicząca po QObject nie może być szablonem
> To bardzo interesujace. 
> 
> template< typename _T> 
> class Foo : public _T 
> { 
> }; 
> 
> class Bar : public Foo< QWidget > 
> { 
> Q_OBJECT 
> 
> Q_SIGNALS 
> ... 
> } 
> 
> I się kompiluje zarówno C++ jak i MOCem. W mocu znajdziesz: 
> Foo<QWidget>::staticMetaObject i inne ciekawoski z mocowania Qt. Qt w 
> wersji 5 coś. 
> 
> Innymi słowy, sprawdź sam. 

Zrobiłeś tu pewne oszustwo. Bo Bar jest potomkiem szablonu konkretyzowanego typem pochodnym po QObject. Zatem Bar nie jest szablonem. Więc nie udowodniłeś, że QObject może być dziedziczony w szablonach.
Ale OK! Nie znałem tej sztuczki.

On 09/12/2020 16:35, Jacek Jaworski wrote:
> Czyli mamy klasy:
> class MojaKontrolka {...};
> class Etykieta : public QLabel, public MojaKontrolka {...};

A czemu to nie może być MojaKontrolka< QLabel >, gdzie MojaKontrolka
wyglada tak:

template < _T >
class MojaKontrolka : public _T

On 09/12/2020 18:29, Adam M wrote:
>> template < _T >
>> class MojaKontrolka : public _T
> To zadziala ale twoj template musi akumulowac kod aby obsluzyc wszystkie sytuacje gdzie zachodzi interakcja pomiedzy twoim kodem a klasami QTw przypadku dziedziczenia wielobazowego

Ale tu nie ma wielobazowego.

class MojButton : public MojaKontrolka< QButton >

> MojaKontrolka ma tylko podstawowy kod

Tak właśnie jest.

> a caly "glue code" idzie do implementacji poszczegolnych klas

I tu też właśnie tak jest.

> - nie musisz pisac kody na wszystkie mozliwe klasy QT ale tylko na te ktor ci sa potrzebebne i tylko wtedy kiedy ci sa potrzebne.

I tu tez tak jest.

> Zreszta uzywanie dzieciczenia wielobazowego przy pracy z QT to standard

Z grubsza: pisuje w Qt relatywnie duży kawał kodu. Nie żebym był jakimś
specjalistą od Qt, ale wielodziedziecznia u mnie tyle co kot napłakał. W
dodatku wszystkie powody są możliwe do przeskoczenia, zdecydowana
większośc implementacji wielobazowego dziedziczenia wynika z lenistwa.
Ciężko mi wskazać palcem inny na przestrzeni 15 lat dzibdziania w sporej
aplikacji, która w częsci jest m.in. Qt.

> - ponizszy przyklad z kodu na produkcji:

Za mało aby ocenić, ale jestem pi x dzwi przekonany że dziedziczenie
wielobazowe (szczególnie implementacji) jest zbędne. Czego dowodem jest
Java oraz fakt że jeszcze mi się nigdy nie przydało *naprawdę* poza
pseudo-semantyką typu boost::noncopyable albo shared_from_this.

To co pkazałem ma nawet nazwę. To Mixin. Przy czym puryści programowania
obiektowego mogą mnie za to ukatrupic, więc tylko szeptem to podpowiadam.

On 09/12/2020 18:47, Jacek Jaworski wrote:
>> template < _T >
>> class MojaKontrolka : public _T
> W brew temu co pisze Adam to nie zadziała, bo klasa dziedzicząca po QObject nie może być szablonem

To bardzo interesujace.

template< typename _T>
class Foo : public _T
{
};

class Bar : public Foo< QWidget >
{
	Q_OBJECT

Q_SIGNALS
...
}

I się kompiluje zarówno C++ jak i MOCem. W mocu znajdziesz:
Foo<QWidget>::staticMetaObject i inne ciekawoski z mocowania Qt. Qt w
wersji 5 coś.

Innymi słowy, sprawdź sam.

Rozwiązanie z mixinem jest dokładnie tym co potrzebujesz, nie wymaga
wielodziedziczenia i nie zawiera wad o których bym wiedział na podstawie
Twojego opisu używania na produkcji. Innymi słowy możesz już dzisiaj
zmienić wszystko na mixiny.

On 09/12/2020 20:05, Adam M wrote:
> Czesciowo zgodze sie z kolege - to bedzie dzialac i nawet mi sie to podoba  - ma tylko jedna bardzo paskudna wade - koncowy kod puchnie przez template

Tylko o ilośc QWidgetów, a nie własnych. Masz ich milion czy naście?

> - w moim przypadku klasa display ma okol 1000 lini a w zrodle jest ponad 150 klas dziedziczacych po display (nie liczac innego "paskudztwa")

Wiec będzie tylko 1 template instancjonowany.

Nikt nie każde robić template inline. Możesz zrobić explicit
instantiation w pliku cpp.

On 09/12/2020 20:25, heby wrote:
> Nikt nie każde robić template inline. Możesz zrobić explicit
> instantiation w pliku cpp.

Podpowiem:

W pliku my_widget.hpp:

template< typename _T >
class MyWidget : public _T
{
public:
	void update() override;
}

W pliku my_widget.cpp:

#include "my_widget.hpp"

template< typename _T>
void
MyWidget::update()
{
	//coś
}

template class MyWidget< QButton >;
template class MyWidget< QFoo >;
template class MyWidget< QBar >;
[...]

I tyle. Dalsze dziedziczenie w kodzie po MyWidget< QFoo > nie powoduje
przyrostu kodu wykonywalnego. Zystałeś brak wielodziedziczenia,
straciłeś troche miejsca na podobny kod dla róznych widgetów bazowych
(ale tylko bazowych). Kompilator *może* ten kod połaczyć w jedno, więc
może się okazać że nic nie straciłeś.

Zyskałeś również *prawdziwą* możliwość wirtualizacji QFoo, gdzie można
nadpisać wszystko co chcesz. Dodatkowo nic nie stoi na przeszkodzie aby
to ciągnąc dalej:

template< typename _T >
class MyMagicButtonWithFancyBorder : public MyWidget< _T >
{
	// common logic
}

class UpButton : MyMagicButtonWithFancyBorder< QButton >
{
}

class DownButton : MyMagicButtonWithFancyBorder< QButton >
{
}

class PlayButton : MyMagicButtonWithFancyBorder< QFooButton >
{
}

itd.

On 09/12/2020 20:55, Jacek Jaworski wrote:
> Więc nie udowodniłeś, że QObject może być dziedziczony w szablonach.

Jest dziedziczony. Zapewne chodzi Ci o to że klasa template nie może być
Q_OBJECTem. Być może nie. Choć nie wiem dlaczego.