...az az emberi társadalom egyértelmű elhülyülésének eredménye...
Minden szavad igaz, de ez az egész jelenség még jobban megérthető a gazdasági jelenségek, - és most itt hegyezzük ki - a szakmai folyamatok tükrében.
Volt először a hardver...
Nem a szoftver, hanem "a hardver futott". Ebben a korszakban a szakemberek számára szinte nulla volt a tévesztési lehetőség. Ez alatt természetesen nem azt értem, hogy nem tévedhetett egy ember, hanem a produktum nem tartmalazhatott hibákat.
A következő a gépi kód és assembler állomása. Ez még mindig hardver, csak flexibilis eszközök segítségével megfogalmazva. Ezzel párhuzamosan megjelent a szoftver is. Az assemblerben kivitelezett produktum, - mivel hardvert valósít meg - még mindig nulla közeli hibalehetőséget enged meg. De ugye, a szoftver már nem. ;)
Aztán jött a C, amely lehetővé tette a gépközeli programozást és szoftvertermékek előállítását is. Míg az assembler eleinte a hardverhez értő kevés szakember privilégiuma volt, a fejletteb nyelv már szélesítette az alkotásban résztvevők körét.
A C++ már igazi tömegek számára biztosított munkát. Ezzel egyúttal elindította a szakma felhígulását.
No, és hol tartunk most? Informatikus hiány van! Fluktuáció, nincs igény, tudás, hajlandóság az alapos munkavégzésre.
(Mielőtt bárki is belekötne, ez nem egy szoftvertörténelem óra, csak kiragadott példa.)
A dolog buktatója a hardver. Van egyszer a Moore-törvény, ami a sebesség exponenciális növekedését jósolta és az idő bebizonyította a sejtés működését.
Sajnos a szakma felhígulása, a szereplők (összefoglalásként) trehánysága, és az ilyen hozzáállással készült toolok használata a lassulásban magasabb negatív kitevőt eredményeznek.
Egyszer oktatás közben - régi szép időkről mesélvén - kaptam egy kérdést, hogy miként értékelem a fejlődést? Hiszen a "személyi számítógépek hajnala óta" a szakmában vagyok. Rövid fejszámolás után - amit extrapolálok a mai napra - a következő megállapítas tehető: Azóta a processzorok teljesítménye 5000000x (ötmillíószor) nagyobb, miközben ugyanazt a feladatot legalább egy kicsit lassabban végzik el.
A cikk írója szerint: That is not engineering. That’s just lazy programming. Engineering is understanding performance, structure, limits of what you build, deeply. Combining poorly written stuff with more poorly written stuff goes strictly against that. To progress, we need to understand what and why are we doing.
Ezt kellene megérteni néhány huptársunknak is, akik szerint én vagyok a rossz, amikor nem tudok, se nem is látom értelmét annak, hogy egy feladatot perlben oldjak meg.
Igen, már megint a hardvernél tartunk! Az OOP esetében fel kell fogni a sok absztaktció mellett azt az egyszerű tényt is, hogy bizony a 10x több memória megtöltése 10x annyi időbe kerül. Ez egy gyors gépen persze nem számít. Biztosan nem számít, hiszen ettől (is) lassabbak a programok. :-D És nem szabad beérni azzal, ha a fejlesztő gépén még elfogadható idő alatt lefut a feladat! Hiszen ma már kizárólag multitasking környezetben futnak a programok. A feleslegesen felhasznált erőforrások a többi program elől veszik el a lehetőséget.
Az ilyen dolgokat összevonva a hasonló elvek szerint készült libbel és a nem túl nagy kvalitású programozóval máris jól megdöntöttük a Moore-törvényt!
Sok esetben tapasztaltam, hogy egy rendszert modernizálva és korszerű gépen futtatva a jelentős mértékű lassulás mellett funkcióvesztés is fellép. Vagyok annyira szkeptikus, hogy előre meg tudom jósolni a romlás mértékét. De mindig bejön. ;)
I’ve been programming for 15 years now.
No, én meg 35. Nem dobálodzom azzal, hogy az XP jobb. Egyszerűen - előzetesen hozzáértő szakemberekkel konzultálva - nem vállalom fel a fenti jelenségek miatt keletkező extra szívást. Így aztán nyugodtabb az életem.