-
Path: news-archive.icm.edu.pl!news.gazeta.pl!not-for-mail
From: Wojciech Jaczewski <w...@o...pl>
Newsgroups: pl.comp.programming
Subject: Re: Dlaczego w branży rozrywkowej najsłabiej płacą?
Followup-To: pl.comp.programming
Date: Thu, 13 Oct 2011 00:51:28 +0200
Organization: "Portal Gazeta.pl -> http://www.gazeta.pl"
Lines: 72
Message-ID: <j755n8$1f6$1@inews.gazeta.pl>
References: <5...@n...onet.pl> <j4286s$jg9$1@inews.gazeta.pl>
<j532hg$sr8$1@inews.gazeta.pl> <j59mgi$9rv$1@inews.gazeta.pl>
<j5g378$ooq$1@inews.gazeta.pl> <j5s9mu$c1e$1@inews.gazeta.pl>
<j60dl2$or5$1@inews.gazeta.pl> <j6f0tl$f35$1@inews.gazeta.pl>
<f...@j...googlegroups.com>
<j6hra9$6qj$1@inews.gazeta.pl>
<4...@t...googlegroups.com>
<j6l5sd$5u$1@inews.gazeta.pl> <j6m0pc$pp6$1@inews.gazeta.pl>
<j6sqj7$skh$1@inews.gazeta.pl> <j6tqei$hr2$1@inews.gazeta.pl>
<j6u1ie$2ri$1@inews.gazeta.pl>
<d...@5...googlegroups.com>
<j6udri$b1b$1@inews.gazeta.pl>
<a...@d...googlegroups.com>
<j71a8c$cti$1@inews.gazeta.pl>
<6...@p...googlegroups.com>
<j725i2$7d5$1@inews.gazeta.pl> <j73f5k$en8$1@inews.gazeta.pl>
NNTP-Posting-Host: user-46-113-150-65.play-internet.pl
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8Bit
X-Trace: inews.gazeta.pl 1318459946 1510 46.113.150.65 (12 Oct 2011 22:52:26 GMT)
X-Complaints-To: u...@a...pl
NNTP-Posting-Date: Wed, 12 Oct 2011 22:52:26 +0000 (UTC)
X-User: wjaczewski1
User-Agent: KNode/4.4.10
Xref: news-archive.icm.edu.pl pl.comp.programming:192740
[ ukryj nagłówki ]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?
Następne wpisy z tego wątku
- 12.10.11 23:03 Wojciech Jaczewski
- 13.10.11 00:31 Andrzej Jarzabek
- 13.10.11 00:39 Andrzej Jarzabek
- 13.10.11 09:10 Wojciech Jaczewski
- 13.10.11 09:58 Wojciech Jaczewski
- 13.10.11 14:13 Andrzej Jarzabek
- 13.10.11 16:12 Andrzej Jarzabek
- 15.10.11 21:51 Wojciech Jaczewski
- 15.10.11 21:59 Wojciech Jaczewski
- 16.10.11 21:26 Andrzej Jarzabek
- 17.10.11 09:45 Wojciech Jaczewski
- 26.10.11 11:40 Sarr.
Najnowsze wątki z tej grupy
- Do czego nadaje się QDockWidget z bibl. Qt?
- Bibl. Qt jest sztucznie ograniczona - jest nieprzydatna do celów komercyjnych
- Co sciaga kretynow
- AEiC 2024 - Ada-Europe conference - Deadlines Approaching
- Jakie są dobre zasady programowania programów opartych na wtyczkach?
- sprawdzanie słów kluczowych dot. zła
- Re: W czym sie teraz pisze programy??
- Re: (PDF) Surgical Pathology of Non-neoplastic Gastrointestinal Diseases by Lizhi Zhang
- CfC 28th Ada-Europe Int. Conf. Reliable Software Technologies
- Młodzi programiści i tajna policja
- Ada 2022 Language Reference Manual to be Published by Springer
- Press Release - AEiC 2023, Ada-Europe Reliable Softw. Technol.
- Ada-Europe - AEiC 2023 early registration deadline approaching
- Ada-Europe Int.Conf. Reliable Software Technologies, AEiC 2023
- Ile cykli zajmuje mnożenie liczb 64-bitowych?
Najnowsze wątki
- 2024-07-05 eSIM na czym polega
- 2024-07-15 Roaming poza unią
- 2024-07-16 Jak tanio dzwonic do Wielkiej Brytani?
- 2024-07-16 Dzień bez ICE
- 2024-07-15 Spalinówki płoną doszczętnie
- 2024-07-15 Pojemność akumulatora
- 2024-07-15 Elektryk8i dalej płoną.
- 2024-07-15 Motodziennik #284 NOWY MG HS z hybrydą oraz wraca FORD CAPRI (jako SUV)
- 2024-07-14 [FILM] SAMOCHODY ELEKTRYCZNE DO WIELKIE ŚCIEMA? TYLKO FAKTY!
- 2024-07-14 Znieczulica w narodzie
- 2024-07-13 Protect Your PC with IObit Malware Fighter Pro 11.3.0.1346 Multilingual
- 2024-07-13 Advanced SystemCare Pro 17.5.0.255: Complete Performance and Health Optimization
- 2024-07-15 stara idea nowe hardware
- 2024-07-14 Dzwonek gong z transformatorem
- 2024-07-14 espnow przerywa na jeziorze?