🚀 go-pugleaf

On 2011-05-19, jacek2v <jacek2v@gmail.com> wrote:
>> >> Chodzi o coś zupełnie innego. Typowy błąd początkujących programistów:
>> >> branie implikacji za równoważność.
>> >> "Jeśli program jest dobry, to typy się zgadzają."
>> >> Odwracając implikację:
>> >> "Jeśli typy się nie zgadzają, to program nie jest dobry."
>> > Bardziej poprawnie powinno być: jeśli typy się zgadzają to jest  duża
>> > szansa, że kompilator skompiluje :)
>> Bardziej poprawnie od którego? Bo jakoś nie widać do czego pijesz.
> Właściwie do obu - a jak chcesz wybrać jednego to do drugiego :)
> "Poprawne" ponieważ oba stwierdzenia nic nie mówią o sile "typowania".

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.

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

> taki jest cel programowania, czym
> szybciej masz możliwość weryfikacji poprzez uruchomienie tym lepiej.

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.

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

>> 2. Kompilacja, jako operacja wykonywana na kodzie źródłowym przez
>>    automat, jest dokładniejsza od kontrolnego uruchomienia aplikacji.
>>    Sprawdzisz za jednym zamachem wszystkie możliwe ścieżki wykonania
>>    w blokach kontrolnych?
> I tak to trzeba robić - może nie wszystkie ścieżki, ale testy/skrypty
> testowe trzeba zrobić i puszczać po każdej integracji - unit testy i
> testy symulacji użytkownika. A potem i tak najlepiej "napuścić"
> testera :)

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

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

>> 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 tak poza tym wątkiem to często się zapomina, że Python to nie tylko
>> > skryptowy język, ale język obdarzony niesamowicie zwięzłą, a
>> > jednocześnie czytelną składnią.
>> A co to ma do rzeczy? Mówimy o statycznym systemie typów, a nie o tym
>> czy składnia jest zwięzła. Zresztą zwięzłość składni nie ma specjalnego
>> wpływu na długość kodu w większych projektach.
> Napisałem "A tak poza wątkiem" - wybiórcze czytanie? :)
> Nie będę polemizował czy zwięzłość kodu ma coś do rzeczy z jego
> ilością :) - bo dla mnie to oczywista oczywistość :)

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.

-- 
Secunia non olet.
Stanislaw Klekot