W dniu sobota, 29 grudnia 2018 14:24:18 UTC+1 użytkownik s...@g...com napisał:
> > > 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.

Nie o to chodzi.
Pytanie brzmi, czy ucząc się C++ dobrze się nauczysz podstawowych koncepcji.

> > > + 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.

Są pisane w dowolnym języku, który jest kompatybilny z systemem
uruchomieniowym. Raczej w C niż w C++, bo C++ ma swój "name mangling",
który komplikuje dużo rzeczy.

> > > + 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.

Ja też. Tym językiem jest język C.
Stroustrup zresztą sam kiedyś stwierdził:

"Within C++, there is a much smaller
and cleaner language struggling to get out."

> 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.

Jeżeli idzie o SDL i OpenGL, to używam na co dzień.
Nawet zrobiłem framework, który udostępnia mi te interfejsy
do interpretera Scheme'u: http://puszcza.gnu.org.ua/software/slayer/

I nie, nie na każdej platformie. Na embedach niestety nie działa.
STL i Boost? Mam lepsze zajęcia. Qt? Może ma sens w niektórych
zastosowaniach.

> 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).

Jak to kiedyś powiedział mój kolega,
"nikt, kto kroi chleb, nie myśli, że wysyła wiadomość do noża,
nakazującą mu krojenie chleba, albo do chleba, nakazującą
mu się pokroić".
W każdym razie ja nie znam nikogo takiego. Jak chcę przesunąć kamień,
to przesuwam kamień, a nie mówię do kamienia: kamień.przesuń(się).
O tym zresztą też pisałem:
https://www.quora.com/Why-is-OO-programming-consider
ed-bad-by-some-people/answer/Panicz-Godek

> > > + 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.

Brzmi to dla mnie jak "wielodziedziczenie jest dobre, bo rozwiązuje niektóre
problemy, które wprowadza mechanizm dziedziczenia".

> > 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.

A dlaczego bez przeładowania operatorów miałbyś nie móc porównywać
złożonych typów?

> Albo by napisać zoptymalizowany menadżer pamięci w aplikacji jednowątkowej (trochę
to trąci myszką w dzisiejszych czasach...).

W różnych okolicznościach pisanie menadżera pamięci może mieć sens.
Tyle że do tego żadne przeładowania operatorów nie są potrzebne.

> > > + 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.

Kurde, szkoda że nikt mi o tym nie powiedział, jak pisałem
pracę magisterską.

> > > + 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.

Warto zapoznać się z tą prezentacją:
https://fsharpforfunandprofit.com/rop/

> > > + 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).

Co to znaczy: "wolność, ale nie w tak szerokim zakresie"?

> > > + 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.

Podobnie jak w przypadku wielu innych języków.

> > > + 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).

"biblioteki w asemblerze i C" można włączyć do każdego języka, który
ma jakąś implementację FFI.
Dużo języków ma dużo bibliotek. Na przykład Python (który dodatkowo
ma FFI). Albo Java.

> > > + 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++.

Prezentacja dotyczy w całości języka C++. D jest może wspomniany
gdzieś na końcu, i to bardziej kokieteryjnie.

do góry

> > [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.

To tak, jakbyś powiedział, że silnik zwiększa koszt samochodu.
Otóż nie zwiększa, bo jest jego integralną częścią. Klima albo automat może
zwiększać, ale nie silnik.
Podobnie jest z operatorem przypisania w językach imperatywnych. On niczego nie
zwiększa, bo nie może go nie być.

> Proponuję, żebyś - zamiast zgadywać w ciemno o czym mówię
> - spróbował przeczytać tę książkę, i dopiero wtedy się
> wypowiedzieć.

Czytałem. Tylko jakoś nie uległem czarowi języków funkcjonalnych do tego stopnia,
żeby uznać je jako teoretyczną podstawę do czegokolwiek.
I mam wrażenie (również z poprzednich naszych dyskusji), że tak właśnie sądzisz - że
języki funkcjonalne są podstawą, z której można budować inne konstrukcje. Dlatego
zastanawiasz się, jaki jest koszt dodania operatora przypisania.
Tymczasem w informatyce, jeżeli w ogóle jest jakaś podstawa dla innych konstrukcji,
to zwyczajowo była nią maszyna Turinga (i nie widzę powodu, żeby miała stracić ten
status) a akurat tam jest już koncepcja modyfikacji wartości. Głowica zapisująca nową
wartość w tym samym miejscu to właśnie operator przypisania.
W tym kontekście zamiast pytać, jaki jest koszt dodania operatora przypisania do
czegokolwiek, należałoby zapytać, jaki jest koszt udawania, że go może nie być.
Otóż ten koszt to jest między innymi ta dyskusja. :-)

> To dobra książka, naprawdę.

https://cemerick.com/2009/03/24/why-mit-now-uses-pyt
hon-instead-of-scheme-for-its-undergraduate-cs-progr
am/

Wracając do tematu: jeżeli operator przypisania jest problemem w Scheme, to jest to
problem w Scheme. W językch imperatywnych ten operator nie jest problemem, tylko
integralną częścią języka. A narzędzi analitycznych to w ogóle nie komplikuje,
naprawdę.

> > 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.

Mi się zdarzyło. Natomiast przyznam, że moje własne niezadowolenie z języka C++
skierowało mnie ku nauce Ady. I paradoksalnie, mój C++ się wtedy też poprawił.

> 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.

Tak, to prawda. Ale znam ludzi, którzy twardo stosują C++ jako platformę do nauki
programowania i struktur danych. Myślę, że przy odpowiednim prowadzeniu to nie jest
zły pomysł.
Ale sam osobiście poleciłbym nowicjuszom język Wolfram. Również dzieciom, jak im się
już Scratch znudził. C++ nie jest dobrym pierwszym językiem, chociaż może być bardzo
praktycznym językiem w późniejszej pracy czy innym realnym projekcie.

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

do góry

W dniu niedziela, 30 grudnia 2018 00:21:16 UTC+1 użytkownik Maciej Sobczak napisał:
> > > [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.
>
> To tak, jakbyś powiedział, że silnik zwiększa koszt samochodu.
> Otóż nie zwiększa, bo jest jego integralną częścią. Klima albo automat może
zwiększać, ale nie silnik.
> Podobnie jest z operatorem przypisania w językach imperatywnych. On niczego nie
zwiększa, bo nie może go nie być.

Nie. Programy, które nie posiadają instrukcji przypisania,
można analizować, po prostu zastępując wyrażenia ich wartościami.
Programów, w których używa się instrukcji przypisania, nie
można analizować w taki sposób - trzeba zaprzęgać inne środki
analizy. Oczywiście można ostrożnie wprowadzać instrukcje
przypisania, otrzymując modele, które wciąż mają dobre właściwości.
I oczywiście obowiązkowy link do Quory ;]
https://www.quora.com/What-is-your-opinion-on-purely
-functional-programming/answer/Panicz-Godek

> > Proponuję, żebyś - zamiast zgadywać w ciemno o czym mówię
> > - spróbował przeczytać tę książkę, i dopiero wtedy się
> > wypowiedzieć.
>
> Czytałem. Tylko jakoś nie uległem czarowi języków funkcjonalnych do tego stopnia,
żeby uznać je jako teoretyczną podstawę do czegokolwiek.
> I mam wrażenie (również z poprzednich naszych dyskusji), że tak właśnie sądzisz -
że języki funkcjonalne są podstawą, z której można budować inne konstrukcje. Dlatego
zastanawiasz się, jaki jest koszt dodania operatora przypisania.

Tzn. ściśle rzecz biorąc cała informatyka teoretyczna bazuje na
"czystych funkcjach" - to jest budulec, z którego tworzy się
semantyki denotacyjne dla języków programowania.

> Tymczasem w informatyce, jeżeli w ogóle jest jakaś podstawa dla innych konstrukcji,
to zwyczajowo była nią maszyna Turinga (i nie widzę powodu, żeby miała stracić ten
status) a akurat tam jest już koncepcja modyfikacji wartości. Głowica zapisująca nową
wartość w tym samym miejscu to właśnie operator przypisania.

Jeśli zapytamy, jaki model obliczeń jest współcześnie
najbardziej rozpowszechniony i najlepiej zrozumiany, to prawdopodobnie
tym modelem obliczeń będzie arkusz kalkulacyjny: jest bardzo duża
rzesza osób, które umieją korzystać z arkuszy kalkulacyjnych,
a które nawet nie wiedzą, że to jest programowanie.
Ten model obliczeń charakteryzuje się tym, że nie ma w nim
przepływu sterowania ani operacji przypisania. Jest dużo
prostszym modelem od maszyny von Neumanna, choć oczywiście
nie wszystko da się w nim zrealizować. (Ale można w nim robić
np. takie programy, jak sieci neuronowe. I wspiera obliczenia na
GPGPU)

Model podstawieniowy jest bardziej złożony od arkusza
kalkulacyjnego. Ale jest też bardziej uniwersalny w tym sensie,
że umożliwia tworzenie odrębnych komponentów i łączenie ich
ze sobą na różne sposoby.

Dobrym przykładem tego rodzaju kompozycjonalności są
potoki UNIXa. Co prawda programy, które łączy się w potoki,
takie jak sed czy grep, są napisane w sposób imperatywny,
ale same te programy nie polegają w żaden sposób na globalnym
stanie.

> W tym kontekście zamiast pytać, jaki jest koszt dodania operatora przypisania do
czegokolwiek, należałoby zapytać, jaki jest koszt udawania, że go może nie być.
> Otóż ten koszt to jest między innymi ta dyskusja. :-)

Tutaj nie chodzi o to, że operatora przypisania ma nie być.
Chodzi o to, żeby nie używać go wtedy, kiedy to nie jest konieczne.

Programy, które nie polegają na globalnym stanie, analizuje
się łatwiej - i to przede wszystkim analizuje się je łatwiej
osobom, które muszą pracować z zastanym kodem, czyli
programistom. W językach takich jak C istnieją idiomy, które
pozwalają ograniczać zasięg instrukcji przypisania do
minimum (np. pętle for z iteratorem), ale one istnieją
właśnie dlatego, że modyfikacje globalnego stanu są
kłopotliwe.

> > To dobra książka, naprawdę.
>
> https://cemerick.com/2009/03/24/why-mit-now-uses-pyt
hon-instead-of-scheme-for-its-undergraduate-cs-progr
am/

Nie wiem co miałoby z tego linka wynikać dla tej dyskusji.

> Wracając do tematu: jeżeli operator przypisania jest problemem w Scheme, to jest to
problem w Scheme. W językch imperatywnych ten operator nie jest problemem, tylko
integralną częścią języka. A narzędzi analitycznych to w ogóle nie komplikuje,
naprawdę.

Owo ustalenie, że stosowanie operatora przypisania (oraz operatów
wyrażających przepływ sterowania) komplikuje
środki analizy programu, dotyczy wszystkich języków, w których
procedury mogą przyjmować argumenty i zwracać wartości.
Dotyczy zatem takich języków, jak Java, C++, JavaScript,
Pascal, PHP, Perl, Python i wielu innych.

> > > 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.
>
> Mi się zdarzyło.

A to z chęcią bym zobaczył ;]

> Natomiast przyznam, że moje własne niezadowolenie z języka C++ skierowało mnie ku
nauce Ady. I paradoksalnie, mój C++ się wtedy też poprawił.

Nie wiem co miałoby w tym być paradoksalnego - nauka nowych języków
programowania daje nam nowe perspektywy na to, czym ogólnie jest
programowanie. Akurat dla mnie ciekawie byłoby się dowiedzieć,
czego się można nauczyć od Ady, bo nie miałem z nią żadnej styczności.

W quorowym artykule, który wcześniej podlinkowywałem ("what are some
examples of bad code"), dlatego nie zawarłem dobrej implementacji
w C++, że naprawdę nie wiedziałbym, jak się za to zabrać.
Mógłbym napisać "Haskella w C++", ale nie wiem, czy to by było
zgodne z "duchem C++" (jeżeli ten język w ogóle ma jakiegoś ducha)

> > 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.
>
> Tak, to prawda. Ale znam ludzi, którzy twardo stosują C++ jako platformę do nauki
programowania i struktur danych. Myślę, że przy odpowiednim prowadzeniu to nie jest
zły pomysł.
> Ale sam osobiście poleciłbym nowicjuszom język Wolfram. Również dzieciom, jak im
się już Scratch znudził. C++ nie jest dobrym pierwszym językiem, chociaż może być
bardzo praktycznym językiem w późniejszej pracy czy innym realnym projekcie.

Jak dla mnie Wolfram pewnie byłby OK, gdyby był open-source'owy.

do góry

> Nie będę się jednak upierał, że tego typu wiedza jest konieczną częścią edukacji
programisty. Nie jest. Ale jeżeli ktoś już zadaje sobie takie pytania, to
mikrokontrolery są o tyle ciekawą platformą edukacyjną, że można ją (jeszcze)
zrozumieć w całości i bez niedopowiedzeń. Kiedyś do tego samego celu służyły 8-bitowe
komputery domowe (Atari, Commodore, Spectrum, itp. - starsi może pamiętają).
Dzisiejsze pecety tej ważnej edukacyjnie cechy już nie posiadają.

Ja bym zaczął od początkowego pytania "Jaki język, aby nauczyć się
programować?" - bo wydaje mi się, że zdecydowanej większości zadającej
to pytanie chodzi o inne "programowanie", niż poznawanie jak struktury
rozkładać w pamięci.

--
Pozdrawiam,
Mateusz Bogusz

do góry

> > 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).
>
> Jak to kiedyś powiedział mój kolega,
> "nikt, kto kroi chleb, nie myśli, że wysyła wiadomość do noża,
> nakazującą mu krojenie chleba, albo do chleba, nakazującą
> mu się pokroić".
> W każdym razie ja nie znam nikogo takiego. Jak chcę przesunąć kamień,
> to przesuwam kamień, a nie mówię do kamienia: kamień.przesuń(się).
> O tym zresztą też pisałem:
> https://www.quora.com/Why-is-OO-programming-consider
ed-bad-by-some-people/answer/Panicz-Godek

Powiedz to wszystko automatykom i programistom Cnc. Oni na pewno są bardzo
szczęśliwi, że mogą właśnie tak gadać ze sprzętem. Bo to najprostsze i nie
odbiegające od zdroworozsądkowego sposobu myślenia.

do góry

W dniu niedziela, 30 grudnia 2018 18:08:10 UTC+1 użytkownik s...@g...com
napisał:
> > > 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).
> >
> > Jak to kiedyś powiedział mój kolega,
> > "nikt, kto kroi chleb, nie myśli, że wysyła wiadomość do noża,
> > nakazującą mu krojenie chleba, albo do chleba, nakazującą
> > mu się pokroić".
> > W każdym razie ja nie znam nikogo takiego. Jak chcę przesunąć kamień,
> > to przesuwam kamień, a nie mówię do kamienia: kamień.przesuń(się).
> > O tym zresztą też pisałem:
> > https://www.quora.com/Why-is-OO-programming-consider
ed-bad-by-some-people/answer/Panicz-Godek
>
> Powiedz to wszystko automatykom i programistom Cnc. Oni na pewno są bardzo
szczęśliwi, że mogą właśnie tak gadać ze sprzętem. Bo to najprostsze i nie
odbiegające od zdroworozsądkowego sposobu myślenia.

Ale co konkretnie mam powiedzieć?
(NB jak studiowałem automatykę, to mieliśmy tam przedmiot "technika
cyfrowa", na którym jednym z podstawowych rozróżnień było to pomiędzy
"układami kombinacyjnymi" i "układami sekwencyjnymi", które dobrze
odzwierciedla to pomiędzy "programowaniem funkcyjnym" a
"programowaniem imperatywnym". Za to programowania na tych studiach
uczyli raczej dziadosko)

do góry

W dniu 2018-12-29 o 12:51, g...@g...com napisał:

>> + 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 jest bardzo stara książka, jeśli chodzi o Stroustrupa, to dla
początkujących na prawdę fajnie napisana jest "Programowanie. Teoria i
praktyka z wykorzystaniem C++" Na stronie Heliona, znajdziesz sobie
fragment i możesz sam ocenić język i sposób przekazania dla
początkujących http://helion.pl/view/8528E/pcppt2.htm

--
http://kaczus.ppa.pl

do góry

W dniu poniedziałek, 31 grudnia 2018 08:18:32 UTC+1 użytkownik Tomasz Kaczanowski
napisał:

> >> + 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 jest bardzo stara książka

Z tego co pamiętam, chyba została wydana w 1998 roku (patrzę
w Intenetach, i polskie wydanie pochodzi z 2000 roku).
Struktura i Interpretacja Programów komputerowych miała pierwsze
wydanie w 1984 roku, a drugie wydanie pochodzi chyba z 1992,
i jakoś się kurde nie zestarzała.
Książka Petera Norviga, https://github.com/norvig/paip-lisp, wydana
w 1992, wciąż się doskonale czyta (nawet jeśli pewne Common Lispowe
idiosynkrazmy trącą już myszką)
Dialogi Platona powstały 2500 lat temu, a wiele jego diagnoz
społecznych czyta się tak, jakby to było napisane wczoraj.
"Język ANSI C", który miał drugie wydanie w 1988 roku,
wciąż pozostaje całkiem aktualnym podręcznikiem.

Nawet katalog Ikei się tak szybko nie starzeje.

> jeśli chodzi o Stroustrupa, to dla
> początkujących na prawdę fajnie napisana jest "Programowanie. Teoria i
> praktyka z wykorzystaniem C++" Na stronie Heliona, znajdziesz sobie
> fragment i możesz sam ocenić język i sposób przekazania dla
> początkujących http://helion.pl/view/8528E/pcppt2.htm

Zajrzałem.

Kurde, kalkulator facet robi.

W SICP jest różniczkowanie symboliczne, symulator obwodów
logicznych, interpreter Prologa i kompilator.
W PAIP są programy, które na podstawie słownych zadań z podręcznika
do matematyki formułują układy równań, które potem rozwiązują,
algorytmy wyszukujące optymalną trasę oraz systemy ekspertowe.

A tutaj kalkulator.

W mojej ocenie C++ jest językiem, który sprawia, że proste rzeczy
stają się na tyle trudne, że o zaawansowanych można w ogóle zapomnieć.

do góry

> > http://helion.pl/view/8528E/pcppt2.htm
>
> Zajrzałem.
>
> Kurde, kalkulator facet robi.

Super, dzięki temu można tą książkę zrozumieć bez wnikania w dziedzinę, dla której
stworzono ten sztuczny przykład.

> W SICP jest różniczkowanie symboliczne, symulator obwodów
> logicznych, interpreter Prologa i kompilator.

Do bani, przez to nie można zrozumieć tych przykładów bez wnikania w dziedzinę, dla
której stworzono te sztuczne przykłady. Taka książka dla początkujących doktorantów.

> W PAIP są programy, które na podstawie słownych zadań z podręcznika
> do matematyki formułują układy równań, które potem rozwiązują,
> algorytmy wyszukujące optymalną trasę oraz systemy ekspertowe.

Do bani, przez to nie można zrozumieć tych przykładów bez wnikania w dziedzinę, dla
której stworzono te sztuczne przykłady. Taka książka dla początkujących doktorantów.

> A tutaj kalkulator.

Super, focus jest na języku a nie na szpanowaniu przykładami, dzięki czemu książka ma
szansę dotrzeć również do młodszych czytelników. I znam takich młodszych, którzy są w
stanie uczyć się z takiej właśnie książki.

Pamiętam, jak w szkole uczyłem się języka Logo. Zdaje się, że miałem wtedy frajdę z
narysowania wielokąta foremnego a nie z różniczkowania symbolicznego. Jest w SICP
albo w PAIP coś o rysowaniu wielokątków foremnych? Nie ma? Nie da się?

> W mojej ocenie C++ jest językiem, który sprawia, że proste rzeczy
> stają się na tyle trudne, że o zaawansowanych można w ogóle zapomnieć.

A ja wpisałem w Googla hasło "C++ scientific computing" i zalało mnie wynikami.

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

do góry

> Jak to kiedyś powiedział mój kolega,
> "nikt, kto kroi chleb, nie myśli, że wysyła wiadomość do noża,
> nakazującą mu krojenie chleba, albo do chleba, nakazującą
> mu się pokroić".

Zły poziom abstrakcji.
Pomyśl, o zespole kucharzy, którzy wydają sobie właśnie takie polecenia. Dlaczego
wtedy to ma sens?

Jeśli już jesteś w kuchni, pomyśl też o guzikach na piekarniku albo kuchence
mikrofalowej. Czym jest wciśnięcie przycisku jeśli nie wysłaniem wiadomości do
obiektu, żeby wykonał jakąś akcję?
Dlaczego wtedy to ma sens?

> W każdym razie ja nie znam nikogo takiego.

Być może masz bardzo ograniczone doświadczenia?

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

W C++ konieczne, żeby szablony działały.
Da się zrobić szablony tak, żeby przeciążanie funkcji i operatorów nie było konieczne
(np. w Adzie się da), ale nie sprzyja to czytelności programów.

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

do góry