🚀 go-pugleaf

On 2011-05-17, 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.

>> Owszem, great. Kompilator odwalił za ciebie brudną robotę ze wstępnym
>> sprawdzeniem poprawności i wybronił cię przed koniecznością uruchamiania
>> programu tylko po to, żebyś znalazł hasz tam gdzie miała być krotka.

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

Ekstrapolując twoje proponowane podejście "jeden ruch mniej", może
darujmy sobie testowanie aplikacji? Kolejny ruch mniej.

> Jak użyjesz stringów zamiast napisania/użycia klas to żadne typowanie
> nie obroni :)

Eeeee... że co?

>> 30kloc, przy zmieniającym się frameworku o który projekt był oparty.
>> Wyszukiwanie miejsc gdzie trzeba poprawiać kod żeby był zgodny
>> z frameworkiem było bardzo uciążliwe, bo trzeba było po prawie każdej
>> poprawce uruchamiać aplikację ponownie.

> No tu problem leży gdzieś indziej - parafrazując klasyka: Puchatka :).
> Framework jak trochę nazwa sugeruje powinien być w miarę niezmienny bo
> wtedy i Święty Typ Najwyższy nie pomoże :)

Ano nie pomoże. Ale statyczna kontrola typów by sporo ułatwiła.

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

> Polecam porównanie http://shootout.alioth.debian.org/.
> Krótszy i przez to łatwiejszy do ogarnięcia kod oznacza mniej
> czytania, mniej miejsc do popełnienia błędów itd.
> Szczerze mówiąc lubiłem Javę, ale nie podobało mi się w niej łatwe
> przekraczanie 80 znaków w linii :)

To nie wina języka, że programiści się nie mieszczą w 80 kolumnach,
tylko powszechnie przyjętych konwencji, prawie wymuszanych przez
bibliotekę standardową (bo weź używaj kontenerów bez tych konwencji).
A najbardziej programistów, bo w ogóle nie myślą o tym jak kod zmieścić
na 80 znakach (bo przecież od dawna mamy monitory panoramiczne).

-- 
Secunia non olet.
Stanislaw Klekot