Tytułowe pytanie zadają niekiedy osoby, zaczynające swoją przygodę z programowaniem. Cóż, nic dziwnego. Istnieją na rynku książki, w których przykłady kodu źródłowego zawierają polskojęzyczne nazwy zmiennych, funkcji i klas. Oczywiście przeplatają się one z angielskimi słowami kluczowymi, stanowiąc w rezultacie obraz co najmniej niepoważny. Gdy korzystająca z takich źródeł osoba, nie mogąc poradzić sobie z jakimś problemem, udaje się po poradę na forum dyskusyjne czy portal społecznościowy, dzieląc się przy tym fragmentami swojego kodu, to pierwszym, co zostaje jej zwykle wytknięte jest używanie w tymże kodzie języka polskiego. Być może ów świeży programista przeczyta tam czasami stanowcze słowa, jakoby pisanie kodu po polsku było absolutnie niedopuszczalne. Czy jednak jest tak w rzeczywistości? Ja uważam, że nie do końca, i w niniejszym wpisie postaram się skutecznie obronić tezę, że istnieją sytuacje, w których programista może, a nawet powinien pisać kod po polsku.

Przypadek pana Józefa

Odważnie? Kontrowersyjnie? Bynajmniej! Cofnijmy się nieco w przeszłość i wyobraźmy sobie Pana Józefa, który jako zdolny inżynier objął właśnie nowe stanowisko. Do jego obowiązków będzie należeć między innymi programowanie komputera ZAM-41. Jest to nowoczesna jak na swoje czasy maszyna, więc pisanie kodu dla niej przeznaczonego będzie czystą przyjemnością. Żegnajcie assemblery, witajcie wysokopoziomowe języki programowania! Jedną z takich właśnie technologii używanych do tworzenia programów dla wspomnianej powyżej maszyny jest SAKO. Czy poniższy fragment kodu w tym języku wygląda spójnie?

Oczywiście, że nie! Dlaczego? Ponieważ mamy tutaj do czynienia z sytuacją odwrotną – słowa kluczowe są w języku polskim, zaś nazwy zmiennych po angielsku. Wniosek może być tylko jeden: nie chodzi, aby zawsze pisać kod po angielsku. Rzecz w tym, by tworzyć kod odpowiedni dla konkretnego języka programowania. Owa odpowiedniość to rzecz jasna nie tylko nazewnictwo, ale i stosowane paradygmaty oraz konwencje. Nie jest najlepszym pomysłem forsować pewne sposoby programowania w językach, dla których są one obce lub nienaturalne. Piszesz w Pythonie? Zatem pisz w stylu, który odpowiada temu właśnie językowi, zamiast nieefektywnie powielać schematy znane z innych technologii. Piszesz w SAKO? Pisz po polsku.

Narodziny SAKO

Powróćmy jednak od spostrzeżeń natury ogólnej do konkretów związanych z naszym SAKO, aby dowiedzieć się kto w ogóle wpadł na pomysł stworzenia polskojęzycznego języka programowania. I to nie jakiegoś tam ezoterycznego języka zrobionego dla zabawy ani języka czysto edukacyjnego (jak np. LOGO, który też przecież występuje w wersjach nieanglojęzycznych), ale poważnej technologii, wykorzystywanej w nauce i przemyśle.

Prace nad Systemem Automatycznego Kodowania (bo tak właśnie brzmi rozwinięcie skrótu SAKO) rozpoczęły się w roku 1959 w Zakładzie Aparatów Matematycznych Polskiej Akademii Nauk. Język ukończony został w roku 1960 i w ciągu następnych lat służył do programowania polskich komputerów: XYZ, ZAM-2, ZAM-21 oraz ZAM-41, zaś pierwszy translator, który tłumaczył autokod SAKO na asembler SAS (System Adresów Symbolicznych) uruchomiono w roku 1962. Leon Łukaszewicz, profesor informatyki z licznymi dokonaniami i jeden ze współtwórców SAKO, tak pisał o tym języku na łamach magazynu Informatyka: „Było to opracowanie w Polsce pionierskie i przez wiele lat w dziedzinie języków proceduralnych i w tej skali – jedyne”. Z kolei o samym kompilatorze, składającym się z około 5000 rozkazów maszynowych, w wydanej w 1961 roku książce o języku SAKO pisano, iż „zastępuje on całkowicie doświadczonego i sprawnego programistę” (programistę asemblera oczywiście). Wart uwagi jest też inny fragment z tej samej książki, który głosi, że czas, który pozwala specjalistom z różnorodnych dziedzin na przyswojenie sobie zasad programowania w SAKO to zaledwie kilka dni.

Rozdziały, nadmiar i dziesiętna skala

Tworzone w SAKO programy, niczym dobra powieść lub gra fabularna, składały się z rozdziałów. Nie był to żaden zamiennik funkcji, bowiem ich również można było używać, ale sposób związany z ograniczoną pamięcią, którą dysponowały ówczesne komputery. Dość wspomnieć, że maszyny XYZ oraz ZAM-2 pozwalały na przechowywanie w pamięci wewnętrznej jedynie 1024 słów krótkich (18-bitowych). Nietrudno sobie więc wyobrazić, że zmieszczenie w niej co bardziej rozbudowanych programów mogłoby stanowić problem. Na szczęście komputery te posiadały też dostęp do pamięci bębnowej, z której odczyt był wprawdzie około 40 razy wolniejszy, ale w zamian oferowała ona aż 16 (lub 32 w przypadku ZAM-2) razy więcej miejsca. Zastosowanie podziału programu na rozdziały umożliwiało przechowywanie w pamięci wewnętrznej tylko aktualnie przetwarzanego rozdziału i umieszczenie pozostałych w obszerniejszej pamięci bębnowej. W temacie pamięci bębnowej warto przy tym wspomnieć, iż zapewniała ona statyczne adresowanie, a pula dostępnych adresów rozpoczynała się od liczby 0.

Pierwsze wersje SAKO pozwalały na używanie ułamków jedynie w formie liczb o stałym przecinku. Programista musiał każdorazowo określać ile bitów chce przeznaczyć na zapis części dziesiętnej, a ile na przechowywanie części ułamkowej liczby. Tak zdefiniowany sposób zapisu liczby w komórce pamięci nosił nazwę skali dziesiętnej (jeżeli określaliśmy ile cyfr ma znajdować się przed przecinkiem przy zapisie dziesiętnym) lub skali binarnej (jeśli posługiwaliśmy się systemem binarnym). Skale te były oczywiście wzajemnie przeliczalne na siebie (zob. rys. poniżej), a ustawianie właściwej skali odbywało się za pomocą rozkazów:

• SKALA DZIESIETNA PARAMETROW oraz SKALA BINARNA PARAMETRÓW dla liczb, które zostały explicite wyrażone w programie
• USTAW SKALE DZIESIETNIE oraz USTAW BINARNIE SKALE dla liczb, które stanowiły rezultat obliczeń

 

Późniejsze wersje (m.in. dla komputera ZAM-42) wprowadziły już normalne liczby zmiennoprzecinkowe, czyli takie, które definiowane są za pomocą cechy i mantysy (notacja naukowa). Cały czas problemem pozostawał jednak fakt, że pojedyncze zmienne nie były w stanie przechowywać zbyt dużych liczb. Jeżeli w wyniku obliczeń powstała liczba, która wychodziła poza zakres, to pojawiał się tzw. nadmiar. Programista mógł sprawdzić wartość wskaźnika nadmiaru i obsłużyć taką sytuację przeskokiem do odpowiedniego rozkazu, np.:

Więc jak z tym kodem po polsku?

Na zakończenie tej krótkiej historii o języku SAKO powróćmy jeszcze do tego, co stało się punktem wyjściowym naszych rozważań, czyli do nazewnictwa zmiennych. To prawda, że do zaprezentowanego autokodu zdecydowanie najlepiej pasują polskojęzyczne nazwy zmiennych, funkcji i rozdziałów. Nie ma jednak co ukrywać, że czasy, w których programowano maszyny ZAM bynajmniej nie były epoką samoopisującego się kodu. Parametry i zmienne często oznaczane były po prostu pojedynczymi literami i w gruncie rzeczy nie ma się co dziwić ówczesnym programistom. Nadawanie dłuższych nazw mogło być źródłem pomyłek i problemów. Dlaczego? Otóż zmienne w SAKO charakteryzowały się tym, że własność identyfikującą posiadały tylko 4 pierwsze (nie licząc spacji) znaki. A zatem wszystkie z poniższych zmiennych były uznawane przez program za ten sam obiekt:

• SUMA ROWEROW
• SUMA PILEK
• SUMA KASKOW

Nieco lepiej sytuacja kształtowała się w przypadku rozdziałów – tutaj rozróżnialnych było aż 10 pierwszych znaków. Ale coś za coś – własność identyfikującą w przypadku podprogramów (funkcji) miały już jedynie 3 pierwsze znaki (i oczywiście nie mogły się one pokrywać z nazwami funkcji wbudowanych).

Jaki z tego wszystkiego morał? Osobiście uważam, że historia polskiej informatyki jest niezwykle ciekawa, a wysiłek naszych rodzimych naukowców, zwłaszcza uwzględniając niesprzyjające uwarunkowania polityczne, wart jest docenienia. Interesującą lekturą dla osób, które podzielają ten punkt widzenia mogą być archiwalne numery magazynów Maszyny Matematyczne oraz Informatyka (dostępne online, polecam!) Zaś jeśli chodzi o koncepcję nieanglojęzycznych języków programowania, to dziś nikt nie ma już chyba wątpliwości, że nie przetrwała ona próby czasu i w zglobalizowanym świecie wszyscy programujemy w jednym języku. Całe szczęście!

Źródła

1. J. Śliwieński, B. Buśko, 1000 słów o komputerach i informatyce, 1976.
2. L. Łukaszewicz et. al., System Automatycznego Kodowania SAKO, Warszawa 1961 (link).
3. K. Balińska-Deloff, J. Szmelter, Język programowania SAKO dla ZAM-41, Warszawa 1971 (link).
4. Informatyka, nr 3/1971 (link).