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

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

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

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

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

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

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

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

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

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

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

WTF? Dlaczego?!

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

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

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

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

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

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

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

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