W dniu poniedziałek, 11 lutego 2013 17:24:41 UTC+1 użytkownik M.M. napisał:
> W dniu poniedziałek, 11 lutego 2013 10:49:54 UTC+1 użytkownik Maciej Sobczak
napisał:
>
>
>
> > Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy bilans.
>
> Właśnie to jest to. Chodzi o bilans końcowy. Zdaje się, że nikt (łącznie
>
> ze mną) nie potrafi w tej dyskusji podać argumentów które by przekonywały
>
> o użyciu takiego lubi innego typowania. Wygląda na to że różnica w
>
> korzyściach pomiędzy jednym typowaniem a drugim nie jest taka duża, jak
>
> pomiędzy asemblerem a językiem wysokiego poziomu.
>
>
>
> Dwa posty wyżej zauważyłem zaletę dynamicznego typowania: można uruchomić
>
> program z błędami, można eksperymentować na tej części działającej, a
>
> dopiero po zakończeniu eksperymentów poprawiać części pozostałe. Jest
>
> to ewidentna zaleta, bo po co za każdym razem dostosowywać cały program
>
> z GUI włącznie, jeśli nie ma jeszcze pewności czy logika zadziała
>
> zgodnie z przewidywaniami. Nie trzeba gdzieś na boku zakładać pomocniczego
>
> projektu z prototypem.
>
>
>
> Skupiając się na problemie, widzimy niezaprzeczalną zaletę, wręcz dodatkową
>
> możliwość jaką daje typowanie dynamiczne. Jednak nie wiem, czy takie
>
> skupianie się jest dobre, raczej jest złe. Liczy się właśnie bilans
>
> końcowy, a w tym bilansie pojawia się brak komunikatów o błędach ze strony
kompilatora.
>

Zeby moc o tym pogadac z sensem, nalezalo by
mz podac przyklad konkretnego kawałka kodu
ktory w wydaniu wewnetrznietypowym jest
ladniejszy i prostszy niz w wersji z twardymi
typami.
Cos takiego pewnie da sie podac ale akurat ja
jak wspomnialem prawie wogole nie mam doswiadczen z yakimi kodami, totez zeby cos
ttakiego podac musialbym sie troche pewnie
nadlubac (nazastanawiac).

Mz teki jezyk z ukrytymi automatycznymi typami
ma jednak racje bytu, takie kodowanie byloby tez inne niz to z twardymi typami,
bardziej
abstrakcyjne np moge sobie wyobrazic komendy
(funkcje) "apply" "send" "find" "load_to_ram" i inne tego rodzaju abstrakcyjne wobec
konkretnych typow pojecia, ktorymi mozna by pisac uniwersalne programy na
uniwersalnych 'kontentach' zupelnie niezaleznie od ich typu - bylby to bardziej
wysokopoziomowy paradygmat
niz ten z twardymi typami