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.