Wieczni programiści

Groteskowa przesada Eda Posta doskonale oddaje istotę problemu: jego typowy programista najlepiej czuje się sam na sam z komputerem, z którym radzi sobie w każdych okolicznościach, przynajmniej we własnym mniemaniu. Często rekompensuje mu to brak podobnej sprawności w realnym życiu, pełnym barier nie do pokonania.

Tworzenie w powietrzu

Już pod koniec lat 70. twierdzono (H. Kopetz), że programowanie to proces intelektualny (i do tego momentu porównywalny z konstruowaniem nowego mecha- nizmu), ale pozbawiony ograniczeń wynikających z praw natury, takich jak własności materiałów. W efekcie szczególny sposób weryfikacji skutków działań powoduje, że programista, gdy tylko dać mu czas, wielokrotnie cyzeluje i poprawia kod programu, co bardzo szybko staje się uprawianiem sztuki dla sztuki.

Prawdziwe zderzenie programu z rzeczywistością następuje dopiero w trakcie jego użytkowania, zaś taka próba bardzo często wypada dla programu niekorzystnie, szczególnie gdy uwzględnić - pozostając przy porównaniach z innymi dziedzinami - że nie słyszy się o spadających windach czy zarywających się mostach.

Echem tego są dowcipy o skutecznej naprawie samochodu metodą wysiadania i ponownego wsiadania. Do ciągle wypominanych przypadków serio należy zaś śmiertelne przedawkowanie promieniowania (3 ofiary w okresie 1985-87), w wyniku błędu oprogramowania w amerykańskim urządzeniu Therac-25 do radioterapii, całkowite załamanie się organizacyjne pogotowia ratunkowego w Londynie 4 listopada 1992 r. w wyniku błędów informatycznego systemu dyspozytorskiego oraz eksplozja (4 czerwca 1996 r.) w 37 sekund po starcie francuskiej rakiety kosmicznej Ariane-5, spowodowana utratą kontroli nad jej zachowaniem w wyniku przepełnienia licznika w programie komputerowym.

Wśród przyczyn zarówno takich, jak i mniej krytycznych przypadków wymienia się trudności rozumienia przez programistów realiów dziedzin, w których muszą działać tworzone przez nich programy. Rozwiązaniem miały być języki, takie jak Cobol, mające umożliwić formułowanie zadań dla komputerów przez fachowców z danej dziedziny w języku możliwie bliskim naturalnemu. Próby te nie przyniosły istotnych efektów i nie sprawdziły się również rozwiązania, w których programy miały powstawać bez pomocy programisty na podstawie modeli opisujących reguły funkcjonowania organizacji. Okazało się, że ludzie wykonujący latami niewielki zakres powtarzających się czynności mają kłopoty z ich przełożeniem na reguły, schematy czy - sięgając po żargon informatyczny - z ich algorytmizacją.

Wyjątkiem stała się jedynie dziedzina określana mianem obliczeń naukowo- -technicznych. Tu okazało się, że znacznie łatwiej jest specjaliście nauczyć się programowania komputerów niż zawodowemu programiście zrozumieć problem, bez czego nie da się napisać przybliżającego jego rozwiązanie programu.

Szary programista

W praktyce zawodowej miałem bliski kontakt z ponad dwoma setkami programistów zaś pracę kilkudziesięciu, pochodzących z różnych krajów świata (od Indii poprzez południową Afrykę do kilku krajów europejskich), oglądam codziennie. Odnoszę wrażenie, że ta wyróżniająca się wyraźnie grupa to coś w rodzaju czubka góry lodowej - oni tworzą to wrażenie, które się dostrzega i o którym się mówi. Cała reszta jest szara jak wszyscy pozostali pracownicy różnych spec-jalności i zdarzają się wśród nich ludzie o najróżniejszych charakterach. W innych grupach większość też nie awansuje i usiłuje trzymać się status quo.

W jednym z niedawno opublikowanych wywiadów Stanisław Lem powiedział: "Zatarcie granicy pomiędzy dziełem sztuki a śmieciem, pomiędzy kunsztem a bylejakością zdaje mi się jednym z głównych znamion naszej epoki". Sztuka programowania komputerów też nie jest od tego wolna.