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.