Michal wrote:
> On Fri, 01 Apr 2011 10:18:25 -0500
> A.L. <l...@a...com> wrote:
>
>> Byla mowa nie o nauczaniu w zawodowej szkole programistow, a na
>> uczelni wyzeszej. To dwie zupelnie rozne rzeczy. Na uniwersytetach nie
>> ksztalci sie programistow.
>
> Not tak na uniwersytetach uczy sie jezykow programowania nie po to aby programowac.
> Pozniej tacy nie programojacy najlepsi-na-swiecie-absolwenci-albo-i-doktury-jezyko
w-programowania
> mowia innym na grupach dyskusyjnych jak maja programowac.

Nie rozumiesz. Uniwersytet nie jest szkołą zawodową. Uniwersytet *nie daje
zawodu*!

Uniwersytet ma dać wiedzę i nauczyć sposóbów jej efektywnego pozyskiwania.
Uniwerystet ma zadanie dostarczyć wykształconych ludzi którzy opierając
się bardziej lub mniej na otrzymanej wiedzy wybiorą sobie zawód.

Jak ktoś idzie na uniwerek po to, żeby go nauczyli fachu to się fatalnie
pomylił.

pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)

do góry

W dniu 2011-04-04 12:38, Sebastian Kaliszewski pisze:
[...]
> unit cośtam;
>
> interface ....
> implementation ....
>
>
> Na poziomie języka przyzwoity moduł ma dobrze określany interfejs i jest
> dobrze oddzielony od reszty kodu, tzn. z reszty kodu może sam z z
> siebie[**] korzystać tylko poprzez interfejsy innych modułów.
>
> To co nie jest udostępnione w interfejsie nie jest dostępne dla kodu
> spoza modułu (za wyjątkiem jakiś spyficznych tricków, ale nie zajmujemy
> ani nie interesujemy się tu rzeźbiarstwem). To jest podobne do tego, co
> znamy z OO z klasami (jest OO bez klas, gdzie jest już mniej podobne)
> ale do "nieco" czego innego służy i generalnie na innym poziomie
> struktury kodu działa.
>
> Stąd zarówno rozwiązania z C++ z jednej strony (przestrzenie nazw i
> jednostki kompilacji) jak i z Javy z drugiej (pakiety i jednostki
> kompilacji ograniczone do jednej publicznej klasy) to tylko
> fragmentaryczne, niekompletne kawałki.
>
> Mam nadzieję, że nieco wyjaśniłem

Pomijając na razie kwestie łatwości zapisu i czytelności - nie widzę tu
niczego, czego nie dałoby się wyrazić w C++ za pomocą przestrzeni nazw
i jednostek kompilacji. Na tej samej zasadzie w C++ nie ma słowa
interface, ale daje się go dobrze wyrazić za pomocą klasy wyłącznie
z metodami tylko abstrakcyjnymi.

Innymi słowy - da się pisać modułowo w C++, kwestia zachowania
konwencji. Oczywiście - każdy będzie miał inną 8-)

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

do góry

On Mon, 04 Apr 2011 13:15:57 +0200, Paweł Kierski <n...@p...net>
wrote:

>W dniu 2011-04-04 12:38, Sebastian Kaliszewski pisze:
>[...]
>> unit cośtam;
>>
>> interface ....
>> implementation ....
>>
>>
>> Na poziomie języka przyzwoity moduł ma dobrze określany interfejs i jest
>> dobrze oddzielony od reszty kodu, tzn. z reszty kodu może sam z z
>> siebie[**] korzystać tylko poprzez interfejsy innych modułów.
>>
>> To co nie jest udostępnione w interfejsie nie jest dostępne dla kodu
>> spoza modułu (za wyjątkiem jakiś spyficznych tricków, ale nie zajmujemy
>> ani nie interesujemy się tu rzeźbiarstwem). To jest podobne do tego, co
>> znamy z OO z klasami (jest OO bez klas, gdzie jest już mniej podobne)
>> ale do "nieco" czego innego służy i generalnie na innym poziomie
>> struktury kodu działa.
>>
>> Stąd zarówno rozwiązania z C++ z jednej strony (przestrzenie nazw i
>> jednostki kompilacji) jak i z Javy z drugiej (pakiety i jednostki
>> kompilacji ograniczone do jednej publicznej klasy) to tylko
>> fragmentaryczne, niekompletne kawałki.
>>
>> Mam nadzieję, że nieco wyjaśniłem
>
>Pomijając na razie kwestie łatwości zapisu i czytelności - nie widzę tu
>niczego, czego nie dałoby się wyrazić w C++ za pomocą przestrzeni nazw
>i jednostek kompilacji. Na tej samej zasadzie w C++ nie ma słowa
>interface, ale daje się go dobrze wyrazić za pomocą klasy wyłącznie
>z metodami tylko abstrakcyjnymi.

Tak, ale twoja modularyzacja opiera się na systemie typów: z jednej
strony musisz w nim zawrzeć taką strukturę która odzwierciedla logikę
modelowanego bytu, z drugiej strony logikę modułów. Obydwie te logiki
mogą nie mieć ze sobą nic wspólnego, to raz, dwa że struktura
dziedziczenia robi się zbyt skomplikowana.
Jeżeli używasz modułów to obie te części są całkowicie niezależne, nie
mieszasz ze sobą logiki modelu z logiką konstrukcji programu co jest
niebagatelną zaletą.
--
Grzegorz Krukowski

do góry

On 4 Kwi, 13:15, Paweł Kierski <n...@p...net> wrote:

> Pomijając na razie kwestie łatwości zapisu i czytelności - nie widzę tu
> niczego, czego nie dałoby się wyrazić w C++ za pomocą przestrzeni nazw
> i jednostek kompilacji.

Ja też nie, ale tylko dlatego, że Sebastian niewiele napisał :-) -
chociaż można się przyczepić, że w C++ trzeba posługiwać się fizcznymi
aspektami kodu (podział na pliki), żeby osiągnąć jakiś cel logiczny,
np. ukrycie części prywatnej. To powinno być dostępne nawet w obrębie
jednego pliku.

Ale dodaj do tego jeszcze jakąś semantykę hierarchii i przestrzenie
nazw okazują się być zbyt ubogie. Np. relację rodzic-dziecko między
pakietami, która ma konsekwencje w widoczności nazw w jednym kierunku
(np. tylko dziecko widzi część prywatną rodzica). Albo podział na
pakiety publiczne i niepubliczne, również z konsekwencjami w
hierarchii (np. tylko rodzic może wciągać swoje niepubliczne dzieci).
Można sobie jeszcze wyobrazić różne rodzaje hierarchii - np.
zagnieżdżenie vs. rodzic-dziecko. To są dwie różne relacje i mogą być
użyte w różnych celach.

Do tego można sobie jeszcze wyobrazić, że pakiety czy moduły wcale nie
muszą być konstrukcjami top-level. Np. czemu nie mieć lokalnych
pakietów/modułów tak jak mogą być lokalne klasy czy lokalne
podprogramy? Albo czemu by pakiet/moduł nie miał być parametrem
szablonu? To by było dobre zwłaszcza przy szablonach typu traits -
teraz w C++ robi się sztuczne struktury ze statycznymi deklaracjami w
środku, żeby zebrać do kupy parę rzeczy i podać razem jako parametr;
przecież to nie powinna być struktura, to powinien być właśnie pakiet/
moduł.

Biorąc to wszystko do kupy przestrzenie nazw w C++ właściwie niczego
nie oferują, a pakiety w Javie to (jak zwykle) tzw. "half-ass
solution".

> Innymi słowy - da się pisać modułowo w C++

Da się organizować deklaracje w grupy. Np. std:: to grupa nazw z
biblioteki standardowej a yami:: to grupa nazw z YAMI4. W C do tego
samego celu stosuje się przedrostki i niestety ale to jest cała
funkcjonalność tego elementu języka. Faktem jest, że w 98% przypadków
tylko o to chodzi, ale pozostaje jeszcze te ciekawe 2%.

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

do góry

W dniu 2011-04-04 13:28, Grzegorz Krukowski pisze:
[...]
>>> Stąd zarówno rozwiązania z C++ z jednej strony (przestrzenie nazw i
>>> jednostki kompilacji) jak i z Javy z drugiej (pakiety i jednostki
>>> kompilacji ograniczone do jednej publicznej klasy) to tylko
>>> fragmentaryczne, niekompletne kawałki.
>>>
>>> Mam nadzieję, że nieco wyjaśniłem
>>
>> Pomijając na razie kwestie łatwości zapisu i czytelności - nie widzę tu
>> niczego, czego nie dałoby się wyrazić w C++ za pomocą przestrzeni nazw
>> i jednostek kompilacji. Na tej samej zasadzie w C++ nie ma słowa
>> interface, ale daje się go dobrze wyrazić za pomocą klasy wyłącznie
>> z metodami tylko abstrakcyjnymi.
>
> Tak, ale twoja modularyzacja opiera się na systemie typów: z jednej
> strony musisz w nim zawrzeć taką strukturę która odzwierciedla logikę
> modelowanego bytu, z drugiej strony logikę modułów. Obydwie te logiki
> mogą nie mieć ze sobą nic wspólnego, to raz, dwa że struktura
> dziedziczenia robi się zbyt skomplikowana.
> Jeżeli używasz modułów to obie te części są całkowicie niezależne, nie
> mieszasz ze sobą logiki modelu z logiką konstrukcji programu co jest
> niebagatelną zaletą.

Modułem mogę uczynić wiele klas zamykając je w przestrzeń nazw
i oddzielną bibliotekę. Tak - tu wychodzą "szwy": nie da się zupełnie
ukryć interfejsów "wewnętrznych" klas modułu, czyli mamy trochę
obiektowość w C.

Chyba, że sensowne w ramach modułu jest cięcie "w poprzek" klasy. Wtedy
istotnie się nie da. Cięcie przez hierarchie dziedziczenia też są
niezbyt miłe (co przy okazji pokazuje gdzie powinna być agregacja,
a nie dziedziczenie).

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

do góry

On 4 Kwi, 12:57, Sebastian Kaliszewski
<s...@r...this.informa.and.that.pl> wrote:

> > Czyli chaos. Nie przejmowałbym się tym i pewnie to chwilowa anomalia.
>
> Taka "chwilowa anomalia" obowiązuje np. na UW od n lat

Przecież napisałem w innym poście, że na PW też tak było, przynajmniej
12 lat temu. Mam nadzieję, że tego nie zepsuli, chociaż pewności brak.

> > Czyli proszę się rozejść, nie ma na co patrzeć.
>
> Udajesz że, czy nie rozumiesz? :)

Temat był na Slashdocie wałkowany jakiś tydzień wcześniej, niż A.L.
zrobił tu z niego sensację. Akurat dla A.L. możliwość pokazania
jakiegokolwiek newsa z jakiegokolwiek znanego uniwerku w USA to wiatr
w żagle, ale naprawdę uważam, że w tym wypadku nie ma na co patrzeć.
Ot, jakiś univ przesunął OO na późniejszy semestr w programie. No i?

Zwłaszcza, że 100% ludzi, którzy idą akurat na CMU i tak już zna Javę
albo innego Pythona (nie wierzę, że jest inaczej), więc mają też
"robocze" wyobrażenie o podstawowych pojęciach związanych z OO. Dla
takich ludzi przedmiot "Programowanie obiektowe w Javie" na początku
studiów jest zbędny, natomiast może być ciekawiej poprowadzony
później, korzystając z tego wszystkiego, co się studenci dowiedzieli
na pierwszych semestrach. Ale co to za sensacja? Wydawało mi się, że
na dobrych uniwerkach to jest oczywista oczywistość.
Nie ma na co patrzeć.

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

do góry

W dniu 2011-04-04 14:37, Maciej Sobczak pisze:
[...]
>> Innymi słowy - da się pisać modułowo w C++
>
> Da się organizować deklaracje w grupy. Np. std:: to grupa nazw z
> biblioteki standardowej a yami:: to grupa nazw z YAMI4. W C do tego
> samego celu stosuje się przedrostki i niestety ale to jest cała
> funkcjonalność tego elementu języka. Faktem jest, że w 98% przypadków
> tylko o to chodzi, ale pozostaje jeszcze te ciekawe 2%.

Stąd - może niewyraźnie sformułowane - pytanie, czego w związku
z modułami nie da się wyrazić w C++. Teraz trochę lepiej to widzę.

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

do góry

On Mon, 4 Apr 2011 05:56:15 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>Temat był na Slashdocie wałkowany jakiś tydzień wcześniej, niż A.L.
>zrobił tu z niego sensację. Akurat dla A.L. możliwość pokazania
>jakiegokolwiek newsa z jakiegokolwiek znanego uniwerku w USA to wiatr
>w żagle, ale naprawdę uważam, że w tym wypadku nie ma na co patrzeć.
>Ot, jakiś univ przesunął OO na późniejszy semestr w programie. No i?
>

Przeprazam Kolego, ale jakos tak zywie dla Kolegi wiekszy szacunek niz
dla "sredniej".. Tym bardziej zadziwily mnie (i zasmucily)
niemerytoryczne przytyki personalne tego rodzaju jak powyzej.

JA z niczego nei robie sensacji, po prostu wiadomosc wydawala mi sie
ciekawa, i w tak zwanym "srodowisku" (przynajmniej tu gdzie jestem)
wzbudzila dyskusje. Jezeli zas idzie o "uniwersytety amerykanskie" to
gwarantuje ze jezeli dowiem sie czegos ciekawago o University of
Zielona Gora, nie omieszkam napisac o tym na grupie.

>Zwłaszcza, że 100% ludzi, którzy idą akurat na CMU i tak już zna Javę
>albo innego Pythona (nie wierzę, że jest inaczej),

Programy uklada sie przy zalozeniu ze na wstepnym kursie nikt nei wie
niczego. Albowiem wstepny kurs jest nei dla tych co wiedza wszystko, a
dla tych co wiedza nic.

A.L.

do góry

On Mon, 4 Apr 2011 05:37:34 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:
> > Innymi słowy - da się pisać modułowo w C++
> Da się organizować deklaracje w grupy. Np. std:: to grupa nazw z

Jest jeszcze coś takiego jak anonymous namespace.

do góry

Paweł Kierski wrote:
> W dniu 2011-04-04 12:38, Sebastian Kaliszewski pisze:
> [...]
>> unit cośtam;
>>
>> interface ....
>> implementation ....
>>
>>
>> Na poziomie języka przyzwoity moduł ma dobrze określany interfejs i jest
>> dobrze oddzielony od reszty kodu, tzn. z reszty kodu może sam z z
>> siebie[**] korzystać tylko poprzez interfejsy innych modułów.
>>
>> To co nie jest udostępnione w interfejsie nie jest dostępne dla kodu
>> spoza modułu (za wyjątkiem jakiś spyficznych tricków, ale nie zajmujemy
>> ani nie interesujemy się tu rzeźbiarstwem). To jest podobne do tego, co
>> znamy z OO z klasami (jest OO bez klas, gdzie jest już mniej podobne)
>> ale do "nieco" czego innego służy i generalnie na innym poziomie
>> struktury kodu działa.
>>
>> Stąd zarówno rozwiązania z C++ z jednej strony (przestrzenie nazw i
>> jednostki kompilacji) jak i z Javy z drugiej (pakiety i jednostki
>> kompilacji ograniczone do jednej publicznej klasy) to tylko
>> fragmentaryczne, niekompletne kawałki.
>>
>> Mam nadzieję, że nieco wyjaśniłem
>
> Pomijając na razie kwestie łatwości zapisu i czytelności - nie widzę tu
> niczego, czego nie dałoby się wyrazić w C++ za pomocą przestrzeni nazw
> i jednostek kompilacji. Na tej samej zasadzie w C++ nie ma słowa
> interface, ale daje się go dobrze wyrazić za pomocą klasy wyłącznie
> z metodami tylko abstrakcyjnymi.
>

wyrazić != zapewnić.

> Innymi słowy - da się pisać modułowo w C++, kwestia zachowania
> konwencji. Oczywiście - każdy będzie miał inną 8-)
>

Można też jak najbardziej pisać obiektowo w zwykłym C a nawet w
assemberze. Też kwetsta zachowania konwencji B-)

pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)

do góry