Reminiscencje Twórcy Systemów cz. 10: Programowanie funkcyjne i sposób na naukę trudnych zagadnień

W pierwszej mapie (cz. 2) zwróciłem uwagę na konsekwencje obranej (nieświadomie) na początku ścieżki rozwoju. Moja droga w programowaniu wiodła przez asemblera i C, ponieważ w tych językach pisali wszyscy zawodowcy, jakich znałem. Ponadto do wizualizacji algorytmów i struktur danych wykorzystywano grafy i schematy, które łatwo się przekładały na języki imperatywne. Wiedziałem jak pracuje maszyna, więc myślałem jak maszyna. Na program składały się sekwencje instrukcji wykonywane jedna po drugiej, w każdej chwili mogłem wcisnąć w debuggerze pauzę i sprawdzić stan programu.

Taki sposób myślenia był i pozostaje wiodący wśród programistów. Wystarcza do tworzenia dobrych systemów. Jest naturalny, ponieważ wynika bezpośrednio z konstrukcji najpopularniejszych języków programowania.

Od drugiego roku studiów moje umiejętności programistyczne wykraczają już znacząco poza średnią. Na trzecim wydaje mi się, że poznałem już wszystko i teraz głównym problemem jest nauka narzędzi, w których się pracuje, a nie samej sztuki programowania. Błogi stan przerywają ćwiczenia ze Sztucznej Inteligencji, na których piszemy programy w Prologu. Piszemy to zresztą powiedziane na wyrost: dostajemy gotowe programy, w których mamy dodać kilku reguł, żeby otrzymać prawidłowy wynik. Jeśli poprawnie zdefiniujesz wszystkie reguły, program magicznie się zadzieje.

Kod programów wygląda jak starożytny manuskrypt z przepisem na eliksir. Pytam wszystkich kumatych “jak to się dzieje”, “jak to przetłumaczyć na ciąg przyczynowo-skutkowy”, ale nikt nie zna odpowiedzi. Z perspektywy czasu widzę, że gdybym przyjął inne kryteria zapytań, mógłbym dotrzeć do sedna szybciej. Nie miałem przecież problemu z SQL, ponieważ tam z założenia przyjąłem inne zasady niż w językach tłumaczonych na kod maszynowy. 

Mój guru Kamil, z którym robiłem na przełomie wieków grę (ja design i grafika, on programowanie) studiuje informatykę na Uniwersytecie Wrocławskim i podsuwa mi język funkcyjny OCaml jako prostszą alternatywę dla Prologa. W OCamlu można operować tymi magicznymi listami x::xs tudzież head::tail ale jak już nie dajesz rady, możesz napisać wszystko na zwykłej tablicy z indeksami jak w C++. No i przede wszystkim widzisz deterministyczny flow. Jestem jednak tak silnie osadzony w myśleniu sekwencyjnym, że nieprawidłowo postrzegam pattern matching i gubię najsilniejsze atuty programowania funkcyjnego. Z perspektywy czasu ciężko mi już sobie przypomnieć, dlaczego tego nie rozumiałem, ale fakt jest taki, że po kilku tygodniach porzucam OCamla i wracam do C++. Do tworzenia gier nie potrzebuję funkcyjnych wodotrysków. Za dużo było tam typów, transformacji funkcji i innych “nieżyciowych” zagadnień, a za mało praktycznych zastosowań.

A jednak to programowanie funkcyjne zaważy później mocno na mojej karierze. Opiszę również metodę nauki, którą stosuję do dziś. Nie jest to nic wielkiego, zapewne wielu z was ją zna, ale wielu też nie jest jej świadomych. Otóż gdy 3 lata później zasiadłem ponownie do programowania funkcyjnego, to mój postęp w nauce był błyskawiczny. Wszystko co sprawiało mi problemy w OCamlu za pierwszym razem, rozumiałem już w sposób naturalny. Tak jakby mózg przez te lata gdzieś przepracował problemy. Z marszu przeskoczyłem wszystkie pierwotne zadania i wszedłem na poziom wyżej.

Wtedy uświadomiłem sobie, że żaden wysiłek nie idzie na marne. Jeżeli natrafiam na zagadnienie wykraczające poza mój aktualny stan pojmowania, ale wiem, że będę go w życiu potrzebował, po prostu biorę je na klatę. Czytam, próbkuję, tworzę koncepcje, nasiąkam teorią. A potem, gdy na horyzoncie pojawiają się zadania o wyższym priorytecie, porzucam naukę. Wracam do niej po tygodniach, miesiącach a czasem latach - i wtedy ten drugi start jest o wiele prostszy. Samo utworzenie zalążka nowej teorii wystarcza, by umysł zaczął przeprowadzać symulacje. Zaczynam patrzeć inaczej na nowe sytuacje, ponieważ pojawił się kolejny punkt widzenia.

Metodę tę stosuję z premedytacją od 15 lat i dzięki niej stałem się ekspertem w wielu oddalonych od informatyki dziedzinach.