🚀 go-pugleaf

"Paweł" <pawellt@gazeta.SKASUJ-TO.pl> writes:

> witam 
>  
> Pytalem o ciekawy jezyk obiektowy, uczacy dobrych nawykow 
> i nie wymuszajacy "kodu spaghetti" jak Java.

Java IMO nie tyle wymusza spaghetti code, co jest mało zwięzła.

Dnia Tue, 01 Nov 2005 23:24:23 +0100, Piotr Dembiński skrobie:
> 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.

Ups racja. Moja pomyłka.


-- 
//  _    ___         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, 01 Nov 2005 23:19:08 +0100, pdemb@gazeta.pl (Piotr
Dembiński) wrote:

>"Paweł" <pawellt@gazeta.SKASUJ-TO.pl> writes:
>
>> witam 
>>  
>> Pytalem o ciekawy jezyk obiektowy, uczacy dobrych nawykow 
>> i nie wymuszajacy "kodu spaghetti" jak Java.
>
>Java IMO nie tyle wymusza spaghetti code, co jest mało zwięzła.

A niby jak Java wymusza "spaghetti code" i dlaczego nie jest
"zwiezla"?...

A.L.

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

>> Java IMO nie tyle wymusza spaghetti code, co jest malo
>> zwiezla.

> A niby jak Java wymusza "spaghetti code" i dlaczego nie jest
> "zwiezla"?...

Podejrzewam, ze chodzi tutaj o zwiezlosc zapisu. Np. kod programu 
drukujacego fragment ciagu Fibonnaciego w Rubym da sie napisac nastepujaco:

x1, x2 = 0, 1
10.times do
    puts x2
    x1, x2 = x2, x1+x2
end

co w Javie wypadlo by nieco dluzej. Pytaniem oczywiscie pozostaje, czy tego 
typu oszczednosc ma jakiekolwiek znaczenie. Dla mnie osobiscie stosunkowo 
niewielkie i jesli mialbym pokusic sie o zmiany w jezyku dotyczylyby 
zupelnie innych jego obszarow. Warto rowniez chyba zauwazyc, ze generalnie 
rzecz biorac ocena sposobu/jakosci zapisu jest rzecza daleko subiektywna i z 
zalozenia trudna do przedstawienia w kategoriach "gorszy" / "lepszy".

Robert Perlinski 

Dnia Wed, 2 Nov 2005 14:31:38 +0800, Robert Perlinski skrobie:
> "A.L." <alewando@kapturek62.com> wrote:

> >> Java IMO nie tyle wymusza spaghetti code, co jest malo
> >> zwiezla.

> > A niby jak Java wymusza "spaghetti code" i dlaczego nie jest
> > "zwiezla"?...

> Podejrzewam, ze chodzi tutaj o zwiezlosc zapisu. Np. kod programu 
> drukujacego fragment ciagu Fibonnaciego w Rubym da sie napisac nastepujaco:

> x1, x2 = 0, 1
> 10.times do
>     puts x2
>     x1, x2 = x2, x1+x2
> end

> co w Javie wypadlo by nieco dluzej. Pytaniem oczywiscie pozostaje, czy tego 
> typu oszczednosc ma jakiekolwiek znaczenie. Dla mnie osobiscie stosunkowo 
> niewielkie i jesli mialbym pokusic sie o zmiany w jezyku dotyczylyby 
> zupelnie innych jego obszarow. Warto rowniez chyba zauwazyc, ze generalnie 
> rzecz biorac ocena sposobu/jakosci zapisu jest rzecza daleko subiektywna i z 
> zalozenia trudna do przedstawienia w kategoriach "gorszy" / "lepszy".

Głównie przydałyby się takie zmiany, jakie ma C# w stosunku do Javy.


-- 
//  _    ___         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:37:31 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
 
>
>Głównie przydałyby się takie zmiany, jakie ma C# w stosunku do Javy.

A konkretnie?...

A.L.

Dnia Wed, 02 Nov 2005 07:21:52 -0600, A.L. skrobie:
> On Wed, 2 Nov 2005 12:37:31 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>  
> >
> >Głównie przydałyby się takie zmiany, jakie ma C# w stosunku do Javy.

> A konkretnie?...

Na przykład delegaty.

-- 
//  _    ___         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:58:26 +0000 (UTC), Sektor van Skijlen
<ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

>Dnia Wed, 02 Nov 2005 07:21:52 -0600, A.L. skrobie:
>> On Wed, 2 Nov 2005 12:37:31 +0000 (UTC), Sektor van Skijlen
>> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
>>  
>> >
>> >G³ównie przyda³yby siê takie zmiany, jakie ma C# w stosunku do Javy.
>
>> A konkretnie?...
>
>Na przyk³ad delegaty.

Byly w Javie, ale sie nie przyjely...

A.L.

Dnia Wed, 02 Nov 2005 09:02:45 -0600, A.L. skrobie:
> On Wed, 2 Nov 2005 13:58:26 +0000 (UTC), Sektor van Skijlen
> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> >Dnia Wed, 02 Nov 2005 07:21:52 -0600, A.L. skrobie:
> >> On Wed, 2 Nov 2005 12:37:31 +0000 (UTC), Sektor van Skijlen
> >> <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:
> >>  
> >> >
> >> >G?ównie przyda?yby si? takie zmiany, jakie ma C# w stosunku do Javy.
> >
> >> A konkretnie?...
> >
> >Na przyk?ad delegaty.

> Byly w Javie, ale sie nie przyjely...

To ja nic ntt. nie wiem. A co, że niby listenery lepsze?


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

Piotr Dembiński napisał(a):
> 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.
> 
[...]

Wiara, że programista przetestował swój kod może okazać się zabójczą.

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał:

> Wiara, że programista przetestował swój kod może okazać się zabójczą.

Swieta prawda.
Rowniez wiara ze tester przetestowal kod programisty jest tak samo zabojcza.

AK

Adam Karpierz napisał(a):
> Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał:
> 
> 
>>Wiara, że programista przetestował swój kod może okazać się zabójczą.
> 
> 
> Swieta prawda.
> Rowniez wiara ze tester przetestowal kod programisty jest tak samo zabojcza.

Tu niektórzy próbują walczyć poprzez płacenie testerowi za każdy wykryty 
błąd.

Po prostu IMO zdrowsza jest sytuacja dwurolowa tester-programista. Bo 
jedna osoba nie może na raz popełniać najmniej błędów w kodzie i jak 
najwięcej ich wykrywać. Chyba, że cierpi na schizofremię :-)

Pozdrawiam

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> writes:

[...]

> Wiara, że programista przetestował swój kod może okazać się
> zabójczą.

Wiara?  To jest pl.soc.religia?

Użytkownik "Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> napisał:

> Tu niektórzy próbują walczyć poprzez płacenie testerowi
> za każdy wykryty błąd.

Skutek takize mamy wiecej bledow ktore niz sa
bledami albo sa bledami 99 kategorii za to mniej tych
prawdziwych.
No ale ruch w bugtrackingu jest :)

Tu tez  nie ma srebrnych kul.
Poza tym powszechna wiara ze tester wykryje wsio
ma sie nijak do rzeczywistosci.

Ale testerzy sa bardzo potrzebni rowniez po to aby...
miec podkladke.
No bo.. jesli powaznych wielokrotnych testow tester nie
wykryl to blad musial byc naprawde jadowity wiec programsta
jest niejako troche chroniony :)
Sila wyzsza :).

> Po prostu IMO zdrowsza jest sytuacja dwurolowa tester-programista.

Napewno.
Co dwoch to nie jeden.

> Bo jedna osoba nie może na raz popełniać najmniej błędów w
> kodzie i jak  najwięcej ich wykrywać. Chyba, że cierpi na schizofremię :-)

No przeciez to warunek utrzymania sie w tym zawodzie :) !
Nikt przy zdrowych zmyslach nie bedzie sie pchal do tej stajni Augiasza.

AK

Dnia Mon, 07 Nov 2005 11:04:00 +0100, Grzesiek G. skrobie:

> Wiara, że programista przetestował swój kod może okazać się zabójczą.

Jaka znów wiara? Testkejsy mają być napisane, zakonfigurowane i ma
być udokumentowane ich wykonanie. Przynajmniej tak się to odbywa w porządnych
firmach.

-- 
//  _    ___         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 napisał(a):
> Dnia Mon, 07 Nov 2005 11:04:00 +0100, Grzesiek G. skrobie:
> 
> 
>>Wiara, że programista przetestował swój kod może okazać się zabójczą.
> 
> 
> Jaka znów wiara? Testkejsy mają być napisane, zakonfigurowane i ma
> być udokumentowane ich wykonanie. Przynajmniej tak się to odbywa w porządnych
> firmach.
> 
Ja po prostu nie wierzę w samokontrolę, ale może nie pracowałem w 
porządnych firmach.

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Sektor van Skijlen napisał(a):
> Dnia Mon, 07 Nov 2005 11:04:00 +0100, Grzesiek G. skrobie:
> 
> 
>>Wiara, że programista przetestował swój kod może okazać się zabójczą.
> 
> 
> Jaka znów wiara? Testkejsy mają być napisane, zakonfigurowane i ma
> być udokumentowane ich wykonanie. Przynajmniej tak się to odbywa w porządnych
> firmach.
> 
Ja po prostu nie wierzę w samokontrolę, ale może nie pracowałem w 
porządnych firmach.

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Sektor van Skijlen napisał(a):
> Dnia Mon, 07 Nov 2005 11:04:00 +0100, Grzesiek G. skrobie:
> 
> 
>>Wiara, że programista przetestował swój kod może okazać się zabójczą.
> 
> 
> Jaka znów wiara? Testkejsy mają być napisane, zakonfigurowane i ma
> być udokumentowane ich wykonanie. Przynajmniej tak się to odbywa w porządnych
> firmach.
> 
Ja po prostu nie wierzę w samokontrolę, ale może nie pracowałem w 
porządnych firmach.


-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

On Tue, 08 Nov 2005 09:08:08 +0100, "Grzesiek G."
<gruza@spamerom_nie.priv4.onet.pl> wrote:

>Sektor van Skijlen napisał(a):
>> Dnia Mon, 07 Nov 2005 11:04:00 +0100, Grzesiek G. skrobie:
>> 
>> 
>>>Wiara, że programista przetestował swój kod może okazać się zabójczą.
>> 
>> 
>> Jaka znów wiara? Testkejsy mają być napisane, zakonfigurowane i ma
>> być udokumentowane ich wykonanie. Przynajmniej tak się to odbywa w porządnych
>> firmach.
>> 
>Ja po prostu nie wierzę w samokontrolę, ale może nie pracowałem w 
>porządnych firmach.

Slusznie. Pracownika tzreba trzymac za morde. To i trzyma sie...

A.L.

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

[...]

> W zasadzie testy jednostkowe powinno się pisać tylko tam, gdzie
> wystąpią błędy :)

:^)

Dnia Tue, 08 Nov 2005 09:08:45 +0100, Grzesiek G. skrobie:
> Sektor van Skijlen napisał(a):
> > Dnia Mon, 07 Nov 2005 11:04:00 +0100, Grzesiek G. skrobie:
> > 
> > 
> >>Wiara, że programista przetestował swój kod może okazać się zabójczą.
> > 
> > 
> > Jaka znów wiara? Testkejsy mają być napisane, zakonfigurowane i ma
> > być udokumentowane ich wykonanie. Przynajmniej tak się to odbywa w porządnych
> > firmach.
> > 
> Ja po prostu nie wierzę w samokontrolę, ale może nie pracowałem w 
> porządnych firmach.

To nie jest żadna samokontrola - proces, wedle którego to wszystko ma być
zrobione, jest globalny i obowiązujący dla wszystkich. Narzędzia, w których to
trzeba dokumentować są tak zrobione, że obejście jest albo niemożliwe, albo je
trzeba załatwiać u wyższego managera. I wszystkie dane z pracy nad projektem
są w "papierach" i na VOB-ach. A jak ktoś by próbował ten proces obchodzić
nagminnie, to dostanie po głowie. A etapów i ludzi, przez których ręce
przechodzi kolejno kod lub build, jest tyle, że nie ma najmniejszych szans, by
jakieś oszustwo się ukryło.

Jakiś czas temu miałem taki przypadek, jak byłem akurat w testach, że gościu
dodał jednego ifa, stwierdził że aaa co tam to pewnie jest dobrze - po czym my
robimy builda, puszczamy testy, a kod po załadowaniu nawet nie chce się
podnieść; sypie się już po paru sekundach. Nie było przeproś - gościu odwalił
fuszerkę (Ziemkiewicz twierdzi, że to słowo w języku angielskim nie istnieje -
ciekawe, bo ten, kto to sfuszerował, to Amerykanin) i musiał za to polecieć.
I nikogo nie obchodziło, że "miał mało czasu, żeby wykonać UT po tej
poprawce".


-- 
//  _    ___         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 napisał(a):
> Dnia Tue, 08 Nov 2005 09:08:45 +0100, Grzesiek G. skrobie:
> 
>>Sektor van Skijlen napisał(a):
>>
>>>Dnia Mon, 07 Nov 2005 11:04:00 +0100, Grzesiek G. skrobie:
>>>
>>>
>>>
>>>>Wiara, że programista przetestował swój kod może okazać się zabójczą.
>>>
>>>
>>>Jaka znów wiara? Testkejsy mają być napisane, zakonfigurowane i ma
>>>być udokumentowane ich wykonanie. Przynajmniej tak się to odbywa w porządnych
>>>firmach.
>>>
>>
>>Ja po prostu nie wierzę w samokontrolę, ale może nie pracowałem w 
>>porządnych firmach.
> 
> 
> To nie jest żadna samokontrola - proces, wedle którego to wszystko ma być
> zrobione, jest globalny i obowiązujący dla wszystkich. Narzędzia, w których to
> trzeba dokumentować są tak zrobione, że obejście jest albo niemożliwe, albo je
> trzeba załatwiać u wyższego managera. I wszystkie dane z pracy nad projektem
> są w "papierach" i na VOB-ach. A jak ktoś by próbował ten proces obchodzić
> nagminnie, to dostanie po głowie. A etapów i ludzi, przez których ręce
> przechodzi kolejno kod lub build, jest tyle, że nie ma najmniejszych szans, by
> jakieś oszustwo się ukryło.
[...]

Zakładam, że piszesz o projekcie w którego skład wchodzi więcej niż 
jeden programista. Zatem dlaczego sytuacja, w której jedna osoba pisze 
kod i testy ma być lepsza od sytuacji, gdy robią to dwie osoby?

-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

Dnia Wed, 9 Nov 2005 11:06:43 +0100, Karpierz, Adam skrobie:
> "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.

A obiekty Tk (bo taki właśnie przykład podałem)?



-- 
//  _    ___         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, 09 Nov 2005 08:46:43 +0100, Grzesiek G. skrobie:
> > To nie jest żadna samokontrola - proces, wedle którego to wszystko ma być
> > zrobione, jest globalny i obowiązujący dla wszystkich. Narzędzia, w których to
> > trzeba dokumentować są tak zrobione, że obejście jest albo niemożliwe, albo je
> > trzeba załatwiać u wyższego managera. I wszystkie dane z pracy nad projektem
> > są w "papierach" i na VOB-ach. A jak ktoś by próbował ten proces obchodzić
> > nagminnie, to dostanie po głowie. A etapów i ludzi, przez których ręce
> > przechodzi kolejno kod lub build, jest tyle, że nie ma najmniejszych szans, by
> > jakieś oszustwo się ukryło.
> [...]

> Zakładam, że piszesz o projekcie w którego skład wchodzi więcej niż 
> jeden programista. Zatem dlaczego sytuacja, w której jedna osoba pisze 
> kod i testy ma być lepsza od sytuacji, gdy robią to dwie osoby?

Nie rozumiem. A czy ja coś takiego powiedziałem?

Pisanie tego przez jedną osobę zapewnia mniejszy koszt tworzenia, owszem, ale
wymaga dodatkowych aktywności w celu zapewnienia jakości.

Jak ja pisałem UT do "swojego" kodu, to pisałem je co prawda sam, ale po ich
napisaniu wszystko musiało być konsultowane z kierownikiem technicznym
(Technical Lead). Czyli też wychodzi dwie osoby co najmniej.

Mówi się, że co dwie głowy to nie jedna, ale w przypadku programowania ma też
znaczenie przyczyna, dla której wymyślono wzmacniacz różnicowy.

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

> A obiekty Tk (bo taki właśnie przykład podałem)?

Jakie obiekty Tk ?
Nie ma zadnych obiektow TK ani innych.
W Tcl wszystko jest wylacznie stringiem

AK

Sektor van Skijlen napisał(a):
> Dnia Wed, 09 Nov 2005 08:46:43 +0100, Grzesiek G. skrobie:
> 
>>>To nie jest żadna samokontrola - proces, wedle którego to wszystko ma być
>>>zrobione, jest globalny i obowiązujący dla wszystkich. Narzędzia, w których to
>>>trzeba dokumentować są tak zrobione, że obejście jest albo niemożliwe, albo je
>>>trzeba załatwiać u wyższego managera. I wszystkie dane z pracy nad projektem
>>>są w "papierach" i na VOB-ach. A jak ktoś by próbował ten proces obchodzić
>>>nagminnie, to dostanie po głowie. A etapów i ludzi, przez których ręce
>>>przechodzi kolejno kod lub build, jest tyle, że nie ma najmniejszych szans, by
>>>jakieś oszustwo się ukryło.
>>
>>[...]
> 
> 
>>Zakładam, że piszesz o projekcie w którego skład wchodzi więcej niż 
>>jeden programista. Zatem dlaczego sytuacja, w której jedna osoba pisze 
>>kod i testy ma być lepsza od sytuacji, gdy robią to dwie osoby?
> 
> 
> Nie rozumiem. A czy ja coś takiego powiedziałem?
> 

Wydawało mi się, że dyskutujemy tu i teraz o projektach na tyle 
wielkich, że jeden programista dla nich to za mało. Dlatego napisałem, 
że zakładam. Ale jeżeli to założenie nie jest prawdziwe, to wycofam się 
z dyskusji.

> Pisanie tego przez jedną osobę zapewnia mniejszy koszt tworzenia, owszem, ale
> wymaga dodatkowych aktywności w celu zapewnienia jakości.
> 
> Jak ja pisałem UT do "swojego" kodu, to pisałem je co prawda sam, ale po ich
> napisaniu wszystko musiało być konsultowane z kierownikiem technicznym
> (Technical Lead). Czyli też wychodzi dwie osoby co najmniej.
> 
> Mówi się, że co dwie głowy to nie jedna, ale w przypadku programowania ma też
> znaczenie przyczyna, dla której wymyślono wzmacniacz różnicowy.
> 
Można jaśniej? Interesuje mnie odpowiedź na pytanie, dlaczego źle jest 
zakładać, iż UT ma pisać druga osoba.


-- 
Grzegorz Gruza
Odpowiadając usuń "spamerom_nie." z adresu!!!

"Grzesiek G." <gruza@spamerom_nie.priv4.onet.pl> wrote:

>> Jak ja pisalem UT do "swojego" kodu, to pisalem je co prawda sam, ale po
>> ich napisaniu wszystko musialo byc konsultowane z kierownikiem 
>> technicznym
>> (Technical Lead). Czyli tez wychodzi dwie osoby co najmniej.

>> Mówi sie, ze co dwie glowy to nie jedna, ale w przypadku programowania ma
>> tez znaczenie przyczyna, dla której wymyslono wzmacniacz roznicowy.

> Mozna jasniej? Interesuje mnie odpowiedz na pytanie, dlaczego zle jest
> zakladac, iz UT ma pisac druga osoba.

Zdecydowanie zalezy od sytuacji. W praktyce czesto spotkalem sie z 
przypadkami kiedy UT byly pisane przez programistow z mniejszym stazem, 
poniewaz zatrudnienie do tego "senior developer" (ktory kod podlegajacy 
testowaniu napisal) byloby po prostu zbyt kosztowne. Niewatpliwie jest to 
kwestia kompromisu jak i stopnia zlozonosci testu. Zdarza sie bowiem, ze UT 
jest bardziej skomplikowany niz testowany problem.

Robert Perlinski 

"Robert Perlinski" <robert.perlinski@null.com> wrote:

> Zdarza sie bowiem, ze UT jest bardziej skomplikowany
> niz  testowany problem.

Konsensus pelny :)

AK

Dnia Wed, 9 Nov 2005 18:57:43 +0100, Karpierz, Adam skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > A obiekty Tk (bo taki wła?nie przykład podałem)?

> Jakie obiekty Tk ?
> Nie ma zadnych obiektow TK ani innych.
> W Tcl wszystko jest wylacznie stringiem

button też?


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

> button też?

Wszystko.
Button tez.
Nawet Frame :)

AK

Dnia Wed, 9 Nov 2005 21:13:52 +0100, Karpierz, Adam skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > button też?

> Wszystko.
> Button tez.
> Nawet Frame :)

A canvas albo image twoim zdaniem też jest stringiem?


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

> A canvas albo image twoim zdaniem też jest stringiem?

Dokladnie
Wszystko Sektorku, _wszystko_ !

AK

Dnia Wed, 9 Nov 2005 22:15:02 +0100, Karpierz, Adam skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > A canvas albo image twoim zdaniem też jest stringiem?

> Dokladnie
> Wszystko Sektorku, _wszystko_ !

No cóż, nie wiedziałem że Tcl odkrył jakąś metodę przechowywania obrazków w
postaci stringów (unikodowych przecież!).

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

> No cóż, nie wiedziałem że Tcl odkrył jakąś metodę przechowywania
> obrazków w postaci stringów (unikodowych przecież!).

Sektor ty nie masz pojecia ani o Tcl-u !
Ani o tym czym jest typizacja w jezyku progr w ogole.

AK

Dnia Wed, 9 Nov 2005 23:08:43 +0100, Karpierz, Adam skrobie:
> "Sektor van Skijlen" <ethouris@pl.wp.spamu.lubie.nie.invalid> wrote:

> > No cóż, nie wiedziałem że Tcl odkrył jak?? metodę przechowywania
> > obrazków w postaci stringów (unikodowych przecież!).

> Sektor ty nie masz pojecia ani o Tcl-u !

No jasne.

> Ani o tym czym jest typizacja w jezyku progr w ogole.

W szczególności, jeśli wszystko jest stringiem.



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

>> Sektor ty nie masz pojecia ani o Tcl-u !
>
> No jasne.

Dla mnie tak.

>> Ani o tym czym jest typizacja w jezyku progr w ogole.
>
> W szczególności, jeśli wszystko jest stringiem.

Zapomniales jeszcze o liscie stringow :)

No ale dobrze, jesli  w/g ciebie Tcl jest "typowanmym"
jezykiem to w takim razie podaj mi mechaniz w Tcl
ktory potrafi stwierdzic jaki jest tym np. 1+3
Cos w rodzaju puts type 1+3

Nawet prosciej:
set x 1

Prosze podaj mi jaki jest typ x

set x {lala}

teraz tez pokaz typ x-ksa

AK

Dnia Thu, 10 Nov 2005 09:43:16 +0100, Karpierz, Adam skrobie:
> No ale dobrze, jesli  w/g ciebie Tcl jest "typowanmym"
> jezykiem to w takim razie podaj mi mechaniz w Tcl
> ktory potrafi stwierdzic jaki jest tym np. 1+3
> Cos w rodzaju puts type 1+3

A od kiedy to możliwość jednoznacznego stwierdzenia "jaki jest typ" obiektu
warunkuje typowanie?

Język nie musi udostępniać takiej operacji. Musi jedynie sam umieć rozpoznać
typ obiektu i stosownie do tego podejmować konkretne akcje.

Przykład pierwszy:

set a 16
set b 0x10

# Zeby nie bylo watpliwosci
puts "$a $b"

if { $a == $b } { puts equal. } else { puts not-equal. }

set c "ala"
set d "ala"

if { $c == $d } { puts equal. } else { puts not-equal. }


I co, nie ma tu twoim zdaniem typizacji? To skąd niby interpreter Tcl-a wie,
że $a == $b należy porównać jako liczby, a $c == $d należy porównać jako
napisy?

Przykład drugi:

Dlaczego poniższe operacje powodują rzucenie wyjątku?

set a ala; incr a
if { $a < 2 } exit

Jakbyś trochę uważniej studiował różne dokumentacje, to może byś się
dowiedział, że w Tcl-u każdy obiekt posiada swój typ, który jest taki, w jakim
ostatnio obiekt był używany. Jeśli istnieje potrzeba użycia go w innym typie,
to następuje domyślna konwersja (która może się nie powieść i zakończyć
wyjątkiem).

set a 0  ;# $a jest typu całkowitego
append a x12 ;# $a teraz jest typu string
incr a ;# $a jest znów typu całkowitego


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

> A od kiedy to możliwość jednoznacznego stwierdzenia
> "jaki jest typ" obiektu warunkuje typowanie?

Od zawsze.

> Język nie musi udostępniać takiej operacji. Musi jedynie sam
> umieć rozpoznać typ obiektu i stosownie do tego podejmować
> konkretne akcje.

Aby byla typizacja obiekty w jezyku musze _miec_ typy.

> Przykład pierwszy:
>
> set a 16
> set b 0x10
>
> # Zeby nie bylo watpliwosci
> puts "$a $b"
>
> if { $a == $b } { puts equal. } else { puts not-equal. }
>
> set c "ala"
> set d "ala"
>
> if { $c == $d } { puts equal. } else { puts not-equal. }
>
> I co, nie ma tu twoim zdaniem typizacji?

Nie ma :)

set a {16}      # string, prawda
set b {0x10}  # string, prawda

puts "$a $b"

if { $a == $b } { puts equal. } else { puts not-equal. }

No i ?
Przeciez string {16} w zaden sposob nie jest rowny stringowi {0x10}
a tu mi ciagle pisze:

equals
equals
equals
equals
...
i przestac nie chce

Jakos te Twoje Tcl-owe niby "wewnetrzne typu" zostaly
delikatnei mowiac olane.
Moze ich po prostu w ogole nie ma ? Hę ?

Juz wiesz o co chodzi czy dalej sie upierasz ze znasz Tcl-a ?
Chwaliles sie niedawno ze Twoje programy w Tcl chodza "od reki"...
Hmmm.  Moze i chodza ale chyba wlasnymi sciezkami :)

> To skąd niby interpreter Tcl-a wie, że $a == $b należy porównać jako
>  liczby,  a $c == $d należy porównać jako napisy?

Nie z ich typow ale z ich "wygladu".
Powaznie :)
I nie w momencie set-a ale w zupelnie innych momentach.

Sektorku kochany, znamy sie z newsow tyle lat i tyle lat sie
klocimy a ty ciagle a to C++ nie umiesz, teraz sie okazuje ze
Tcl-a nie umiesz

Co Ty tyle lat robiles ze nie zdazyles sie nauczyc
_nawet_ swoich ulubionych narzedzi ?

AK

Dnia Thu, 10 Nov 2005 19:31:05 +0100, Karpierz, Adam skrobie:
> Nie ma :)

> set a {16}      # string, prawda
> set b {0x10}  # string, prawda

Adamie, za takie bzdury to na comp.lang.tcl by cię wyśmiali.

Co, że niby 16, {16} i "16" czymś się różnią pod względem wartości wynikowej,
czy też typu, jaki posiada zmienna ustawiona komendą set, której podajesz tą
wartość?

Nie, Adamie, ja cię Tcl-a uczyć nie zamierzam. Przynajmniej się nie chwal jego
nieznajomością.

> puts "$a $b"

> if { $a == $b } { puts equal. } else { puts not-equal. }

> No i ?
> Przeciez string {16} w zaden sposob nie jest rowny stringowi {0x10}

[...]

> Jakos te Twoje Tcl-owe niby "wewnetrzne typu" zostaly
> delikatnei mowiac olane.
> Moze ich po prostu w ogole nie ma ? Hę ?

Adamie, prawdą jest, że wartości, jakie zostały podane do komendy 'set' to
jest string. Zarówno w twojej, jak i w mojej wersji.

Prawdą jest również, że po ustawieniu tych wartości do zmiennych komendą set,
mają one typ całkowity (jeśli mi nie wierzysz, zapytaj ludzi na
comp.lang.tcl).

> Juz wiesz o co chodzi czy dalej sie upierasz ze znasz Tcl-a ?

Oczywiście, że się upieram, tyle że w odróżnieniu od ciebie, mam do tego
podstawy.

> > To sk?d niby interpreter Tcl-a wie, że $a == $b należy porównać jako
> >  liczby,  a $c == $d należy porównać jako napisy?

> Nie z ich typow ale z ich "wygladu".
> Powaznie :)
> I nie w momencie set-a ale w zupelnie innych momentach.

W momencie set-a. Jeśli uważasz, że w innych momentach, to masz nieaktualne
informacje (może tak było w poprzednich wersjach Tcl-a, obecnie jest tak).

> Sektorku kochany, znamy sie z newsow tyle lat i tyle lat sie
> klocimy a ty ciagle a to C++ nie umiesz, teraz sie okazuje ze
> Tcl-a nie umiesz

Jak to mawiają "prawda jest jak dupa: każdy ma swoją".

Jeśli dla ciebie znajomość C++ i znajomość Tcl-a oznacza znać te języki
dokładnie tak, jak ty je znasz, to oczywiście mogę swobodnie powiedzieć, że na
takiej zasadzie ich nie znam. I bynajmniej się tego nie wstydzę; wstydziłbym
się dopiero gdybym te języki ZNAŁ tak jak ty.

> Co Ty tyle lat robiles ze nie zdazyles sie nauczyc
> _nawet_ swoich ulubionych narzedzi ?

Zarabiałem na życie stosując je.
;)

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

> Co, że niby 16, {16} i "16" czymś się różnią pod względem wartości
> wynikowej, czy też typu, jaki posiada zmienna ustawiona komendą set,
> której podajesz tą wartość?

W tym sęk, że się nie różnią: koncepcyjnie wszystkie są stringami.

Operator == (ściślej: if, widząc napis z == jako operatorem) sprawdza,
czy oba stringi wyglądają jak liczby. Jeśli tak, to porównuje ich
liczbowe wartości. Jeśli nie, to porównuje je jako stringi. Z tego
powodu używanie go do sprawdzania równości stringów jest ryzykowne,
chyba że statycznie wiemy, że któryś string nie wygląda jak liczba.

W Perlu liczby też są traktowane jako podzbiór stringów. Poza nimi
Perl ma jednak referencje na inne obiekty, a Tcl również je symuluje
napisami.

Prawie wszystkie dynamicznie typowane języki (poza Perlem, Tclem
i uniksowymi szelami) używają wielu rozłącznych typów. Dzięki temu
podanie wartości złego typu jest zwykle wykryte w czasie wykonania.
Dzięki temu też można programować obiektowo również na podstawowych
typach: jeden zapis abstrakcyjnej operacji (np. równości albo
mniejszości) ma różną interpretację w zależności od typów obiektów.

Jeśli natomiast koncepcyjnie różne wartości są modelowane przez
włożenie do tego samego typu (stringu), to trzeba jawnie określić,
o którą interpretację chodzi, przez wybór operacji, a pomyłki w tym
zakresie nie są wykrywane.

Gdyby == w Tcl było błędem na stringach nie wyglądających jak liczby,
to przynajmniej błędy w jedną stronę byłyby wykrywane.

> W momencie set-a. Jeśli uważasz, że w innych momentach, to masz
> nieaktualne informacje (może tak było w poprzednich wersjach Tcl-a,
> obecnie jest tak).

To jest szczegół implementacyjny, którego nie widać w semantyce.

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

Dnia Sat, 12 Nov 2005 14:17:40 +0100, Marcin 'Qrczak' Kowalczyk skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> > Co, że niby 16, {16} i "16" czymś się różnią pod względem wartości
> > wynikowej, czy też typu, jaki posiada zmienna ustawiona komendą set,
> > której podajesz tą wartość?

> W tym sęk, że się nie różnią: koncepcyjnie wszystkie są stringami.

> Operator == (ściślej: if, widząc napis z == jako operatorem) sprawdza,
> czy oba stringi wyglądają jak liczby.

Właśnie nie do końca jest tak. W moomencie gdy wykonujesz komendę "set", to
już wtedy jest dokonane sprawdzenie, czy to wygląda jak liczba. Oczywiście w
obiekcie Tcl-owym jest przechowywany zarówno string w takiej postaci, w jakiej
podano go do set, ale także liczba całkowita.

Ponieważ string uważa się za podstawowy sposób przechowywania informacji, więc
jego zawężenie 'typ całkowity' uważa się za typ tego obiektu.

> Jeśli tak, to porównuje ich
> liczbowe wartości. Jeśli nie, to porównuje je jako stringi. Z tego

Jeśli przypadkiem mogłoby się zdarzyć, że dany string "nie jest liczbą", to
następuje próba dokonania domyślnej konwersji na liczbę. Jeśli się nie
powiedzie, to jest to string. Ale z tego, co ja się ostatnio orientuję, to
taka operacja w ogóle nie ma miejsca w operatorze ==, ani w ogóle w arytmetyce
(właśnie dlatego stanowczo doradza się, żeby argument do komendy expr szedł w
klamrach, bo wtedy wykonuje się szybciej). Ma za to miejsce we wszelkich
'set-ach' (czyli również incr i append).

Przykładowo: jeśli dwie zmienne przechowują jakieś liczby i zostanie wykonana
operacja arytmetyczna na ich wartościach, a nowa zostanie zwrócona przez
wartość i wpisana do innej zmiennej, to w tym wszystkim może się ani razu nie
odbyć konwersja int -> string (ani tym bardziej odwrotnie). Wartość zostanie
zwrócona przez obiekt Tcl-owy, a wykonujące się tu operacje są wyłącznie
zainteresowane wartością całkowitą; to, czy ten obiekt przechowuje wartość
również w wersji stringa, to ich serdecznie wali.

> powodu używanie go do sprawdzania równości stringów jest ryzykowne,
> chyba że statycznie wiemy, że któryś string nie wygląda jak liczba.

Zazwyczaj tak jest. Jeśli porównujemy ze "statycznym" stringiem, który widać,
że nie jest liczbą, to możemy bezpiecznie używać operatora ==. Operatora eq
należy używać tylko gdy porównujemy arbitralne stringi, albo wiemy że
porównujemy liczby, a chcemy je porównać co do znaku.

> W Perlu liczby też są traktowane jako podzbiór stringów. Poza nimi

Tak, tylko że tam konwersja stringa na liczbę nie rzuca wyjątkiem w razie
niepowodzenia, tylko zwraca wartość 0.

> Perl ma jednak referencje na inne obiekty, a Tcl również je symuluje
> napisami.

Też nie do końca masz rację. Te referencje są jedynie REPREZENTOWALNE jako
stringi. Po prostu w Tcl-u każda wartość musi być jedynie reprezentowalna jako
string. Ale wcale to nie oznacza, że dane przechowuje się tylko jako stringi.

> Prawie wszystkie dynamicznie typowane języki (poza Perlem, Tclem
> i uniksowymi szelami) używają wielu rozłącznych typów. Dzięki temu
> podanie wartości złego typu jest zwykle wykryte w czasie wykonania.
> Dzięki temu też można programować obiektowo również na podstawowych
> typach: jeden zapis abstrakcyjnej operacji (np. równości albo
> mniejszości) ma różną interpretację w zależności od typów obiektów.

No tak, ale potrafi ją rozpoznać. I o to właśnie chodzi. Na takiej samej
zasadzie działa == w Tcl-u.

> Jeśli natomiast koncepcyjnie różne wartości są modelowane przez
> włożenie do tego samego typu (stringu), to trzeba jawnie określić,
> o którą interpretację chodzi, przez wybór operacji, a pomyłki w tym
> zakresie nie są wykrywane.

Nie no teoretycznie mógłbyś spróbować zrobić [read 0]. Ale wartość "0"
momentalnie zostanie wykryta jako niepoprawny deskryptor pliku.

Problem jest tylko wtedy gdy budujesz np. strukturę drzewiastą, gdzie wieszasz
różne obiekty, których typy jakoś musiałbyś rozpoznać. Można tu stosować różne
metody, w tym wieszać tylko identyfikatory obiektów IncrTcl i odpytywać je
przez isa (lub po prostu kazać im zrobić konkretne rzeczy).

> Gdyby == w Tcl było błędem na stringach nie wyglądających jak liczby,
> to przynajmniej błędy w jedną stronę byłyby wykrywane.

Nie no można byłoby zrobić tak, można było zrobić "fallback" do porównania
stringów, co zrobiono.

Zawsze możesz np. napisać:

if { $a+0 == $b }

i wtedy dostaniesz wyjątek, jeśli '$a' nie wygląda jak liczba. A sprawdzać czy
$b jest liczbą już i tak nie musisz, bo jak nie będzie liczbą, to porównanie
zwróci false.

> > W momencie set-a. Jeśli uważasz, że w innych momentach, to masz
> > nieaktualne informacje (może tak było w poprzednich wersjach Tcl-a,
> > obecnie jest tak).

> To jest szczegół implementacyjny, którego nie widać w semantyce.

Wiesz, to wszystko zależy.

Jeśli mówimy, że wszystko jest stringiem, to możemy powiedzieć, że typizacji
nie ma.

Jeśli mówimy, że każdy obiekt ma swój określony typ, a jedynie istnieje wymóg,
aby każda wartość była reprezentowalna w postaci stringa, to sytuacja wygląda
na inną, choć to semantyki faktycznie nie zmienia.

CO więc takiego jest w tej semantyce, co decydowałoby o tym, że Tcl nie
posiada 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"

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

[...]

> Ponieważ string uważa się za podstawowy sposób przechowywania
> informacji, więc jego zawężenie 'typ całkowity' uważa się za typ
> tego obiektu.

Ja myślałem, że w Tcl jest podobnie, jak w Pythonie, tj. obiekty mają
jakiś tam typ i przy każdej operacji typy są uzgadniane.

Dnia Sat, 12 Nov 2005 20:54:27 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> [...]

> > Ponieważ string uważa się za podstawowy sposób przechowywania
> > informacji, więc jego zawężenie 'typ całkowity' uważa się za typ
> > tego obiektu.

> Ja myślałem, że w Tcl jest podobnie, jak w Pythonie, tj. obiekty mają
> jakiś tam typ i przy każdej operacji typy są uzgadniane.

No mniej więcej tak jest. Faktyczny typ obiektu jest taki, w jakim był
ostatnio używany.

Ale np. komenda 'set' nadaje zmiennej typ całkowity, jeśli string, który się
tam ustawia można przekształcić na liczbę. W Pythonie, o ile pamiętam,
literały tekstowe i liczbowe się różnią. Taka jest mniej więcej różnica.

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

>> Operator == (ściślej: if, widząc napis z == jako operatorem) sprawdza,
>> czy oba stringi wyglądają jak liczby.
>
> Właśnie nie do końca jest tak. W moomencie gdy wykonujesz komendę
> "set", to już wtedy jest dokonane sprawdzenie, czy to wygląda jak
> liczba.

Nieważne, jak to jest implementowane - ważne, jak się zachowuje.
A zachowuje się tak, że liczby, tablice itp. są wyrażone przez stringi.
Nie ma rozróżnienia między liczbą a stringiem, który wygląda jak liczba.

>> Prawie wszystkie dynamicznie typowane języki (poza Perlem, Tclem
>> i uniksowymi szelami) używają wielu rozłącznych typów. Dzięki temu
>> podanie wartości złego typu jest zwykle wykryte w czasie wykonania.
>> Dzięki temu też można programować obiektowo również na podstawowych
>> typach: jeden zapis abstrakcyjnej operacji (np. równości albo
>> mniejszości) ma różną interpretację w zależności od typów obiektów.
>
> No tak, ale potrafi ją rozpoznać. I o to właśnie chodzi. Na takiej samej
> zasadzie działa == w Tcl-u.

W Tcl to tak nie działa. Nie można mieć jednej operacji, która działa
w sposób odpowiedni dla stringów i liczb w zależności od typów
argumentów, bo stringi wyglądające jak liczby są tym samym co liczby
i dla takich wartości mamy konflikt interpretacji tej operacji.

To samo dotyczy stringów używanych wymiennie z innymi typami. Nie
można mieć jednej funkcji, która wyszukuje znak w stringu bądź element
w tablicy, tudzież która generuje permutacje stringu bądź tablicy, bo
tablica jest szczególnym przypadkiem stringu (w taki sposób, że jeden
element nie odpowiada jednemu znakowi). Każdy interfejs musi mieć
osobne wersje dla stringów i osobne dla innych typów.

> Jeśli mówimy, że każdy obiekt ma swój określony typ, a jedynie
> istnieje wymóg, aby każda wartość była reprezentowalna w postaci
> stringa, to sytuacja wygląda na inną, choć to semantyki faktycznie
> nie zmienia.

W takiej interpretacji Tcl nie oferuje typu string w zwyczajnym
rozumieniu (rozłącznego z innymi typami), tylko coś pełniącego rolę
typu uniwersalnego (tzn. typu Object).

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

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

>> Operator == (ściślej: if, widząc napis z == jako operatorem) sprawdza,
>> czy oba stringi wyglądają jak liczby.
>
> Właśnie nie do końca jest tak. W moomencie gdy wykonujesz komendę
> "set", to już wtedy jest dokonane sprawdzenie, czy to wygląda jak
> liczba.

Nieważne, jak to jest implementowane - ważne, jak się zachowuje.
A zachowuje się tak, że liczby, tablice itp. są wyrażone przez stringi.
Nie ma rozróżnienia między liczbą a stringiem, który wygląda jak liczba.

>> Prawie wszystkie dynamicznie typowane języki (poza Perlem, Tclem
>> i uniksowymi szelami) używają wielu rozłącznych typów. Dzięki temu
>> podanie wartości złego typu jest zwykle wykryte w czasie wykonania.
>> Dzięki temu też można programować obiektowo również na podstawowych
>> typach: jeden zapis abstrakcyjnej operacji (np. równości albo
>> mniejszości) ma różną interpretację w zależności od typów obiektów.
>
> No tak, ale potrafi ją rozpoznać. I o to właśnie chodzi. Na takiej samej
> zasadzie działa == w Tcl-u.

W Tcl to tak nie działa. Nie można mieć jednej operacji, która działa
w sposób odpowiedni dla stringów i liczb w zależności od typów
argumentów, bo stringi wyglądające jak liczby są tym samym co liczby
i dla takich wartości mamy konflikt interpretacji tej operacji.

To samo dotyczy stringów używanych wymiennie z innymi typami. Nie
można mieć jednej funkcji, która wyszukuje znak w stringu bądź element
w tablicy, tudzież która generuje permutacje stringu bądź tablicy, bo
tablica jest szczególnym przypadkiem stringu (w taki sposób, że jeden
element nie odpowiada jednemu znakowi). Każdy interfejs musi mieć
osobne wersje dla stringów i osobne dla innych typów.

Co gorsza, to utrudnia tworzenie grafów współdzielonych obiektów
i wyklucza odśmiecanie. Stringa można rozłożyć na części i potem
złożyć z powrotem, więc uzależnianie czasu życia obiektów od istnienia
dowiązań do nich nie miałoby sensu.

> Jeśli mówimy, że każdy obiekt ma swój określony typ, a jedynie
> istnieje wymóg, aby każda wartość była reprezentowalna w postaci
> stringa, to sytuacja wygląda na inną, choć to semantyki faktycznie
> nie zmienia.

W takiej interpretacji Tcl nie oferuje typu string w zwyczajnym
rozumieniu (rozłącznego z innymi typami), tylko coś pełniącego rolę
typu uniwersalnego (tzn. typu Object).

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

Dnia Sun, 13 Nov 2005 12:22:41 +0100, Marcin 'Qrczak' Kowalczyk skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> >> Operator == (ściślej: if, widząc napis z == jako operatorem) sprawdza,
> >> czy oba stringi wyglądają jak liczby.
> >
> > Właśnie nie do końca jest tak. W moomencie gdy wykonujesz komendę
> > "set", to już wtedy jest dokonane sprawdzenie, czy to wygląda jak
> > liczba.

> Nieważne, jak to jest implementowane - ważne, jak się zachowuje.
> A zachowuje się tak, że liczby, tablice itp. są wyrażone przez stringi.

Bzdura. Te wszystkie rzeczy mogą być jedynie niejawnie konwertowane na
stringi.

> Nie ma rozróżnienia między liczbą a stringiem, który wygląda jak liczba.

Jeśli zapiszesz w zmiennej wartość całkowitą i to jeszcze powstałą z jakiegoś
expr, to ma ona typ całkowity. Nie posiada nawet W OGÓLE reprezentacji w
postaci stringa. Będzie tą reprezentację posiadała dopiero gdy np. każesz to
wypisać na ekranie (albo nawet powiedzmy zaiterować).

I wtedy nie jest to string, który wygląda jak liczba, tylko naprawdę liczba.
String, który wygląda jak liczba to może z niej dopiero powstać.

> >> Prawie wszystkie dynamicznie typowane języki (poza Perlem, Tclem
> >> i uniksowymi szelami) używają wielu rozłącznych typów. Dzięki temu
> >> podanie wartości złego typu jest zwykle wykryte w czasie wykonania.
> >> Dzięki temu też można programować obiektowo również na podstawowych
> >> typach: jeden zapis abstrakcyjnej operacji (np. równości albo
> >> mniejszości) ma różną interpretację w zależności od typów obiektów.
> >
> > No tak, ale potrafi ją rozpoznać. I o to właśnie chodzi. Na takiej samej
> > zasadzie działa == w Tcl-u.

> W Tcl to tak nie działa. Nie można mieć jednej operacji, która działa
> w sposób odpowiedni dla stringów i liczb w zależności od typów
> argumentów, bo stringi wyglądające jak liczby są tym samym co liczby
> i dla takich wartości mamy konflikt interpretacji tej operacji.

Nieprawda. Operacja porównania liczbowego jest wybierana jeśli obie wartości
mają typ całkowity. Jeśli co najmniej jedna z nich takiego nie posiada, to
wtedy wybiera się porównanie stringów.

I właśnie dlatego to działa.

> To samo dotyczy stringów używanych wymiennie z innymi typami. Nie
> można mieć jednej funkcji, która wyszukuje znak w stringu bądź element
> w tablicy, tudzież która generuje permutacje stringu bądź tablicy, bo
> tablica jest szczególnym przypadkiem stringu (w taki sposób, że jeden
> element nie odpowiada jednemu znakowi). Każdy interfejs musi mieć
> osobne wersje dla stringów i osobne dla innych typów.

Tu problem polega na tym, że lista nie jest automatycznie dosynchronizowywana,
w odróżnieniu od typów całkowitych. Musisz zatem jawnie za każdym razem
określać, że dana wartość jest listą albo stringiem. Dlatego zamiast
wprowadzać dodatkowe mechanizmy wymuszające reprezentację typu, używa się
osobnych komend do list i stringów.

Niedawno zresztą miałem jednego zagwoździa, bo nie wiedziałem, jak iterować po
kolejnych znakach stringu. Ale wystarczyło zrobić "subst -all $s . {& }".

> Co gorsza, to utrudnia tworzenie grafów współdzielonych obiektów

To się zgadza - ale do tego nie trzeba koniecznie stosować mechanizmów
dostarczanych przez sam język.

> i wyklucza odśmiecanie.

Tu niekoniecznie. Zależy na jakim poziomie miałby on działać. Istnieją
biblioteki do Tcl-a dysponujące własnymi odśmiecaczami.

> Stringa można rozłożyć na części i potem
> złożyć z powrotem, więc uzależnianie czasu życia obiektów od istnienia
> dowiązań do nich nie miałoby sensu.

Tego nie wiem. Na pewno odśmiecania takiego "powszechnego" zrobić się nie da.

> > Jeśli mówimy, że każdy obiekt ma swój określony typ, a jedynie
> > istnieje wymóg, aby każda wartość była reprezentowalna w postaci
> > stringa, to sytuacja wygląda na inną, choć to semantyki faktycznie
> > nie zmienia.

> W takiej interpretacji Tcl nie oferuje typu string w zwyczajnym
> rozumieniu (rozłącznego z innymi typami), tylko coś pełniącego rolę
> typu uniwersalnego (tzn. typu Object).

Ale jego uniwersalność niewiele ma do rzeczy.

I nie jest to Object, bo w Tcl-u można posługiwać się obiektami w ogóle nie
obsługiwanymi na tym poziomie (istnieje to tylko dla typów wbudowanych).

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

>> Nieważne, jak to jest implementowane - ważne, jak się zachowuje.
>> A zachowuje się tak, że liczby, tablice itp. są wyrażone przez stringi.
>
> Bzdura. Te wszystkie rzeczy mogą być jedynie niejawnie konwertowane na
> stringi.

Nieprawda, one są stringami (koncepcyjnie, implementacja jest nieważna).

No chyba że chcesz stwierdzić, że w Tcl nie istnieją stringi składające
się z samych cyfr. Ale ten punkt widzenia byłby już całkiem niespójny:
zbiór stringów miałby nieregularny kształt, z dziurami pozostawionymi
przez inne typy.

Jeśli i z tym też się nie zgadzasz, to pokaż, jak rozróżnić 42 od "42".

>> W Tcl to tak nie działa. Nie można mieć jednej operacji, która
>> działa w sposób odpowiedni dla stringów i liczb w zależności od
>> typów argumentów, bo stringi wyglądające jak liczby są tym samym
>> co liczby i dla takich wartości mamy konflikt interpretacji tej
>> operacji.
>
> Nieprawda. Operacja porównania liczbowego jest wybierana jeśli obie
> wartości mają typ całkowity. Jeśli co najmniej jedna z nich takiego
> nie posiada, to wtedy wybiera się porównanie stringów.

Czyli "42" ma typ całkowity? Ciekawe pojęcie typu. I ciekawe pojęcie
stringa.

Kiedy robię operację dispatchowaną po typie, to oczekuję, że będzie
traktowała "foo", "42" i "foo42" tak samo.

> Tu problem polega na tym, że lista nie jest automatycznie
> dosynchronizowywana, w odróżnieniu od typów całkowitych.

Nie ma żadnego "w odróżnieniu". Relacja między liczbami a stringami
jest taka sama jak relacja między listami a stringami. To znaczy
pierwsze są tylko podzbiorem drugich.

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

Dnia Sun, 13 Nov 2005 17:11:09 +0100, Marcin 'Qrczak' Kowalczyk skrobie:
> >> Nieważne, jak to jest implementowane - ważne, jak się zachowuje.
> >> A zachowuje się tak, że liczby, tablice itp. są wyrażone przez stringi.
> >
> > Bzdura. Te wszystkie rzeczy mogą być jedynie niejawnie konwertowane na
> > stringi.

> Nieprawda, one są stringami (koncepcyjnie, implementacja jest nieważna).

Jejku, to jest naprawdę mało istotne, czy te obiekty są faktycznie
reprezentowane wewnętrznie wyłącznie przez stringi, czy też na string
następuje tylko konwersja konieczna do pokazania na ekranie. To nie przeczy
temu, że obiekty jednak te typy mają.

> No chyba że chcesz stwierdzić, że w Tcl nie istnieją stringi składające
> się z samych cyfr.

Nie, Qrczak. To jest jeszcze gorzej. Istnieją te stringi jak najbardziej, tyle
że obiekty zainicjalizowane takim stringiem posiadają dwa typy jednocześnie.
Jeśli zmienna jest jawnie zapisywana stringiem składającym się z cyfr, to
oczywiście następuje kopiowanie łańcucha znaków, ale równocześnie
dosynchronizowanie z typem całkowitym. W ten sposób obiekt jest reprezentowany
przez dwa typy jednocześnie.

> Ale ten punkt widzenia byłby już całkiem niespójny:
> zbiór stringów miałby nieregularny kształt, z dziurami pozostawionymi
> przez inne typy.

No więc nie jest aż tak.

> Jeśli i z tym też się nie zgadzasz, to pokaż, jak rozróżnić 42 od "42".

Nie rozumiem, co masz na myśli.

W Tcl-u nie ma pojęcia typów takiego, że - powiedzmy - obiekt ma jeden
przypisany konkretny typ. Obiekt jest jedynie reprezentowany w różnych typach
na ile jest to możliwe.

Nie jest zatem możliwe rozróżnienie typu "int albo string". Jest możliwe tylko
stwierdzenie, czy taka wartość może być stringiem i intem równocześnie, czy
też może być tylko stringiem.

> >> W Tcl to tak nie działa. Nie można mieć jednej operacji, która
> >> działa w sposób odpowiedni dla stringów i liczb w zależności od
> >> typów argumentów, bo stringi wyglądające jak liczby są tym samym
> >> co liczby i dla takich wartości mamy konflikt interpretacji tej
> >> operacji.
> >
> > Nieprawda. Operacja porównania liczbowego jest wybierana jeśli obie
> > wartości mają typ całkowity. Jeśli co najmniej jedna z nich takiego
> > nie posiada, to wtedy wybiera się porównanie stringów.

> Czyli "42" ma typ całkowity? Ciekawe pojęcie typu. I ciekawe pojęcie
> stringa.

Tak, dokładnie.

> Kiedy robię operację dispatchowaną po typie, to oczekuję, że będzie
> traktowała "foo", "42" i "foo42" tak samo.

Nie rozumiem. Co mają do tego ""? W Tcl-u nie ma czegoś takiego (tzn. jest
jako element składni, ale z typowaniem nie ma to nic wspólnego).

Ale nie rozumiem, co ci tu może nie działać. Że co, chciałbyś mieć coś w
rodzaju:

myexpr { $a + $b }

które zwróci ci wynik dodawania, jeśli to są liczby całkowite, albo sklejony
string, jeśli to są stringi?

No to niestety, w Tcl-u tak się nie robi.

A to, że operator == tak działa, jak działa, to tylko jego szczególna cecha,
polegająca na tym, że jak nie są liczbami oba argumenty, to robi "fallback" na
[string equal]. Mógłby robić inaczej, np. rzucać wyjątkiem, ale zrobiono
akurat taki fallback.

W OCamlu też są typy i to nawet statyczne, a jakoś istnieje oddzielny zestaw
operatorów arytmetycznych dla wartości całkowitych i rzeczywistych. Czemu?

> > Tu problem polega na tym, że lista nie jest automatycznie
> > dosynchronizowywana, w odróżnieniu od typów całkowitych.

> Nie ma żadnego "w odróżnieniu". Relacja między liczbami a stringami
> jest taka sama jak relacja między listami a stringami. To znaczy
> pierwsze są tylko podzbiorem drugich.

Nie no oczywiście jak najbardziej arbitralny string może się konwertować na
listę (chyba że nie może, np. ma niezbalansowane klamry lub ciapki), co
więcej, w Tcl-u bardzo często się z tego korzysta. Lista zatem jest
"podzbiorem" stringa, podobnie jak liczba (liczba zresztą może być również
listą z jednym elementem).

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

> Istnieją te stringi jak najbardziej, tyle że obiekty zainicjalizowane
> takim stringiem posiadają dwa typy jednocześnie.

Ok, czyli mój zarzut sprowadza się do tego, że typ liczb (i każdy
inny) jest podtypem stringów. Przez to automatycznie nie wiadomo,
kiedy string reprezentuje napis, a kiedy inne typy.

> Ale nie rozumiem, co ci tu może nie działać. Że co, chciałbyś mieć
> coś w rodzaju:
>
> myexpr { $a + $b }
>
> które zwróci ci wynik dodawania, jeśli to są liczby całkowite,
> albo sklejony string, jeśli to są stringi?

Technicznie tak, choć w tym akurat przypadku jestem zdania,
że dodawanie liczb i dodawanie stringów różnią się tak mocno
(i zawsze statycznie wiadomo, które mamy na myśli), że lepiej
oznaczać je różnie.

Rzeczywiste przykłady dispatchowanych funkcji, w których stringi mogą
brać udział, ale model Tcl na to nie pozwala: równość, porządek, to
co z nich wynika (rozpoznawanie kluczy w słowniku, szukanie elementu
w ciągu, sortowanie), operacje na ciągach (podciągi, aplikacja funkcji
do każdego elementu, sortowanie, szukanie elementu liniowe i binarne -
tym razem z punktu widzenia różnych typów ciągów, a nie różnych typów
elementów).

> W OCamlu też są typy i to nawet statyczne, a jakoś istnieje
> oddzielny zestaw operatorów arytmetycznych dla wartości całkowitych
> i rzeczywistych. Czemu?

Bo system typów OCamla nie obsługuje przeciążania i uznano,
że sytuacji, w których jest przydatne, jest wystarczająco mało,
że nie chcą go w tym miejscu komplikować. Przy czym jest to często
pojawiający się zarzut, były próby rozwiązania (generic OCaml),
a podobne języki stosują ten sam operator do tego samego działania
na różnych typach liczbowych, choć uzyskują to za pomocą różnych
mechanizmów (SML - ad hoc reguły dla wbudowanych operatorów i typów,
Haskell, Clean i Mercury - system tzw. klas, Miranda - jeden typ
liczbowy; oczywiście problem dotyczy tylko statycznie typowanych
języków).

Do tego rodzaju systemów typów przeciążanie naprawdę pasuje słabo.
System haskelowych klas jest moim zdaniem jedynym dobrym rozwiązaniem
w tym kontekście, przy czym koszt to spore skomplikowanie systemu
typów i brak principal types, co w praktyce oznacza możliwość
niejednoznaczności i przez to potrzeby jawnego określenia typu
podwyrażenia.

Statycznie typowane języki z rodziny "obiektowej" zazwyczaj
uwzględniają przeciążanie (w sposób mniej lub bardziej ad hoc, choć
koncepcyjnie jest im łatwo), bo podjęły inne powiązane decyzje: przede
wszystkim podtypianie z niejawną subsumpcją, niejawne konwersje typów,
brak dedukowania typów zmiennych z kontekstu użycia (type inference)
i jawne deklarowanie polimorfizmu parametrycznego. Trudno mieszać te
dwie rodziny systemów typów, choć niektóre języki próbują (Nemerle,
C# 3.0).

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

Dnia Sun, 13 Nov 2005 21:23:53 +0100, Marcin 'Qrczak' Kowalczyk skrobie:
> Sektor van Skijlen <ethouris@pl.wp.spamu.lubie.nie.invalid> writes:

> > Istnieją te stringi jak najbardziej, tyle że obiekty zainicjalizowane
> > takim stringiem posiadają dwa typy jednocześnie.

> Ok, czyli mój zarzut sprowadza się do tego, że typ liczb (i każdy
> inny) jest podtypem stringów. Przez to automatycznie nie wiadomo,
> kiedy string reprezentuje napis, a kiedy inne typy.

No... no tak. Co najwyżej wiadomo tylko, że dany string nie mógłby
reprezentować listy albo liczby.

> > Ale nie rozumiem, co ci tu może nie działać. Że co, chciałbyś mieć
> > coś w rodzaju:
> >
> > myexpr { $a + $b }
> >
> > które zwróci ci wynik dodawania, jeśli to są liczby całkowite,
> > albo sklejony string, jeśli to są stringi?

> Technicznie tak, choć w tym akurat przypadku jestem zdania,
> że dodawanie liczb i dodawanie stringów różnią się tak mocno
> (i zawsze statycznie wiadomo, które mamy na myśli), że lepiej
> oznaczać je różnie.

Nie no rozumiem.

> Rzeczywiste przykłady dispatchowanych funkcji, w których stringi mogą
> brać udział, ale model Tcl na to nie pozwala: równość, porządek,

O równości już rozmawialiśmy.

Co do porządkowania, to się akurat niespecjalnie zgodzę. Jeśli chcesz mieć
zbiornik odpowiednio porządkowany, to też musisz owo porządkowanie
zdefiniować. I to pod kątem tego, co zawiera dany zbiornik, bo chyba nie
chcesz mi powiedzieć, że porządkowałbyś zbiornik, który mógłby zawierać
zarówno liczby jak i stringi.

> to
> co z nich wynika (rozpoznawanie kluczy w słowniku, szukanie elementu
> w ciągu, sortowanie),

Nie no to wszystko można zrealizować za pomocą opakowań w klasy. Za pomocą
samego Tcl-a się nie da, bo nie był do tego przewidziany. Z tego zresztą
względu taka ilość opcji w polecenicah lsearch i lsort.

> operacje na ciągach (podciągi, aplikacja funkcji
> do każdego elementu, sortowanie, szukanie elementu liniowe i binarne -
> tym razem z punktu widzenia różnych typów ciągów, a nie różnych typów
> elementów).

Owszem, można to zrobić np. obiektowo.

W Tcl-u na upartego możesz nawet zmusić zwykłe liczby całkowite do tego, żeby
miały swoje metody. Wystarczy, że odpowiednio pomanipulujesz komendą
"unknown". ;)

> Statycznie typowane języki z rodziny "obiektowej" zazwyczaj
> uwzględniają przeciążanie (w sposób mniej lub bardziej ad hoc, choć
> koncepcyjnie jest im łatwo), bo podjęły inne powiązane decyzje: przede
> wszystkim podtypianie z niejawną subsumpcją, niejawne konwersje typów,
> brak dedukowania typów zmiennych z kontekstu użycia (type inference)
> i jawne deklarowanie polimorfizmu parametrycznego. Trudno mieszać te
> dwie rodziny systemów typów, choć niektóre języki próbują (Nemerle,
> C# 3.0).

I C++ chyba też ;)

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