On Sun, 10 Feb 2013 14:25:54 +0000, Andrzej Jarzabek
<a...@g...com> wrote:
> Osobną sprawą jest to, że jesteśmy w takim a nie innym czasie i
> popularne rozwiązania do różnych zastosowań są takie a nie inne -
> niekoniecznie dlatego, że są pod każdym względem najlepsze. Kiedyś
> całkiem duże systemy biznesowe powstawały w dynamicznie typowanym
> Smalltalku i przecież właśnie w tym środowisku opracowano techniki
> refaktoryzacji.

Dla mnie jako współautora kilku juz bibliotek do wyceny tych
nieslawnych derywatow bardzo duza zaletą statycznego systemu typow
jest możliwość precyzyjnego zdefiniowania API biblioteki, w
szczególności zaś blokowanie "podpisania" do biblioteki rzeczy, które
nie miały byc przez nia obrabiane.

RW

do góry

W dniu poniedziałek, 11 lutego 2013 00:58:41 UTC+1 użytkownik Andrzej Jarzabek
napisał:
> To jest argument nazasadzie: "może i ta cała obiektowość ma jakieś
> zalety przy pisaniu dużych systemów, ale co z tego, skoro nidgy bym nie
> zdecydował się użyć jej do pisania czegoś takiego".
Argument "ma zalety bo używam" też niewiele wnosi :)

Właśnie 2-3 godziny temu stanąłem w obliczu takiej refaktoryzacji ze
zmianą struktury danych dla algorytmów, a więc musiałem także
poprawiać algorytmy. Konieczność wynikła z nieudanej próby optymalizacji.
Zamiast globalnie trzymać dane w pamięci, a potem filtrowanie/sortowanie
zrobić na wskaźnikach, to dla algorytmów przygotowałem specjalistyczne
struktury danych. Globalne dane były konwertowane na specjalistyczne,
liniowe tablice w pamięci. Miałem nadzieję że dzięki sekwencyjnemu
dostępowi do pamięci i mniejszym rozmiarom specjalistycznych struktur
program zadziała szybciej. Niestety nie udało się, narzut na konwersje i
kopiowane pożarł cały zysk.

No więc stanąłem w obliczu tej refaktoryzacji i myślę sobie, jakbym miał
język z dynamicznym typowaniem, to pomimo wielu błędów w pozostałych
częściach programu, bym mógł program uruchomić. Bym mógł uruchomić te
działające części, a w trakcie uruchomienia może zdołałbym zrobić
jeszcze jakiś eksperyment z optymalizacją. Ze statycznym typowaniem nie
mogłem na to sobie pozwolić, musiałem wszystkie użycia specjalistycznych
struktury zamienić na tablice wskaźników. Myślę sobie dalej: znalazłem
zaletę dynamicznego typowania.

Jednak po chwili druga myśl: przecież kompilator przez 2-3 godziny krzyczał, że
jest źle. Bez tej pomocy bym pewnie te wszystkie użycia znajdował przez
tydzień albo dłużej. Co więcej, środowisko uruchomieniowe odsyłałoby mnie
do linii w której błąd się uaktywnił, a do złego użycia bym musiał dochodzić
debugerem po stosie wielokrotnych wywołań funkcji. Tutaj kompilator pokazał
mi od razu gdzie nie ma zdefiniowanych typów i od razu byłem w linii
która wymagała poprawek.

Podsumowując, moje stanowisko nie zmieniło się, nie widzę tych zalet,
choć niewykluczone że są.

Pozdrawiam

do góry

On 11/02/2013 05:04, M.M. wrote:
[...]
> Jednak po chwili druga myśl: przecież kompilator przez 2-3 godziny krzyczał, że
> jest źle. Bez tej pomocy bym pewnie te wszystkie użycia znajdował przez
> tydzień albo dłużej. Co więcej, środowisko uruchomieniowe odsyłałoby mnie
> do linii w której błąd się uaktywnił, a do złego użycia bym musiał dochodzić
> debugerem po stosie wielokrotnych wywołań funkcji.

Argument jest taki, że gdybyś stosował odpowiednie techniki, co się
wiąże również z pisaniem w sposób idiomatyczny dla dynamicznego
typowania, to:
a) większość tych sytuacji nie byłaby błedami,
b) pozostałe błędy zostałyby wyłapane przez unit testy,
c) mógłbyś wyłapać błędy w momencie powstania np. przy pomocy asercji.

Oczywiście, jesli piszesz swoje programy tak, jakbyś pisał w języku ze
statycznym typowaniem, to prawdopodobnie będziesz miał gorsze rezultaty
niż ze statycznym typowaniem.

do góry

W dniu poniedziałek, 11 lutego 2013 00:58:41 UTC+1 użytkownik Andrzej Jarzabek
napisał:

> > Co z tego, że pokazuje, skoro przez swoją dynamiczność nie dałbym mu
> > szansy się wykazać.
>
> To jest argument nazasadzie: "może i ta cała obiektowość ma jakieś
> zalety przy pisaniu dużych systemów, ale co z tego, skoro nidgy bym nie
> zdecydował się użyć jej do pisania czegoś takiego".

Tak, to jest dokładnie taki argument. Poza tym, że obiektowość powstała z myślą o
dużych systemach i sama w sobie nie ma cech, który by były z nimi sprzeczne.

> >>> 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?
>
> Nie wiem nawet, jak to porównać. Chodzi o zupełnie inny paradygmat
> pisania programów,

Droższy? Bardziej efektywny? Czy jedynie "też pozwala"?

Jeśli coś ma być inaczej, to ma być po coś i ma się opłacać.

> > Jak do tej pory jedyny code reuse między różnymi typami widywałem w
> > kontenerach
>
> To niewiele widziałeś.

Możliwe, ale nie czuję się tym pokrzywdzony a skoro tak, to najwyraźniej nic nie
straciłem, że nie widziałem.
Poproszę o lepszy argument, niż "niewiele widziałeś".

> Żeby nie było: w C++ da się osiągnąć niezły code reuse, ale czasem
> sensowne zrobienie tego wymaga ostrego lawirowania między dziedziczeniem
> klas a szablonami.

Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy bilans.

> > 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.
>
> Można tak zrobić system rozproszony, żeby nie był heterogeniczny.

Dlaczego? Po co? Żeby móc powiedzieć, że jakiś jeden język jest OK?
Jednym z celów rozpraszania jest wykorzystanie zalet różnych technologii, bo różne
technologie mają swoje mocne punkty w różnych częściach całości.

Czyli znowu mamy podobny argument: co z tego, że język dynamiczny daje fajną
serializację w homogenicznym systemie rozproszonym, skoro nie robię homogenicznych
systemów rozproszonych. Ten argument może być niewygodny, ale jest realny i oznacza,
że w realu wartość dodana dynamicznego systemu typów jest mniejsza, niż się
reklamuje.

> Poza tym jest też taki dyanmiczny język specjalnie zaprojektowany do
> pisania homogenicznych systemów rozproszonych jakim jest Erlang.

I jego też nie użyję z powodu tego samego argumentu?

Tak, wiem, że ktoś takie systemy pisze. Ale *ja* nie piszę, więc Erlang rozwiązuje
problem, którego nie mam a tych, które mam, nie rozwiązuje.

> >> loose coupling
>
> > Daję radę bez dynamicznego systemu typów.
>
> Nie chodzi o to, czy daje radę, tylko czy jest wygodne, łatwe i proste.

Całe programowanie obiektowe powstało po to, żeby mieć loose coupling, więc nie widzę
tu problemu. Realizacja OO w mainstreamowych językach sprawia, że jest to zarówno
wygodne, łatwie i proste.

> W jęyku dynamicznie typowanym też nie potrzebujesz takiego unit testu,
> bo skoro masz test, który testuje, to, co robi foo, kiedy wywołuje bar z
> tą liczbą parametrów, to on automatycznie sprawdza też, że może zawołać
> z taką listą, z jaką woła.

Zakładając pokrycie 100%. Bo tylko wtedy faktycznie zawoła.
Testy z pokryciem 100% są bardzo kosztowne.

> > 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ę.
>
> I co, wyjątków z Javy nie widujesz?

A czy ja gdzieś w tej dyskusji napisałem, że Java jest dla mnie statycznym językiem?

(Wyprzedzam następne pytanie: w C++ i w Adzie też wyjątki widuję.)

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

do góry

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.

Pozdrawiam

do góry

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

do góry

W dniu poniedziałek, 11 lutego 2013 18:41:42 UTC+1 użytkownik firr kenobi napisał:
> 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.
Tak na szybko tez nie potrafie zrobic takiego opracowania. Watpie aby
to mogl byc maly kawalek. Rozmawiamy o trudnosciach jakie pojawiaja sie
przy zarzadzaniu duzymy projektami i o tym jak jezyk moze pomagac.


> (funkcje) "apply" "send" "find" "load_to_ram" i inne tego rodzaju
Zgadza sie, w jezyku bez dynamicznych typow, trzeba sobie radzic
inaczej - pytanie czy "to jest warte tego".

Pozdrawiam

do góry

W dniu poniedziałek, 11 lutego 2013 18:55:19 UTC+1 użytkownik M.M. napisał:
> W dniu poniedziałek, 11 lutego 2013 18:41:42 UTC+1 użytkownik firr kenobi napisał:
>
> > 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.
>
> Tak na szybko tez nie potrafie zrobic takiego opracowania. Watpie aby
>
> to mogl byc maly kawalek. Rozmawiamy o trudnosciach jakie pojawiaja sie
>
> przy zarzadzaniu duzymy projektami i o tym jak jezyk moze pomagac.
>
>
>
>
>
> > (funkcje) "apply" "send" "find" "load_to_ram" i inne tego rodzaju
>
> Zgadza sie, w jezyku bez dynamicznych typow, trzeba sobie radzic
>
> inaczej - pytanie czy "to jest warte tego".
>

mz jest warte ale w pewnym obszarze
zastosowan (mniej biblioteki zwł graficzne
czy inne gdzie potrzebna jest wydajnosc)
a bardziej kod userski ze tak to nazwe

Mz niekoniecznie duze projekty maly
przyklad tez na pewno mozna podac

Inna kwestia to czy dynamiczne typowanie
i jezyki sktyptowe to wlasciwie jedno i to
samo czy nie - nie bardzo kojarze ktore
jezyi nie bardzo daja sie kompilowac ale
mozliwe ze wlasnie te z dynamicznym typowaniem
co by wyznaczalo moze cos w rodzaju znaku
rownosci miedzy tymi sprawami;

do góry

On 11/02/2013 09:49, Maciej Sobczak wrote:
> W dniu poniedziałek, 11 lutego 2013 00:58:41 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>>> Co z tego, że pokazuje, skoro przez swoją dynamiczność nie dałbym
>>> mu szansy się wykazać.
>>
>> To jest argument nazasadzie: "może i ta cała obiektowość ma jakieś
>> zalety przy pisaniu dużych systemów, ale co z tego, skoro nidgy bym
>> nie zdecydował się użyć jej do pisania czegoś takiego".
>
> Tak, to jest dokładnie taki argument.

No to odpowiem: ty nie dałbyś, ale kto inny dał. Tajemnica wyjaśniona?

> Poza tym, że obiektowość powstała z myślą o dużych systemach

W którym momencie?

> i sama w sobie nie ma cech, który by były z nimi sprzeczne.

http://c2.com/cgi/wiki?ArgumentsAgainstOop
http://folk.uio.no/andersmo/oo.html

>>>> Pozwala, ale są inne sposoby, które też pozwalają.
>>> Droższe?
>>
>> Nie wiem nawet, jak to porównać. Chodzi o zupełnie inny paradygmat
>> pisania programów,
>
> Droższy? Bardziej efektywny? Czy jedynie "też pozwala"?

Zapewne zależy kto, co i w jakim języku.

> Jeśli coś ma być inaczej, to ma być po coś i ma się opłacać.

A dlaczego akurat to dynamiczny, a nie statyczny system typów to jest
"inaczej"?

>>> Jak do tej pory jedyny code reuse między różnymi typami widywałem
>>> w kontenerach
>>
>> To niewiele widziałeś.
>
> Możliwe, ale nie czuję się tym pokrzywdzony a skoro tak, to
> najwyraźniej nic nie straciłem, że nie widziałem. Poproszę o lepszy
> argument, niż "niewiele widziałeś".

Poproszę o lepszy argument, niż "nie widziałem".

>> Żeby nie było: w C++ da się osiągnąć niezły code reuse, ale czasem
>> sensowne zrobienie tego wymaga ostrego lawirowania między
>> dziedziczeniem klas a szablonami.
>
> Statyczne typowanie ma swój koszt. Pytanie, jaki jest końcowy
> bilans.

I uważasz, że potrafisz ten bilans policzyć?

>>> 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
[...]
>> Można tak zrobić system rozproszony, żeby nie był heterogeniczny.
>
> Dlaczego? Po co? Żeby móc powiedzieć, że jakiś jeden język jest OK?

Na przykład dlatego, że nie ma potrzeby robić go heterogenicznym, a
heterogeniczność pociąga koszta.

> Jednym z celów rozpraszania jest wykorzystanie zalet różnych
> technologii, bo różne technologie mają swoje mocne punkty w różnych
> częściach całości.

Ale to tylko jeden z celów. Są inne powody, jak wykorzystanie zasobów
(mocy obliczeniowej, pamięci, dysku, przepustosości połączeń
sieciowych), wysoka niezawodność (redundancja), globalne rozproszenie
(żeby klient ze Stanów nie musiał się łączyć z serwerem w Europie) i tak
dalej.

Poza tym pozostańmy nawet przy heterogeniczności. Dość popularnym
rozwiązaniem z językami dynamicznymi jest Javascript w przeglądarce i
jakiś Python czy inny Ruby na serwerze. W celu serializacji obiektów i
przesyłania ich przez sieć wymyślono format JSON - dzięki niemu można z
łatwością serializować dane w Pythonie i przesyłać do javascriptowego
klienta lub odwrotnie. Można to spokojnie robić bez potrzeby
uzgadaniania definicji typów pomiędzy serwerem a klientem - każda strona
korzysta z tych właściwości, jakich potrzebuje, i każda jest w stanie
wziąć odserializowany obiekt i zserializować go z powrotem razem ze
wszystkimi polami/właściwościami, nawet jeśli nie były one jeszcze
zdefiniowane w momencie pisania tego kodu.

> Czyli znowu mamy podobny argument: co z tego, że język dynamiczny
> daje fajną serializację w homogenicznym systemie rozproszonym, skoro
> nie robię homogenicznych systemów rozproszonych. Ten argument może
> być niewygodny, ale jest realny i oznacza, że w realu wartość dodana
> dynamicznego systemu typów jest mniejsza, niż się reklamuje.

Argument, że czegośtam nie robisz jest tyle realny, co mało znaczący.
Dla każdej rzeczy istnieje taki ktoś, kto jej nie robi.

>> Poza tym jest też taki dyanmiczny język specjalnie zaprojektowany
>> do pisania homogenicznych systemów rozproszonych jakim jest
>> Erlang.
>
> I jego też nie użyję z powodu tego samego argumentu?
>
> Tak, wiem, że ktoś takie systemy pisze. Ale *ja* nie piszę, więc
> Erlang rozwiązuje problem, którego nie mam a tych, które mam, nie
> rozwiązuje.

No ale przecież ja się o twoich problemach nie wypowiadam. Chyba że, jak
M.M. uważasz, że jak tobie coś nie jest potrzebne, to w ogóle nie jest
potrzebne.

BTW można się zastanowić nad faktem, że dynamicznie typowany Erlang jest
przeznaczony do, i używany w systemach wysokiej niezawodności.

>>>> loose coupling
>>> Daję radę bez dynamicznego systemu typów.
>> Nie chodzi o to, czy daje radę, tylko czy jest wygodne, łatwe i
>> proste.
>
> Całe programowanie obiektowe powstało po to, żeby mieć loose
> coupling, więc nie widzę tu problemu. Realizacja OO w mainstreamowych
> językach sprawia, że jest to zarówno wygodne, łatwie i proste.

Nie jest. Prosty przykład - w C++ nawet niewielka zmiana definicji typu
danych między biblioteką a programem z niej korzystającym może
spowodować spektakularne wylecenie wszystkiego w powietrze. W Javie jest
trochę lepiej, ale próby ładowania różnych wersji klasy też mogą się
niedobrze skończyć. No i oczywiście rozpraszanie czegokolwiek to osobny
cyrk, wymagający opakowania w wiele warstw, IDL-i, WSDL-i, XML schema i
nie wiadomo czego jeszcze.

>> W jęyku dynamicznie typowanym też nie potrzebujesz takiego unit
>> testu, bo skoro masz test, który testuje, to, co robi foo, kiedy
>> wywołuje bar z tą liczbą parametrów, to on automatycznie sprawdza
>> też, że może zawołać z taką listą, z jaką woła.
>
> Zakładając pokrycie 100%. Bo tylko wtedy faktycznie zawoła. Testy z
> pokryciem 100% są bardzo kosztowne.

Nie musisz mieć pokrycia 100%, wystarczy pokrycietego kawałka kodu, w
którym foo woła bar. To nie powinno być takie trudne, bo jako
programista wiesz przecież, dlaczego foo woła bar (jeśli nie wiesz, to
statyczne typowanie cię nie uratuje) i w związku z tym niezależnie od
tego, czy woła i z jakimi parametrami masz unit test testujący ten
kawałek funkcjonalności foo.

Poza tym niemal 100% pokrycie unit testami (z wyjątkiem cienkich warstw
owijających przekraczanie granic systemu, które można pokryć integration
testami) jest bardzo tanie, jeśli stosuje się TDD. A ponieważ w
większości przypadków TDD jest tańsze niż alternatywy, to wysokie
pokrycie unit testami jest po prostu tak tanie, że aż ma koszt ujemny.

>>> 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ę.
>> I co, wyjątków z Javy nie widujesz?
>
> A czy ja gdzieś w tej dyskusji napisałem, że Java jest dla mnie
> statycznym językiem?

W myśl powszechnie rozumianego podziału na dynamiczne i statyczne
systemy typów, Java jest językiem o typowaniu statycznym.

> (Wyprzedzam następne pytanie: w C++ i w Adzie też wyjątki widuję.)

Na stronach WWW nie widać wyjątków z C++ bo:
a) praktycznie nigdzie nie stosuje się C++ do aplikacji webowych,
b) jak już w C++ coś poleci, to raczej UB i kompletne wywrotka niż
niezłapany wyjątek.

Z Adą myślę, że w punkcie a) jest podobnie, tylko bardziej, w związku z
czym ewentualność punktu b) staje się nieistotna.

do góry

On 11/02/2013 16:24, M.M. wrote:
[...]
> 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.

A ktoś twierdził, że jest?

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

On działa w obydwie strony, bo jeśli logika jest OK, tylko hierarchia
typów błędnie mapuje dziedzinę, to też masz błędy kompilatora.

do góry