Budujemy wieżę Babel

Z językami programowania dzieje się odwrotnie: zamiast rozwijać i wzbogacać te, które już istnieją, tworzymy, w miarę pojawiania się potrzeb, coraz to nowe. Jest ich już ponad dwa tysiące, z czego niecała jedna trzecia w aktywnym użyciu. Gdy wyłączyć z nich języki maszynowe, żaden nie nadaje się do wszystkiego. Argumentem przeciwnym może tu być opinia, że język programowania należy traktować bardziej jako narzędzie niż w dosłownym znaczeniu język. Wówczas - przez analogię - łatwo stwierdzić, że narzędzia uważane za uniwersalne wcale takie nie są i zakres ich stosowania jest bardzo ograniczony. Podjęto zresztą kiedyś próbę stworzenia takiego języka programowania, który miał być uniwersalny - rolę taką miał pełnić PL/I. O próbie tej można rzec wiele z wyjątkiem jednego - że się powiodła.

Bujny ogród

W czasach, gdy jeszcze zajmowałem się programowaniem, byłem klasycznym przypadkiem programisty assemblerowego i nie miałem najlepszego mniemania o takich językach, jak Fortran czy Cobol. Z tym ostatnim zresztą częściej miałem związek poprzez jego kompilator (napisany w assemblerze) niż bezpośrednio. Doskonalenie kompilatora wymagało jednak znajomości składni i reguł poddawanego kompilacji języka na poziomie wykraczającym na ogół poza wiedzę przeciętnego programisty, co nie oznacza z kolei, że sama taka znajomość pozwalałaby na pisanie programów sprawniej, niż to robili programiści.

Znajomość taka pozwalała jednakowoż dopatrywać się związków między Fortranem a C i nie kojarzyć języka BASIC z komputerem Atari czy Spectrum (BASIC powstał 20 lat wcześniej od tych komputerów). Nade wszystko jednak, choć dopiero po bardzo wielu latach, oddaję hołd Cobolowi. Kto miał okazję spróbować odmiany Fujitsu-Cobol, ten wie, że nie ustępuje on w możliwościach takiemu językowi, jak Visual Basic.

Obok Cobolu w wydaniu Fujitsu istnieje również, chyba obecnie najpopularniejszy (i sam mający kilka odmian), Cobol firmy Micro Focus. I właśnie odmiany języków programowania to jest to, co obecnie stanowi kolejną zmorę tej dziedziny i jest de facto ucieczką od jakichkolwiek prób normalizacji. Gdy kolejny raz sięgnąć po porównanie z językami naturalnymi, okazuje się, że ludzie mówiący różnymi narzeczami tego samego języka odbierają jednak sens wypowiedzi. Dla komputerów jest to nieosiągalne.

By sięgnąć po pierwsze z brzegu przykłady - na początku lutego br. minęło pięć lat od momentu, gdy konsorcjum W3C zatwierdziło normę języka XML. Nie odbierając temu językowi (który nie jest uważany za język programowania przez programistów!) żadnych z licznych zalet i nie kwestionując jego niemal rewolucyjności, nie można też nie zauważyć, że przez te pięć lat mamy w swoistym dorobku blisko 100 (słownie: sto!) odmian tego języka. Swoiste stopniowe "rozchodzenie się" specyfikacji poszczególnych jego odmian z pewnością doprowadzi do tego, że stanie się on istotną przyczyną problemów, dla rozwiązania których powstał.

Trochę starszy, bo liczący lat kilkanaście, Python, zdążył w tym czasie skrzyżować się z Javą, z czego powstał Jython. Ten zaś ma trochę z każdego z "rodziców", ale nie zastąpi w pełni żadnego z nich.

Polemizując z moją tezą, że jednak mamy do czynienia z syndromem Wieży Babel, można by sięgnąć po przykłady języków, które trwają od lat. Dobrze przecież ma się Fortran (50 lat), Cobol (niewiele mniej) i dobiegający czterdziestki C. W podobnym wieku jest Basic, a pośród mnogości, jakie przyniósł Internet, nawet Pascal może uchodzić za weterana.

Sny o uniwersalności

Powie ktoś: no tak, ale mamy przecież obiekty i ich klasy. I podobnie jak wygodniej było zatrudnić nowego, wychowanego na obiektach programistę, niż zmienić religię tego, dla kogo polecenie goto czy jump istniało od początku świata, tak łatwiej jest stworzyć nowy język, niż dorabiać obiektowość do istniejącego. Przeczą temu jednak przykłady takich weteranów, jak dopiero co wspomniany Cobol, C czy Pascal, które istniały na długo przed obiektami, a dziś są dostępne również z nimi.

Przykłady poleceń zmieniających kolejność wykonywania instrukcji programu, użyte powyżej w roli symboli mających oznaczać programistów przedobiektowych, przypominają o jeszcze jednej, popularnej kiedyś, metodyce pisania programów - programowaniu strukturalnym. Potocznie i powierzchownie kojarzone właśnie z unikaniem stosowania tych poleceń programowanie strukturalne było znaczącym punktem na drodze do metod obiektowych. Można nawet zaryzykować twierdzenie, że nie byłoby obiektów bez programowania strukturalnego. Można pójść jeszcze dalej i próbować twierdzić, że obiekty z kolei dały podstawy do Web Services. Aby uniknąć niejasności - nie chodzi tu o przechodzenie jednej metodyki w drugą poprzez jej zachowanie i wzbogacenie. Mam na myśli raczej zmiany w sposobie postrzegania możliwości tworzenia niedużych, a za to dobrze sprawdzonych i uniwersalnych modułów programów komputerowych, za jakie przez lata uchodziły np. funkcje biblioteczne programów fortranowych.


TOP 200