Refleksji ciąg dalszy

Minął kolejny tydzień, kolejne spotkanie w ramach szkolenia .NET. Tydzień ten przyniósł kilka odpowiedzi i nowych, tytułowych, refleksji na temat trendu w dzisiejszej informatyce.
Otóż ostatnio żaliłem się na stopień abstrakcji nowych narzędzi programistycznych. Owszem są one wygodne i projektowane "dla ludzi", jednak siłą rzeczy powstaje wiele pośrednich poziomów abstrakcji, które obciążają dodatkowo komputery. Mimochodem usłyszałem powód nurtującego mnie zwiększania wymagań sprzętowych. Otóż godzina pracy programisty jest więcej warta niż 1GB pamięci. Szeroko otwarłem usta jak to usłyszałem. Prawdę mówiąc zmusiło mnie to do zrewidowania poglądów i spojrzenia szerzej na programowanie, jako na proces wytwórczy. Wynika z tego, że ilość pracy, jaką programiści mają do wykonania na rzecz gospodarki przewyższa ich możliwości wytwórcze i fizycznie nie są w stanie zaspokoić potrzeb rynku. W tym kontekście staje się całkiem jasne dlaczego nowe narzędzia nastawione są na łatwość i szybkość tworzenia nowego oprogramowania, ponieważ jeśli oprogramowanie jest, a działa powoli to i tak lepiej, niż gdyby go nie było.
Taki stan rzeczy prawdopodobnie w przyszłości doprowadzi do pogłębienia różnic między programistami zajmujących się pisaniem aplikacji użytkowych na potrzeby firm i instytucji oraz programistów zajmujących się programowaniem narzędzi programistycznych.
Jakie znaczenie mają moje wynurzenia dla przyszłego programisty? Otóż warto byłoby się zastanowić, po której stronie bariery chcemy stanąć: czy będzie to poziom tworzenia aplikacji komercyjnych dla przedsiębiorstw, czy może tworzenie narzędzie niezbędnych do pracy tym wcześniejszym programistom (praca o tyle ciekawsza, że polega na wybieganiu w przyszłość tworzeniu standardów i trendów dla przyszłych pokoleń programistów - należy zauważyć, że jest to bardziej elitarny "poziom" programowania). Inną płaszczyzną aktywności zawodowej dla programisty może być tworzenie sterowników i projektowaniu list rozkazów przyszłych procesorów - dotykamy tutaj tak zwanego programowania niskopoziomowego (low-level programming). Specjaliści w tej dziedzinie muszą jednak posiadać wiedzę z pogranicza informatyki, elektroniki, czy teorii sterowania.
Na zakończenie dodam, że pomimo mocnego argumentu stosowania nowoczesnych (dających duży narzut obciążenia wynikający z zastosowanych metod) technik programowania to jednak dążenie do optymalizowania oprogramowania nie powinno być tylko zrzucone na garb narzędzi. Należy umieć znaleźć kompromis (tak wiem, kompromisy śmierdzą ;P) pomiędzy szybkością tworzenia oprogramowania a jego wydajnością.