Archive for Thoughts

Cebulowy postęp

2010-09-15 17:48

Co pewien czas można natknąć się na porównania odnośnie mocy obliczeniowej komputerów bardzo dawnych i tych dzisiejszych. Takim dość typowym, często powtarzanym stwierdzeniem jest na przykład to, iż komputer sterujący misją Apollo 11 miał moc porównywalną z dzisiejszym kalkulatorem. Podobne ciekawostki służą czasami ukazaniu gigantycznego postępu, jaki dokonał się w ciągu ostatnich kilku dekad jeśli chodzi o sprawność jednostek obliczeniowych.

Jednak nierzadko służą one także kwestionowaniu kierunku zmian w szeroko pojętej technologii komputerowej, które były możliwe właśnie dzięki tak wielkiemu wzrostowi mocy obliczeniowej procesorów. Bez zbędnych słów można te argumenty streścić w postaci następującego pytania: Skoro 40 lat temu “kalkulator” o częstotliwości 1 Mhz mógł dowieźć ludzi na Księżyc, to dlaczego obecnie potrzebujemy tysiąc razy większej mocy obliczeniowej, aby napisać prosty dokument tekstowy?… Aż chciałoby się dodać: co poszło nie tak? :) Ale spokojnie, wszystko jest w jak najlepszym porządku. Takie postawienie sprawy to bowiem nic innego, jak chwytliwy slogan, który przedstawia ją w sposób zdecydowanie zbyt uproszczony. Krótko mówiąc, zionie on przerażającą ignorancją.

Nie chodzi tu już nawet o wyraźne przecenienie stopnia skomplikowania zadań, przed jakimi ów sławetny komputer pokładowy stawał i jakości rozwiązań, które dla nich znajdował (ich częścią był chociażby “interfejs użytkownika”, składający się z komunikatów-liczb, których odcyfrowanie wymagało sporej książki). Bardziej irytuje mnie sugestia, że w dzisiejszych aplikacjach cała ta olbrzymia moc obliczeniowa jest marnowana na parę w gwizdek. No, czyli właściwie na co?… Odpowiedź brzmi: na mnóstwo “oczywistych” rzeczy, na które normalnie nie zwracamy uwagi albo o których nie musimy nawet myśleć. Jest ich dużo, bardzo dużo – i ich lista cały czas się powiększa.

Przykłady? Ależ proszę; nie trzeba ich wcale daleko szukać. Czy ktoś może chociażby uczciwie powiedzieć, że dokładnie wie, jak działa Internet? Jak to się dzieje, że dane mogą zostać przesłane z jednego końca świata na drugi, mijając po drodze kilometry kabli, setki routerów, dziesiątki różnie skonfigurowanych podsieci, a pewnie i kilka satelitów, i być odczytane na komputerze nie tylko działającym pod kontrolą całkiem innego systemu operacyjnego, ale składającym się być może z zupełnie różnych podzespołów?… Totalna magia :)
Ale to jest właśnie ów gwizdek. Taka karkołomna operacja jest możliwa tylko dlatego, że występujące po drodze ogniwa dysponują wystarczającą mocą obliczeniową i przepustowością łączy, by w rozsądnym czasie dokonać wielokrotnego rozpakowywania i ponownego pakowania danych w poszczególne warstwy komunikacji. Każda z nich: Ethernet, IP, TCP, HTTP (a na tym pewnie Unicode, XML/JSON/itp., RPC i w końcu protokół własny aplikacji) służą temu, aby – paradoksalnie – coś uprościć i… przyspieszyć. Tym czymś jest oczywiście tworzenie aplikacji – to, co trwa najdłużej, jest najkosztowniejsze i nie poddaje się prostemu skalowaniu tak, jak możliwości elektroniki.

Rozwój IT polega więc (w dużym stopniu) na dodawaniu kolejnych warstw abstrakcji do coraz większej cebuli. Nie jest to jednak przyczyna, a skutek coraz lepszych możliwości technicznych sprzętu. Możemy sobie po prostu na to pozwolić. I bardzo dobrze.
Nie zapominajmy bowiem, że komputer Apollo 11 programowany był w archaicznym asemblerze przez ładnych kilka lat przez sztab wybitnych fachowców z NASA. Czy nie powinniśmy doceniać faktu, że program wykonujące równoważnie skomplikowane zadania może dzisiaj stworzyć niemal każdy w znacznie krótszym czasie i o wiele przyjemniejszy sposób? Jeśli ktoś twierdzi, że to nie jest postęp, to doprawdy nie wiem, co mu odpowiedzieć :P

Tags: ,
Author: Xion, posted under Computer Science & IT, Internet, Thoughts » 6 comments

Jak się uczyć nowego API

2010-08-10 20:26

Poznawanie nowych narzędzi programistycznych, bibliotek czy nawet platform to częsta konieczność w pracy kodera. Najczęściej jest to środek do osiągnięcia jakiegoś konkretnego celu projektowego, ale nierzadko możemy też zechcieć zagłębić się w nowe API dla samej przyjemności jego poznania. Jak się do tego zabrać? Są różne sposoby.

Możemy na przykład próbować jak najwięcej się o danej bibliotece dowiedzieć. W dzisiejszych czasach nie jest to trudne, bo standardem jest posiadanie dobrej (albo chociaż jakiejkolwiek ;]) dokumentacji. Ponadto wokół niemal każdej choć śladowo popularnej technologii natychmiast wyrastają internetowe społeczności, których dyskusje na forach (rzadziej już na grupach dyskusyjnych) mogą być również cennym źródłem informacji – zwłaszcza w przypadku wystąpienia problemów.
Postępując w ten sposób możemy zyskać bardzo szeroki i głęboki (jak morze :)) wgląd w funkcjonowanie danej biblioteki i jej strukturę, co może nam pomóc w jej użytkowaniu. Istnieje jednak szansa, że poprzez nadmierne skoncentrowanie się na opisach teoretycznych umkną nam ważne kwestie praktyczne.

Niejako przeciwną metodą jest jak najszybsze zajęcie się ową praktyką. W tym celu wystarcza zwykle przejrzenie różnorakich tutoriali (jeśli takowe są dostępne), a zwłaszcza dokładne przestudiowanie przykładowych fragmentów kodu. Zresztą eksperymentalne poznawanie nowej technologii może być wręcz kopiowaniem sampli, ich uruchamianiem, a następnie modyfikacją w celu zmiany sposobu działania, uelastycznienia lub poszerzenia o nową funkcjonalność.
Gdy w taki sposób zabieramy się do rzeczy, możemy szybko zobaczyć rezultaty. Jeśli jednak będziemy mieli pecha i pojawią się niespodziewane problemy, zaledwie pobieżna znajomość technologii może nam wydatnie utrudnić ich rozwiązanie. Poza tym takie kodowanie “na gorąco” wymaga nieporównywalnie częstszych wypadów na łono dokumentacji :)

Tags: ,
Author: Xion, posted under Internet, Programming, Thoughts » 3 comments

Prosty menedżer zasobów?…

2010-06-28 18:09

Silnikologia (przynajmniej ta warsztatowa) ma swoje dziwnostki. Za jedną z nich uważam przykładanie zbyt dużego znaczenia do tych podsystemów engine‘u gry, które są zdecydowanie mniej ważne niż silnik graficzny czy fizyczny. Podpadają pod to (między innymi): mechanizmy logowania, VFS-y (wirtualne systemy plików), kod odpowiedzialny za wczytywanie i zapisywanie opcji konfiguracyjnych, itp. Blisko szczytu tej listy znajduje się też podsystem, o którym chcę napisać dzisiaj kilka słów. Chodzi mianowicie o menedżer zasobów (resource manager).

Pod tą nazwą kryję się obiekt, którego zadaniem jest – jak nazwa zresztą wskazuje – zarządzanie różnego rodzaju zasobami gry, gdzie pod pojęciem ‘zasobu’ kryje się zwykle jakiś element jej contentu: model, tekstura, próbka dźwiękowa, czcionka, shader… Menedżer ma za zadanie udostępniać odwołania do tych zasobów elementom silnika/gry, które ich potrzebują. To jest jego główny, nadrzędny cel.
Tu jednak dochodzimy do małego paradoksu. Jeśli bowiem jest to jedyne przeznaczenie modułu od zarządzania zasobami, to tak naprawdę mogłoby go w ogóle nie być!… W praktyce jego istnienie usprawiedliwia przynajmniej jeden z poniższych powodów:

  • jednoczesne załadowanie wszystkich zasobów gry czy nawet pojedynczego etapu/krainy/lokacji/itp. nie jest możliwe z uwagi na ograniczony rozmiar pamięci
  • ładowanie zasobów trwa na tyle długo, że rozsądne jest wydzielenie tego procesu do osobnego wątku
  • kompatybilność z DirectX w wersjach poniżej 9Ex wymaga obsługi zjawiska utraty urządzenia, a więc ponownego wczytania zasobów umieszczonych w pamięci karty graficznej
  • między poszczególnymi zasobami występują zależności, które nie pozwalają na łatwe określenie prawidłowej kolejności ich zwalniania

Tego rodzaju wymagania rzeczywiście można rozsądnie zrealizować dopiero wówczas, gdy w logiczny sposób wydzielimy z kodu część, która za kontrolę zasobów będzie odpowiadać. Jeśli jednak żadna z powyższych sytuacji nie aplikuje się do nas, nie ma żadnego powodu, by zabierać się za tworzenie modułu zarządzania zasobami tylko dlatego, że “przecież zasoby gdzieś muszą być”. Coś takiego jak ‘prosty menedżer zasobów’ to oksymoron: jeśli faktycznie może być prosty, to najpewniej znaczy, iż jest zbędny. No, chyba że pod tym pojęciem rozumiemy też coś, co w praktyce da się zredukować do:

  1. Texture* sprites[SPRITES_COUNT];
  2. Sound* sounds[SOUNDS_COUNT];

W takim przypadku powinniśmy zadbać przede wszystkich o to, by nasz Menedżer Zasobów (caps intended) dobrze współpracował z Modułem Wyświetlania Życia Gracza, że o Silniku Od PauzyTM nie wspomnę ;P

Standardy kodowania jako choroba dziedziczna

2010-05-25 18:38

Ponieważ programowaniem zajmuję się już od dość długiego czasu, mam w tym nieco doświadczenia praktycznego. Przez ten czas zdążyłem też zmienić część swoich poglądów na niektóre rzeczy z tym związane. Mówiąc trochę górnolotnie: stałem się bogatszy o wiedzę z życia wziętą :)
Jedną z takich nauczek życiowych jest to, by nie ufać zbytnio standardom, zaleceniom i innym tzw. dobrym praktykom podpowiadających (a czasem wręcz nakazujących), jak powinien wyglądać pisany przez nas kod. Dotyczy to na przykład instrukcji rzekomo złych “z natury” i innych tego rodzaju przesądów. Tak, uważam określenie ‘przesądy’ za uprawnione w wielu przypadkach.

Nie jestem ponadto odosobniony w tych poglądach – ba, wśród swoich kolegów po fachu mógłbym wskazać wielu kilku, którzy są pod tym względem nawet bardziej… radykalni :) Jak już jednak wspomniałem na początku, nie zawsze tak było. Kiedyś miałem bardziej rygorystyczne i pryncypialne podejście do kwestii tego, jak kodować należy lub nie należy. Skąd brałem dla niego uzasadnienie, jeśli nie z praktyki, której wtedy zbyt wiele jeszcze nie miałem?…
Ano właśnie – tu dochodzimy do sedna. Przekonanie to brało się głównie – jeśli nie wyłącznie – ze wszelkiego typu materiałów pomocniczych do nauki programowania: książek, kursów, artykułów, czasem dokumentacji. Choćby nie wiem jak techniczne i merytoryczne były te teksty, w każdym – co do jednego, z moim skromnym dziełem włącznie – znajdą się rady, zalecenia, wskazówki i inne “metainformacje” odnośnie tego, jak programować należy – a nie tylko o tym, jak można. Czy ktoś widział w kursie programowania opis instrukcji goto (że pozwolę sobie użyć najbardziej typowego przykładu), który nie zawierał chociaż śladowej wzmianki o tym, iż.. no, w zasadzie to nie należy jej używać?… …Tak myślałem ;-)

Nasuwającą się od razu repliką w obronie autorów jest sugestia, że w sumie to przecież całkiem dobrze, iż uczą oni nowicjuszy tego, co sami musieli wcześniej wypracować przez lata. Nie wątpię wręcz, że taka intencja – oszczędzenia początkującym trudności – rzeczywiście autorom przyświeca. Dodają oni do pisanych przez siebie tekstów, kursów, tutoriali, itp. liczne wskazówki, te wszystkie dos and don’ts właśnie dlatego, iż wierzą w to, że w ten sposób pomogą swoim czytelnikom od razu, już na starcie kodować w sposób przejrzysty, efektywny, elastyczny, elegancki, “łatwo konserwowalny”, i tak dalej.


“Pamiętaj synku, by się zabezpieczać:
dawaj const, gdzie tylko możesz.”
(Źródło obrazka)

Chwalebne intencje – nie da się ukryć. Ale nietrudno jest wskazać przynajmniej dwa błędy takiego rozumowania. Pierwszym jest założenie, że każdą wiedzę i każdą umiejętność da się przekazać innym – czyli że w ogóle istnieje “droga na skróty”, niejako omijająca zdobywanie doświadczenia praktycznego w danej dziedzinie (w tym przypadku w programowaniu). Żeby stwierdzić, że to jednak nieprawda, wystarczy zastanowić się, czy ukończenie podstawowego kursu szachów u arcymistrza da nam od razu ELO 2500. Niestety w rzeczywistości dojście do takiego poziomu wymaga dziesiątków tysięcy rozegranych partii – i nic się na to nie poradzi.
Drugim błędem jest przyjmowanie, że przekazywane mądrości są faktycznie odpowiednie dla odbiorców. Nie, nie chcę wcale sugerować, że ktoś może mieć traumę z powodu wczesnych doświadczeń z hermetyzacją czy wzorcem fabryki ;) Raczej sugeruję, że przywiązując zbyt wielką wagę do przekazywanych zaleceń, początkujący mogą stracić wiele czasu na dopasowywanie swoich pierwszych programów do ich wysoko zawieszonej poprzeczki – najczęściej zupełnie niepotrzebnie. Gra w zgadywanie liczby, kółko i krzyżyk czy tetris nie potrzebują zwykle skomplikowanej, wewnętrznej architektury z dokładnie zaprojektowanymi relacjami między klasami i starannym oddzieleniem interfejsu od implementacji. Prosi się to bowiem o przytoczenie znanego powiedzenia na temat artylerii i pewnego gatunku insekta :)

Tak oto okazuje się więc, że zalecenia i rady tudzież – szumnie nazywane – standardy kodowania są “dziedziczone” przez początkujących programistów od autorów książek, kursów i tutoriali, którzy je tam umieszczają pomiędzy objaśnieniami kolejnych konstrukcji językowych czy elementów API. A że ponadto, jak opisałem wyżej, standardy te zbyt wcześnie poznane mogą być nie tyle nawet zbędne, co wręcz szkodliwe, pozwalam sobie nazwać je ‘chorobami dziedzicznymi’. Nic tak bowiem nie trafia do wyobraźni jak obrazowe porównanie ;>
Zakończyć chcę jednak optymistycznym akcentem. Otóż choroby te są jak najbardziej uleczalne. Terapia jest też nieskomplikowana i – jak sądzę – skuteczna. Trzeba po prostu kodować, kodować i jeszcze raz kodować :)

Tags: , ,
Author: Xion, posted under Books, Programming, Thoughts » 4 comments

ma kau se jinvi mi la lojban.

2010-04-26 13:07

…czyli co sądzę o lojbanie.

Powracam do tematu z notki sprzed kilku tygodni, mimo swoich przeczuć, że nie jest to wcale coś, na co wszyscy z napięciem oczekiwali ;-) Spróbuję jednak przekazać porcję swoich nieco głębszych przemyśleń na temat lojbanu po tym, jak poświęciłem trochę więcej czasu na przyjrzenie się temu językowi. Witam więc tych nielicznych, którzy chcą się z nimi zapoznać :]

Dla osoby zupełnie niewtajemniczonej najbardziej rzucającą się w oczy cechą tego języka jest to, że zdecydowana większość słów jest zupełnie niepodobna do swoich odpowiedników w innych językach – mimo że zostały one skonstruowane właśnie z nich. Chociaż na początku może to się wydawać minusem, w ostatecznym rozrachunku ma chyba więcej zalet niż wad. To dlatego, że – jak pisałem już wcześniej – w lojbanie nie ma tradycyjnych części mowy ani konstrukcji gramatycznych. Nie ma więc uzasadnienia dla tego, żeby słownictwo było w nim podobne do innych języków; to mogłoby wręcz być mylące. Zgadza się to też z założeniem kulturowej bezstronności (“znajome” słowa byłyby faworyzowaniem języków europejskich, jak to jest chociażby w esperanto).
Drugim widocznym atrybutem jest wszechobecność krótkich, zwykle dwu- lub trzyliterowych słów, często z apostrofem w środku (czytanym jako ‘h’). To cmavo (wym. szmawo), słowa strukturalne. W nich zawarta jest zdecydowana większość gramatyki lojbanu. Pełnią one mnóstwo różnorodnych funkcji, będąc odpowiednikami zarówno przyimków, spójników czy zaimków, jak i rodzajników, znaków przestankowych, a nawet podkreśleń czy cudzysłowów (w lojbanie wszystko to ma postać słów). Istnieje więc całe multum różnych cmavo, z których wiele jest logicznie zorganizowanych w grupy mające części wspólne, jak np. ze’i/ze’a/ze’u – krótki/średni/długi odcinek czasu. Nie dotyczy to jednak wszystkich, zatem nierzadko pomyłka o jedną literę może skutkować zupełnie innym znaczeniem wypowiedzi lub jej niepoprawnością.

Jednak cmavo są na szczęście w dużej mierze nieobowiązkowe, bo w wielu przypadkach służą uszczegółowieniu tego, co wynika z kontekstu. Jedną z takich kontekstowych informacji jest często czas (teraźniejszy, przeszły, itp.), który w lojbanie – w przeciwieństwie do wielu innych języków – nieczęsto trzeba podawać wprost, bo reguły gramatyki tego nie wymuszają. Jeśli jednak ktoś sobie życzy sobie, aby go doprecyzować, to ma do dyspozycji bardzo ciekawe rozwiązanie, rozdzielające problem na dwie części. Pierwsza odpowiada relacji czasowej między aktualnym punktem a zdarzeniem – czyli temu, czy mówimy o przeszłości (pu), teraźniejszości (ca) czy przyszłości (ba). Druga (zwana niekiedy aspektem) określa, o którym punkcie osi czasu wokół zdarzenia mówimy, np.: przed jego początkiem (pu’o), dokładnie na początku (co’a), w środku jego trwania (ca’o), dokładnie na końcu (mo’u) lub po jego zakończeniu (ba’o). W sumie daje to kilkanaście kombinacji, z których większość da się odnieść na przykład do czasów w języku angielskim (tenses), ale które jednocześnie są o wiele łatwiejsze do zrozumienia.

Trzecia istotną właściwością lojbanu jest fakt, że znacznie częściej niż w innych językach mówimy w nim o “nie-rzeczach”, takich jak zdarzenia, informacje, wypowiedzi, właściwości, ilości, koncepcje, procesy, stany, itp. Nazywa się je tu ogólnie abstrakcjami i regularnie występują one jako argumenty do predykatów (czyli selbri). Istnieją oczywiście ich odpowiedniki w innych językach, lecz zwykle przyjmują one postać zdań podrzędnych (‘to, że…’), jako że rzeczownikami nazywa się w większości rzeczy lub osoby. W lojbanie tak nie jest (no bo przecież rzeczowników nie ma :)) i w sumie wychodzi mu to na dobre. Można rzecz jasna wskazać dziwne “skutki uboczne” – nie można na przykład chcieć (djica) rzeczy jako takich, a jedynie zdarzeń z nimi związanych – ale ogólnie obecność abstrakcji korzystnie wpływa na specyfikowanie tego, o czym tak naprawdę mówimy.

Tags: ,
Author: Xion, posted under Culture, Thoughts » 4 comments

Aby nie śmiecić

2010-03-20 19:32

Jako moderator forum Warsztatu mam wątpliwą przyjemność kontaktu z różnymi przejawami – nazwijmy to eufemistycznie – niepożądanych zachowań. A to mamy jakieś pytanie, na które odpowiedzią jest pierwszy rezultat, jaki wyszukiwarka wyrzuca w reakcji na prostą kwerendę. Innym razem może to być klasyczne “No i co tu jest źle?!”, opatrzone wysokim na kilka ekranów kawałkiem kodu, dla którego właściwym miejscem jest /dev/null. Kiedy indziej będzie to pojawiający się po raz 2512. problem w rodzaju unresolved external… I tak dalej, i tak dalej. Ot, zwyczajne przypadki, gdy napisanie posta poprzedza (lub zastępuje) myślenie.


Stuprocentowo uzasadnione.

Może nie jestem w stanie tego zrozumieć, ale przynajmniej potrafię się z tym pogodzić – po części pewnie dlatego, że sprzątanie po tego rodzaju twórczości nie jest specjalnie kłopotliwe. Jest jednak przynajmniej jedna rzecz, która skłania mnie do poważnych rozważań na temat intelektualnej kondycji rodzaju ludzkiego – a przynajmniej tej jego części, która się na forum pojawia – połączonych z co najmniej jednokrotnym wykonaniem znanego i lubianego gestu kapitana Picarda.

O co chodzi?… O dołączanie nowych pytań do istniejących wątków, z uzasadnieniem, że czyni się tak po to, aby nie zaśmiecać forum nowymi tematami. Czy jest to dobra praktyka? Czy ma to jakikolwiek sens? I wreszcie, czy skutkiem jej stosowania jest faktycznie większy porządek forum?
Otóż nie – i to po trzykroć nie. Paradoks tu występujący polega właśnie na tym, że – dokładnie przeciwnie do intencji osób tak postępujących – podczepianie się pod istniejące tematy skutkuje tylko i wyłącznie jeszcze większym bałaganem! Dzieje się tak co najmniej z kilku powodów:

  • Wprowadzanie nowego pytania w istniejący wątek odcina możliwość dodania czegokolwiek do oryginalnego tematu dyskusji. Jeśli ktoś mimo wszystko będzie próbował to robić, najprawdopodobniejszym rezultatem jest przeplatanka odpowiedzi na stare i nowe pytanie. Czytanie czegoś takiego to czysta przyjemność, nieprawdaż? 8-)
  • Jeśli jeden wątek zawiera więcej niż jeden temat/dyskusję/pytanie, to jego tytuł staje się mylący. Po niedługim czasie podczepione posty mogą być już zupełnie niezwiązane z tym, o czym wątek był oryginalnie. Istny synonim porządku, co nie? :)
  • Podczepione pytanie jest o wiele trudniejsze do znalezienia przez forumową wyszukiwarkę – jeśli to w ogóle jest możliwe. Co więcej, utrudnia ono też wyszukanie wszystkich informacji z oryginalnej dyskusji – choćby dlatego, że trzeba wpierw ustalić, gdzie się ona kończy…
  • Przywrócenie radośnie zepsutego wątku do stanu używalności jest pracochłonne: wymaga zlokalizowania wszystkich postów odnoszących się do nowego pytania (które mogą się przeplatać z tymi od pierwotnego), wydzielenia ich do nowego wątku i nadania mu sensownego tytułu. To wszystko da się zresztą zrobić tylko przy założeniu, że nie istnieją już posty, które odwołują się do obu pytań naraz. Jeszcze bardziej daleko idące jest przypuszczenie, że istnieje jakikolwiek moderator, któremu chciałoby się takich podziałów dokonywać :)

Widać zatem wyraźnie, że skutek doczepiania się do istniejących wątków jest dokładnie odwrotny do zamierzonego. Nie ma to najmniejszego sensu i jest wybitnie niepożądane. Wciąż jednak nie mogę się nadziwić, jakaż to dziwna logika podsuwa ludziom pomysły, że może być inaczej…

Tags:
Author: Xion, posted under Internet, Thoughts » 3 comments

O obiektowości

2010-02-12 16:58

Kiedy programiści się nudzą, to często spierają się o terminologię. Przedmiotem takich sporów są zwykle nieco mgliste określenia, które czasami – zwykle niesłusznie – używane są jako atrybuty oceniające. Przykład? Choćby “obiektowość” – w zależności od punktu widzenia stwierdzenie, że dany kod/biblioteka/moduł/itp. są bardziej lub mniej obiektowe może stanowić albo zaletę, albo wadę. Zależy to głównie od ‘poglądów’ danej osoby na temat użyteczności podejścia OO w programowaniu.

Co to jednak znaczy, że dany kod jest obiektowy?… Nie uważam wcale, że należy go w tym celu napisać go w języku obiektowym. Twierdzę na przykład, że Windows API jest całkiem dobrym przykładem biblioteki realizującej obiektowy paradygmat, mimo tego że została ona stworzona w jak najbardziej strukturalnym C. Praktyczna różnica między poniższymi wywołaniami:

  1. foo->DoSomething (...);
  2. DoSomething (foo, ...);

jest bowiem właściwie żadna. Dodajmy do tego fakt, że z punktu widzenia programisty-użytkownika w WinAPI występuje zarówno dziedziczenie (rodzajów uchwytów), jak i polimorfizm (funkcje niezależne od typu uchwytów, np. CloseHandle), a więc bardzo obiektowe feature‘y.
Jeśli komuś wydaje się to naciągane i twierdzi, że w ten sposób pod obiektowość można podciągnąć właściwie każdy kod, to już spieszę z przykładem ukazującym, że tak nie jest. Otóż większa część biblioteki OpenGL obiektowa na pewno nie jest, zaś w tych nielicznych miejscach gdzie OOP jest niemal konieczny (jak zarządzanie teksturami czy buforami wierzchołków) pojawia się nieco dziwna koncepcja ‘indeksów’ używanych do identyfikowania poszczególnych obiektów.

Dla niektórych (łącznie ze mną) taki interfejs nie jest szczytem marzeń, a preferowane jest wyraźnie obiektowe podejście DirectX. Absolutnie jednak nie zgadzam się z twierdzeniem, że DirectX jest lepszy, bo bardziej obiektowy – to trochę tak jak powiedzenie, że ten obrazek jest ładniejszy, bo bardziej zielony. W obu przypadkach jest to kwestia gustu i nie powinniśmy zakładać, że cechy pozytywne dla nas są tak samo dobrze odbierane przez innych.
A wyższość DirectX nad OpenGL da się przecież uargumentować na wiele innych, lepszych sposobów :)

Tags: , , ,
Author: Xion, posted under Programming, Thoughts » 3 comments
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.