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

http://www.i-programmer.info/news/150-training-a-edu
cation/2188-cmu-drops-oop.html

...a blog post professor Robert Harper delivers the news that the
Carnegie Mellon University (CMU) Computer Science department is
removing the required study of O-O from the Freshman curriculum. The
reason he gives is interesting:

"Object-oriented programming is eliminated entirely from the
introductory curriculum, because it is both anti-modular and
anti-parallel by its very nature, and hence unsuitable for a modern CS
curriculum. 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."
...
Two courses replace the OOP content. One is "Principles of Imperative
Computation" and guess what the language is that it uses? It is C and
a subset at that
...
The second is on functional programming and you can't help but jump to
the conclusion that it is this paradigm that is really pushing OOP out
of the curriculum. The course is being taught using Standard ML

Wiecej

http://existentialtype.wordpress.com/2011/03/15/teac
hing-fp-to-freshmen/

http://www.cs.cmu.edu/~15150/

http://www.cs.cmu.edu/~fp/courses/15122-f10/

A.L.

do góry

A.L wrote:
> jeden z najlepszych amerykanskich uniwersytetow, Carnegie-Mellon
> oglosil ze pzrestaje uczyc programwoania obiektowego na wstepnych
> kursach programwoania

I to wg Ciebie zle, czy dobrze?

w.

do góry

On Tue, 29 Mar 2011 19:34:27 +0200, Wojciech Mu?a
<w...@p...null.onet.pl.invalid> wrote:

>A.L wrote:
>> jeden z najlepszych amerykanskich uniwersytetow, Carnegie-Mellon
>> oglosil ze pzrestaje uczyc programwoania obiektowego na wstepnych
>> kursach programwoania
>
>I to wg Ciebie zle, czy dobrze?
>
>w.

Dobrze

Yes. There was some discussion in CACM (Communications of the ACM -
journal) regarding teaching/not teaching OO. Majority of opinions
were that OO is JUST ONE programming paradigm, and for some
applications hardly usable (such as embedded systems, control,
avionics), and teaching OO as first paradigm is equally bad as
teaching BASIC with GOTO.

In principle, I believe that they are right, in the sense that
bringing too much OO too early can create more harm than good.
Imperative paradigm is still doing well and students must know how to
use it.

Moreover, in the link above mentioned was the issue of modularization
and teaching students how to modularize programs. Actually,
modularization is totally forgotten in OO community, despite that it
was pointed out many times (Parnas, Wirth, Szyperski) that
modularization and OO are orthogonal concepts. I agree that
modularization should be presented as "stand alone", not within OO
context

This doesn't change my (negative) opinion about MIT's decision to
replace Scheme by Python. This was obviously marketing/business
decision. As they openly said, world today is not the same as 20 years
ago, and now students (even at MIT) have such bad preparation that
book SICP + Scheme is too hard for majority of them.

A.L.

do góry

> A.L wrote:
> > jeden z najlepszych amerykanskich uniwersytetow, Carnegie-Mellon
> > oglosil ze pzrestaje uczyc programwoania obiektowego na wstepnych
> > kursach programwoania

> I to wg Ciebie zle, czy dobrze?
>
> w.

to swietnie :)

smieszne bo ja akurat po 10 latach krytykowania oo
ostatnio troche sie go poduczylem i nawet zastanawialem
sie ostatnio czy nie napisac jakiegos tutoriala oo by
sobie to wyklarowac

nie zmieniam krytycznego stosunku do oo i jezykow obiektowych
ale gdybym sie go bardziej poduczyl to bede mogl
wyrazniej powiedziec dlaczego nie jest raczej ok

jezykow funkjonalnych podobnie dokladnie nie znam i niezbyt mnie tez
przekonuja to co jest ok to c/c2 i paradygmat agentowy

fir

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

do góry

to spostrzezenie ze o-o i modularnosc okazuja
sie (ew) ortogonalnymi konceptami bardzo imo
ciekawe, podobnie ciekawie brzmi ze o-o "is antiparallel
by its very nature" umialby ktos to rozwinac? - anyway dzieki za
podrzucenie tak ciekawego info. (mz ostatnio sporo tu
troche pobocznych ale ciekawych watkow tal ze usenet chyba
jeszcze nie ma sie tak zle)

pzdr, fir

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

do góry

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
paczki i nazywają je: dom, samochód, droga, drzewo, ptak. Takie
pojmowanie świata jest bardzo przyjemne i wygląda na bardzo zdrowe.
Jedyny problem z programowaniem obiektowym jest jego inercja (po
napisaniu już się nie chce tego zmieniać) i upierdliwa składnia C++
(pliki nagłowkowe - można by je generować automatycznie (język D),
includy - to mógłby obczajać kompilator przy pierwszym wywołaniu
(podobnie jak w PHP funkcje wbudowane), nawiasy - jakoś w pythonie już
ich niema i działa).

Chwalą i bronią pod niebiosa język C - a co w nim odwalają? Robią
interfejs w pliku H a plik O traktują jak pojedynczy obiekt klasy
(nabity masą prywatnych zmiennych i funkcji) z interfejsem w pliku H -
taki singleton. To jest programowanie obiektowe tyle że robione w
jeszcze bardziej upierdliwy i zawoalowany sposób!

do góry

On Tue, 29 Mar 2011 21:27:55 +0200, 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
>paczki i nazywają je: dom, samochód, droga, drzewo, ptak. Takie
>pojmowanie świata jest bardzo przyjemne i wygląda na bardzo zdrowe.
>Jedyny problem z programowaniem obiektowym jest jego inercja (po
>napisaniu już się nie chce tego zmieniać) i upierdliwa składnia C++
>(pliki nagłowkowe - można by je generować automatycznie (język D),
>includy - to mógłby obczajać kompilator przy pierwszym wywołaniu
>(podobnie jak w PHP funkcje wbudowane), nawiasy - jakoś w pythonie już
>ich niema i działa).
>
>Chwalą i bronią pod niebiosa język C - a co w nim odwalają? Robią
>interfejs w pliku H a plik O traktują jak pojedynczy obiekt klasy
>(nabity masą prywatnych zmiennych i funkcji) z interfejsem w pliku H -
>taki singleton. To jest programowanie obiektowe tyle że robione w
>jeszcze bardziej upierdliwy i zawoalowany sposób!

No i znow wracamy do syskusji "czy Pascal jest dobrym jezykiem do
nauczania"

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.

A.L.

do góry

heh, ( sorki ze pisze u gory posta ale
mam ograniczona klawiaturke na iphone
i m in nie wiem gdzie tu jest strzalka w dol:/ )

roznic miedzy taka modulowoscia rodem
z c (ja nazywam taki modul 'przestrzenia')
a obj jest kilka i sa one defakto
gigantyczne

musialbym dlugo pomyslec aby wymienic
ich komplet ale przede wszystkim to ze
1)
w obj zalacza sie w programach skomplikowana
(przynajmniej jak ja to niedokladnie widze)
strukture/hierarchie istnienia/nieistnienia
objektow w run time - nie tylko musisz sie
biedzic i trudzic jak dostac do innych obiektow
ale tez uwazac czy one istnieja - jak dla mnie
to jest okropnie trudne wnerwiajace i niepotrzebne
bo malo ktore encje w programie tak naprawde
musza byc niszczone ( i tworzone na nowo)
2) w module (przestrzeni, oddzielnym kawalku kodu)
mozesz grupowac rozmaite funkcje i struktury- np
mozesz to nazwac 'koty i psy.o' i wrzucic tam
127 kotow i 256 psow jest to znacznie luzniejszy
podzial


jest to znacznie luzniejszy


> 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

> paczki i nazywają je: dom, samochód, droga, drzewo, ptak. Takie

> pojmowanie świata jest bardzo przyjemne i wygląda na bardzo zdrowe.

> Jedyny problem z programowaniem obiektowym jest jego inercja (po

> napisaniu już się nie chce tego zmieniać) i upierdliwa składnia C++

> (pliki nagłowkowe - można by je generować automatycznie (język D),

> includy - to mógłby obczajać kompilator przy pierwszym wywołaniu

> (podobnie jak w PHP funkcje wbudowane), nawiasy - jakoś w pythonie już

> ich niema i działa).

>

> Chwalą i bronią pod niebiosa język C - a co w nim odwalają? Robią

> interfejs w pliku H a plik O traktują jak pojedynczy obiekt klasy

> (nabity masą prywatnych zmiennych i funkcji) z interfejsem w pliku H -

> taki singleton. To jest programowanie obiektowe tyle że robione w

> jeszcze bardziej upierdliwy i zawoalowany sposób!



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

do góry

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

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. 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.
O ile dobrze pamiętam to właśnie książki Marciniaka były zbudowane
wedle tej zasady.
--
Grzegorz Krukowski

do góry

On Tue, 29 Mar 2011 22:15:25 +0200, Grzegorz Krukowski
<r...@o...pl> wrote:

>O
>
>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. 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.
>O ile dobrze pamiętam to właśnie książki Marciniaka były zbudowane
>wedle tej zasady.

Zgoda. Wlasnie "podobne" jak obiektowe, ale nie obiektowe.

Problem w tym ze modulowosc i programowanie obiektowe to dwie rozne
rzeczy, o czym pisal Wirth i jego uczniowie. Jezyk Oberon ma moduly, a
obiektowosc realizuje sie przy pomocy rozszerzalnych typow. Podobine
jest w Adzie.

OO nei oznacza automatycznie klas a klasy nie oznaczaja automatycznie
modulow

Proponuje lekture dosyc starego (ale klasycznego) papiery Klemensa
Szyperskiego ze szkoly Wirtha

http://research.microsoft.com/en-us/um/people/cszype
rs/pub/ecoop92.pdf

Import is Not Inheritance
Why We Need Both: Modules and Classes
Clemens A. Szyperski

Abstract. The design of many popular object-oriented languages like
Smalltalk, Eiffel, or Sather follows a certain trend: The class is the
only structuring form. In this paper, the need for having modules
besides classes is claimed. Modules stem from a different language
family and at first glance it seems that they can easily be unified
with classes. Among other things, unifying modules and classes carries
the danger of unifying the import and inheritance relationships.
Constructs in several languages are discussed that indicate that
modules and classes should indeed be kept separate.

A.L.

do góry