🚀 go-pugleaf

On Tue, 1 Nov 2005 13:21:49 +0000 (UTC), "Paweł"
<pawellt@gazeta.SKASUJ-TO.pl> wrote:
 
> 
>- podkresla sie wszedzie ze Ada ma prosta, czytelna skladnie, ktora latwo 
>opanowac. 

Ada jest zajebiscie skomplikowana. tylko C++ jest bardziej
skomplikowany, ale za to Ada prowstala jako projet a nie kolejne
warstwy smeicia kladzine na warswtach smiecia. Innymi slowy, jest
bardzo logiczna.

>Rowniez mechanizmy wspolbieznosci sa klarownie zaimplementowane. 
>Martwi mnie tylko ta "silna typizacja". Czy to rzeczywiscie utrudnia 
>programowanie? 

Owszem. Utrudnia programowanei w stylu "najpierw programujemy a
potem myslimy". Ulubione narzedzie specow od Extreme Programming
czyli refaktoryzacja sprawdza sie w Adzie tak sobie.
 
> 
>- Czy znajomosc Ady ulatwi jakos prace w innych jezykach obiektowych? Czy 
>raczej obiektowosc Ady jest zasadniczo rozna od obiektowosci w innych 
>jezykach OOP? 
> 

Nie. Obiektowosc Ady jest deko inna niz obiektowosc w innych
jezykach.

>- Co to znaczy ze Ada jest doskonala do prototypowania aplikacji? Chodzi o 
>pakiety generic, czy moze jakies inne cechy? 

Ada sie nadaje do roznych rzeczy, ale nie do prototypowania.

A.L.

> Ada jest zajebiscie skomplikowana. tylko C++ jest bardziej 
> skomplikowany, ale za to Ada prowstala jako projet a nie kolejne 
> warstwy smeicia kladzine na warswtach smiecia. Innymi slowy, jest 
> bardzo logiczna. 
 
Mozesz uzasadnic? Jak czytalem wstep do ksiazki Ada 95 Huzara, pisal ze 
zaleta Ady jest prostota i czytelnosc. Poza tym tak czytam sobie: 
http://www.adahome.com/Ammo/cpp2ada.html 
...i wynika z tego, ze w Adzie sporo rzeczy jest zrobione prosciej, 
klarowniej. Przeciez nie trzeba chyba wykorzystywac wszystkich aspektow 
jezyka, wszystkich Aneksow Ady, wszystkich skomplikowanych mechanizmow. Znam 
ludzi programujacych dobrze w Javie (fuj), ktorzy nie uzywaja Beansow, RMI 
ani wspolbieznosci. 
 
Poza tym kurcze. Jak nie Ada i nie Smalltalk to co proponujesz? Bo z rozmowy 
na temat tych dwoch wynika, ze w dzisiejszych czasach nie oplaca sie brac za 
porzadnie zaprojektowane jezyki (bo praktycznie nie istnieja na rynku) tylko 
popluczyny w stylu C++, Java lub balaganiarski i slaby PHP5 (jesli o 
obiektowosc chodzi). A moze Python? Tyle ze tez na rynku go nie uswiadczy za 
bardzo. No i chyba dosyc malo dojrzaly i b. mlody to jezyk.. 
 
Pozdrawiam i dzieki za szczerosc :) 

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

Dnia Tue, 1 Nov 2005 13:21:49 +0000 (UTC), Paweł skrobie:
> - podkresla sie wszedzie ze Ada ma prosta, czytelna skladnie, ktora latwo 
> opanowac.

Bardzo podobną do Pascala. Jeśli Pascala ktoś uważa za czytelny, to może to
samo sądzić o Adzie. Ja się akurat z tym nie zgadzam, najpewniej to kwestia
gustu, podejścia, przyzwyczajeń itp.

> Rowniez mechanizmy wspolbieznosci sa klarownie zaimplementowane. 
> Martwi mnie tylko ta "silna typizacja". Czy to rzeczywiscie utrudnia 
> programowanie?

Silna typizacja utrudnia programowanie _OBIEKTOWE_.

> Czy to nie jest taka kolejna "pulapka" jak to, ze aby programowac w
> teoretycznie prostym Smalltalku trzeba poznac mase klas z ich protokolami?  

W każdym języku musisz poznać od groma kodu, który już jest napisany, plus
interfejsów do całej masy bibliotek.

Zastanów się najpierw, do czego ci ta Ada niby jest potrzebna, czy jakikolwiek
inny język, jakiego chciałbyś się nauczyć.

Jeśli dla rozrywki/nauki/treningu/przyjemności/z-ciekawości - oczywiście, że
się ucz. Każdy nowy język poszerzy twoje spojrzenie na kwestię tworzenia
oprogramowania.

Jeśli miałbyś to traktować jak inwestycję w swoje umiejętności - wydaje mi
się, że powinieneś sobie darować.


-- 
//  _    ___         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, 1 Nov 2005 15:07:03 +0000 (UTC), "Pawe³"
<pawellt@WYTNIJ.gazeta.pl> wrote:

>> Ada jest zajebiscie skomplikowana. tylko C++ jest bardziej 
>> skomplikowany, ale za to Ada prowstala jako projet a nie kolejne 
>> warstwy smeicia kladzine na warswtach smiecia. Innymi slowy, jest 
>> bardzo logiczna. 
> 
>Mozesz uzasadnic? Jak czytalem wstep do ksiazki Ada 95 Huzara, pisal ze 
>zaleta Ady jest prostota i czytelnosc. Poza tym tak czytam sobie: 
>http://www.adahome.com/Ammo/cpp2ada.html 
>...i wynika z tego, ze w Adzie sporo rzeczy jest zrobione prosciej, 
>klarowniej. 

No przeciez ja tak wlasnei pisalem... Tyle ze z faktu ze "cos zrobiono
klarowniej" wcale nie wynika ze to cos jest proste.

>Przeciez nie trzeba chyba wykorzystywac wszystkich aspektow 
>jezyka, wszystkich Aneksow Ady, wszystkich skomplikowanych mechanizmow. 

Niestety, trzeba znac dosyc duzo Ady i to dokladnie zeby ja zaczac
uzywac.

>Poza tym kurcze. Jak nie Ada i nie Smalltalk to co proponujesz? Bo z rozmowy 
>na temat tych dwoch wynika, ze w dzisiejszych czasach nie oplaca sie brac za 
>porzadnie zaprojektowane jezyki (bo praktycznie nie istnieja na rynku) tylko 
>popluczyny w stylu C++, Java lub balaganiarski i slaby PHP5 (jesli o 
>obiektowosc chodzi). A moze Python? Tyle ze tez na rynku go nie uswiadczy za 
>bardzo. No i chyba dosyc malo dojrzaly i b. mlody to jezyk.. 

Proponuje do CZEGO?.... Sa dwie rozne rzeczy: jezyki uzywane w
przemysle i jezyki uzywane w ramach hobby i dla przyjemnosci. Dla
przyjemnosci to mozesz uzywac czego chcesz i co bardziej lubisz.
Pzremysl uzywa tego czego uzywa: Javy, Cobolu, C++ i VB

A.L.

P.S. Acha, proponuje jeszcze Eiffel. No i Ruby. No i Rebol.

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

>Dnia Tue, 1 Nov 2005 13:21:49 +0000 (UTC), Pawe³ skrobie:
>> - podkresla sie wszedzie ze Ada ma prosta, czytelna skladnie, ktora latwo 
>> opanowac.
>
>Bardzo podobn± do Pascala. Je¶li Pascala kto¶ uwa¿a za czytelny, to mo¿e to
>samo s±dziæ o Adzie. Ja siê akurat z tym nie zgadzam, najpewniej to kwestia
>gustu, podej¶cia, przyzwyczajeñ itp.
>
>> Rowniez mechanizmy wspolbieznosci sa klarownie zaimplementowane. 
>> Martwi mnie tylko ta "silna typizacja". Czy to rzeczywiscie utrudnia 
>> programowanie?
>
>Silna typizacja utrudnia programowanie _OBIEKTOWE_.
>

Nonsens.

A.L.

On Tue, 01 Nov 2005 10:16:33 -0600, A.L.
<lewando_won_@kalabambuko.com> wrote:
 
>
>Proponuje do CZEGO?.... Sa dwie rozne rzeczy: jezyki uzywane w
>przemysle i jezyki uzywane w ramach hobby i dla przyjemnosci. Dla
>przyjemnosci to mozesz uzywac czego chcesz i co bardziej lubisz.
>Pzremysl uzywa tego czego uzywa: Javy, Cobolu, C++ i VB

Zapomnialem dopisac: Perla.

A.L.

> Zastanów się najpierw, do czego ci ta Ada niby jest potrzebna, czy 
jakikolwiek 
> inny język, jakiego chciałbyś się nauczyć. 
 
to jest tak, ze znam jako tako C i Perla a chcialbym poznac jakis obiektowy, 
solidny jezyk ogolnego zastosowania. Poki co nie potrzebuje go do niczego 
konkretnego (przynajmniej w tej chwili). Z jednej strony chcialbym zeby byl 
to ciekawy, dobrze zaprojektowany jezyk, ktorego nauka sprawia przyjemnosc - 
z drugiej zeby nie byl ZUPELNIE egzotyczny i zeby jego znajomosc zaowocowala 
chociaz na tyle, zeby dac solidne podstawy (i dobre nawyki obiektowe) do 
pracy z jakims innym jezykiem obiektowym, ktory nie jest doskonaly, ale duzo 
go na rynku (np. PHP5). 
 
Do Smalltalka zachecily mnie glownie opinie, ze jest rewelacyjnie 
zaprojektowany, ze swietnie robi sie w nim refaktoring, ze ma swietny 
debugger, ze prosciutko tworzy sie w nim aplikacje okienkowe. Tylko te 
tysiace klas....... ;) 
 
Pozdrawiam 

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

On Tue, 1 Nov 2005 17:01:14 +0000 (UTC), " Pawe³"
<pawellt@WYTNIJ.gazeta.pl> wrote:

>> Zastanów siê najpierw, do czego ci ta Ada niby jest potrzebna, czy 
>jakikolwiek 
>> inny jêzyk, jakiego chcia³by¶ siê nauczyæ. 
> 
>to jest tak, ze znam jako tako C i Perla a chcialbym poznac jakis obiektowy, 
>solidny jezyk ogolnego zastosowania. Poki co nie potrzebuje go do niczego 
>konkretnego (przynajmniej w tej chwili). Z jednej strony chcialbym zeby byl 
>to ciekawy, dobrze zaprojektowany jezyk, ktorego nauka sprawia przyjemnosc - 
>z drugiej zeby nie byl ZUPELNIE egzotyczny i zeby jego znajomosc zaowocowala 
>chociaz na tyle, zeby dac solidne podstawy (i dobre nawyki obiektowe) do 
>pracy z jakims innym jezykiem obiektowym, ktory nie jest doskonaly, ale duzo 
>go na rynku (np. PHP5). 
> 

Java?... Co by nie powiedziec, Java jest dosyc dobrze zaprojektowana,
solidnie obiektowa, nie zadana hybryda, ma rozne ciekawe wlasciwosci i
biblioteki.

Jak Java, to 1.5 i Eclipse jako srodowisko. Refaktoryzacja rownie
przyjemna jak w Smalltalku. No i duzo jej na rynku.

A.L.

P.S. Co to jest PHP5?... Nie widzialem go jakos "na rynku"...

 

" Paweł" <pawellt@WYTNIJ.gazeta.pl> wrote:

> to jest tak, ze znam jako tako C i Perla a chcialbym poznac jakis 
> obiektowy,
> solidny jezyk ogolnego zastosowania.

Patrzac na sprawe praktycznie, proponowalbym Jave lub C#. Nie sa to jezyki 
bez wad, ale posiadaja doskonale implementacje i olbrzymia wrecz ilosc 
dostepnych bibliotek jak i tez roznego rodzaju narzedzi do programowania. 
Plusem jest rowniez to, ze znajac jeden z nich, mozna stosunkowo latwo 
"przejsc" na drugi. Oczywiscie pomijajac roznice platformowe, ktore nawiasem 
mowiac, wydaja mi sie znacznie istotniejsze niz sam jezyk programowania. 
Jezyka bowiem (mam tu na mysli te z gatunku "normalnych"), uczymy sie w 
kilka dni lub tygodni,  platformy natomiast, znacznie, znacznie dluzej.

Robert Perlinski 

> Java?... Co by nie powiedziec, Java jest dosyc dobrze zaprojektowana, 
> solidnie obiektowa, nie zadana hybryda, ma rozne ciekawe wlasciwosci i 
> biblioteki. 
 
Czyli pewnie skoncze jak wiekszosc ;) Z drugiej strony zapewne masz racje, 
bo jednak Java zaczyna powoli wypierac i Ade (wspolbieznosc, progr. 
rozproszone, RMI) i Smalltalka. 
 
> P.S. Co to jest PHP5?... Nie widzialem go jakos "na rynku"... 
 
to nowa wersja cholernie jednak popularnego jezyka PHP (moze nie na rynku 
enterprise, ale w srednich projektach - ktorych przeciez masa na rynku). 
PHP5 jest w zasadzie solidna wersja, w wiekszosci przepisana od nowa, w 
ktorej jest obiektowosc z prawdziwego zdarzenia. Troche podobne to teraz do 
Javy. Jednak przez zachowanie pewnej kompatybilnosci wstecz, jest to jednak 
mala "hybryda jezykowa" ;) 
 
p.s Acha. Pisales, ze "na rynku" jest dzisiaj Cobol. To prawda? Wydawalo mi 
sie zawsze, ze to wybitnie strukturalny, prymitywny jezyk. Dobry w czasach 
Odry, i VAX'ów. 
 
pozdrawiam i dzieki Wam za wskazowki. 
 

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

On Tue, 01 Nov 2005 17:01:14 +0000,  Paweł wrote:

> to jest tak, ze znam jako tako C i Perla a chcialbym poznac jakis obiektowy, 
> solidny jezyk ogolnego zastosowania. Poki co nie potrzebuje go do niczego 
> konkretnego (przynajmniej w tej chwili). Z jednej strony chcialbym zeby byl 
> to ciekawy, dobrze zaprojektowany jezyk, ktorego nauka sprawia przyjemnosc - 
> z drugiej zeby nie byl ZUPELNIE egzotyczny i zeby jego znajomosc zaowocowala 
> chociaz na tyle, zeby dac solidne podstawy (i dobre nawyki obiektowe) do 
> pracy z jakims innym jezykiem obiektowym, ktory nie jest doskonaly, ale duzo 
> go na rynku (np. PHP5). 

Moze pobaw sie Ruby ? Jesli juz troche liznales Smalltalka, bedzie nawet
latwiej.

  
> Do Smalltalka zachecily mnie glownie opinie, ze jest rewelacyjnie 
> zaprojektowany, ze swietnie robi sie w nim refaktoring, ze ma swietny 
> debugger, ze prosciutko tworzy sie w nim aplikacje okienkowe. Tylko te 
> tysiace klas....... ;) 

Smalltalk umarl, jesli chodzi o rynek. W Telekomunikacji tez juz coraz
mniej sie go uzywa. Weszla Java, pelna para. No i Objective CHILL

Grzechu

On Tue, 01 Nov 2005 11:08:53 -0600, A.L wrote:

> Java?... Co by nie powiedziec, Java jest dosyc dobrze zaprojektowana,
> solidnie obiektowa, nie zadana hybryda, ma rozne ciekawe wlasciwosci i
> biblioteki.

Java solidnie obiektowa ?? muhahaha. Nie ma objektu integer i innych
prymitywnych. Dupa a nie obiektowosc. Smalltalk i Ruby sa tu lepsze. Tylko
faktycznie malo rynkowe.

Grzechu

On Tue, 01 Nov 2005 19:51:21 +0100, Grzegorz Rumatowski
<grzechu@noname.us> wrote:

>On Tue, 01 Nov 2005 11:08:53 -0600, A.L wrote:
>
>> Java?... Co by nie powiedziec, Java jest dosyc dobrze zaprojektowana,
>> solidnie obiektowa, nie zadana hybryda, ma rozne ciekawe wlasciwosci i
>> biblioteki.
>
>Java solidnie obiektowa ?? muhahaha. Nie ma objektu integer i innych
>prymitywnych. Dupa a nie obiektowosc. Smalltalk i Ruby sa tu lepsze. Tylko
>faktycznie malo rynkowe.

Qrde, zanim zaczniesz pisac o jakims jezyku to sie go naucz. Jak to
nie ma "obiektu integer"?.. A o klasie Integer slyszales? A wiesz co
to jest "boxing"?... No wlasnie, nie wiesz...

A.L.

P.S. Osobnikow z klubu "muhahaha" czy "buhahahaah" wpuszczam od razu
do Kill Fajla. Z reguly nie maja pojecia o niczym.

On Tue, 1 Nov 2005 18:05:32 +0000 (UTC), "Pawe³"
<pawellt@WYTNIJ.gazeta.pl> wrote:

> 
> 
>p.s Acha. Pisales, ze "na rynku" jest dzisiaj Cobol. To prawda? Wydawalo mi 
>sie zawsze, ze to wybitnie strukturalny, prymitywny jezyk. Dobry w czasach 
>Odry, i VAX'ów. 

Cobol ma sie dobrze, zwlaszcza ten obiektowy.

A.L.

A.L. <alewando@kapturek62.com> writes:

[...]

> Ulubione narzedzie specow od Extreme Programming czyli
> refaktoryzacja sprawdza sie w Adzie tak sobie.

Refaktoryzacja nie jest narzędziem, tylko techniką programistyczną 
i w Adzie powinna się sprawdzać tak samo dobrze, jak w każdym innym 
języku programowania, bo nie tyle dotyczy języka, co struktury
systemu: rozdziału odpowiedzialności na klasy i obiekty, podziału 
kodu na pliki etc.

-- 
http://www.piotr.dembiński.prv.pl

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

[...]

> Silna typizacja utrudnia programowanie _OBIEKTOWE_.

Chyba chodziło o statyczną typizację.  Silne typy są na przykład w Pythonie.

" Paweł" <pawellt@WYTNIJ.gazeta.pl> writes:

[...]

> Do Smalltalka zachecily mnie glownie opinie, ze jest rewelacyjnie
> zaprojektowany,

IMO Smalltalk jest tak samo dobrze zaprojektowany, jak Lisp :)

Dnia Tue, 01 Nov 2005 13:02:29 -0600, A.L. skrobie:
> On Tue, 01 Nov 2005 19:51:21 +0100, Grzegorz Rumatowski
> <grzechu@noname.us> wrote:

> >On Tue, 01 Nov 2005 11:08:53 -0600, A.L wrote:
> >
> >> Java?... Co by nie powiedziec, Java jest dosyc dobrze zaprojektowana,
> >> solidnie obiektowa, nie zadana hybryda, ma rozne ciekawe wlasciwosci i
> >> biblioteki.
> >
> >Java solidnie obiektowa ?? muhahaha. Nie ma objektu integer i innych
> >prymitywnych. Dupa a nie obiektowosc. Smalltalk i Ruby sa tu lepsze. Tylko
> >faktycznie malo rynkowe.

> Qrde, zanim zaczniesz pisac o jakims jezyku to sie go naucz. Jak to
> nie ma "obiektu integer"?.. A o klasie Integer slyszales? A wiesz co
> to jest "boxing"?... No wlasnie, nie wiesz...

Panie AL. Zanim zaczniesz pan obsobaczać ludzi za nieznajomość danego języka,
to przyjrzyj się pan najpierw niektórym bardzo istotnym sprawom.

W Smalltalku w wyrażeniu typu "5+2*3" występują NAPRAWDĘ prawdziwe obiekty
prawdziwych klas (SmallInteger na przykład).

W Javie jest ten Integer - i co z tego? Czy obiekty klasy Integer występują w
powyższym wyrażeniu? Czy ktokolwiek planując jakikolwiek algorytm zawierający
obliczenia stosuje klasę Integer, czy wbudowany typ int? Czy na obiektach
klasy Integer można wykonywać operacje za pomocą operatorów arytmetycznych?
Pewnie, jak se pan rozpakujesz do 'int'.

Oczywiście, że można z pełną odpowiedzialnością stwierdzić, że takie
rozwiązanie ma oczywiście swoje racjonalne uzasadnienie itd. (ciekawe, że to
jest tłumaczenie identyczne co w przypadku C++), ale faktu nie zmienia.

> P.S. Osobnikow z klubu "muhahaha" czy "buhahahaah" wpuszczam od razu
> do Kill Fajla. Z reguly nie maja pojecia o niczym.

Dołącz pan najlepiej jeszcze takich, co odpowiadają na posty jednym słowem:
"Nonsens".


-- 
//  _    ___         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, 1 Nov 2005 22:54:21 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> .
>
>W Javie jest ten Integer - i co z tego? Czy obiekty klasy Integer wystêpuj± w
>powy¿szym wyra¿eniu? Czy ktokolwiek planuj±c jakikolwiek algorytm zawieraj±cy
>obliczenia stosuje klasê Integer, czy wbudowany typ int? Czy na obiektach
>klasy Integer mo¿na wykonywaæ operacje za pomoc± operatorów arytmetycznych?
>Pewnie, jak se pan rozpakujesz do 'int'.

Obywatelu, jak pieprzyc to z sensem. To nie ja, to Mleczko.

public class IntTest {
    
    Integer a = new Integer(10);
    Integer b = new Integer(20);
    
    int compute() {
        return a + b;
    }
}


public class IntTestTest extends TestCase {

    public final void testCompute() {
        IntTest t = new IntTest();
        System.out.println(t.compute());
    }
}

Rezultat

30

A.L.

On Tue, 01 Nov 2005 23:24:23 +0100, pdemb@gazeta.pl (Piotr
Dembiński) wrote:

>Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
>
>[...]
>
>> Silna typizacja utrudnia programowanie _OBIEKTOWE_.
>
>Chyba chodziło o statyczną typizację.  Silne typy są na przykład w Pythonie.

A dlaczego statyczna typizacja utrudnia programwoanie obiektowe?...

A.L.

Dnia Tue, 01 Nov 2005 17:23:22 -0600, A.L. skrobie:
> On Tue, 1 Nov 2005 22:54:21 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > .
> >
> >W Javie jest ten Integer - i co z tego? Czy obiekty klasy Integer wyst?puj? w
> >powy?szym wyra?eniu? Czy ktokolwiek planuj?c jakikolwiek algorytm zawieraj?cy
> >obliczenia stosuje klas? Integer, czy wbudowany typ int? Czy na obiektach
> >klasy Integer mo?na wykonywa? operacje za pomoc? operatorów arytmetycznych?
> >Pewnie, jak se pan rozpakujesz do 'int'.

> Obywatelu, jak pieprzyc to z sensem. To nie ja, to Mleczko.

> public class IntTest {
>     
>     Integer a = new Integer(10);
>     Integer b = new Integer(20);
>     
>     int compute() {
>         return a + b;
>     }
> }

Ups, zapomnialem ;)

Co nie zmienia jednak faktu, że niestety klasy Integer nie wykorzystuje się w
Javie do niczego innego, jak do boksowania; "normalnym" sposobem użycia
całkowitych w Javie jest wbudowany 'int'. W "Smellticku" tak nie ma (bo nie ma
tam w ogóle niczego takiego).


-- 
//  _    ___         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, 01 Nov 2005 21:50:04 -0600, A.L. skrobie:
> On Tue, 01 Nov 2005 23:24:23 +0100, pdemb@gazeta.pl (Piotr
> Dembiński) wrote:

> >Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
> >
> >[...]
> >
> >> Silna typizacja utrudnia programowanie _OBIEKTOWE_.
> >
> >Chyba chodziło o statyczną typizację.  Silne typy są na przykład w Pythonie.

> A dlaczego statyczna typizacja utrudnia programwoanie obiektowe?...

Bo żeby skorzystać z pełnego generyzmu, jaki wnosi programowanie obiektowe,
trzeba stosować rzutowanie.

-- 
//  _    ___         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 Wed, 2 Nov 2005 12:33:43 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:


>Ups, zapomnialem ;)
>
>Co nie zmienia jednak faktu, że niestety klasy Integer nie wykorzystuje się w
>Javie do niczego innego, jak do boksowania; "normalnym" sposobem użycia
>całkowitych w Javie jest wbudowany 'int'. W "Smellticku" tak nie ma (bo nie ma
>tam w ogóle niczego takiego).

I niedobrze ze nie ma. Operacje arytmetyczne trwaja w Smalltaku
dosyc dlugo, co powoduje ze Smalltalk jako tako tylko nadaje sie do
obliczen numerycznych (nie mowiac o skladni wyrazen arytmetycznych)

A.L.

On Wed, 2 Nov 2005 12:35:45 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>Dnia Tue, 01 Nov 2005 21:50:04 -0600, A.L. skrobie:
>> On Tue, 01 Nov 2005 23:24:23 +0100, pdemb@gazeta.pl (Piotr
>> Dembiński) wrote:
>
>> >Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
>> >
>> >[...]
>> >
>> >> Silna typizacja utrudnia programowanie _OBIEKTOWE_.
>> >
>> >Chyba chodziło o statyczną typizację.  Silne typy są na przykład w Pythonie.
>
>> A dlaczego statyczna typizacja utrudnia programwoanie obiektowe?...
>
>Bo żeby skorzystać z pełnego generyzmu, jaki wnosi programowanie obiektowe,
>trzeba stosować rzutowanie.


Pierwsze slysze ze programowanie obiektowe ma jakis "generyzm". Co
to jest "generyzm"?...

A.L.

Dnia Wed, 02 Nov 2005 07:21:09 -0600, A.L. skrobie:
> On Wed, 2 Nov 2005 12:33:43 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:


> >Ups, zapomnialem ;)
> >
> >Co nie zmienia jednak faktu, że niestety klasy Integer nie wykorzystuje się w
> >Javie do niczego innego, jak do boksowania; "normalnym" sposobem użycia
> >całkowitych w Javie jest wbudowany 'int'. W "Smellticku" tak nie ma (bo nie ma
> >tam w ogóle niczego takiego).

> I niedobrze ze nie ma. Operacje arytmetyczne trwaja w Smalltaku
> dosyc dlugo, co powoduje ze Smalltalk jako tako tylko nadaje sie do
> obliczen numerycznych (nie mowiac o skladni wyrazen arytmetycznych)

Czy to jest słuszna koncepcja, czy nie, to już sprawa drugorzędna. Na pewno w
Javie dobrze zrobili, że rozwiązali to w ten sposób, ale to nie zmienia faktu,
że to już nie jest język w pełni obiektowy.

Można było jednak spróbować zrobić coś w rodzaju "referencji na wszystko", tak
jak ma Smalltalk, żeby można było obejść statyczny system typów i nie
rzutować.

Nie twierdzę też, jakoby obiektowość była dla języka ideałem, do którego
powinien dążyć.

-- 
//  _    ___         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 Wed, 02 Nov 2005 07:24:26 -0600, A.L. skrobie:
> On Wed, 2 Nov 2005 12:35:45 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> >Dnia Tue, 01 Nov 2005 21:50:04 -0600, A.L. skrobie:
> >> On Tue, 01 Nov 2005 23:24:23 +0100, pdemb@gazeta.pl (Piotr
> >> Dembiński) wrote:
> >
> >> >Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
> >> >
> >> >[...]
> >> >
> >> >> Silna typizacja utrudnia programowanie _OBIEKTOWE_.
> >> >
> >> >Chyba chodziło o statyczną typizację.  Silne typy są na przykład w Pythonie.
> >
> >> A dlaczego statyczna typizacja utrudnia programwoanie obiektowe?...
> >
> >Bo żeby skorzystać z pełnego generyzmu, jaki wnosi programowanie obiektowe,
> >trzeba stosować rzutowanie.


> Pierwsze slysze ze programowanie obiektowe ma jakis "generyzm". Co
> to jest "generyzm"?...

Programowanie obiektowe ma za zadanie dostarczyć generyzm. Dzięki obiektowości
na przykład (ale to się sprawdza tylko w Smalltalku) można mieć zbiorniki z
obiektami dowolnej klasy. Ktoś tu na tej grupie parę lat temu zresztą usiłował
udowadniać, że jest to wręcz jedyna słuszna forma generyzmu (jak to było? "nie
ma generyzmu tam, gdzie jest statyczny, monolityczny kompilat"?).

-- 
//  _    ___         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 Wed, 2 Nov 2005 13:54:51 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>Dnia Wed, 02 Nov 2005 07:21:09 -0600, A.L. skrobie:
>> On Wed, 2 Nov 2005 12:33:43 +0000 (UTC), Sektor van Skijlen
>> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>
>
>> >Ups, zapomnialem ;)
>> >
>> >Co nie zmienia jednak faktu, że niestety klasy Integer nie wykorzystuje się w
>> >Javie do niczego innego, jak do boksowania; "normalnym" sposobem użycia
>> >całkowitych w Javie jest wbudowany 'int'. W "Smellticku" tak nie ma (bo nie ma
>> >tam w ogóle niczego takiego).
>
>> I niedobrze ze nie ma. Operacje arytmetyczne trwaja w Smalltaku
>> dosyc dlugo, co powoduje ze Smalltalk jako tako tylko nadaje sie do
>> obliczen numerycznych (nie mowiac o skladni wyrazen arytmetycznych)
>
>Czy to jest słuszna koncepcja, czy nie, to już sprawa drugorzędna. Na pewno w
>Javie dobrze zrobili, że rozwiązali to w ten sposób, ale to nie zmienia faktu,
>że to już nie jest język w pełni obiektowy.

"W pelni obiektozy" znaczy ze ma same obiekty" Jak dla mnie, java
jest wystarczajaco obiektowa a Smalltalk za bardzo obiektowy.
Wlasnei z powodu owych "int".

>Można było jednak spróbować zrobić coś w rodzaju "referencji na wszystko", tak
>jak ma Smalltalk, żeby można było obejść statyczny system typów i nie
>rzutować.

Uchum. Najlepiej byloby Jave wyposazyc w "void". Stoimy po
przeciwnej stronie barykady. To co Kolega uwaza za wade, to ja
uwazam za zalete. 

A.L.

On Wed, 2 Nov 2005 13:57:54 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
 
>
>
>> Pierwsze slysze ze programowanie obiektowe ma jakis "generyzm". Co
>> to jest "generyzm"?...
>
>Programowanie obiektowe ma za zadanie dostarczyć generyzm. Dzięki obiektowości
>na przykład (ale to się sprawdza tylko w Smalltalku) można mieć zbiorniki z
>obiektami dowolnej klasy. Ktoś tu na tej grupie parę lat temu zresztą usiłował
>udowadniać, że jest to wręcz jedyna słuszna forma generyzmu (jak to było? "nie
>ma generyzmu tam, gdzie jest statyczny, monolityczny kompilat"?).

Kolejny raz odpisze ejdnym slowem: "nonsens". 

Jak popatrzec na podreczniki do OO, to nigdzie tam nie pisza o
"generyzmie". Czy Kolega moglby rozwinac ten temat?... W
szczegolnosci zas to zdanie na temat "monolitycznego kompilatu"?...

Poza tym, w Javie do wersji 1.4 wszystkie collections skladowaly
obiekty typu Object. Nie bylo wiec zadnego problemu w pakowaniu tam
obiektow jakich sie chcialo. Wiec o co chodzi z tym, cytuje, "ale to
sie sprawdza tylko w Smalltalku", koniec cytatu?

A.L.

On Wed, 02 Nov 2005 16:10:00 +0100, pdemb@gazeta.pl (Piotr
Dembiński) wrote:

>A.L. <alewando@kapturek62.com> writes:
>
>> On Tue, 01 Nov 2005 23:24:23 +0100, pdemb@gazeta.pl 
>> (Piotr Dembiński) wrote:
>>
>>>Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
>>>
>>>[...]
>>>
>>>> Silna typizacja utrudnia programowanie _OBIEKTOWE_.
>>>
>>> Chyba chodziło o statyczną typizację.  Silne typy są na przykład 
>>> w Pythonie.
>>
>> A dlaczego statyczna typizacja utrudnia programwoanie obiektowe?...
>
>Ciekawe pytanie.  Po prostu przy statycznej typizacji trudniejsze 
>jest wykorzystanie pełnych możliwości obiektowego stylu programowania,
>takich jak dodawanie bądź usuwanie atrybutów czy operacji obiektu 
>w czasie działania programu.  
>
>Rzeczy, które w językach z dynamicznym zestawem typów da się zrobić 
>czytelnie w kilku linijkach kodu, w językach ze statycznym zestawem 
>typów wymagają często pisania dodatkowych klas, interfejsów i ogólnie:
>mnożenia kodu ponad potrzebę.  Przynajmniej takie jest moje zdanie.


Merde. Dynamiczna typizacja jest jednym z powodow dla ktorych
Smalltalk przepadl. Problem zas w tym, ze nei o to chodzi zeby
program byl "zwiezly" czy "dynamiczny" czy tez "czytelny". Chodzi o
to zeby program byl poprawny, a mozliwie duza czesc tej poprawnosci
zweryfikowal kompilator.

Jeden z tworcow Smalltalka powiedzial keidys: "raczej bym nie chcial
poleciec samolotem w ktorym oprogramowanie jest napisane w
Smalltalku. W krytycznej chwili, na przyklad podczas ladowania,
Smalltalk moglby powiedziec doesNotUnderstand".

W przypadku duzych programow przeklada sie to w nigdy nie konczoacy
sie proces odpluskiwania, wieczne bledy i wielkie marnowanie
pieniedzy.

A.L.

A.L. <alewando@kapturek62.com> writes:

> On Tue, 01 Nov 2005 23:24:23 +0100, pdemb@gazeta.pl 
> (Piotr Dembiński) wrote:
>
>>Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
>>
>>[...]
>>
>>> Silna typizacja utrudnia programowanie _OBIEKTOWE_.
>>
>> Chyba chodziło o statyczną typizację.  Silne typy są na przykład 
>> w Pythonie.
>
> A dlaczego statyczna typizacja utrudnia programwoanie obiektowe?...

Ciekawe pytanie.  Po prostu przy statycznej typizacji trudniejsze 
jest wykorzystanie pełnych możliwości obiektowego stylu programowania,
takich jak dodawanie bądź usuwanie atrybutów czy operacji obiektu 
w czasie działania programu.  

Rzeczy, które w językach z dynamicznym zestawem typów da się zrobić 
czytelnie w kilku linijkach kodu, w językach ze statycznym zestawem 
typów wymagają często pisania dodatkowych klas, interfejsów i ogólnie:
mnożenia kodu ponad potrzebę.  Przynajmniej takie jest moje zdanie.

-- 
http://www.piotr.dembiński.prv.pl

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

[...]

> Można było jednak spróbować zrobić coś w rodzaju "referencji na
> wszystko", tak jak ma Smalltalk, żeby można było obejść statyczny
> system typów i nie rzutować.

'Referencja na wszystko' jest też w pythonach.  Tam to jest po prostu
nazwa składowana w przestrzeni nazw.

Zresztą: 'referencją na wszystko' jest również assemblerowa etykieta :)

> Nie twierdzę też, jakoby obiektowość była dla języka ideałem, 
> do którego powinien dążyć.

IMO obiektowość jest w wielu zastosowaniach użyteczna, to wszystko.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 02 Nov 2005 16:17:55 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> [...]

> > Można było jednak spróbować zrobić coś w rodzaju "referencji na
> > wszystko", tak jak ma Smalltalk, żeby można było obejść statyczny
> > system typów i nie rzutować.

> 'Referencja na wszystko' jest też w pythonach.  Tam to jest po prostu
> nazwa składowana w przestrzeni nazw.

> Zresztą: 'referencją na wszystko' jest również assemblerowa etykieta :)

Bzdura. W Smalltalku nawet nil jest normalnym obiektem, który może odbierać
komunikaty. A z asemblerową etykietą (i podobnie void*) to nie wiadomo, co
możesz zrobić.

-- 
//  _    ___         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. wrote (tak! stara dobra wrotka!):

> Poza tym, w Javie do wersji 1.4 wszystkie collections skladowaly
> obiekty typu Object. Nie bylo wiec zadnego problemu w pakowaniu tam
> obiektow jakich sie chcialo. Wiec o co chodzi z tym, cytuje, "ale to
> sie sprawdza tylko w Smalltalku", koniec cytatu?

Nie znam dobrze smalltalka, właściwie wcale. Mogę więc pisać bzdury, ale
chyba nie powinienem.
Mając Object nie możesz wykorzystać tego, co się pod nim tak naprawdę kryje
bez rzutowania na z góry określony typ. Nie jest tam ważne jaką
funkcjonalność obiekt oferuje, a jedynie klasa (interfejs) do której
należy.

Nie jest legalne:
void foo(Object bar)
{
	bar.add(5);
}

nawet jeśli pod referencją bar kryje się obiekt klasy posiadającej metodę
add(int).

MyDouble d = ...
MyFloat f = ...

void foo(Zeroable z)
{
	z.zero();
}

foo(d);
foo(f);

są legalne tylko jeśli explicite zaznaczy się, że klasy MyDouble i MyFloat
implementują Zeroable.

Chociaż z drugiej strony piszę trochę w Javie i nie spotkałem się z
sytuacją, w której to byłby duży problem. Przeważnie odpowiednia hierarchia
klas i interfejsów załatwia wszystko. Tyle że trzeba z góry zadecydować,
jakie interfejsy implementuje.

-- 
Zbigniew Malec Ustronie:104 gg:2756100

Dnia Wed, 02 Nov 2005 08:03:01 -0600, A.L. skrobie:
> "W pelni obiektozy" znaczy ze ma same obiekty" Jak dla mnie, java
> jest wystarczajaco obiektowa a Smalltalk za bardzo obiektowy.
> Wlasnei z powodu owych "int".

I ja jestem zwolennikiem takiego podejścia. Tylko może bez hipokryzji w stylu
"Java is full OO language", bo jest to wierutna bzdura. Java jest taką samą
hybrydą, jak C++, z tą tylko różnicą, że twórcy C++ przyznają to bez
hipokryzji.

> >Można było jednak spróbować zrobić coś w rodzaju "referencji na wszystko", tak
> >jak ma Smalltalk, żeby można było obejść statyczny system typów i nie
> >rzutować.

> Uchum. Najlepiej byloby Jave wyposazyc w "void".

Nie w void (void* chyba pan miałeś na myśli), bo nie pozwala to na wszelkiego
rodzaju weryfikacje i zapewnienie poprawności, nawet jeśli to jest tylko w
runtime.

> Stoimy po przeciwnej stronie barykady.

Pan Kolega jest w błędzie.

> To co Kolega uwaza za wade, to ja uwazam za zalete. 

Pan Kolega musi trochę uważniej czytać ;)

Nie uważam tego za wadę, tylko za niedotrzymanie obiektowości. To, że Java
posiada statyczną typizację to dobrze, co nie zmienia faktu, że statyczna
typizacja przeszkadza w obiektowości.

Ja się natknąłem na jeden dość charakterystyczny przykład: w MFC architektura
dokument-widok zakłada wzajemne powiązanie klasy widoku, ramki i dokumentu,
spięte razem klasą wzorca dokumentu. Problem jednak polegał na wzajemnym
udostępnianiu owych obiektów innym. Można zatem było spod klasy CView uzyskać
obiekt klasy CDocument, ale jako CDocument*. Jeśli się zaś chciało na jego
rzecz wywołać metodę w klasie pochodnej dokumentu (a taką przecie trzeba było
przecie zrobić, bo CDocument to tylko szkielet), to trzeba rzutować na
wskaźnik do klasy pochodnej.

Żeby nie było nieścisłości: gdyby to zostało zrealizowane w Javie, to trzeba
by było dokładnie tak samo rzutować z dokładnie tego samego powodu.

Oczywiście, że MFC stanowi przykład niedostosowania założeń do narzędzia;
takie rozwiązanie sprawdzało się w Smalltalku, ale niezbyt sprawdza się w C++.
W C++ zresztą znacznie sensowniej byłoby wzorzec dokumentu zrobić jako...
wzorzec. Wtedy obiekt dokumentu (np.) byłby zwracany od razu przez odpowiedni
typ, a nie przez klasę bazową. Odpada rzutowanie, sprawdzanie i można metodę
wołać od razu, bez żadnych kombinacji.

Różne zresztą zdania słyszałem na ten temat. Jedni uważają, że ta statyczna
typizacja wprowadza niepotrzebne ograniczenia. Inni, że nie ma co biadolić,
tylko trzeba operacje implementować na metodach wirtualnych i nie doprowadzać
nigdy do sytuacji, w której chcemy wołać metodę na rzecz obiektu trzymanego za
referencję do klasy bazowej, która tej metody nie posiada. Natknąłem się
zresztą swego czasu na takie coś, że w metodzie klasy bazowej należało jedną
drobną operację wykonać różnie w zależności od tego, jaka jest klasa
wyjściowa. Ponieważ zdarzało się to często (zbyt często, żeby na każdą taką
okazję dorabiać osobną metodę wirtualną), a klas wyjściowych było dwie, to
dorobiłem po prostu metodę, która wykonywała rzutowanie, a potem normalnie
warunek.


-- 
//  _    ___         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 Wed, 02 Nov 2005 08:12:20 -0600, A.L. skrobie:
> Kolejny raz odpisze ejdnym slowem: "nonsens". 

Z pewnych względów nawet bym się pod tym podpisał.

> Jak popatrzec na podreczniki do OO, to nigdzie tam nie pisza o
> "generyzmie".

Może się wtedy ten termin aż tak nie ukuł. Nie wiem.

> Czy Kolega moglby rozwinac ten temat?... W
> szczegolnosci zas to zdanie na temat "monolitycznego kompilatu"?...

Nie ja to zdanie pisałem. Ja uważam, że jeśli mamy jeden kawałek kodu w
źródłach, który potrafi działać z różnymi typami (klasami) obiektów i w którym
można niektóre drobne operacje wykonywać w zależności od tego typu, to taki
kawałek jest generyczny. W przypadku obiektowości można osiągnąć to samo, za
pomocą wołania po prostu metody na rzecz obiektu, która to metoda zrobi być
może specyficzne dla obiektu rzeczy. Można, ale tylko mając w pełni dynamiczną
typizację, która wiadomo co oznacza w praktyce.

> Poza tym, w Javie do wersji 1.4 wszystkie collections skladowaly
> obiekty typu Object. Nie bylo wiec zadnego problemu w pakowaniu tam
> obiektow jakich sie chcialo. Wiec o co chodzi z tym, cytuje, "ale to
> sie sprawdza tylko w Smalltalku", koniec cytatu?

No dobrze, i co z tą kolekcją można potem zrobić? Można w jakiś sposób
zapewnić np., że będzie zawierała tylko liczby całkowite, że każdy element z
niej wyciągnięty będzie też liczbą całkowitą? Można, pod warunkiem, że w
każdym miejscu, gdzie taką kolekcję obsługujemy, będziemy wykonywać rzutowanie
ze sprawdzaniem poprawności.

W przypadku Smalltalka tylko wysyłamy wiadomość i reszta nas nie obchodzi. W
kodzie wynikowym efekt jest dokładnie ten sam (w sensie, też sobie możemy
rzucić wyjątkiem), tylko w kodzie źródłowym trzeba się bardziej napocić.
Generyki w Javie o tyle ułatwiły sprawę, że zaoszczędza się na tym rzutowaniu,
a sprawdzanie jest niepotrzebne, bo i tak kod zostanie najpierw sprawdzony w
czasie kompilacji.

Ja osobiście uważam, że jeśli mamy język ze statyczną typizacją, to
najbardziej właściwą techniką dla generyzmu jest polimorfizm statyczny. A
polimorfizm dynamiczny ma go zastąpić tylko tam, gdzie polimorfizm statyczny
nie będzie mógł być zastosowany, np. jeśli chcemy trzymać w jednej kolekcji
obiekty różnych typów.

-- 
//  _    ___         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 Wed, 02 Nov 2005 19:43:13 +0100, pdemb@gazeta.pl (Piotr Dembiñski)
wrote:

>A.L. <alewando@kapturek62.com> writes:
>
>[...]
>
>> Chodzi o to zeby program byl poprawny, a mozliwie duza czesc tej
>> poprawnosci zweryfikowal kompilator.
>
>Teraz takich rzeczy nie robi siê kompilatorem, tylko automatycznymi
>testami jednostkowymi :)
>
>> Jeden z tworcow Smalltalka powiedzial keidys: "raczej bym nie chcial
>> poleciec samolotem w ktorym oprogramowanie jest napisane 
>> w Smalltalku. 
>
>No to szkoda, ¿e tak powiedzia³.  Ludzie mówi± ró¿ne rzeczy.
>
>> W krytycznej chwili, na przyklad podczas ladowania, Smalltalk moglby
>> powiedziec doesNotUnderstand".
>
>Wow.  A procesorowi móg³by siê spaliæ pin i nic by nie powiedzia³ :)
>
>> W przypadku duzych programow przeklada sie to w nigdy nie konczoacy
>> sie proces odpluskiwania, wieczne bledy i wielkie marnowanie
>> pieniedzy.
>
>:^D

Kolega zartuje czy powaznie? Sadzac po "mordkach"" to zartuje. Mam
nadzieje...

A.L.

A.L. <alewando@kapturek62.com> writes:

[...]

> Chodzi o to zeby program byl poprawny, a mozliwie duza czesc tej
> poprawnosci zweryfikowal kompilator.

Teraz takich rzeczy nie robi się kompilatorem, tylko automatycznymi
testami jednostkowymi :)

> Jeden z tworcow Smalltalka powiedzial keidys: "raczej bym nie chcial
> poleciec samolotem w ktorym oprogramowanie jest napisane 
> w Smalltalku. 

No to szkoda, że tak powiedział.  Ludzie mówią różne rzeczy.

> W krytycznej chwili, na przyklad podczas ladowania, Smalltalk moglby
> powiedziec doesNotUnderstand".

Wow.  A procesorowi mógłby się spalić pin i nic by nie powiedział :)

> W przypadku duzych programow przeklada sie to w nigdy nie konczoacy
> sie proces odpluskiwania, wieczne bledy i wielkie marnowanie
> pieniedzy.

:^D

-- 
http://www.piotr.dembiński.prv.pl

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

> Dnia Wed, 02 Nov 2005 16:17:55 +0100, Piotr Dembiński skrobie:
>> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:
>
>> [...]
>
>> > Można było jednak spróbować zrobić coś w rodzaju "referencji 
>> > na wszystko", tak jak ma Smalltalk, żeby można było obejść 
>> > statyczny system typów i nie rzutować.
>
>> 'Referencja na wszystko' jest też w pythonach.  Tam to jest 
>> po prostu nazwa składowana w przestrzeni nazw.
>
>> Zresztą: 'referencją na wszystko' jest również assemblerowa
>> etykieta :)
>
> Bzdura. W Smalltalku nawet nil jest normalnym obiektem, który może
> odbierać komunikaty. A z asemblerową etykietą (i podobnie void*) 
> to nie wiadomo, co możesz zrobić.

W takim razie o czym rozmawiamy?

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

[...]

> Różne zresztą zdania słyszałem na ten temat. Jedni uważają, że ta
> statyczna typizacja wprowadza niepotrzebne ograniczenia.

Statyczne typy są również formą optymalizacji.

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

[...]

>>> W przypadku duzych programow przeklada sie to w nigdy nie
>>> konczoacy sie proces odpluskiwania, wieczne bledy i wielkie
>>> marnowanie pieniedzy.
>>
>>:^D
>
> Kolega zartuje czy powaznie? Sadzac po "mordkach"" to zartuje. 
> Mam nadzieje...

Niekończący się proces odpluskwiania do centrum całego open source :)

Dnia Wed, 02 Nov 2005 19:43:13 +0100, Piotr Dembiński skrobie:
> A.L. <alewando@kapturek62.com> writes:

> [...]

> > Chodzi o to zeby program byl poprawny, a mozliwie duza czesc tej
> > poprawnosci zweryfikowal kompilator.

> Teraz takich rzeczy nie robi się kompilatorem, tylko automatycznymi
> testami jednostkowymi :)

Ciekaw jestem przede wszystkim, kto te testy napisze. I ile będzie to
kosztowało.

Biorąc pod uwagę, że Smalltalk zdechł a jego dorobek po części przejęła Java,
obawiam się, że należało to zdanie zacząć od "Kiedyś nie robiło się takich
rzeczy kompilatorem...".

> > Jeden z tworcow Smalltalka powiedzial keidys: "raczej bym nie chcial
> > poleciec samolotem w ktorym oprogramowanie jest napisane 
> > w Smalltalku. 

> No to szkoda, że tak powiedział.  Ludzie mówią różne rzeczy.

Zebrało się gościowi na szczerość...

> > W krytycznej chwili, na przyklad podczas ladowania, Smalltalk moglby
> > powiedziec doesNotUnderstand".

> Wow.  A procesorowi mógłby się spalić pin i nic by nie powiedział :)

Problem tylko w tym, że sprzęt stosowany dzisiejszych tego typu urządzeniach
jest znacznie mniej skomplikowany (i rozbudowany), niż oprogramowanie. A ja
wiem co mówię, bo widziałem źródła "procka" który bywa używany do takich
sprzętów i choćby porównanie wielkości z projektem oprogramowania, które miało
na tym chodzić, to różnica w rzędach wielkości. Co ma mieć sprzęt? Właściwie
nic; ma mieć procesor, pamięć i urządzenia do wspomagania komunikacji. Czasem
w razie potrzeby procesor specjalistyczny (typu DSP). Co ma robić? Wykonywać
oprogramowanie. Tyle.

Właśnie dlatego poprawność działania sprzętu jest wbrew pozorom ZNACZNIE
łatwiej zapewnić, niż poprawność działania oprogramowania. To nie tylko nie są
rzeczy równorzędne; to są rzeczy wręcz nieporównywalne.


-- 
//  _    ___         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> writes:

> Dnia Wed, 02 Nov 2005 19:43:13 +0100, Piotr Dembiński skrobie:
>> A.L. <alewando@kapturek62.com> writes:
>
>> [...]
>
>> > Chodzi o to zeby program byl poprawny, a mozliwie duza czesc tej
>> > poprawnosci zweryfikowal kompilator.
>
>> Teraz takich rzeczy nie robi się kompilatorem, tylko automatycznymi
>> testami jednostkowymi :)
>
> Ciekaw jestem przede wszystkim, kto te testy napisze. I ile będzie
> to kosztowało.

Ten koszt powinien się zamortyzować.  A testy jednostkowe dla swojego
kodu powinni pisać programiści.

> Biorąc pod uwagę, że Smalltalk zdechł a jego dorobek po części
> przejęła Java, obawiam się, że należało to zdanie zacząć 
> od "Kiedyś nie robiło się takich rzeczy kompilatorem...".

:)

>> > Jeden z tworcow Smalltalka powiedzial keidys: "raczej bym nie
>> > chcial poleciec samolotem w ktorym oprogramowanie jest napisane 
>> > w Smalltalku.
>
>> No to szkoda, że tak powiedział.  Ludzie mówią różne rzeczy.
>
> Zebrało się gościowi na szczerość...

Może wpadł w dołek :)

>> > W krytycznej chwili, na przyklad podczas ladowania, Smalltalk
>> > moglby powiedziec doesNotUnderstand".
>
>> Wow.  A procesorowi mógłby się spalić pin i nic by nie powiedział
>> :)
>
> Problem tylko w tym, że sprzęt stosowany dzisiejszych tego typu
> urządzeniach jest znacznie mniej skomplikowany (i rozbudowany), 
> niż oprogramowanie. A ja wiem co mówię, bo widziałem źródła "procka"
> który bywa używany do takich sprzętów i choćby porównanie wielkości
> z projektem oprogramowania, które miało na tym chodzić, to różnica 
> w rzędach wielkości. Co ma mieć sprzęt? Właściwie nic; ma mieć
> procesor, pamięć i urządzenia do wspomagania komunikacji. Czasem 
> w razie potrzeby procesor specjalistyczny (typu DSP). Co ma robić?
> Wykonywać oprogramowanie. Tyle.
>
> Właśnie dlatego poprawność działania sprzętu jest wbrew pozorom
> ZNACZNIE łatwiej zapewnić, niż poprawność działania
> oprogramowania. To nie tylko nie są rzeczy równorzędne; 
> to są rzeczy wręcz nieporównywalne.

Niom, dlatego programiści zarabiają więcej niż elektronicy.

-- 
http://www.piotr.dembiński.prv.pl

Dnia Sat, 05 Nov 2005 15:01:20 +0100, Piotr Dembiński skrobie:
> >> > Chodzi o to zeby program byl poprawny, a mozliwie duza czesc tej
> >> > poprawnosci zweryfikowal kompilator.
> >
> >> Teraz takich rzeczy nie robi się kompilatorem, tylko automatycznymi
> >> testami jednostkowymi :)
> >
> > Ciekaw jestem przede wszystkim, kto te testy napisze. I ile będzie
> > to kosztowało.

> Ten koszt powinien się zamortyzować.  A testy jednostkowe dla swojego
> kodu powinni pisać programiści.

Koszt pisania testów jednostkowych? Ciekaw jestem, na ile ty w ogóle wiesz, o
czym mówisz.

Nie pisałem co prawda w Smalltalku, ale po samym choćby Tk wiem, ile trzeba
się namęczyć z zapewnieniem poprawności aplikacji pisanej w języku
posiadającym tylko dynamiczną typizację. Praktycznie do każdej możliwej
rzeczy.

Dynamiczna typizacja zmniejsza zależności, ale wymaga więcej pracy nad
testowaniem. Mniejszy koszt związany ze zmniejszeniem zależności wcale nie
musi zrekompensować zwiększonego effortu na testowanie.

> >> > Jeden z tworcow Smalltalka powiedzial keidys: "raczej bym nie
> >> > chcial poleciec samolotem w ktorym oprogramowanie jest napisane 
> >> > w Smalltalku.
> >
> >> No to szkoda, że tak powiedział.  Ludzie mówią różne rzeczy.
> >
> > Zebrało się gościowi na szczerość...

> Może wpadł w dołek :)

Ja tam podejrzewam, że wiedział co mówi.

-- 
//  _    ___         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> writes:

> Dnia Sat, 05 Nov 2005 15:01:20 +0100, Piotr Dembiński skrobie:
>> >> > Chodzi o to zeby program byl poprawny, a mozliwie duza czesc
>> >> > tej poprawnosci zweryfikowal kompilator.
>> >
>> >> Teraz takich rzeczy nie robi się kompilatorem, tylko
>> >> automatycznymi testami jednostkowymi :)
>> >
>> > Ciekaw jestem przede wszystkim, kto te testy napisze. I ile
>> > będzie to kosztowało.
>
>> Ten koszt powinien się zamortyzować.  A testy jednostkowe 
>> dla swojego kodu powinni pisać programiści.
>
> Koszt pisania testów jednostkowych? Ciekaw jestem, na ile ty w ogóle
> wiesz, o czym mówisz.

Piszę to, co myślę :)

Testy jednostkowe są po to, żeby po wprowadzeniu zmiany, która wnosi
ze sobą błąd można szybko ten błąd wychwycić.  Wszystko przy
założeniu, że system powstaje w iteracjach, wymagania się 
zmieniają etc.

> Nie pisałem co prawda w Smalltalku, ale po samym choćby Tk wiem, ile
> trzeba się namęczyć z zapewnieniem poprawności aplikacji pisanej 
> w języku posiadającym tylko dynamiczną typizację. Praktycznie do
> każdej możliwej rzeczy.
>
> Dynamiczna typizacja zmniejsza zależności, ale wymaga więcej pracy
> nad testowaniem. 

Yup.

> Mniejszy koszt związany ze zmniejszeniem zależności wcale nie musi
> zrekompensować zwiększonego effortu na testowanie.

Przydałyby się wyniki badań naukowych, bo tak to sobie możemy gdybać
'na czuja'.  W językach z dynamicznym typowaniem na pewno o wiele
większe znaczenie ma czytelność kodu, komentarze w trudniejszych
miejscach etc.

>> >> > Jeden z tworcow Smalltalka powiedzial keidys: "raczej bym nie
>> >> > chcial poleciec samolotem w ktorym oprogramowanie jest
>> >> > napisane w Smalltalku.
>> >
>> >> No to szkoda, że tak powiedział.  Ludzie mówią różne rzeczy.
>> >
>> > Zebrało się gościowi na szczerość...
>
>> Może wpadł w dołek :)
>
> Ja tam podejrzewam, że wiedział co mówi.

OK, ja bym z tym samolotem zaryzykował, gdybym miał pewność, że system
został stworzony przez solidną firmę :)

-- 
http://www.piotr.dembiński.prv.pl

In message dkimcj$rji$1@kujawiak.man.lodz.pl, Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
> > Ten koszt powinien się zamortyzować.  A testy jednostkowe dla
> > swojego kodu powinni pisać programiści.
>
> Koszt pisania testów jednostkowych? Ciekaw jestem, na ile ty w ogóle
> wiesz, o czym mówisz.
>
> Nie pisałem co prawda w Smalltalku, ale po samym choćby Tk wiem, ile
> trzeba się namęczyć z zapewnieniem poprawności aplikacji pisanej w
> języku posiadającym tylko dynamiczną typizację. Praktycznie do każdej
> możliwej rzeczy.

Zazwyczaj jest tak, że 90% testów jednostkowych na nic się nie
przyda, bo w tych miejscach błędy nie wystąpią.
Jeszcze gorzej z testami, które należy napisać po wykryciu błędu.
jak już się błąd poprawi to jest minimalna szansa, że znów się tam
coś zwali :)
W zasadzie testy jednostkowe powinno się pisać tylko tam, gdzie wystąpią
błędy :)
No i w ogóle pisać testów w zasadzie się nie da, bo program ma być
"na wczoraj", byle jaki byle się uruchamiał, a później będzie się
łatać :(
Takie jest niestety podejście wielu pracodawców. Mam do poczytania
kawałek na ten temat:
http://miniurl.pl/projekty
i kliknąć:
"Tworzenie projektów informatycznych"

-- 
Pozdrawiam
Miroo
Teoria względności: "Pracownik jest zbędny w firmie gdy prosi o
podwyżkę, lecz niezastąpiony gdy prosi o urlop" 

Miroo wrote:

> Zazwyczaj jest tak, że 90% testów jednostkowych na nic się nie
> przyda, bo w tych miejscach błędy nie wystąpią.
> Jeszcze gorzej z testami, które należy napisać po wykryciu błędu.
> jak już się błąd poprawi to jest minimalna szansa, że znów się tam
> coś zwali :)
eee co najmniej dyskusyjne zdanie. z doświadzenia wiem, ze błędy 
względnie często nawracają (jest kilka powodów).
> W zasadzie testy jednostkowe powinno się pisać tylko tam, gdzie wystąpią
> błędy :)
eee jeden PM zarządził kiedyś: "od teraz piszemy bez błędów"  i to było 
doskonałe rozwiązanie.
-- 
jarek

Miroo wrote:

> Zazwyczaj jest tak, że 90% testów jednostkowych na nic się nie
> przyda, bo w tych miejscach błędy nie wystąpią.
> Jeszcze gorzej z testami, które należy napisać po wykryciu błędu.
> jak już się błąd poprawi to jest minimalna szansa, że znów się tam
> coś zwali :)
co najmniej dyskusyjne zdanie. z doświadzenia wiem, ze błędy
względnie często nawracają (jest kilka powodów).
> W zasadzie testy jednostkowe powinno się pisać tylko tam, gdzie wystąpią
> błędy :)
jeden PM zarządził kiedyś: "od teraz piszemy bez błędów"  i to było
doskonałe rozwiązanie.
-- 
jarekr

"Miroo" <miroo75@REMOVEIT.o2.pl> wrote:

>> Nie pisałem co prawda w Smalltalku, ale po samym choćby Tk wiem, ile
>> trzeba się namęczyć z zapewnieniem poprawności aplikacji pisanej w
>> języku posiadającym tylko dynamiczną typizację. Praktycznie do każdej
>> możliwej rzeczy.

Tcl nie posiada dynamicznej typizacji.
Tcl nie posiada _w ogole_ typizacji.
To zasadnicza roznica.

AK 

Dnia Tue, 8 Nov 2005 15:39:56 +0100, Karpierz, Adam skrobie:
> "Miroo" <miroo75@REMOVEIT.o2.pl> wrote:

> >> Nie pisałem co prawda w Smalltalku, ale po samym choćby Tk wiem, ile
> >> trzeba się namęczyć z zapewnieniem poprawno?ci aplikacji pisanej w
> >> języku posiadaj?cym tylko dynamiczn? typizację. Praktycznie do każdej
> >> możliwej rzeczy.

> Tcl nie posiada dynamicznej typizacji.

Adamie, czy ty w ogóle wiesz, na czym polega dynamiczna typizacja?

> Tcl nie posiada _w ogole_ typizacji.
> To zasadnicza roznica.

W ogóle typizacji to nie posiada asembler, Intercal i Brainfuck.


-- 
//  _    ___         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:

>> Tcl nie posiada dynamicznej typizacji.
>
> Adamie, czy ty w ogóle wiesz, na czym polega dynamiczna typizacja?

Wiem dokladnie.

>> Tcl nie posiada _w ogole_ typizacji.
>> To zasadnicza roznica.
>
> W ogóle typizacji to nie posiada asembler, Intercal i Brainfuck.

Oraz wlasnie Tcl.
W Tcl-u wszytsko jest tylko i wylacznie stringiem.

AK