On 30 Mar, 14:52, A.L. <l...@a...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.

Odpowiem przewrotnie: jeśli CMU to faktycznie jedna z najlepszych
szkół, to mogliby spokojnie sami sobie opracować język spełniający te
docelowe cechy. Nie byłoby to nawet nic nadzwyczajnego - wiele języków
powstało na uniwerkach właśnie w taki sposób. Zwłaszcza, że
ograniczając się do celów dydaktycznych taki język nie musiałby już
mieć żadnych innych cech. Wywalenie całego paradygmatu tylko dlatego,
że Java czy Python nie odzwierciedlają jakiegoś teoretycznego ideału
nie pasuje mi do profilu ani lokalnego college'u ani CMU. Dlatego
napisałem, że ten ruch to chaos.

Natomiast jeśli ktoś szuka inspiracji w istniejących językach, to
przecież sam wspomniałeś o Adzie. Tam OO jest, chociaż nawet nie ma
słowa kluczowego "class". Można to potraktować jako punkt wyjścia i
użyć do prezentacji różnych pojęć. Potem można ludzi wpuścić w Javę
czy Pythona.

Myślę, że ktoś w CMU za bardzo się rozmachnął i potem musiał pójść za
ciosem gdy przyszło do wywiadów. W ten sposób doszło do sztucznego
pogłębienia sensacji, która nie powinna była powstać. Za semestr
sprawa ucichnie.

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

A to wiadomo. Jak studiowałem to OO było - nie pamiętam, na 4
semestrze? Wtedy ludzie byli już chociaż trochę oklepani. To było 12
lat temu. Jakoś nikt nie robił z tego sensacji tak jak teraz. Ale
cieszę się, że CMU dorównuje do najlepszych polskich wzorców. :-D

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

do góry

Szyk wrote:

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

I jedną z takich paczek jest komputer, albo system informatyczny. Wydaje się
mu wtedy polecenie: komputerze - korzystając ze swoich zasobów wykonaj to i
to.

> Jedyny problem z programowaniem obiektowym jest jego inercja (po
> napisaniu już się nie chce tego zmieniać)

Bo i często nie ma jak zmieniać, ponieważ program obiektowy ma dość sztywną
strukturę. Jeśli już na starcie w 100% wiadomo, co mamy osiągnąć, to sztywna
struktura nie jest problemem, natomiast w przeciwnym - dość częstym -
przypadku, jest problemem dość uciążliwym do rozwiązania.

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

Jest bardzo dużo programów w C, które przy tych wadach, mają jedną ogromną
zaletę: poprawnie działają. Gdyby inne języki były tak znacząco lepsze,
bardzo szybko powstałyby konkurencyjne, lepsze, programy w tych językach i
wyparły z użycia te napisane w C.

do góry

W dniu 2011-03-31 21:23, Wojciech Jaczewski pisze:
[...]
>> 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!
>
> Jest bardzo dużo programów w C, które przy tych wadach, mają jedną ogromną
> zaletę: poprawnie działają. Gdyby inne języki były tak znacząco lepsze,
> bardzo szybko powstałyby konkurencyjne, lepsze, programy w tych językach i
> wyparły z użycia te napisane w C.

Pytanie, czy są też łatwe w serwisowaniu?

Tak naprawdę to na poziomie C vs. C++ więcej zależy od umiejętności
programisty niż przewagi któregokolwiek z języków.

C bywa bardziej ekonomiczny, bo jest prostszy do nauczenia się niż C++
(więcej tańszych i wystarczająco dobrych programistów) i starszy (więcej
gotowego kodu względnie łatwego do zlinkowania).

Lepsze (w sensie "ładności") języki i programy w nich pisane nie
powstają właśnie ze względu na ekonomię. C i C++ (często jako "C
z klasami" albo i gorzej) i marnie napisany, ale (dzięki sporemu
wysiłkowi kolejnych programistów ze "sznurkiem i taśmą klejącą")
działający poprawnie program jest często wystarczający. Nijak się ma to
do dobrze napisanych projektów w C/C++.

Innymi słowy - C i C++ z rzeszą niezbyt dobrze wyedukowanych
programistów wypierają (choć nie wszędzie oczywiście) dobrych
programistów, którzy potrafią wykorzystać zarówno C i C++ jak
i bardziej nowoczesne i "lepsze" języki. Tak jak gorszy pieniądz
wypiera lepszy.

Kilka lat temu (teraz szczyt chyba przechodzi) mieliśmy coś takiego
w kategorii tworzenia serwisów internetowych i PHP.

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

do góry

Michoo wrote:
> 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.

Z faktu, że w C++ napisano coś składające się z modułów, nie wynika,
że ten język ma jakiekolwiek wsparcie dla modularyzacji (ok, ma śladowe).
Moduły są w Pascalu, Pythonie Javie, a moduły generyczne masz w Adzie,
czy SML-u (w którym można parametryzować moduły innymi modułami).

w.

do góry

Paweł Kierski wrote:

>> Jest bardzo dużo programów w C, które przy tych wadach, mają jedną
>> ogromną zaletę: poprawnie działają. Gdyby inne języki były tak znacząco
>> lepsze, bardzo szybko powstałyby konkurencyjne, lepsze, programy w tych
>> językach i wyparły z użycia te napisane w C.
>
> Pytanie, czy są też łatwe w serwisowaniu?

Zależy co rozumieć pod pojęciem serwisowanie. Binarki powstałe z programów w
czystym C są nieco bardziej przenośne niż w C++. Dla mnie to jest miłe, gdy
mogę binarkę zlinkowaną dynamicznie przenieść z nowszego systemu (np.
Debian) na starszy i nie muszę kompilować.
Które łatwiej serwisować w sensie modyfikować - nie wiem.

> C bywa bardziej ekonomiczny, bo jest prostszy do nauczenia się niż C++
> (więcej tańszych i wystarczająco dobrych programistów)

Nie byłbym pewny czy tak jest. Rozwiązania w C zwykle są proste, bo do
tworzenia takich skłania język. Programista by się za bardzo namęczył, gdyby
zrobił to w sposób skomplikowany, więc więcej czasu poświęca na szukanie
rozwiązań prostych. Ale chyba łatwiej wymyślić jakiś C++-owy przerost formy
nad treścią (dzięki wsparciu języka nie aż tak zawiły) niż dobre rozwiązanie
w C.

> Lepsze (w sensie "ładności") języki i programy w nich pisane nie
> powstają właśnie ze względu na ekonomię. C i C++ (często jako "C
> z klasami" albo i gorzej)

Co jest takiego złego w "C z klasami". Być może każdy trochę inaczej
definiuje co to pojęcie oznacza. Ja osobiście bardzo lubę styl C ze
standardowymi kontenerami C++ oraz shared_ptr. Czy uważasz to za "C z
klasami", czy coś innego?

> i marnie napisany, ale (dzięki sporemu
> wysiłkowi kolejnych programistów ze "sznurkiem i taśmą klejącą")
> działający poprawnie program jest często wystarczający. Nijak się ma to
> do dobrze napisanych projektów w C/C++.

Wolę ten sznurek i taśmę klejącą wewnątrz programu niż na zewnątrz. Klejenie
często jest niezbędne i można je zrobić w programie, albo zachować w
programie piękną strukturę i wszystkie przypadki szczególne, które trzeba
uwzględnić usunąć sobie z oczu, zwalając problem na integratora (i
jednocześnie czyniąc ten problem większym, niż był gdy znajdował się
wewnątrz programu).
Te "lepsze" języki często mają ograniczoną funkcjonalność i klejenie trzeba
zrobić jakimiś zewnętrznymi skryptami, czy programami w C bądź C++.

do góry

W dniu 31.03.2011 23:26, Wojciech Muła pisze:
> Michoo wrote:
>> 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.
>
> Z faktu, że w C++ napisano coś składające się z modułów, nie wynika,
> że ten język ma jakiekolwiek wsparcie dla modularyzacji (ok, ma śladowe).
Zgadza się, że wsparcie jest małe. Ale nawiązywałem do wyciętego przez
Ciebie cytatu:
>> Wszyscy programisci OO spod znaku
>> C++ i pochodnych o modularnosci nie maja zielonego pojecia.
Co jest kolejnym bullshitem ze strony AL.
Normalnie staram się ignorować jego posty wypływające czasami w
cytowaniach, ale niektóre z bredni imo wymagają komentarza bo ten
osobnik cały czas się lansuje na autorytet.

> Moduły są w Pascalu, Pythonie Javie, a moduły generyczne masz w Adzie,
> czy SML-u (w którym można parametryzować moduły innymi modułami).
Pascalowe moduły rzeczywiście są całkiem niezłą koncepcją i dobrze
zrealizowaną jeżeli nie liczyć braku automatycznych zależności (istotna
kolejność wymienienia na liście importów - a przynajmniej tak było jak
miałem ostatni raz do czynienia z pascalem).

Pythonowe moduły to jest przecież jakaś porażka. (Powodująca na dodatek
często bardzo brzydkie praktyki - wszystko w jednym pliku.) Dopiero
paczki z __init__ importującym klasy wszystkich modułów "w głąb" dają
jakąś protezę "prawdziwego modułu".

W javie ztcw nie da się sprawdzić co jest w JAR inaczej jak go
rozpakowując, a statyczne konstruktory nie wywołują się do czasu
załadowania danej klasy, więc bez strasznych kombinacji z dependency
injection nie da się zrobić modułu, który podepnie się "sam" do reszty -
nie wystarczy mieć wspólnego api, ale trzeba podać wprost nazwy klas.

Ady nie znam na tyle (a SML wcale) aby się wypowiadać.

W C++ pisałem zaliczenie z programowania wizualnego w QT gdzie było
ustalone, publiczne API i można było podmienić fragment implementacji w
gotowej aplikacji przez podmianę odpowiedniej biblioteki DLL. Jak te
powyższe to są moduły to czemu nie to?

--
Pozdrawiam
Michoo

do góry

W dniu 01.04.2011 00:01, Wojciech Jaczewski pisze:
> Rozwiązania w C zwykle są proste, bo do
> tworzenia takich skłania język. Programista by się za bardzo namęczył, gdyby
> zrobił to w sposób skomplikowany, więc więcej czasu poświęca na szukanie
> rozwiązań prostych.
A potem powstaje takie gtk (czy glib) reimplementujące możliwości c++ w c.

--
Pozdrawiam
Michoo

do góry

On Thu, 31 Mar 2011 23:26:31 +0200, Wojciech Mu?a
<w...@p...null.onet.pl.invalid> wrote:

>Michoo wrote:
>> 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.
>
>Z faktu, że w C++ napisano coś składające się z modułów, nie wynika,
>że ten język ma jakiekolwiek wsparcie dla modularyzacji (ok, ma śladowe).
>Moduły są w Pascalu, Pythonie Javie, a moduły generyczne masz w Adzie,
>czy SML-u (w którym można parametryzować moduły innymi modułami).

Moduly w Javie?... Gdzie?

A.L.

do góry

On Thu, 31 Mar 2011 01:12:34 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>On 30 Mar, 14:52, A.L. <l...@a...com> wrote:

>
>Odpowiem przewrotnie: jeśli CMU to faktycznie jedna z najlepszych
>szkół, to mogliby spokojnie sami sobie opracować język spełniający te
>docelowe cechy.

Owszem, bylo to keidys dosyc popularne, niektore proby byly dosyc
ciekawe (jezyk Turing w Toronto), ale jakos ten trend zanikl. Przy
takiej mnogosci jezykow programwoanie robienie ejszcze jednego ma maly
sens.

>
>Natomiast jeśli ktoś szuka inspiracji w istniejących językach, to
>przecież sam wspomniałeś o Adzie. Tam OO jest, chociaż nawet nie ma
>słowa kluczowego "class". Można to potraktować jako punkt wyjścia i
>użyć do prezentacji różnych pojęć. Potem można ludzi wpuścić w Javę
>czy Pythona.
>

Ja wspomne o Oberonie. Ma moduly, obiektowosc realizuje pzrez
rozszerzane typy. Jast maly i zgrabny. Byl uzywany do nauczanai w
Europie. Wirth zaczal pzrepisywac swoja ksiazke o algorytmach i
strukturach danych z Pascala na Oberon, ale nie skonczyl (szkic jest
na jego stronie webowej). Ada wydaje mi sie za skomplikwoana na
nauczanie poczatkowe.

>Myślę, że ktoś w CMU za bardzo się rozmachnął i potem musiał pójść za
>ciosem gdy przyszło do wywiadów. W ten sposób doszło do sztucznego
>pogłębienia sensacji, która nie powinna była powstać. Za semestr
>sprawa ucichnie.
>

Nie ma zadnej sensacji. Nierozmawia sie o tym w kawiarniach. Znacznei
wieksza sensacje zrobil MIT

A.L.

do góry

On 30 Mar, 14:52, A.L. <l...@a...com> wrote:

> P.S. A tak na marginesie, to jeszcze raz sie zgodze z koncepcja ze OO
> nie jest tematem na POCZATKOWE nauczanie
Duzo zalezy od tego jak ten programista potem ma wykorzystywac swoje
umiejetnosci. Jesli ktos ma byc tylko klepaczem aplikacji w javie +
sql to
po co mu zawracac glowe programowaniem czysto procueduralnym, albo
asemblerem? Nie lepiej jak od razu uczyc go jak to sie robi w Javie i
obiektowo?
Pozdrawiam

do góry