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.

do góry

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

do góry

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.

do góry

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

do góry

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

do góry

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

do góry

> 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

do góry

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

do góry

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

do góry

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)

do góry