Dnia Sat, 17 Sep 2011 17:46:27 +0200, Luke napisał(a):
> 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.

Panowie (i Panie ?) - ale w Basicu tez da się w miare elegancko i
strukturalnie.

Problemy sa dwa:
a) poczatkujacy programisci maja tendencje do "glupich skokow". Cos pisza,
skacza na koniec, wracaja w srodek, kontynuuja. Byc moze przyczynia sie do
tego wlasnie numeracja linii i "spektrumowski edytor".
Kto ma male dziecko - do sprawdzenia, jak to bedzie w Basicu z etykietami i
zwyklym edytorem.

b) tej struktury nie widac .. chyba ze ktos ladne wciecia robi - na
spectrum sie chyba nie dalo.

Pascal tez nie jest bez winy, i tylko smiac sie mozna jak niektorzy
kombinuja zeby np znalezc pierwszy niezerowy element w tablicy (hi hi -
dwuwymiarowej) byleby tylko goto nie uzyc. Tylko smiech trafia w pustke
bo "goto sie nie uzywa i juz"

> 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ć,

eee - a co w tym trudnego ? Rzeklbym ze niemal takie same sa.

> Odpowiednio wczesne uczenie alokacji pamięci

Przeciez w obu jest ?

> i uważania na indeksowanie zmiennych (aby program nie wywalał
> się z niewiadomego powodu)

Ale przeciez to to samo.
Moze troche niechlujnie pisales - ale klient nie placi za program
ktory zamiast robic co ma robic wywala sie z bledem "indeks przekroczony w
linii 1534".
Wiec albo programista jest pewny ze dany algorytm nie przekroczy zakresu,
albo wstawia jawny kod sprawdzajacy i podejmujacy sensowna akcje.
I automatyczne sprawdzanie indeksow sie wtedy wylacza, bo to generuje
nieefektywny kod :-)

Przyznaje ze C mialo sporo miejsc w ktorych latwo bylo sie pomylic.
ANSI C znacznie to poprawilo, a dobry kompilator generowal dodatkowe
ostrzezenia i 99% pomylek eliminowal.

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

C tez nie bylo obiektowe.

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

no nie wiem czy jest jeszcze miejsce na "czyste C", czy trzeba jednak
myslec od poczatku obiektowo.

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

Ale to mozna w metodach i wlasciwosciach omowic :-)

> 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)

Hm, jest straszliwie rozbudowany pod tym wzgledem, a podstawy sa w zasadzie
wszedzie takie same.
No i C++ jest passe, teraz piszemy w C# :-)

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

Bez GUI trudno dzis cokolwiek zrobic i zadowalajacy efekt uzyskac.

I tu jest wlasnie ta roznica miedzy LOGO a C/Basic/Pascal na konsoli.
Dziecku powiesz "narysuj kwadrat", to pomysli i narysuje.

A powiesz "oblicz silnie" .. "tatusiu, a co to jest silnia" :-)

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

Oj, zeby sie nie okazalo odwrotnie. Koledzy w godzine policza to w excelu,
a corka bedzie godzine szukala darmowego C, nie znajdzie, poszuka
alternatyw, sciagne Octave, poswieci pol nocy na czytanie dokumentacji, nie
bedzie zadowolona z mozliwosci ale zacznie cos robic .. a tu niespodzianka,
trzeba jeszcze sukac jakiegos narzedzia do importu, bo dane w plikach xml
:-)

Niestety - domorosly programista ma coraz trudniejsze zycie :-)

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

No coz, jest to nieco inny sposob myslenia od poczatku.
Jak widac - swiat poszedl jednak w obiekty.

J.