On 16/12/2010 22:44, Maciej Sobczak wrote:
> On Dec 16, 12:40 pm, Andrzej Jarzabek<a...@g...com>
>
>> Nie zgadzam się. SQL jest mainstreamowy na ten przykład.
>
> Bo będąc 4GL jest bardziej zrozumiały dla człowieka (widziałem kiedyś

No więc nie jestem przekonany, czy jakiś bardziej złożony select jest
bardziej zrozumiały niż jego wersja imperatywna. Z całą pewnością jednak
się bardzo ładnie skaluje bez konieczności specyfikowania jakichkolwiek
elementów współbieżności - czy to wątków, locków, czy czego tam jeszcze
może używać.

>> W przypadku znacznie większych programów komercyjnych, [...]
>
> No właśnie - teraz pojawia się pytanie, czy języki funkcjonalne, ze
> swoją specyficzną idiomatyką są odpowiednie do takich systemów.

Pytasz, czy w tej chwili są, czy z zasady są? Z zasady nie widzę
powodów, żeby nie miały być, jeśli chodzi o tu i teraz, to powody
zapewne są, ale według mnie nie mają nic wspólnego z idiomatyką.

> Zauważ też, że obecnie w takich systemach współbieżność jest zwykle
> zarządzana nie przez programistę, tylko przez jakiś framework. Czy to
> centralny broker, czy to serwer aplikacyjny, czy jeszcze coś -
> wszystko jedno. To znaczy, że zarządzanie wielowątkowością, przydział
> zadań, itd. są robione niejawnie i poza głównym kodem. I bardzo
> dobrze, ale jednocześnie jest to cecha, którą niby chcemy uzyskać w
> nowych językach. Tylko że to żaden postęp, bo to już dawno jest.

Nie wiem, o jakich frameworkach mówisz. Jest jakiś framework, który
zrównolegli mi mój przykład z a, b i c?

>> Problem jest w tej chwili taki, i to jest druga połowa odpowiedzi na
>> Twoje pytanie, że ten język jeszcze nie istnieje. Ale pracuje się nad
>> tym i wiadomo, że takie wymagania znacznie łatwiej mozna spełnić
>> językiem funkcyjnym lub zbliżonym, niż językiem imperatywnym.
>
> Dlaczego?

Dlatego, że model imperatywny opiera się na tym, że specyfikujesz
kolejność wykonania operacji, które potencjalnie modyfikują stan
programu. Jeśli masz rzeczywistą zależność gdzie C zależy od A i B, ale
A i B nie zależą od siebie nawzajem, to zapisując ją w postaci
imperatywnego programu A, B, C gubisz informację, która pozwoliłaby
kompilatorowi zadecydować, że A i B mogą być wykonane równolegle.

> Hint: są języki imperatywne, które współbieżność mają wbudowaną w
> swoją konstrukcję. Pytanie jest o to, czego ciekawego nie można nimi
> uzyskać a co przyniosą nam nowe języki.

Patrz wyżej.

>> Wnoszą tyle, że można napisać jeden program i patrzeć jak się skaluje.
>> Imperatywnie i na jawnych wątkaach można teoretycznie zrobić tak samo
>> albo nawet lepiej, ale będzie to oznaczało kupę pracy programistów,
>> wielokrotne przepisywanie kodu, trudne do namierzenia bugi itd.
>
> To spory skok myślowy. Nie widzę powodu, dla którego miałoby tak być.
> Automatycznie skalujące się pule wątków to nawet w Javie są - a to
> jest język imperatywny.

Nie mówię o pulach wątków. Mówię o tym, że SQL-owy select bez problemów
skaluje się na praktycznie dowolną ilość wątków bez _żadnego_ wysiłku ze
strony programisty (piszącego tego selecta) aby uczynić go równoległym.
Dlatego właśnie, że nie jest imperatywny.