W dniu piątek, 15 lutego 2013 12:29:02 UTC+1 użytkownik Andrzej Jarzabek napisał:

> Nadal będziesz miał ten sam problem - jeśli twoja baza danych
> przechowuje skompilowane jednostki (instantiation units w terminologii
> standardu) pochodzące z różnych translacji z różnymi źródłowymi
> definicjami typów danych, to nie ma żadnej gwarancji zadziałania.

Nie ma, bo standard jest niedospecyfikownany. Napisałem już: nie musi tak być i np. w
Adzie nie jest.
Natomiast nie rozumiem, co to daje w dyskusji o językach dynamicznych. One tym
bardziej nie działają, bo w ogóle nie mają mechanizmów zapewniania spójności. C++
chociaż próbuje takie mechanizmy mieć i nawet całkiem dobrze można się nimi
posługiwać. Ada próbuje lepiej i można się lepiej posługiwać. Języki dynamiczne w
ogóle nie próbują - i to jest ich ficzer?

> Badziewnośc realnie dostępnych narzędzi to bardzo dobry powód, żeby w
> praktyce wybrać inny język, który ma mniej badziewne narzędzia.

Np. Ada?

Bo język, który planowo w ogóle nie ma takich narzędzi, nie liczy się w kategorii "ma
mniej badziewne narzędzia".

> Na
> Adzie się nie znam, ale czy nie jest przypadkiem tak, że do wielu
> aplikacji biznesowych byłaby słabym wyborem ze względu na brak
> bibliotek i narzędzi właśnie?

Ja znam ludzi, którzy tego używają w systemach bankowych, więc może nie jest tak źle.

> Ale jeśli przez to, że wybiorę inny język może nie być zepsute, to po
> co w ogóle mam naprawiać?

Co nie jest zepsute? ClassDefNotFound i NoSuchFunction nie są zepsute?

> > I bardzo dobrze. To jest zaleta statycznego systemu.
>
> Że się program wywali?

Że się nie skompiluje przy normalnym wykorzystaniu.

> > Jeżeli dynamiczne techniki nie działają a statyczne działają, to jaki z tego
> > wniosek w kontekście tytułu tego wątku?
>
> Skoro programy komputerowe często nie działają, to może zamiast
> komputerów lepiej używać znacznie bardziej niezawodnych pięściaków?

Możesz tak zrobić. Ja natomiast spróbuję wybrać taki język, który działa lepiej, niż
gorzej.

> Akurat rozmawiamy o tym, czy Java jest językiem statycznie czy
> dynamicznie typowanym. Umówmy sie może w takim razie, że konstrukcja
> pozwalająca na niebezpieczne rzutowania nie dyskwalifikuje języka z
> bycia statycznie typowanym.

Dobrze, umówmy się tak.

1. Pytanie było o wybór między językami statycznymi a dynamicznymi.
2. Zauważyłeś, że jak się używa dynamicznych ficzerów, to program może nie działać.

Mój wniosek z tej dyskusji (jak też przed nią) jest taki, że im mniej dynamicznych
elementów w programie, tym łatwiej o poprawny program.

> > Tak. Jeżeli dynamiczne ficzery prowadzą do programów, które nie działają,
> > to est to argument przeciwko dynamicznym ficzerom.
>
> Każdy język, który jest Turing-complete ma dynamiczne ficzery, które
> nie działają.

Więc ich nie używajmy.
Ja napisałem parę programów bez używania tych ficzerów.

Czy może chcesz napisać, że im bardziej jakiś języki jest dynamiczny, tym bardziej
jest "Turing-complete"? Coś jakby synonim na "cool" dla geeków?

> > UB. Język wyraźnie mówi, że nie wolno tego static cast zrobić.
> > Kompilator nie nadąża, więc może język jest za mało statyczny?
>
> Jak napisałem, chodziło o sytuację, kiedy B dziedziczy po A.

A ja nadal będę pisał, że to jest UB i standard to wyraźnie określa. Nie wolno
takiego rzutu zrobić, nawet jeśli język nie określa tego jako błąd statyczny. Coś jak
dzielenie przez 0.

I wniosek mam konsekwentny: weźmy język, który będzie jeszcze bardziej statyczny. Bo
język, który będzie jeszcze bardziej dynamiczny sprawi nam jeszcze więcej problemów.


W tym momencie muszę przeprosić: wyjeżdżam na parę dni i nie będę miał dostępu do
sieci. Nie będę mógł więc kontynuować tej dyskusji, chociaż jestem pewny, że ona
powróci, bo na tej grupie jest zjawiskiem powtarzalnym.

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