Co bys považoval za dobrou alternativu k dynamizovanému statickému webu?
Zahodit koncept webového prohlížeče a nahradit ho pouhou VM, zahodit koncept webových stránek a nahradit je kompletně jednotným standardizovaným bytekódem appletů, které ať si každý píše, v čem mu to vyhovuje/co je pro daný účel nejvýhodnější, doplnit o podepsané knihovny (dostupné transparentně z dotazovaného serveru či odjinud), vše spravované na straně klienta systémem cache. Webová stránka, jež je ze své podstaty pouhým označkovaným textem, by tak byla nahrazena plnohodnotným programem.
Applet, který jen zobrazí analogii statického webu, by nebyl o nic složitější ani delší než současný web. Odpadly by všelijaké CSS, cookies, flashe a podobné nesmysly. Při přístupu k portálu (třeba jako root.cz) by došlo jen ke stažení dat, protože veškerý kód by byl nacachovaný u klienta včetně potřebných knihoven. Zjednodušila by se komunikace klient-server i klientA-server-klientB, klient-klient apod. Zjednodušilo by se sdílení dat. Ne, že by řada z toho dnes nešla zařídit, praxe si to vynutila, ale děje se tak často neuvěřitelně krkolomnými způsoby. Což je i důvod, proč si myslím, že se jednodušší řešení při masovém rozšíření toho současného nemá šanci rozšířit - prostě protože
nějak to jde i tak.
protoze nic lepsiho vymysleneho nebylo 
Právě že bylo.
Jestliže tytéž problémy vyřeším na třetině LOC a za pětinu času, tak ať mě nikdo nepřesvědčuje, že nepracuji s lepším nástrojem. Dlouhé roky jsem dělal v C++, backendy i frontendy, embedded i PC, pamatuji Turbo Vision i OWL, jásal jsem nad Qt... Něco málo (ve srovnání s objemem práce v C++) jsem dělal v Javě a v C#. Ale když to srovnám s věcmi jako Cocoa v Objective C nebo smalltalkovými frameworky, tak je to prostě parní stroj versus parní turbína - základní myšlenka je sice stejná, ale jsou tam jisté velmi podstatné rozdíly.
V OOP je dynamické typování opravdu výhodnější - kvůli polymorfismu a velmi pozdní vazbě.
Nenašel jsem situaci, kdy by pozdní vazba bránila typům. Můžeš uvést příklad?
Už to tu zmiňoval Kit. Spíš jde o ty přívlastky statický/dynamický. Rozdíl bych viděl asi v tom, že ve statickém případě se v daném místě další (řádný) běh programu může odvíjet jedině od dat. V dynamickém od dat
a/nebo jejich typu, nebo dokonce nezávisle na jejich typu. To dává větší spektrum možností, jak na ně program v daném místě může (řádně) reagovat. Ve statickém případě se musím omezit (často zbytečně defenzivně) jen na určitý typ dat, přičemž diskrepance mezi povinně deklarovaným očekávaným a reálně přijatým typem dat vede k chybovému stavu. Jsou to opačné imperativy - za všech okolností znát typ dat, s nimiž pracuji, vs. nestarat se o typ dat, dokud to nezbytně nepotřebuji k práci s nimi.
Jinými slovy, zatímco v klasickém přístupu chci pole integerů a případ, kdy bych chtěl pole nějakých obecných prvků, je více či méně krkolomný, u objektového přístupu chci primárně pole nějakých obecných prvků a když budu chtít, aby tam byly jen integery, budu si to muset nějak (více či méně krkolomně) pohlídat.
Nevidím důvod, proč by ty obecné prvky neměli mít patřičný typ. Mám komponentu, do které chci vkládat různé widgety. Tak bude dozajisté užitečné, když mi to tam pustí jen widgety (input, textarea, datepicker, timepicker, calendar, grid, form, ...), a integer nikoliv.
A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky. O to, že v ní budou jen rohlíky, se postarám tak, že do ní prostě nic jiného nedám. Ale konat nákup za situace, že mám k dispozici jen tašky na rohlíky, přepravky na lahve, tašky na šunkové salámy, tašky na párky, tašky na chleby apod. by mohl být docela nesnadný úkol. Přitom v tom obchodě je jistě vhodné, aby zboží bylo roztříděno dle druhů, stejně tak ten, kdo z něj bude vařit, bude potřebovat odlišit máslo od chleba. Ale pro účely přenosu z obchodu domů to bude jedno, nebo spíš bude třeba odlišit, co je křehké a co ne. Křehká jsou vejce, ale taky třeba sklenice nebo žárovky či pivo ve skle. Nikoli však pivo v PETce. Pro účely uskladnění se bude rozlišovat podle toho, co půjde do ledničky (pivo bez ohledu na to, je-li ve skle či v PETce), co do mrazáku, co do špajzu. A to je právě ta mnohotvárnost - možnost klasifikovat tytéž objekty za různých situacích - pro různé potřeby různě. Ale k tomu je nezbytné, aby se s nimi
technicky dalo zacházet úplně stejně - abych je pokud možno mohl všechny uchopit do ruky a tím s nimi manipulovat a pouhým pohledem, přičichnutím apod., prostě dle vlastnosti, jež mě zajímá, je klasifikovat (včetně situace "tohle mi dali místo sušenek Vanda, ty se už nevyrábějí, ale prý je to něco podobného" a "tohle vůbec netuším, co je, dali mi to pro Frantu, tak mu to prosím předej").
Jiná analogie - dříve PC mělo DIN konektor na klávesnici, DB9 na myš, DB25 na tiskárnu, ale taky byly PS/2 konektory na myš a klávesnici, externí disky měly SCSI, které obvykle představovalo taky další kartu do základní desky... Dnes to řeší jednotné USB a dynamicky se rozhodne, jakým způsobem se připojené zařízení bude obsluhovat.
Takže většina toho, čemu říkáme citáty, zvláště ty latinské, vlastně podle tebe vůbec citáty nejsou. Prosím, držme se obecně přijímaného významu slov a nevymýšlej si pro ně své vlastní definice. Ale nešť - tak jsem přeparafrázoval Kayovy názory
Souhlas, tak si nevymýšlej nesmysly. Definice: “Citát je doslovné znění z díla spisovatele, anebo doslovně zopakovaný výrok. [...] Při citování se uvádí jak autor, tak i dílo v kterém se výrok objevil.” Tohle jsi měl mít na ZŠ (předpokládám, žes ji úspěšně ukončil), asi to fakt jde s naším školstvím od 5 k 0.
1355 Odpovědí
129834 Zhlédnutí