On 2011-08-17, Michal Kleczek <k...@p...onet.pl> wrote:
> On 2011-08-17 15:12, Stachu 'Dozzie' K. wrote:
>> On 2011-08-17, Michal Kleczek<k...@p...onet.pl> wrote:
>>>
>>> W koncu nie wiem, czy chcesz miec kontrole statyczna, czy dynamiczna.
>>
>> Chcę statyczną, ale jak się nie da (bo Java jest typowana statycznie ale
>> dynamicznie), to niech będzie *jakakolwiek*. A nie żeby mnie zaskakiwało
>> że mimo wszystko do ArrayList<Integer> da się dodać Stringa.
>>
>
> No przeciez sie nie da - tu dostaniesz blad kompilacji:
>
> void funkcja(ArrayList<Integer> lista) {
> lista.add("string");
> }

No przecież pokazałem że się da. Nie próbuj mi wmawiać że parę
szczególnych przypadków przytoczonych przez ciebie wystarcza żeby mówić
o statycznej kontroli typów w Javie. Równie dobrze możesz mówić że Perl
ma statyczną kontrolę typów, bo *da się wyprodukować pewną sytuację* gdy
na etapie parsowania interpreter zgłosi niezgodność typów.

>>> Nie rozumiem. W ogolnosci po wprowadzeniu generykow nie ma potrzeby
>>> _explicite_ sprawdzac typu w runtime (czyli nie ma potrzeby robienia
>>> rzutowania explicite). Niczym to sie nie rozni od dowolnego innego
>>> jezyka bez RTTI.
>>
>> Trochę się różni. Miałeś przykład. Typowanie statyczne albo jest, albo
>> go nie ma. W Javie jest taka podpierdółka, więc liczy się że nie ma.
>>
>
> Przy takim podejsciu to zaden jezyk nie ma, bo chyba (tutaj - fakt -
> potrzebuje wsparcia mocniejszych teoretykow) nie da sie zrobic jezyka
> "turing complete" bez operacji "unsafe" czyli nieweryfikowalnych
> statycznie (takich jak rzutowanie).

Przepraszam, ale dlaczego w Adzie się dało zrobić poprawnie silny system
typów? Dlaczego dało się w Haskellu i SML-u? Nie wyskakuj mi więc
z pomysłem że rzutowanie jest ogólnie niebezpieczną operacją,
niemożliwą do weryfikacji podczas kompilacji, bo nie jest.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2011-08-17, Michal Kleczek <k...@p...onet.pl> wrote:
> On 2011-08-17 15:29, Marcin Biegan wrote:
>> W dniu 2011-08-17 14:59, Michal Kleczek pisze:
>>> Gwoli uczciwosci w dyskusji: jak ja rozumiem te argumentacje (chociaz
>>> sie z nia nie zgadzam), to mowi ona tyle, ze i tak musisz miec testy,
>>> zas - w praktyce - jezeli juz je masz to wykrywaja one bledy, ktorych
>>> nie wykryje kompilator.
>>> Wiec to nie jest tak, ze piszemy testy by zastapic statyczna
>>> weryfikacje, lecz piszemy testy tak czy inaczej i niejako przy okazji
>>> mozemy zrezygnowac ze statycznej kontroli typow (bo mamy testy).
>>
>> I piszesz normalnie w silnie-typowanym języku testy sprawdzające typy
>> argumentów? Czy jak zamiast int przekażesz double to rzuci wyjątek?
>
> Nie w tym rzecz - piszesz testy weryfikujace logike programu. Te testy
> niejako przy okazji wykrywaja te same bledy, ktore wykrylby kompilator
> jezyka statycznie typowanego.

Tylko że nie wykryją wszystkiego, bo 1) najpierw funkcja się musi
uruchomić i 2) jak już się uruchomi, to musi zajść sytuacja że funkcja
dostała niezgodny typ. To w języku dynamicznym może zależec od ścieżki,
którą pójdzie program. Trochę do dupy twój pomysł z zastępowaniem
statycznego typowania testami.

> Fakt, ze argumentacja zwolennikow "dynamicznie typowanych" jezykow jest
> pokretna :) - mowia oni "jezeli twoje testy nie wykryly takiego bledu,
> to masz za malo testow".

Zawsze masz za mało testów żeby uzyskać pewność. W języku statycznie
typowanym dostajesz pewność zgodności typów przez sam fakt skompilowania
programu.

--
Secunia non olet.
Stanislaw Klekot

do góry

W dniu 2011-08-17 15:42, Stachu 'Dozzie' K. pisze:
[...]
>> Fakt, ze argumentacja zwolennikow "dynamicznie typowanych" jezykow jest
>> pokretna :) - mowia oni "jezeli twoje testy nie wykryly takiego bledu,
>> to masz za malo testow".
>
> Zawsze masz za mało testów żeby uzyskać pewność. W języku statycznie
> typowanym dostajesz pewność zgodności typów przez sam fakt skompilowania
> programu.

Trochę mi to przypomina argumentację zwolenników "czystego" C, że RAII
jest niepotrzebne i można to samo osiągnąć umieszczeniem free()/fclose()
gdzie trzeba (oraz być może testami na tę okoliczność). Jasne, że można.
Tyle, że RAII (oraz statyczna kontrola typów) może automatycznie
(czyli bezbłędnie) wygenerować część kodu zwalniającego (część testów).

Nie przeczę, że testy warto mieć, a statyczne typowanie nie zastąpi
testów w ogólności. Ale świetnie, a co najważniejsze - automatycznie,
zastępuje część testów dotyczących zgodności typów.

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

do góry

Dnia 17-08-2011 o 15:39:36 Stachu 'Dozzie' K.
<d...@g...eat.some.screws.spammer.invalid> napisał(a):

[...]
> Przepraszam, ale dlaczego w Adzie się dało zrobić poprawnie silny system
> typów? Dlaczego dało się w Haskellu i SML-u? Nie wyskakuj mi więc
> z pomysłem że rzutowanie jest ogólnie niebezpieczną operacją,
> niemożliwą do weryfikacji podczas kompilacji, bo nie jest.

Haskell ma rzutowanie? jak wygląda?

--
Jordan Szubert

do góry

On 2011-08-17, Jordan Szubert <u...@j...us.to> wrote:
> Dnia 17-08-2011 o 15:39:36 Stachu 'Dozzie' K.
><d...@g...eat.some.screws.spammer.invalid> napisał(a):
>
> [...]
>> Przepraszam, ale dlaczego w Adzie się dało zrobić poprawnie silny system
^^^^^^^^^^^^
>> typów? Dlaczego dało się w Haskellu i SML-u? Nie wyskakuj mi więc
^^^^^
>> z pomysłem że rzutowanie jest ogólnie niebezpieczną operacją,
>> niemożliwą do weryfikacji podczas kompilacji, bo nie jest.
>
> Haskell ma rzutowanie? jak wygląda?

Czytać do skutku.

--
Secunia non olet.
Stanislaw Klekot

do góry

> Tylko że nie wykryją wszystkiego, bo 1) najpierw funkcja się musi
> uruchomić i 2) jak już się uruchomi, to musi zajść sytuacja że funkcja
> dostała niezgodny typ. To w języku dynamicznym może zależec od ścieżki,
> którą pójdzie program. Trochę do dupy twój pomysł z zastępowaniem
> statycznego typowania testami.
Wniosek jest prosty, ani statyczne typowanie, ani testy automatycznie
generowane w runtimie nie zastępują uważności (jest takie słowo?)
programisty. Tyle że jak w C++ statycznie zadeklaruje tablicę i dojdzie
do przepełnienia zakresów, to program może długo działać bez wyraźnych
objawów tego przepełnienia. Oczywiście w C++ można tablice tworzyć
tylko przez new i jeszcze można zaimplementować testy zakresów. Tyle
że w takim przypadku składnia Javy wydaje się przyjemniejsza.

Apropo testów przytoczę jeden z moich przypadków który chyba daje
dużo do myślenia. Kiedyś wprowadziłem kilka poprawek do generatora
posunięć w szachach. Pech chciał że miałem ważną robotę i nad
szachami nie mogłem dalej pracować. Niemniej generator posunięć był
kompletny i stał wolny komputer z sześcioma rdzeniami. Odpaliłem
walidacje krzyżową dwóch programów na tych sześciu rdzeniach.
Zgromadziłem mnóstwo gier, gry zapisałem do plików, programy
wybierały losowo grę i przeszukiwały drzewo gry na określoną głębokość.
Taki test ma nawet swoją nazwę, zwie się testem perft. No i
co to daje do myślenia? Sytuacja w której dwa programy dały
inny wynik dla tych samych danych wejściowych pojawiła się
pierwszy raz dopiero po dwóch tygodniach ciągłych obliczeń na
tych sześciu rdzeniach. Przez dwa tygodnie nie pojawiła się
ani razu.

Pozdrawiam




Programy
ładowały losowe pozycje z losowy wybra




>

> > Fakt, ze argumentacja zwolennikow "dynamicznie typowanych" jezykow jest

> > pokretna :) - mowia oni "jezeli twoje testy nie wykryly takiego bledu,

> > to masz za malo testow".

>

> Zawsze masz za mało testów żeby uzyskać pewność. W języku statycznie

> typowanym dostajesz pewność zgodności typów przez sam fakt skompilowania

> programu.

>

> --

> Secunia non olet.

> Stanislaw Klekot



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On 2011-08-17 15:39, Stachu 'Dozzie' K. wrote:
> On 2011-08-17, Michal Kleczek<k...@p...onet.pl> wrote:
>> On 2011-08-17 15:12, Stachu 'Dozzie' K. wrote:
>>> On 2011-08-17, Michal Kleczek<k...@p...onet.pl> wrote:
>>>>
>>>> W koncu nie wiem, czy chcesz miec kontrole statyczna, czy dynamiczna.
>>>
>>> Chcę statyczną, ale jak się nie da (bo Java jest typowana statycznie ale
>>> dynamicznie), to niech będzie *jakakolwiek*. A nie żeby mnie zaskakiwało
>>> że mimo wszystko do ArrayList<Integer> da się dodać Stringa.
>>>
>>
>> No przeciez sie nie da - tu dostaniesz blad kompilacji:
>>
>> void funkcja(ArrayList<Integer> lista) {
>> lista.add("string");
>> }
>
> No przecież pokazałem że się da.

Nie wydaje mi sie. Nie ma takiego jezyka, ktory przepusci rzutowanie typu:
List<Integer> l = (List<Integer>) cokolwiek;
i nastepnie wyrzuci blad przy:
l.add(new Integer(2));

To byloby zaprzeczenie idei rzutowania.

> Nie próbuj mi wmawiać że parę
> szczególnych przypadków przytoczonych przez ciebie wystarcza żeby mówić
> o statycznej kontroli typów w Javie.

Mysle, ze zebysmy mogli dalej sensownie dyskutowac, musialbys mi
powiedziec, co rozumiesz przez "statyczna kontrole typow".

>
> Przepraszam, ale dlaczego w Adzie się dało zrobić poprawnie silny system
> typów?

Nie dalo sie (sa operacje "unsafe").

> Dlaczego dało się w Haskellu i SML-u?

W Haskelu - unsafePerformIO
SMLa nie znam, ale jak czytalem to tez sa operacje "unsafe".

> Nie wyskakuj mi więc
> z pomysłem że rzutowanie jest ogólnie niebezpieczną operacją,
> niemożliwą do weryfikacji podczas kompilacji, bo nie jest.
>

Nie jestem specjalista, ale wydaje mi sie ze jednak ma do rzeczy tutaj:
http://en.wikipedia.org/wiki/Rice's_theorem
Moge sie jednak mylic.

Natomiast, jesli chcesz powiedziec, ze istnieja jezyki z mocniejszymi
systemami typow niz Java - to ja sie z tym calkowicie zgadzam.

--
Michal

do góry

On 2011-08-17 15:42, Stachu 'Dozzie' K. wrote:
> On 2011-08-17, Michal Kleczek<k...@p...onet.pl> wrote:
>> On 2011-08-17 15:29, Marcin Biegan wrote:
>>> W dniu 2011-08-17 14:59, Michal Kleczek pisze:
>>>> Gwoli uczciwosci w dyskusji: jak ja rozumiem te argumentacje (chociaz
>>>> sie z nia nie zgadzam), to mowi ona tyle, ze i tak musisz miec testy,
>>>> zas - w praktyce - jezeli juz je masz to wykrywaja one bledy, ktorych
>>>> nie wykryje kompilator.
>>>> Wiec to nie jest tak, ze piszemy testy by zastapic statyczna
>>>> weryfikacje, lecz piszemy testy tak czy inaczej i niejako przy okazji
>>>> mozemy zrezygnowac ze statycznej kontroli typow (bo mamy testy).
>>>
>>> I piszesz normalnie w silnie-typowanym języku testy sprawdzające typy
>>> argumentów? Czy jak zamiast int przekażesz double to rzuci wyjątek?
>>
>> Nie w tym rzecz - piszesz testy weryfikujace logike programu. Te testy
>> niejako przy okazji wykrywaja te same bledy, ktore wykrylby kompilator
>> jezyka statycznie typowanego.
>
> Tylko że nie wykryją wszystkiego, bo 1) najpierw funkcja się musi
> uruchomić i 2) jak już się uruchomi, to musi zajść sytuacja że funkcja
> dostała niezgodny typ. To w języku dynamicznym może zależec od ścieżki,
> którą pójdzie program. Trochę do dupy twój pomysł z zastępowaniem
> statycznego typowania testami.

To nie jest moj pomysl.
Jak pisze - ja sie z tym nie zgadzam. Natomiast staralem sie wyjasnic
argumentacje zwolennikow dynamicznego typowania (przedstawiona w linku).

--
Michal

do góry

On 2011-08-17 15:42, Stachu 'Dozzie' K. wrote:
> On 2011-08-17, Michal Kleczek<k...@p...onet.pl> wrote:
>
>> Fakt, ze argumentacja zwolennikow "dynamicznie typowanych" jezykow jest
>> pokretna :) - mowia oni "jezeli twoje testy nie wykryly takiego bledu,
>> to masz za malo testow".
>
> Zawsze masz za mało testów żeby uzyskać pewność. W języku statycznie
> typowanym dostajesz pewność zgodności typów przez sam fakt skompilowania
> programu.
>

Bede adwokatem diabla - a co ci daje "pewnosc zgodnosci typow"?
Masz jakies dane empiryczne mowiace o tym, ze programy zweryfikowane
statycznie na "zgodnosc typow" maja wyzszy poziom akceptacji
uzytkownikow? Chetnie sie z nimi zapoznam.

--
Michal

do góry

On 2011-08-17, Michal Kleczek <k...@p...onet.pl> wrote:
> On 2011-08-17 15:42, Stachu 'Dozzie' K. wrote:
>> On 2011-08-17, Michal Kleczek<k...@p...onet.pl> wrote:
>>
>>> Fakt, ze argumentacja zwolennikow "dynamicznie typowanych" jezykow jest
>>> pokretna :) - mowia oni "jezeli twoje testy nie wykryly takiego bledu,
>>> to masz za malo testow".
>>
>> Zawsze masz za mało testów żeby uzyskać pewność. W języku statycznie
>> typowanym dostajesz pewność zgodności typów przez sam fakt skompilowania
>> programu.
>>
>
> Bede adwokatem diabla - a co ci daje "pewnosc zgodnosci typow"?

Pewność wyeliminowania pewnej klasy błędów, dość często spotykanej
zresztą. To już dużo.

> Masz jakies dane empiryczne mowiace o tym, ze programy zweryfikowane
> statycznie na "zgodnosc typow" maja wyzszy poziom akceptacji
> uzytkownikow? Chetnie sie z nimi zapoznam.

#define "akceptacja użytkowników", bo mnie kojarzy się z użytkownikiem
końcowym, który chce jedynie ładne ikonki do klikania.

--
Secunia non olet.
Stanislaw Klekot

do góry