On 15/02/2013 15:46, Maciej Sobczak wrote:
> W dniu piątek, 15 lutego 2013 12:29:02 UTC+1 użytkownik Andrzej
> Jarzabek napisał:
>
>> 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.

Nie mam pojęcia jak jest naprawdę, ale niekoniecznie z tego, że takich
znasz, coś wynika. Może po prostu użytkownicy Ady są nadreprezentowani
wśród twoich znajomych? Ja mam jakiś przekrój czego sie używa w
instytucjach finansowych i firmach produkujących oprogramowanie dla
nich i wiem, czego się mniej więcej używa. Java, C++, C#, Python, Tcl,
nawet spotkałem się z F# i Fortranem, ale z Adą nigdy. Oczywiście nie
wykluczam, że gdzieśtam jakiś system napisany w Adzie jest, ale to też
nie wyklucza możliwości, że mimo wszystkich swoich zalet Ada jest złym
wyborem dla 99.99% zastosowań, gorszym np. od Pythona.

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

Nie jest zepsuty system który w takiej sytuacji po prostu działa tak,
jak powinien, mimo że jeden z jego komponentów został wymieniony bez
zmieniania pozostałych.

>>> I bardzo dobrze. To jest zaleta statycznego systemu.
>> Że się program wywali?
>
> Że się nie skompiluje przy normalnym wykorzystaniu.

Z mojej praktyki z C++ wynika, że korzystanie z bibliotek, które były
kompilowane oddzielnie od głównego programu, w tym dynamiczne
linkowanie, jest czymś całkowicie normalnym.

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

No ale pięściak działa jeszcze lepiej.

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

Program napisany w języku dynamicznym w takiej samej sytuacji może działać.

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

A ja napisałem program "Hello World", który działał. Tylko że nie radzę
nikomu, żeby zamiast pisać swoje programy, które czasem nie działają,
pisali Hello World, który zadziała na pewno.

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

Powinieneś wiedzieć, że Turing-complete się nie stopniuje.

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

Ale nie da się tego statycznie sprawdzić.

> Nie wolno takiego rzutu zrobić, nawet jeśli język nie określa tego
> jako błąd statyczny. Coś jak dzielenie przez 0.

No i luzik, przecież języki dynamiczne też mają różne sytuacje, gdzie
specyfikacja mówi, że operacja nie zadziała i np. rzuci wyjątkiem.

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

Lepiej wziąć język, w którym co prawda jakichś tam błędów unikniesz, ale
programu robiącego to, co ma robić też nie napiszesz?

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

Życzę miłego wyjazdu w takim razie, na pewno wątek będzie dalej wisiał
na serwerze jak wrócisz :)