On 08/02/2013 20:56, darekm wrote:
> W dniu 2013-02-08 18:14, Andrzej Jarzabek pisze:
>
>>> To że zawsze możesz użyć wszystko ma swoją drugą stronę: niczego nie
>>> możesz zabronić. Przy statycznym typowaniu każda funkcja ma
>>> zdefiniowane dla jakich typów i w jakim kontekście jest poprawna i w
>>> innych jej nie użyjesz. A wraz ze wzrostem programu liczba kontekstów
>>> niepoprawnych rośnie szybciej niż tych poprawnych.
>>
>> Można ograniczyć ten efekt odpowiednio projektując kod.
>
> Przy wsparciu języka to ograniczenie jest skuteczniejsze.

Ale ma swój koszt.

>>>> Bo zajmuje czas, bo wprowadza szum do kodu, bo utrudnia refaktoryzację.
>>>> Może nie zawsze, ale przynajmniej niekiedy.
>>> Co zajmuje czas: wklepanie kodu? Przecież to jest czas pomijalny.
>> Wymyślenie zestawu typów i relacji między nimi, odpowiadające
>> problemowi. Przerabianie tego zestawu w miarę jak problem się zmienia.
>
> Co jest prostsze: "odpowiednio" projektować kod, czy tylko wprowadzać
> więcej typów wraz z ewentualnie duplikowaniem kodu, szczególnie że to
> ostatnie jest w mniejszym lub większym zakresie mechaniczne.

Odpowiednie projektowanie jest inne w językach statycznie typowanych niż
dynamicznie typowanych. W statycznie typowanym języku też możesz mieć
problem duplikacji kodu, który wykonuje te same operacje, ale na
niekompatybilnych typach. Żeby zlikwidować ten problem musisz przerobić
kod np. modyfikując hierarchię typów. Różne języki oferują różne
idiomatyczne narzędzia do tego, interfejsy i generyki w Javie, w C++
masz szablony ze specjalizacją i wielodziedziczenie, włącznie z
dziedziczeniem normalnym i wirtualnym. Nie zawsze jest oczywiste, które
rozwiązanie jest właściwe, i nie zawsze rozwiązanie, które likwiduje
duplikację i "działa" ma jeszcze dodatkowo te zalety, że kod jest
czytelny i łatwy w utrzymaniu.

> Poza tym struktury danych i relacje między nimi masz dane w
> specyfikacji. Typy to mechanizm separacji, aby błędnie nie mieszać
> niewłaściwych struktur i narzędzi.

W specyfikacji czego? W firmach, w których zdarzyło mi się pracować,
programiści mieli dane co najwyżej specyfikacje wymagań, tworzenie typów
danych do realizacji tych wymagań należało do zadań programisty.

Oczywiście jeśli kto inny to zroi, to niczego to nie rozwiązuje, b nadal
ktoś musi to zrobić - raczej jeszcze pogarsza to sprawę.

>>> Refaktoryzacja: kompilator powie Ci gdzie NIE możesz użyć nowej
>>> funkcji/struktury
>>
>> W pewnych sytuacjach tak, ale czasem ci powie, że błąd, bo typ X nie
>> istnieje i faktycznie, po refaktoryzacji nie istnieje.
>
> czyli dobrze, nieprawdaż?

Niedobrze, bo muszę się zastanawiać, jak wpasować wcześniej dobrze
działający kod do nowego systemu typów - i ewentualne ponowne
przerobienie tego systemu. W sytuacji z dynamicznym typowaniem nie masz
tego problemu, bo o ile wykonanie danej operacji na danym obiekcie ma
sens z punktu widzenia funkcjonalności, to możesz to po prostu zrobić.

>>>> Wprowadzasz duplikację. No i pojawiają się dalsze problemy, co na
>>>> przykład, jeśli chcesz skopiować structa i owej kopii dołożyć kilka
>>>> nowych pól?
>>>
>>> Tylko wtedy gdy to ma sens, mogę zawsze przekazywać nie obiekty a pole.
>>
>> Przykład był przecież uproszczony, jeśli funkcja korzysta z siedmiu
>> pól, to przekażesz jej siedem argumentów?
>>
>
> zacytuję:
> "Można ograniczyć ten efekt odpowiednio projektując kod."

Rozmawiamy w tym momencie o bardzo konkretnym projekcie, który podobno
miał dawać w języku ze statycznym typowaniem zalety języków typowanych
dynamicznie.

Oczywiście, że w językach statycznie typowanych można (zwykle) rozwiązać
problem, o którym dyskutujemy w sposób ograniczający duplikację poprzez
odpowiedni projekt, ale też nie znajdziesz sposobu, który jest równie
wygodny, szybki, prosty i czytelny jak rozwiązanie w języku typowanym
dynamicznie.

>>> Po drugie to kompilator zabroni mi wywołać
>>> foo(foo(c))
>>
>> Nawet jeśli właśnie foo(foo(c)) jest dokładnie tym, co chcesz zrobić.
>
> Jeśli tak jest to będzie istniała odpowiednia definicja.

Sama się zaistniała?

> Jeśli nic nie zrobię to znaczy że nie chcę takiej konstrukcji.
> Mam wybór.

Napisałeś taką konstrukcję, załóżmy, że dlatego, że chciałeś.

>> Nie bardzo rozumiem, jak to się ma do tematu dyskusji. Chcesz
>> powiedzieć, że samochody rodzinne są niepotrzebne, skoro można rodzinę
>> zapakować w dwa tiry i wybrac sobie takie jezioro, do którego prawie
>> dojeżdża uprawniona droga?
>
> Zupełnie odwrotnie. Pytanie brzmi: dlaczego tiry są takie popularne
> skoro mają tyle ograniczeń. W analogii do języków z typowaniem
> statycznym, w których tyle się trzeba "napracować" aby cokolwiek działało.

No więc trochę nie trafiłeś z tą analogią, bo przecież ja nie mówię, że
języki ze statycznym typowaniem są popularne bez powodu, tylko dyskutuję
z tezą, że to, co dają języki dynamicznie typowane albo masz też w
językach statycznie typowanych, albo jest bezużyteczne.