Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #32197 > unrolled thread

Uwagi odnośnie książki Stroustrupa

Back to article view | Back to pl.comp.programming

Contents

  Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-01 07:15 -0800
    Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-01 17:28 -0800
      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-01 22:13 -0800
        Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-02 03:42 -0800
        Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-02 04:44 -0800
          Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-02 06:55 -0800
            Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-02 07:34 -0800
              Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-02 08:39 -0800
            Re: Uwagi odnośnie książki Stroustrupa fir <profesor.fir@gmail.com> - 2019-01-02 07:59 -0800
            Re: Uwagi odnośnie książki Stroustrupa Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2019-01-03 10:43 +0100
    Re: Uwagi odnośnie książki Stroustrupa szykcech@gmail.com - 2019-01-01 21:41 -0800
      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-01 22:40 -0800
        Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-03 01:14 -0800
          Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-03 07:07 -0800
            Re: Uwagi odnośnie książki Stroustrupa AK <nobody@nowhere.net> - 2019-01-03 17:41 +0100
            Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-03 23:15 -0800
              Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-04 00:53 -0800
                Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-06 22:59 -0800
                  Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-07 01:34 -0800
                    Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-08 00:46 -0800
                      Re: Uwagi odnośnie książki Stroustrupa AK <nobody@nowhere.net> - 2019-01-08 09:51 +0100
                        Re: Uwagi odnośnie książki Stroustrupa AK <nobody@nowhere.net> - 2019-01-08 10:05 +0100
                          Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-08 01:51 -0800
                            Re: Uwagi odnośnie książki Stroustrupa AK <nobody@nowhere.net> - 2019-01-08 13:33 +0100
                      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-08 02:15 -0800
    Re: Uwagi odnośnie książki Stroustrupa Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2019-01-02 08:17 +0100
      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-02 06:25 -0800
    Re: Uwagi odnośnie książki Stroustrupa Maciej Sobczak <see.my.homepage@gmail.com> - 2019-01-02 01:37 -0800
      Re: Uwagi odnośnie książki Stroustrupa godek.maciek@gmail.com - 2019-01-02 03:44 -0800

Page 2 of 2 — ← Prev page 1 [2]

#32283

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

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

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

AK

[toc] | [prev] | [next] | [standalone]

#32284

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

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

AK

[toc] | [prev] | [next] | [standalone]

#32286

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

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

Ale jednak jest.

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#32288

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

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

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

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

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

AK

[toc] | [prev] | [next] | [standalone]

#32287

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

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

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

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

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

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

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#32205

W dniu 2019-01-01 o 16:15, godek.maciek@gmail.com napisał:
> Wczoraj Tomek Kaczanowski polecił tu książkę do nauki programowania
> spod pióra Stroustrupa pt. "Programowanie. Teoria i praktyka
> z wykorzystaniem C++".
[...]
> Każdy, kto uczył się Pythona z tutoriala Guidona van Rossum,
> zapewne pamięta, że jedna z początkowych sekcji nosi tytuł
> "Using Python as calculator". Programiści Pythona raczej
> nie byliby szczególnie zainteresowani problemem dydaktycznym,
> który proponuje Stroustrup, ponieważ wiersz poleceń w Pythonie
> już jest "takim kalkulatorem, tylko lepszym".

Pytanie tylko co z tego. W jednym języku masz przygotowane rzeczy do 
jednych operacje, w innym do innych. W zasadzie po co pisać proste 
programy, skoro większość z nich był już napisany wielokrotnie. A 
jednak. Swojego czasu (pierwsza połowa lat 90), żeby dobrze zrozumieć 
jak wykorzystać polimorfizm analizowałem sobie napisany program 
przykładowy dołączany do jednego z kompilatorów. Znowu - też nie jakieś 
super skomplikowane rzeczy - ot parser funkcji matematycznych, dzięki 
któremu rysowane były wykresy. Nic zaawansowanego, ale dało trochę do 
myślenia i do analizy jak to  działa. Wiele rzeczy pisze się podczas 
nauki nie po to by rozwiązać realny problem, tylko aby na jakimś 
problemie przećwiczyć sposoby rozwiązania. Oczywiście można wymyślić 
jakiś problem nie rozwiązany już na 1000 sposobów, tylko po co? Co to da 
w kontekście dydaktycznym poza trudniejszym opisem problemu?


> Jak możemy się domyślać, Stroustrup proponuje początkującemu
> czytelnikowi raczej ciężką i niewdzięczną drogę: oto bowiem
> zostajemy rzuceni w wir tokenizacji i parsowania (a dodatkowo
> mistrz wymaga od swoich uczniów, żeby pojedyncze wyrażenia mogły się
> rozciągać na wiele linii, żeby początkującemu nie było za łatwo).

i bardzo dobrze moim zdaniem, pokazuje, że proste na początku zadanie, 
może mieć dużo dodatkowych wymagań. Czasami proste rozwiązanie może 
okazać się prostackie i dla mnie nieakceptowalne, jak np kiedyś coś tam 
robiąc w PHP, korzystając z funkcji str_getcsv, okazało się, że nie jest 
ona odporna na różność kodowań. Standard csv nie ma takich ograniczeń, 
natomiast jeśli mamy źle lokale ustawione i niekompatybilne z nim 
zakodowany plik, to nagle funkcja nie potrafi prawidłowo podzielić 
rekordów na pola. Koś poszedł na skróty, właśnie nie przeprowadził 
wystarczająco dobrze procesu rozpoznawania problemu i stworzony został 
moim zdaniem potworek.


-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#32217

W dniu środa, 2 stycznia 2019 08:17:40 UTC+1 użytkownik Tomasz Kaczanowski napisał:

> > Wczoraj Tomek Kaczanowski polecił tu książkę do nauki programowania
> > spod pióra Stroustrupa pt. "Programowanie. Teoria i praktyka
> > z wykorzystaniem C++".
> [...]
> > Każdy, kto uczył się Pythona z tutoriala Guidona van Rossum,
> > zapewne pamięta, że jedna z początkowych sekcji nosi tytuł
> > "Using Python as calculator". Programiści Pythona raczej
> > nie byliby szczególnie zainteresowani problemem dydaktycznym,
> > który proponuje Stroustrup, ponieważ wiersz poleceń w Pythonie
> > już jest "takim kalkulatorem, tylko lepszym".
> 
> Pytanie tylko co z tego. W jednym języku masz przygotowane rzeczy do 
> jednych operacje, w innym do innych.

Czasem rzeczywiście jest tak, że masz je "w języku". Na przykład w Perlu
(czy nawet w JavaScripcie) jest specjalna składnia do pracy z
wyrażeniami regularnymi.
W Pythonie czy PHP wyrażenia regularne są dostępne z funkcji bibliotecznej.
I to podejście wydaje się zwyciężać, bo lepiej się skaluje.

> W zasadzie po co pisać proste 
> programy, skoro większość z nich był już napisany wielokrotnie.

To zależy. Dla nauki, dla treningu, dla zabawy.
Po co rozwiązywać krzyżówki, skoro ktoś je już rozwiązał?

> A jednak. Swojego czasu (pierwsza połowa lat 90), żeby dobrze zrozumieć 
> jak wykorzystać polimorfizm analizowałem sobie napisany program 
> przykładowy dołączany do jednego z kompilatorów. Znowu - też nie jakieś 
> super skomplikowane rzeczy - ot parser funkcji matematycznych, dzięki 
> któremu rysowane były wykresy. Nic zaawansowanego, ale dało trochę do 
> myślenia i do analizy jak to  działa.

No i bardzo dobrze. Programy pisze się między innymi po to,
żeby można je było czytać.

> Wiele rzeczy pisze się podczas 
> nauki nie po to by rozwiązać realny problem, tylko aby na jakimś 
> problemie przećwiczyć sposoby rozwiązania.

W porządku. Ja nie mówię, że ten akurat problem nie ma wartości dydaktycznej.
Mówię, że podejście Stroustrupa jest niedobre.

Przeglądam sobie jeszcze raz ten fragment, a tam widzę takie coś:

case '8': // Za pomocą znaku '8' reprezentujemy liczby.

WTF? Dlaczego?!

> Oczywiście można wymyślić 
> jakiś problem nie rozwiązany już na 1000 sposobów, tylko po co? Co to da 
> w kontekście dydaktycznym poza trudniejszym opisem problemu?

Jakiś czas temu zgłosił się do mnie jakiś student z Czech, żebym mu
pomógł w jakimś projekcie.
Projekt był dość ciekawy. Jego nauczyciel przygotował program, w którym
jakiś ludzik chodził po labiryncie w poszukiwaniu skarbu.
Celem studenta było napisanie programu, który tym ludzikiem posteruje.
To była całkiem fajna zabawa.
Podobnie np. gra "Human Resources Machine", w której układasz z klocków
programy sterujące pnącym się po szczeblach kariery pracownikiem korporacji.
Miłe, przyjemne zadanka.

> > Jak możemy się domyślać, Stroustrup proponuje początkującemu
> > czytelnikowi raczej ciężką i niewdzięczną drogę: oto bowiem
> > zostajemy rzuceni w wir tokenizacji i parsowania (a dodatkowo
> > mistrz wymaga od swoich uczniów, żeby pojedyncze wyrażenia mogły się
> > rozciągać na wiele linii, żeby początkującemu nie było za łatwo).
> 
> i bardzo dobrze moim zdaniem, pokazuje, że proste na początku zadanie, 
> może mieć dużo dodatkowych wymagań.

Tak, i czasem łatwiej przeformułować wymagania tak, żeby były one
w naszym zasięgu. Ale Stroustrup zamiast powiedzieć np.
"obsługa precedensów operatorów arytmetycznych jest trudna,
w związku z czym użyjmy zamiast tego odwrotnej notacji Polskiej"
albo coś w tym rodzaju, brnie w niezbyt interesującą teorię.

> Czasami proste rozwiązanie może 
> okazać się prostackie i dla mnie nieakceptowalne, jak np kiedyś coś tam 
> robiąc w PHP, korzystając z funkcji str_getcsv, okazało się, że nie jest 
> ona odporna na różność kodowań. Standard csv nie ma takich ograniczeń, 
> natomiast jeśli mamy źle lokale ustawione i niekompatybilne z nim 
> zakodowany plik, to nagle funkcja nie potrafi prawidłowo podzielić 
> rekordów na pola. Koś poszedł na skróty, właśnie nie przeprowadził 
> wystarczająco dobrze procesu rozpoznawania problemu i stworzony został 
> moim zdaniem potworek.

Ostatnio mieliśmy aplikację od dużej firmy. Była chyba napisana w C#,
i też trzeba było zmieniać język w systemie operacyjnym, bo jakieś tam
pola gdzieś tam miały przecinki zamiast kropek albo na odwrót.

I ważne moim zdaniem jest pytanie, jak unikać tego rodzaju problemów.

Tyle że nie bardzo wiem, jak ma się to do tego, co napisałem wcześniej.

[toc] | [prev] | [next] | [standalone]

#32209

> Choć swoimi pierwszymi wrażeniami już się zdążyłem podzielić,
> pomyślałem sobie, że nie zaszkodziłoby przedstawić nieco bardziej
> dogłębną analizę moich przekonań dotyczących podejścia, jakie
> Stroustrup w niej reprezentuje.

Problem w tym, że w ogóle nie zrozumiałeś, co Stroustrup prezentuje w tej książce. Naprawdę sądzisz, że to jest ksiażka o pisaniu kalkulatora?
To jest ksiązka o języku programowania i tak jakoś się przyjęło, że do tłumaczenia procesu w praktyce używa się przykładów. Kalkulator jest przykładem, który nie wymaga dodatkowej wiedzy a ujawnia ważną cechę pracy programisty, którą jest odkrywanie problemów, których nie było widać wcześniej. Stąd też ta cała zabawa w parsowanie i wykorzystanie tej okazji do zaprezentowania różnych elementów języka.
Gdyby przykłady były o robieniu animacji, to też być krytykował, że iPhonem można zrobić film łatwiej?

> Każdy, kto uczył się Pythona z tutoriala Guidona van Rossum,
> zapewne pamięta, że jedna z początkowych sekcji nosi tytuł
> "Using Python as calculator". Programiści Pythona raczej
> nie byliby szczególnie zainteresowani problemem dydaktycznym,
> który proponuje Stroustrup, ponieważ wiersz poleceń w Pythonie
> już jest "takim kalkulatorem, tylko lepszym".

I ten interpreter Pythona napisano w, no w czym?
Wyobrażam sobie, że GvR czytał książkę Stroustrupa (naprawdę sobie to wyobrażam) i właśnie na tym polega wartość tej książki.

> Jak możemy się domyślać, Stroustrup proponuje początkującemu
> czytelnikowi raczej ciężką i niewdzięczną drogę: oto bowiem
> zostajemy rzuceni w wir tokenizacji i parsowania

Świetnie. Przyda się to później w prawdziwych programach.

> Czasem zamiast rozwiązywać jakiś problem, lepiej go ominąć.

Problemem podjętym przez książkę Stroustrupa jest nauka języka C++. Zdaje się, że autor nawiązał do tego problemu w tytule książki.
Nie da się rozwiązać tego problemu omijając go.

Sorry, ale mam ogólne wrażenie, że albo masz ograniczoną perspektywę albo próbujesz czymś szpanować. Sęk w tym, że Twoje argumenty są jałowe a dotychczasową krytyką C++ strzelasz w płot.

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

[toc] | [prev] | [next] | [standalone]

#32212

W dniu środa, 2 stycznia 2019 10:37:27 UTC+1 użytkownik Maciej Sobczak napisał:
> > Choć swoimi pierwszymi wrażeniami już się zdążyłem podzielić,
> > pomyślałem sobie, że nie zaszkodziłoby przedstawić nieco bardziej
> > dogłębną analizę moich przekonań dotyczących podejścia, jakie
> > Stroustrup w niej reprezentuje.
> 
> Problem w tym, że w ogóle nie zrozumiałeś, co Stroustrup prezentuje w tej książce. Naprawdę sądzisz, że to jest ksiażka o pisaniu kalkulatora?
> To jest ksiązka o języku programowania

Zajrzałeś w ogóle do tej książki przed napisaniem swojej odpowiedzi?
Czy postanowiłeś napisać "coś" w myśl zasady "nie znam się, to się
wypowiem", bo Ci się coś wydawało?

To jest książka o programowaniu, a nie o języku. Tak przynajmniej
deklaruje jej autor.

> i tak jakoś się przyjęło, że do tłumaczenia procesu w praktyce używa się przykładów. Kalkulator jest przykładem, który nie wymaga dodatkowej wiedzy a ujawnia ważną cechę pracy programisty, którą jest odkrywanie problemów, których nie było widać wcześniej. Stąd też ta cała zabawa w parsowanie i wykorzystanie tej okazji do zaprezentowania różnych elementów języka.
> Gdyby przykłady były o robieniu animacji, to też być krytykował, że iPhonem można zrobić film łatwiej?

Nie rozumiem tego koślawego porównania.

> > Każdy, kto uczył się Pythona z tutoriala Guidona van Rossum,
> > zapewne pamięta, że jedna z początkowych sekcji nosi tytuł
> > "Using Python as calculator". Programiści Pythona raczej
> > nie byliby szczególnie zainteresowani problemem dydaktycznym,
> > który proponuje Stroustrup, ponieważ wiersz poleceń w Pythonie
> > już jest "takim kalkulatorem, tylko lepszym".
> 
> I ten interpreter Pythona napisano w, no w czym?

W C.

> Wyobrażam sobie, że GvR czytał książkę Stroustrupa (naprawdę sobie to wyobrażam) i właśnie na tym polega wartość tej książki.

Jeżeli wartość książki polega dla Ciebie na tym, że coś sobie wyobrażasz,
to jest to Twoja sprawa. Dla mnie na tym polega np. wartość "Stu lat
samotności" Marqueza, ale od książki do programowania oczekuję nieco
innych walorów.

Książka miała swoje pierwsze wydanie w roku 2008, a drugie pochodzi
z 2014. Pierwsza wersja Pythona powsała w 1991 roku. Musisz zatem
jeszcze wpleść do swojej opowieści wehikuł czasu.

> > Jak możemy się domyślać, Stroustrup proponuje początkującemu
> > czytelnikowi raczej ciężką i niewdzięczną drogę: oto bowiem
> > zostajemy rzuceni w wir tokenizacji i parsowania
> 
> Świetnie. Przyda się to później w prawdziwych programach.

Jeżeli ktoś chce tworzyć języki programowania, to są do tego lepsze
narzędzia i lepsze książki (choćby "Essentials of Programming Languages"
Friedmana i Wanda).
Ja w "prawdziwych programach" tworzę interfejsy oparte na funkcji
getline albo readline parsowanych scanfem, a jak coś się źle
sparsuje, po prostu wypisuję komunikat, że się źle sparsowało.
Jest proste i działa.
A jak chcę mieć pełny język programowania, to biorę np. Luę.

> > Czasem zamiast rozwiązywać jakiś problem, lepiej go ominąć.
> 
> Problemem podjętym przez książkę Stroustrupa jest nauka języka C++. Zdaje się, że autor nawiązał do tego problemu w tytule książki.
> Nie da się rozwiązać tego problemu omijając go.

Postawionym problemem jest nauka programowania.
C++ jest tylko narzędziem. Nawet Stroustrup to przyznaje.

> Sorry, ale mam ogólne wrażenie, że albo masz ograniczoną perspektywę albo próbujesz czymś szpanować.

Ograniczoną perspektywę? Powiedz coś więcej.
"próbuję czymś szpanować"? Niby czym?

> Sęk w tym, że Twoje argumenty są jałowe

Przedstawiam swoją percepcję i swoją ocenę.
Nie musisz się z nią zgadzać.

Ja z kolei mam wrażenie, że czepiasz się mnie głównie po to,
żeby się czepiać, i że z Twojego czepiania wynikają wyłącznie
bezowocne dyskusje.

> a dotychczasową krytyką C++ strzelasz w płot.

Raczej rzucam grochem o ścianę.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | pl.comp.programming

csiph-web