Przyszłość programowania
- Jakub Chabik,
- 08.06.2010
Odpowiadam na to pytanie gdzieś tak od 1983 roku. Dawniej myśleliśmy, że w ogóle nie będziemy programować: powiemy komputerowi, co ma zrobić, i on to po prostu zrobi. Jeśli będziemy cokolwiek robić, to najwyżej przestawiać prostokąty i łączyć je liniami. Oto jesteśmy 25 lat później i oto nadal programujemy. Postęp okazał się być wolniejszy niż wszyscy sądziliśmy. Będę więc bardzo ostrożny i powstrzymam się przed prognozami, że będziemy komputerom mówić co mają zrobić, a nie jak. Ale z pewnością będziemy w stanie przekazać więcej przy pomocy mniejszej ilości kodu i w bardziej deklaratywny sposób. Z pewnością przez następne lata programistom nie zabraknie zajęcia.
Anders Hejlsberg o przyszłości programowania dla amerykańskiej edycji Computerworld.
Nie sposób nie wspomnieć o narzędziach niby-programistycznych, niezwiązanych jednak z językiem programowania, a służących do przetwarzania danych. Doskonałym przykładem jest tutaj arkusz kalkulacyjny, proste środowisko, które w rękach utalentowanego samouka może stać się prawdziwą bronią masowego rażenia. Informatycy w przedsiębiorstwach ze zdumieniem odkrywają dziś, że zaawansowane funkcje związane ze sprzedażą, planowaniem produkcji czy finansami przedsiębiorstwa nie są realizowane przez specjalizowane aplikacje, a przez rozbudowane arkusze Excela. Bogate w funkcjonalność i graficzne wizualizacje, wykorzystywane w wielu procesach biznesowych, często korzystające z zewnętrznych źródeł danych, stają się krytyczne biznesowo - mimo że nie tworzył ich informatyk, a specjalista z danej dziedziny.
To tylko przedsmak rewolucji, która może się wydarzyć dzięki językom dziedzinowym, środowiskom mashup oraz rozpowszechnieniu się wiedzy na temat budowy rozwiązań informatycznych wśród osób innych niż inżynierowie IT (tzw. business empowerment).
Otwartość i bezpieczeństwo
Kolejnym trendem, który - jak się wydaje - przesądzi o przyszłości w programowaniu, to otwartość. Środowiska developerskie są sceptyczne wobec wszystkich technologii, narzędzi i środowisk, które należą do jednej firmy i są od niej w pełni zależne. Słowo proprietary dyskwalifikuje technologię nieomal tak samo jak odpowiedniki "niestabilne" albo "nieskalowalne". Nawet firmy, dla których narzędzia programistyczne to tzw. core business (Sun z Javą, Microsoft z .NET), musiały zgodzić się na przynajmniej częściową otwartość i radykalnie obniżyć ceny swoich środowisk ze względu na konkurencję ze strony darmowych, a jednocześnie otwartych i sprawdzonych platform, jak wspomniane już PHP, MySQL, Ruby, Python, Perl, itd.
To samo dotyczy aplikacji. Wspomniany już problem budowania rozwiązań informatycznych z usług i aplikacji zgromadzonych w internetowej "chmurze" oraz takiej konstrukcji własnych rozwiązań, by mogły stać się tej "chmury" częścią, wymaga publicznie dostępnego i dobrze udokumentowanego interfejsu aplikacji. Wielu autorów do swoich aplikacji dołącza tzw. μAPI i schemat udostępnianych przez aplikację danych. Pozwala w ten sposób innym autorom aplikacji skorzystać ze swoich rozwiązań, jednocześnie nadając społecznościowe (jak na Web 2.0 przystało) oblicze środowiskom aplikacyjnym.
Jeśli współczesne rozwiązania aplikacji internetowych przypominają mozaikę lokalnych i zdalnych komponentów realizujących konkretne funkcjonalności, to moc tej mozaiki jest taka, jak siła wiązania kleju, który ją spaja. Współczesny autor (a po trochu architekt) aplikacji musi nie tylko umieć tworzyć komponenty i korzystać z istniejących, ale przede wszystkim łączyć to wszystko w całość odpowiadającą na oczekiwania klienta biznesowego i dającą dodatnią wartość ekonomiczną.