> Może do końca nie jest to zgodne z zakresem tematycznym tego forum ale liczę na
> życzliwe podpowiedzi.

Każdy odpowie inaczej, ja też dorzucę swoje trzy grosze.

Nie wiem czy 8 lat to nie jest za wcześnie. Ja zacząłem programować
gdzieś tak w wieku 10-11 lat. Zaczynałem od BASIC-a na Spectrum i Atari.
Przy czym BASIC na spectrum był teoretyczny (programy pisałem na kartce)
ze względu na brak dostępu do sprzętu.

Następnie po kilku latach po przesiadce na peceta był Pascal. To
wymagało całkowitego przeprogramowania myślenia na strukturalne
konstruowanie algorytmów, zdziwienie że nie ma numerowanych linii i da
się bez goto. W zasadzie w tym wieku (miałem z 15 lat) można się szybko
przestawić i BASIC mi krzywdy nie zrobił, a dodatkowo znam zalety
programowania strukturalnego.

Natomiast uważam za swój największy błąd zajmowanie się Pascalem zamiast
C. Po przyjęciu nawyków pascalowych przejście do C jest niesamowicie
trudne i w zasadzie nigdy mi się w pełni nie udało tego zrobić, bo C
zająłem się już znacznie później. Odpowiednio wczesne uczenie alokacji
pamięci i uważania na indeksowanie zmiennych (aby program nie wywalał
się z niewiadomego powodu), odpowiednio wczesne zwracanie uwagi na pewne
galimatiasy konstrukcyjne pozwoliłoby mi na kodowanie w C "bez
zastanowienia", jednak tego etapu nigdy nie osiągnąłem, gdyż C uczyłem
się w wieku, kiedy umysł nie chłonie wszystkiego i wiele rzeczy się
momentalnie zapomina, a potem godzinę szuka błędu typu wyjście za
tablicę o jeden rekord. Dlatego byłem zmuszony po wejściu windowsa
przejść na Delphi zamiast jakiegoś C++ i to wspominam ze smutkiem. Tutaj
nauczyłem się dopiero myślenia obiektowego (bo Delphi jest obiektowe, a
Pascal nie był) na tyle, na ile musiałem. Potem miałem okres skutecznego
programowania w czystym C, ale to wymagało częstego sięgania do książek,
gdyż zapominałem pewne sprawy bardzo szybko.

Co ja mogę doradzić?

1. Zacznij od nauki Logo. Niech córka spróbuje pisać proste programy
sterujące żółwiem, potem może wprowadzać bardziej skomplikowane
elementy, pętle, instrukcje warunkowe (rysowanie jakichś wielkich
ażurowych wzorków). Trzeba zachęcić do zabawy w eksperymentowanie - co
będzie gdy zmienię tę linię w taki sposób i dlaczego?

2. Przejdźcie potem na czyste C i realizujcie np. książkę "Algorytmy" z
Helionu. Niech to będzie czyste C, nieobiektowe, z samym stdin i stdout.
Tak, żeby wiedzieć co to są pętle for, do-while, repeat-until, co to
jest funkcja, jak grupować kawałki kodu w funkcje, i tak dalej. Do tego
np. rekurencja.

3. Jak czyste C opanujecie dość dobrze, lecimy C++ (uważam i będę
uważał, że od tego języka trzeba się zacząć uczyć programowania
obiektowego). Też na stdin/stdout. Realizujemy myślenie obiektowe, czyli
konstruowanie obiektów, dziedziczenie.

4. Potem można robić GUI i nauczyć się odniesienia obiektowości do
elementów tegoż GUI.

Jeśli córka to zrealizuje (ale to kwestia lat), to nie będzie miała
żadnego problemu z przejściem na dowolny język programowania, bo
elementy, schematy i konstrukcje są w zasadzie identyczne, a zmienia się
tylko składnia i detale. Natomiast to, że opanuje C/C++ z dobrym
zrozumieniem granicy między nimi będzie zaletą i atutem, bo wszystkie
nowsze języki są łatwiejsze i myśleć tam trzeba mniej. Jak na studiach
każą jej przeliczyć 1500 wyników badań w taki sam sposób, to napisze
sobie stronę kodu w R albo Octave i zrobi obliczenia w 15 minut idąc
potem do koleżanki, a inni studenci będą 5 nocy obklikiwać je w mozolnie
zrobionych arkuszach. Jak trzeba będzie przekonwertować 1500 zdjęć, to
napisze sobie skrypt shellowy do imagemagicka, zamiast się zastanawiać
nad makrami albo ręcznie przerabiać każde. Do takich przykładowych
ułatwień życia ma służyć szaremu człowiekowi umiejętność programowania.

Nigdy też nie podzielałem i nie podzielam opinii, że należy się uczyć
programowania od programowania obiektowego, co spotyka się w niektórych
książkach. Znam osoby, które tak zrobiły i mają wielkie problemy z
zakodowaniem pewnych rzeczy (generalnie wszystko robiłyby obiektowo).



Luke