PL/C to język programowania stworzony na Cornell University w latach 70. jako narzędzie do nauki programowania. Jego główna innowacja nie leżała w składni ani w systemie typów — leżała w kompilatorze. Kompilator PL/C był zaprojektowany tak, by nigdy nie odmawiać kompilacji. Niezależnie od tego, ile błędów było w kodzie, kompilator zawsze generował program wykonywalny — poprawiając błędy na tyle, na ile potrafił, i wstawiając runtime checks tam, gdzie nie był pewien.

Brzmi jak szaleństwo? Może. Ale PL/C rozwiązywał realny problem: studenci pisali kod z błędami, kompilator odmawiał kompilacji, studenci spędzali godziny na poprawianiu błędów składni zamiast uczyć się programowania. PL/C mówił: „OK, rozumiem co chciałeś zrobić, skompiluję to, ale dam ci znać, co poprawiłem”. To podejście wyprzedzało swoje czasy o dekady — dzisiejsze IDE z live error recovery i AI-assisted coding robią w zasadzie to samo.

PL/C był oparty na PL/I — potężnym (i skomplikowanym) języku IBM — ale drastycznie uproszczonym do celów edukacyjnych. Dla współczesnego developera PL/C jest ciekawy jako studium przypadku: jak zaprojektować język i kompilator, który maksymalizuje produktywność początkującego programisty.

Spis treści

Krótka historia i ewolucja

PL/C został stworzony w 1970 roku przez Richarda W. Conwaya i Thomasa R. Wilcoxa na Cornell University. Conway był profesorem informatyki zafascynowanym problemem nauczania programowania. Zauważył, że studenci tracą motywację, gdy ich kod nie kompiluje się za piątym razem z powodu brakującego średnika.

Kompilator PL/C był prawdziwym osiągnięciem inżynierskim. Miał zaawansowany error recovery — potrafił odgadnąć intencje programisty nawet przy poważnych błędach składni, wstawić brakujące nawiasy, naprawić literówki w słowach kluczowych i wygenerować działający program z runtime checks. Jeśli kompilator nie był pewien, wstawiał kod, który przy uruchomieniu sprawdzał poprawność i raportował błędy.

PL/C był używany na Cornell i kilku innych uczelniach przez lata 70. i 80. Conway i Wilcox opublikowali podręcznik „An Introduction to Programming: A Structured Approach Using PL/I and PL/C”, który był popularny na kursach wprowadzających. Wraz z popularyzacją Pascala (a później C i Javy) jako języków edukacyjnych, PL/C stopniowo wyszedł z użycia.

Kluczowe cechy i filozofia

PL/C jest podzbiorem PL/I — ale PL/I uproszczonym do tego stopnia, że studenci mogli go opanować w kilka tygodni. Język zachował proceduralną strukturę PL/I (procedury, bloki, pętle, warunki), ale usunął większość egzotycznych features: tasking, preprocessor, generic procedures i większość atrybutów danych.

Składnia PL/C jest czytelna i zbliżona do angielskiego:

DCL (X, Y, Z) FLOAT;
IF X > Y THEN Z = X;
ELSE Z = Y;
PUT LIST('Większa wartość:', Z);

DCL (DECLARE) deklaruje zmienne. FLOAT to typ zmiennoprzecinkowy. PUT LIST to wyjście. Składnia jest wolna od restrykcyjnych reguł formatowania — kompilator PL/C i tak to naprawi.

Najważniejszą cechą — i prawdziwą innowacją — był kompilator z error recovery. Oto co robił:

Automatyczna korekta składni: brakujące nawiasy, brakujące END, brakujące średniki — kompilator wstawiał je sam.
Korekta literówek: BGEIN zamiast BEGIN? Kompilator rozumiał.
Runtime checks: jeśli kompilator nie był pewien, generował kod, który przy uruchomieniu sprawdzał poprawność (np. zakres tablicy, dzielenie przez zero).
Diagnostyka: kompilator raportował, co poprawił i dlaczego, ucząc studenta poprawnego kodu.

Filozofia PL/C to „nie karz studenta za błędy — pomóż mu je zrozumieć”. To podejście, które dziś jest standardem w nowoczesnych IDE i narzędziach edukacyjnych.

Gdzie PL/C sprawdza się najlepiej

PL/C był używany wyłącznie w edukacji — na kursach wprowadzających do programowania na Cornell i kilku innych uczelniach. Nie miał zastosowań komercyjnych, nie był używany w przemyśle. Jego wartość leżała w tym, że studenci mogli skupić się na nauce algorytmiki i logiki programowania, zamiast walczyć z kompilatorem.

Dziś PL/C nie ma praktycznych zastosowań. Ale jego idee przetrwały w: nowoczesnych IDE z error recovery (IntelliJ, VS Code), edukacyjnych językach jak Scratch i Alice (które eliminują błędy składni przez design), i w rosnącym ruchu „forgiving compilers” w badaniach nad kompilatorami.

Jak wygląda kod w PL/C

Prosty program obliczający średnią:

PROGRAM SREDNIA;

DCL (SUMA, LICZBA, SREDNIA) FLOAT;
DCL I FIXED;

SUMA = 0;
LICZBA = 0;

DO I = 1 TO 5;
   PUT LIST('Podaj liczbę:');
   GET LIST(X);
   SUMA = SUMA + X;
   LICZBA = LICZBA + 1;
END;

SREDNIA = SUMA / LICZBA;
PUT LIST('Średnia wynosi:', SREDNIA);

END SREDNIA;

Kod jest prosty i czytelny. DCL deklaruje zmienne, DO ... END to pętla, PUT LIST i GET LIST to I/O. Zwróć uwagę na brak wymogu deklarowania zmiennej X — kompilator PL/C by to wybaczył i automatycznie zadeklarował X jako FLOAT.

A co, gdybyś zapomniał END?

DO I = 1 TO 5;
   SUMA = SUMA + X;
   LICZBA = LICZBA + 1;

SREDNIA = SUMA / LICZBA;

Kompilator PL/C zauważyłby brak END, wstawił go automatycznie przed SREDNIA = ..., i wygenerował ostrzeżenie: „Wstawiono brakujące END w linii 4″. Program by się skompilował i uruchomił.

Ekosystem i narzędzia

PL/C nigdy nie miał rozbudowanego ekosystemu. Kompilator był dostępny na mainframe’ach IBM (System/360, System/370) jako program wsadowy. Studenci punchowali karty z kodem, submitowali job i odbierali wydruk z wynikiem.

Dziś PL/C nie ma żadnych aktywnych narzędzi. Kompilator jest dostępny w archiwach Cornell i w emulatorach mainframe’ów (np. Hercules + MVS). Nie ma IDE, nie ma debuggera, nie ma community. To język zamknięty w historii.

Jedynym współczesnym śladem PL/C jest PL/C-7 — wersja zaimplementowana na potrzeby badań nad error recovery w kompilatorach. Kilka prac naukowych analizuje kompilator PL/C jako studium przypadku w dziedzinie fault-tolerant compilation.

Mocne i słabe strony

Mocne strony: PL/C miał najlepszy error recovery w historii kompilatorów. Studenci mogli pisać kod bez frustracji związanej z błędami składni. Diagnostyka kompilatora była edukacyjna — uczyła poprawnego kodu zamiast tylko karać za błędy. Składnia była prosta i czytelna.

Słabe strony: PL/C był zbyt prosty do zastosowań komercyjnych — brak zaawansowanych struktur danych, brak OOP, brak bibliotek. Error recovery, choć genialny, mógł maskować poważne błędy logiczne — program się uruchamiał, ale robił coś innego niż chciał programista. I wreszcie — PL/C był związany z mainframe’ami IBM, co ograniczało jego dostępność.

Podsumowanie

PL/C to język, który zasługuje na pamięć nie za to, co robił, ale za to, jak myślał o programowaniu. Wierzył, że narzędzie powinno dostosować się do człowieka, nie odwrotnie. Dziś, gdy AI w IDE poprawia nasze błędy w czasie rzeczywistym, gdy kompilatory Rust dają genialne sugestie poprawek, gdy TypeScript inferuje typy za nas — żyjemy w świecie, który PL/C przewidział 50 lat temu. Nie nauczysz się PL/C, by pisać kod — ale warto wiedzieć, że ktoś kiedyś wpadł na te same pomysły, co dzisiejsi twórcy narzędzi.