eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingUwagi odnośnie książki Stroustrupa
Ilość wypowiedzi w tym wątku: 29

  • 1. Data: 2019-01-01 16:15:41
    Temat: Uwagi odnośnie książki Stroustrupa
    Od: g...@g...com

    Wczoraj Tomek Kaczanowski polecił tu książkę do nauki programowania
    spod pióra Stroustrupa pt. "Programowanie. Teoria i praktyka
    z wykorzystaniem C++".

    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.

    Przykładowy rozdział, który można podejrzeć na stronie Helionu,
    a konkretniej rozdział szósty, zatytułowany "Pisanie programu",
    dotyczy "prezentacji procesu myślowego, który ma miejsce
    podczas wytwarzania oprogramowania".

    Stroustrup twierdzi (skądinąd słusznie), że pisanie programu
    należy zacząć od sformułowania probelmu, który program ma rozwiązać.
    Problemem, jaki Stroustrup stawia, jest domniemana niewiedza
    czytelnika, zaś jako rozwiązanie proponuje "program zmuszający
    komputer do wykonywania typowych działań arytmetycznych
    na wyważeniach, które mu podamy".

    Stroustrup nalega również, żeby program działał w "oknie konsoli",
    ponieważ wyjaśniał we wcześniejszych rozdziałach "jak posługiwać się
    strumieniami `cin` i `cout`, a graficzne interfejsy użytkownika (GUI)
    zostaną opisane dopiero w rozdziale 16".

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

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

    Innymi słowy, Stroustrup chce, żebyśmy na początku naszej drogi
    programistycznej nauczyli się w lichy sposób rozwiązywać szereg
    problemów, które nie są ani trochę interesujące z perspektywy
    zastosowania komputera, których lichość będzie nas prześladować
    w przyszłości, i których można by było w ogóle uniknąć.

    Nietrudno się domyślić, skąd bierze się takie przekonanie.
    Twórcy języka C byli jednocześnie autorami systemu operacyjnego
    UNIX. Mieli świadomość, że opracowany przez nich system jest
    kompromisem, którego główną cechą ma być przede wszystkim
    prostota implementacji i przenośność. Stąd też w UNIXie "wszystko
    jest plikiem", zaś pliki to po prostu ciągi bajtów, które
    można odczytywać i zapisywać wywołaniami systemowymi "read"
    i "write". Dotyczy to w takim samym stopniu danych zapisanych
    lokalnie na dysku, jak i urządzeń czy innych komputerów.

    Najbardziej rozpowszechniona forma grupowania bajtów
    polega na oddzielaniu ich znakiem nowej linii. Na tym
    założeniu opiera się większość narzędzi uniksowych, takich
    jak `grep`, `sed` czy `tail`. Niestety, to założenie nie pozwala
    nam tworzyć "złożonych złożoności". Do tego celu służą jednak
    takie pomysły, jak zgrupowany hierarchicznie system plików.

    Używanie tego mechanizmu jest jednak do wielu rzeczy
    niewygodne. Czasem wolimy zapisać złożoną teksturę w pliku
    tekstowym, ponieważ taki plik łatwiej wyświetlić na ekranie,
    przesyłać i edytować.

    Jednak jeśli zdecydujemy się na taki krok, doświadczymy
    pewnych komplikacji:
    - musimy mieć sposób konwersji danych z pliku tekstowego
    do postaci drzewa (parser)
    - dajemy sobie możliwość budowania wadliwych struktur (błędów
    składniowych)

    Pomimo tych niedogodności, taki model dobrze się rozpowszechnił.

    Stroustrup natomiast uznał go za ostateczną prawdę, i wybudował
    mu ołtarz w postaci języka C++.

    Jeśli ktoś poszukuje całościowego modelu alternatywnego względem
    tego z UNIXa, to dobrym przykładem jest środowisko Smalltalka
    (np. Pharo albo Squeak). Stworzenie aplikacji kalkulatora dla takiego
    środowiska jest znacznie przyjemniejszym ćwiczeniem dla początkujących
    osób, niż studiowanie gramatyk BNF (i z funkcjami graficznymi
    nie trzeba czekać "do rozdziału 16").

    Warto też zapoznać się z s-wyrażeniami języka LISP: jest to składnia
    dużo prostsza do parsowania nawet od tego głupiego kalkulatorka,
    któremu Stroustrup poświęca tak dużo miejsca, a jej dodatkową
    zaletą jest to, że jest to lekki i uniwersalny format serializacji,
    którego można używać np. wszędzie tam, gdzie stosuje się XML
    (stanowi uniwersalne rozwiązanie zagadnienia "złożonych złożoności").
    A co najważniejsze, można ten problem parsowania rozwiązać raz
    i dobrze i się nim więcej nie przejmować, a nie wmawiać początkującym,
    że to na tym polega programowanie. (Można też ten problem całkowicie
    zignorować, i od początku skupić się na bardziej interesujących
    zagadnieniach, jak choćby nawet różniczkowanie symboliczne - Stroustrup
    nie konstruuje przecież w swojej książce parsera dla C++a, tylko
    dla wyrażeń arytmetycznych.)

    Czasem zamiast rozwiązywać jakiś problem, lepiej go ominąć.
    Podobnie jak tę książkę.

    Najlepszego wszystkim w nowym roku.


  • 2. Data: 2019-01-02 02:28:37
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: fir <p...@g...com>

    W dniu wtorek, 1 stycznia 2019 16:15:42 UTC+1 użytkownik g...@g...com napisał:
    > Wczoraj Tomek Kaczanowski polecił tu książkę do nauki programowania
    > spod pióra Stroustrupa pt. "Programowanie. Teoria i praktyka
    > z wykorzystaniem C++".
    >
    > 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.
    >
    > Przykładowy rozdział, który można podejrzeć na stronie Helionu,
    > a konkretniej rozdział szósty, zatytułowany "Pisanie programu",
    > dotyczy "prezentacji procesu myślowego, który ma miejsce
    > podczas wytwarzania oprogramowania".
    >
    > Stroustrup twierdzi (skądinąd słusznie), że pisanie programu
    > należy zacząć od sformułowania probelmu, który program ma rozwiązać.
    > Problemem, jaki Stroustrup stawia, jest domniemana niewiedza
    > czytelnika, zaś jako rozwiązanie proponuje "program zmuszający
    > komputer do wykonywania typowych działań arytmetycznych
    > na wyważeniach, które mu podamy".
    >
    > Stroustrup nalega również, żeby program działał w "oknie konsoli",
    > ponieważ wyjaśniał we wcześniejszych rozdziałach "jak posługiwać się
    > strumieniami `cin` i `cout`, a graficzne interfejsy użytkownika (GUI)
    > zostaną opisane dopiero w rozdziale 16".
    >
    > 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".
    >
    > 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).
    >
    > Innymi słowy, Stroustrup chce, żebyśmy na początku naszej drogi
    > programistycznej nauczyli się w lichy sposób rozwiązywać szereg
    > problemów, które nie są ani trochę interesujące z perspektywy
    > zastosowania komputera, których lichość będzie nas prześladować
    > w przyszłości, i których można by było w ogóle uniknąć.
    >
    > Nietrudno się domyślić, skąd bierze się takie przekonanie.
    > Twórcy języka C byli jednocześnie autorami systemu operacyjnego
    > UNIX. Mieli świadomość, że opracowany przez nich system jest
    > kompromisem, którego główną cechą ma być przede wszystkim
    > prostota implementacji i przenośność. Stąd też w UNIXie "wszystko
    > jest plikiem", zaś pliki to po prostu ciągi bajtów, które
    > można odczytywać i zapisywać wywołaniami systemowymi "read"
    > i "write". Dotyczy to w takim samym stopniu danych zapisanych
    > lokalnie na dysku, jak i urządzeń czy innych komputerów.
    >
    > Najbardziej rozpowszechniona forma grupowania bajtów
    > polega na oddzielaniu ich znakiem nowej linii. Na tym
    > założeniu opiera się większość narzędzi uniksowych, takich
    > jak `grep`, `sed` czy `tail`. Niestety, to założenie nie pozwala
    > nam tworzyć "złożonych złożoności". Do tego celu służą jednak
    > takie pomysły, jak zgrupowany hierarchicznie system plików.
    >
    > Używanie tego mechanizmu jest jednak do wielu rzeczy
    > niewygodne. Czasem wolimy zapisać złożoną teksturę w pliku
    > tekstowym, ponieważ taki plik łatwiej wyświetlić na ekranie,
    > przesyłać i edytować.
    >
    > Jednak jeśli zdecydujemy się na taki krok, doświadczymy
    > pewnych komplikacji:
    > - musimy mieć sposób konwersji danych z pliku tekstowego
    > do postaci drzewa (parser)
    > - dajemy sobie możliwość budowania wadliwych struktur (błędów
    > składniowych)
    >
    > Pomimo tych niedogodności, taki model dobrze się rozpowszechnił.
    >
    > Stroustrup natomiast uznał go za ostateczną prawdę, i wybudował
    > mu ołtarz w postaci języka C++.
    >
    > Jeśli ktoś poszukuje całościowego modelu alternatywnego względem
    > tego z UNIXa, to dobrym przykładem jest środowisko Smalltalka
    > (np. Pharo albo Squeak). Stworzenie aplikacji kalkulatora dla takiego
    > środowiska jest znacznie przyjemniejszym ćwiczeniem dla początkujących
    > osób, niż studiowanie gramatyk BNF (i z funkcjami graficznymi
    > nie trzeba czekać "do rozdziału 16").
    >
    > Warto też zapoznać się z s-wyrażeniami języka LISP: jest to składnia
    > dużo prostsza do parsowania nawet od tego głupiego kalkulatorka,
    > któremu Stroustrup poświęca tak dużo miejsca, a jej dodatkową
    > zaletą jest to, że jest to lekki i uniwersalny format serializacji,
    > którego można używać np. wszędzie tam, gdzie stosuje się XML
    > (stanowi uniwersalne rozwiązanie zagadnienia "złożonych złożoności").
    > A co najważniejsze, można ten problem parsowania rozwiązać raz
    > i dobrze i się nim więcej nie przejmować, a nie wmawiać początkującym,
    > że to na tym polega programowanie. (Można też ten problem całkowicie
    > zignorować, i od początku skupić się na bardziej interesujących
    > zagadnieniach, jak choćby nawet różniczkowanie symboliczne - Stroustrup
    > nie konstruuje przecież w swojej książce parsera dla C++a, tylko
    > dla wyrażeń arytmetycznych.)
    >
    > Czasem zamiast rozwiązywać jakiś problem, lepiej go ominąć.
    > Podobnie jak tę książkę.
    >
    > Najlepszego wszystkim w nowym roku.

    jak dla mnie te krytyki c++ itp sa malo
    sensowne lub istotne, (ale tez zarazem
    sie nie umpieram bo nie mam specjalnego zdania na te tematy, malo mnie to obchodzi
    odbieram to jako nieistotne)

    wielokroc chyba juz mowilem jak to widze:
    to jak cos szybko i sprawnie zrobisz zalezy juz bardziej od biblioteki niz od jezyka
    i od jej znajomosci, no i od umiejetnosci klecenia programu...sama jakosc docelowa
    moze zalezec od jezyka/platformy ale to nie ma tez takiego znaczenia bo ew mozna
    przeportowac

    co ma znaczenie pierwszorzedne wobec
    tego? chyba to co stanowi nawieksze problemy i jest realna przeszkoda by zrobic cos
    dobrego

    a co to jest? to jest wlasnie moim zdaniem dobre pytanie (w tym sensie ze odpowiedz
    na nie moglaby duzo dac)

    ja na nie zwykle odpowiadam tak ze sa to
    w moim wypadku
    1) przeszkody psychologiczne (czy tez moze raczej mentalno energetyczne).. moze nie
    tyle ciezko mi sie za cos wziac, (bo wziac sie za cos w kodowaniu jest mi dosyc
    latwo), ale ciezko mi sie zmusic
    by to dlugo robic i sie nie wypalic ..
    a jak sie wypale by jakos w miare szybko do tego wrocic


    2) problemy 'koncepcyjne'

    A]
    - niektore rzeczy sa dosyc latwe do pisania, [wystarczyla by wiac ta energia z punktu
    1 i by sie nie meczyc i by miec ogromna ilosc czasu i sie nie starzec itd itd i mozna
    pisac (chyba bo nawet tego nie jestem pewien)]

    [
    a1) przykldem takiego programu ktory sam sie niemal pisze byl np edytor tekstu jaki
    troche pisalem w zeszlym roku, zasadniczo bralo sie to i pisalo, pozatym
    bezprobloemowo..natrafilem co prawda na pewne problemy zwiazane z tym jak dziala gdi
    do rysowania fontow (chodzilo o to ze
    nie wiem jak zrobic tak by przeplatanie rysowanie fontow na ekranie i rysowań per
    pixel na tym samym ekranie bylo 'naturalnie' wydajne, bo to co znalazlem
    wymagalo blitowania w tą i z prwrotem przy kazdym takim przeplocie wiec w ogolnosci
    by zarznelo program -- nie znalazlem czy da sie to obejsc bo nie chcialo mi sie
    tracic czasu na dlugie czytania -- ale zakladam ze pewni ejest jakis sosob by to
    zadzialalo jak trzeba,
    w najgorszym wypadku musialbym sobie generowac fonty bitmapowe ofscreen tym gdi i
    wtedy rysowac je jak sprity)
    a2) innym przykladem bylo pisanie gry roguelike - tez zasadniczo sie bralo i pisalo..
    nie kojarze jakichs wiekszych koncepcyjnych problemow..
    a3) moglbym podac wiecej taich przykladow ale mi sie nie chce na to tracic czasu naw
    ymienienie tego (... doodam ze chyba nawet pisaie kompilatora poprawionego c trafia
    do tej 'latwej' kategorri.. "sie bierze i sie pisze")

    ]

    B]

    - ale niektore programy do pisania takie nie są..czesc tez byc moze nalezy do takiej
    kategorii ze z poczatku sie bierze i sie pisze a pozniej przechodza w druga kategorie

    ta druga kategoria to co takiego ze "sie bierze ale sie nie pisze" ew "sie nie bierze
    bo sie nie chce (?)"

    mozna by sie zastanowic na czym to polega bo te przypadki mnie conieco przygnebialy
    czy wprowadzaly w jakis miks zlego humoru

    co prawda jest juz nieco pozno jak to pisze i nie wiem czy to jest dobry moment by to
    probowac wymianiac, ale moze w jakims cienkim szkicu

    b1) pewne rzeczy bym ew mogl napisac ale mi sie nie chce tego robic bo widze to jakos
    zbyt malo konkretnie..ew wydaje mi sie ze to za duzo roboty na ktora nie mam
    nastroju..problem jest moze w tym ze wydaje mi sie ze niektore rzeczy moze i daloby
    sie zrobic ale nie ma gwarancji ze to dobrze wyjdzie i mi si enie chce tegio robic i
    zarazem jest to chyba sporo roboty.. troche mi sei nie chce wymieniac co to jest ale
    moze np
    -) powiedzmy ze chce zrobic gre oparta na animacjach, te operacje tzreba rysowac i
    trzeba tez zrobic tai system przejsc miedyz jej roznymi odnogami bo nei chialbym by
    onebyly zbyt kanciaste tylko takie berdziej realistyczne... to niby jest do zrobienia
    ale dla mnie jaos nie nalezy do kategori A tylko wlasnie do B
    (ze wzgledu jedna bardziej na 'duzo roboty brak gwarancji' niz na scisle 'nie wiadomo
    co zrobic')
    -) sa pewne rzeczy ktorych zrobienie tez nie zakrawa na ciezkie do wykoncypowania ale
    wymaga czytania np na msdnie czy gdzies (np o tym przpelataniu fontow, albo o raw
    input do myszy, albo o socketach) a mi sie tego nie che robic
    bo uwazam to za troche malo atrakcyjne, ew o czyms z matematyki jak np kiedys chciaem
    zgrac swoje wyniki z rasteryzacji z wynikami z raytracingu bo wyszlo mi ze to sie
    bedzie lekko rozjeżdzac, ze wzgledy na przyblizenia w perspektywie w rasteryzerze
    (cyba, moge troche nie pamietac) i tego tez mi si eni chcialo robic (i ciagle nie
    chce)... to moze nie jest scisle kategoria B ale troche na nia wchodzi ..kaegoria AB
    powiedzialbym
    b2) sa pewne rzeczy ktorych realnie nie wiem jak zrobic choc wiem ze ludzi to
    rozgryzli, musialbym sie jednak douczyc.
    konkretnie np w zeszlym roku costa dlubalem prosta symulacje z odbijaniem sie kulek
    ale taka ze mogly sie sklejac
    w takie sprezyste dosyc czasteczki..okazalo sie ze oja metoda licznie tego mimo ze z
    grubsza dzial wyjebscie tak jak chcialem scilse nie zachowuje energii - by to zglebic
    musialbym sie porzadniej tej fizyki anuczyc a mi sie nie chce (nie chcodzi o to ze
    nie moglbym tylko ze cenie swoj czas bo czas mojego zycia jest ograniczony) - moze
    ten przypadek wyglada
    w sumie podobnie do tego AB wczesniej wymienionego (typu "zrobilbym ale mi sie nie
    chce czytac") ale tutaj moze mam na mysli troche trudniejsza klase problemow gdzie te
    studia by cos zrobic musialybybyc powiedzmy dluzsze (niz nawet 2 czy 3 tygodnie
    studiowania artylkow w necie)
    b3) bywaja jeszcze gorsze problemy bo w tych wyzej przynajmniej z grubsza wiadomo
    ze jak cos potestuje narobie sie i ew przeczytam kupe googla to cos zrobie (placac za
    to jakims wiekszym kosztem czasowym typu miesiac czy dwa) ale sa problemy bardziej
    mgliste gdzie problem polega chyab na tym ze nie wystarczy czytac jakies papiery na
    dany temat tylko samemmu trzeba cos 'zresearchowac' obadac i wytworzyc takie
    papiery... dla mnie np robenie ai zakrawalo troche o takie cos..
    byuc moze widzialem to zwykle nieco zyt pesymistycznie ale by ai dzialalo jak tzreba
    wydawalo mi sie trzebbylo nawymyslac jakies reguly (czym te postaci maja byc
    ograniczane) pozniej jak maja w ich ramach dzialac i to nie jest cos na co jest
    prosty przepis bo jak sie zrobi poprstu cos co przyjdzie do glowy to toz adziala ale
    spektakularnosc tego bedzie bliska zeru
    jak sie nie wie o czym mowie to moze nie wydaje sie takie ciezkie ale problem jest
    naprawde trudny - to cos takiego jak by ktos powiedzial "napisz dobry maly sceneriusz
    filmu dla hollywood" niby proste ale tak naprawde troche ciezko z tym

    tu sie troche wlasnie chyab gubie z tym wyliczaniem, gdy robis ie trudniej bu tu te
    problemy pewnie mozna podzilic a wiecej roznych przypadkow..no ale wlasnie tosa
    problematyczne kwestie i urwe moze te wylicznie i opisywanie zwlaszcza ze pozno sie
    zrobilo

    generalnie chodzi wlasnie o to ze to sa wlasnie istatnie problemy (zwlaszcza ta
    kategoria pzniejszego B zdaje sie) a nie raczej bzdurne problemiki jaki to jezyk jest
    lepszy, albo straszliwe problemy z debugowaniem i inne malo wazne bzdury



  • 3. Data: 2019-01-02 06:41:18
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: s...@g...com

    Wystarczy spojrzeć na spis treści by stwierdzić, że programowanie grafiki to
    rozdziały 12-16 a nie sam 16. Tym nie mniej nie jest jasne co to za biblioteka
    została zaprezentowana. W każdym razie jest to zgodne z jakąś manierą "z dala od Qt".
    No i dodatek C: Visual Studio...
    Ja tak że dziękuję...
    W moich czasach (20 lat temu) standardem nauki C++ była "Symfonia C++" dr. Jerzego
    Grębosza (fizyka). Obecnie jej nowe wcielenie jest od ponad roku sprzedawane jako
    "Opus Magnum". Aktualizacja obejmuje uwzględnienie standardu C++11. 1696 stron bez
    bibliotek graficznych.


  • 4. Data: 2019-01-02 07:13:44
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: g...@g...com

    W dniu środa, 2 stycznia 2019 02:28:38 UTC+1 użytkownik fir napisał:

    > jak dla mnie te krytyki c++ itp sa malo
    > sensowne lub istotne, (ale tez zarazem
    > sie nie umpieram bo nie mam specjalnego zdania na te tematy, malo mnie to obchodzi
    odbieram to jako nieistotne)

    Ja mam podobnie z Twoimi tematami.
    Piszesz o programach w rodzaju "tworzę swój edytor tekstu", "piszę grę rogue-alike",
    "opracowuję swój własny asembler" - szczerze powiedziawszy, nie są to rzeczy bez
    precedensu.
    Jeżeli masz ochotę się w to bawić, Twoja sprawa, ale tego rodzaju programów istnieje
    już milion czy coś koło tego, i nie wygląda mi na to, żeby te Twoje rozwiązywały
    jakieś rzeczywiste problemy.

    Jeśli cokolwiek, to z rzeczy, które robisz, bardziej interesowałoby mnie to C2.
    Moim zdaniem używane przez nas języki programowania mają kolosalny wpływ na nasze
    myślenie o problemach, zaś perspektywa, którą prezentuje Stroustrup, poniekąd wymusza
    błędne myślenie o problemach, albo rozwiązywanie nie tych problemów, co trzeba.

    Obszar badań, który mnie interesuje, to zwiększanie ekspresywności pracy z komputerem
    - żeby móc łatwo i szybko przechodzić od pomysłów do działających programów.

    Lubię refren tej piosenki:

    https://www.youtube.com/watch?v=hHdvmblt948


  • 5. Data: 2019-01-02 07:40:27
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: g...@g...com

    W dniu środa, 2 stycznia 2019 06:41:19 UTC+1 użytkownik s...@g...com napisał:
    > Wystarczy spojrzeć na spis treści by stwierdzić, że programowanie grafiki to
    rozdziały 12-16 a nie sam 16. Tym nie mniej nie jest jasne co to za biblioteka
    została zaprezentowana. W każdym razie jest to zgodne z jakąś manierą "z dala od Qt".
    No i dodatek C: Visual Studio...
    > Ja tak że dziękuję...
    > W moich czasach (20 lat temu) standardem nauki C++ była "Symfonia C++" dr. Jerzego
    Grębosza (fizyka). Obecnie jej nowe wcielenie jest od ponad roku sprzedawane jako
    "Opus Magnum". Aktualizacja obejmuje uwzględnienie standardu C++11. 1696 stron bez
    bibliotek graficznych.

    Spojrzałem sobie na "próbny" rozdział 30 "Wyrażenia lambda i wysyłanie kodu do innych
    funkcji": https://www.ifj.edu.pl/private/grebosz/Opus_C++11_la
    mbda_fragment.pdf

    Znamienne, że w "Strukturze i Interpretacji Programów Komputerowych" wyrażenia lambda
    pojawiają się już w pierwszym rozdziale, ponieważ funkcje stanowią podstawowy
    mechanizm abstrakcji (i to nie tylko w językach takich jak Scheme czy JavaScript, ale
    również abstrakcji jako takiej, o czym pisałem tutaj:
    https://www.quora.com/What-is-the-difference-between
    -simplification-and-abstraction/answer/Panicz-Godek)

    Rozbawiła mnie też mikro-sekcja zatytułowana "uwaga na martwe referencje".
    Wygląda na to, że starym C++owym zwyczajem wyrażenia lambda są po prostu kolejnym
    mechanizmem do strzelania sobie w stopę.


  • 6. Data: 2019-01-02 08:17:36
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: Tomasz Kaczanowski <k...@p...onet.pl>

    W dniu 2019-01-01 o 16:15, g...@g...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


  • 7. Data: 2019-01-02 10:37:26
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: Maciej Sobczak <s...@g...com>

    > 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


  • 8. Data: 2019-01-02 12:42:32
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: fir <p...@g...com>

    W dniu środa, 2 stycznia 2019 07:13:45 UTC+1 użytkownik g...@g...com napisał:
    > W dniu środa, 2 stycznia 2019 02:28:38 UTC+1 użytkownik fir napisał:
    >
    > > jak dla mnie te krytyki c++ itp sa malo
    > > sensowne lub istotne, (ale tez zarazem
    > > sie nie umpieram bo nie mam specjalnego zdania na te tematy, malo mnie to
    obchodzi odbieram to jako nieistotne)
    >
    > Ja mam podobnie z Twoimi tematami.
    > Piszesz o programach w rodzaju "tworzę swój edytor tekstu", "piszę grę
    rogue-alike", "opracowuję swój własny asembler" - szczerze powiedziawszy, nie są to
    rzeczy bez precedensu.

    lol, roznica nie dotyczy tego kto robi tylko "nieistotnych argumentow" w "dziwnych
    klotniach" ;c

    > Jeżeli masz ochotę się w to bawić, Twoja sprawa, ale tego rodzaju programów
    istnieje już milion czy coś koło tego, i nie wygląda mi na to, żeby te Twoje
    rozwiązywały jakieś rzeczywiste problemy.
    >
    > Jeśli cokolwiek, to z rzeczy, które robisz, bardziej interesowałoby mnie to C2.

    sporo wymyslilem w tym temacie i C2
    przy okazji przemianowalem n "hipermodulowe c"

    te druga nazwa jest z pewnych wzgledow lepsza, mianowicie z tgo ze ja w sumie zawsze
    chcialem robic cos jakby rozwiniecie c trzymajace sie jego glebokiego ducha, [[z
    drugiej strony
    uwazam obecnie ze nie nalezy 'przejmowac' ani naruszac starego c
    (tak jak robia ludzi produkujac nowa wersje czegostam, za duzo tych wersji i upgradow
    w swiecie programowani)
    bo to by powiekszalo wersjacyjny smiernik,]] nazwa hipermodulowe c jakos laczy jedno
    z drugim (tj ze to jest c i ze to jest inne c), nieco lepiej niz C2
    (z nazwa C2 tez sie calkiem nie pozegnalem ale poki co raczej egzystuje ona jako
    nazwa tego co wczesniej okreslalem jako C2)

    o hipermodulowym c narazie nie che mi sie za duzo pisac, ale z grubsza chodzi o to ze
    szitowata objektowosc tutaj w tym jezyku zostala jakby wyparta/zniszczoan przez
    naturalną "encjalnosc" jak w c,
    tj to co w c++ i in jest clasa i obiektem tutaj jest tak naturalne i wbudowane jak
    int i jak importowany modul z drugiej strony

    moduel, czyli binarnie i zrodlowo odzielny kawalek kodu z wlasnymi zmiennymi stanu i
    wlasnymi funkcjami
    jest tu zunifilowany ze strukturą z
    c (modul i struktura jest tym samym, struktura to modul a modul to struktura)
    a to wszystko jest z kolei zunifikowana z typami prostymi jak np int czy float

    module X
    {
    int n;
    void f00() { n++; }
    }


    znaczy to m.in. ze do struktury mozesz dodawac funkcje jak do modulu, z drugiej
    strony mozesz ja jakby z automatu zamienic na odzielna dllke (jak modul),
    z trzeciej strony mozesz to traktowac jak typ prsty (i uzywac jak inta, tj np
    zdefiniowac operatory, albo napisac sobie wlasnego inta, albo np zrobic sobie tablice
    modulow w naturalny sposob)

    X tabx[100]; //tablica stu modoluw X


    roznica miedzy szit klasami jest znaczna chodzi np o to ze widzialnosci miedzy tymi
    modulami masz jak w c tj nie przekazyjesz wskaznikow i nei budujesz jakis
    kretynicznych grafow tylko widzisz to wszystko 'normalnie' tak jak struktury w kodzie

    to jest znaczaca cecha tego jezyka przez to ze te moduly nabraly tych znacznych
    dodatkowych opcji (tj zachowuja sie jak typy wbudowane) zwiekszajacych ich mozliwosci
    uznalem ze nazwa hipermodulowe c jest adekwatna

    ciegle sie tym co nieco zajmuje choc w ostatnim roku mniej, ale i nawet w ostatnim
    roku costam ciekawego bylo

    na przyklad ta opcja do zajmowani sie bledami o ktroej tu psialem byla ciekawa

    int foo(int x, int y)
    {
    if(y==0) error;
    return x/y;
    }

    int main()
    {
    int x = foo(3,0) on_error { printf("err")}

    }
    to jest calkiem porzadne bo duzo mowi o tym jak nalezy podchodzic do bledow w c

    a zupelnie ostatnio pisane byla opcja do definiowania sobie konstrukcji jezyka np ten
    compactowy-for jako cos w stylu


    void deformed_for(block setup;
    block condition;
    block loop_epilogue) { block content; } :
    {
    steup;
    while(condition)
    {
    content;
    loop_epilogue;
    }

    }

    chodzi o to ze mozna tu definiowac po prostu swoje konstrukcje jezyka podobne do
    for(;;) switcha itd -a le to nowy wynalazek i jeszcze nie rpzemsylalem jakie powinny
    byc scisle reguly budowania
    kodow z tych blokow

    inna wazna rzecz to wieksze opracowanie
    resizowalnych tablic do prostej tes skladni typu

    void foo()
    {
    int tab[10];

    tab.size+=10; //tab ma rozmiar 20

    }

    mozna takie tablice robic na stosach (ale jezyk powinien wtedy raczej dostarczac
    wiecej stosow programiscie) lub na reallocu lub na statycznym ramie z rezerwą... w
    kazdym razie taka tabka resizowalna w tej milusiej skladni to jest cos przyjemnego


    > Moim zdaniem używane przez nas języki programowania mają kolosalny wpływ na nasze
    myślenie o problemach, zaś perspektywa, którą prezentuje Stroustrup, poniekąd wymusza
    błędne myślenie o problemach, albo rozwiązywanie nie tych problemów, co trzeba.
    >

    ta persopektywa stroustrupa jest dosyc licha ale to o czym ja mowie to ze nie ma to
    zbytniego znaczenia bo roznic w jezykach to nie sa glowne problemy..wiekszym
    problemem juz chocby niezajmowanie sie glownymi problemami

    > Obszar badań, który mnie interesuje, to zwiększanie ekspresywności pracy z
    komputerem - żeby móc łatwo i szybko przechodzić od pomysłów do działających
    programów.
    >

    to mniej zalezy od jezyka co raczej od bibliotek - ale i to nie jest glownym
    problemem

    > Lubię refren tej piosenki:
    >
    > https://www.youtube.com/watch?v=hHdvmblt948


  • 9. Data: 2019-01-02 12:44:48
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: g...@g...com

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


  • 10. Data: 2019-01-02 13:44:20
    Temat: Re: Uwagi odnośnie książki Stroustrupa
    Od: fir <p...@g...com>

    W dniu środa, 2 stycznia 2019 07:13:45 UTC+1 użytkownik g...@g...com napisał:
    > W dniu środa, 2 stycznia 2019 02:28:38 UTC+1 użytkownik fir napisał:
    >
    > > jak dla mnie te krytyki c++ itp sa malo
    > > sensowne lub istotne, (ale tez zarazem
    > > sie nie umpieram bo nie mam specjalnego zdania na te tematy, malo mnie to
    obchodzi odbieram to jako nieistotne)
    >
    > Ja mam podobnie z Twoimi tematami.
    > Piszesz o programach w rodzaju "tworzę swój edytor tekstu", "piszę grę
    rogue-alike", "opracowuję swój własny asembler" - szczerze powiedziawszy, nie są to
    rzeczy bez precedensu.
    > Jeżeli masz ochotę się w to bawić, Twoja sprawa, ale tego rodzaju programów
    istnieje już milion czy coś koło tego, i nie wygląda mi na to, żeby te Twoje
    rozwiązywały jakieś rzeczywiste problemy.
    >

    szczerze mowiac jest to glupia wypowiedz,
    (pominawszy juz ze nie ma specjalnego zwiazu miedzy pisaniem edytora tekstu a
    wywolywaniu dziwnych wojen z c++ z dziwnymi argumentami, nie mowie nawet ze te
    argumenty nie sa sluszne czesc moze byc jakos tam sluszna ale nie sa one zbyt istotne
    po prostu )
    z tego ze jest duzo edytorow nie wynika ze jak ktos napisze edytor/asembler/roguelike
    to nie moze zrobic w tym edytorze nic nowatorskiego..
    dla mnie akurat te projekty byly nowatorskie (wewnetrznie i zewnetrznie)
    ale to tez gwoli istoty rzeczy nie dotyka sedna istoty najwazniejszych problemow

    istota problemu jest nieststy to co opisalem wczesniej w poscie jako 1 i 2B
    (pisze nieststy bo sa to problemy na ogol odbierane przeze mnie dosyc nieprzyjemne,
    byc moze wlasnie powinienem sobie wypracowac jakies pdescie by uczynic je
    strawniejszymi ale to nie jest lekka sprawa)

strony : [ 1 ] . 2 . 3


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: