COBOL to język, o którym słyszał prawie każdy, kto miał jakąkolwiek styczność z programowaniem. Obecnie znany jest przede wszystkim z żartów na jego temat i powtarzanych wciąż mitów. Niemal każde wrzucone w przestrzeń portali społecznościowych ogłoszenie o pracę w tej technologii skwitowane zostaje dowcipnym komentarzem, że zapewne posada zwolniła się z powodu śmierci któregoś z nielicznych już programistów COBOLa. Jednocześnie w głowach wielu osób istnieje obraz programisty-dinozaura, który wprawdzie zmaga się z utrzymywaniem jakiegoś prehistorycznego kodu, używając do tego beznadziejnych i nieprzystających do XXI wieku narzędzi, ale za to na jego konto wpływa niezwykle obfite wynagrodzenie.

Jako osoba, która wkroczyła do branży w czasach, które można nazwać postCOBOLOwymi, posiadam zaledwie szczątkową wiedzę o tym języku. Niniejszym artykułem chcę nieco poukładać – zarówno sobie, jak i tym, którzy będą mieli okazję go przeczytać, fakty dotyczące COBOLa. Siłą rzeczy opierać się będę na źródłach zewnętrznych, a nie na swoim doświadczeniu, dlatego oczywiście zachęcam wszystkich, którzy przeżyli osobiste zawodowe spotkanie z tą technologią do dzielenia się swoimi wrażeniami, wspomnieniami i opiniami w komentarzach pod wpisem.

 

 

Jaka jest więc prawda o COBOLu? Zacznijmy od kilku podstawowych faktów: początki tego języka sięgają roku 1959, kiedy to pracę nad jego specyfikacją rozpoczęło konsorcjum CODASYL, stawiając sobie za cel stworzenie technologii, cechującej się przenośnością (wieloplatformowością),a zatem mogącej być wykorzystywaną na różnego rodzaju komputerach (co w tamtych czasach bynajmniej nie było elementem charakteryzującym większość języków). Swój udział w procesie powstawania COBOLa miał m.in. Departament Obrony USA, a jedną z kluczowych osób w nim uczestniczących była kontradmirał Grace Hopper, mająca już wtedy za sobą wieloletnie doświadczenie w tworzeniu języków programowania. Jej zaangażowanie w prace nad nowym językiem zaowocowało nadaniem jej przydomku „babcia COBOLa”. Skupmy się jednak na samym języku – poniżej prezentuję garść faktów oraz mitów dotyczących COBOLa:

Fakty i mity

1. Jest językiem typowo biznesowym

Zdecydowanie tak. Sama nazwa COBOL to akronim oznaczający Common Business-Oriented Language, ale propozycji, spośród których wyłoniono właśnie tę było kilka. Źródła wspominają m.in. o BUSY (Business System), COCOSYL (Common Computer Systems Language) oraz INFOSYL (Information System Language). W rezultacie otrzymaliśmy jeden z niewielu przypadków, w których już sama nazwa języka zdradza jego główny obszar zastosowania – biznes. Systemy bankowe, backendy wielkich korporacyjnych systemów – właśnie to najczęściej kojarzymy – i całkiem słusznie – z COBOLem. Środowiska akademickie już od samego początku nie były zbyt zainteresowane wykorzystaniem tego języka, preferując pozostanie chociażby przy FORTRANIE. W rezultacie COBOL, jako rozwijany przede wszystkim przez osoby z kręgów korporacyjnych, uległ pewnej alienacji w świecie informatyki.

Zjawisko to analizuje Ben Shneiderman w swoim artykule pt. „The Relationship Between COBOL and Computer Science”[1], jako przyczynę takiego stanu rzeczy przytaczając m.in. fakt, że w okresie powstawania COBOLa naukowcy byli zainteresowani całkiem inną grupą problemów niż te, które miał rozwiązywać ów język. Większe zainteresowanie niż przetwarzanie danych biznesowych budziły wtedy analiza numeryczna, oprogramowanie wspomagające obliczenia związane z fizyką czy programowanie systemów. Jednym z widocznych rezultatów separacji COBOLa od środowiska informatyki akademickiej jest mniejsza w porównaniu z innymi językami tamtego okresu liczba publikacji dotyczących COBOLa. Co więcej, nawet jeśli jakieś artykuły o tym języku ukazywały się, to nie zawierały prawie żadnych referencji do innych prac – stosunki ze środowiskiem naukowym były więc co najmniej oziębłe.

2. Jest trudny

Nie jest! Nauczenie się COBOLa nie jest wcale trudniejsze niż poznawanie innych języków programowania. COBOL został zaprojektowany w taki sposób, aby swoją składnią jak najbardziej przypominać język angielski. Dzięki temu miał być prosty w czytaniu dla osób niebędących programistami, np. kadry menedżerskiej. Wiele osób twierdzi wręcz, że COBOL jest technologią ukierunkowaną na użytkowników biznesowych. Dla osób technicznych ma to oczywiście swoje wady – specyfikacja języka wyróżnia ponad 300 słów kluczowych, a to z kolei sprawia, że język może wydawać się zbyt rozwlekły i „przegadany”.

Czyżby więc zostanie COBOLowym ekspertem nie było wcale niczym skomplikowanym? Haczyk polega tu na czym innym niż trudność samego języka. Trudne jest bowiem środowisko, w którym on występuje, czyli komputery typu mainframe. To właśnie systemy, które na nich działają i znajdujące się tam biblioteki są prawdziwym wyzwaniem jeśli chodzi o pracę w COBOLu. Na dodatek zdobycie praktycznej wiedzy związanej z takimi maszynami jest jeszcze utrudnione przez fakt, że przecież mało kto ma do nich dostęp.

3. Nie wywarł wpływu na inne języki

Liczba języków programowania, na których rozwój wpłynął COBOL nie jest duża, ale na pewno nie jest równa zero. Wśród technologii, które zaczerpnęły z niego pewne elementy wymienić można Pascala i PL/I. Rzeczy, który były w COBOLu pewną innowacją i inspirowały później innych to przede wszystkim sposób zapisu danych – definiowanie struktury plików wejściowych oraz tak zwanych rekordów. Niektórzy twierdzą też, że oddzielna dywizja zawierająca deklaracje używanych danych (DATA Division) oraz specyfikowanie hierarchii pól w strukturze pliku można uznać za poprzednika dzisiejszych systemów zarządzania bazą danych [1]. W ogólnym rozrachunku, mimo pewnych oryginalnych i niekoniecznie złych pomysłów, COBOL nie stał się podstawą dla wielu nowych języków. Taki stan rzeczy wynika z alienacji COBOLa w środowisku akademickim (w którym rodziło się większość nowych technologii), o czym pisałem w punkcie 1.

4. Jest rzadko używany

Zdecydowanie nie jest to prawdą. Wprawdzie jeśli chodzi o aplikacje na komputery osobiste, to COBOL rzeczywiście wykorzystywany jest marginalnie, jednak w środowisku komputerów klasy mainframe jest prawdziwym dominatorem. Niektórzy posuwają się nawet do stwierdzenia, że póki istnieć będą tego typu maszyny, tak długo COBOL pozostanie w użytku. Zresztą, niechaj przemówią liczby! Jak szacuje firma Micro Focus, jeden z dostawców implementacji COBOLa statystyki użycia tego języka na rok 2013 wyglądały następująco [6]:

• Każdego roku baza tworzonego w COBOLu kodu powiększa się o 5 miliardów linii
• Całkowity wkład w personel, sprzęt i technologie związane z COBOLem wynosi już 5 bilionów dolarów
• 70% krytycznej logiki biznesowej napisane jest w tym języku
• 90% systemów biznesowych przedsiębiorstw z listy Fortune 500 używa COBOLa
• 95% transakcji bankomatowych korzysta z COBOLa
• Codziennie COBOL łączy ze sobą 500 milionów użytkowników sieci telefonii komórkowej
• Aplikacje napisane w COBOLu zarządzają opieką 60 milionów pacjentów dziennie
• Każdego dnia COBOLowe programy obsługują 72 tysiące kontenerów i przetwarzają 85% transakcji portowych
• 2 miliony programistów wykorzystuje w swojej pracy COBOLa

Można zatem pokusić się o stwierdzenie, że każdego dnia sami używamy aplikacji napisanych w COBOLu. Oczywiście nie bezpośrednio, ale chociażby korzystając z kart płatniczych prawdopodobnie nasze transakcje przetwarza gdzieś na odległym komputerze jakiś COBOLowy program z wieloletnią historią. Z czego wynika tak ogromne zastosowanie tego języka i komputerów mainframe, na których on pracuje? Z kosztów i niezawodności. Uptime takich systemów mierzony jest w latach, a wszelkie modernizacje sprzętu wykonywane są na działających komputerach (osiąga się to dzięki redundancji większości podzespołów – można np. wymienić procesor na włączonej maszynie, bo wciąż będzie działał drugi). Stworzone dziesiątki lat temu COBOLowe aplikacje wciąż działają, więc są naprawdę gruntownie przetestowane. Koszt przepisywania takich programów na nowsze technologie sprawia, że jest to działanie praktycznie nieopłacalne. A więc póki co jesteśmy skazani na COBOLa… brzmi strasznie? Nie mogąc doczekać się świata wolnego od COBOLa autorzy strony hyperorg.com pokusili się nawet o dokonanie wyliczeń tego, kiedy nie będą istnieli już żadni programiści tego języka. Przewidywaną datą jest dopiero rok 2083, co oznacza, że za jakiś czas będzie można zajmować się rozwijaniem aplikacji w liczącym sobie ponad 100 lat języku [7]!

5. Jest martwy

Śmierć COBOLa obwieszczano już wiele razy, ale póki co bynajmniej się na nią nie zanosi [8]. I nawet jeśli śmierć języka programowania rozpatrywać na dwa sposoby – biorąc pod uwagę to, czy powstaje w nim nowy kod, a także to, czy sam język jest rozwijany, dodawane są do niego kolejne funkcjonalności itd. – to w każdym z tych aspektów COBOL jest żywy. Wiele osób myśli, że COBOL jest tą samą technologią, która narodziła się 59 lat temu – a więc jak na dzisiejsze czasy językiem całkowicie archaicznym i przestarzałym. Owszem, wiele elementów COBOLa można za takie uważać, ale biorąc pod uwagę, że jego najnowsza specyfikacja ukazała się niespełna cztery lata temu (jako COBOL 2014) i zawiera takie zmiany jak przeciążanie metod, wskaźniki do funkcji czy tablice o dynamicznym rozmiarze [9]. Poprzednie duże wydanie standardu języka miało miejsce w roku 2002 (przygotowywane było już od wczesnych lat 90.) i wniosło wiele znaczących zmian, czerpiąc nowe funkcjonalności między innymi z C++ i Smalltalka. Biorąc pod uwagę te fakty, to jakkolwiek krytycznie nie wypowiadać by się o COBOLu, trudno jest mu zarzucić, że nie jest językiem współczesnym i twierdzić, że już umarł. Jest tak samo współczesny jak i język C, który mimo, iż swoimi początkami sięga roku 1972, to jego najnowszy standard pochodzi z roku 2011.

6. Kod w nim pisany jest brzydki

To niestety prawda – bardzo dużo napisanego w COBOLu kodu po prostu razi w oczy i urąga wszelkim obecnie wyznawanym zasadom dobrego stylu. Nie ma jednak sensu obarczać całą winą za to zwykłych programistów kodujących w tym języku. Funkcjonalności COBOLa, a zwłaszcza jego pierwszych wersji (wydanych przed rokiem 1985), wymuszały stosowanie pewnych nieładnych konstrukcji [10]. Kiedy pojawiły się nowe wydania specyfikacji języka, poprawiające wiele jego bolączek, tradycja starego stylu kodowania nie została wyeliminowana jak za dotknięciem magicznej różdżki. Stąd wiele osób, które styka się z napisanym w COBOLu kodem, nabywa przekonanie, że programowanie w tym języku musi tak wyglądać i że budzący odrazę kod jest nie do uniknięcia. Wśród społeczności programistów COBOLa pojawiają się jednak głosy broniące współczesnego standardu i chwalące czytelność, którą można za jego pomocą osiągnąć. Jak pisze Jerome Garfunkel, specjalista IT z ponad 40-letnim doświadczeniem [11]:

Nowoczesna wersja COBOLa jest dramatycznie inna niż COBOL używany w latach 60. i 70. Ludzie, którzy kłócą się, że COBOL nie żyje lub umiera, często nie znają współczesnego języka COBOL (…). Dzisiejszy COBOL nie jest COBOLem twojego ojca. Mój znajomy profesor lubi mówić swoim studentom: „lepiej załóżcie okulary przeciwsłoneczne, jeśli spoglądacie w przyszłość COBOLa”

Obecnie COBOL nie jest tak złym językiem, aby nie dało się w nim pisać w miarę czytelnego, przejrzystego i przyjemnego w utrzymaniu kodu. Pozostaje pytanie – jaki procent COBOLowych aplikacji stanowią te, tworzone w najlepszym do osiągnięcia w tej technologii stylu?

7. Programiści COBOLa świetnie zarabiają

Jest to często powielany mit, który niestety nie ma zbyt wiele wspólnego z prawdą. Zarobki programistów COBOLa wcale nie wyróżniają się na tle innych języków programowania. Kwoty, o jakich wspominają osoby piszące w tej technologii to ok. 110 tysięcy dolarów rocznie dla najbardziej doświadczonych i 70 tysięcy dolarów dla mniej zaawansowanych [3][4]. Wprawdzie niektórzy prognozują, że zapotrzebowanie na programistów COBOLa będzie w najbliższych czasach rosnąć, a wraz z tym zwiększą się ich pensje, jednak na chwilę obecną wybór tego języka z myślą o szybkim wzbogaceniu się nie wygląda jak dobry plan [5]. Miejsc pracy dla programistów specjalizujących się w COBOLu na pewno jest sporo, ale skłaniałbym się ku tezie, że jeśli rzeczywiście zacznie brakować COBOLowców, to firmy przygarną każdego programistę, który wyrazi chęć nauki tego języka (zresztą po części już tak robią), więc wpisywanie tej technologii do swojego CV już dziś nie jest koniecznym warunkiem znalezienia takiej pracy w przyszłości.

8. Nie nadaje się do tworzenia aplikacji webowych

Z teoretycznego punktu widzenia powyższe stwierdzenie nie ma zbyt wiele sensu – skoro COBOL jest językiem kompletnym w sensie Turinga, to da się w nim stworzyć to wszystko, co w każdym innym takim języku. Oczywiście potrzebny do tego wkład pracy może być wielokrotnie większy, ale, zupełnie teoretycznie, nadaje się. A co jeśli chodzi o praktykę? Budowanie front-endu w COBOLu można rozpatrywać jedynie jako sztukę dla sztuki (przynajmniej w większości przypadków) – w takie doświadczenie zabawił się np. Adrian Zandberg (przez większość czytelników kojarzony zapewne bardziej z polityką aniżeli z programowaniem), tworząc micro-framework webowy COBOL On Wheelchair (kod można obejrzeć na GitHubie) [12].

Inaczej ma się rzecz jeżeli mówić o backendzie aplikacji webowych. Dzisiejszy świat to świat wszechobecnego internetu, więc oczywistym jest, że wszystkie te wciąż działające COBOLowe programy muszą się z nim w jakiś sposób komunikować. Gdzieś z tyłu większości bankowych stron działa zatem COBOL i wygląda na to, że jest to dla niego całkiem dobre miejsce.

9. Jest językiem proceduralnym

Przez długi czas COBOL rzeczywiście był językiem wyłącznie proceduralnym, ale jego nowe wersje wspierają również programowanie obiektowe. Pomysł włączenia OOP do specyfikacji języka pojawił się już dość dawno, bo w roku 1989 [11]. Pracująca nad tym komisja nie działała z przesadną prędkością, czego rezultatem było wprowadzenie obiektowości dopiero w wersji, która ukazała się w roku 2002. Klasy, interfejsy, polimorfizm i wsparcie dla programowania generycznego – to wszystko należy do funkcjonalności współczesnego COBOLa! Odrębną kwestią jest natomiast stopień wykorzystania tych możliwości w utrzymywanych aplikacjach. W działający na komputerach mainframe kod raczej niechętnie wprowadza się zmiany jeśli nie ma ku temu naprawdę ważnych powodów, więc nie spodziewałbym się, że zostając programistą COBOLa będzie się programować zgodnie z paradygmatem obiektowym (co zresztą potwierdzają komentarze osób pracujących z tym językiem [13]). 

10. Nie ma żadnych zalet

Aż tak źle na szczęście nie jest. Mimo sporej ilości krytyki wymierzonej w ten język, posiada on również pewne zalety. Pierwszą z nich jest czytelność – nie tyle dla programistów, co dla osób nietechnicznych, które znając jedynie angielski są w stanie zrozumieć działanie wielu fragmentów COBOLowego kodu. Nawet pospolite instrukcje modyfikujące wartość zmiennej wyglądają jakoś tak przyjaźniej i bardziej zrozumiale. Np. chcąc obliczyć kwotę netto wynagrodzenia, a następnie powiększyć o nią nasze oszczędności nie napiszemy:

tylko tak:

Nie ma chyba wątpliwości, że dla bankowego menedżera bez backgroundu technicznego właśnie ta druga wersja będzie bardziej czytelna. Kolejny podkreślany przez wiele osób plus tego języka to fakt, że rzeczywiście nadaje się on do zastosowań, do których go zaprojektowano – do szybkiego, wydajnego i poprawnego przetwarzania danych biznesowych [2]. Zapewnienie ostatniej z wymienionych cech, czyli poprawności, jest ułatwione dzięki domyślnemu stosowaniu takiej reprezentacji liczb, która nie jest podatna np. na błędy związane z zaokrągleniami (mowa o zapisie stałopozycyjnym). Zredukowanie potencjalnych błędów związanych z użyciem liczb zmiennoprzecinkowych to ważna sprawa dla instytucji, więc COBOL dobrze wpasował się w to zapotrzebowanie.

Z elementów bardziej technicznych, udało mi się natknąć na dwie całkiem ciekawe funkcjonalności [16]. Jedna z nich to instrukcja, której użycie wygląda następująco:

pozwala ona na przepisanie z jednego rekordu do drugiego wartości wszystkich odpowiadających sobie pól (czyli posiadających takie same nazwy). Na przykład jeśli w strukturze A będą pola:

• name
• surname
• city
• street

Zaś w strukturze B:

• name
• surname
• clientId

To za pomocą tej jednej krótkiej linijki możemy wypełnić pola name i surname w rekordzie B wartościami ze rekordu A. Druga ze zwracających na siebie uwagę cech COBOLa jest o tyle zabawna, że niektórzy początkujący próbują dokładnie to samo zrobić w innych językach programowania, tyle że tam nie działa to w sposób, którego oczekują. Świadczy to jednak o tym, że właśnie takie rozumienie składni, którą za chwilę przedstawię, jak najbardziej naturalne dla osób nietechnicznych. Spójrzmy na taki oto fragment kodu:

Dla programisty oczywistym będzie, że niezależnie od wartości zmiennej a rezultatem zawsze będzie wejście do pierwszego ifa i wyświetlenie „OK”, ponieważ liczba 10 ewaluuje do wartości, oznaczającej prawdę. Z pewnością zamysł piszącego taki kod byłby jednak inny – „jeśli a jest równe 5 lub 10, to…” a nie „jeśli a jest równe 5 lub jeśli prawda, to…”. W COBOLu tego typu kod nie będzie błędem – twórcy języka zaprojektowali go dosyć konsekwentnie, bo skoro jego czytanie ma być jak najbardziej zbliżone do języka naturalnego, to rezultatem poniższego fragmentu musi być wyświetlenie „NOT OK”:

11. Ma złą opinię wśród programistów

To wprawdzie żadne odkrycie, ale przyznam szczerze, że niektóre komentarze dotyczące COBOLa nieźle mnie rozbawiły.

Języki programowania są tworzone przez programistów dla programistów i tak powinno być. Ostatnim językiem napisanym dla menedżerów był COBOL… Nigdy nie słyszałem aby ktoś powiedział o nim coś dobrego
Walter Bright, twórca języka D [14]

Używanie COBOLa kaleczy mózg, jego nauczanie powinno być więc uznane za przestępstwo.Edsger Dijkstra [15]

Wiedziałem, że będę nienawidził COBOLa gdy tylko zobaczyłem, że używa on komendy PERFORM zamiast DO.Larry Wall, twórca Perla [14]

Pamiętajmy przy tym, że wypowiedzi te dotyczą starszych wersji COBOLa, posiadającego znacznie więcej wad niż aktualny standard. Z kolei jeden z komentarzy użytkownika serwisu Reddit, który osobiście doświadczył bolesnego spotkania z COBOLem, pozwolę sobie pozostawić nieprzetłumaczony:

I’d rather get fucked by every JS framework on the planet than ever see another monochrome editor like ROSCOE or hear the word „core dump” again. I’m having nightmares right now while I’m awake just thinking about it.GrokFu [2]

O złej opinii świadczą też wyniki ankiety, w której o stosunek do COBOLa pytano wykładowców akademickich z różnych krajów. Aż 22% z nich wyraziło negatywny punkt widzenia wobec nauczania języka COBOL. Wśród studentów informatyki zdanie o tym języku jest jeszcze gorsze – prawie 40% respondentów stwierdziło, iż COBOL jest technologią przestarzałą i niemodną, a wiele osób nie wiedziało nawet o istnieniu COBOLa [6].

12. Jest źle zaprojektowany

To chyba najważniejszy podpunkt tej całej wyliczanki, czyli odpowiedź na pytanie „dlaczego COBOL jest taki zły?”. Dlaczego tak wiele osób nienawidzi go lub wspomina o nim z pogardą czy uśmiechem? Oto kilka argumentów przemawiających za tym, że programowanie w COBOLu to zajęcie, które może nie należeć do najprzyjemniejszych [17]:

• Nie posiada biblioteki standardowej ani żadnych innych bibliotek wspomagających pisanie kodu. Wszystkie nowe funkcjonalności są implementowane w postaci kolejnych słów kluczowych, przez co ich i tak już spora baza wciąż się rozrasta. Np. gdy w jednym z ostatnich standardów dodano obsługę plików XML, postanowiono po prostu dołożyć kilka kolejnych słów kluczowych – w rezultacie parsowanie XML-i odbywa się przy użyciu wyrażenia XML RENDER.
• Przez długi czas nie było możliwości definiowania zmiennych lokalnych, więc wszystkie zmienne były globalne. Tylko to sobie wyobraźcie…
• Z powodu kiepskich możliwości modularyzacji programy w COBOLu na ogół były wielkimi monolitycznymi aplikacjami wypełnionymi spaghetti-kodem rojącym się od instrukcji skoku GO TO.
• Dopiero późniejsze wersje języka wprowadziły istnienie funkcji (wcześniej były tylko podprogramy, a i to nie od samego początku)
• Możliwość wywołań rekurencyjnych została dodana dopiero w 2002 roku
• Brak sprawdzania typu przekazywanych do podprogramów parametrów
• Blok instrukcji warunkowej należało zakończyć kropką, a jej omyłkowe pominięcie prowadziło do trudnych do znalezienia błędów. Dopiero w roku 1985 wprowadzono słowo kluczowe END-IF.

Na pewno nie jest to kompletna lista wad COBOLa, podobnie jak nie przedstawiłem kompletnego wykazu jego zalet. Próbując go oceniać trzeba pamiętać o tym, że nie jest to język ogólnego przeznaczenia, ale technologia, której właściwym zastosowaniem jest przetwarzanie danych biznesowych. Po przeczytaniu dość sporej liczby artykułów i opinii na temat COBOLa sądzę, że często jest on demonizowany, zwłaszcza przez osoby, mające z nim zerową styczność lub opierające się co najwyżej na wiedzy dotyczącej początkowych wersji COBOLa. Każdy z języków programowania ma swoje wady i zalety, podobnie jak każdy z nich ma jakieś obszary, w których sprawdza się najlepiej. Nie wydaje mi się, aby współczesny COBOL sam w sobie był aż tak strasznym złem, że należałoby odmówić mu tych trzech cech.

Kodujemy!

Cóż byłoby warte pisanie artykułu na temat COBOLa, gdybym nie spróbował przy tym doświadczyć tej technologii na własnej skórze. Kodując nawet najbanalniejsze programy w nowym dla siebie języku nierzadko można dowiedzieć się więcej niż z czytania suchej teorii. Wyposażyłem się więc w kompilator GnuCOBOL i spróbowałem stworzyć parę „heloł-łordów”, testując różne funkcjonalności tego języka. Zaczęło się oczywiście od problemów:

Trochę googlowania i poznałem zasadę, o której nie miałem wcześniej pojęcia – otóż standardowy zapis kodu źródłowego w COBOLu wymaga, aby w konkretnych kolumnach znalazły się konkretne elementy. Nie można sobie tak „od czapy” zacząć swojego programu pisząc:

W kolumnie numer 7 znajdzie się w takim wypadku znak ‚F’, a w tradycyjnym układzie jest to kolumna zarezerwowana na znak wskazujący typ obszaru, który po nim następuje (np. ‚*’ oznacza komentarz, spacja – normalny kod, zaś ‚-‚ kontynuację). Kolumny 1-6 standardowo były przeznaczone na numer linii, a kod powinien mieścić się w kolumnach od 8 do 72 (wszystko co dalej jest już ignorowane przez kompilator, więc równie dobrze mogą być to komentarze). Chociaż zasady te wydają się na pierwszy rzut oka dosyć dziwne, ich pochodzenie jest dosyć proste – pierwotnym nośnikiem, na którym zapisywano kod COBOLa były 80-kolumnowe karty perforowane (takie jak na zdjęciu poniżej).

Oczywiście współczesne kompilatory nie wymuszają już stosowania tego wywodzącego się z dawnych czasów zapisu, choć jak widać niektóre z nich mają domyślnie włączoną taką opcję. W GnuCobolu wystarczy skorzystać z przełącznika -free. Warto też użyć flagi -x, bo inaczej kod zostanie skompilowany do postaci biblioteki współdzielonej (swoją drogą pierwszy raz spotkałem się z tym, aby tak wyglądało domyślne działanie kompilatora).

Krótka przygoda z COBOLowym kodem odsłoniła też przede mną tajemnicę dziwnego sposobu definiowania w nim zmiennych. Nie twierdzę oczywiście, że wszystko już rozumiem, ale widząc kod taki jak poniżej przynajmniej wiem już co oznaczają numerki przed nazwami zmiennych oraz słówko PIC znajdujące się po nich:

Tych, którzy również, chociażby z czystej ciekawości, chcieliby dowiedzieć się nieco więcej technicznych szczegółów dotyczących COBOLa, zachęcam do zapoznania się z którymś z podstawowych tutoriali, np. dostępnym na stronie Tutorialspoint. Ja po dzisiejszych walkach z wczytywaniem danych z pliku, trimowaniem stringów i wrzucaniem ich do dynamicznej wielkości struktur póki co podziękuję za przyjemność pisania kodu w tym języku. Daleki jestem od twierdzenia, że COBOL jest najgorszym językiem jaki kiedykolwiek powstał, ale zdecydowanie wolę korzystać z technologii, które zostały stworzone z myślą o programistach, a nie ludziach biznesu.

Źródła

1. The Relationship Between COBOL and Computer Science, B. Shneiderman, „Annals of the History of Computing”, vol. 7 nr. 4, październik 1985.
2. Reddit: The Relationship Between COBOL and Computer Science.
3. Reddit: COBOL Developer salary.
4. Glassdoor – Salaries for COBOL programmer.
5. Laserfiche: Looking for a Job? How’s Your COBOL?
6. Micro Focus: Academia needs more support to tackle the IT skills gap.
7. The COBOL Extinction Calculator.
8. Why it’s time to learn COBOL.
9. Cobol 2014, perhaps the definitive final version of the language…
10. COBOL: The Good, the Bad and the Ugly.
11. Modern COBOL, J. Garfunkel
12. COBOL On Wheelchair.
13. Quora: Is COBOL an object oriented language.True or False?
14. Is Your Next Language COBOL?
15. How do we tell truths that might hurt?, E. W.Dijkstra, 18.06.1975.
16. StackOverflow: What’s the bright side of Cobol?
17. Stackoverflow: Why the scorn for COBOL?