🚀 go-pugleaf

On 2011-05-21, jacek2v <jacek2v@gmail.com> wrote:
> On 20 Maj, 10:24, "Stachu 'Dozzie' K."
><doz...@go.eat.some.screws.spammer.invalid> wrote:
>> Oczywiście że nie mówią. Mówią o statyczności typowania, bo o tym
>> dyskutujemy w tej gałęzi. Nadal nie rozumiem co ma do rzeczy "silność"
>> systemu typów.
>
> Wydawało mi się, że cały czas o tym mówisz - o wyższości języka z
> typowaniem, czyli o jego "sile" .

Eeee... Że co? Co ma siła typowania do statyczności typowania?

>> >> > A co to za różnica, że uruchomię zamiast skompiluję? Jeden "ruch"
>> >> > mniej :)
>> >> 1. Uruchomienie może być bardziej kłopotliwe niż sam proces budowania
>> >>    (dla webaplikacji to może być skopiowanie na serwer testowy,
>> >>    przeładowanie serwera, otwarcie przeglądarki i dokopanie się do
>> >>    ekranu którego kod chcesz sprawdzić).
>> > Nigdy i tak musisz uruchomić,
         ^^^
>> Parse error.
>
> Mhh, a ja zawsze myślałem, że programy się pisze by je uruchamiać.

Parse error, znaczy błąd składni. Teraz widzę nawet jaki. Proponuję
używać więcej znaków interpunkcyjnych.

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

>> Nikt ci nie zabrania uruchamiać aplikacji do woli. Etap weryfikacji
>> typów podczas kompilacji to po prostu dodatkowe sprawdzenie, które
>> dochodzi ci praktycznie za darmo.
>
> Nie za darmo. Trzeba wszędzie pisać explicite typ, a to sporo kodu
                                                          ^^^^^^^^^^
> więcej.

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.

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

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

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

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.

>> >> Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
>> >> darujmy sobie testowanie aplikacji? Kolejny ruch mniej.
>> > Dziwna ekstrapolacja - poza zbiór dopuszczalnych wyników :)
>>
>> Właśnie. Do tego prowadzi twój pomysł z opuszczaniem kolejnych kroków
>> budowania softu: do opuszczenia zbioru dopuszczalnych wyników.
>
> To był Twój pomysł, aby nie testować - nie dokręcaj kota ogonem :)

Ty zacząłeś. Ja tylko pociągnąłem twoją ścieżkę dalej, żeby pokazać do
czego prowadzi i że to nic dobrego.

>> >> Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.
>> > Wydaje mi się, że przy zmiana framework raczej przeszkadza. Kiedyś
>> > spotkałem się z podobnym przypadkiem w Pascalu. Typowanie wymagało
>> > dużo "bezrozumnego" poprawiania kodu.
>>
>> Ale przynajmniej wiedziałeś gdzie się zmieniło API. Przy typowaniu
>> dynamicznym nie masz tej informacji podczas kompilacji.
>
> 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.

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

> Ostatniego Twojego zadanie nie zrozumiałem, sorry :)

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-

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 { ?? } ??".

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

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

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.

-- 
Secunia non olet.
Stanislaw Klekot