Wcześniejsze środowiska baz danych wymagały opisania krok po kroku ścieżki postępowania przy łączeniu, sortowaniu i formatowaniu danych, aż do osiągnięcia zamierzonego efektu. Dzisiaj, za sprawą pojawienia się tzw. języków dziedzinowych (domain-specific languages, DSL), które tworzone są pod konkretną potrzebę, przetwarzanie informacji jest dostępne nawet dla osób bez przygotowania technicznego. Charakterystyką DSL jest przywiązanie do konkretnego zastosowania, np. ubezpieczeń, logistyki czy geologii. DSL posługuje się pojęciami, danymi i strukturami charakterystycznymi dla tej (i żadnej innej) dziedziny. Dzięki temu, to samo zadanie, które w tzw. ogólnym (generic purpose) języku programowania zajmuje trzy strony, w DSL realizowane jest w kilku linijkach. Ceną jest brak uniwersalności - ale też nie po to tworzy się tę klasę języków. Siła formalnego rygoru i elastyczność, tak charakterystyczny element w programowaniu AD 2010, poświęcona została w imię prostoty i zwięzłości języka.

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ą.