W dniu niedziela, 10 lutego 2013 18:53:53 UTC+1 użytkownik Andrzej Jarzabek napisał:

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

Co z tego, że pokazuje, skoro przez swoją dynamiczność nie dałbym mu szansy się
wykazać. Coś w stylu: być może Fiat 126p przejawia jakieś ciekawe własności podczas
przekraczania bariery dźwieku, ale nie przekonam się o nich, bo w obawie o swoje
bezpieczeństwo w całym zakresie poniżej tego, po prostu do niego nie wsiądę.
(Nie znaczy to, że w ogóle nie wsiądę - może i wsiądę, ale w innym celu.)

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

Droższe?

> Daje różne rzeczy, między innymi ułatwia code reuse między różnymi
> typami danych,

Jak do tej pory jedyny code reuse między różnymi typami widywałem w kontenerach i ten
reuse polegał na tym, że można coś skopiować albo porównać albo wyliczyć hash, itd.
Do tego niepotrzebne są języki dynamiczne. Innym przykładem może być np.
serializacja, ale ponieważ temat serializacji pojawia się w systemach rozproszonych,
które zwykle są heterogeniczne, to i tutaj mało mnie interesuje, co mi ma do
zaoferowania jakiś jeden język, bo zwykle co by nie miał, to i tak nie rozwiązuje to
problemu heterogeniczności. I tak, np. fajnie, że Python ma swoją dynamiczną
serializację a Java swoją, ale nic mi po tym, skoro jedno z drugim nie chce rozmawiać
i w rezultacie wybieram rozwiązanie, do którego znowu dynamiczność nie jest
potrzebna. Itd.

Poważnie - nie przypominam sobie, od ręki, pozytywnego przykładu w temacie code
reuse.

> programowanie deklaratywne,

Nie widzę związku z dynamicznością.

> loose coupling

Daję radę bez dynamicznego systemu typów. Większość wzorców projektowych właśnie po
to istnieje, więc nawet nie trzeba wymyślać koła od nowa.

> i różne inne
> rzeczy.

Które też nie są przekonywujące?

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

W języku statycznym nie potrzebuję unit testu, żeby upewnić się, że foo może zawołać
bar z podaną listą parametrów. Unit test, który to sprawdza, nie jest dobry.

Unit testy są dobre (i uzasadnione) wtedy, gdy sprawdzają rzeczy, których system
typów nie sprawdzi. W danym języku - bo w różnych językach siła wyrazu systemu typów
potrafi się znacząco różnić.
Np. są języki, które nie potrafią wyrazić tego, że funkcja sortująca powinna sortować
- wtedy unit testy są dobrym, choć kosztownym uzupełnieniem (i tak jak piszesz, są
wtedy lepsze, niż ich brak). Ale są języki, które potrafią to statycznie wyrazić i
tam unit testy są po grzyba. Z tego wnioskuję, że im bardziej statyczny jest jakiś
język i im bardziej ekspresywny ma system typów, tym mniej unit testów będzie tam
potrzebnych. Dla mnie to prosty rachunek.

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

https://www.google.pl/search?q=django+exception

Google na to: "Około 3,760,000 wyników (0,15 s)"

Nabijam się, ale na poważnie: nie raz dostałem po gałach różnymi komunikatami, które
ładnie zdradzały w czym dany serwis został ulepiony, więc potwierdzam: faktycznie,
masz rację, pisze się.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com