On 2013-02-10 22:36, Maciej Sobczak wrote:
>
> 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.

W tym mysleniu jest pulapka, bo nie da sie zintegrowac (pod)systemow bez
_jednego_ wspolnego jezyka.
Pytanie tylko jaki to jezyk i czy przypadkiem nie taniej jest po prostu
zrezygnowac z innych i wszystko zaimplementowac w tym jednym.


--
Michal

do góry

W dniu 2013-02-13 14:00, Michal Kleczek pisze:
> On 2013-02-10 22:36, Maciej Sobczak wrote:
>>
>> 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.
>
> W tym mysleniu jest pulapka, bo nie da sie zintegrowac (pod)systemow bez
> _jednego_ wspolnego jezyka.
To chyba nie jest prawda, wystarczy odpowiedni protokół komunikacyjny
(to też jest rodzaj języka, ale nie o takim kontekście chyba mówimy).

> Pytanie tylko jaki to jezyk i czy przypadkiem nie taniej jest po prostu
> zrezygnowac z innych i wszystko zaimplementowac w tym jednym.

do góry

Użytkownik "Piotr Chamera" <p...@p...onet.pl> napisał:

>> W tym mysleniu jest pulapka, bo nie da sie zintegrowac (pod)systemow bez
>> _jednego_ wspolnego jezyka.
> To chyba nie jest prawda, wystarczy odpowiedni protokół komunikacyjny (to też jest
rodzaj języka,
> ale nie o takim kontekście chyba mówimy).

Masz racje.
Przyklady (dawnodojrzale technologie komponentowe):
CORBA, COM/DCOM/ActiveX/.NET

AK

do góry

On Feb 13, 9:10 am, Maciej Sobczak <s...@g...com> wrote:
> W dniu wtorek, 12 lutego 2013 20:14:34 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
> > > > > Poza tym, że obiektowość powstała z myślą o dużych systemach
> > > > W którym momencie?
>
> > > W takim, że w małych nie było powodów, żeby powstała.
>
> > Kto konkretnie, kiedy i co takiego zrobił z myślą o dużych systemach?
>
> > Bo mi wygląda na to, że opowiadasz o wymyślonej przez siebie historii
> > OO, a nie tej, która faktycznie miała miejsce.
>
> Bo ta, która miała miejsce, absolutnie nie dotyczyła dużych systemów,
> tylko systemów sztucznej inteligencji i symulacji? Bo, jak wszyscy wiedzą,
> sztuczna inteligencja i symulacje to malutkie programiki, i właśnie w takim
> kontekście wymyślono OO, żeby te malutkie programiki pisało się jeszcze fajniej?

Krótko: masz mniej więcej dwa etapy wymyślania OO, w uproszczeniu
Simula i Smalltalk. Simula została wymyślona pod kątem symulacji;
symulacje jako takie moga być różnej wielkości systemami,
niekoniecznie dużymi.

Drugi etap to wymyślanie ogólnego paradygmatu programowania na
zasadzie "jak pisać programy, żeby było dobrze" - bez szczególnego
skupiania się ani nad konkretnymi zastosowaniami, ani nad skalą.
Smalltalk był stosowany w biznesie, ale został wymyślony jako język do
celów edukacyjnych - czyli raczej do pisania małych programów.

> > > Przewinąłem losowo i trafiłem na argument "Everything has to be an object".
> > Poszczególne argumenty odnoszą się do różnych definicji
> > obiektowości...
>
> Do jakich? Nie napisali a ja nie znam żadnej definicji, do której przykładowe dwa
argumenty by się odnosiły.

To się odnosi do tego, co pisałem powyżej: Simula wprowadziła pewne
cechy języka programowania, które dzisiaj są uważane za
charakterystyczne dla OO, ale nikt wtedy nie mówił o "object oriented
programming". Taka koncepcja została wymyślona później, biorąc to, co
było w Simuli-67 za podstawę i rozwijając to w ogólny paradygmat
programowania.

To, co natomiast jest w popularnym rozumieniu sprzedawane jako OO jest
jakąś tam, zazwyczaj mocno niepełną, adaptacją tej koncepcji. C++
nigdy nie był tworzony jako język OO, jest natomiast bezpośrednio
adaptacją koncepcji z Simuli na grunt języka C. Można w C++ pisać OO w
pierwotnym sensie, i na pewno klasy i dziedziczenie w tym pomagają.

Java pierwotnie miała być językiem w miarę wiernie realizującym tę
koncepcję OO, do której należy również zasada "everything is an
object", ale zdecydowano się złamać między innymi tę zasadę, bo było
"too slow".

Jeśli chodzi o takie OO jak jest w Javie czy C++, to oczywiście
nietrudno znaleźć problemy przeszkadzające w tworzeniu dużych
systemów, dla których "prawdziwe" OO ma dobre rozwiązanie. Na dzień
dobry - kiepskie wsparcie dla współbieżności i związane z tym wyścigi
i problemy z synchronizacją.

> > Technicznie nawet assembler nie posiada cech sprzecznych z dużymi
> > systemami,
>
> Ma, bo przez brak czytelnego wsparcia dla tworzenia abstrakcji nie sprzyja

Nie załapałeś. "Sprzeczne" nie znaczy "nie sprzyja", "sprzeczne"
znaczy obiektywnie uniemożliwia.

Ja rozumiem, że chodziło ci o cechy nie sprzyjające, ale tu właśnie
wychodzi kwestia subiektywności - sprzeczność można uznać za cechę
obiektywną (jeśli coś jest z czymś sprzeczne, to nikt nie da rady).
Sprzyjanie lub nie sprzyjanie jest subiektywne, ale można postulować
intersubiektywny konsensus: assembler nie sprzyja tak w ogóle, bo
prawie każdemu przeszkadza, a ci, którym sprzyja, i tak gorzej (mniej
wydajnie, z większą ilością błędów, z wadami typu brak przenośności)
tworzą w assemblerze niż inni w językach wyższych poziomów.

Podobny konsensus masz w sprawie goto czy nawet powiedzmy w kwestii OO
(choć ta ostatnia jest bardziej kontrowersyjna).

Natomiast w kwestii dynamicznego typowania nie ma takiego konsensusu.
Dynamiczne programowanie ma długą tradycję i przydatne dla wielu ludzi
techniki dla języków takich jak Lisp, Smalltalk, Erlang czy nawet
Python czy Ruby nie są łatwe ani tanie do odtworzenia w językach ze
statycznym systemem typów. Systemów w tych językach powstało i nadal
powstaje sporo i nie ma przekonywaujących dowodów empirycznych na to,
że mają znacząco większe problemy z niezawodnością niż systemy pisane
w C++ czy w Javie.

> > okoliczności. Jeśli np. chcesz mieć UI w przeglądarce, to możesz
> > zaimplementować go:
>
> >  * w dynamicznym Javascript
> >  * jako aplikacja flashowa w dynamicznym actionScript czy jak to się
> > tam nazywa
> >  * jako applet Javowy
> >  * w C++ jako komponent ActiveX
>
> > Nie powiesz chyba, że skoro używasz już C++ albo Javy, to rozwiązanie
> > z tym właśnie językiem jest oczywistym wyborem.
>
> Nie jest.
> Mogę jedynie ubolewać, że w kategorii "UI w przeglądarce" rynek nie wypracował
> safysfakcjonyjących rozwiązań.

Jest całkiem sporo ludzi, których wystarczająco satysfakcjonuje
Javascript.

> Niektórzy pokładają nadzieje w HTML5, ale to tylko czas pokaże, czy te nadzieje się
spełnią.

HTML5 nadal będzie programowany w Javascripcie.

[...]
> > postanowiłem zaimplementowac embedded DSL i wybrałem do tego język
> > Groovy,
> [...]
>
> Tak, też tego używamy.

No i popatrz, wcale nie musze cie przekonywać do używania języka
dynamicznie typowanego, bo już używacie.

> > Na zasadzie: "postawiliśmy checkboxa dla Scali bo ma lambdy? Proszę o
> > konkretny dowód na to, że języki z lambdami są mniej błedogenne niż
> > języki bez lambd".
>
> To bardzo dobry argument. Dlatego nie wprowadziłbym Scali dlatego że ma
> lambdy myśląc o mniejszej błędogenności.

No to immutable data czy cokolwiek. Problem oglnie taki, że bardzo
trudno udowodnić takie rzeczy inaczej niż "mnie się tak wydaje".
Dobrych danych empirycznych nie ma, więc nie wiadomo co innego miałoby
być dobrym argumentem. Jeśli można argumentować z autorytetu, to
przecież bez problemu znajdziesz wielu guru którzy twierdzą, że języki
dynamicznie typowane rządzą (i równie wielu, którzy twierdzą dokładnie
przeciwnie).

do góry

> C++ nigdy nie był tworzony jako język OO,

Swieta racja.
Sam autor C++ okresla C++ jako jezyk _hybrydowy_ do zastosowan _systemowych_.

"Wydaje się", ze ObjC byl blizej "myslenia" o OOP.
(Ma np. wiele cech zapozyczonych z "pureoopowego" Smaltalka).

AK

do góry

W dniu środa, 13 lutego 2013 18:55:37 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Jeśli chodzi o takie OO jak jest w Javie czy C++, to oczywiście
> nietrudno znaleźć problemy przeszkadzające w tworzeniu dużych
> systemów, dla których "prawdziwe" OO ma dobre rozwiązanie. Na dzień
> dobry - kiepskie wsparcie dla współbieżności i związane z tym wyścigi
> i problemy z synchronizacją.

To jest argument podobny do "too slow". Nie widzę w jaki sposób OO ma mieć szczególne
problemy ze współbieżnością. To są zupełnie ortogonalne zagadnienia a nawet można się
pokusić o stwierdzenie, że aktywne obiekty w sposób naturalny realizują
współbieżność, więc tym bardziej nie widzę tu starcia.
Bo to, że można źle napisać wielowątkowy program OO, to wiadomo, ale to nie jest
cecha ani OO ani statycznego systemu typów (w konsekwencji: dynamiczny niczego tu nie
poprawia).

> Natomiast w kwestii dynamicznego typowania nie ma takiego konsensusu.

To zależy, kogo zapytasz. Systemów lotniczych w Pythonie nie widziałem i zdaje się,
że w ogóle nie miałyby szans ze względu na wymagania formalne. To jest dla mnie
konsensus.

O, przypadkiem dobre słowo - formalne. Metody formalne raczej polegają na
statyczności systemu typów. Skądinąd mają też związek z niezawodnością.
To też przyczynia się do tego konsensusu.

> Dynamiczne programowanie ma długą tradycję

Ma.

> Systemów w tych językach powstało i nadal
> powstaje sporo i nie ma przekonywaujących dowodów empirycznych na to,
> że mają znacząco większe problemy z niezawodnością niż systemy pisane
> w C++ czy w Javie.

Kto decyduje, czy dowody są przekonywujące?

> > Mogę jedynie ubolewać, że w kategorii "UI w przeglądarce" rynek nie wypracował
> > safysfakcjonyjących rozwiązań.
>
> Jest całkiem sporo ludzi, których wystarczająco satysfakcjonuje
> Javascript.

Milion much? Czy to znowu ten akwizytor, który mówi "Pana sąsiad kupił"?

> > Niektórzy pokładają nadzieje w HTML5, ale to tylko czas pokaże, czy te nadzieje
się spełnią.
>
> HTML5 nadal będzie programowany w Javascripcie.

No to kiepsko.

> > > Groovy,
>
> > Tak, też tego używamy.
>
> No i popatrz, wcale nie musze cie przekonywać do używania języka
> dynamicznie typowanego, bo już używacie.

Chyba czegoś nie wiesz.
Swego czasu byłem fanem Tcla:

http://cpptcl.sourceforge.net/

Nie musisz mnie przekonywać do użycia języków dynamicznych.
Natomiast nie przekonuj mnie do pisania w nich dużych systemów.

> > To bardzo dobry argument. Dlatego nie wprowadziłbym Scali dlatego że ma
> > lambdy myśląc o mniejszej błędogenności.
>
> No to immutable data czy cokolwiek. Problem oglnie taki, że bardzo
> trudno udowodnić takie rzeczy inaczej niż "mnie się tak wydaje".

Zgadza się. Za immutable data też bym niczego nie wprowadzał, bo podobnie jak lambda
nie uważam tego za postęp. Ale nie róbmy z tego kolejnej odnogi tego multi-wątku.

> Dobrych danych empirycznych nie ma, więc nie wiadomo co innego miałoby
> być dobrym argumentem. Jeśli można argumentować z autorytetu, to
> przecież bez problemu znajdziesz wielu guru którzy twierdzą, że języki
> dynamicznie typowane rządzą (i równie wielu, którzy twierdzą dokładnie
> przeciwnie).

Tak, najlepsze z ekspertami jest to, że jest ich tak wielu - można sobie wybrać tych,
którzy nam odpowiadają.

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

do góry

On 13/02/2013 22:25, Maciej Sobczak wrote:
> W dniu środa, 13 lutego 2013 18:55:37 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> systemów, dla których "prawdziwe" OO ma dobre rozwiązanie. Na
>> dzień dobry - kiepskie wsparcie dla współbieżności i związane z tym
>> wyścigi i problemy z synchronizacją.
>
> To jest argument podobny do "too slow". Nie widzę w jaki sposób OO ma
> mieć szczególne problemy ze współbieżnością. To są zupełnie
> ortogonalne zagadnienia a nawet można się pokusić o stwierdzenie, że
> aktywne obiekty w sposób naturalny realizują współbieżność, więc tym
> bardziej nie widzę tu starcia. Bo to, że można źle napisać
> wielowątkowy program OO, to wiadomo, ale to nie jest cecha ani OO ani
> statycznego systemu typów (w konsekwencji: dynamiczny niczego tu nie
> poprawia).

OO w realizacji takiej jak Java/C++ ma dokładnie takie same problemy ze
współbieżnością co programowanie strukturalne/proceduralne, którego jest
prostym rozwinięciem. Wszystkie te paradygmaty mają problem ze
współbieżnością, który jest związany z dzieleniem stanu, w porównaniu
np. z programowaniem funkcyjnym, gdzie się dzielonego stanu nie używa.

Również "modelowy" OO, chociaż opiera się na dzieleniu stanu, ma
rozwiązanie tego problemu, ale nie ma popularnych implementacji, bo taki
OO jest "too slow".

>> Natomiast w kwestii dynamicznego typowania nie ma takiego
>> konsensusu.
>
> To zależy, kogo zapytasz. Systemów lotniczych w Pythonie nie
> widziałem i zdaje się, że w ogóle nie miałyby szans ze względu na
> wymagania formalne. To jest dla mnie konsensus.

Przecież Python nie nadaje się do systemów czasu rzeczywistego i w ogóle
słabo do systemów embedded (wymaga interpretera i sporego wsparcia
systemu operacyjnego).

> O, przypadkiem dobre słowo - formalne. Metody formalne raczej
> polegają na statyczności systemu typów. Skądinąd mają też związek z
> niezawodnością. To też przyczynia się do tego konsensusu.

Nie znam się na tym prawdę mówiąc. Wiem, że są jakieś metody formalnej
weryfikacji programów w LISPie czy w Prologu (oba dyanmicznie typowane),
ale w praktyce nie wiem jak to wygląda - nie spotkałem się z tym, żeby
ktoś stosował metody formalne w komercyjnym oprogramowaniu.

W skrócie - nie mam nic do powiedzenia w kwestii czego używać do
tworzenia oprogramowania w przypadku, kiedy używa się metod formalnych,
ale czego by się nie używało, nie przyjmę tego za automatyczny dowód na
to, że te same technologie dadzą lepszą niezawodność również w sytuacji,
gdzie metod formalnych się nie używa.

>> Systemów w tych językach powstało i nadal powstaje sporo i nie ma
>> przekonywaujących dowodów empirycznych na to, że mają znacząco
>> większe problemy z niezawodnością niż systemy pisane w C++ czy w
>> Javie.
>
> Kto decyduje, czy dowody są przekonywujące?

Konsensus decyduje. Przekonywujące znaczy przekonują wystarczająco wielu
ludzi, żeby powstał konsensus.

do góry

W dniu czwartek, 14 lutego 2013 09:18:03 UTC+1 użytkownik Andrzej Jarzabek napisał:

> OO w realizacji takiej jak Java/C++ ma dokładnie takie same problemy ze
> współbieżnością co programowanie strukturalne/proceduralne, którego jest
> prostym rozwinięciem.

Ale to nie jest wina OO, tylko tego rozwinięcia.
Ja nadal nie widzę w OO niczego, co by miało mieć problem ze współbieżnością.

> Wszystkie te paradygmaty mają problem ze
> współbieżnością, który jest związany z dzieleniem stanu,

Ja nie widzę niczego w OO, co zmuszałoby mnie do dzielenia stanu a tam, gdzie
chciałbym stan dzielić, będę musiał to zrobić niezależnie od paradygmatu.

> Również "modelowy" OO, chociaż opiera się na dzieleniu stanu,

W którym miejscu się opiera?

> Przecież Python nie nadaje się do systemów czasu rzeczywistego i w ogóle
> słabo do systemów embedded (wymaga interpretera i sporego wsparcia
> systemu operacyjnego).

A jakiś dynamiczny język nie wymaga?

> W skrócie - nie mam nic do powiedzenia w kwestii czego używać do
> tworzenia oprogramowania w przypadku, kiedy używa się metod formalnych,
> ale czego by się nie używało, nie przyjmę tego za automatyczny dowód na
> to, że te same technologie dadzą lepszą niezawodność również w sytuacji,
> gdzie metod formalnych się nie używa.

Dowód polega na tym, że nie da się powiedzieć, w którym momencie już używa się metod
formalnych a w którym się nie używa. Np. ja używam metod formalnych kompilując
program w C++ - kompilator sprawdza tyle ile umie i mówi mi, co zrobiłem źle - mogę
go nawet poprosić, żeby tylko sprawdzał i nawet nie generował kodu. Granica jest tu
płynna i ta płynność objawia się też dostępnością narzędzi, które oferują różne
poziomy weryfikacji.
Czyli język statyczny pozwala mi używać metod formalnych na różnych poziomach,
zależnie od moich potrzeb i umiejętności - w szczególności mogę dołożyć nowe
narzędzie w trakcie trwania projektu.
Oczywiście różne języki różnie to wspierają, ale statyczne wypadają tu znacznie
lepiej, niż dynamiczne.

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

do góry

jak juz wspomnielem ale jeszcze mnie naszlo by sie
chwile nad tym pozastanawiac programowanie bez typow
(czyli z wewnetrznie zarzadzanymi ukrytymi typami)
moze byc znaczym krokiem w kierunku wysokopoziomowosci
wlasnie ze wzgledu na to ze w tym modelu nie
trzeba zawracac sobie glowy typami tyko programowac
po kontencie - a to samo z siebie to jest znaczny skok

mozna by np pisac os takiego


pliki = reach files: "d:\muza"
nagrania sundgarden = chose "soundgarden, audio, video" from pliki
tume = count play time: nagrania soundgarden
window = create smal window: time

przyklad troche beznadziejny ale mz moze czesciowo ilustrowac
taki paradygmat dane moga byc dowolnymi kolekcjami czegokolwiek
zarzadzanymi wewnetrznie, wogole nie mysli sie o typach, api jest
napisane tak by obslugiwalo cokolwiek

pewien rodzaj roboty jaki tu trzeba wykonac to konwencje
potrzebne do tego by wewnetrznie obslugiwac typy bo to
trzebaby robic jakims spojnym i chyba dosyc oficjalnym
systemem otagowania czy cos takiego

do góry

On 13/02/2013 09:29, Maciej Sobczak wrote:
> W dniu środa, 13 lutego 2013 06:31:15 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>> Większe problemy masz
>> takie:
>>
>> * używasz dwóch konstrukcji językowych (struct/class lub hashtable) do
>> tego samego celu
>
> To nie jest ten sam cel - obiekty istniejące na granicy modułów (podobnie na
> granicy z DB) to inne cele i w tych miejscach jestem gotowy na inne konwencje.

To, że cośtam jest na granicy to jest szczegół implementacyjny. W
funkcji liczącej bezwistność flafulca obchodzi cię czym jest flafulec,
jakie ma właściwości potrzebne do wyliczenia jego bezwistności i jak się
z tych właściwości bezwistność wylicza, a nie czy obiekt reprezentujący
flafulca przyszedł z przeglądarki, bazy danych, czy został wygenerowany
przez kod C++ zlinkowany z funkcją liczącą bezwistność.

>>>> 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.
>>
>>> Na moim komputerze kompilator pokaże, gdzie nastąpiła niezgodność.
>>
>> Naprawdę? Jak nowa wersja execa spróbuje załadować starą DLL-kę?
>
> Nie wierzę, że sobie takiego gola strzelasz.
> DLL-ki nie są częścią C++ a ich wsparcie to trick ze strony systemu
> operacyjnego. Jeżeli wychodzisz poza język po to, żeby nie korzystać
> z jego zalet, to nie miej pretensji, że coś nie działa.

DLL-ki to tylko trick, który ułatwia życie. Częścią definicji języka
(jego modelu kompilacji) są object files. Rozwiązanie, w którym ja
dostarczam program korzystający z funkcji w postaci zestawu object
files, a kto inny dostarcza tych funkcji w postaci object files, a
klient sobie to wszystko linkuje statycznie linkerem przed uruchomieniem
ma dokładnie ten sam problem, tylko że dodatkowo jest mniej wygodne.

Problem jest taki, że coupling między skompilowanymi object files jest
tight - muszą być skompilowanymi z tymi samymi definicjami typów, bo
inaczej nie ma żadnych gwarancji na to, że będzie działało.

> DLL-ki to właśnie metoda na dynamiczność w programie. Czy sugerujesz,
> że języki statyczne są do dupy, bo jak się je omija i używa dynamicznych
> tricków, to nie działają dobrze?
> No, nie działają.

No więc sam masz przykład na to, że w pewnych realnych sytuacjach
spotykanych w dużych systemach taki np. C++ po prostu nie działa dobrze,
bo musisz "wychodzić poza język" i "używać dynamicznych tricków".

>> W języku statycznie typowanym możesz mieć nawet:
>> TreeSet s = new TreeSet();
>> s.add(new CannotCompare());
>> [...]
>
> To nie jest język statycznie typowany, nawet jeśli tak ma napisane na pudełku.

Niby dlaczego? Biorąc pod uwagę całą historię języków statycznie
typowanych, i w szczególności języków statycznie typowanych ze wsparciem
OO w popularnym rozumieniu (czyli wywodzący się z Simuli - klasy,
dziedziczenie), to jest to możliwe chyba w każdym z nich - z całą
pewnością zarówno w C++ jak i w Object Pascalu - pomijając nawet typ
void* i jego odpowiednik w Pascalu, to wystarczy zdefiniować klasę
bazową Object czy inne Comparable i już masz dokładnie ten sam problem.

>>> W tym przykładzie Java zachowuje się dokładnie jak skryptowy język
>>> dynamiczny.
>>
>> int i=3;
>> i=5;
>>
>> W tym momencie C++ zachowuje się dokładnie jak skryptowy język
>> dynamiczny. Zatem jest językiem dynamicznym.
>
> Nie. Nie mógłbyś zrobić i="x"; Zatem słaby argument.

Tak samo dobry jak twój, przecież w twoim programie też nie można zrobić
TreeSet<CannotCompare> s = "x";

>> Dodatkowo od dynamicznego języka wymagałbym
>
> Ale ja nie twierdzę, że Java ma wszystkie cechy takich języków.
> Natomiast od języka statycznego wymagam, żeby kod, który nie może się
> poprawnie wykonać ze względu na *nieistnienie jakiejś funkcji*, która
> na pewno będzie zawołana, się nie kompilował. Java tego wymagania nie spełnia.

No to proszę bardzo, przykład w C++:

struct A
{
};

struct B
{
void foo();
};

bar(A& b)
{
B& b = dynamic_cast<B&> a;
b.foo();
}

int main()
{
A a;
bar(a);
}

Skompiluje się? Jeśli uważasz, że dynamic_cast jest dynamicznym trickiem
i dlatego działa źle, to zamień sobie na static_cast i zastanów się, czy
na pewno będzie lepiej.

do góry