W dniu 2011-03-29 22:15, Grzegorz Krukowski pisze:
> On Tue, 29 Mar 2011 14:40:43 -0500, A.L.<l...@a...com> wrote:
>
>> No i znow wracamy do syskusji "czy Pascal jest dobrym jezykiem do
>> nauczania"
>
> Wracając do tej dyskusji
>
>> OO nie jest paradygmatem UNIWERSALNYM, nei wszystko jest obiektem, nie
>> wszystko daje sie naturalnie odwzorowac jako hierarchia obiektow. Sa
>> inne paradygmaty, na przykald "logic programming" ktore sie nijak do
>> OO nie ma, a problemy ktore sie tam rozwiazuje nijak sie nie maja do
>> OO.
>>
>> Poza tym, mowa jest o kursach dla POCZATKUJACYCH. Poczatkujacy musi
>> umiec napisac algorytm, a nie "grupowac funkcjonalnosc" w Koncu OO
>> siedzi na programowaniu imperatywnym - aby napisac wnetrze metody
>> trzeba wiedziec jak sie pisze zwyczajne, nie obiektowe programy.
>> Wciskanie poczaktujacym OO na poczatek to tak jak, pardon, konsumpcja
>> jablka odbytem
>>
>> Poza tym, byla mowe o MODULARNOSCI. Wszyscy programisci OO spod znaku
>> C++ i pochodnych o modularnosci nie maja zielonego pojecia. Wiec jak
>> najbardziej tzreba studentow tego uczyc, i to jak najlepiej z dala od
>> OO.

Wszyscy "ortodoksyjni" 8-) Czyli trochę z klapkami na oczach.

> warto również zauważyć, że dzięki modułom Pascalowym można bardzo
> ładnie pokazać przejście od programowania strukturalnego, poprzez
> modularyzację aż do konceptu programowania obiektowego.

Właśnie zdałem sobie sprawę, że tę drogę przechodziłem nawet od jeszcze
prostszych elementów - ciągu przetwarzanych instrukcji w BASCICu
i asemblerze. Strukturalizacja (danych i programu) to już był pierwszy,
ważny krok. Nb w Pascalu właśnie 8-)

> Możliwe jest
> bowiem pokazanie, że programowanie strukturalne wraz z modularyzacją
> dają efekty takie jak podejście obiektowe. I to wszystko w sposób
> jasny i uporządkowany, co ma niebagatelne znaczenie w procesie
> dydaktycznym.

Tak naprawdę to wszystko sprowadza się do stanu, sposobu jego
reprezentowania i modyfikacji lub (komplementarnie) przetwarzania
danych przez funkcje. Tego warto nauczyć jak najprostszymi narzędziami.

Obiekty dość dobrze nadają się do reprezentowania sporej części
problemów. Ale uczenie w ten sposób np. rekurencji to trochę jak nauka
jazdy od razu na ciężarówce z przyczepą. Stąd pomysł przesunięcia
nauczania OOP "na później" wygląda dla mnie sensownie.

--
Paweł Kierski
n...@p...net

do góry

Szyk <s...@o...pl> wrote:
> Jednym słowem to muszą być świry!!!
> Bo oczywiste jest, że programowanie obiektowe odzwierciedla naturalne i
> intuicyjne metody radzenia sobie ludzi ze złożonością otaczającego
> świata. Ludzie po prostu grupują sobie funkcjonalności i atrybuty w
... taa, tylko kompilator nie jest w stanie potem zrobic z tego
wlasciwego kodu;-) Zwlaszcza takiego ktory mozna urownoleglic. IMHO,
to tropche tak jak z gadaniem do komputera w jezyku naturalnym, dla ludzi
to naturalne ale komputery nie lubia niejednoznacznosci. Widzisz analogie?;-)
Z powazaniem
Adam Przybyla

do góry

On 29 Mar, 18:58, A.L. <l...@a...com> wrote:

> jeden z najlepszych amerykanskich uniwersytetow, Carnegie-Mellon
> oglosil ze pzrestaje uczyc programwoania obiektowego na wstepnych
> kursach programwoania

Nie przestaje uczyć, tylko usuwa z wymaganego zbioru i to tylko z
"introductory course". Uczy nadal, co sam nawet zacytowałeś.

Poza tym chyba trochę się ktoś rozpędził w interpretacjach. Wywalenie
OO bo jest niemodularne (albo raczej: nie mają związku z
modularnością) to debilizm. To nie OO jest niemodularne, tylko pewne
jego realizacje takie są. W szczególności Java, C++ też. Samo OO nic
do modularności nie ma.

Sam w innym poście napisałeś, że są języki, w których pojęcia "klasy"
i "modułu" są rozdzielone (chociaż nie do końca są ortogonalne). W
takim razie, zamiast wywalać OO jako cały paradygmat i w ten sposób
wylewać dziecko z kąpielą należało raczej zmienić język na taki, w
którym OO i modularność ze sobą nie kolidują.

Czyli chaos. Nie przejmowałbym się tym i pewnie to chwilowa anomalia.

> "Object-oriented programming is eliminated entirely from the
> introductory curriculum,

Przecież "introductory curriculum" to nie całe studia.

Tłumaczenie: studenci i tak nauczą się wszystkiego, tylko w innej
kolejności.
Czyli proszę się rozejść, nie ma na co patrzeć.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Wed, 30 Mar 2011 04:45:30 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>Sam w innym poście napisałeś, że są języki, w których pojęcia "klasy"
>i "modułu" są rozdzielone (chociaż nie do końca są ortogonalne). W
>takim razie, zamiast wywalać OO jako cały paradygmat i w ten sposób
>wylewać dziecko z kąpielą należało raczej zmienić język na taki, w
>którym OO i modularność ze sobą nie kolidują.

Na przyklad?... Jakie?... Nie pytam "w ogolnosci" a w kontekscie
nauczania.

A.L.

P.S. A tak na marginesie, to jeszcze raz sie zgodze z koncepcja ze OO
nie jest tematem na POCZATKOWE nauczanie

do góry

W dniu 2011-03-30 13:45, Maciej Sobczak pisze:
[...]
> Tłumaczenie: studenci i tak nauczą się wszystkiego, tylko w innej
> kolejności.
> Czyli proszę się rozejść, nie ma na co patrzeć.

Właśnie chyba o kolejność idzie. Jak kogoś masz nauczyć kompletnych
podstaw, to tłumaczenie mu, że mnożenie to wysłanie komunikatu multiply
z parametrem do obiektu klasy int, to jednak overkill 8-)

--
Paweł Kierski
n...@p...net

do góry

On Wed, 30 Mar 2011 04:45:30 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>Tłumaczenie: studenci i tak nauczą się wszystkiego, tylko w innej
>kolejności.

Niekoniecznie. Cytuje:

" A proposed new course on object-oriented design
methodology will be offered at the sophomore level for those students
who wish to study this topic."

O ie jest traktowane jako "swiety obowiazek" a jako rzecz opcjonalna

A.L.

do góry

W dniu 29.03.2011 22:15, Grzegorz Krukowski pisze:
> On Tue, 29 Mar 2011 14:40:43 -0500, A.L.<l...@a...com> wrote:
>> Poza tym, byla mowe o MODULARNOSCI. Wszyscy programisci OO spod znaku
>> C++ i pochodnych o modularnosci nie maja zielonego pojecia. Wiec jak
>> najbardziej tzreba studentow tego uczyc, i to jak najlepiej z dala od
>> OO.
Widzę, że A.L. znowu głosi prawdy objawione - w c++ nikt nigdy nie pisał
systemu pluginowego gdzie wszystko jest zbiorem modułów spinanych przez
określone api? Tak, pewnie.

--
Pozdrawiam
Michoo

do góry

> oglosil ze pzrestaje uczyc programwoania obiektowego na wstepnych
> kursach programwoania

Jezeli celem "wstepnych kursów programowania" jest przeglad koncepcji
programowania, to usuwanie z niego któregokolwiek z paradygmatów jest
dyskusyjne. Mozna dyskutowac o "wyrównywaniu proporcji", jesli z jakiegos
powodu nauczanie mialo charakter zbyt "inzynierski" i opieralo sie na
przyklad wylacznie o jezyki obiektowe. Ale usuwac? To pachnie podejsciem
dogmatycznym, zamiast oczekiwanym - praktycznym.

Z wlasnego podwórka - w Instytucie Informatyki UWr, gdzie pracuje, od dawna
programowania nie uczy sie na przykladzie zadnego konkretnego jezyka -
zamiast tego studenci uczeszczaja na "Programowanie", gdzie

"Celem zajec jest przedstawienie studentom mozliwie szerokiego kregu
zagadnien zwiazanych z programowaniem komputerów, ze szczególnym
uwzglednieniem podstawowych konstrukcji wystepujacych w jezykach
programowania i zwiazanych z nimi technik tworzenia programów."

Program obejmuje:

Podstawy inzynierii oprogramowania. (3 godz.)
Definicje indukcyjne, rekursja i dowody przez indukcje strukturalna. (1
godz.)
Gramatyki regularne i bezkontekstowe. Analiza leksykalna i skladniowa.
Lekser. Parser. Konkretne i abstrakcyjne drzewa rozbioru. (3 godz.; Teoria
informatyki)
Metody opisu semantyki jezyków programowania. Strukturalna semantyka
operacyjna. Semantyka denotacyjna. Definicje rekurencyjne i funkcje
czesciowe. (5 godz.; Wstep do semantyki jezyków programowania)
Logika Hoare'a i dowodzenie poprawnosci programów. Metoda niezmienników.
Synteza programów metoda wstepujaca i zstepujaca. (5 godz.; Wstep do
semantyki jezyków programowania)
Struktura wspólczesnych jezyków programowania. Nazwy, komórki i wartosci,
struktury sterujace, funkcje i procedury, dynamiczne struktury danych,
wyjatki. Typy danych, mocna typizacja, rekonstrukcja typów. (7 godz.)
Pojecie translatora. Zasieg zmiennych, wywolywanie funkcji i zarzadzanie
pamiecia. Jezyki o strukturze blokowej, rekordy aktywacji, metody przydzialu
pamieci dla zmiennych lokalnych i globalnych. Funkcje wyzszego rzedu, funarg
problem. Automatyczne zarzadzanie pamiecia i odsmiecanie. (6 godz.;
Translatory)
Algebraiczne specyfikacje typów danych. Typy definiowane indukcyjnie (listy,
drzewa, stosy, kolejki itd.) Indukcyjne dowody ich wlasnosci. (4 godz.;
Algorytmy i struktury danych)
Moduly, rodzajowosc i abstrakcja danych. Ukrywanie (encapsulation) danych.
Rozwiazania w konkretnych jezykach (moduly, pakiety w Adzie, klastery w
Clu). Rodzajowosc (funktory, pakiety rodzajowe, wzorce (templates) w C++).
(6 godz.; Algorytmy i struktury danych)
Programowanie funkcjonalne. Programowanie deklaratywne a imperatywne. Skutki
uboczne. Porzadek wartosciowania. (4 godz.; Programowanie funkcjonalne)
Programowanie obiektowe, metodologia OO, obiekty i klasy, abstrakcyjne typy
danych a klasy, podtypowanie a dziedziczenie, jezyki bezklasowe, Smalltalk.
Obiektowy styl programowania w C++. Java. (6 godz.; Programowanie obiektowe)
Wspólbieznosc. Elementarne metody synchronizacji: semafory, monitory, rejony
krytyczne. CSP. CCS. Model asynchroniczny. Programowanie rozproszone.
Kanaly, watki, coroutines. Mechanizmy wspólbieznosci w Adzie i innych
jezykach programowania. Pieciu filozofów itp. Obliczenia sterowane
przeplywem danych. (6 godz.; Obliczenia równolegle i rozproszone, Systemy
operacyjne)
Programowanie w logice. Prolog. (4 godz.; Programowanie logiczne)

Mozna spierac sie o szczególy, ale jest tu dokladnie to, co daje podstawe do
studiowania wielu dalszych zagadnien zwiazanych z programowaniem.

I gdyby mój Szanowny Kolega prowadzacy wyklad oglosil wszem i wobec, ze z
programu nauczania usunal zagadnienia zwiazane z programowaniem obiektowym,
bo "it is both anti-modular and anti-parallel by its very nature, and hence
unsuitable for a modern CS curriculum" to - podobnie jak tam - zwyczajnie
"zubozylby" ten wyklad.

Jezyki funkcjonalne bronia sie same, nie trzeba im pomagac na sile usuwajac
z programu nauczania Jave. Efekt moze byc odwrotny od zamierzonego. W
kontekscie polskim nie mamy sie kompletnie czego wstydzic - zalaczony wyzej
przyklad pokazuje, ze tam gdzie sie chce, tam mozna.

pozdrawiam uprzejmie,
Wiktor Zychla

do góry

> I gdyby mój Szanowny Kolega prowadzacy wyklad oglosil wszem i wobec, ze z
> programu nauczania usunal zagadnienia zwiazane z programowaniem obiektowym,
> bo "it is both anti-modular and anti-parallel by its very nature, and hence
> unsuitable for a modern CS curriculum" to - podobnie jak tam - zubzoylby ten wyklad

>

raczej chodzi o to: "staramy sie nauczyc
metod rozwiazywania problemow i pisania
programow, uwazamy ze objektowy paradygmat
programowania nie jest wcale taki specjalnie dobry
zeby warto go bylo tak promowac moze warto
wlasnie skupic sie na czyms innym"

od zawsze powtarzam ze mnie obiektowka
odrzuca - modularnosc tak ,ale powinno to
byc raczej nieco inaczej robione i trzeba sie
zastanowic jak; ciekawe jest czemu uwazaja
ze o-o jest z natury anty rownolegle i anty modulowe -
byc moze moglbym przedefiniowac i poprawic je
by bylo i 'rownolegle' i 'modulowe' - klaruja mi sie
tu pewne rzeczy wiec moglbym zapodac jakis 'esej'




--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

jest cos takiego jak jakis miesiecznik czy
kwartalnik dla profesorow informatyki teoretycznej
ktory czytaja na Harwardzie w Mit itd
w ktorym sie zapodaje prace naukowe?
pytam nieco zartobliwie ale ciekaw jestem

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry