On 09/02/2013 18:53, M.M. wrote:
> W dniu sobota, 9 lutego 2013 18:45:20 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>> Przecież nie mówimy o przerabianiu programu do wyceny instrumentów
>> fianasowych na program do sterowania samolotem.
> No więc jeśli rozmawiamy o przerabianiu tego typu, to z całym
> szacunkiem, ale nie rozumiem dlaczego w Java/C++ jest znacznie
> trudniej.

Bo trzeba mieć hierarchię typów dobrze mapującą kawałek dziedzinę i
funkcjonalność programu. Zmienia się dziedzina i/lub funkcjonalność,
może się okazać, że potrzebna nam hierarchia jest zupełnie inna. W
związku z tym potencjalnie każdem miejsce, gdzie używane są te typy,
trzeba zmienić.

> Nie musi być tak, że program bardziej ogólny jest trudniejszy w
> analizie, zaprojektowaniu i implementacji niż program wyspecjalizowany.
> Powiedziałbym wręcz, że zwykle proście się pisze, jeśli od razu,
> nawet w wyspecjalizowanym programie, robi się dobre abstrakcje. Owszem,

Łatwiej zrobić prostszy program z dobrymi abstrakcjami niż skomplikowany
program z dobrymi abstrakcjami. Dobre abstrakcje nie oznaczają, że
musisz uwzględnić wszystko, czego twój program nie musi robić ani
wiedzieć. Wręcz przeciwnie, mogą od tego wszystkiego wyabstrahować.

> w prostym/wyspecjalizowanym programie, jest trochę szybciej jeśli
> niechlujnie sobie wrzucimy dane do kilku struktur/tablic. Zdarza mi
> się samemu tak niechlujnie pisać. Jednak takie programowanie naraża
> nas na straty czasu w trakcie debugowania. Narzut czasu na kilka
> definicji abstrakcyjnych klas zwróci się w postaci mniejszej ilości
> błędów.

Prostota to nie niechlujność.

>> PIeczołowice zaprojektowałeś system typów opierając się na założeniu, że
>> dinozaur to rodzaj gada, a tu nagle się okazuje, że niektóre dinozaury,
>> które musisz obsłużyć w swoim systemie, w myśl twojego systemu typów
>> wcale nie są gadami tylko ptakami. W statycznym systemie typów musisz
>> wszystko teraz przerabiać, przy dynamicznym typowaniu nie przejmujesz
>> się - jeśli masz funkcję obsługującą dinozaura, to możesz tam wrzucić
>> dinozaura, niezależnie od tgo, czy jest gadem czy nie.
> Zgadza się poza najważniejszym: "wszystko przerabiać". Zresztą
> nie wiem... może piszesz o jakimś przypadku w którym naprawdę wszystko
> trzeba przerabiać.

Raz trzeba przerabiać mniej, raz więcej. W praktyce niekiedy trzeba
przerabiać na tyle dużo, że zamiast porządnie zrefaktoryzować wpycha się
dziedzinę w niepasujący stary model, sztukując go tak, żeby działało. W
powyższym przykładzie możesz to sobie wyobrazić tak, że ktoś decyduje,
że najprościej będzie zaimplementować zmianę zakładając, że klasa Gad
nie zawsze reprezentuje gady, więc wstawia się nową metodę
'jestPrawdziwymGadem()'. O przykrych konsekwencjach takiego działania
nie muszę nawet wspominać.

> Tak czy inaczej nie widzę tego że trzeba wszystko
> przerabiać. O jakie dokładnie przeróbki chodzi z tymi dinozaurami?

No, masz funckją przyjmującą obiet typu Gad (albo metodę tego typu),
która ci wcześniej obsługiwała dinozaury i w iluś miejscach programu
korzystasz z tej właściwości, a tu nagle się okazuje, że tak się nie da
i musisz wymyśleć coś innego.

> Mam nadzieję że nie piszesz tego w nawiązaniu do naszych dawnych
> rozmów,

Nie, absolutnie do niczego nie nawiązuję.

> Wracając do Twojego przykładu z dinozaurami. Przykład jest dobry, ale
> jeszcze za mało konkretny.

Z założenia każdy przykład, jaki można podać w takiej dyskusji będzie
mało konkretny. Konkretne przykłady dotyczą mocno rozbudowanych
programów ze skomplikowanymi hierarchiami typów o dziesiątkach lub
setkach składowych, mapującymi skomplikowane dziedziny, których
zrozumienie wymaga wielu lat nauki i praktyki.

Czy jeśli ci na przykład powiem, że takim przykładem jest wprowadzenie
obsługi transakcji typu taikeshu do systemu wypożyczania papierów
wartościowych, to odpowiesz mi "aha, no faktycznie, teraz rozumiem", czy
"bzdury opowiadasz, refaktoiryzacja dobrze zaprojektowanego modelu
danych wypożyczania papierów wartościowych tak, żeby obsługiwać
transakcje taikeshu nie powinna nastręczać żadnych trudności"?

> Dlaczego w Java/C++ nie można takiego
> Dinozaura przerobić na klasę bazową, a następnie z niej wyprowadzić klas
> Gad i Ptak? Stare algorytmy przecież zadziałają tak samo jak działały do
> tej pory.

Nie zadziałają w ogóle, bo kompilator odmówi ich skompilowania, krzycząc
że spodziewa się Gada, a ty mu przekazujesz Dinozaura. Po poprawieniu
pięciuset takich błędów kompilatora, przy 501-szym zdajesz sobie sprawę,
że twoja nowa hierarchia też jest niedobra, bo nie wszystkie gady są
dinozaurami.

>> Zwłaszcza jeśli wymaganą logikę możesz zaimplementować w tydzień, a
>> przez kolejne trzy tygodnie będziesz uciszał krzyki kompilatora.
> Mój przykład z łodzią, samochodem i amfibią zamieniłeś na prosty
> program do instrumentów finansowych i skomplikowany program do instrumentów
> finansowych. Więc ja Twoje trzy tygodnie krzyków zamieniam na kilka
> godzin w stosunku tygodnia roboty, a przy okazji tych kilku godzin
> kompilator wychwyci błędy, które wyszłyby dopiero w trakcie uruchamiania.

Ale przecież ja nie przeczę, że to, co pisałeś o samochodach i amfibiach
jest prawdą. Może i jest - nieznam się na tym. Moja teza dotyczy czegoś
innego - nie samochodów i amfibii, tylko programów komputerowych.

do góry

>
> > a jedynym Twoim celem jest udowodnienie, ze
>
> > statyczne typowanie jest najlepsze zawsze, wciaz i w ogole.
>
> Nie mam ani takiego celu, ani przeciwnego. Na razie zwyczajnie
>
> nie widzę wyraźnych zalet, nie bardzo wiem jakie stanowisko
>
> przyjąć. Padło porównanie do asemblera i języka wysokiego
>
> poziomu. Nie wiem, ale podejrzewam, że typowanie statyczne i
>
> dynamiczne nie wprowadza aż tak wiele, jak wprowadziły języki
>
> wyższego poziomu niż asembler.
>

Mz moze byc tak ze to wlasnie wewnetrzne
dynamiczne typowanie powoduje ten skok
'wysokopoziomowosci' w jezykach w stosunku
do c - (samo OOP z kolei nie bo to tylko
cos bardziej jak zakret w kleceniu wyrazen)

Zmiana ew bylaby spora bo polegalaby na tym
ze po stronie kodu klienta programista nie
musialby wogole myslec o typach tylko bardziej
o contencie np jak w czyms

x = open("identyfikator do jakichs danych");

send(x, "identyfikator mijejsca docelowego");

to nie myslenie o typach to wlasnie zdaje sie
spory skok wysokopoziomowosci, z kolei nie
wiadomo jakie minusy to za soba pociaga,
pociaga na pewno maskaryczne zmiany w temacie tego czym staje sie takie programowanie
w stosunku do dtarego modelu opartego na znajomosci rozkładu bajtów itd.

do góry

On Fri, 8 Feb 2013 09:52:15 -0800 (PST), "M.M." <m...@g...com>
wrote:
> dogłębna (nie kłóćmy się o zmianę int na double - to niezauwa=
> żalnie mały
> nakład pracy) refaktoryzacja staje się koszmarem.

Maly? Chyba nigdy takiej zmiany nie robiłeś. Przecież to zupełnie
inna arytmetyka.

RW

do góry

On Sat, 09 Feb 2013 17:45:20 +0000, Andrzej Jarzabek
<a...@g...com> wrote:
> Przecież nie mówimy o przerabianiu programu do wyceny instrumentów
> fianasowych na program do sterowania samolotem. Można przewidzieć,
że
> przerabianie programu do wyceny instrumentów finansowych może np.
> uwzględnić inne rodzaje instrumentów finansowych i inne metody
wyceny
> niż oryginalnie przewidywano.


> Problem jest taki, że jeśli spróbujesz zaprojektować swoją
hierarchię
> typów tak, żeby uwzględnić wszelkie możliwe rodzaje instrumentów
> finansowych, to wykonasz gigantyczny kawał nikomu nie potrzebnej
roboty,
> ale też stworzysz gorszy program, bo bardziej skomplikowany,
trudniejszy
> do zrozumienia, a zatem łatwiej będzie popełnić w nim błąd, i
trudniej
> go zmienić np. uwględniając instrument finansowy, którego nie
> uwzględniłeś w pierwotnym projekcie (bo, powiedzmy, jeszcze nie
istniał).
> Natomiast jeśli chodzi o przerabianie programu do wyceny
instrumentów
> tak, żeby wyceniał nowe instrumenty, żeby stosował nowe metody
wyceny,
> czy żeby cośtam jeszcze robił z tymi instrumentami czy wycenami,
czego
> pierwotnie nie przewidziałeś, to refaktoryzacja w celu
uwzględnienia
> danej funkcjonalności nie musi być koszmarem, pod warunkiem, że się
> stosuje odpowiednie praktyki.

W praktyce prawie wszystkie instytucje używają do tego celu
statycznego systemu typów, i nawet jezeli ktos przez to musi wiecej
naklepac kodu w C++/Java, to największe problemy i tak kryją sie
gdzie indziej.

RW

do góry

W dniu sobota, 9 lutego 2013 18:45:20 UTC+1 użytkownik Andrzej Jarzabek napisał:

> > Moim zdaniem jest to kwestia szczęścia. Jeśli nie odgadniemy jak
> > projekt w przyszłości będzie się rozwijał, to w każdym języku
> > nakład pracy) refaktoryzacja staje się koszmarem.

> Przecież nie mówimy o przerabianiu programu do wyceny instrumentów
> fianasowych na program do sterowania samolotem.

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

(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. Przy opisie związków
strukturalnych między bytami w programie statyczny system typów jest *znacznie*
tańszy, niż unit testy.)

Natomiast dynamiczny system typów (i bardziej ogólnie: ...) wydaje się być
spektakularny zanim dojdzie do fazy przerabiania czegokolwiek, bo można wykazać się
postrzegalnie wysoką produktywnością.

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.

> Można przewidzieć, że
> przerabianie programu do wyceny instrumentów finansowych

Zdaje się, że takie coś zajmuje zwykle więcej, niż jeden plik.

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

do góry

On 10/02/2013 10:16, Roman W wrote:
> On Sat, 09 Feb 2013 17:45:20 +0000, Andrzej Jarzabek
>
>> czy żeby cośtam jeszcze robił z tymi instrumentami czy wycenami,
> czego
>> pierwotnie nie przewidziałeś, to refaktoryzacja w celu
> uwzględnienia
>> danej funkcjonalności nie musi być koszmarem, pod warunkiem, że się
>> stosuje odpowiednie praktyki.
>
> W praktyce prawie wszystkie instytucje używają do tego celu statycznego
> systemu typów, i nawet jezeli ktos przez to musi wiecej naklepac kodu w
> C++/Java, to największe problemy i tak kryją sie gdzie indziej.

Nikt przecież nie mówi, że statyczne typowanie nie ma swoich zalet. Z
drugiej strony tej wyceny instrumentów użyłem jako przykładu czegoś, co
może być ciężkie w refaktoryzacji w statycznym systemie typów, nie jako
dziedziny, do której dynamiczne typowanie nadaje się szczególnie dobrze.
Nie podałem jako przykładu np. programu do logistyki bo nie mam o tym
żadnego pojęcia i nie potrafiłbym nawet podać przykładu wymaganej
poprawki dla takiego programu, która mogłaby spowodować potrzebę
refaktoryzacji z daleko idącą modyfikacją hierachii typów - po prostu
naprawdę nie mam pojęcia, co to mogłaby być za zmiana albo jakie to typy
byłoby trzeba refaktoryzować.

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.

do góry

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.

do góry

W dniu niedziela, 10 lutego 2013 18:53:53 UTC+1 użytkownik Andrzej Jarzabek napisał:
> Całkiem spore i mocno zmieniające się w czasie serwisy webowe pisze się
> np. w Pythonie czy Ruby.
Miałem okazję przyglądać się pracom nad serwisami webowymi w Pythonie -
samemu nie brałem udziału, ponieważ nie znam Pythona. Co mi się rzuciło w
oczy i było to miłe wrażenie, to mała (wręcz bardzo mała) ilość kodu
względem PHP i JSP. Różnice w czasie wykonania pewnie były, ale gołym okiem
nie zaobserwowałem. Podobnie nie widziałem na tyle dużych różnic w ilości
popełnianych błędów aby dało się porównać do JSP, czy PHP.

ASP nie znam, ciekawe jak wypada na tle reszty.

Abstrahując od powyższego tematu, do jakich projektów polecacie Pythona, do
jakich Rubiego, a do jakich Scalę?

Druga sprawa, jaki język uważacie za najlepszy do ogólnych zastosowań?
Chodzi mi o najlepszy z praktycznego punktu widzenia, czyli jeśli dobry
język nie ma dużej ilości bibliotek, to w gruncie rzeczy jest językiem
kiepskim.



Pozdrawiam

do góry

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

do góry

On 10/02/2013 21:36, Maciej Sobczak wrote:
> W dniu niedziela, 10 lutego 2013 18:53:53 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> 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.)

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

>>> 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, różnica powiedzmy jak między programowaniem
obiektowym a funkcyjnym.

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

To niewiele widziałeś. W sumie ja też niewiele widziałem, ale reuse poza
kontenerami 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.

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

Można tak zrobić system rozproszony, żeby nie był heterogeniczny.
Serializacja jest tutaj właściwie przyczynkiem do punktu "loose
coupling" - można mieć system rozproszony, którego poszczególne węzły
przekazują sobie zserializowane obiekty i masz różne korzyści typu
łatwiejsze rozbijanie czy scalanie węzłów, ale też to, że możesz
wymienić niektóre części systemu bez wymieniania innych - np. komponent
może zdeserializować obiekt z właściwościami, które nie były częścią
typu w momencie pisania tego komponentu, cośtam zrobić w zależności od
komponentów, które już zna, po czym zserializować go i przesłać dalej
razem ze wszystkimi nieznanymi sobie właściwościami.

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

>> programowanie deklaratywne,
>
> Nie widzę związku z dynamicznością.

http://groovy.codehaus.org/Creating+XML+using+Groovy
%27s+MarkupBuilder
http://code.google.com/p/spock/

Całe code-as-data/data-as-code w dialektach Lispa i techniki korzystania
z tego.

>> loose coupling
>
> Daję radę bez dynamicznego systemu typów.

Nie chodzi o to, czy daje radę, tylko czy jest wygodne, łatwe i proste.

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

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.

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

I co, wyjątków z Javy nie widujesz?

do góry