🚀 go-pugleaf

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.
>
>
> 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ą? :)

> A uruchomienie programu do testów może być (i zwykle jest) bardziej
> kłopotliwe niż kompilacja.

Ale konieczne.

> 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

> >> > Mi. do tego dążą metodyki agile. Przeładowywanie serwera nie jest
> >> > konieczne - automat. Skopiowanie na serwer - automat. Otwarcie
> >> > przeglądarki - automat po kliknięciu na link.
>
> >> A potem przeklikuj się ręcznie przez wszystkie formularze żeby sprawdzić
> >> ich poprawność. Albo napisz automat, który będzie automatyzować klikanie
> >> pól (uwaga na AJAX!). Ot, taki dodatkowy kłopot.
>
> > Kłopot?, ja uważam, że bez tego to bugów będzie jak "mrówków" :)
> > Niezależnie od języka programowania, testy trzeba pisać i wykonywać.
> > Automatyczne zwłaszcza w większych aplikacjach lub o wyższych
> > wymaganiach co do niezawodności/wydajności są wręcz niezbędne - czyli
> > tam gdzie jest większy budżet.
>
> 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ą"?
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).

> > 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
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ń :)

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

> Powiedziałbym że to raczej odwrotnie jest: zaufanie testowaniu daje ci
> w błędne przekonanie, że program zawsze dobrze działa i inna weryfikacja
> jest niepotrzebna.

Nigdy nie osiągniemy "zawsze" :P Możemy jedynie dążyć do tego :)

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

> > 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? :(

> >> Proponuję popisać w paru innych językach (np. w Javie), wtedy zobaczysz
> >> jaki jest wpływ samej składni na długość kodu. Bo większość operacji
> >> w przeciętnym kodzie źródłowym tłumaczy się wprost na inne języki,
> >> a idiomów używa się sporadycznie.
>
> > Pisałem w asseblerze x86, Pascalu, Javie, Clipperze, Visual Basicu,
> > trochę w :C, Perlu i jeszcze paru językach :) Jakoś tak wydaje mi się,
> > że mam pojęcie przekrojowe :)
>
> Bo wiesz, jakoś nie widzę tego po tobie.
A to mnie nie dziwi, bo mnie w ogóle nie widzisz :P. Ale jeśli się
podzieliłeś opinią o mnie, to pozwól, że i ja się podzielę swoją.
Myślę, że nie używałeś zbytnio Pythona, a swoją wiedzę czerpiesz z
teorii.

> Rozumiem że chodzi o to:
> #v+
> Bo większość operacji w przeciętnym kodzie źródłowym tłumaczy się wprost
> na inne języki, a idiomów używa się sporadycznie.
> #v-

Tak, tu się zgadzamy - to znaczy to jest ostatnie zdanie :)

> Idiom w programowaniu to wyrażenie (lub krótka konstrukcja w języku
> programowania) mające znaczenie tylko w danym języku, na ogół trudne do
> przełożenia na inny język za pomocą jednej instrukcji. Na przykład
> idiomem w Pythonie jest konstruowanie tablicy za pomocą
> "[?? for x in ??]", co się w Perlu przekłada jako "map { ?? } ??".

A teraz mój wredny wtręt: nie tablicy, a listy. Różnica niewielka,
ale ... :)

> W przypadku programowania, większość kodu to instrukcje warunkowe,
> pętle, wywołania funkcji, ewentualnie definicje klas lub innych typów.
> Idiomy pojawiają się dość rzadko i zwykle dają się przełożyć na krótkie
> konstrukcje w innym języku, o ile język docelowy reprezentuje podobny
> paradygmat programowania (np. [?? for x in ??] wymaga dużo kodu
> w C (inny paradygmat), ale w Perlu to już wywołanie jednej funkcji
> wbudowanej).

Wybacz, nie zgadzam się z Tobą. Przy tej definicji idiomy i tym
podejściu to każda instrukcja, każdego języka jest idiomem !!!!
Oczywiście wszystko odnosząc do assemblera :)
Moim zdaniem języki programowania powstały po to by się pisało łatwo,
krótko i ... przyjemnie :) Nie po to by programy działały szybciej.

> Biorąc pod uwagę że program składa się tylko w małej części z idiomów,
> a w dużej części z pozostałych, typowych dla danego paradygmatu
> instrukcji, oraz że idiomy się tłumaczy raczej na krótkie sekwencje,
> program w Perlu i taki sam w Pythonie będą miały podobną długość.

W Python "idiomów" wg Twojej definicji używa się cały czas. Po co
pisać ciągle te same kawałki kodu?
Ale chyba odeszliśmy od głównego wątku "typowania" :)

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

Pzdr.
Jacek