Szkółka jest OK

Parę tygodni temu w wyniku spontanicznej akcji jednego z moderatorów na forum Warsztatu pojawił się dział o nazwie Szkółka. W założeniu mają tam trafiać wątki reprezentujące niższy poziom niż te, których miejsce jest w innych zakątkach forum. Mówiąc wprost, ma to być dział dla początkujących, jakich na Warsztacie nie jest wcale tak mało.

Przyznam, że początkowo byłem dość sceptycznie nastawiony do tego pomysłu. Szkółka powstała jako odtrutka na plagę pytań banalnych, oczywistych oraz takich, które zahaczają bardziej o podstawy programowania w ogóle niż programowania gier (a to drugie jest przecież zakresem tematycznym Warsztatu). Na pewno jednak nie miała być miejscem, gdzie toleruje się wybryki lamerskie, jak wątki typu “Oto mój kod, co tu jest źle?” czy pytania, na które odpowiedź można w 10 sekund znaleźć dowolną wyszukiwarką.
Moje wątpliwości dotyczyły tego, czy da się ten zamysł zrealizować w praktyce. Rzekoma Szkółka mogła bowiem łatwo stać się strefą wolnej amerykanki, gdzie dozwolone byłoby wszystko lub prawie wszystko.

Teraz jednak muszę stwierdzić, że ten eksperyment chyba jednak się powiódł. Korzyści z jego realizacji są całkiem spore: przede wszystkim jest to powolne zacieranie się wrażenia, iż na Warsztacie moderatorzy bez wahania banują każdego nowego użytkownika. (Co oczywiście było zawsze bardzo dalekie od prawdy, ale mniejsza o to ;P). Dodatkowo mamy też znacznie wyraźniejsze rozgraniczenie między początkującymi a lamerami dzięki przejrzystym zasadom moderacji w Szkółce. Dowolny wątek może bowiem być z niej usunięty tylko z powodów regulaminowo-netykietowych, a nie na podstawie rzekomo “zbyt niskiego poziomu” (którego ocena, nie ukrywajmy, jest zawsze w jakimś stopniu funkcją widzimisię danego moderatora).
Można oczywiście narzekać, że istnienie Szkółki obniża poziom Warsztatu jako całości. Argument ten opiera się na twierdzeniu, że ów wysoki poziom jest cenną wartością, którą należy usilnie chronić. Osobiście zupełnie się z tym nie zgadzam (o czym zresztą pisałem jakiś czas temu), więc ten postulat nie robi na mnie wielkiego wrażenia :) Za konieczną niedogodność istnienia Szkółki uważam jedynie to, iż przeglądając forum pod kątem ewentualnych interwencji moderatorskich (że tak eufemistycznie to nazwę ;]) należy zwracać uwagę na to, w którym dziale jest dany wątek. A to nie jest przecież jakoś specjalnie kłopotliwe.

Bo to zła instrukcja była…

Ostatnio na forum Warsztatu wyrosła dyskusja wokół niepozornej instrukcji break. Zaczęło się od zasłyszanej opinii, że korzystanie z niej jest objawem złego stylu programowania i że jest generalnie niezalecane. Argumentem na rzecz takiego twierdzenia jest to, że break jest podobny w swoim działaniu do etykiet i “wyklętej” instrukcji goto:

W sumie wyszła z tego całkiem długa polemika, która ujawniła kilka ciekawych faktów. Po pierwsze: przejrzystość kodu jest w całkiem dużym stopniu kwestią subiektywną i o ile jednemu może przeszkadzać brak (lub niewystarczająca ilość) komentarzy, to dla drugiego o wiele ważniejsze może być używanie lub nieużywanie określonych konstrukcji językowych. Po drugie: oprócz wspomnianego już goto czy wywołanego we wspomnianym wątku breaka, do instrukcji potencjalnie niepożądanych swobodnie można zaliczyć bardzo wiele innych rozwiązań – zależnie od upodobań, poczucia ‘słuszności’, bieżącej fazy księżyca i pewnie mnóstwa jeszcze innych kryteriów. I tak dostało się chociażby pętlom “nieskończonym” (typu while(true) lub for(;;)), wspomniano coś o wyjątkach, a sam napomknąłem o instrukcji continue lub “przedwczesnym” return:

Teoretycznie można by wszystkie te konstrukcje usunąć w imię ideologicznej czystości programowania strukturalnego, w którym każdy blok ma dokładnie jedno wejście i wyjście. Ale tu na szczęście wkracza wniosek trzeci: języki programowania używane w praktyce nie są żadnymi doskonałymi modelami, nad którymi należy się zachwycać. To narzędzia i jako takie powinny być przede wszystkim wygodne w użytkowaniu.
Więc nie warto drzeć kotów o sens stosowania break czy nawet goto (która to instrukcja też ma swoje zastosowania) i wydawać ogólne sądy na temat ich ‘nieprofesjonalności’. Bo nawet jeśli ta czy inna instrukcja rzekomo jest zła, to korzystający z niej kod nadal może być dobry, czytelny i łatwy do modyfikacji… Łącznie z refaktoringiem, który tego czy innego breaka może przecież usunąć ;P

Forumowa numerologia

Internetowe fora to podobno następny stopień ewolucji list i grup dyskusyjnych Usenetu. Na pewno mają niezaprzeczalne zalety – jak choćby to, że można się do nich dostać przy pomocy zwykłej przeglądarki (nie potrzeba specjalnych klientów), a ich zawartość jest indeksowana przez co sprytniejsze wyszukiwarki. Ale razem z tymi zaletami “w pakiecie” mają też pewną cechę, którą osobiście uważam za wadę – wprawdzie niezbyt ciężką gatunkowo, lecz stanowiącą według mnie pewien mankament.
Mam tu na myśli panujący na forach kult numerków, którego najważniejszym obiektem jest oczywiście licznik postów opublikowanych przez danego użytkownika. Liczba ta, niby ważna dana osobowa, prezentowana jest prawie zawsze po lewej stronie każdej wypowiedzi (w miejscu, które żartobliwie nazywam ‘nagrobkiem’ :]).

Co w niej takiego złego? Obiektywnie patrząc, to tylko statystka, która nie niesie żadnej znaczącej informacji. Nie mówi ani o stażu danego delikwenta na forum, ani o jego codziennej aktywności, ani o jego poziomie zaawansowania w temacie, którego forum dotyczy, ani o umiejętności stosowania przezeń zasad netykiety. Część z tych informacji można odnaleźć, przyglądając się profilowi ze szczegółowymi informacjami o danym użytkowniku. Jednak one nie są pokazywane przy każdym poście – w przeciwieństwie do wspomnianego licznika postów. Czym więc on jest? Otóż jest to taki “magiczny numerek”, kojarzący się nieodparcie z dziesiątkami liczb występujących w grach (MMO)RPG i których mozolne podbijanie zajmuje wiele godzin. Prawie nic nie znacząca wartość, która może być co najwyżej skorelowana z samooceną tego, który zwraca na nią uwagę. Notabene zdarzało mi się widzieć rozwinięcie owego numerka do karykaturalnej postaci RPG-owej: z paskami życia, many i doświadczenia! Na całe szczęście na warsztatowe forum takie wynalazki (jeszcze) nie dotarły :)
Ażeby dodać przeciwwagę dla licznika postów (podbijanego zarówno przez wartościowe, jak i bezsensowne wypowiedzi), na wielu forach – włączając Warsztat – istnieje karma (choć są warianty tego mechanizmu o innych nazwach). W założeniu każdy użytkownik forum może innemu użytkownik dodać jeden punkt owej karmy, jeśli uzna jakąś jego wypowiedź za pomocną, interesującą lub wartościową. Akt ten nazywa się ‘dokarmianiem’, chociaż użyta w tym znaczeniu nazwa ‘karma’ nie ma rzecz jasna nic wspólnego z jedzeniem :) Tak czy owak, sumaryczna wartość zebranej przez forumowicza karmy jest, podobnie jak licznik postów, wyświetlana obok każdej jego wypowiedzi.

Pomysł na pierwszy rzut oka wydaje się znacznie lepszy niż licznik postów, ale ja uważam, że skutki istnienia obu tych mechanizmów są w gruncie rzeczy podobne. Oba są związane z jakimiś rzekomo znaczącymi liczbami, które mają w jakiś sposób opisywać użytkownika, którego się tyczą – co w domyśle znaczy oczywiście, że im większe one są, tym forumowa twórczość danej osoby jest bardziej wartościowa. Oba są też bardzo narzucające się innym użytkownikom; w końcu nie sposób przeoczyć czegoś, co jest wyświetlane obok każdej wypowiedzi.
I oba mogą sprawić, że będziemy – choćby podświadomie – zwracali uwagę na to, aby “przy okazji” dyskusji na forum podbijać te współczynniki jak najwyżej. Samo to nie będzie dobrze jej służyło, a poziom i przydatność forum może wręcz na tym ucierpieć. Zwiększenie licznika postów polega przecież na, niespodzianka, pisaniu postów – a wiadomo przecież, ze ilość nie musi przekładać się bezpośrednio na jakość. Z kolei polowanie na każdy dodatkowy punkt karmy oznacza dopisywanie swoich pięciu centów do każdego pojawiającego się wątku – zwłaszcza takiego z pytaniem lub prośbą o pomoc – nawet jeśli nie mamy w temacie zbyt wiele do powiedzenia (co może wręcz ograniczać się do zakamuflowanego powtarzania wypowiedzi przedmówców). Trudno się nie zgodzić, że podobne praktyki nie służą dobrze funkcjonowaniu forum jako źródła wiedzy i miejsca do rzeczowej dyskusji oraz zadawania pytań i otrzymywania na nie pożytecznych odpowiedzi.

I dlatego przyznam się do radykalnego poglądu. Gdybym dysponował odpowiednią mocą sprawczą, czym prędzej pozbyłbym się tego rodzaju pseudostatystyk – a przynajmniej schował je głęboko i nie eksponował przy każdej okazji. Na forum wymowni powinni być ludzie, a nie liczby :P

Polityka spójności

Fakt jest oczywisty: moderatorzy są tylko ludźmi i mogą popełniać błędy. Dotyczy to nawet tak wybitnych osobistości, jak moderatorzy forum Warsztatu :) Co więcej, można mylić się na całego i globalnie – czyli na przykład w tak fundamentalnej kwestii jak to, czy wobec tzw. lamerstwa przyjmować postawę ostrą czy względnie łagodną.
Można to jednak zawsze poprawić. Ale sytuacja wygląda o wiele gorzej, jeśli moderatorzy przestają działać jako drużyna i zaczynają wchodzić sobie nawzajem w drogę.

W ten sposób dorobiliśmy na Warsztacie dwóch swego rodzaju “frakcji” moderatorskich. Pierwsza z nich opowiada się za literalnym stosowaniem dość restrykcyjnego regulaminu i stanowczym reagowaniem na wszelkie przejawy wspomnianego już lamerstwa. Druga zaś preferuje raczej łagodne podejście do problemu i służenie pomocą nowo przybyłym, którzy niekoniecznie potrafią jeszcze dostosować się do panujących zasad,
Nietrudno zauważyć, że te dwie grupy mogą często wykonywać sprzeczne ze sobą działania. A to na pewno nie poprawia skuteczności ani jednej, ani drugiej. Dodajmy do tego jeszcze spore grono zwolenników każdej z tych opcji wśród zwykłych użytkowników forum i mamy niewielki chaos.

Poglądowa ilustracja, obrazująca dwa różne podejścia do problemu lamerstwa :)

Nie twierdzę oczywiście, że wśród moderatorów nie mogą występować nawet najmniejsze różnice opinii, bo taki stan rzeczy jest z założenia idealny i niemożliwy do osiągnięcia w rzeczywistości. Według mnie wypadałoby jednak prezentować w miarę spójne stanowisko przynajmniej “na zewnątrz”. W sytuacji, gdy dwie grupy wykonują względem siebie mniej lub bardziej krecią robotę, utrzymanie porządku staje się o wiele trudniejsze. A poza tym przysparza to jeszcze większych dylematów tym moderatorom, którzy chcą zachować jako taką ‘neutralność’, do których to zaliczam swoją skromną osobę :]

Na pierwszej linii

Przez kilka ostatnich dni zaglądałem na forum Warsztatu dość nieregularnie i kiedy w końcu przyjrzałem się mu dokładniej, byłem odrobinę zdziwiony. Mógłbym wręcz powiedzieć, że beze mnie forum jest zostawione niemal na pastwę losu, ale na szczęście nie cierpię na aż taki brak skromności :P Prawdą jest raczej to, że jako moderator nie jestem obecnie odosobniony w potyczkach zaliczeniowo-sesyjnych, na czym jakość sprawowania pieczy nad forum oczywiście nieco cierpi.

Zostało to zresztą zauważone i wywiązała się przy okazji ciekawa dyskusja. Według mnie najciekawszym spostrzeżeniem, jakie w niej padło, jest hipoteza dotycząca przyczyn, dla których na Warsztacie pojawiają się często osoby mające nikłe pojęcie o programowaniu w ogóle – mimo że o wiele lepszym dla nich miejscem są fora ogólnokoderskie, jakich sporo można znaleźć w sieci. Otóż wskazuje ona, że wiele osób zaczyna się interesować programowaniem głównie dlatego, że chce pisać właśnie gry. Wszelkie problemy, na jakie nieuchronnie natrafiają, uważają więc za związane z programowaniem gier. Nie zdają sobie sprawy, że osoba rozpoczynająca przygodę z kodowaniem z zupełnie innego powodu również z dużym prawdopodobieństwem może natrafić na podobne kłopoty. Cel (tworzenie gier) wydaje się im bowiem o wiele ważniejszy niż środek (nauka programowania), szukają więc pomocy w środowisku związanym z tym pierwszym.
I tak Warsztat staje się naturalnym miejscem, do którego początkujący programiści (z aspiracjami bycia programistami gier) kierują swoje kroki. Dla bardziej doświadczonych bywalców wydaje się to niezmiernie dziwne. Przecież “wiadomo”, że aby zająć się gamedevem, należy wpierw być dobrym programistą w sensie ogólnym. No cóż, rzecz w tym, że właśnie nie wiadomo – a przynajmniej nie wiedzą tego ci, którzy powinni.

Jeżeli tezę tę uznamy za prawdziwą, to wiemy już, skąd się bierze ten strumień newbies, przepływających codziennie przez forum. Aby go powstrzymać, można oczywiście budować kolejne (coraz silniejsze) tamy regulaminów i moderacji, ale chyba bardziej zależałoby nam na skierowaniu go na inne – właściwe – tory. A do tego droga jest tylko jedna: uświadamiać, że programistą gier nie zostaje się w chwili, gdy rozpoczyna się naukę jakiegoś języka i że jest to dopiero początek bardzo długiej drogi. Ładnie obrazuje ją na przykład stworzone przez Rega drzewko umiejętności programisty gier.

Nowy artykuł

W święta podobno się nie programuje, więc wziąłem się chwilowo za coś innego :) Postanowiłem więc zrealizować pomysł na artykuł, który przyszedł mi do głowy kilka dni temu – głównie pod wpływem kilku pytań o podobnej tematyce, jakie przewinęły się na forum Warsztatu.
Tak powstał tekst o nieco tajemniczym tytule Pętla czasu rzeczywistego, który w rzeczywistości jest prostym omówieniem prawidłowego sposobu konstrukcji głównej pętli gry i uaktualniania jej stanu zależnie od czasu – tak, by gra działała tak samo niezależnie od wydajności sprzętu. Sprawy to dość proste, ale ważne i najwyraźniej zbyt często pomijane. Myślę więc, że taki artykuł ma niezerową szansę, żeby komuś się przydać :)

Standard i Visual C++ 2005

Zainspirowany pewnym wątkiem na forum Warsztatu, traktującym o rzekomych poważnych niezgodnościach między standardem C++ a kompilatorem zawartym w MS Visual C++ 2005, postanowiłem nieco dogłębniej zbadać tę sprawę. Jak dotąd z owych niezgodności kojarzyłem tylko brak wsparcia dla szablonów eksportowanych – czyli “magicznego” słówka export, pozwalającego na rozdzielanie kodu szablonowego na pliki nagłówkowe i pliki .cpp tak samo, jak zwykłego. Nie jest to zresztą wielkie wykroczenie, jako że kompilatory wspierające szablony eksportowane można pewnie policzyć na palcach jednej ręki, a sam mechanizm też nie należy do szeroko znanych.

Co z innymi niezgodnościami? Odwołanie do dokumentacji Visual C++ przynosi ich jeszcze kilka. Z ciekawszych – oprócz braku obsługi słowa export, o którym już wspomniałem – mogę wymienić:

• Ułomność preprocesorowego operatora # (tzw. łańcuchującego – stringizing operator), który zawiedzie, jeśli zastosujemy go względem stałej napisowej zawierającej sekwencje ucieczki (ciągi rozpoczynające się od znaku backslash: \n, \t, itd.).
• Możliwość, że obiekty nie posiadające żadnych pól będą dzieliły miejsce w pamięci (którego i tak nie zajmują) z innymi obiektami. Standard C++ wymaga natomiast, żeby każdy obiekt miał unikalną lokalizację w pamięci operacyjnej w trakcie całego swojego istnienia (obiektu, nie standardu C++ ;]).
• Brak wykorzystania specyfikacji wyjątków (instrukcji throw (typ_wyjątku)). Innymi słowy, w Visual C++ nie sprawdza się, czy funkcja wyrzuciła wyjątek takiego samego typu, który wcześniej został w niej zadeklarowany.
• Pewne ograniczenia liczbowe, jak choćby: liczbę poziomów zagnieżdżenia bloków kodu (VC++ obsługuje 64, standard rekomenduje 256), kwalifikatorów dostępu dla jednej nazwy (127 zamiast 256) czy parametrów szablonu (64 przeciwko 1024).

I to mniej więcej tyle. Być może kogoś zmartwi brak możliwości napisania algorytmu ze 100 zagnieżdżonymi pętlami lub szablonu z tyloma parametrami, ale osobiście mam co do tego pewne wątpliwości :)