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.