szuboptimális
Tényleg nem fogod fel, hogy nincs olyan, hogy optimális.
Sikerült felsorolnod három olyan példát, amelyeknél a fenti körben emlegetett "kompatibilitás" (itt: több platform támogatása) skálán... hát legalábbis messze megbuknak az általad "optimális"-nak kikiáltott szoftverek. Tényleg elképzelni sem tudod, hogy nem mindenkinek (sőt: a többségnek nem) azok a prioritásai, mint neked? Hogy te vagy az egyetlen, aki a gépet folyamatosan úgy használja, hogy figyeli a task managerben a CPU minden rezdülését?
Van, akinek mondjuk az a fontos, hogy minden rendszerén használhassa a programját (cross platform). Van, akinek mondjuk az a fontos, hogy ne használjon annyira retardált programot, ami a C:\ gyökerébe okádja be magát egy 1800-ból ránk maradt telepítő által (helló, TC... és mondjuk vesd össze a Double Commander msi telepítőjével - Ghislernek sem lenne több 30 percnél fogni egy Wix-et, megírni egy retkes xml fájlt és csinálni normális telepítőt). Van, akinek...
Hanem az, hogy melyik bloated frameworköt használjuk, hogy két héttel előbb legyünk készen, mint a konkurencia™.
Igen, mert a TTM az _egyetlen_ érv, ami bármilyen framework/tool/nyelv/akármi használata mellett szólhat. A fent felsoroltak (kód mennyiség, karbantarthatóság, portolhatóság, biztonság, vendor-függetlenség, ...) még véletlenül sem játszhatnak közbe egy-egy ilyen kiválasztáskor. Tényleg, milyen gyönyörű világ lenne, ha senki nem használhatna semmilyen libet és mindent NIH szindróma szerint újra és újra feltalálnának. _MINDEN_ olyan szinten kibaszott bug halmaz lenne, hogy csak na.
Egyébként pedig: melyik szintig kelljen minden újraírni. Így pl. ha írni akarok egy hello world-öt, számíthatok arra, hogy van alattam egy kernel és van egy loader, ami betölti a programom, vagy kezdjek CPU-ütemezőt írni? Ugyebár a fordító egy eszköz, tehát az elméleted szerint bloat, tehát az egészet közvetlenül gépi kódban kell írnom. De várjál, amikor elküldöm a write request-et a diszknek, akkor abban is szoftver fut, azt meg ugye nem használhatom, tehát azzal kell kezdenie a programomnak, hogy feltölti a saját firmware-jét a diszkekre...
Azt kéne már megértened, hogy ami neked "bloated framework", amögött más látja, hogy miért van rá szükség. Például mert már n+1-szer megírta azt a kódot, ami azt a működést adja, ami a "bloated framework"-ből egy mozdulattal kiszedhető. És rájött, hogy nincs értelme újra és újra feltalálnia a kereket.
Persze, továbbra is megéri™ megvenni az új processzort és kidobni a régit azért, hogy legyen benne AES-NI.
Az AES-NI csak egy példa volt az elmúlt 10 évben megjelent új utasításkészlet kiterjesztésekre (TSE, AVX-*, BMI stb.). Eközben persze a CPU-n levő, de nem tisztán a számításban részt vevő egységek (GPU, MMU...) is folyamatosan fejlődtek.
És nem, nem csak a szoftverek erőforráséhségének a növekedését követték le a változások. Ha ez így lenne, akkor nem lenne játszhatatlanul lassú egy 3rd és játszható egy 4th gen. laptop i5-ön ugyanaz a játék - a kettő között levő másfél év alatt az átlag szoftver GPU igénye nem nőtt ennyit, az Intel GPU-kat meg soha nem szánta játékra.
(btw, egész sokat hangoztatod ezt a "tíz év alatt alig duplája" szöveget, de nem adtál forrást, hogy honnan és milyen metodikával jött ez ki)
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)