On Dec 15, 5:24 pm, A.L. <l...@a...com> wrote:

> Koledze sei ciagle zdaje ze profesjonalnosc programisty mierzy sie
> iloscia certyfikatow z C++?

No rozczarowujesz mnie. Już po jednym pingpongu skończyły Ci się
argumenty? A miałem nadzieję na jakąś dyskusję.

> No a ostatnia milosc Kolegi, Ada , tez jakos mainstreamowa nie jest.
> Co nie wyklucza ze jest uzyteczna.

Oczywiście. Nie podważam użyteczności języków funkcjonalnych, tylko
ich szanse na mainstream.
Napisałeś:

> Neidlugo nei bedzie mozna znalezc pracy jak sie tego
> nie bedzie znalo :)

To podważam.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Dec 15, 5:46 pm, Andrzej Jarzabek <a...@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.

Chociaż, może nie doceniam siły trendu.

> > 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*?

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.

I dlatego "rozpowszechnienie architektur równoległych" nie będzie
nośnikiem dla ich większej popularności. Tzn. w jakimś stopniu będzie,
bo większość ludzi i tak nie rozumie o co chodzi z tą współbieżnością,
więc ludzie chętnie chwycą się każdego buzzworda, który się napatoczy.
W tym sezonie faktycznie buzzwordem jest "functional programming", ale
to zjawisko też ma swój limit.

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.

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

> Są rzeczy, do których dopuszcza
> management, o których się nie śniło waszym filozofom.

Fajny ten Wasz management. Naprawdę. :-)

--
Maciej Sobczak * http://www.inspirel.com

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Maciej Sobczak"
>> Ż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.

Assembler? To już chyba było.

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

"Funkcyjny"!

>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

Oczywiście. Przecież wszystko i tak docelowo jest tłumaczone na kod
maszynowy.

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

Funkcjonalne języki, w przeciwieństwie do języków niefunkcjonalnych
(Brainf*ck anyone?) dają jednak jakieś możliwości.


--
\------------------------/
| K...@e...eu.org |
| http://epsilon.eu.org/ |
/------------------------\

do góry

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.

do góry

On Dec 16, 1:37 am, Mariusz Marszałkowski <m...@g...com> wrote:
> On 16 Gru, 02:02, Andrzej Jarzabek <a...@g...com> wrote:> Można
zacząć od przykładu banalnie prostego. Mamy coś, co powiedzmy
> > można zapisać tak:
> > a = A()
> > b = B()
> > c = C(a,b)
>
> > Clou jest takie, że A i B są niezależne i można by je wykonać
> > równolegle. Oczywiście rozwiązanie tego na wątkach jeest banalne, ale
> > jeśli w całym programie są dziesiątki tysięcy takich scenariuszy, gdzie
> > za A i B można podstawić różne możliwe obliczenia, poczynając od
> > podstawienia stałej znanej w czasie kompilacji, a kończąc na jakiejś
> > skomplikowanej i czasochłonnej operacji, to lądujemy z tysiącami pytań
> > czy lepiej A i B obliczać w wątkach i synchronizować, czy epiej wykonać
> > po kolei w jednym wątku. Odpowiedź zależy od kosztów operacji A i B,
> > oraz kosztów tworzenia wątku, synchronizacji itd.
>
> Racja.
>
> > We współczesnych
> > archotekturach i systemach operacyjnych ciężko, żeby programista mógł
> > samodzielnie określić tę granicę, kompilator zaś może mieć zakodowaną
> > wiedzą o czasowych charakterystykach procesora i systemu operacyjnego,
> > dane z profilera na temat czasu trwania operacji zależnych od danych, a
> > nawet korzystać z dobrodziejstw technik typu JIT, żeby podejmować te
> > decyzje na bieżąco w trakcie działania programu.
>
> To chyba jest niemozliwe, zaden kompilator ani JIT nie moze
> przewidziec
> kosztow wykonania bardziej skomplikowanych kawalkow kodu - inne dane
> to inny czas.

Teoretycznie to prawda, ale w praktyce jednak dla wielu programów za
czasem wyłaniają się statystyczne prawidłowości, których można z
powodzeniem używać do predykcji.

> Poza tym jak bylby narzut czasu na pomiary i
> przeprowadzanie
> takiej statysytki?

Jakiś tam by był, ale też zauważ, że JIT może zauwazyć, że jakiś
licznik zlicza się zbyt często i w związku z tym należy go usunąć. W
ogóle narzut chyba nie musi być szczególnie duży, jeśli każdy wątek
sporządza swój pomiar, to nie ma dzielenia cache i synchronizacji poza
momentami zbierania tych statystyk (które z kolei dokładnie mozna
kontrolować, jak często jest wykonywane).

do góry

On Dec 16, 1:10 am, A.L. <l...@a...com> wrote:
> On Thu, 16 Dec 2010 01:02:07 +0000, Andrzej Jarzabek
>
> >archotekturach i systemach operacyjnych ci ko, eby programista m g
> >samodzielnie okre li t granic , kompilator za mo e mie zakodowan
> >wiedz o czasowych charakterystykach procesora i systemu operacyjnego,
> >dane z profilera na temat czasu trwania operacji zale nych od danych, a
> >nawet korzysta z dobrodziejstw technik typu JIT, eby podejmowa te
> >decyzje na bie co w trakcie dzia ania programu.
>
> Panie Kolego, Pan Kolega opowiana nonsensy. Ja mam problem jak jak
> zrownoleglic aplikacje ktora ma pol miliona linii w jakims jezyku, na

Panie Kolego, czasem warto sobie zdać sprawę, że na Pańskich
problemach świat się nie kończy.

> przykald w Javie  a nie "korzystac z dobrodzeijstw XT". Kompilator
> moze pomoc w roznych rzeczach ale w tym to na pewno nie.

Chodziło mi dokładnie o to, że Pański kompilator nie pomoże właśnie
dlatego, że jest to kompilator "na przykład Javy", a "na przykład
Java" jest językiem imperatywnym.

do góry

On Thu, 16 Dec 2010 01:38:12 -0800 (PST), Maciej Sobczak
<s...@g...com> wrote:

>
>
>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*?
>

No i to argument na co jest? Za Ada najlepsza?...

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

Nie wiadomo, poki co. Jezzyk Erlang, jak najbardziej funkcjonalny,
stosowany jest w przemysle, i owszem. telekomunikacyjnym

A jak idzie o jezyk Ada i jego wsparcie dla wspolbieznosci, to keidys
zdarzylo mi sie wspolpracowac z firma 8888 gdzie uzywano Ady, ale tak
zwanego "bezpiecznego podzbioru". Ten podzbior wykluczal Adowe "taski"
ze wzgledu na niepzrewidywalnosc ich wykonywania pod wzgledem
czasowym.

>I dlatego "rozpowszechnienie architektur równoległych" nie będzie
>nośnikiem dla ich większej popularności. Tzn. w jakimś stopniu będzie,
>bo większość ludzi i tak nie rozumie o co chodzi z tą współbieżnością,
>więc ludzie chętnie chwycą się każdego buzzworda, który się napatoczy.
>W tym sezonie faktycznie buzzwordem jest "functional programming", ale
>to zjawisko też ma swój limit.
>

Zgadziam sie ze wiekszosc ludzi nei rozumie o co chodzi ze
wspolbieznoscia, co pokazuje chociazby ten watek, ale wynuraenia
Kolegi przypominaja mi wynurzenia pewnego fizyka z koncza 19 wieku
ktory twierdzil ze "wszystko w fizyce juz odkryto i pozostaje praca
nad szczegolami". czy tez wynurzenia szefa amerykanskiego Urzedu
Patentowego z tego okresu ktory twierdzil ze "wiecej wynalazkow juz
nie bedzie".

Gdy procesory beda mialy 64 jadra, nie da sie ich programwoac w C++
czy Jave. Ani nawet w Adzie. Potzrebny jest nowy paradygmat. Nat tym
paradygmatem ludzie pracuja. Czy to beda jezyki funkcyjne czy nie, nie
wiadomo. Na razie pracuja nad funkcyjnymi, i uwazam ze ktos nei bedacy
"komputerowym spawaczem" powinien sie im przygladac.

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

Ales Kolego, nikt i nigdzie nie mowi ze jezyki funkcyjne maja byc
zastosowane w bazach danych

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

Autor Haskela kiedys popelnil papier "How industry is using functional
languages and why not".

http://homepages.inf.ed.ac.uk/wadler/papers/how-and-
why/how-and-why.pdf

Od tego czasu troche sie zminilo, i wiele powodow dla ktorych "why
not" ustapilo. Jak idzie o zastosowania haskela, to lista jest tutaj:

http://www.haskell.org/haskellwiki/Haskell_in_indust
ry

Troche dluzsza niz ta od Ady

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

Rozumiem o czym czlowiek pisze, i nie wydaje mi sie zeby managemennt
byl "fajny" w negatywnym znaczeniu tego slowa.

Zas wracajac do meritum: Jakie jest doswiadczenie Kolego z jezykamu
funkcyjnymi ze wydaje takie stanowcze opinie?... Czy to na podstawie
"hands on" czy tez teoretycznej wszechwiedzy?...

A.L.

do góry

On Dec 15, 5:38 pm, A.L. <l...@a...com> wrote:
> On Wed, 15 Dec 2010 08:46:37 -0800 (PST), Andrzej Jarzabek
>
> <a...@g...com> wrote:
> > aden j zyk programowania nie odzwierciedla tego, jak my li cz owiek.
> >Ci najwy ej cz owiek mo e si nauczy my le tak, eby odzwierciedla
> >to, jak dzia a jaki j zyk programowania.
>
> Owszem. Jak czlowiek mysli - dokladnie nei wiadomo.
>
> Istotne jednak jest co innego - aby jezyk byl "blisko" problemu, to
> znaczy aby pzrekladanie problemu na formalizm wspierany przez jezyk
> bylo jak najprostsze.

Nie tylko to jest istotne. Czasem w ogóle jest istotne nie tylko żeby
program robił to, co ma robić, ale też ile zasobów przy tym musi
zużyć.

W związku z tym nawet jeśli przełożenie danego problemu na ciąg
instrukcji wykonywanych jedna po drugiej jest proste, to przełożenie
tego samego problemu na n równoległych sekwencji instrukcji,
operujących na wspólnych danych, synchronizujących dostęp do tych
danych przez semafory, muteksy, monitory, spinlocki, atomowe operacje
acquire-release, read-modify-write itd. - już wcale nie jest takie
proste i intuicyjne.

do góry

On Thu, 16 Dec 2010 01:13:46 -0800 (PST), Maciej Sobczak
<s...@g...com> wrote:

>On Dec 15, 5:24 pm, A.L. <l...@a...com> wrote:
>
>> Koledze sei ciagle zdaje ze profesjonalnosc programisty mierzy sie
>> iloscia certyfikatow z C++?
>
>No rozczarowujesz mnie. Już po jednym pingpongu skończyły Ci się
>argumenty? A miałem nadzieję na jakąś dyskusję.
>
>> No a ostatnia milosc Kolegi, Ada , tez jakos mainstreamowa nie jest.
>> Co nie wyklucza ze jest uzyteczna.
>
>Oczywiście. Nie podważam użyteczności języków funkcjonalnych, tylko
>ich szanse na mainstream.
>Napisałeś:
>
>> Neidlugo nei bedzie mozna znalezc pracy jak sie tego
>> nie bedzie znalo :)
>
>To podważam.

OK. Moze za stanowczo powieziane. Moze sie okazac ze facio znajacy
jezyki funkcyjne bedzie bral 3 razy wiecej pieneidzy niz Joe Shmoe
programujacy w Javie. Co juz mialo miejsce gdy na fali byl Smalltalk,
i co ja mam przyjemnosc doseiadczac z logic programming i Prologiem.
Co i po czesci dotyczy osob znajacych Ade.

A.L.

do góry

On Dec 16, 1:07 am, A.L. <l...@a...com> wrote:
> On Thu, 16 Dec 2010 01:02:07 +0000, Andrzej Jarzabek
>
> <a...@g...com> wrote:
> >On 15/12/2010 23:03, A.L. wrote:
> >> No dobrze. Jak to takie proste, to proponuje zadanko:
>
> >> Dane sa sekcje krytyczne A, B, C, D, E, F
>
> >> Maja one nastepujace wlasiciwosci
>
> >> A ~ B (gdzie ~ nalezy czytac "wzajemnie sie wyklucza"
>
> >Ja bym w og le postawi spraw inaczej. To, co jest opisane to jest
> >starsznie niskopoziomowe i jednocze nie do abstrakcyjne.
>
> To nie jest ani niskopoziomowe ani abstarkcyjne. To jest
> wyabstrachowany model problemu rzeczywisctego do rozwizania ktorego
> "programista bez doktoratu" uzyl jednego semafora, za kazdym razem
> blokuajc wszystko jak leci.

Inna z kolei możliwość jest taka, że programista bez doktoratu użyje
wielu semaforów (czy czego tam) i program zrobi deadlocka.

do góry