🚀 go-pugleaf

On Mon, 14 Nov 2005 19:05:56 +0000 (UTC), " aneta"
<aneta_ra.SKASUJ@gazeta.pl> wrote:
 
>A moze znacie jakies bardzo podobne do Smalltalka jezyki, które mozna by 
>wykorzystaæ do "wyrabiania dobrych nawykow obiektowych, prototypowania, czy 
>wrêcz specyfikacji? 
> 

Jak juz pisalem, wedle mojego skromnego zdania zaden jezyk sluzacy do
programowania nie nadaje sie do robienia specyfikacji.

Prototypowanie nalezy robic w jezyku docelowym.

Zas najlepiej wyrabia "nawyki obiektowe" jezyk zwany Eiffel. Dostepne
sa darmowe implemenatcje.

A.L.

> Zas najlepiej wyrabia "nawyki obiektowe" jezyk zwany Eiffel. Dostepne 
> sa darmowe implemenatcje. 
 
Tylko czy to nie będzie ekstrawagancja w stylu Smalltalka? No bo jaką 
wartosc przemysłowa ma Eiffel?  
A tak BTW Eiffela, co sądzicie o Meyerze? Warto zainwestować w tę 
jego grubasna knige? (zakladając ze ktos chce sie nauczyc tych dobrych 
nawyków obiektowych). Warto zainwestowac swój czas w Eiffela Waszym zdaniem? 
 
pozdrawiam. Aneta 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Mon, 14 Nov 2005 21:45:15 +0000 (UTC), " Aneta"
<aneta_ra.WYTNIJ@gazeta.pl> wrote:

>> Zas najlepiej wyrabia "nawyki obiektowe" jezyk zwany Eiffel. Dostepne 
>> sa darmowe implemenatcje. 
> 
>Tylko czy to nie bêdzie ekstrawagancja w stylu Smalltalka? No bo jak± 
>wartosc przemys³owa ma Eiffel?  

Nijaka. Ale mowilismy o "wyrabianiu nawykow". A nawyki Eiffel wyrabia
bardzo dobrze. 

>A tak BTW Eiffela, co s±dzicie o Meyerze? Warto zainwestowaæ w tê 
>jego grubasna knige? (zakladaj±c ze ktos chce sie nauczyc tych dobrych 
>nawyków obiektowych). Warto zainwestowac swój czas w Eiffela Waszym zdaniem? 
> 

W ksiazke warto. To najlepsze ksiazka na temat OO. W Eiffla tez.
Aczkolwiek prawdopodobnie/na pewno nie bedziesz go uzywac w pracy, to
jednak jest on "otwierajcy oczy". Znacznie bardziej niz Mozart-OZ
ktory zreszta nalezy do innego podworka.

A.L.

Dnia Mon, 14 Nov 2005 19:05:56 +0000 (UTC),  aneta skrobie:
> A moze znacie jakies bardzo podobne do Smalltalka jezyki, które mozna by 
> wykorzystać do "wyrabiania dobrych nawykow obiektowych, prototypowania, czy 
> wręcz specyfikacji? 

Właśnie po pierwszej części zdania miałem zaproponować Tcl-a, ale po
przeczytaniu drugiej chyba bym się wstrzymał. Nie wiem oczywiście, po co do
prototypowania lub specyfikacji potrzebne komukolwiek wyrabianie dobrych
nawyków obiektowych (szczerze mówiąc jest to dla mnie cokolwiek abstrakcyjne
pojęcie, bo akurat tak się składa, że owe "nawyki" są specyficzne dla języka;
o ile zatem można mówić o dobrych nawykach obiektowych po nauczeniu się
Smalltalka, to jednak potem się okazuje, że owszem, ma się dobre nawyki
obiektowe, ale z obiektowych języków umie się tylko pisac w Smalltalku).

Cóż, może jednak, ryzykując wyśmianie przez różnych mądrali na tej grupie,
spróbuję przestawić moje argumenty. Tcl, dzięki swojej elastyczności i
minimalistycznej składni (oraz tzw. sztuczki z klamrami) jest w stanie pełnić
rolę języka specyfikacji.

No dobrze, ryzykuję również, że prawdopodobnie nie wiem, co to jest
prototypowanie i specyfikacja. Nieważne. I tak liczę na zainteresowanie ;)

Przykładowo, kiedyś tak zupełnie "dla picu" napisałem sobie w Tcl-u coś w
rodzaju programu "make":

http://www.intercon.pl/~sektor/tcl/make.tcl

W którym całą składnię makefile'a opisuje się... skryptem w Tcl-u. Składnia od
normalnego Makefile'a różni się dosłownie nieznacznie. Na przykład, taki
fragment:

CC = gcc
LIBS = -lstdc++

f: f1.o f2.o
	$(CC) -o $@ $? $(LIBS)

f1.o: f1.cc f.h
f2.o: f2.cc f.h
	$(CC) -c $<


wyglądałby w nim tak (tam było parę zmian i dawno się nim nie zajmowałem, więc
próba może się nie powieść - uprzedzam ;):

set CC gcc
set LIBS -lstdc++

rule f f1.o f2.o {
	$CC -o $@ $? $LIBS
}

rules {
	{f1.o f1.cc f.h}
	{f2.o f2.cc f.h}
} {
	$CC -c $<
}

Można się oczywiście kłócić, czy wybrałem odpowiednią i czytelną metodę, ale
mimo wszystko zarówno jest to łatwe do opisania, jak i istnieje kilka
możliwości zrobienia takiego opisu. Od niechcenia można się nawet pokusić o
częściowe ręczne parsowanie (poprzez dzielenie linii samemu przy podanym
znaku), ale to już w bardzo specyficznych przypadkach.

W podobny sposób można składnią Tcl-a opisać całkowicie dowolną strukturę
jakiejkolwiek konstrukcji.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

A.L. <lewando_won_@kalabambuko.com> writes:

> Zas najlepiej wyrabia "nawyki obiektowe" jezyk zwany Eiffel.
> Dostepne sa darmowe implemenatcje.

Słyszałem, że Meyer broni jak niepodległości dziurawego systemu typów
(który w ciemno zakłada, że wszystkie typy z parametrami są kowariantne,
nawet kiedy z definicji typu wynika, że tak nie jest).

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Mon, 14 Nov 2005 23:11:59 +0100, Marcin 'Qrczak' Kowalczyk
<qrczak@knm.org.pl> wrote:

>A.L. <lewando_won_@kalabambuko.com> writes:
>
>> Zas najlepiej wyrabia "nawyki obiektowe" jezyk zwany Eiffel.
>> Dostepne sa darmowe implemenatcje.
>
>S³ysza³em, ¿e Meyer broni jak niepodleg³o¶ci dziurawego systemu typów
>(który w ciemno zak³ada, ¿e wszystkie typy z parametrami s± kowariantne,
>nawet kiedy z definicji typu wynika, ¿e tak nie jest).

Owszem, argumenty przedstawia w ksiazce i papierach. Ale to dobrze, bo
wlasnie "wyrabia nawyki" i "otwiera oczy". Kto na tej grupie wie co to
sa "typy kowariantne"?...

Anyway, nie ma jezyka uniwersalnie dobrego... Zreszta, podobno Meyer
cos tam ostatnio zmienil (co zreszta spowodowalo swiete oburzenie
"Eiffel community") ale wiem dokladnie co bo nie sledze...

A.L.

> Cóż, może jednak, ryzykując wyśmianie przez różnych mądrali na tej grupie, 
> spróbuję przestawić moje argumenty. Tcl, dzięki swojej elastyczności i 
> minimalistycznej składni (oraz tzw. sztuczki z klamrami) jest w stanie 
pełnić 
> rolę języka specyfikacji. 
 
O! O Tcl'u slyszalam duzo dobrego. Na codzien pracuje też z Oracle'm, a 
tam m.in jest Tcl stosowany (+ rozszerzenia typu OraTCL). Nie inetresowalam 
się Tclem za specjalnie wcześniej a moze warto. Jesli do tego dochodzi 
minimalistyczna skłądnia i elegancka obiektowość, to w sumie jest 
to cos - o co by mi chodziło. Prosty, niezbyt przegadany język, który nie 
będzie wymagal znajomości 1000 klas jak Smalltalk. Tyle, ze chyba sam Tcl 
zbytnio obiektowy nie jest? Chyba ze miales na mysli Incr TCL.  
 
No i tylko, czy zabawa z Tcl'em jako językiem obiektowym z lekturami 
typu Meyer - to nie będzie niezbyt "dobrana para"? ;) 
 
 
Dzięki i pozdrawiam. Aneta 
 
 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> W ksiazke warto. To najlepsze ksiazka na temat OO. W Eiffla tez. 
> Aczkolwiek prawdopodobnie/na pewno nie bedziesz go uzywac w pracy, to 
> jednak jest on "otwierajcy oczy". Znacznie bardziej niz Mozart-OZ 
> ktory zreszta nalezy do innego podworka. 
 
Uff. Wreszcie widze jakies swiatelko w tunelu ;-))) 
Bo po osttanich postach na temat Smalltalka, Oza, Javy, C++ zaczęlam 
wątpic w istnienie przyjemnego, klarownej metodyki OOP. 
 
 
Dzięki i pozdrawiam. Aneta 

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Mon, 14 Nov 2005 23:17:48 +0000 (UTC), " Aneta"
<aneta_ra.WYTNIJ@gazeta.pl> wrote:

>> W ksiazke warto. To najlepsze ksiazka na temat OO. W Eiffla tez. 
>> Aczkolwiek prawdopodobnie/na pewno nie bedziesz go uzywac w pracy, to 
>> jednak jest on "otwierajcy oczy". Znacznie bardziej niz Mozart-OZ 
>> ktory zreszta nalezy do innego podworka. 
> 
>Uff. Wreszcie widze jakies swiatelko w tunelu ;-))) 
>Bo po osttanich postach na temat Smalltalka, Oza, Javy, C++ zaczęlam 
>wątpic w istnienie przyjemnego, klarownej metodyki OOP. 
> 

Eiffel nie jest "metodyka OOP" a jezykiem programowania... 

A.L.

Dnia Mon, 14 Nov 2005 23:10:28 +0000 (UTC),  Aneta skrobie:
> > Cóż, może jednak, ryzykując wyśmianie przez różnych mądrali na tej grupie, 
> > spróbuję przestawić moje argumenty. Tcl, dzięki swojej elastyczności i 
> > minimalistycznej składni (oraz tzw. sztuczki z klamrami) jest w stanie 
> pełnić 
> > rolę języka specyfikacji. 
>  
> O! O Tcl'u slyszalam duzo dobrego. Na codzien pracuje też z Oracle'm, a 
> tam m.in jest Tcl stosowany (+ rozszerzenia typu OraTCL). Nie inetresowalam 
> się Tclem za specjalnie wcześniej a moze warto.

Warto. Choćby ze względu na to, że jest naprawdę stosowany w przemyśle.

> Jesli do tego dochodzi 
> minimalistyczna skłądnia i elegancka obiektowość, to w sumie jest 
> to cos - o co by mi chodziło. Prosty, niezbyt przegadany język, który nie 
> będzie wymagal znajomości 1000 klas jak Smalltalk.

Mniej więcej ;)

Tyle że trzeba pamiętać, że o ile Smalltalk jest językiem "naturalnie
obiektowym", o tyle wiele różnych innych języków ma tą obiektowość zrobioną
nieco z boku. Do takich języków - mimo różnic w obiektowości - należą zarówno
Objective-C, jak i Java, C++ i również Incr Tcl.

> Tyle, ze chyba sam Tcl 
> zbytnio obiektowy nie jest? Chyba ze miales na mysli Incr TCL.  

No tak, to w tej chwili najbardziej popularna implementacja obiektowości, być
może przez swoje podobieństwo do C++. Są też inne, jak snit czy xotcl, ale
mnie wydały się nieco bardziej toporne na mój łeb ;)

Incr Tcl nosi w sobie kilka podobieństw do C++ i kilka podobieństw do
Smalltalka. Ze Smalltalkiem łączy go pełen dynamizm. Ale w zasadzie na tym
koniec. Model obiektowości jest raczej bardziej zbliżony do C++; nie ma tak
jak w Smalltalku czegoś takiego, że klasa tworzy inną klasę przez
"subclassing", tylko dziedziczenie określa się przez dodatkową deklarację
wewnątrz klasy (i jest to takoż dziedziczenie wielorakie).

> No i tylko, czy zabawa z Tcl'em jako językiem obiektowym z lekturami 
> typu Meyer - to nie będzie niezbyt "dobrana para"? ;) 

Cóż... ja przyjąłem taką taktykę, że uczę się tego, co mnie interesuje, jeśli
jednak nie widzę przed czymś przyszłości, to pomijam sprawę. A ile różnych
materiałów wyląduje w takim worku i co mają ze sobą wspólnego, to już mało
istotne. W ten właśnie sposób zainteresowałem się trochę Smalltalkiem, bo
uważałem, że poznanie choćby natury tego języka to obowiązek każdego
szanującego się programisty ;). Ale do Eiffla np. nie zajrzałem. Mam za sobą
raptem rzut oka na ten język. Za mało oczywiście, żeby powiedzieć, czy jest
dobry, czy zły, ale żeby do niego zajrzeć potrzebuję sensownej listy "za"
wystarczająco przeważającą listę "przeciw", którą niestety otwiera
stwierdzenie, że ten język nie ma przyszłości, a przemysł go olał.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

> Eiffel nie jest "metodyka OOP" a jezykiem programowania... 

Ależ wiem :) To był moze niezbyt fortunny skrot myslowy (ten krót to:
w C++ realizacja OOP nie jest do konca dobra bo to i tamto, w Javie
to tez nie jest takie czyste OOP, Smalltalk ok, ale martwy...).

Z językiem Eiffel jak rozumiem OOP jest i dosyc "czyste" i nie tak 
przesadnie czyste jak ze Smalltakiem.

Zdażylam juz znaleźc za pomocą googli opinię, ze wspomniana
kniga Pana od OOP jest lepsza niż "wszelkie Symfonie C++". 
Czy można więc ja traktować jako podręcznik do Eiffla? 

Pozdrawiam. Aneta

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> stwierdzenie, że ten język nie ma przyszłości, a przemysł go olał.

Eech. Czy jak już pojawi sie jakis ciekawy, wzorcowy niemal język, 
to musi byc na tyle "akademicki", ze czlowiek dochodzi do wniosku
"A na na co mam się uczyc calej tej rozpasionej biblioteki klas, skoro
pewnie nie wykorzystam tego w praktyce"? ;}
Potem szuka kolejnego "wzorcowego", akademickiego języka, tyle
że już mniejszego, oszczedniejszego, ot, żeby mu takie Perle i inne
PHP [używane zawodowo] nie zatruly umyslu. Na końcu dochodzi sie do
wniosku że nie ma tak latwo...

O ile Eiffel nie ma "rozpasionej" biblioteki klas i nie jest
tak skomplikowany jak C++, to poucze się go razem z TCLem :}

Pozdrawiam. Aneta

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Tue, 15 Nov 2005 02:22:51 +0000 (UTC), " Aneta"
<aneta_ra.WYTNIJ@gazeta.pl> wrote:

>> Eiffel nie jest "metodyka OOP" a jezykiem programowania... 
>
>Ależ wiem :) To był moze niezbyt fortunny skrot myslowy (ten krót to:
>w C++ realizacja OOP nie jest do konca dobra bo to i tamto, w Javie
>to tez nie jest takie czyste OOP, Smalltalk ok, ale martwy...).
>
>Z językiem Eiffel jak rozumiem OOP jest i dosyc "czyste" i nie tak 
>przesadnie czyste jak ze Smalltakiem.
>
>Zdażylam juz znaleźc za pomocą googli opinię, ze wspomniana
>kniga Pana od OOP jest lepsza niż "wszelkie Symfonie C++". 

Zgadzam sie.

>Czy można więc ja traktować jako podręcznik do Eiffla? 
>

Mozna, chociaz jest to podrecznik dosyc trudny. Jak ktos sie chce
szybko nauczyc Eiffla, to sa krotsze ksaizki. Tyle ze w tej "grubej"
jest sporo filozofii na temat OOP jak rozniez motywacji dlaczego
Eiffel robi rozne rzeczy tak a nie inaczej. To jest dosyc ciekawe
mimo ze (jak niektorzy pisali) kontrowersyjne...

A.L.

Dnia Mon, 14 Nov 2005 16:18:19 -0600, A.L. skrobie:
> On Mon, 14 Nov 2005 23:11:59 +0100, Marcin 'Qrczak' Kowalczyk
> <qrczak@knm.org.pl> wrote:

> >A.L. <lewando_won_@kalabambuko.com> writes:
> >
> >> Zas najlepiej wyrabia "nawyki obiektowe" jezyk zwany Eiffel.
> >> Dostepne sa darmowe implemenatcje.
> >
> >S?ysza?em, ?e Meyer broni jak niepodleg?o?ci dziurawego systemu typów
> >(który w ciemno zak?ada, ?e wszystkie typy z parametrami s? kowariantne,
> >nawet kiedy z definicji typu wynika, ?e tak nie jest).

> Owszem, argumenty przedstawia w ksiazce i papierach. Ale to dobrze, bo
> wlasnie "wyrabia nawyki" i "otwiera oczy". Kto na tej grupie wie co to
> sa "typy kowariantne"?...

Nie wiem, co takiego dobrego jako nawyk programowania może mi dać znajomość
terminu "typy kowariantne".

Trzeba zresztą przyznać, że jeśli język coś takiego w ciemno zakłada, to jego
system typów jest tak trochę o dupę potłuc.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Tue, 15 Nov 2005 02:39:37 +0000 (UTC),  Aneta skrobie:
> > stwierdzenie, że ten język nie ma przyszłości, a przemysł go olał.

> Eech. Czy jak już pojawi sie jakis ciekawy, wzorcowy niemal język, 
> to musi byc na tyle "akademicki", ze czlowiek dochodzi do wniosku
> "A na na co mam się uczyc calej tej rozpasionej biblioteki klas, skoro
> pewnie nie wykorzystam tego w praktyce"? ;}

No to jest niestety fakt. Tak to już jest.

Bardzo często przyczyny tego stanu rzeczy są dość prozaiczne, jak np.
niestrawna składnia albo wymuszanie określonego stylu. A "lepszość języka"
wyznacza wiele różnych czynników, wśród których jakość projektu języka jest
nawet najmniej istotna. Nie przypadkiem najbardziej popularne języki
programowania mają najmniej czyste projekty, czy też nawet w ogóle nie mają
jednoznacznie spójnych projektów. C++ jest tu dobrym przykładem, Java prawdę
mówiąc też.

> Potem szuka kolejnego "wzorcowego", akademickiego języka, tyle
> że już mniejszego, oszczedniejszego, ot, żeby mu takie Perle i inne
> PHP [używane zawodowo] nie zatruly umyslu.

No... PHP szczęśliwie mnie ominął chwilowo, ale wiele mnie pracy kosztowało
wyzwolenie się od programowania w Perlu. Ale warto było, mimo że mnie to
trochę kosztowało (dostałem ochrzan za używanie Tcl-a, bo "kto to będzie po
tobie poprawiał").

Warto zwrócić w takich rozważaniach uwagę również na taki język jak Python. I
to, jak zdobył popularność. Myślę, że popularność Eiffla mogłaby być większa,
gdyby sensownie prowadzono jego popularyzację.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"A.L." <lewando_won_@kalabambuko.com> wrote:

> Owszem, argumenty przedstawia w ksiazce i papierach.
> Ale to dobrze, bo wlasnie "wyrabia nawyki" i "otwiera oczy".
> Kto na tej grupie wie co to sa "typy kowariantne"?...

Nie ma czegos takiego jak "typy kowariantne". Typ co najwyzej moze byc _na
pozycji_ kowariantnej.

Pozatym, akurat dla "otwarcia oczu" forsowanie _blednej_ wariancji w mysl
_praktycznosci_, jest delikatnie mowiac...


mp

" Aneta" <aneta_ra.WYTNIJ@gazeta.pl> wrote:

>  Prosty, niezbyt przegadany język, który nie
> będzie wymagal znajomości 1000 klas jak Smalltalk. Tyle,
> ze chyba sam Tcl zbytnio obiektowy nie jest?
> Chyba ze miales na mysli Incr TCL.

Jesli moge cos doradzic szczerze.
Zapomnij o Tcl-u (o iTcl-u rowniez).
Szkoda zycia tracic na cos takiego.
Tcl nie jest prosty.
Tcl jest prostacki.

AK

"Michal Przybylek" <mrp@neostrada.pl> writes:

>> Owszem, argumenty przedstawia w ksiazce i papierach.
>> Ale to dobrze, bo wlasnie "wyrabia nawyki" i "otwiera oczy".
>> Kto na tej grupie wie co to sa "typy kowariantne"?...
>
> Nie ma czegos takiego jak "typy kowariantne". Typ co najwyzej moze
> byc _na pozycji_ kowariantnej.

Inaczej: parametr typu może być kowariantny (albo kontrawariantny,
albo to i to, albo żadne). Dla każdego parametru osobno. Mój
"kowariantny typ" to był skrót myślowy na to, że wszystkie parametry
typu takie są.

W OCamlu wariancja pojawia się jawnie w składni języka tam, gdzie ma
znaczenie (w sygnaturach, gdzie opisany jest tylko "interfejs typu",
czyli jakie ma parametry).

Problem w Eifflu nie jest taki prosty, jaki się może naiwnie wydawać:
to nie tak, że wystarczyłoby przyjąć poprawną definicję wariancji
i wszystko byłoby dobrze. Problem wynika stąd, że Eiffel używa
podtypów tam, gdzie ten mechanizm się nie nadaje, a przynajmniej nie
w ten sposób - w szczególności tam, gdzie mamy metody binarne. To nie
jest tak, że sortowanie wymaga, żeby każdy element z osobna był typu
COMPARABLE (albo podtypu). Bo napisu z liczbą nie ma jak porównać,
mimo że oba obiekty "są COMPARABLE". Porównywalność jest cechą typu,
a nie obiektu. Sortowanie wymaga, żeby elementy były jakiegoś
wspólnego typu, na którym zdefiniowany jest porządek. Wspólny nadtyp
COMPARABLE źle modeluje rzeczywistość.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

> Jesli moge cos doradzic szczerze.
> Zapomnij o Tcl-u (o iTcl-u rowniez).
> Szkoda zycia tracic na cos takiego.
> Tcl nie jest prosty.
> Tcl jest prostacki.

Pozwolę sobie wtrącić. Zasadniczo też jestem zainteresowany takim
językiem jak Aneta. Piszesz że Tcl jest prostacki. Ale skoro jest klarowny,
nadaje się do prototypowania, do tego nie jest rozbudowany, jest przenosny -
to chyba można traktować to jako zalety. Jakieś tam głębokie, projektowe
kwestie językowe, lub to że obiekt posiada dwie reprezentacje - maja tu chyba
mniejsze znaczenie. No i język jest stosowany tu i ówdzie (bardzo szybki
AOLServer, scotty+tkined, ORATcl).


No bo jesli brać pod uwage Eiffel'a to czy nie jest to język z
rozbudowaną jednak biblioteka klas, w dodatku kompletnie nieprzydatny?
W dodatku najgorszy jest brak sensownego (za free) środowiska do Eiffel'a
Chyba że zalety tego języka rekompensują powyzsze.....

Pozdrawiam.



-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

 rr <rradz.WYTNIJ@gazeta.pl> napisał(a): 

> > Jesli moge cos doradzic szczerze.
> > Zapomnij o Tcl-u (o iTcl-u rowniez).
> > Szkoda zycia tracic na cos takiego.
> > Tcl nie jest prosty.
> > Tcl jest prostacki.
> 
> Pozwolę sobie wtrącić. Zasadniczo też jestem zainteresowany takim
> językiem jak Aneta. Piszesz że Tcl jest prostacki. Ale skoro jest klarowny,
> nadaje się do prototypowania, do tego nie jest rozbudowany, jest przenosny -
> to chyba można traktować to jako zalety. Jakieś tam głębokie, projektowe
> kwestie językowe, lub to że obiekt posiada dwie reprezentacje - maja tu 
chyba
> mniejsze znaczenie. No i język jest stosowany tu i ówdzie (bardzo szybki
> AOLServer, scotty+tkined, ORATcl).
> 
> 
> No bo jesli brać pod uwage Eiffel'a to czy nie jest to język z
> rozbudowaną jednak biblioteka klas, w dodatku kompletnie nieprzydatny?
> W dodatku najgorszy jest brak sensownego (za free) środowiska do Eiffel'a
> Chyba że zalety tego języka rekompensują powyzsze.....

Ostatnio na grupie pojawily sie osoby, ktore cos pisza, pisza, pisza, ale jak 
do tej pory nie wykoncepowalem o co im tak naprawde chodzi. Najpierw 
modelowanie, teraz prototypowanie. Prolog, UML, Tcl, Oz.... Moze tak 
podpowiem: jest taka wspaniala technologia IRC - prosta, przenosna i lepiej 
pasuje niz USENET do niektorych zastosowan.
And BTW: chyba ktos juz pisal, ale powtorze - do prototypowania uzywa sie 
zwykle jezyka docelowego. Ewentualnie do prototypowania GUI idealnie pasuje 
VB.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

> To nie
> jest tak, że sortowanie wymaga, żeby każdy element z osobna był typu
> COMPARABLE (albo podtypu). Bo napisu z liczbą nie ma jak porównać,
> mimo że oba obiekty "są COMPARABLE". Porównywalność jest cechą typu,
> a nie obiektu. Sortowanie wymaga, żeby elementy były jakiegoś
> wspólnego typu, na którym zdefiniowany jest porządek. Wspólny nadtyp
> COMPARABLE źle modeluje rzeczywistość.

OK


BTW: Kiedys podawalem nawet papier ntt. Giusppe Castagna'y "Covariance and
contravariance..." (nie pamietam juz dokladnie nazwy). Podobnie, pozostalym
grupowiczom radze nie czytac, bowiem czytanie aby mialo sens musi sie laczyc
ze zrozumieniem, zas zrozumienie wymaga przynajmniej minimum wysilku
intelektualnego. Tak - wysilku intelektualnego - to cos, na co tak trudno
sie zdobyc piszac kilobajty tekstu na pl.comp.objects...


mp

On Tue, 15 Nov 2005 09:32:48 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
 
>
>Nie wiem, co takiego dobrego jako nawyk programowania może mi dać znajomość
>terminu "typy kowariantne".
>
>Trzeba zresztą przyznać, że jeśli język coś takiego w ciemno zakłada, to jego
>system typów jest tak trochę o dupę potłuc.

Owszem. Tcl lepszy.

A.L.

On Tue, 15 Nov 2005 12:32:39 +0000 (UTC), " rr"
<rradz.WYTNIJ@gazeta.pl> wrote:
 
>
>No bo jesli brać pod uwage Eiffel'a to czy nie jest to język z
>rozbudowaną jednak biblioteka klas, w dodatku kompletnie nieprzydatny?
>W dodatku najgorszy jest brak sensownego (za free) środowiska do Eiffel'a

A te co sa free to nie sa sensowne?... Dlaczego?...

A.L.

On Tue, 15 Nov 2005 11:43:43 +0100, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"A.L." <lewando_won_@kalabambuko.com> wrote:
>
>> Owszem, argumenty przedstawia w ksiazce i papierach.
>> Ale to dobrze, bo wlasnie "wyrabia nawyki" i "otwiera oczy".
>> Kto na tej grupie wie co to sa "typy kowariantne"?...
>
>Nie ma czegos takiego jak "typy kowariantne". Typ co najwyzej moze byc _na
>pozycji_ kowariantnej.

Slowek sie czepiacie, Przybylek, slowek sie czepiacie...

A.L.

A.L. <alewando@kapturek62.com> napisał(a): 

> >Nie wiem, co takiego dobrego jako nawyk programowania może mi dać znajomość
> >terminu "typy kowariantne".
> >
> >Trzeba zresztą przyznać, że jeśli język coś takiego w ciemno zakłada, to 
jego
> >system typów jest tak trochę o dupę potłuc.
> 
> Owszem. Tcl lepszy.

C++. Tylko C++.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Dnia Tue, 15 Nov 2005 07:32:48 -0600, A.L. skrobie:
> On Tue, 15 Nov 2005 09:32:48 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>  
> >
> >Nie wiem, co takiego dobrego jako nawyk programowania może mi dać znajomość
> >terminu "typy kowariantne".
> >
> >Trzeba zresztą przyznać, że jeśli język coś takiego w ciemno zakłada, to jego
> >system typów jest tak trochę o dupę potłuc.

> Owszem. Tcl lepszy.

Przynajmniej nie kręci, że ma szczelny system typów. Że ma wogle.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Tue, 15 Nov 2005 13:46:26 +0000 (UTC), "Aleksander Galicki"
<tretete.WYTNIJ@gazeta.pl> wrote:

>A.L. <alewando@kapturek62.com> napisał(a): 
>
>> >Nie wiem, co takiego dobrego jako nawyk programowania może mi dać znajomość
>> >terminu "typy kowariantne".
>> >
>> >Trzeba zresztą przyznać, że jeśli język coś takiego w ciemno zakłada, to 
>jego
>> >system typów jest tak trochę o dupę potłuc.
>> 
>> Owszem. Tcl lepszy.
>
>C++. Tylko C++.
>

Radykal z Pana, Panie Galicki...

A.L.

A.L. <alewando@kapturek62.com> napisał(a): 

> >> >Nie wiem, co takiego dobrego jako nawyk programowania może mi dać 
znajomość
> >> >terminu "typy kowariantne".
> >> >
> >> >Trzeba zresztą przyznać, że jeśli język coś takiego w ciemno zakłada, 
to 
> >jego
> >> >system typów jest tak trochę o dupę potłuc.
> >> 
> >> Owszem. Tcl lepszy.
> >
> >C++. Tylko C++.
> >
> 
> Radykal z Pana, Panie Galicki...

I purysta. Ani Eiffel, ani Java nie moga zaspokoic moich wysublimowanych 
zmyslow technicznych. Tam trzeba kastowac, nie ma makr, template'y sa do 
dupy, no i ta paskudna kowariancja o ktorej nic nie wiem, ale ktora jest 
niewatpliwie zla. Prawdziwi programisci programuja w C++.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> A te co sa free to nie sa sensowne?... Dlaczego?...

No fakt. Znalazłem wlasnie sensownie wyglądajacy VisualEiffel na
gplu. Zasadniczo na stronach podaja jedynie linka do SmartEiffel'a - a 
to nie wyglada zbyt zachęcajaco.

Tylko czy rzeczywiście polecalbyś Eiffel'a jako jezyk mniej rozbudowany 
niż np. C++ w którym przyjemnie poprogramuje sie obiektowo?
Z tego co zauważylem klasa definiująca listy jednokierunkowe ma kilkadziesiat
operacji w interfejsie publicznym (inna sprawa że zerkam na niego od 2-3
godzin, wiec wybacz jesli plote bzdury..

Pozdraiwam


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Tue, 15 Nov 2005 14:21:35 +0000 (UTC), " rr"
<rradz.WYTNIJ@gazeta.pl> wrote:

>> A te co sa free to nie sa sensowne?... Dlaczego?...
>
>No fakt. Znalazłem wlasnie sensownie wyglądajacy VisualEiffel na
>gplu. Zasadniczo na stronach podaja jedynie linka do SmartEiffel'a - a 
>to nie wyglada zbyt zachęcajaco.
>

A tutaj?...

http://www.eiffel.com/downloads/index.html#studio

Eiffel Software is pleased to provide a Free Edition of
EiffelStudioTM, EiffelEnvisionTM, and Eiffel for ASP.NET. We
encourage you to download them and use them as often as you like, as
our Free Editions will not expire. The Free Edition license is for
non-commercial use only. EiffelStudio Free Edition has no
limitations and offers the same functionalities as EiffelStudio
Enterprise Edition. The only difference is that it comes with a
non-commercial license and a splash screen reminder. To compare the
differences between the Free and Enterprise Editions of our
products, click here for EiffelStudio and here for EiffelEnvision.
Please check the system requirements (EiffelStudio | EiffelEnvision)
before downloading.

A.L.

> A tutaj?...

No nie jest to do końca free (w końcu komercyjnie używać nie można. Z drugiej
strony - pewnie i okazji ku temu nie będzoe ;)) ale miło z ich strony. 

No i to jest zachęcające:

"Concurrent engineering allows the use of EiffelStudio to automatically
generate BON diagrams to see and interact with the overall design of your
system as you engineer it".

Pozdrawiam


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > Owszem, argumenty przedstawia w ksiazce i papierach.
> > Ale to dobrze, bo wlasnie "wyrabia nawyki" i "otwiera oczy".
> > Kto na tej grupie wie co to sa "typy kowariantne"?...
>
> Nie wiem, co takiego dobrego jako nawyk programowania może
> mi dać znajomość terminu "typy kowariantne".
>
> Trzeba zresztą przyznać, że jeśli język coś takiego w ciemno
> zakłada, to jego system typów jest tak trochę o dupę potłuc.

Tym razem przeszedles samego siebie.

Juz dawno sie tak nie usmialem :-)


mp

"Michal Przybylek" <mrp@neostrada.pl> writes:

[...]

> Nie ma czegos takiego jak "typy kowariantne". Typ co najwyzej moze
> byc _na pozycji_ kowariantnej.

Czy to ma jakiś związek z inwariantami obiektu?  
I czym różni się typ od klasy?

" rr" <rradz.WYTNIJ@gazeta.pl> writes:

[...]

> W dodatku najgorszy jest brak sensownego (za free) środowiska 
> do Eiffel'a

Bez przesady.  Zawsze jest Emacs plus np. Etags i tym podobne
programy.

"Aleksander Galicki" <tretete.WYTNIJ@gazeta.pl> writes:

[...]

> And BTW: chyba ktos juz pisal, ale powtorze - do prototypowania
> uzywa sie zwykle jezyka docelowego. Ewentualnie do prototypowania
> GUI idealnie pasuje VB.

Do prototypowania GUI świetnie się nadaje blok i kredki.

Dnia Tue, 15 Nov 2005 16:49:30 +0100, Michal Przybylek skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > > Owszem, argumenty przedstawia w ksiazce i papierach.
> > > Ale to dobrze, bo wlasnie "wyrabia nawyki" i "otwiera oczy".
> > > Kto na tej grupie wie co to sa "typy kowariantne"?...
> >
> > Nie wiem, co takiego dobrego jako nawyk programowania może
> > mi dać znajomość terminu "typy kowariantne".
> >
> > Trzeba zresztą przyznać, że jeśli język coś takiego w ciemno
> > zakłada, to jego system typów jest tak trochę o dupę potłuc.

> Tym razem przeszedles samego siebie.

> Juz dawno sie tak nie usmialem :-)

Nie przejmuj się, ja się z twojej co drugiej tak uśmiewam.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Tue, 15 Nov 2005 12:47:36 +0000 (UTC), Aleksander Galicki skrobie:
> And BTW: chyba ktos juz pisal, ale powtorze - do prototypowania uzywa sie 
> zwykle jezyka docelowego. Ewentualnie do prototypowania GUI idealnie pasuje 
> VB.

"Idealnie" to do prototypowania (a nawet tworzenia ;) GUI nadaje sie Tk. ;)

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > Juz dawno sie tak nie usmialem :-)
>
> Nie przejmuj się

Alez ja sie ciesze :-)


mp

"Piotr Dembiński" <pdemb@gazeta.pl> wrote:

> > Nie ma czegos takiego jak "typy kowariantne".
> > Typ co najwyzej moze byc _na pozycji_ kowariantnej.
>
> Czy to ma jakiś związek z inwariantami obiektu?
> I czym różni się typ od klasy?

Zobacz np. u Cardelli'ego w "A Theory Of Objects".

Najkrocej mowiac:

- nie (o ile masz namysli inwarianty w sensie Eiffel'a),
- klasa _moze_ sluzyc do _opisu_ typu.


mp

On Tue, 15 Nov 2005 18:06:47 +0100, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"Piotr Dembi?ski" <pdemb@gazeta.pl> wrote:
>
>> > Nie ma czegos takiego jak "typy kowariantne".
>> > Typ co najwyzej moze byc _na pozycji_ kowariantnej.
>>
>> Czy to ma jaki? zwi?zek z inwariantami obiektu?
>> I czym ró?ni si? typ od klasy?
>
>Zobacz np. u Cardelli'ego w "A Theory Of Objects".
>

Ja wole czytac, na przyklad, Kamasutre....

A.L.

On Tue, 15 Nov 2005 18:12:10 +0100, "Michal Przybylek"
<mrp@neostrada.pl> wrote:

>"A.L." <alewando@kapturek62.com> wrote:
>
>> >Nie ma czegos takiego jak "typy kowariantne". Typ co najwyzej
>> >moze byc _na pozycji_ kowariantnej.
>>
>> Slowek sie czepiacie, Przybylek, slowek sie czepiacie...
>
>Nie. Ta terminologia po prostu kluje mnie w oczy (jest kompletnie bez
>sensu). A slysze ja juz po ktorys raz...
>
>Ty powtorzyles po Qrczaku, a Qrczak sie juz wytlumaczyl. Wiec jest OK.
>

I don't care.

A.L.

"A.L." <alewando@kapturek62.com> wrote:

> >Nie ma czegos takiego jak "typy kowariantne". Typ co najwyzej
> >moze byc _na pozycji_ kowariantnej.
>
> Slowek sie czepiacie, Przybylek, slowek sie czepiacie...

Nie. Ta terminologia po prostu kluje mnie w oczy (jest kompletnie bez
sensu). A slysze ja juz po ktorys raz...

Ty powtorzyles po Qrczaku, a Qrczak sie juz wytlumaczyl. Wiec jest OK.


mp

Dnia Tue, 15 Nov 2005 11:09:58 -0600, A.L. skrobie:
> On Tue, 15 Nov 2005 18:06:47 +0100, "Michal Przybylek"
> <mrp@neostrada.pl> wrote:

> >"Piotr Dembi?ski" <pdemb@gazeta.pl> wrote:
> >
> >> > Nie ma czegos takiego jak "typy kowariantne".
> >> > Typ co najwyzej moze byc _na pozycji_ kowariantnej.
> >>
> >> Czy to ma jaki? zwi?zek z inwariantami obiektu?
> >> I czym ró?ni si? typ od klasy?
> >
> >Zobacz np. u Cardelli'ego w "A Theory Of Objects".
> >

> Ja wole czytac, na przyklad, Kamasutre....

Cóż, wydawało mi się, że znacznie sensowniej jest ją czytać w młodszym wieku
(choć w dzisiejszych czasach istnieje raczej tendencja do oglądania ;)))


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Tue, 15 Nov 2005 19:27:25 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>Dnia Tue, 15 Nov 2005 11:09:58 -0600, A.L. skrobie:
>> On Tue, 15 Nov 2005 18:06:47 +0100, "Michal Przybylek"
>> <mrp@neostrada.pl> wrote:
>
>> >"Piotr Dembi?ski" <pdemb@gazeta.pl> wrote:
>> >
>> >> > Nie ma czegos takiego jak "typy kowariantne".
>> >> > Typ co najwyzej moze byc _na pozycji_ kowariantnej.
>> >>
>> >> Czy to ma jaki? zwi?zek z inwariantami obiektu?
>> >> I czym ró?ni si? typ od klasy?
>> >
>> >Zobacz np. u Cardelli'ego w "A Theory Of Objects".
>> >
>
>> Ja wole czytac, na przyklad, Kamasutre....
>
>Có¿, wydawa³o mi siê, ¿e znacznie sensowniej jest j± czytaæ w m³odszym wieku
>(choæ w dzisiejszych czasach istnieje raczej tendencja do ogl±dania ;)))

Nigdy nie jest za pozno, zwlaszcza ze po niejakich doswiadczenich
wlasnych odbiera sie ja nieco inaczej niz w wieku
przed-doswiadczeniowym :) Zreszta, kto tak naprawde czytal Kamasutre,
te tlumaczona z oryginalu,  a nei albumy z kolorowymi obrazkami...

A.L.

"Aleksander Galicki" <tretete.WYTNIJ@gazeta.pl> wrote:

> C++. Tylko C++.

Nieprawda.
C
czyste C

PS: z dodatkiem assemblera

AK

"Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>> Owszem. Tcl lepszy.
>
> Przynajmniej nie kręci, że ma szczelny system typów.
> Że ma wogle.

Ba ! On nawet gramatyki nie ma.

AK

Dnia Wed, 16 Nov 2005 10:59:35 +0100, Karpierz, Adam skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> >> Owszem. Tcl lepszy.
> >
> > Przynajmniej nie kręci, że ma szczelny system typów.
> > Że ma wogle.

> Ba ! On nawet gramatyki nie ma.

Znów zagłębiamy się w zagadnienie, na ile "biblioteka standardowa" jest
częścią języka.

Faktem jest, że gdyby chcieć mówić tylko o samym języku, to owszem, Tcl
gramatyki nie posiada. Bo i faktycznie w Tcl-u nie ma nawet ani jednego słowa
kluczowego; wszelkie konstrukcje strukturalne, również return, są tylko
komendami, jak wszystkie inne, które użytkownik może sobie samemu zdefiniować.

Jeśli nie zauważyłeś, w Smalltalku jest podobnie ;)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"A.L." <lewando_won_@kalabambuko.com> wrote:

> >> Slowek sie czepiacie, Przybylek, slowek sie czepiacie...
> >
> >Nie. Ta terminologia po prostu kluje mnie w oczy (jest kompletnie bez
> >sensu). A slysze ja juz po ktorys raz...
> >
> >Ty powtorzyles po Qrczaku, a Qrczak sie juz wytlumaczyl. Wiec jest OK.
> >
> 
> I don't care.

Nieprawda. Inaczej zachowal bys ta informacje dla siebie.


mp