On 10/10/2011 19:03, Edek wrote:
>
> Zawsze chciałem spytać, a nie miałem okazji:
>
> czym się różni "kaszaniasty, trudny w utrzymaniu kod" od takiego,
> który taki nie jest?
>
> Ja może mam swój pogląd, ale jestem ciekawy, jak ktoś to zdefiniuje.

"Czym się różni" to niekoniecznie to samo, co definicja. Z definicji
różni się tym, że jest trudny w utrzymaniu, co powoduje wprowadzanie do
niego większej ilości błędów lub znacznie większy nakład pracy w celu
tych błędów uniknięcia.

do góry

Andrzej Jarzabek wrote:

>> > Nie zrozumia=B3e=B6. Poprzedni programista to ty, a nadbudowywa=E6
>> > mia=B3by kto=B6 inny.
>>
>> robota tego programisty zalezy od tego programisty, co do
>
> Czytasz to Wojtku Jaczewski? I rest my case.

"Profesora" w tym wątku akurat czytam, ale tylko dlatego że na nie
odpowiadasz. Zwykle pomijam jego wypowiedzi, bo wg mnie jest tam za niski
stosunek sygnału do szumu. Mam wątpliwości, czy profesor/fir/... pisze to
wszystko poważnie, czy po prostu z jakiegoś powodu pisanie jest dla niego
dobrą rozrywką, więc pisze cokolwiek.
Natomiast jedno, co z jego wypowiedzi w tym wątku zrozumiałem i z czym się w
100% zgadzam, to że ten sam człowiek może pisać poprawne programy na jedną
platformę, a niepoprawne na inną (bo nie ma w niej doświadczenia). Nie
wszystkie szczegóły z dokumentacji się od razu rzucają w oczy i na
platformie sobie nieznanej dużo łatwiej trafić w jakąś funkcjonalność, która
akurat zadziałała, ale był to przypadek, bo platforma wcale tego nie
gwarantuje.
Tu też nie bardzo widzę możliwość, aby przez rozmowę ocenić, który kandydat
jest bardziej uważny podczas zapoznawania się z dokumentacją.

do góry

On Oct 11, 12:44 pm, Wojciech Jaczewski <w...@o...pl> wrote:
> Andrzej Jarzabek wrote:
> >> > Nie zrozumia=B3e=B6. Poprzedni programista to ty, a nadbudowywa=E6
> >> > mia=B3by kto=B6 inny.
>
> >> robota tego programisty zalezy od tego programisty, co do
>
> > Czytasz to Wojtku Jaczewski? I rest my case.
>
> "Profesora" w tym wątku akurat czytam, ale tylko dlatego że na nie
> odpowiadasz.

Przepraszam, z zasady ignoruję, ale tutaj mi się ładnie podłożył jako
ilustracja siebie samego.

> Natomiast jedno, co z jego wypowiedzi w tym wątku zrozumiałem i z czym się w
> 100% zgadzam, to że ten sam człowiek może pisać poprawne programy na jedną
> platformę, a niepoprawne na inną (bo nie ma w niej doświadczenia). Nie

Według mnie znajomość API systemowego nie jest bardzo znacząca jeśli
chodzi o niezawodność i ogólną poprawność kodu.

Oczywiście w zależności od umiejętności i znajomości API można napisać
kod dobrej jakości, który zawiera błąd związany z nieprawidłowym
użyciem API, albo też napisać kaszaniasty kod używający API, który
akurat działa prawidłowo.

Tylko że jedną z praktyk pisania niezawodnego oprogramowania jest żeby
w większych projektach opakować systemowe API w coś bardziej
abstrakcyjnego, czy to bibliotekę in-house czy third-party. W takiej
sytuacji doświadczenie z API systemowego jest mało istotne, bo
większość programistów nie używa go bezpośrednio, a jak czasem zajdzie
potrzeba używać, to zwykle jest to jakiś strasznie egzotyczny
przypadek. Z kolei znajomości konkretnej biblioteki opakowującej API
pracodawca często nie zakłada.

W praktyce jeśli ktoś pracuje przy większym projekcie robionym
powiedzmy w C++ na Windows, to ilość błędów programistycznych przez
niego wprowadzanych będzie mocno zależna od tego jak dobrym jest
programistą w ogóle i jak dobrym jest programistą w C++, natomiast to,
jak dobrze zna WinAPI ma raczej minimalne znaczenie.

Natomiast jeśli czyjeś programy nie wywalają się na jednej platformie
a wywalają się na drugiej, bo taki profesor na przykład robi sobie
założenia co do tego, ile bitów ma int i nie widzi w tym problemu, to
masz właśnie do czynienia z kimś, kto nie potrafi pisać niezawodnych
programów tak w ogóle.

do góry

Andrzej Jarzabek wrote:

> Tylko że jedną z praktyk pisania niezawodnego oprogramowania jest żeby
> w większych projektach opakować systemowe API w coś bardziej
> abstrakcyjnego, czy to bibliotekę in-house czy third-party.

Z tym się zdecydowanie nie zgodzę. To jest praktyka pisania oprogramowania
przenośnego między platformami. Do pisania niezawodnego nie jest to
wymagane.

Co jeśli poziom abstrakcji API systemowego jest właśnie idealnie dopasowany
do zadania? Opakowywać go w coś, co ma te same możliwości, ale
NIESTANDARDOWY interfejs?
Ja wiem, że mamy trochę inne spojrzenie, ze względu na inne doświadczenia.
Przechodziłem kiedyś przez taki etap rozwoju, że próbowałem opakowywać API
systemowe. Z czasam osiągałem taki efekt, że moja "abstrakcja" powielała
dokładnie to, co dawało API systemowe. Po prostu większość szczegółów API
systemowego była mi rzeczywiście potrzebna.

do góry

Dnia Mon, 10 Oct 2011 22:42:42 +0200, Edek napisał(a):
>> O, tu masz niezgorsze zestawienie:
>> http://en.wikipedia.org/wiki/Anti-pattern
>
> Znam lepsze źródła, gdzie jest miejsce na dyskusję z poczuciem humoru.

To się podziel.

> Generalnie, definiujesz kod jako "kaszaniasty i trudny w utrzymaniu"
> wg. tej strony wikipedii, z której połowa jest nie na temat
> (zarządzanie)? Według Ciebie review to check-lista z antywzorcami?

Pytasz, na czym polega kaszaniasty kod. Podaję Ci link
do paru niezłych przykładów takowego.
Eeeeee?
Ja coś definiuję?

> Jakby to było takie proste, to byłyby toole, które to sprawdzają.

A kto mówi, że to proste?

> A jest takich tooli mało i zazwyczaj więcej jest z nimi problemów
> niż jest z nich pożytku; na pewno człowieka nie zastępują.

Eeeeeee?
Narzędzia do sprawdzania np. nadużyć wzorców projektowych?

Pozdrawiam,
Zbaraniały

do góry

On 10/11/2011 09:51 PM, Waldek M. wrote:
> Dnia Mon, 10 Oct 2011 22:42:42 +0200, Edek napisał(a):
>>> O, tu masz niezgorsze zestawienie:
>>> http://en.wikipedia.org/wiki/Anti-pattern
>>
>> Znam lepsze źródła, gdzie jest miejsce na dyskusję z poczuciem humoru.
>
> To się podziel.

Eeeeeeeeee?

>
>> Generalnie, definiujesz kod jako "kaszaniasty i trudny w utrzymaniu"
>> wg. tej strony wikipedii, z której połowa jest nie na temat
>> (zarządzanie)? Według Ciebie review to check-lista z antywzorcami?
>
> Pytasz, na czym polega kaszaniasty kod. Podaję Ci link
> do paru niezłych przykładów takowego.

Hmm. Obejrzałem tą stronę na wiki i nadal nie widzę. Potrafię
sobie wyobrazić Zbaraniałego jako autora Management by Perkele,
tyle, że niewiele mi to mówi o samym kaszaniastym kodzie.

> Eeeeee?
> Ja coś definiuję?

Nie. Tylko ja spytałem o jakąś definicję. Definicja czy nie-definicja,
rozumiem, że dla Ciebie kaszaniaty kod to taki, do którego można
przyczepić jakiś AntiPattern. Uważasz Singleton za Pattern?
(retoryczne)

>
>> Jakby to było takie proste, to byłyby toole, które to sprawdzają.
>
> A kto mówi, że to proste?

Twoja odpowiedź była prosta, a przynajmniej krótka. Widziałem już
w życiu kaszaniasty kod, o wzorcach też wiem, nie uważam wzorców,
antywzorców, debatowania o wzorcach, wzorcu poprawnego debatowania
o wzorcach ani ciasta wzorcowego za odpowiedź cokolwiek wnoszącą.
Prywatnie uważam wzorce głównie za zbiór pojęć, którego
na szczęście nie wszyscy używają jako czarno białą wyrocznię.

Natomiast uważam ludzi, którzy dowiedzieli się o wzorcach, a jeszcze
nie nauczyli się pisać kodu, za Wzorcowych Łosi (tm) (o ile
się tym chwalą i robią więcej Fabryk niż ich powstało na początku ery
przemysłowej)

>
>> A jest takich tooli mało i zazwyczaj więcej jest z nimi problemów
>> niż jest z nich pożytku; na pewno człowieka nie zastępują.
>
> Eeeeeee?
> Narzędzia do sprawdzania np. nadużyć wzorców projektowych?

Te, do których widziałem toole: Circular Dep., Raze Hazard, Constant
Interface, BaseBean (chyba), Object Orgy, Blind Faith (fcuk, gcc to
sprawdza, b oczywiście), Ctrl-C Ctrl-V, i sporo innych, których
akurat na tej stronie nie ma.

Oczywiście nie ma toola, który ze źródeł wywnioskuje, że ma miejsce
Improbability Factor czy Anemic Domain Model, o Gold Plating nie
wspominam. Wspomniałem o toolach głównie dlatego, że dla nich nie
istnieje coś takiego jak wyjątek od reguły, o wyższych funckjach
nie wspominając.

Edek

do góry

On 10/11/2011 05:13 AM, Andrzej Jarzabek wrote:
> On 10/10/2011 19:08, Edek wrote:
>> On 10/10/2011 05:57 AM, Andrzej Jarzabek wrote:
>>>
>>> Zgodzę się, że to jest trudniejszy problem, ale to nie jest tylko
>>> kwestia umiejętności programisty. Zresztą samo "wywalanie się" to był
>>> skrót myślowy, możemy sobie rozszerzyć czy dodefionować pojęcie na
>>> nieprawidłowe działanie programu wynikające z błędu programistycznego, w
>>> przeciwieństwie do błędnego czy niedostatecznego sformułowania lub nie
>>> do końca zrozumienia wymagań.
>>
>> Skrajne podejście do sprawy: pisanie kodu to spełnienie wszystkich
>> ograniczeń, z czego jednym z ograniczeń są wymagania. To eksperyment
>> myślowy, ale też prawda.
>
> Mówiliśmy o tym, co należy do kompetencji programisty. Programista nie
> musi i zwykle nie będzie znał wszystkich wymagań, a w praktyce raczej
> rzadko się zdarza, żeby była specyfikacja wymagań, która jest kompletna,
> bezbłędna i jednoznaczna. Oczywiście sztka robienia programu tak, żeby
> był zgodny ze wszytkimi wymaganiami jest też istotna, ale rola
> programisty w tym wszystkim zależy od różnych rzeczy, na przykład od
> procesu, poza tym jest to proces iteracyjny, gdzie w danej kolejnej
> iteracji zazwyczaj się pisze program mniej lub bardziej nie spełniający
> wymagań itd. itd., to jest temat rzeka.

Podtrzymuję swoją tezę w ten sposób: jak się podzieli problem na
mniejsze, to zna się wymagania małych fragmentów. Chociażby dlatego,
że samemu się podzieliło problem tak, że ten fragment ma robić to i to.
Raczej o takie wymagania mi chodziło, niż o wynegocjowany z klientem
dokument.


> [...]
> I: jeśli ktoś jest programistą z jakąkolwiek praktyką, ale bez
> znajomości dobrych praktyk, ale dla dostania pracy przeczyta wszystkie
> te książki i przygotuje się do odpowiadania tak, jakby stosował je w
> praktyce, to potencjalnie jest bardzo dobrym programistą i cennym
> pracownikiem.

Sam z siebie? Wyobraziłem sobie sytuację, gdy potencjalny pracodawca
mówi mi, "wie pan, przeczytałby pan może tę książkę..". Nie wiem,
czy dobrze odczytałbym intencje :)

[...]
>> [...] komentowanie kodu,
>
> A właśnie: spotkałem się z opinią, do której się przychylam, że jeśli w
> kodzie potrzeba wielu komentarzy, to wskazuje to na problem z jego
> strukturą, że raczej należy starać się pisać kod tak, żeby komentarz nie
> był potrzebny.

Ja chyba nie znam reguły. Najbliższym przybliżeniem tego, co wymaga
komentarzy, to rzeczy nie oczywiste. No bo dobry kod sam się
komentuje, tak się czasami mówi, ja komentuję to, o czym sam
mogę zapomnieć za pół roku, bo jest podchwytliwe, albo się opiera
na jakiejś konstrukcji. W ogóle lubię komentować konstrukcje,
podziały, idee, oraz takie podchwytliwe rzeczy jak zależność
od czegoś zupełnie gdzie indziej, no i API, które IDE wyświetla
wraz właśnie z komentarzami, a jak nie to są w jednym miejscu.
Zazwyczaj moje pojęcie o tym co jest oczywiste a co nie pokrywa
się z grubsza z pojęciem innych; co nie znaczy, że nie mam na koncie
kawałka kodu, o którym po tygodniu sam nie miałem zielonego pojęcia
jak działa i spędziłem więcej czasu niż wtedy jak to pisałem nad
rozszyfrowaniem dlaczego on faktycznie działa. To było oczywiście
nie i +=1, tylko odrobina matematyki i logiki, nic specjalnego, ale
wystarczyło. I tam wybitnie brakowało komentarza.

Edek

do góry

On 11/10/2011 20:30, Wojciech Jaczewski wrote:
> Andrzej Jarzabek wrote:
>
>> Tylko że jedną z praktyk pisania niezawodnego oprogramowania jest żeby
>> w większych projektach opakować systemowe API w coś bardziej
>> abstrakcyjnego, czy to bibliotekę in-house czy third-party.
>
> Z tym się zdecydowanie nie zgodzę. To jest praktyka pisania oprogramowania
> przenośnego między platformami. Do pisania niezawodnego nie jest to
> wymagane.

Do pisania oprogramowania niezawodnego potrzebna jest abstrakcja i
czytelność kodu. Kod, który sobie po cichu zakłada, że int ma 32 bity ma
niedobory w jednym i drugim.

> Co jeśli poziom abstrakcji API systemowego jest właśnie idealnie dopasowany
> do zadania? Opakowywać go w coś, co ma te same możliwości, ale
> NIESTANDARDOWY interfejs?

Jeśli mówisz o programie, którego najlepszym opisem jest "wywołuje
taką-a-taką funkcję systemową" to może i jest to najlepszy poziom
abstrakcji. Jeśli jednak mówimy o dużych projektach pisanych przez
zespoły, to raczej norma jest taka, że operują na wyższym poziomie
abstrakcji.

> Ja wiem, że mamy trochę inne spojrzenie, ze względu na inne doświadczenia.
> Przechodziłem kiedyś przez taki etap rozwoju, że próbowałem opakowywać API
> systemowe. Z czasam osiągałem taki efekt, że moja "abstrakcja" powielała
> dokładnie to, co dawało API systemowe. Po prostu większość szczegółów API
> systemowego była mi rzeczywiście potrzebna.

Pracowałem przy kilku większych projektach i normą było korzystanie z
biblioteki opakowującej API, chociaż nie takiej, która jest tworzona pod
konkretny projekt: albo były to biblioteki third party, albo robione w
firmie na potrzeby wielu projektów. To, czy korzystają czy nie
korzystają ze wszystkich funkcji API nie ma znaczenia - istotne jest, że
reprezentują wyższy poziom abstrakcji.

do góry

On Oct 11, 11:50 pm, Edek <e...@g...com> wrote:
> On 10/11/2011 05:13 AM, Andrzej Jarzabek wrote:
>
> Podtrzymuję swoją tezę w ten sposób: jak się podzieli problem na
> mniejsze, to zna się wymagania małych fragmentów. Chociażby dlatego,
> że samemu się podzieliło problem tak, że ten fragment ma robić to i to.
> Raczej o takie wymagania mi chodziło, niż o wynegocjowany z klientem
> dokument.

Nie będę z tą rezą polemizował. POwtórzę tylko, że z tym wywalaniem
się programu to był skrót myślowy, a praktyki, o których pisałem,
odnoszą się nie tylko do problemów niezawodnościowych, ale też do
innych sytuacji, gdzie program robi nie to co powinien z powodu błędów
programisty.

> > [...]
> > I: jeśli ktoś jest programistą z jakąkolwiek praktyką, ale bez
> > znajomości dobrych praktyk, ale dla dostania pracy przeczyta wszystkie
> > te książki i przygotuje się do odpowiadania tak, jakby stosował je w
> > praktyce, to potencjalnie jest bardzo dobrym programistą i cennym
> > pracownikiem.
>
> Sam z siebie? Wyobraziłem sobie sytuację, gdy potencjalny pracodawca
> mówi mi, "wie pan, przeczytałby pan może tę książkę..". Nie wiem,
> czy dobrze odczytałbym intencje :)

Odnosiłem się do tekstu o "samym czytaniu książek". Jeśli ktoś nie
posiada w praktyce umiejętności z tych książek, ale w ramach
przygotowań do rozmowy o pracę przeczyta je, żeby wyjść na bardziej
kompetentnego niż jest w rzeczywistości, i w dodatku faktycznie uda mu
się na takiego w rozmowie wyjść, to raczej dobrze o nim świadczy jako
o potencjalnym pracowniku?

> > A właśnie: spotkałem się z opinią, do której się przychylam, że jeśli w
> > kodzie potrzeba wielu komentarzy, to wskazuje to na problem z jego
> > strukturą, że raczej należy starać się pisać kod tak, żeby komentarz nie
> > był potrzebny.
>
> Ja chyba nie znam reguły. Najbliższym przybliżeniem tego, co wymaga
> komentarzy, to rzeczy nie oczywiste. No bo dobry kod sam się
> komentuje, tak się czasami mówi, ja komentuję to, o czym sam
> mogę zapomnieć za pół roku, bo jest podchwytliwe, albo się opiera
> na jakiejś konstrukcji.

Ogólnie to jakby rozszerzenie tej zasady, że dobry kod komentuje się
sam. W bardziej radykalnej wersji można powiedzieć, że komentarze są
evil. Że czasem jest to zło konieczne, ale za każdym razem, kiedy
widzi się potrzebę skomentowania kodu, należy się zastanowić czy
zamiast tego nie da się lepiej wyrazić tego samego w kodzie. Powiedzmy
masz licznik czegośtam w postaci inta, który musi być podbijany z
kilku różnych wątków, więc dodajesz mutex i komentarz, że ten mutex
służy do zabezpieczania licznika, który jest podbijany z kilku wątków.
A może zamiast tego lepiej zrobić klasę i nazwać ją ThreadSafeCounter,
to komentarz przestanie być potrzebny.

> W ogóle lubię komentować konstrukcje,
> podziały, idee, oraz takie podchwytliwe rzeczy jak zależność
> od czegoś zupełnie gdzie indziej, no i API, które IDE wyświetla
> wraz właśnie z komentarzami, a jak nie to są w jednym miejscu.
> Zazwyczaj moje pojęcie o tym co jest oczywiste a co nie pokrywa
> się z grubsza z pojęciem innych; co nie znaczy, że nie mam na koncie
> kawałka kodu, o którym po tygodniu sam nie miałem zielonego pojęcia
> jak działa i spędziłem więcej czasu niż wtedy jak to pisałem nad
> rozszyfrowaniem dlaczego on faktycznie działa. To było oczywiście
> nie i +=1, tylko odrobina matematyki i logiki, nic specjalnego, ale
> wystarczyło. I tam wybitnie brakowało komentarza.

Nie będę odnosił się do twoich przykładów, bo ich nie znam. Ogólnie,
bynajmniej nie chodziło o to, że ten sam kod bez komentarza będzie
lepszy niż z komentarzem, tylko że kod, w którym "brakuje komentarza"
często lepiej przepisać tak, żeby tego komentarza nie brakowało, niż
dodać do niego komentarz. Czy też powiedzmy od razu starać się go
pisać tak, żeby komentarz nie był potrzebny.

Nie uważam, że to jest jakaś złota zasada czy srebrna kula, ale jednak
zauważyłem, że często tak faktycznie jest: mam do czynienia z funkcją,
w której bez komentarzy trudno byłoby rozkminić jakiś istotny aspekt,
dzięki komentarzom jest to możliwe, ale jednak jest możliwe i byłoby
lepiej, gdyby te aspekty były wprost wyrażone w kodzie.

do góry

Andrzej Jarzabek wrote:

>>> Tylko że jedną z praktyk pisania niezawodnego oprogramowania jest żeby
>>> w większych projektach opakować systemowe API w coś bardziej
>>> abstrakcyjnego, czy to bibliotekę in-house czy third-party.
>>
>> Z tym się zdecydowanie nie zgodzę. To jest praktyka pisania
>> oprogramowania przenośnego między platformami. Do pisania niezawodnego
>> nie jest to wymagane.
>
> Do pisania oprogramowania niezawodnego potrzebna jest abstrakcja i
> czytelność kodu. Kod, który sobie po cichu zakłada, że int ma 32 bity ma
> niedobory w jednym i drugim.

Mowa o funkcjach systemowych, a nie zakładaniu ile bitów ma int. Trudno mi
sobie wyobrazić, aby ktoś korzystał z tego założenia, mając do dyspozycji
alternatywę w postaci int32_t.

>> Co jeśli poziom abstrakcji API systemowego jest właśnie idealnie
>> dopasowany do zadania? Opakowywać go w coś, co ma te same możliwości, ale
>> NIESTANDARDOWY interfejs?
>
> Jeśli mówisz o programie, którego najlepszym opisem jest "wywołuje
> taką-a-taką funkcję systemową" to może i jest to najlepszy poziom
> abstrakcji. Jeśli jednak mówimy o dużych projektach pisanych przez
> zespoły, to raczej norma jest taka, że operują na wyższym poziomie
> abstrakcji.

Bardzo jest dla mnie zagadkowe, że tak wiele osób uważa, iż interfejs
opracowywany i testowany przez kilka dziesięcioleci koniecznie wymaga
opakowania w jakąś abstrakcję, bo inaczej korzystać z niego nie należy...
Nie wiem jak jest z interfejsami windowsowymi, bo z nimi doświadczenie
miałem znikome, ale interfejsy POSIX-owe są bardzo dobre. Abstrakcja w
postaci deskryptora pliku - coś wspaniałego.
Również dla krytykowanych przez niektórych uniksowych sygnałów daje się
czasem znaleźć fajne zastosowanie, gdzie bez sygnałów program byłby dużo
bardziej zawiły.

Oczywiście w każdym API dałoby się wskazać jakieś wady, ale na jakiej
podstawie miałbym przypuszczać, że zrobiona w dużo krótszym czasie
abstrakcja będzie istotnie lepsza?

Dla ścisłości: nie mam nic przeciwko takim abstrakcjom, jak np. baza danych
- tam rzeczywiście nie używa się systemowego API do komunikacji
międzyprocesowej, tylko API udostępnionego przez twórcę bazy danych. Ale ja
tego nie nazwałbym "opakowywaniem systemowego API", tylko zrobieniem modułu
wykorzystującego systemowe API.
Dla mnie "opakowywanie systemowego API" to takie wynalazki jak np. QSocket z
Qt. Dla programów międzyplatformowych - może ma sens. Dla programów na jedną
platformę - żadnego. Interfejs udostępniany przez system (POSIX) jest
lepszy. Testowałem też kiedyś Boost::Asio - nieczytelny w porównaniu z tym,
co można zrobić korzystająć bezpośrednio z POSIX. I ciężki do integracji,
jeśli program ma reagować jednocześnie na zdarzenia innego typu.

>> Ja wiem, że mamy trochę inne spojrzenie, ze względu na inne
>> doświadczenia. Przechodziłem kiedyś przez taki etap rozwoju, że
>> próbowałem opakowywać API systemowe. Z czasam osiągałem taki efekt, że
>> moja "abstrakcja" powielała dokładnie to, co dawało API systemowe. Po
>> prostu większość szczegółów API systemowego była mi rzeczywiście
>> potrzebna.
>
> Pracowałem przy kilku większych projektach i normą było korzystanie z
> biblioteki opakowującej API, chociaż nie takiej, która jest tworzona pod
> konkretny projekt: albo były to biblioteki third party, albo robione w
> firmie na potrzeby wielu projektów. To, czy korzystają czy nie
> korzystają ze wszystkich funkcji API nie ma znaczenia - istotne jest, że
> reprezentują wyższy poziom abstrakcji.

Czy wyższy poziom abstrakcji w sensie np. baza danych zamiast bezpośredniego
czytania z plików i synchronizowania przy pomocy fcntl/flock? czy tylko
pozbierane kilka funkcji systemowych do kupy i pozamykane w obiekty?

do góry