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.