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