🚀 go-pugleaf

On 2011-05-22, jacek2v <jacek2v@gmail.com> wrote:
> On 21 Maj, 20:41, "Stachu 'Dozzie' K."
><doz...@go.eat.some.screws.spammer.invalid> wrote:
>
>> Eeee... Że co? Co ma siła typowania do statyczności typowania?
>
> "Siła" to inaczej mówiąc, że lepiej jak jest typowanie niż jak go
> niema.

Eeee... Nie? C ma słabsze typowanie niż C++, od którego silniejsze
typowanie ma Haskell.

>> Parse error, znaczy błąd składni. Teraz widzę nawet jaki. Proponuję
>> używać więcej znaków interpunkcyjnych.
>
> Aha :) Zapomniałeś włączyć w kompilatorze logikę rozmytą? :)

Nie. Ty zapomniałeś użyć prawidłowo interpunkcji.

>> Eeee... Nie? A dostajesz w zamian kontrolę typów. Proponuję przyjrzeć
>> się dowolnemu programowi dowolnego języka ze statycznym typowaniem
>> i policzyć, ile kodu, tak na literki, jest przeznaczone na deklaracje
>> typów.
>
> Liczyłem. Jak Twoje wyniki? Wg moich sporo więcej :P

To twój program składał się chyba wyłącznie z deklaracji. U mnie nie
wychodzi nawet 10% kodu.

>> Tam, gdzie wymagania niezawodnościowe są dużo wyższe, to akurat się unika
>> testowania, zastępując je formalną automatyczną weryfikacją. Testy nie
>> są tak niezawodne jak próbujesz przedstawiać, nie dają gwarancji
>> poprawności programu. Zautomatyzowana weryfikacja (przy której
>> weryfikacja typów to tylko preludium do wstępu) za to daje.
>
> A co to "formalną automatyczną weryfikacją"?

Proponuję poszukać w takim razie materiałów.

> Nie uważam, że testy dają 100% niezawodności, ale dają (znacznie
> wyższy poziom niezawodności) vs. (włożony nakład pracy na ich
> przygotowanie) niż (typowanie) vs. (włożony nakład pracy na pisanie
> kodu).

To może tak wyglądać w małych projektach, gdzie jesteś w stanie
naprodukować i utrzymywać testy dla mniej więcej większości kodu.
W większych projektach przy refaktoryzacji okazuje się że system typów
przynajmniej pokazuje, gdzie jeszcze trzeba poprawić kod, co jest IMO
bardzo dużym zyskiem (tym większym, im większy projekt), a uzupełnienie
kodu o deklaracje typów nie zwiększa jakoś specjalnie jego długości.

>> > Sugerujesz, że oddajesz aplikację nawet jej nie przeklikawszy?
>>
>> Nie. Ale może się zdarzyć że testy, które przygotowałeś, nie pokryją
>> wszystkich możliwych sytuacji. Kompilator jest za to dokładniejszy.
>
> I na pewno się tak zdarzy, gwarantuję :) Użytkownicy są
> nieobliczalni :D

Nie chodzi o to jak obliczalni są użytkownicy, tylko czy ty jesteś
w stanie pokryć testami wszystkie możliwe ścieżki wykonania. Nie jesteś.

> A kompilator jest i Python :) Zapewne miałeś na myśli, że kompilator
> sprawdzi typy, ale jak już mówiłem, moim zdaniem złudne to poczucie
> sprawdzenia. A ja wolę nie mieć złudzeń :)

To po co testujesz? To ci daje złudne poczucie że twój program działa.
A to co kompilator w statycznie typowanym języku sprawdzi, to jest
prawdziwe sprawdzenie. Niewystarczające do uznania kodu za prawidłowy (o
czym wie każdy piszący w językach statycznie typowanych), ale prawdziwe.

>> >> A i tak mogą się prześlizgnąć błędy w rzadko używanych formularzach,
>> >> o których nikt nie pamięta i co do których nikt nie pomyślał żeby
>> >> napisać testy. A automat (kompilator) by po prostu sprawdził poprawność
>> >> *wszędzie*.
>>
>> > Ale i tak kompilator nie wyłapie znacznej większości błędów, a
>> > świadomość, że trzeba testować jest lepsza niż życie w błędnym
>> > przekonaniu, że coś samo się sprawdzi i będzie ok.
>>
>> Ależ świadomość nadal jest. Weryfikacja typu nie wychwyci błędu
>> logicznego. Za to wychwyci dużo typowych błędów, co już samo w sobie
>> pomaga.
>
> Weryfikacja typu wychwyci jedynie błąd typu i nic więcej.
> Moja praktyka jest taka, że zawsze błąd typu jest wykrywany po
> pierwszym uruchomieniu poprawianego kodu.

To chyba w jakichś malutkich projektach. Gdy program robi się duży,
z jednej funkcji którą zmieniasz może korzystać fafnaście innych
modułów. Potem weź szukaj tych modułów i przekopuj się przez kod, żeby
ujednolicić typ danych, na którym ten kod operuje.

> I tak każdy moduł/funkcja/
> metoda przez programistę jest dziesiątki (jeśli nie setki razy)
> uruchomiany/debugowany. Trzeba sobie uświadomić, że kod jest pisany po
> to by był uruchomiony. Nie wyobrażam sobie by programista zrobi commit
> kodu nie uruchomiwszy go, zakładając, że pisze nieomylnie.

Nie wyobrażam sobie żeby programista był w stanie sprawdzić dokładnie
cały duży projekt, wszystkie wywoływane w nim funkcje.

> Żeby uprzedzić argumenty o zmiennych warunkach wykonania i że ścieżka
> wykonania jest niedeterministyczna, chciałby zwrócić Twoją uwagę, że
> Python nie jest językiem "nie typowanym" jest językiem "dynamicznie
> typowanym", czyli typowanie ma, tylko nie jest ono podawane explicite.

Bzdurzysz, chłopcze. To powinno brzmieć: "Python [...] jest językiem
"dynamicznie typowanym", czyli typowanie ma, tylko jest ono sprawdzane
dopiero przy uruchomieniu". Nie podawane exlicite typy to są w SML-u,
a mimo to język jest statycznie i silnie typowany.

>> Ty zacząłeś. Ja tylko pociągnąłem twoją ścieżkę dalej, żeby pokazać do
>> czego prowadzi i że to nic dobrego.
>
> Będę się upierał, że Ty zacząłeś :), na potwierdzenie przytaczam cytat
> z Twojej wypowiedzi: "Ekstrapolując twoje proponowane podejście "jeden
> ruch mniej", może darujmy sobie testowanie aplikacji?"
> Twoja "ekstrapolacja"  była nadinterpretacją mojej wypowiedzi.

Nie. Była rozszerzeniem twojego rozumowania: "usuńmy kolejny element
który kosztuje".

>> > A jak zmienisz klasę na niższą lub wyższą w ścieżce dziedziczenia, to
>> > też się zorientuje - zwłaszcza, że bardzo często używa się
>> > rzutowania?
>>
>> Zależy czy ta wyższa czy niższa jest niezbędna, czy też nie. W ogóle nie
>> rozumiem pytania i problemu, który byś chciał pokazać. Please elaborate.
>
> class c1{
>    public int m1(int a) {
>        a = a + 1;
>        return(a);
>    }
> }
> class c2 extends c1{
>    public int m1(int a) {
>        a = a + 2;
>        return(a);
>    }
> }
> public class jsimple{
>     public static void main (String[] args) {
> 	c1 o1 = new c2();
> 	System.out.println (o1.m1(3));
>     }
> }
> result: 5
>
> I co z tego, że typ c1? :(

Chłopcze, a może tak byś doczytał o polimorfizmie dynamicznym zamiast
pokazywać nieistniejące problemy? W Javie wiadomo od zawsze, że
adresy wszystkich metod są rozwiązywane at runtime. Inaczej w C++, gdzie
musisz powiedzieć jawnie, które metody są rozwiązywane podczas
kompilacji.

Nawiasem mówiąc, jak ktoś piszący w Pythonie może nie umieć utrzymać
jednolitego systemu wcinania kodu i miesza spacje z tabulatorami? O_o

>> Tak więc zwięzłość składni, która wyraża się właśnie obecnością idiomów,
>> nie przekłada się specjalnie na długość kodu.
>> Powiem ci że parę lat temu też uważałem że ilość idiomów pozytywnie
>> wpływa na ilość kodu i jego konserwowalność, ale z doświadczeniem się
>> z tego przekonania wyrasta.
>
> Zajrzyj na shootout.alioth.debian.org, przekonasz się jak to się
> przekłada na ilość kodu w rzeczywistości. Strona ta zawiera porównanie
> programów (szybkość, zużycie pamięci, ilość linii kodu) rozwiązujących
> ten same problemy w różnych językach programowania. W tej chwili coś
> nie działa ta strona - może jakieś prace trwają i nie mogę przytoczyć
> konkretnego przykładu :). Ale jeśli dobrze pamiętam to wielkość kodu
> java vs python oscyluje między 5:1 do 10:1. Oczywiście nie tylko
> "idiomy" zmniejszają ilość kodu w python. Jest jeszcze brak nawiasów,
> typowania explicite, krótka notacja - chyba wszystko wymieniłem.

Tylko to wszystko są fistaszki. Rzeczy istotne dla skrócenia kodu, to:
  * dobrze przemyślane API bibliotek (w tym: biblioteki standardowej)
  * konstrukcje nieprzekładalne na języki innego paradygmatu (słyszał
    o domknięciach?)
  * zwyczaje programistyczne różnych środowisk (javistów, pythonistów
    itd.)

-- 
Secunia non olet.
Stanislaw Klekot