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

> 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.

Czyli nie chciałeś sugerować, że Haskell jest przykładem bezpiecznego
rzutowania (a IMO jest uzasadniona interpretacja zacytowanego fragmentu),
a jedynie porządnego systemu typów?
To się zgadzam, na pożegnanie prosząc (z ciekawości jedynie, nie dlatego,
iżbym nie wierzył, że może istnieć) o opis, jak działa porządne/bezpieczne
rzutowanie.

--
Jordan Szubert

do góry

On Aug 17, 3:30 pm, Michal Kleczek <k...@p...onet.pl> wrote:

> 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).

A tak żeby było ciekawiej, zapytam: po co rzutowanie [*]?
Udało mi się napisać parę programów bez rzutowania. W szczególności
"Hello World" nie używa rzutowania, ale dłuższe programy też się da.
Najwyraźniej mógłbym te programy napisać również w języku, który
rzutowania w ogóle nie ma.

Niebezpieczne rzutowanie może być potrzebne w języku, żeby na
współczesnych systemach operacyjnych zaimplementować dany język w tym
samym języku (np. bibliotekę i cały run-time C++ da się napisać w C+
+), albo ale to wymaganie nie musi być uzasadnione z punktu widzenia
"normalnego" programisty.

[*] Hint: jawne konwersje typów tu się nie zaliczają, bo są
bezpieczne. Mówimy o rzutowaniu typu reinterpret_cast, void* i tego
typu chwytach.

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

do góry

On 2011-08-17 17:11, Maciej Sobczak wrote:
> On Aug 17, 3:30 pm, Michal Kleczek<k...@p...onet.pl> wrote:
>
>> 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).
>
> A tak żeby było ciekawiej, zapytam: po co rzutowanie [*]?
> Udało mi się napisać parę programów bez rzutowania. W szczególności
> "Hello World" nie używa rzutowania, ale dłuższe programy też się da.
> Najwyraźniej mógłbym te programy napisać również w języku, który
> rzutowania w ogóle nie ma.
>
> Niebezpieczne rzutowanie może być potrzebne w języku, żeby na
> współczesnych systemach operacyjnych zaimplementować dany język w tym
> samym języku (np. bibliotekę i cały run-time C++ da się napisać w C+
> +), albo ale to wymaganie nie musi być uzasadnione z punktu widzenia
> "normalnego" programisty.
>

Jezeli twoj jezyk nie pozwala zaimplementowac siebie samego, to problem
lezy w zdefiniowaniu do czego sie nadaje (czyli do czego mozna go uzyc)
- no chyba ze potrafisz udowodnic, ze to jedyny problem, ktorego nie da
sie rozwiazac w tym jezyku.
I tak potrzebujesz jezyka tzw. "ogolnego przeznaczenia" do rozwiazania
problemow, ktorych nie mozesz rozwiazac przy uzyciu specjalizowanych
jezykow.

--
Michal

do góry

On 2011-08-17 16:50, Stachu 'Dozzie' K. wrote:
> 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.

No wlasnie konrargument zwolennikow dynamicznego typowania jest taki, ze:
a) wlasnie - wbrew obiegowym opiniom - wcale nie "czesto spotykanej"
b) i tak najpowazniejsze oraz najtrudniejsze w diagnozie i naprawie
bledy (nie musza byc czeste) wynikaja z przyczyn, ktorych nie
wyeliminuje statyczny typechecker.

Analogiczna dyskusja toczy sie wsrod zwolennikow statycznego typowania.
Dotyczy ona tego, czy ma byc "nominal typing" czy wystarczy "structural
typing".
I sam fakt, ze zastosowanie "nominal typing" powoduje wylapanie bledow w
wiekszej ilosci programow nie jest wystarczajacym argumentem za jego
stosowaniem.

>
>> 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.
>

Chociazby.
Jak to sie ma do statyczniej kontroli typow?
Czy programy napisane dajmy na to w Adzie maja ladniejsze ikonki i
lepiej je wyswietlaja niz te napisane w Smalltalku?

Czy dysponujesz jakimikolwiek danymi empirycznymi, ktore mowilyby o
korelacji pomiedzy uzytym jezykiem programowania (w szczegolnosci czy
jest on statycznie typowany), a akceptacja klienta (definiowana
jakkolwiek rozsadnie)?

--
Michal

do góry

On 08/17/2011 04:29 PM, m...@t...pl wrote:
>
>> 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.

Trafiłeś jak nie wiem co: napisz w Javie v1 * v2 gdzie v1 i v2 to
wektory, piewrszy przykład z setki możliwych; vector[index] += 3 drugi
(zamiast myJavaVektor.set(index, myJavaVector.get(index) + 3)).

Co ma new do sprawdzania zakresów. Można stworzyć klasę Tablica,
która ma stały rozmiar i sprawdzi zakresy, compile time albo runtime
wg potrzeb i nie używa new.

>
> 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.
>

Faktycznie, daje do myślenia. Ja np. myślę, że valgrind nie wymagałby
dwóch tygodni, a byłby wart więcej niż te testy (które można
też zrobić, ale jak rozumiem wynik wskazuje na zwykły UB). Ten test
chyba nie ma nazwy, i valgrind niestety używa tylko jednego rdzenia.

Edek

do góry

> On 08/17/2011 04:29 PM, m...@t...pl wrote:


> Co ma new do sprawdzania zakresów. Można stworzyć klasę Tablica,
> która ma stały rozmiar i sprawdzi zakresy, compile time albo runtime
> wg potrzeb i nie używa new.
Mechanizm sprawdzania to jeden int i porównanie. W wyniku błędnego działania
tego inta też można uszkodzić. Tyle ma wspólnego new, że jak uszkodzisz
coś na stercie to się szybciej wywali niż na stosie - oczywiście nie
zawsze, ale częściej.

> Faktycznie, daje do myślenia. Ja np. myślę, że valgrind nie wymagałby
> dwóch tygodni, a byłby wart więcej niż te testy (które można
> też zrobić, ale jak rozumiem wynik wskazuje na zwykły UB). Ten test
> chyba nie ma nazwy, i valgrind niestety używa tylko jednego rdzenia.

To w valgrinda jest zakodowany generator posunięć szachowych i sprawdza
czy nie ma błędu? ;-)

Pozdrawiam


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

do góry

On 08/17/2011 10:58 PM, m...@t...pl wrote:
>> On 08/17/2011 04:29 PM, m...@t...pl wrote:
>
>
>> Co ma new do sprawdzania zakresów. Można stworzyć klasę Tablica,
>> która ma stały rozmiar i sprawdzi zakresy, compile time albo runtime
>> wg potrzeb i nie używa new.
> Mechanizm sprawdzania to jeden int i porównanie. W wyniku błędnego działania
> tego inta też można uszkodzić. Tyle ma wspólnego new, że jak uszkodzisz
> coś na stercie to się szybciej wywali niż na stosie - oczywiście nie
> zawsze, ale częściej.

Przykład dotyczy tablicy o stałym rozmiarze. W przypadku compile time,
co ci umknęło, nie da się "uszkodzić" ani indeksu ani rozmiaru.
W przypadku runtime można zepsuć index co najwyżej, czyli i tak po
sprawdzeniu dostęp jest w zakresie.

Ogólnie mam wrażenie, że niektórzy żyją w generalnym chaosie, lepiej
wtedy w ogóle nie używać new bo i tak się zapomni zwolnić, pointery
mogą wskazywać gdziekolwiek "uszkadzając inty" - też lepiej nie używać.
Code and pray.

>
>> Faktycznie, daje do myślenia. Ja np. myślę, że valgrind nie wymagałby
>> dwóch tygodni, a byłby wart więcej niż te testy (które można
>> też zrobić, ale jak rozumiem wynik wskazuje na zwykły UB). Ten test
>> chyba nie ma nazwy, i valgrind niestety używa tylko jednego rdzenia.
>
> To w valgrinda jest zakodowany generator posunięć szachowych i sprawdza
> czy nie ma błędu? ;-)
>

:) sprawdza, czy "genialny szachista" nie spadnie pod stół już podczas
otwarcia.

do góry

> Ogólnie mam wrażenie, że niektórzy żyją w generalnym chaosie, lepiej
> wtedy w ogóle nie używać new bo i tak się zapomni zwolnić, pointery
> mogą wskazywać gdziekolwiek "uszkadzając inty" - też lepiej nie używać.
> Code and pray.
Ludzie się mylą. Lepiej przewidzieć pomyłki i zastanowić się jak łagodzić
ich skutki, niż wierzyć że się nie popełni błędu.

Języków C/C++ z reguły używam do bardzo małych programów, np. w granicach
500-1000 linii kodu. Są one na tyle małe i niezbyt skomplikowane że wiele
się nie zastanawiam nad estetyką, metodyką, itd, a one dobrze działają.
Dużych albo trudnych projektów w C/C++ mam raptem cztery. Jeden z nich był
napisany zgodnie ze sztuką. Podczas pisania programu zabroniłem na głos
używać określenia "będzie za wolno działało". Program przez wiele lat
działa i nie stwarza problemów. Pozostałe 3 programy zostały dlatego
napisane w C/C++ żeby dokonać optymalizacji. No i od dziś nikt nie ma
pewności czy nie został jakiś błąd.

Jeśli ktoś twierdzi że w C/C++ można pisać bez błędów to ja się pod tym
podpisuję. Ale czy np. w Javie nie jest trochę łatwiej?

> >> Faktycznie, daje do myślenia. Ja np. myślę, że valgrind nie wymagałby
> >> dwóch tygodni, a byłby wart więcej niż te testy (które można
> >> też zrobić, ale jak rozumiem wynik wskazuje na zwykły UB). Ten test
> >> chyba nie ma nazwy, i valgrind niestety używa tylko jednego rdzenia.
Valgrind to dobra rzecz, ale gdy ostatnio chciałem nim sprawdzić program,
to były błędy... w kompilatorze. Muszę jeszcze raz spróbować. Są jakieś
alternatywne narzędzia dla valgrinda?
Pozdrawiam

> :) sprawdza, czy "genialny szachista" nie spadnie pod stół już podczas
> otwarcia.
To akurat był błąd typu: brak ifa :) Pomoże jedynie walidacja krzyżowa z
innym programem który tego ifa ma :)
Pozdrawiam



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

do góry

On 08/17/2011 05:11 PM, Maciej Sobczak wrote:
> On Aug 17, 3:30 pm, Michal Kleczek<k...@p...onet.pl> wrote:
>
>> 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).
>
> A tak żeby było ciekawiej, zapytam: po co rzutowanie [*]?
> Udało mi się napisać parę programów bez rzutowania. W szczególności
> "Hello World" nie używa rzutowania, ale dłuższe programy też się da.
> Najwyraźniej mógłbym te programy napisać również w języku, który
> rzutowania w ogóle nie ma.

Przez ostatnie dwa lata reinterpret_cast użyłem chyba raz (nie mogę
sobie przypomnieć po co zamieniałem * na int, chyba po to, żeby
sprawdzić alignment w celu weryfikacji zachowania kompilatora
w testach. Niektóre nie alignowały odpowiednio zmiennych na stosie.).

Void* używam często i gęsto, gdy nie ma nullptr; poza tym, nie
przypomninam sobie. Może memcpy.

Ale, żeby być uczciwym, użycie static_cast jest czasami przydatne,
konkretnie w abstrakcyjnych klasach instancjonowanych z podklasą jako
własnym parametrem, itp przyklady. Na C style to mam warninga.

Edek

do góry

On 08/17/2011 11:56 PM, m...@t...pl wrote:
>
>> Ogólnie mam wrażenie, że niektórzy żyją w generalnym chaosie, lepiej
>> wtedy w ogóle nie używać new bo i tak się zapomni zwolnić, pointery
>> mogą wskazywać gdziekolwiek "uszkadzając inty" - też lepiej nie używać.
>> Code and pray.
> Ludzie się mylą. Lepiej przewidzieć pomyłki i zastanowić się jak łagodzić
> ich skutki, niż wierzyć że się nie popełni błędu.
>
> Języków C/C++ z reguły używam do bardzo małych programów, np. w granicach
> 500-1000 linii kodu. Są one na tyle małe i niezbyt skomplikowane że wiele
> się nie zastanawiam nad estetyką, metodyką, itd, a one dobrze działają.
> Dużych albo trudnych projektów w C/C++ mam raptem cztery. Jeden z nich był
> napisany zgodnie ze sztuką. Podczas pisania programu zabroniłem na głos
> używać określenia "będzie za wolno działało".

Brutalne rozwiązanie, szkoda że czasem tak trzeba.

Program przez wiele lat
> działa i nie stwarza problemów. Pozostałe 3 programy zostały dlatego
> napisane w C/C++ żeby dokonać optymalizacji. No i od dziś nikt nie ma
> pewności czy nie został jakiś błąd.

To ja ci powiem, że został popełniony jeden generalny. Kiedyś faktycznie
optymalizacja to assembler albo bardzo blisko. Dzisiaj, fakt, jakieś
multimedia i podobne niektórzy jeszcze rzeźbią w assemblerze, czy
też wstawki typu atomiki, których dotychczas nie było, i ok. Natomiast
większość optymalizacji - o ile wiem - to umiejętne użycie kompilatora.
Czasami wydaje mi się, że niektórzy nie uświadomili sobie, że
zarówno procki i kompilatory "deczko" się zmieniły przez ostatnie
dziesięć lat. Oczywiście, niektóre rzeczy były i są kosztowne,
trzeba kod pisać inaczej, żeby kompilator mógł go optymalizować,
bo robi tylko te przekształcenia, które może zrobić mając dostępne
założenia - zazwyczaj wystarczy mu przeszkody usunąć z drogi. Nie jest
to darmo, ale nie ma to większego wpływu na pisanie poprawnego
kodu. Range check w przypadku większych pętli zazwyczaj sprowadza się
do jednorazowego >=start <end - co i tak kompilator musi zrobić,
żeby np. wygenerować prologi przekształconych pętli, więc taki check
w kodzie źródłowym paradoksalnie ułatwia mu pracę (ok, jak to zwykle
z optymalizacjami bywa: czasami, nie zawsze, zależy, itd.).

>
> Jeśli ktoś twierdzi że w C/C++ można pisać bez błędów to ja się pod tym
> podpisuję. Ale czy np. w Javie nie jest trochę łatwiej?
>

Java ma inne zalety: jest ogólnie prostsza i ma reflection. Moim zdaniem
jest za mało ekspresywna, muszę się stanowczo dużo więcej naklepać,
żeby uzyskać ten sam efekt. Przy małym i prostym kodzie tego może nie
być widać; przy frameworkach FWIW też nie.

Co do optymalizacji i Javy, to różnie mówią. Znam testy gdzie Java i C++
były podobne. Znam takie, gdzie Java była wolniejsza. Znam też takie,
że w HPC używają Javy, ale tylko ze słyszenia - kiedyś googlnę, nie
spędza mi to snu z powiek łagodnie mówiąc.

>>>> Faktycznie, daje do myślenia. Ja np. myślę, że valgrind nie wymagałby
>>>> dwóch tygodni, a byłby wart więcej niż te testy (które można
>>>> też zrobić, ale jak rozumiem wynik wskazuje na zwykły UB). Ten test
>>>> chyba nie ma nazwy, i valgrind niestety używa tylko jednego rdzenia.
> Valgrind to dobra rzecz, ale gdy ostatnio chciałem nim sprawdzić program,
> to były błędy... w kompilatorze. Muszę jeszcze raz spróbować. Są jakieś
> alternatywne narzędzia dla valgrinda?
> Pozdrawiam
>

Są. Ale sam valgrind ma "suppresions" czy jakoś tak to się nazywa, co
obchodzi znane problemy z libami, ma też opcję "wygeneruj suppresion",
jak już nie ma innego wyjścia pod każdym upierdliwcem wypluje, jak go
wyłączyć.

Nie znam opcji pod Win, mam malutkie doświadczenie.


>> :) sprawdza, czy "genialny szachista" nie spadnie pod stół już podczas
>> otwarcia.
> To akurat był błąd typu: brak ifa :) Pomoże jedynie walidacja krzyżowa z
> innym programem który tego ifa ma :)
> Pozdrawiam

Testy tego możliwie małego kawałka kodu też. Nie pisałem algorytmów
szachowych, nie wiem, czy dają się tak podzielić. No i fakt, valgrind
braku ifa nie wyniucha - szkoda ;) Przydałby się tool, który bierze dwa
algorytmy, powiedzmy, że różniące się nie zasadą działania, tylko
użytymi strukturami danych, i mówi, czy są równoważne.

Edek

do góry