On 14/02/2013 09:22, Maciej Sobczak wrote:
> 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.

To rozwinięcie to właśnie OO (w popularnym znaczeniu). W kwestii czy coś
ma cechy przeszkadzające, czy nie ma, nie jest istotne, czyja to wina
ani czy co innego ma takie same problemy.

> Ja nadal nie widzę w OO niczego, co by miało mieć problem ze
> współbieżnością.

No przecież właśnie cały model, gdzie możesz mieć równolegle działający
kod który ma dostęp do tego samego zmiennego stanu jest tym problemem.
No chyba że powiesz, że w rzeczywistości w dużych systemach napisanych w
językach wspierających OO błędy polegające na data races, deadlocks,
livelocks i tym podobnych atrakcjach nie są poważnym problemem, bo
zdarzają się niezmiernie rzadko, a jak już się zdarzą, to są łatwe do
zdiagnozowania, znalezienia i poprawienia.

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

W asemblerze też nie ma niczego, co cię zmusza do popełniania błędów, po
prostu łatwo zrobić to przypadkowo. W momencie, kiedy masz w programie
współbieżność opartą na wątkach, to znalezienie w paradygmacie OO miejsc
gdzie dzielisz stan między wątkami jest w ogólnym przypadku nietrywialne.

W innych paradygmatach może być tak, że albo w ogóle nie możesz dzielić
stanu, albo masz stan wyizolowany w specjalnych konstrukcjach (powiedzmy
- monadach), i wtedy kompilator czy runtime na podstawie wiedzy czy
program się wykonuje współbieżnie i które funkcje odwołują się do
których monad może automatycznie dać locki na wszystkich operacjach na
owych monadach.

>> Również "modelowy" OO, chociaż opiera się na dzieleniu stanu,
>
> W którym miejscu się opiera?

W tym miejscu, że obiekty są z założenia "stateful", że klient obiektu
może dowiadywać się i modyfikować jego stan i że ten sam obiekt może
mieć wielu klientów.

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

Lisp i Prolog na pewno. Poza tym Lisp, nawet z interpreterem może
chodzić z powodzeniem na malutkim i słabiutkim komputerku i z
powodzeniem był wykorzystywany w robotyce i nawet w sondach kosmicznych.

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

Ach, przepraszam, myślałem, że masz na myśli to, co się powszechnie
nazywa metodami formalnymi. To, że nie można dokładnie powiedzieć, od
ilu włosów ktoś jest łysy, to nie znaczy, że łysym jest każdy.

Jeśli w całej dygresji o metodach formalnych chodziło o to, że w
językach ze statycznym systemem typów kompilator statycznie sprawdza
typy, to chyba powinieneś zgłosić się po jakąś nagrodę za najbardziej
zawiły i okrężny sposób na stwierdzenie oczywistej oczywistości.

> ta płynność objawia się też dostępnością narzędzi, które oferują
> różne poziomy weryfikacji.

Jak pisałem, nie znam się na tym i pewnie się mylę, ale normalnie np.
taki Lisp (czy jego podzbiory/dialekty) czy Prolog (czy jego warianty)
są znacznie łatwiejsze do analizowania faktycznymi metodami formalnymi
niż Java czy C++. Dostępność narzędzi prawodopodobnie jest faktycznie
większa dla Javy i C++, po prostu dlatego, że są bardziej popularne.

Przy czym oczywiście jest to znakomity argument - jeśli potrzebujesz
formalnej weryfikacji, to faktycznie może lepiej użyć nawet bardziej
błedogennych i trudniejszych w takiej weryfikacji języków Java i C++, po
prostu dlatego, że są do nich lepsze narzędzia, niż języków mniej
błędogennych, ale mniej popularnych i przez to z mniejszą dostępnością
takich narzędzi. Dotyczy to również statycznie typowanych języków
programowania, które nawet mogą mieć bardziej zaawansowane i bardziej
bezpieczne typowanie - jak Haskell czy ML - czy nawet Ada. Dodatkowo,
może to też oznaczać, że być może jeśli wymagasz formalnej weryfikacji,
to Java jest lepsza niż C++, bo do Javy jest więcej narzędzi do tego
(nie wiem, czy faktycznie jest więcej, ale załóżmy, że tak).

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

No właśnie czy nie jest tak, że uważana przez Ciebie za dynamiczną Java
wypada bardzo dobrze?

Poza tym jak mówię - nie wiem jak jest w systemach do sterowania
samolotami, ale poza tym nawet w biznesowych systemach obracających
dużymi pieniędzmi to, co się powszechnie nazywa metodami formalnymi
(czyli nie zwykłe static checkery czy kompilatory) stosuje się raczej
niezwykle rzadko - obiegowa opinia jest taka, że się nie opłaca. Tym
bardziej chyba dotyczy to dużych systemów - im większy system, tym
bardziej się nie opłaca. Tak więc przy wyborze języka dla powiedzmy
systemu bankowego czy serwisu webowego pytanie, czy dany język ma dużo
narzędzi do automatyzacji formalnego dowodzenia poprawności programu
jest na dalekim, bardzo dalekim miejscu.

Jeśli chodzi o prostsze narzędzia, jak kontrola poprawności typów w
kompilatorze, czy programy do statycznej analizy kodu, to nikt nie
przeczy, że mają one jakąś tam wartość. Czy ta wartość zawsze przeważy
zalety dynamicznych językó i koszta statycznego typowania. No i tak samo
jak przy metodach formalnych, powstaje pytanie, czy w takiej sytuacji
nie jest znowu najlepsza Java, bo ma najwięcej programów do statycznej
analizy.

do góry

Co do krytyki oop (troche spojrzałem na
ten artykul na stronie c2.com :/)
to ja moge wymienic dwa punkty :/

1. w programach nie ma potrzeby tworzenia i niszczenia w runtime (zwlaszcza
recznie:/)
wszeliakich malych encji - jest to nieco
bezsens, meczyc sie z tym

2. jeszcze wieksza masakra jest budowanie tej głupiej siatki widzialnosci przez
wskazniki
(na ktorej budowniu ja zreszta dosyc slabo
sie znam), (mz krótko mowiac jest ona nie potrzebna i jej budowanie to bezsens)

powiedzmy ze wezme za przyklad cos
co dobrze znam z zycia i praktyki,
tyle ze w c, nie wiem jak to kodowaloby
sie w oop : prosty protatyp gry

w c to wyglada tak ze mam pare modulow
z frameworka setup_okna, blitter, procedury_graficzne, z samej gry powiedzmy hud,
tablice mapy i kontener postaci
(i powiedzmy ze jeszcze jakas plansze z highscorechoc nie robiem jeszcze czegos
takiego)

wszystko jest statyczne, to co jest potrzeba
inicjalizowac jest inicjalizowane zwyklymi wywolaniami procedur (to czy ew nie
nalezalo
by zrobic cos w jezyku co pomagaloby w tej
inicjalizacji to ew troche odzielny problem)

szczerze mowiac nie mam wiekszego poojecia
ak to by mialo wygladac w wykonaniu obiektowym

mialbym robic

new window();
new blitter();
new drawsystem();

new hud();
new map();
new characters();

new highscore();

?

przy czym nie robic tego w przestrzeni
'globalnej' tylko w drzewku wywolan i
zakladac siatke przez ustawianie wskaznikow
(np w characters, map , hud i highscore
ustawic membersy na drawsystem?)

??
ktos moglby sie wypowiedziec, i powiedziec
jak wg niego ta siatka powinna wygladac
(najlepiej tak zebym zrozumial)


dla mnie tak czy owak nie ma to za bardzo sensu bo tak naprawde w grze takich modulow
obiektow jest wiecej zakladanie i pilnowane
tej siatki jest meczace itd

do góry

W dniu czwartek, 14 lutego 2013 23:57:25 UTC+1 użytkownik Andrzej Jarzabek napisał:

> DLL-ki to tylko trick, który ułatwia życie. Częścią definicji języka
> (jego modelu kompilacji) są object files.

Nie są. Np. C++ coś tam wspomina, że translation units mogą być translowane osobno i
potem zlinkowane, ale kompletnie niczego nie określa. Można sobie wyobrazić
implementację, która używa w tym celu bazy danych.

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

Nie musi mieć i np. w Adzie nie ma. To, że ma w C++ wynika z badziewności typowego
zestawu narzędzi, ale nie z języka.
DLL już całkowicie jest poza językiem. Jak Ci nie działa, to naprawiaj to tam, gdzie
jest zepsute, czyli nie w języku.

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

I bardzo dobrze. To jest zaleta statycznego systemu.

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

Jeżeli dynamiczne techniki nie działają a statyczne działają, to jaki z tego wniosek
w kontekście tytułu tego wątku?

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

OK, w takim razie nie dogadaliśmy się. Ty piszesz o tym, że nawet języki statyczne
dają narzędzia do strzelania sobie w stopę i to wiadomo.
Ja piszę o tym, że przynajmniej wiadomo, jaki jest zakres użycia tych niebezpiecznych
ficzerów: ja dynamiczność jest tylko tam, gdzie ja chcę ją mieć (w szczególności
nigdzie) a nie totalnie wszędzie, bez wyboru.

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

> B& b = dynamic_cast<B&> a;

> Skompiluje się?

Tak. Jeżeli dynamiczne ficzery prowadzą do programów, które nie działają, to est to
argument przeciwko dynamicznym ficzerom.

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

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?

Jeżeli jakiś ficzer prowadzi do programów, które nie działają, to jest to argument
przeciwko temu ficzerowi.
Nie rozumiem, jak język dynamiczny miałby poprawić poprawność w tym kontekście.

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

do góry

W dniu czwartek, 14 lutego 2013 23:57:25 UTC+1 użytkownik Andrzej Jarzabek napisał:

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

Przepraszam bardzo, za szybko dzisiaj odpisuję.
Nie skompiluje się.

Czy u Ciebie się kompiluje?

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

Ze static_cast też się nie skompiluje.

Czy u Ciebie się kompiluje?

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

do góry

Użytkownik "Maciej Sobczak" <s...@g...com> napisał:

> Przepraszam bardzo, za szybko dzisiaj odpisuję.
> Nie skompiluje się.

Skompiluje sie to:

struct A
{
};

struct B
{
void foo();
};

void bar(A& a)
{
B& b = (B&)a;
b.foo();
}

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

albo to:

struct A
{
virtual ~A() {}
};

struct B
{
void foo();
};

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

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

Co gorzej: rowniez sie wykona !
Nie zyczę nikomu rezultatow takiego wykonania.

Jak widac dzieki swej "scislej typowosci" i "doglebnej analizie typologicznej"
C++ siegnal zenitu. Zenitu smiesznosci.

AK

do góry

On Feb 15, 9:59 am, Maciej Sobczak <s...@g...com> wrote:
> W dniu czwartek, 14 lutego 2013 23:57:25 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
>
>
>
>
>
>
>
>
> > 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ę?
>
> Przepraszam bardzo, za szybko dzisiaj odpisuję.
> Nie skompiluje się.
>
> Czy u Ciebie się kompiluje?

przepraszam, miało być
struct B: A
[...]

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:

> przepraszam, miało być
> struct B: A

Nie musi byc.

PS: Sa chyba jeszcze dwie pomylki:
1. bar(A& b) => void bar(A& a)
2. dynamic_cast<B&> a; => dynamic_cast<B&>(a);

AK

do góry

On Feb 15, 9:37 am, Maciej Sobczak <s...@g...com> wrote:
> W dniu czwartek, 14 lutego 2013 23:57:25 UTC+1 użytkownik Andrzej Jarzabek napisał:
>
> > DLL-ki to tylko trick, który ułatwia życie. Częścią definicji języka
> > (jego modelu kompilacji) są object files.
>
> Nie są. Np. C++ coś tam wspomina, że translation units mogą być translowane osobno
> i potem zlinkowane, ale kompletnie niczego nie określa. Można sobie wyobrazić
> implementację, która używa w tym celu bazy danych.

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.

Poza tym w rzeczywistości decydując o wyborze języka do tworzenia
oprogramowania sensownie kierować się implementacjami istniejącymi, a
nie tymi, które można sobie wyobrazić. Chyba że działanie programu,
który tworzysz, też masz zamiar sobie tylko wyobrażać.

> > 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,
>
> Nie musi mieć i np. w Adzie nie ma. To, że ma w C++ wynika z badziewności
> typowego zestawu narzędzi, ale nie z języka.

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

> DLL już całkowicie jest poza językiem. Jak Ci nie działa, to naprawiaj to tam,
> gdzie jest zepsute, czyli nie w języku.

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

> > 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.
>
> I bardzo dobrze. To jest zaleta statycznego systemu.

Że się program wywali? Faktycznie, rewelacyjna zaleta.

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

> > Niby dlaczego? Biorąc pod uwagę całą historię języków statycznie
> > typowanych,
>
> OK, w takim razie nie dogadaliśmy się. Ty piszesz o tym, że nawet
> języki statyczne dają narzędzia do strzelania sobie w stopę i to wiadomo.
> Ja piszę o tym, że przynajmniej wiadomo, jaki jest zakres użycia tych
[...]

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.

> > No to proszę bardzo, przykład w C++:
> >      B& b = dynamic_cast<B&> a;
> > Skompiluje się?
>
> 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ą.

> > 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.
>
> 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. To jest
trywialny przypadek, więc może jakiś model checker by to wyłapał, ale
w ogólnym przypadku kompilator nie ma podstawy do stwierdzenia, czy za
referencją na A kryje się obiekt typu B, więc możnaby temu zapobiec
jedynie zabraniając downcastów w ogóle.

Zarówno Java, jak i C++, jak i wiele innych języków powszechnie
uważanych za statycznie typowane i obiektowe (czy powiedzmy
wspierające obiektowość) mają taką instytucję jak niebezpieczny
downcast.

do góry

W dniu piątek, 15 lutego 2013 09:20:25 UTC+1 użytkownik firr kenobi napisał:
> Co do krytyki oop (troche spojrzałem na
>
> ten artykul na stronie c2.com :/)
>
> to ja moge wymienic dwa punkty :/
>
>
>
> 1. w programach nie ma potrzeby tworzenia i niszczenia w runtime (zwlaszcza
recznie:/)
>
> wszeliakich malych encji - jest to nieco
>
> bezsens, meczyc sie z tym
>
>
>
> 2. jeszcze wieksza masakra jest budowanie tej głupiej siatki widzialnosci przez
wskazniki
>
> (na ktorej budowniu ja zreszta dosyc slabo
>
> sie znam), (mz krótko mowiac jest ona nie potrzebna i jej budowanie to bezsens)
>
>
>
> powiedzmy ze wezme za przyklad cos
>
> co dobrze znam z zycia i praktyki,
>
> tyle ze w c, nie wiem jak to kodowaloby
>
> sie w oop : prosty protatyp gry
>
>
>
> w c to wyglada tak ze mam pare modulow
>
> z frameworka setup_okna, blitter, procedury_graficzne, z samej gry powiedzmy hud,
tablice mapy i kontener postaci
>
> (i powiedzmy ze jeszcze jakas plansze z highscorechoc nie robiem jeszcze czegos
takiego)
>
>
>
> wszystko jest statyczne, to co jest potrzeba
>
> inicjalizowac jest inicjalizowane zwyklymi wywolaniami procedur (to czy ew nie
nalezalo
>
> by zrobic cos w jezyku co pomagaloby w tej
>
> inicjalizacji to ew troche odzielny problem)
>
>
>
> szczerze mowiac nie mam wiekszego poojecia
>
> ak to by mialo wygladac w wykonaniu obiektowym
>
>
>
> mialbym robic
>
>
>
> new window();
>
> new blitter();
>
> new drawsystem();
>
>
>
> new hud();
>
> new map();
>
> new characters();
>
>
>
> new highscore();
>
>
>


w paradygmacie modulowym to by bylo schematycznie np cos jak


loop
{
window

map
characters
hud

blitter

}


gdzie kazdy modul moze miec tylko jedna
metode wejsciową (run() ) tj jedna z tych
glownych, bo byloby tez ew troche
komunikacji miedzymodulowej (ale ta poboczna
komunikacja miedzymodulowa to bardziej tylko
czytania lub jakies podsettingsowania,
o tyle jeszcze przychodzi na mysl czy
dorobic jakies okreslenia przy naglowku
dostepu do modulu np read/write/call
(typu "module hud reaches characters (read)"
"module map reaches blitter (write)"
(jesli blitter zawiera backbuffer do ktorego
map tylko pisze a nie czyta ani odpala)
:/

> ?
>
>
>
> przy czym nie robic tego w przestrzeni
>
> 'globalnej' tylko w drzewku wywolan i
>
> zakladac siatke przez ustawianie wskaznikow
>
> (np w characters, map , hud i highscore
>
> ustawic membersy na drawsystem?)
>
>
>
> ??
>
> ktos moglby sie wypowiedziec, i powiedziec
>
> jak wg niego ta siatka powinna wygladac
>
> (najlepiej tak zebym zrozumial)
>
>
>
>
>
> dla mnie tak czy owak nie ma to za bardzo sensu bo tak naprawde w grze takich
modulow obiektow jest wiecej zakladanie i pilnowane
>
> tej siatki jest meczace itd

do góry

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

do góry