On 10/02/2013 11:12, Maciej Sobczak wrote:
>
> Moim zdaniem właśnie statyczny system typów najbardziej pokazuje
> swoje zalety właśnie wtedy, gdy należy przerobić istniejący kod -
> wszystko jedno, czy w celu refaktoryzacji czy w celu rozszerzenia
> albo zmiany funkcjonalności.

Być może jest to prawda, ale to nie znaczy, że dynamiczny system typów
nie pokazuje innych zalet, które są w takich sytuacjach przydatne.

> Statyczny system typów pozwala wyrazić
> związki między różnymi bytami w programie, dzięki czemu szybciej
> widać jaki jest zakres wprowadzanych zmian.

Pozwala, ale są inne sposoby, które też pozwalają.

> Dynamiczny system typów
> (i bardziej ogólnie: dynamiczna kultura w procesie programowania, bo
> nie chodzi tylko o typy, ale też o to, czy np. w danym pakiecie w
> ogóle istnieje jakaś funkcja, itd.) nie daje mi tu żadnej pomocy -
> mogę wywalić z projektu cały plik i udawać, że nic się nie stało. To
> prowadzi do tzw. fałszywego poczucia bezpieczeństwa.

Daje różne rzeczy, między innymi ułatwia code reuse między różnymi
typami danych, programowanie deklaratywne, loose coupling i różne inne
rzeczy.

> (Tak, słyszałem o unit testach. Znam również ich realny koszt i
> najchętniej posługuję się tą metodą, która w danej sytuacji jest
> tańsza.

Z mojego doświadczenia wynika, że w prawie każdym przypadku koszt unit
testów jest tańszy od kosztu braku (dobrych) unit testów. Również w
językach ze statycznym typowaniem.

> Przy opisie związków strukturalnych między bytami w programie
> statyczny system typów jest *znacznie* tańszy, niż unit testy.)

zależy jakich związków stukturalnych. Znane mi systemy typów słabo
wspierają związki typu "prawie to samo co...", "naczęściej jest
rodzajem...", "staje się ... w momencie ...".

> Zależnie od projektu, jedno bądź drugie ma większy sens. Granicą
> podziału wydaje się być właśnie to, czy dany projekt może być w
> przyszłości przerabiany albo refaktoryzowany. Osobiście: jeśli widzę,
> że dany projekt zajmie więcej niż jeden plik, to nie piszę go w
> języku dynamicznym.

Całkiem spore i mocno zmieniające się w czasie serwisy webowe pisze się
np. w Pythonie czy Ruby.