PL/I (Programming Language One) to język programowania stworzony przez IBM w latach 60. jako „uniwersalny język” — mający zastąpić jednocześnie Fortran (obliczenia naukowe), COBOL (biznes) i asembler (programowanie systemowe). Był to jeden z najbardziej ambitnych projektów w historii języków programowania — i jeden z najbardziej kontrowersyjnych. PL/I miał wszystko: procedury, rekurencję, wyjątki, tasking, preprocessor, struktury danych, I/O i setki innych features.

Dla współczesnego developera PL/I jest fascynujący, bo pokazuje, co się dzieje, gdy projektanci języka próbują zadowolić wszystkich. PL/I był potężny, ale skomplikowany. Był elastyczny, ale nieprzewidywalny. Był używany w krytycznych systemach (NASA, banki, telekomunikacja), ale narzekali na niego niemal wszyscy użytkownicy. Edsger Dijkstra napisał o PL/I jeden z najostrzejszych listów w historii informatyki.

Mimo kontrowersji, PL/I przetrwał dekady i jest nadal używany — szczególnie w systemach mainframe’owych. A jego idee (wyjątki, tasking, preprocessor) wpłynęły na dziesiątki późniejszych języków.

Spis treści

Krótka historia i ewolucja

PL/I został zaprojektowany w 1964 roku przez zespół IBM pod kierownictwem George’a Radina. IBM chciał stworzyć jeden język, który zastąpiłby Fortran, COBOL i asembler na systemie System/360. Projekt początkowo nazywał się NPL (New Programming Language), potem MPL (Multi-Purpose Language), aż wreszcie PL/I — bo „PL” było już zajęte.

Pierwszy kompilator PL/I (PL/I F) ukazał się w 1966 roku i był… problematyczny. Był wolny, generował nieefektywny kod i miał setki bugów. IBM przepisał go od zera jako PL/I Optimizer (1970) i PL/I Checkout Compiler — ten drugi był szybki i miał genialną diagnostykę, ale nie produkował zoptymalizowanego kodu. Dopiero PL/I Optimizing Compiler dał programistom jedno narzędzie, które robiło wszystko dobrze.

W latach 70. i 80. PL/I był szeroko używany w systemach korporacyjnych i rządowych. NASA używała PL/I w programie kosmicznym. Banki, firmy ubezpieczeniowe i telekomunikacyjne budowały w PL/I systemy transakcyjne. Standard ISO PL/I ukazał się w 1976 roku.

W latach 90. IBM stworzył VisualAge PL/I — nowoczesne IDE z debuggerem i profilerem. Dziś PL/I jest nadal wspierany przez IBM jako Enterprise PL/I for z/OS i jest używany w systemach mainframe’owych na całym świecie. Migracja z PL/I jest kosztowna, więc wiele organizacji po prostu utrzymuje istniejący kod.

Kluczowe cechy i filozofia

PL/I jest językiem proceduralnym z niezwykle bogatym zestawem features. Oto najważniejsze:

System typów jest rozbudowany: FIXED i FLOAT (z precyzją), DECIMAL i BINARY, CHARACTER (varying i fixed), BIT, POINTER, AREA (surowa pamięć). Możesz definiować struktury (odpowiednik rekordów) z poziomami zagnieżdżenia. PL/I ma nawet PICTURE specification (jak COBOL) do formatowania danych.

Obsługa wyjątków (CONDITION w terminologii PL/I) była rewolucyjna. ON ENDFILE, ON ZERODIVIDE, ON SUBSCRIPTRANGE — programista mógł definiować handlery dla niemal każdego warunku błędu. To koncepcja, która trafiła do C++, Javy i Pythona dekady później.

Tasking (współbieżność) był wbudowany: TASK tworzył równoległy proces, EVENT służył do synchronizacji. PL/I miał tasking w 1966 roku — Java dostała threads dopiero w 1995.

Preprocessor w stylu makr pozwalał na metaprogramowanie: %DECLARE, %IF, %DO, makra z parametrami. To było potężne, ale prowadziło do nieczytelnego kodu.

Scope i lifetime były elastyczne: zmienne mogły być STATIC, AUTOMATIC (na stosie), BASED (dynamicznie alokowane) lub CONTROLLED (na stosie z jawnym push/pop). PL/I dawał programiście pełną kontrolę nad zarządzaniem pamięcią.

Filozofia PL/I to „daj programiście wszystko, czego może potrzebować”. Problem polegał na tym, że „wszystko” oznaczało język tak duży, że nikt nie znał go w całości. Kompilatory były skomplikowane, a interakcje między features bywały nieprzewidywalne.

Gdzie PL/I sprawdza się najlepiej

PL/I był używany w systemach, które wymagały zarówno obliczeń numerycznych, jak i przetwarzania danych biznesowych. NASA używała PL/I w programie Apollo i w systemach naziemnych. Banki (szczególnie w USA i Europie) budowały systemy transakcyjne w PL/I. Telekomunikacja — systemy billingowe i przełączniki. Rządy — systemy podatkowe, ewidencji, statystyczne.

Dziś PL/I jest nadal używany na mainframe’ach IBM z/OS, głównie w bankowości i ubezpieczeniach. Firmy jak SAS Institute miały znaczące bazy kodu w PL/I. Enterprise PL/I for z/OS jest aktywnie wspierany i rozwijany przez IBM.

Jak wygląda kod w PL/I

Prosty program z obsługą wyjątków:

SILNIA: PROCEDURE OPTIONS(MAIN);
   DCL (N, WYNIK) FIXED BIN(31);
   DCL I FIXED BIN(31);

   ON ZERODIVIDE
      PUT SKIP LIST('Błąd: dzielenie przez zero');

   PUT SKIP LIST('Podaj N:');
   GET LIST(N);

   WYNIK = 1;
   DO I = 1 TO N;
      WYNIK = WYNIK * I;
   END;

   PUT SKIP LIST('Silnia', N, '=', WYNIK);

END SILNIA;

PROCEDURE OPTIONS(MAIN) oznacza punkt wejścia programu. DCL deklaruje zmienne z typem i precyzją (FIXED BIN(31) to 31-bitowa liczba całkowita). ON ZERODIVIDE to handler wyjątku. PUT SKIP LIST to wyjście z nową linią. GET LIST to wejście. Składnia jest verbose, ale czytelna.

Ekosystem i narzędzia

Głównym narzędziem jest IBM Enterprise PL/I for z/OS — komercyjny kompilator z pełnym wsparciem IBM. VisualAge PL/I (starsze IDE oparte na Eclipse) jest nadal używane w niektórych organizacjach. Istnieje też Iron Spring PL/I — komercyjny kompilator na Linux i Windows.

Biblioteka standardowa PL/I jest rozbudowana: I/O (STREAM i RECORD), matematyka, stringi, datetime, alokacja pamięci. IBM dostarcza też biblioteki do integracji z CICS (system transakcyjny), DB2 (baza danych) i IMS.

Community PL/I to głównie programiści mainframe’owi — doświadczeni profesjonaliści, którzy utrzymują legacy systemy. Forum IBM Mainframe i grupy na LinkedIn to główne kanały komunikacji. Nowych programistów PL/I jest niewielu, ale ci, którzy są, zarabiają bardzo dobrze.

Mocne i słabe strony

Mocne strony: PL/I jest niezwykle potężny i elastyczny. Obsługa wyjątków, tasking i preprocessor były rewolucyjne w latach 60. Język nadaje się zarówno do obliczeń numerycznych, jak i do przetwarzania danych. Na mainframe’ach PL/I generuje wydajny kod i integruje się z ekosystemem IBM.

Słabe strony: PL/I jest zbyt skomplikowany. Dijkstra nazwał go „językiem, którego kompilacja jest trudniejsza niż użycie asemblera”. Setki features, niejednoznaczna składnia, nieprzewidywalne interakcje między mechanizmami. Kompilatory były wolne i skomplikowane. I wreszcie — PL/I przegrał wojnę o popularność z C (systemy) i COBOL (biznes), bo żaden z nich nie potrzebował „wszystkiego naraz”.

Podsumowanie

PL/I to lekcja o tym, że więcej features nie znaczy lepszy język. Ale to też lekcja o trwałości — PL/I, mimo wszystkich krytyk, działa w produkcji od ponad 50 lat i obsługuje systemy, od których zależą miliardy dolarów. Jeśli pracujesz z mainframe’ami lub interesujesz się historią języków programowania, PL/I jest obowiązkową lekturą. Nie dla przyjemności — dla zrozumienia, jak NIE projektować języków (i jak mimo to przetrwać dekady).