"Miért nem lehetséges?" - kérdezed. Én alapvetően szoftverfejlesztői szemszögből tudom elmondani, hogy miért illetve miért nem lehetséges elérni amit akarsz.
- Ahogy fentebb már írták, az új, bonyolultabb funkciókhoz több CPU és memória kell. Könnyű belátni, hogy egy olyan levelező progamban, ahol van helyesírás ellenőrző ami folyamatosan fut a háttérben, jóval több memória és CPU kell, mint ami egy egyszerű szövegbeviteli mező (főleg, hogy akár még a szöveg nyelvét se adod meg, ezért a programnak kell több szótárat memóriában tartva kitalálni, hogy milyen nyelven kellene helyesírást ellenőrizni).
- Ezzel nincs is gond, de a te kérdésed ha jól értem az, hogy "nekem nem kellenek az új fancy funkciók, bőven elég amit 10 éve tudott, de az legyen gyors". Erre a válasz pedig részben anyagi, részben technológiai.
- Anyagi azért, mert az emberek valamilyen oknál fogva többre tartják a hardvert, mint a szoftvert. Hány ember vett több százezres telefonokat, de alkalmazásokra már nem költ ilyen nagyságrendben? Hány ember volt, aki ész nélkül vett erősebb PC-t, minthogy letiltson pár erőforrászabáló plugint a firefoxban? Hány ember fizetné ki a win98 árát a megjelenése után mondjuk 10 évvel még egyszer, hogy cserébe megkapjon bele egy csomó kompatibilitást elősegítő featuret és biztonsági javításokat? Amíg ez a hozzáállás nem változik, nem lesz motiváció a vevői oldalról a fejlesztők felé. A fejlesztők mennek abba az irányba, ahol nekik a legolcsóbb a fejlesztés, mivel a vevők nem fizetik meg a több energiával elkészült szoftvert.
- Kérdés persze, hogy ha rendelezésre állna a motiváció, tudnánk-e olyan szoftvereket csinálni, amik jobban kiállják az idő próbáját. Sajnos e szempontból hiányzik az oktatás és a fejlesztői kultúra, módszertan. A programokat több, különálló modulra kellene bontani, oly módon, hogy azok később könnyebben karbantarthatóak, cserélhetőek legyenek. Energiát kell fektetni az interfészek alapos átgondolásába, hogy ne tartalmazzon olyan dolgot, ami később nehezen karbantartható (https://en.wikipedia.org/wiki/Leaky_abstraction). Teljesítmény teszteket kell írni, hogy egy esetleges új funkció ne tudja lerontani a már meglévők teljesítményét. Kompatibilitási teszteket kell írni, hogy az új és régi modulok az összes lehetséges (vagy leggyakoribb) kombinációban működőképesek-e. Ezek részben anyagi, részben kultúrális kérdések is (értem ez alatt, hogy a fejlesztő gyakran szívesebben dolgozik valami érdekes, de túl sok ember által nem használt featureon, mint próbál memóriát optimalizálni, ami bonyolult és "veszélyes"). Számtalan példa van az iparban, hogy SW fejlesztők bika gépekkel (átlag desktop gép x 3) fejlesztik a szoftvert, mondván "mire megjelenik, már ez a teljesítmény lesz az "átlag" (ráadásul még ezeken a gépeken se fut gyorsan).
- Aki SW fejlesztő és nem hiszi, hogy lenne mit söprögetni a saját háza táján, beszéljen mondjuk private cloud üzemeltető adminokkal. Nekik a munkájuk jelentős része arról szól, hogy lekorlátozzák az erőforrásokat (adatbázist, virtuális gépet, hálózati tárolót), utána pedig veszekedjenek a fejlesztőkkel, akik megpróbálják elmagyarázni, hogy de, nekik bizony miért is jár ez az erőforrás és "manapság a hardver már semmibe se kerül". Ja persze a fejlesztők olcsó desktop hardverre gondolnak, nem minőségi, redundáns rendszerre, amin a kódjuk ténylegesen fut. Ettől függetlenül persze ténylegesen lehet olyan eset, amikor egy fejlesztő órabére több, mint amennyivel több erőforrást felhasznál optimalizálatlanul.. a trükkös kérdés inkább az, hogy évek alatt, az adatmennyiség növekedésével is olcsóbb az erőforrást pakolni a szoftver alá, mint egyszer hatékonyabbra megírni?
- Szintén gyakori, hogy van egy X db modulból álló rendszer, ahol ha csak egy modulnak is kell valami újabb (akár utasításkészlet, akár szoftver API), akkor az lesz a legalacsonyabb közös nevező az egész rendszert tekintve. Ha X nagy, akkor mindig van olyan dolog, ami "húzza" magával az egész rendszert, új minimum követelményt definiálva.
Nyugtasson a tudat, hogy néhány év múlva a szoftverek igen nagy része webes lesz, ahol a web böngésző mint kompatibilitási réteg valószínűleg alacsonyabb erőforrásigényű és/vagy régi gépeknek is képes ugyanazt a funkciót biztosítani (ehhez persze vedd hozzá, hogy a funkciók egy része átvándorolt a szerver oldalra, ahol ugyanúgy fogyasztja az energiát, csak nem közvetlenül számodra látható módon).