On Dec 16, 9:38 am, Maciej Sobczak <s...@g...com> wrote:
>
> > > Te języki nigdy nie zdobędą mainstream'u, bo nie odzwierciedlają ani
> > > tego jak działa komputer, ani tego, jak myśli człowiek. Będą sobie
>
> > Żaden język programowania nie odzwierciedla tego, jak myśli człowiek.
>
> Zgadza się. Ale wtedy dobrze by było, żeby był chociaż przyjazdy dla
> maszyny. Jeśli nie jest przyjazny ani dla maszyny ani dla człowieka,
> to jego rola będzie co najwyżej eksploracyjna. Jakiś mniej lub
> bardziej spektakularny sukces tu lub tam, ale na mainstream nie ma
> szans.

Nie zgadzam się. SQL jest mainstreamowy na ten przykład.

> > > Skoro nie udało
> > > się to przez ostatnie 50 lat, to nie widzę, co nagle miałoby się tu
> > > zmienić.
>
> > Rozpowszechnienie architektur równoległych.
>
> No i?
>
> Taka historyjka:
>
> Jakiś czas temu Sun zorganizował konkurs na najszybszy program w
> jakimś kryptograficznym temacie. Jako nagrodę rzeczową zaoferowali
> swój serwer T1000. Czyli nie jakiś tam hipisowski benchmark, ale
> prawdziwe zawody. Trochę musieli się zaczerwienić, bo zwycięzcą nie
> został żaden z programów napisanych w ich własnych technologiach
> (trochę wstyd, nie?) ani żaden funkcjonalny, tylko program w języku
> 100% imperatywnym:
>
> http://www.adaic.org/news/perfcont.html
>
> Pytanie: dlaczego?
>
> Nie, poważnie pytam: *dlaczego*?

Poważnie odpowiem: bo to jest mały, wyizolowany, dobrze znany problem,
nad którego optymalizacją masa ludzi ślęczy latami.

Bo w tym przypadku dłubane rozwiązanie było na bardzo konkretna
maszynę z konkretnym systemem operacyjnym, gdzie wszystkie
charakterystyki są dokładnie znane, więc można bardzo dokładnie zadać
pytanie, gdzie przy znanej ilości wątków hardware-owych, znanych co do
instrukcji maszynowej kawałkach kodu, znanych czasach wykonania tego
kodu, znanych wielkościach cache, znanych kosztach tworzenia,
przełączania itd. wątków, znanych kosztach wszelkich możliwych technik
synchronizacji, mając do dyspozycji zespół matermatyków i czas na
skonstuowanie modelu zagadnienia i policzenia tego modelu na dość
mocnym komputerze - jak najlepiej zrónoleglić ten program.

W przypadku znacznie większych programów komercyjnych, zawierających
tysiące drobnych problemów, nie tak trudnych w sensie obliczeniowym
rzecz jasna, ale potencjalnie o podobnej trudności jeśli chodzi o
optymalizację na architekturę równoległą, takiego dłubania nie da się
zastosować. Pewnym ideałem byłoby zadanie problemu w ten sposób, żeby
kompilator sam mógł wiedzieć, które kawałki kodu można zrównoleglić i
znając charakterystyki docelowej maszyny zdecydował kiedy
zrównoleglać, a kiedy nie, kiedy opłaca się powielać, a kiedy
synchronizować itd. Oczywiście kompilator często nie znajdzie
rozwiązania optymalnego, ale np. w przypadku maszyny z setkami wątków
hardware-owych, wykonywaniem poleceń maszynowych poza kolejnością,
operacjami atomowymi, synchronizacją cache itd. kompilator jest
potencjalnie w stanie znaleźć rozwiązanie wystarczająco dobre, gdy
programistom rozpisującym problem na wątki, muteksy, kolejki lock-free
itd. zajęłoby to wiele tygodni, którą to pracę trzebaby znowu
powtórzyć jak się okaże, że trzeba ten program zaimplementowac ina
inny sprzęt.

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.

> Disclaimer: nie chodzi mi o udowadnianie wyższości Ady nad
> czymkolwiek, tylko na pokazaniu, że języki funkcjonalne nie wnoszą
> niczego niezastąpionego w temacie wspóbieżności. Wydajne programy
> współbieżne można pisać bez nich a powyższa historyjka pokazuje, że
> może nawet bez nich dopiero jest wydajnie.

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.

> Takie przykładowo współbieżne systemy bazodanowe istniały od tzw.
> "zawsze", więc to nie jest tak, żę języki funkcjonalne otwierają
> jakieś nowe nieznane wcześniej możliwości.

No więc SQL jest właśnie świetnym przykładem języka o paradygmacie
innego, niż imperatywny, który się przyjął w mainstreamie, i który się
znakomicie zrównolegla właśnie dzięki temu, że nie jest imperatywny.
Ale oczywiście języki funkcjonalne otwierają jakieś nowe możliwości
kompletnie niemożliwe dla SQL.

> > Nie zdarzyło mi się pracować przy żadnym projekcie, gdzie używano by
> > języka funkcyjnego
>
> Dlaczego? Przecież one istnieją od 50 lat. Istniały długo zanim
> wynaleziono Javę.

Bo zasadnicza część mojej pracy zawodowej przypadała na okres
darmowego lunchu. Kilka lat temu darmowy lunch się skończył, ale
branża ma swoją bezwładność. Np. w ostatnich dwóch projektach, w
których pracowałem, ciągłość codebase jest od lat 90-tych. Nawet tam,
gdzie projekty były greenfieldowe, pracowali nad nimi ludzie, którzy
już wcześniej pracowali w danej firmie i znali takie a nie inne
technologie.

Kolejna sprawa jest taka, że generalnie stare języki funkcyjne nie
były tworzone z myślą o masowym zrównolegleniu. Np. Lisp, o którym jak
sądzę myślisz, ani nie jest językiem czysto funkcyjnym, ani też nie
został zaprojektowany pod kątem optymalizacji.

Być może powodem jest też to, że nie znam żadnego języka funkcyjnego w
wystarczająco dobrym stopniu, więc jeśli ktoś szuka programistów w
Haskellu czy F#, to mnie raczej nie zatrudni.

> > Są rzeczy, do których dopuszcza
> > management, o których się nie śniło waszym filozofom.
>
> Fajny ten Wasz management. Naprawdę. :-)

To jest doświadczenie z kilku różnych managementów, plus w różny
sposób zdobywana wiedza jakie się stosuje rozwiązania również tam,
gdzie osobiście nie pracowałem. Na ile się orientuję, nie jest to
jakieś bardzo niezwykłe.