On Jul 12, 7:01 pm, Jacek <a...@o...pl> wrote:
> Dnia Thu, 12 Jul 2012 08:36:09 -0700 (PDT), Andrzej Jarzabek napisał(a):
>
> > On Jul 12, 3:39 pm, Jacek <a...@o...pl> wrote:
>
> >> To może kolega odniósłby się do nauki elementów, które podałem?
> >> Dlaczego nauka programowania dziecka w wieku 6 lat ma mieć wyższy
> >> priorytet, aniżeli nauka połowu dorsza bałtyckiego metodą Redrigera?
>
> > Nie mam pojęcia co to jest metoda Redrigera, ale wydaje mi się, że z
> > dorszem jest taki problem, że są limity odłowów i obecni rybacy
> > strasznie narzekają, że  ciężko wyżyć. Z tego powodu wydaje się, że
> > nakłanianie jeszcze kogokolwiek do kariery przy połowach dorszy wydaje
> > się głupim pomsyłem.
>
> > Nie mówiąc już o takim szczególe, że kazanie przedszkolakom pracować
> > przy (jak zgaduję) jakimś ciężkim sprzęcie na statku na morzu nie jest
> > chyba zbyt bezpieczne?
>
> Nie zdziwiła Ciebie wielka rozbieżnośc miedzy elementami, które podałem?

Głupi przykład to głupi przykład.

> Palnąłem sobie tego Redigera, jak haft Riszelie.
> Zamiast odnosić się do dorszy, to może odnieś sie do koronek?
> To nie jest rpaca cieżka, nic cieższa od programowania.

Nie znam się na tym również kompletnie. Czy przypadkiem do haftowania
nie używa się igieł?

> A może... czy nie lepiej nauczyć sześciolatków robienia sobie śniadania
> bardziej, aniżeli deklarowania zmiennych?

Z zasady nie jestem przeciwny, ale wyobrażam sobie, że może być kilka
problemów: noże, sanepid, logistyka...

do góry

W dniu 2012-07-11 20:58, PK pisze:
> Logo jest chyba najlepszym językiem do nauki programowania dzieci.

Napisałem Logomocja nie Logo. To teoretycznie jest takie Logo na
sterydach, ale po przyjrzeniu się:
- Do podręcznika dołączona jest wersja demo, w której nie da się zapisać
prac (!)
- Rozszerzenia obiektowe to chyba ich własna twórczość, nie wiem, w
każdym razie ja tego nie trawię, dziecko polegnie na bank
- IDE powiedzmy ujdzie, chociaż z minionej epoki, ale sam edytor kodu to
rozpacz
- Nauka Logo to nauka grafiki żółwia, dzieci przy tym ziewały nawet za
czasów ZX Spectrum
- "Tato, ale jak w tym czymś napisać grę?"

Szczerze powiedziawszy myślałem nad tym i mam problem, bo nie wiem, co
bym dziecku polecił na pierwszy ogień. Oglądałem Small Basic. Jest
prosty i ładny, ale jest zbyt prostacki i niekonsekwentny (wbudowane
funkcje są obiektowe, ale sam język nawet nie ma ani funkcji tylko
procedury, o parametrach nie wspominając). Mogli chociaż oprzeć się o
okrojony C#. Poza tym do edukacji DZISIAJ, skoro już proponuje się
klepanie kodu, a nie składanie funkcjonalnych klocków, to nie wystarczy
kolorowanie składni, IDE musi prowadzić za rączkę.

artur

do góry

On 2012-07-13, Artur Muszyński <a...@u...wytnijto.com.pl> wrote:
> - Nauka Logo to nauka grafiki żółwia, dzieci przy tym ziewały nawet za
> czasów ZX Spectrum

Ja nie ziewałem. Logo wyrabia sporo niezłych nawyków - np. posługiwania
się funkcjami, co nie jest takie oczywiste dla wielu osób w gimnazjum
Później zresztą też.
Pamiętaj, że większość dzieci ma generalnie wstręt do programowania.
I to nie wina Logo - gwarantuję Ci, że "rysowanie żółwiem" poprawia tę
sytuację, a nie ją pogarsza.

Poza tym w końcu to tylko język. W tych zajęciach przyciągły mnie
bardziej problemy, które naprawdę bywały niełatwe. A język był
prosty i przyjazny, a wyniki są przede wszystkim graficzne -
to zachęca nastolatków bardziej niż wyskakująca z programu liczba.
Skup się na interesujących problemach dla dziecka. Język ma go po
prostu nie zniechęcać.

Ja na zajęciach z Logomocji nie wybrzydzałem, choć równolegle w domu
klepałem już całkiem nieźle w C++, który jest totalnym przeciwieństwem.

Zresztą co tu kryć. Piszę już w C++ 12 lat i nigdy (słowo daję) nie
napisałem programu wychodzącego poza terminal. Akurat jutro to się
może zmienić, ale 12 lat to prawie połowa mojego życia :).

> funkcje są obiektowe, ale sam język nawet nie ma ani funkcji tylko
> procedury, o parametrach nie wspominając). Mogli chociaż oprzeć się o
> okrojony C#. Poza tym do edukacji DZISIAJ, skoro już proponuje się
> klepanie kodu, a nie składanie funkcjonalnych klocków, to nie wystarczy
> kolorowanie składni, IDE musi prowadzić za rączkę.

Zależy czegoś chciałbyś nauczyć (tzn. jakich umiejętności).
Gdybym ja miał dziecko, to kierowałbym go na podstawowe technologie web,
czyli HTML(5)+JS+CSS.
1) Pewnie najłatwiej będzie na tym zarobić,
2) JS jest uniwersalny i można się nauczyć naprawdę sporo, a zestaw
wyrabia dobre nawyki (porządek w kodzie).
3) Wynik jest graficzny, czyli bardziej oddziaływuje na umysł dziecka.
Poza tym jest to bardzo praktyczna wiedza i łatwo znaleźć zastosowanie.

Tworzenie stron jest w programie gimnazjum/szkół średnich, ale robione
jest najczęściej źle - zły typ stron, źle uczone języki, archaiczne
standardy.

Z całą pewnością odradzam Pythona, w którym piszę od roku i im bardziej
znam, tym bardziej cieszę się, że zaczynałem od C++.

Odradzam także C++ na korzyść Java/C#. Tu także dylemat - Java bardziej
praktyczna i powszechna, ale nigdy w życiu nie pisało mi się przyjemniej
niż w Visual C#.

pozdrawiam,
PK

do góry

Użytkownik "PK" <k...@n...pl> napisał:

> Z całą pewnością odradzam Pythona, w którym piszę od roku i im bardziej
> znam, tym bardziej cieszę się, że zaczynałem od C++.

A ja dokladnie odwrotnie.
Zdecydowanie polecam Pythona.
Python jest bardzo dobrym jezykiem rowniez (a moze przede wszystkim?) do nauki.
Kiedys nawet byla taka inicjatywa:
http://www.python.org/doc/essays/cp4e.html

PS: Mialem wiecej "szczescia".
Nie zaczynalem od C++ (mimo, ze w nim juz pisze ok 24lat).

> przyjemniej niż w Visual C#.

Tu sie zgadzam. Tyle tylko, ze nie do nauki.

AK

do góry

On 2012-07-14, AK <n...@n...com> wrote:
> A ja dokladnie odwrotnie.
> Zdecydowanie polecam Pythona.

Problem z Pythonem jest taki, że ma zbyt wygodne biblioteki:).
To bardzo rozleniwia i ludzie odzwyczająją się od samodzielnego myślenia
o algorytmach.

Rozmowa z "pythoniarzem" zaczyna wyglądać tak:
"To jak by Pan posortował tę listę?"
"W Pythonie x.sorted()"
"A bez tej metody?"
"Ale jak to? Przecież ona jest zawsze dostępna!"

I 3 minuty później okazuje się, że człowiek nawet bardzo nie wie, na
czym polega sortowanie i że istnieją różne podejścia.

Nie mniej w pisaniu aplikacji użytkowych Python jest świetny i nie
sprawia żadnego problemu osobie z pewnym doświadczeniem. Nie wiem
jakie wrażenie mają osoby zaczynające programowanie od tego języka.

> PS: Mialem wiecej "szczescia".
> Nie zaczynalem od C++ (mimo, ze w nim juz pisze ok 24lat).

Ależ ja jestem bardzo wdzięczny losowi za tego C++. Zajmuję się
obliczeniami i symulacjami, więc gdybym go nie znał, to musiałbym
się nauczyć. I o ile przejście z C++ na Pythona jest banalne, to
słyszę od znajomych, że w drugą stronę jest znacznie gorzej.

pozdrawiam,
PK

do góry

On 2012-07-14, PK <k...@n...pl> wrote:
> "To jak by Pan posortował tę listę?"
> "W Pythonie x.sorted()"

No właśnie widać jak często tego używam :D

Oczywiście x.sort() i sorted(x) :)

pozdrawiam,
PK

do góry

Dnia 14 Jul 2012 12:03:50 GMT, PK napisał(a):
> Problem z Pythonem jest taki, że ma zbyt wygodne biblioteki:).
> To bardzo rozleniwia i ludzie odzwyczająją się od samodzielnego myślenia
> o algorytmach.
[...]
> I 3 minuty później okazuje się, że człowiek nawet bardzo nie wie, na
> czym polega sortowanie i że istnieją różne podejścia.

No tak, plusy dodatnie, plusy ujemne.
Jasne, podstawy trzeba znać. Nie ma zmiłuj się.
Z drugiej strony, widziałem już tyle kodu piszącego podstawowe algorytmy
(włącznie z samodzielną obsługą listy dwukierunkowej),
że cieszę się prawie za każdym razem, gdy ktoś
wpadnie na pomysł "hej, a może to już ktoś napisał? :-)

Pozdrawiam
Waldek

do góry

Dnia Sat, 14 Jul 2012 21:52:02 +0200, Waldek M. napisal:

> Dnia 14 Jul 2012 12:03:50 GMT, PK napisał(a):
>> Problem z Pythonem jest taki, że ma zbyt wygodne biblioteki:).
>> To bardzo rozleniwia i ludzie odzwyczająją się od samodzielnego
>> myślenia o algorytmach.
> [...]
>> I 3 minuty później okazuje się, że człowiek nawet bardzo nie wie, na
>> czym polega sortowanie i że istnieją różne podejścia.
>
> No tak, plusy dodatnie, plusy ujemne.
> Jasne, podstawy trzeba znać. Nie ma zmiłuj się.

Była mowa o sortowaniu. Czy aby na pewno nie da się żyć bez znajomości
quick sorta? Ile razy w życiu trzeba algorytm sortowania napisać
samemu? Szczerze mówiąc, mi się jeszcze _nigdy_ nie zdarzyło. To
samo mogę powiedzieć o wielu innych algorytmach, znam ich właściwości
i używam, nie muszę nawet wiedzieć jak działają i do głowy by mi
nie przyszło żeby przepisywać na nowo coś, co zawsze po prostu jest.

Ciekawość i chęć poznania świata to zupełnie inny temat, ale
dlaczego akurat quick sort?

Edek

do góry

On 2012-07-15, Edek Pienkowski <e...@g...com> wrote:
> Była mowa o sortowaniu. Czy aby na pewno nie da się żyć bez znajomości
> quick sorta? Ile razy w życiu trzeba algorytm sortowania napisać

W większości rzeczywistych problemów oczywiście jest to obojętne.
Ale sporo zależy od sytuacji. Np. dla mnie sortowanie jest często
niezłym wyzwaniem i wymaga chwili koncentracji. Każdy programista może
się znaleźć w takiej sytuacji, więc warto znać nie tyle same algorytmy,
co ich charakterystykę - wiedzieć jakiego użyć w danym problemie. Po kod
zawsze można zerknąć do jakiejś publikacji lub po prostu na wiki :).

Quicksort jest dobrym przykładem, bo ma słaby wariant pesymistyczny
O(n^2). To dyskwalifikuje go w wielu zastosowaniach. Poza tym jest
niestabilny.

Akurat w przypadku Pythona sytuacja jest niezła, bo zastosowano
świetnego Timsorta, który ma tylko jedną istotną wadę - "ramożerność".
Ja zależnie od sytuacji wybieram Timsort lub insertion sort
(2 skrajnie różne algorytmy, dobrze się uzupełniają).

Quicksorta napisałem kilka razy w życiu, bo IMO nadaje się tylko do
testowania - wtedy korzystam po prostu z tego, co jest w bibliotekach,
bo zazwyczaj jest lepsze :).

pozdrawiam,
PK

do góry

Dnia Sun, 15 Jul 2012 08:47:54 +0000, PK napisal:

> On 2012-07-15, Edek Pienkowski <e...@g...com> wrote:
>> Była mowa o sortowaniu. Czy aby na pewno nie da się żyć bez znajomości
>> quick sorta? Ile razy w życiu trzeba algorytm sortowania napisać
[...]
>
> Quicksort jest dobrym przykładem, bo ma słaby wariant pesymistyczny
> O(n^2). To dyskwalifikuje go w wielu zastosowaniach. Poza tym jest
> niestabilny.

W to akurat nie wątpię, że quicksort dobrym przykładem jest, tylko
jakoś mi umknęło, czego konkretnie miałby być podstawą.

>
> Akurat w przypadku Pythona sytuacja jest niezła, bo zastosowano
> świetnego Timsorta, który ma tylko jedną istotną wadę - "ramożerność".
> Ja zależnie od sytuacji wybieram Timsort lub insertion sort
> (2 skrajnie różne algorytmy, dobrze się uzupełniają).

Czy używa tego algorytmu czy innego, tak na codzień albo nie
zwracam uwagi bo nie muszę, albo kiedy muszę to czytam opis,
bo nigdy nie pamiętam, która biblioteka ma którą wersję,
i czasem muszę też sprawdzić jak się konkretnie metoda nazywa.

Zazwyczaj jestem świadomy sytuacji, kiedy powinienem się na tym
pochylić, a jak się pomylę to profiler szybko mnie naprostuje;
stabilność to osobna cecha, jak o niej nie myślę to zazwyczaj
nie ma ku temu powodu.

> Quicksorta napisałem kilka razy w życiu, bo IMO nadaje się tylko do
> testowania - wtedy korzystam po prostu z tego, co jest w bibliotekach,
> bo zazwyczaj jest lepsze :).

Tu jest cała śmieszność sytuacji: kazano kiedyś w ramach testu
porządnym programistom napisać, już nie pamiętam, chyba binary
search w pół godziny, ale na kartce, bez testów.
Poprawną odpowiedź wypluło z 10% testowanych, reszta w czymś się
sypnęła, przy czym 100% twierdziło, że ma algorytm w małym
palcu, bo to takie oczywiste. Najczęściej któryś warunek
brzegowy nie był poprawnie uwzględniony.

Przyznam się, że u mnie z podstawowych algorytmów rb-tree i
właśnie quicksort mają od X lat status "kiedyś poświęcę
te 10 minut". Zawsze mogę powiedzieć że to wina prowadzących
zajęcia, co najwyżej wspomnieli o rb-tree.

Edek

do góry