ale tyhle reci o bohu a o prospesnosti globalni kvalite zivota nikomu faktury za telefon a elektriku nezaplati.
A zalozit firmu na tom, ze jedine support ktery vydelava obvykle nejmene bude ziskovy... to je spatna vize
Opět jste se projevil jako krátkozraký materialista zřejmě neschopný nadhledu a jiného progresivního myšlení, lpící na zaběhlých principech a své misce kaše.
Naprosto mi nebudou chybět firmy zaměstnávající programátory, kteří se jednou naučili svůj jazyk plus nějaké API a od té doby skálopevně setrvávající na svých zaběhlých postupech.
Já sám jsem po letech technického i duševního vývoje dospěl do stavu kdy pro jakoukoliv smysluplnou (pro mě) práci, používám nástroje a jazyky vyjadřující myšlenku a řešený problém v její co nečistší abstraktní podobě, protože CPU a systémové architektury, operační systémy a jejich API či knihovny rozhraní jsou věcí pomíjivou. Proč se obskurní architektura x86 udržuje tak dlouho a bolestně při životě kromě ekonomické vazby na svého výrobce? Protože její software jakožto (nevhodně nízká) aplikace myšlenky přežívá po velice dlouhou dobu narozdíl od HW. Jedině použití otevřeného, multiplatformního a vysokoůrovňového modelu zajistí dlouhodobý přínos z fungování kvalitního a odladěného programu a optimální využití investované duševní práce.
...pro jakoukoliv ... práci, používám nástroje a jazyky vyjadřující ...problém v její co nečistší abstraktní podobě, protože CPU a systémové architektury...jsou věcí pomíjivou...
To je jen jedno z řady možných hledisek, které abstrahuje od toho, že SW projekty mají svou omezenou životnost, programování obecné je dražší, než programování specifické (viz optimalizace web stránek pro různé typy browserů) a hlavně z technických důvodů často nepřijatelné - protože výkonem i funkcionalitou musí respektovat nejslabší článek z platforem, o které se implementačně opírá.
Výsledkem např. je, že Java je sice relativně abstraktní prostředí, ale současně relativně pomalé a pro např. pro vývoj her, které mají životnost na trhu několik měsíců, v nejlepším případě let je její použití těžko odůvodnitelné. Čili Vaše teze je nutno brát s rezervou a s přihlédnutím ke konkrétnímu účelu a podmínkám řešení. Nehledě k tomu, že zcela abstraktní prostředí je záležitost abstraktní.
Ano. V podstatě s vámi souhlasím. Samozřejmě nemohu v pár slovech postihnout všechny formy SW.
Moje jak říkáte "teze" se nedají a ani jim to nemám příliš za zlé, aplikovat na dnešní spotřební SW, který je tvořen cestou nejmenšího odporu a nákladů pro krátkodobou okamžitou spotřebu. Něco jiného je to s projekty které v různých podobách úspěšně přežívají léta. Podíváte-li se na datum vzniku většiny základních programů libovolného UNIXového systému, ocitnete se v období počítačového dávnověku, aniž by jim to snad ubíralo na užitné hodnotě. Ony nepřežívají z pozice ekonomické síly či dominantního postavení na trhu, přežívají proto že jsou všeobecně užitečné a splňují podmínky otevřenosti, platformní přenositelnosti a dodržování elementárních standardů.
ad Java. Pohnutky jejího vzniku bych také příliš čistě neviděl, ale jako příklad určitého stupně abstrakce poslouží dobře. Problém Javy který jste nastínil je pouze otázka vrstvy mezi HW a JVM, kterou tvoří operační systém. Pokud ale je pro tvůrce OS platformní přenositelnost v přímém rozporu se základní marketingovou strategií jeho dominantní firmy, pak i sebelépe specifikované Java3D API, JIT kompilátor s optimalizací pro cílovou architekturu nebo buffering optimalizovaného nativního kódu zbytečný. Tato skutečnost samozřejmě negativně ovlivní rozvoj vlastností Java API i JVM na ostatních platformách. Pomalost je jen dočasný relativní nepoměr mezi náročností programu a výkonem HW. Podívejte se na NextStep - koncepce jež předběhla svoji dobu a zažívá rozkvět až v modernizované podobě MacOS X, protože v době svého zrodu nebyl HW který by jí výkonově stačil.
Hlavne je duolezite brat ohlady na vyrobne naklady daneho SW. Hlavne v pomere ku "ziskom", ktore su umerne dobe jeho pouzivania.
RAD (Rapid Aplication Development) nastroje su velmi pekna vec umoznujuca znizovat vyrobne naklady a zrychlyt tempo vyvoja aplikacie, ale maju jednu velmi nebezpecnu vlastnost, ktora nie je na prvy pohlad vidiet:
Ak niekto vytvori nejaky modul, obvykle sa v dalsich fazach vyvoja uz nikto nestara, co vsetko ten modul robi a ako cisto je implementovany. Tak sa moze chybne (alebo nebezpecne) napisany modul znovu-pouzit v RAD prostredi dlhe roky a "nakazit" tak mnoho projektov.
Nazornym prikladom je BO exploit na M$ W2k3, ktory je pouzitelny aj na W2K a NT (a to PR M$ vyhlasovali cosi o kompletnom prepisani kodu W2k3). Zda sa, ze to iba prepisali z jedneho HDD na druhy HDD :-)
ČLÁNKY DO MAILU