Reminiscencje Twórcy Systemów cz. 11: Uczelnia zaskakuje na finiszu

 Ostatni rok studiów zaczynam w październiku 2004. Pracuję już od pół roku, dzięki zdobytemu know-how po raz kolejny przeprojektowuję swój engine do gier. Na nim buduję opisaną wcześniej grę strategiczną Historical Wars. 

Największe zaskoczenie przychodzi z kierunku, z którego już nie spodziewałem się niczego odkrywczego. Na piątym roku studiów mamy przedmiot “Automaty i języki formalne”, na którym poznajemy jak tworzy się kompilatory. Nie zrozumcie mnie źle - nie pozjadałem wszystkich rozumów, widziałem jak wielkie jest morze tematów, których nie ogarniam. Ale po odejściu przedmiotów inżynierskich (druty, półprzewodniki itp.) kolejne przedmioty wyglądały do siebie podobnie; można je było przypisać z grubsza do czterech grup:

- fouriero-pochodne, czyli różne systemy rozpoznawania wzorców (obraz, dźwięk, “AI”),

- inżynieria oprogramowania, czyli pogaduchy o testowaniu, metodach top-down, synergie i inne specjalności akademików, którzy skończyli programować dwie dekady wcześniej (a może nawet nigdy nie zaczęli),

- algorytmy (numeryka, grafy, grafika itd.), które same w sobie były ciekawe i często trudne, ale nie wykraczały poza to, z czym spotykałem się od lat,

- sieci komputerowe, konfiguracja, administracja.

“Automaty” pokazują rewolucję w myśleniu i rozwiązują dylematy, które blokowały mnie przy programowaniu funkcyjnym. Dotychczas naczelną zasadą było: nigdy nie używaj rekurencji, nie dość że są wolniejsze od pętli, to jeszcze mogą przepełnić stos. Okazuje się, że to rekurencja jest królową programowania, zapisujesz kilka reguł i jesteś w stanie przeczytać cały kod języka programowania.

Już po kilku miesiącach w pracy zacząłem pierwsze podejścia do własnego języka, ale podchodziłem do tego jak wszyscy wokół: tworzysz jakieś słowa kluczowe, operacje arytmetyczne, wywołanie funkcji, blok IF-ELSE, pętla, definiowanie funkcji. Ewaluacja skryptu polega na skanowaniu kodu linia po linii spodziewając się tych kilku elementów języka. Bardziej złożone operacje programujesz w engine i udostępniasz wyżej do skryptu. Ma to wiele zalet, jak prostota, pozwalająca współtworzyć logikę gry nie-programistom, ale też zasadnicze wady: język jest bardzo ograniczony, bo dodanie kolejnej funkcjonalności generuje mnóstwo zależności. Pamiętam, jak raz zastosowałem w pracy rekurencję i w zupełnie innym miejscu gra się freezowała - okazało się, że projektant skryptu założył, że funkcja nie może wywołać sama siebie więcej niż 8 razy. Podobne problemy występowały z zagnieżdżaniem IF-ów. Programiści się nauczyli, żeby pewnych rzeczy nie robić, bo nie wiadomo jak zachowa się cały system i to wystarczyło, by wszystko działało przez lata. Drugi problem to wydajność - teraz wygląda to już inaczej, ale wtedy np. nie korzystaliśmy ze zmiennych lokalnych, bo ich dynamiczne tworzenie i usuwanie zjadało CPU. Podłączenie skryptu do np. 100 animacji zażynało procesor, więc trzeba było kombinować z tablicami i kod już nie wyglądał czysto. 

Gdybym zetknął się z automatami na 1 a nie 5 roku, moja edukacja potoczyłaby się inaczej. Kamil przerabiał te tematy na uniwerku we Wrocławiu od samego początku. Polibuda stawiała akcent na inne aspekty, co zresztą jest zrozumiałe, bo rynek najczęściej nie potrzebuje błyskotliwych rozwalaczy algorytmów, tylko rozkładaczy dokumentacji na czynniki pierwsze. Pisałem o tym wyborze w cz. 2 cyklu (pierwsza mapa). Z drugiej strony - gdybym nie siedział wcześniej tyle w asemblerze, nie miałbym podstaw, żeby napisać szybki kompilator. “Automaty” otworzyły mi oczy, że mogę podejść do własnego języka znacznie szerzej.