W obszarach związanych z komputerami, kilka lat – oznacza epokę. W tym czasie może całkowicie zmienić się paradygmat programowania. I obecnie możemy obserwować zwrot, w kierunku programowania funkcjonalnego. Młodemu pokoleniu programistów, może się to wydać nowe, a nawet interesujące ze względu na dość daleko posunięta prostotę. Jednak ci którzy uczyli się na początku rewolucji informatycznej , pamiętają jeszcze języki proceduralne oraz funkcyjne, które istniały zanim programowanie obiektowe stało się popularne.
Rozwój języków programowania zawsze był potraktowany względami praktycznymi ale także ograniczeniami wynikającymi z możliwości dostępnego sprzętu, przy czym niewiele może się obecnie na tym polu zdarzyć. Rozwój hardware-u sporo wyprzedził rozwój oprogramowania, w którym istnieje coś w rodzaju „main streamu” – komputerowego odpowiednika „modelu standardowego” – czyli obecnie panującej metodologii.
Nie oznacza to, że inaczej nikt nie pisze, jednak rynek stawia konkretne wymagania, a uczelnie dostarczają programistów jacy są potrzebni. Potrzebny jest Cobol? Nie ma problemu. A teraz Java? Już się robi.
Niestety język, kształtuje sposób naszego pojmowania. Jeśli pracujemy wyłącznie w bazach danych, nasz program będzie pełen tabel, procedur i triggerów. Jeśli kształciliśmy się w metodach big-data, będziemy konwertowali dane tak długo, aż będą dały się redukować. Mamy w ręku młotek – rozglądamy sięga gwoździem. Ale jeśli uwierzymy, że młotek jest narzędziem uniwersalnym, bez problemy będziemy wbijali co popadnie.
Obecnie wielka popularność zdobywa programowanie funkcyjne pozwalające na budowanie złożonych obliczeń poprzez składnie funkcji. Nie mamy tu klasycznej sekwencji operacji wymuszonej przez programistę, lecz raczej określenie tego co chcemy osiągnąć i jakie etapy pośrednie będą nam potrzebne by to opisać. Tu nie piszemy pętli, lecz określamy jaki rodzaj agregacji chcemy wykonać na zbiorze danych. Wydaje się to bardziej naturalne i bliższe temu jak organizujemy sobie pracę na co dzień. Jeśli potrzebujemy faktury za ostatni miesiąc – to prosimy kogoś by taki zbiór przygotował, informując ewentualnie gdzie można je (między innymi dokumentami) – znaleźć. W programowaniu proceduralnym, wyjaśnialibyśmy jak przeszukiwać dokumenty (od górnej półki od lewej) i sprawdzali czy pasują do zbioru.
Wygląda na to, że wymagana akcja oznacza jedno i to samo, ale jest subtelna różnica. Gdy piszemy program proceduralny, określamy sposób przeglądania, i nawet gdy kolejność nie ma żadnego znaczenia, mówimy jak kolejno przeglądać każdy dokument. I tu pojawia się problem, bo o ile komputery rzeczywiście tak działają, to aby rozwiązanie – na przykład zrównoleglić, musimy najpierw podzielić zbiór danych wejściowych, a potem połączyć rezultaty. I trzeba komputerowi dokładnie te procesy wyjaśnić. Trzeba – bo maszyna nie wie, czy kolejność w pliku wynikowym jest istotna, jak dane trzeba posortować, czy będziemy je jakoś grupować. Ale za to mamy pełna kontrole jak działa program.
Języki funkcyjne pewnych problemów nie rozwiązują, ale niektóre zagadnienia dają się w nich bez problemu podzielić na wątki, procesory lub procesy – jeśli przyjdzie nam na to ochota, i co ważne – nie będziemy musieli modyfikować kodu programu, żeby zyskać na czasie. W świecie chmur obliczeniowych – trudno pogardzić taką możliwością, gdy program możemy pisać nawet na tablecie i testować na niewielkim zbiorze danych, po czym, bez najmniejszych zmian – puścić jednocześnie na tysiącu maszyn. To robi wrażenie. I choć tego typu procesowanie danych nie zachwyca optymalnym wykorzystaniem pojedynczego procesora, to możliwość uruchomienia na paru setkach, likwiduje jakiekolwiek niedogodności. Zwłaszcza, że czas pracy procesora jest wyjątkowo tani w porównaniu z czasem pracy programisty.
Jednak programowanie funkcyjne nie jest specjalnie nowe, choć trąci nowością gdy pojawia się w kolejnych językach programowania – jako ich rozszerzenie lub jako ewolucyjna zmiana. W C++ mamy obecnie możliwości budowy nienazwanych funkcji (lambd) pozwalających tworzyć funkcje ad hoc przez program. Konstrukcja ta w C++ pojawiła się niedawno, ale w jzyku Lisp, istnieje od jego powstania które datuje się na póżne lata sześćdziesiąte, a więc około 50 lat temu.
Programu funkcyjnie nie pozwalają jednak na wielowarstwową organizację kodu programu i dlatego do dużych systemów niespecjalnie się nadają, choć są doskonałe do przetwarzania dużych ilości danych, szczególnie w zagadnieniach które można sprowadzić do konwersji danych oraz ich grupowania i redukowania (liczenie sum, średnich, zliczanie wystąpień, indeksowanie). Gdy programy stawały się coraz bardziej skomplikowane, trzeba było sięgnąć po także powstałe w tym samym czasie programowanie obiektowe – pozwalające na modelowanie nie tylko przetwarzania informacji, ale także struktury rzeczywistości w której problem istnieje. Programowanie w którym musimy napisać sporo dodatkowego kodu, by wyjaśnić nie tylko jak coś zrobić, ale dlaczego tak a nie inaczej – rozwiązujemy problem. W tym czasie komputery nie były specjalnie rozbudowane i kompilatory obiektowe, jako bardziej wymagające, nie miały możliwości specjalnie się rozwinąć. Teraz wracamy do technik funkcyjnych.
Czyżby wszystkie możliwości zostały już wykorzystane? Na pewno nie. W końcu pojawiają się cały czas nowe metodologie takie jak metaprogramowanie czy programowanie aspektowe pozwalające na opis tego jak program ma stworzyć program. Co będzie następne? Może programowanie kontekstowe, które narodziło się podczas dyskusji w mistrzem projektowania domenowego – Dino Esposito, na konferencji Code Forward która odbyła się pod koniec kwietnia. Czy to się przyjmie – nie wiadomo. Może znajdzie swój czas, i ktoś dostrzeże, że dane różnie pracują w zależności od kontekstu w jakim są użyte, i choć dane są takie same – to kontekst, podobnie jak interfejs, określa metody. Jest to bardzo przydatne przy modelowanie wielu procesów i może poprawić czytelność rozwiązań, jednak nie jest to powód do mody prowadzącej do nadużywania.
Faktem jest, że obserwujemy różne mody, promujące na stanowisko „najlepszego paradygmatu programowania” coraz to inne techniki które sprawdziły się tam, gdzie poprzednio modny paradygmat – się nie sprawdzał. Dostajemy więc do ręki inne narzędzie. Na przykład śrubokręt. I z uporem godnym lepszej prawy – usiłujemy wkręcać gwoździe.
Czy jesteśmy skazani na mody dotyczące kolejnych metodologii? Cóż, przynajmniej do czasu, aż nie zrezygnujemy z religijnego podejścia do poszczególnych technologii. Może to trochę potrwać, bo prędzej dostosowujemy problem do umiejętności rozwiązywania, niż uczymy się czegoś zupełnie nowego. A jeśli się uczymy – chcemy to stosować. Najlepiej wszędzie, bo skoro to takie dobre…
Jednak nie istnieje uniwersalna metoda która pozwoli efektywnie rozwiązać każdy problem. Istnieje za to wiele sposobów rozwiązywania.