TheTarPit

lepiej późno czy wcale?

Niedawno kolega zadał mi pytanie: „czy ten PL jest faktycznie tak bardzo inny?” Chodziło o porównanie języka PL/I i Javy, a konkretnie o to, czy dzieląca je przepaść może być tak ogromna, że dla niektórych nie do przeskoczenia. Ten (nawiasem mówiąc dosyć ciekawy z akademickiego punktu widzenia) problem wyniknął na skutek zatrudnienia do pewnego dużego i bardzo obrzydliwego projektu w Javie programistów pracujących dotychczas w środowiskach mainframe'owych z wykorzystaniem języków PL/I i COBOL. Pytający kolega dostał oczywiście nowe „zasoby ludzkie” pod opiekę...

dinozaury mają krzepę

Oglądając gazety „komputerowe” wystawiane na witrynach kiosków lub książki w księgarniach, mogłoby się wydawać, że języki typu PL/I, podobnie jak platformy podobne do OS/390 i maszyny wielkości sporej garderoby, przeszły dawno do lamusa. Jednak wg mnie ktoś, kto tak uważa, nie rozumie informatyki, albo zajmuje się nią od niedawna (co na jedno wychodzi). Systemy „legacy”, powstałe przed laty, stanowią w wielu miejscach świata trzon wielkich biznesów. Nawet w tak wówczas zacofanym technologicznie kraju jak Polska powstawały spore systemy mainframe'owe i niektóre z nich pracują do dziś ponieważ nadal działają instytucje ich używające^[1]. A skoro istnieje system napisany np. w PL/I(F), który dzięki totalnie archaicznym umowom generuje spore przychody, to utrzymywanie grupy na pierwszy rzut oka równie archaicznych specjalistów jest jak najbardziej uzasadnione. Niestety jeżeli w okolicy jest projekt w fazie zasysania wszystkich z okolicy to przychodzi taki moment, że programiści „legacy” muszą w ciągu dnia przejść kilkanaście, jeśli nie kilkadziesiąt, lat ewolucji teorii programowania.

Kilka lat temu sam należałem do takiego zespołu. Myślę więc, że potrafię się wczuć w dzisiejszą sytuację kolegów...

inna perspektywa

Programowanie obiektowe jest dzisiaj tak oczywiste, że podejrzewam, iż wielu ze współczesnych „zawodowców” nie potrafi sobie dokładnie wyobrazić innego sposobu. Nawet nie wiem czy uczelnie techniczne uczą jeszcze algorytmów sekwencyjnych w całkowitym oderwaniu od obiektowości...? Czy ktoś dzisiaj zna zastosowanie instrukcji GOSUB z modelowego, klasycznego BASIC-a? Nie te czasy, nie ten świat... I nawet jeśli „informatyk/programista” rozpoczynający dzisiaj pracę w zawodzie nie potrafiłby precyzyjnie zdefiniować takich pojęć jak enkapsulacja, hermetyczność czy dziedziczenie, to intuicyjnie je czuje, zna i rozumie.

Natomiast co innego człowiek, który przez lata zarabiał na życie pisząc programy dla środowiska, gdzie zbiory danych są mozolnie sekwencyjne^[2], gdzie życie płynie rytmem „blokowo - wsadowym” i przy odrobinę bardziej skomplikowanym zadaniu poszczególne fragmenty to osobne programy odpalane w kolejności ustalonej na poziomie systemu operacyjnego za pomocą JCL. Jest to świat tak różny od współczesnego programu obiektowego, złośliwie asynchronicznego i rozproszonego po najróżniejszych serwisach (lokalnych, zdalnych i nie-wiadomo-jakich), że bardziej różny już być nie może. Chyba łatwiej przechodzą pewne pojęcia z programowania sekwencyjnego do świata współczesnego niż odwrotnie^[3].

stare na nowe

Człowiek w pewnym wieku nie jest już w stanie przestawić się na nowy model myślenia drastycznie inny od tego, co uważał za oczywiste przez wiele lat. Po prostu przestaje się uczyć i już. Znam kilku takich programistów, dla których (być może paradoksalnie) pozostanie przy systemach „odpowiednich” dla ich własnego wieku wydaje się rozwiązaniem najbardziej sensownym. Oczywiście wiele zależy od cech osobniczych i właściwości danej osoby, ale dla prostoty pozostańmy przy takim uogólnieniu.

Jednak człowiek trzydziestoletni (podobnie jak autor tych słów) nie powinien mieć generalnie kłopotów z rozpoznaniem „nowej perspektywy”, nawet jeśli przez wiele lat zajmował się systemami czy komputerami będącymi jego rówieśnikami. A już szczególnie w sytuacji kiedy uprawia zawód „programista” a nie zawód „programista języka X”, do czego chcąc nie chcąc wszyscy dążymy. A mimo to pewne rzeczy dla jednych oczywiste pozostają zupełnie niejasne dla innych...

Cóż zatem można powiedzieć na ich usprawiedliwienie? Parę banałów typu „brak doświadczenia”? Faktycznie doświadczenie w konkretnej technologii jest istotne, ale przede wszystkim chodzi o skalę wyboru. Wybór między C++, Javą czy C# (a takiego typu wybory się praktycznie dzisiaj dokonuje) jest bez znaczenia w porównaniu do wyboru między PL/I a Javą. Tu już nie można mówić o wpływie doświadczenia; tu następuje przeskok na zupełnie inną płaszczyznę. Określenie „trudności adaptacyjne” chyba nie jest w stanie pomieścić wszystkiego z czym muszą się zmierzyć...

Jaką więc odpowiedź można udzielić na postawione na wstępie pytanie? Czy jest faktycznie tak bardzo inny? Tak, jest bardzo inny. Czy ta różnica w idei jest do przeskoczenia? Pewnie tak. Czy można to zrobić w czasie przewidzianym w projekcie na wdrożenie „nowych zasobów ludzkich”? Pewnie nie...

Komentarze