Dnia Fri, 15 Feb 2013 00:08:08 +0000, Andrzej Jarzabek wyszeptal:

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

Dzięki za link na c2.com. Nigdy nie wpadłem wcześniej na taki pomysł,
żeby czytać tam o czymś takim podstawowym jak OO, a jednak warto.

Ja powiem:
> 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.

W tej dyskusji padło wiele ciekawych twierdzeń, m.in. o typach w Javie.
Główną różnicą pomiędzy definicjami teoretycznymi (Java: taki a taki
system typów) i "OO ma problemy z współbieżnością" a praktyką jest
dokładnie to, co opisane jest na c2.com: teoria języka to jedno, praktyka
używania języka to drugie. Po kolei.

Ani Java ani taki Go nic nie wnoszą do teorii języków programowania.
Nie taki jest ich cel. Mają zmienić praktykę. Ja nawet nie widzę
sensu w zastanawianiu się, czy Java ma statyczny silny system typów - ok,
może, nie dotyczy kolekcji, kto dzisiaj używa kolekcji? - bo liczy się
praktyka pisania w tym języku. Mówiąc "OO is too slow" nikt nie ma
na myśli faktycznie że OO is too slow, tylko że taki bywa argument
przeciwko OO - praktycznie pojawia się tylko wtedy, gdy liczą się
pojedyncze procenty wydajności. Znowu argument taki że "OO is too slow"
na podstawie Javy ma jedną wadę: to nie wina OO tylko Javy, która
wiele zasad łamie po to, żeby była użyteczna. Podobnie w Javie było
z współbieżnością: do czasu Memory Model (jsr-133 chyba) NIE DAŁÓ
SIĘ pisać programów współbieżnych w Javie, które używałyby większość
cech języka i mogły być poprawne. Jednak programy współbieżne w Javie
okazały się praktycznie istotne i zmienił się Memory Model - kolejna
zmiana złamanych zasad w Javie podyktowana praktyką. Praktyką,
która wskazała na to, że chociaż większość programistów nawet
nie słyszało o Memory Model a pisze w Javie, to jednocześnie są
tacy, którzy potrzebują rozwiązania podstawowych trywialnych problemów
ze współbieżnością, a język tego nie umożliwia.

OO ma problemy z współbieżnością w tym sensie, że problemy ze
współbieżnością istnieją w programach OO, plus kilka argumentów
o związkach pomiędzy współbieżnością a praktyką OO (na c2.com),
m.in. takim,
że stos ywołań w obiektach połączony z więcej niż jednym lockiem
bywa trudny do analizy. Taka jest praktyka OO (Java, C++), że
wielu programistów źle projektuje programy współbieżne. Natomiast
jest znacząca różnica pomiędzy "w X nie da się Y" i "praktycznie
w X często jest źle z Y". "OO powoduje problemy z współbieżnością"
= false, "Java przed memory model nie pozwalała pisać poprawnych
współbieżnych" = true (chyba że ktoś potrafił omijać problemy
starego modelu pamięci, albo akceptował sporadyczne błędy).

Wracając do cytatu o systemach i ich problemach ze współbieżnością
oraz do linka do c2.com: przyczyny problemów ze współbieżnością
są głównie kognitywne (na ArgumentsAgainstOop wymieniona jest
cała lista kognitywnych argumentów, m.in. to, że mapowanie domeny
na typy jest strukturą poznawczą z wstępnych książek, która
ułatwia zrozumienie OO, ale prawdziwa to ona nie jest poza
relacyjnym mapowaniem - a w OO pisze się wiele innych rzeczy też.
Jak ktoś zna kraj, gdzie rośnie sobie AVLTree, rozważę wycieczkę.
Chciałbym zobaczyć, jak to drzewko wygląda ;).

Problemy ze współbieżnością biorą się najczęściej stąd, że
programiści mają wyrobiony (w nature-vs-nurture byłoby to nurture)
mechanizm, że kod wykonuje się linijka po linijce. Dodatkowo
często brakuje po prostu wiedzy na ten temat. Stąd pojęcie
o tym że w drugiej linijce zmienna i może mieć wartość 1 LUB 2 bywa
trudny do ogarnięcia:
i = 1
print i # jak to: nie 1 ?!
... a tak bywa w programach współbieżnych, piszący kod lub
szukający błędu często tego nie widzi - z przyczyn kognitywnych,
konkretnie zwykłego przyzwyczajenia.

Wracając do dużych systemów i problemów ze współbieżnością:
po pierwsze się DA, po drugie jest to szukanie błędów takie jak
każde inne (inne techniki, zasada ta sama) - jeżeli program jest usiany
błędami, to faktycznie poprawienie "buga" (czyli sterty bugów
i złego projektu) zajmuje trochę czasu. Znalezie źródła zwykłego
pojedynczego problemu zajmuje z grubsza tyle co każdego innego.
Pisanie dużych systemów bez większych problemów ze współbieżnością
to też żadna kosmiczna technologia.

No to się rozpisałem. Mi się nóż otwiera w kieszeni czasami
jak słyszę dyskusję o typach w Javie czy takie demonizowanie
współbieżności, i to przy okazji całkiem rozsądnego cytatu ze strony,
gdzie analizuje się "czy i ewentualnie dlaczego". Ale nie przerywam
dyskusji.

--
Edek