Kod źródłowy Leonarda da Vinci

Kiedy byłem małym chłopcem (hej!) i programowałem na ZX Spectrum, moim marzeniem było posiadanie kompilatora. Otóż dzięki kompilatorowi kod napisany w "przyjaznym" (przynajmniej wedle ówczesnych standardów) BASIC-u działał kilkadziesiąt razy szybciej od kodu interpretowanego.

Kiedy byłem małym chłopcem (hej!) i programowałem na ZX Spectrum, moim marzeniem było posiadanie kompilatora. Otóż dzięki kompilatorowi kod napisany w "przyjaznym" (przynajmniej wedle ówczesnych standardów) BASIC-u działał kilkadziesiąt razy szybciej od kodu interpretowanego.

Jednocześnie nie trzeba było programować w assemblerze, którą to umiejętność posiadłem parę lat później. Przypomnę, że jednym z najlepszych - jeśli nie najlepszym - kompilatorem BASIC-a na ten komputer był ToBoS-FP stworzony przez duet Skaba & Borkowski z Torunia. Przez większość życia zawodowego (tj. od momentu, gdy zarobiłem pierwsze pieniądze na programowaniu w Clipperze 87) czymś najnaturalniejszym na świecie była dla mnie praca z kompilatorem (a dokładniej: ze zintegrowanym środowiskiem programistycznym, którego elementem był kompilator) i właściwie dopiero po wielu latach zrozumiałem, że tryb pracy, w którym po wykonaniu szybkiej zmiany trzeba od nowa skompilować i uruchomić program (co często trwało wiele minut), to coś najnaturalniejszego na świecie i tak właśnie być musi.

Dopiero po latach zrozumiałem, że interpreter nie jest wcale takim złym pomysłem i znakomicie przyspiesza pracę nad programem, przede wszystkim eliminując uciążliwe i czasochłonne rekompilacje po każdej zmianie. Zintegrowane środowisko Visual Studio .NET jest najdoskonalszym narzędziem programistycznym, jakie kiedykolwiek widziałem, a jego siła płynie między innymi z pracy z interpreterem (a dokładniej mówiąc - z maszyną wirtualną CLR). W sukurs programistom przyszło bezpieczeństwo - program interpretowany da się umieścić "w skrzynce" maszyny wirtualnej. Renesans interpretera umożliwiła też technologia krzemowa - dzięki miniaturyzacji i przyspieszaniu układów przestało mieć znaczenie, że program interpretowany wykonuje się 100 razy wolniej od kompilowanego, skoro w praktyce jest to różnica między 10 µs a 1 ms.

Śmiem twierdzić, że większość programów dzisiaj jest interpretowanych, nie kompilowanych. Zarówno HTML - swoisty "program dla przeglądarki", szeroko stosowane języki skryptowe (perl, python, JavaScript, VBScript) oraz środowiska oparte na maszynie wirtualnej (Java, CLR) - wszystkie te technologie mają wspólną cechę: program zapisany jest w nich w pewnego rodzaju kodzie pośrednim, zamienianym na instrukcje procesora podczas wykonania programu, nie zaś podczas kompilacji.

Gdyby ktoś powiedział mi piętnaście lat temu, że nikt nie będzie kupował kompilatorów popularnych języków programowania, bo praktycznie wszystkie produkty, które kiedyś miały charakter komercyjny, będą dostępne dzisiaj za darmo ( np. zhttp://www.thefreecountry.com/compilers/cpp.shtml ); że czasochłonny cykl popraw-kompiluj-uruchom odejdzie do lamusa, że najszybciej rozwijać się będą języki skryptowe itd., uznałbym go za wariata. Przyszłość kompilatora wydawała mi się wówczas jasna jak słońce.

Przyznam, że rozwój narzędzi do programowania zaskoczył mnie. I kocham informatykę między innymi za to, że ciągle mnie zaskakuje.

PS. Jeżeli ktoś się zastanawia, jaki ten felieton ma związek z bestsellerem Dana Browna, to uprzejmie odpowiadam, że żaden - oryginalny tytuł mówił o renesansie interpretera. Ale patrzę na szaleństwo, które ogarnęło konsumentów, każąc im np. kupować płytę z "muzyką inspirowaną Kodem Leonarda da Vinci" i pomyślałem, że może i nam coś skapnie z popkulturowego tortu. W końcu w informatyce tyle mówi się o kodach... Mam nadzieję, że Redaktor Naczelny i wydawnictwo przywitają tę inicjatywę z uznaniem i zaoferują mi procent od zwiększonych wpływów.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200