Přejít k navigační liště

Zdroják » Různé » Zpátky do osmdesátých…

Zpátky do osmdesátých…

Články Různé

Pokrok informačních technologií vypadá z pohledu technika jako neustálé zvyšování počtu hertzů a bajtů, jako jízda po rovné silnici dál a dál, a zdá se, že zvyšování výkonu ani kapacity zatím nestojí nic v cestě. Ale co z toho mají lidé? Dělají taky víc a složitějších věcí? Potřebují opravdu gigahertzy a terabajty?

Nálepky:

Připravoval jsem testovací nástroj pro seriál na Zdrojáku a prohlížel si přitom seznam technologií, počítaných do rodiny HTML5 – tedy kromě nových značek v HTML a novinek v CSS i všelijaká API, která slouží k ukládání dat, ke komunikaci se servery, ke geolokaci… Změna ve vnímání prohlížeče z těchto návrhů a (budoucích) standardů přímo čiší. Během patnácti let se prohlížeč proměnil z čehosi, co umělo zobrazit formátovaný text s obrázky a odkázat na jiný text, na velmi výkonný a důležitý program, jeden z nejzásadnějších v dnešních osobních počítačích. Tak důležitý, že stírá hranice mezi systémem a aplikací. Je prohlížeč vůbec ještě pouhá aplikace, nebo je to běhové prostředí pro aplikace, které umí i zobrazovat dokumenty?

HTML5 a technologie s ním spojené posouvají prohlížeče od „zobrazovačů textů“ k „systémům a aplikacím“, a vypadá to jako lineární vývoj, ale dost možná se nám zdá lineární proto, že vnímáme nejsilněji jen bezprostřední minulost a budoucnost. Co když je to spíš spirála, po níž se posouváme do stejného místa, kde jsme už byli, jen o kousek výš?

Historická odbočka

V osmdesátých letech jsme si, nadšení, natahali do domů malé osmibitové počítače. Hráli jsme na nich hry, učili jsme se na nich programovat, a někteří z nás je používali i k relativně smysluplné činnosti: malovali na nich obrázky, psali texty, připravovali výkresy, vedli evidenci čehosi či jimi řídili externí zařízení. Bylo to pomalé a z dnešního pohledu primitivní, ale stačilo nám to.


Ilustrační obrázek: sxc.hu

Když začal výkon počítačů růst, byli jsme zase nadšení z toho, že můžeme psát delší texty, malovat jemnější obrázky lepšími nástroji a vést obsáhlejší evidenci čehosi (a hrát vymakanější hry). Každý megahertz a megabajt navíc znamenal pohodlnější práci (a úžasnější hraní), až jsme se někdy po roce 2000 dostali do okamžiku, kdy výkon počítačů už není to, co by nás omezovalo. Práce dnešního stolního PC či notebooku vypadá tak, že počítač se vším svým obřím výkonem a kapacitou asi tak 97 % času čeká, jestli po něm něco nebudeme chtít. Když po něm něco chceme, tak to bleskurychle udělá, a zase čeká.

A my píšeme texty, zpracováváme fotografie a video, připravujeme výkresy, vedeme evidence čehosi a řídíme externí zařízení, o hrách nemluvě. V podstatě tedy děláme totéž, co jsme dělali v osmdesátých letech (až na to video), jen to máme barevnější, větší, máme lepší nástroje a míň u toho čekáme. Na co jsme tehdy čekali minutu a v 90. letech několik desítek sekund, to trvalo v roce 2005 sekundu (a bylo to použitelné). Před dvěma lety půl (a bylo to pohodlné). Letos 0.37 sekundy. Slavný bonmot o milisekundách, co zdržují sice má racionální jádro, ale ruku na srdce: když něco trvá 0.37 sekundy, je to „hned“, pokud to trvá 0.5, je to „hne-ed“; ten rozdíl by musel být mnohem větší, aby se pro běžného uživatele z nepostřehnu­telného proměnil na iritující.

Lidé nepotřebují, aby počítač měl rychlý procesor a hodně paměti; potřebují, aby je nezdržoval.

Rychleji a radostněji

Vývoj aplikací prochází takovými cykly – aplikace se zrychluje, má stále víc funkcí, a jednoho dne se objeví její klon, který je podstatně jednodušší, menší, hezčí, nemá vůbec tolik funkcí, a stane se populární, protože si běžní uživatelé uvědomí, že vlastně všechny ty funkce ani nepotřebovali. Jako příklad mě napadá třeba „odloupnutí“ Firefoxu od Mozilla Suite.

Výkon současných počítačů už několikanásobně přesahuje minimum použitelnosti i pohodlí. Podívejte se na Word verze 2000 a 2007, odmyslete si jiné rozložení ovládacích prvků a efekty a zkuste přijít na to, co zásadně nového přinesla nová verze, bez čeho byste se neobešli a co by přitom před deseti lety nebylo technicky možné. Moc toho není, že?

Pěknou ukázkou toho, že nové vyumělkované funkce v aplikacích vlastně nepotřebujeme (ve smyslu nezbytnosti), jsou všelijaké online verze desktopových programů – všechny ty online Wordy a Photoshopy a čtečky a další. Jsou naprogramovány – alespoň ta viditelná část – v JavaScriptu (či ve Flashi, který je totéž, jen v bledě modrém – klidně by následující odstavce mohly být o něm).


Ilustrační obrázek: sxc.hu

Kdysi jsem v nadsázce psal, že JavaScript se dostal do stádia, kdy svým výkonem na 2GHz procesoru dokáže totéž, co umělo ZX Spectrum s 3.5MHz osmibitovým Z80. Dnes už jsme dál – dnes má JavaScript na rychlých strojích s rychlým JS enginem výkon, který bych se nebál srovnat s Amigami či Atari ST. Už dokáže emulovat ZX Spectrum.

A co? Vždyť na tom není vlastně nic špatného. Copak nám ty stroje nenabídly možnost dělat skoro všechno, co jsme dělat potřebovali? Jasně, bylo to pomalé, nedokonalé a (mili)sekundy nás zdržovaly, ale upřímně: být ty aplikace rychlejší – místo „možné“ alespoň „použitelné“ – tak nám stačí dodneška.

Jako bychom se se vší slávou kolem HTML5 a spol. vraceli na konec osmdesátých let, ke svým Amigám a eSTéčkům – jen jich máme víc najednou. Dnešní prohlížeč se mění ve virtuální počítač a ta změna je čím dál tím zřetelnější. Co okno, to jedna virtuální Amiga, Atari ST či Spectrum. JavaScript je strojový kód těhle virtuálních počítačů, DOM jejich textová konzole, canvas grafická. FileAPI a WebStorages jsou jejich hardware.

A to je ve skutečnosti přesně to, co většině lidí stačí. Běžnému uživateli na jeho práci opravdu stačí počítač se schopnostmi té Amigy, možná snad potřebuje mít jich víc – na jednom mu hraje hudba, na druhém běží mailový klient a IM, na třetím píše text. S rychlejším počítačem člověk nepracuje ani víc, ani rychleji. Komfortněji, to ano.

Co bude dál? Zatím se vždycky vysoký výkon úspěšně promrhal v tom, že se doplnila nějaká softwarová mezivrstva, která sice zpomalila běh programů, ale zato zjednodušila vývoj aplikací či umožnila přenositelnost. V dobách osmibitů to byl interpret BASICu, dnes to je JVM, .NET a nejrůznější vrstvy OS. Zítra to bude pravděpodobně prohlížeč a JavaScript/Flash.

Je tedy jen logické, že až se JavaScript zrychlí z „použitelné“ na „pohodlné“, přijde další krok – co takhle v JavaScriptu napsaný interpret dalšího jazyka? HTML parser (ten už je – Pure JS HTML Parser) a zobrazovací engine pro canvas? Teoreticky by šlo v JavaScriptu napsat HTML prohlížeč s výstupem do canvasu (a nebudu se divit, jestli se dozvím, že ho někdo už napsal). Vzniknou pak i vyšší jazyky a překladače, jejichž výstupem bude JavaScript+HTML5 kód? Pravděpodobně ano – a se vší tou parádou a obrovským výkonem uvnitř budeme spouštět skoro tytéž aplikace, co jsme používali na konci 80. let. Ne rychleji, ale víc najednou.

Protože většina uživatelů vlastně doopravdy nepotřebuje o moc víc. Stačí jim, když to bude pohodlné a nebude je to zdržovat.

Komentáře

Subscribe
Upozornit na
guest
138 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Dero

Proklínám tě, Arthure! Teď si kvůli tobě musím zahrát Manic Minera. :)
Jinak počítač coby okno do internetu je fantastická věc. Do tohoto věku jsem se já narodil. Na stará kolena budu vnukům vyprávět, jak jsme kdysi měli na počítači aplikace, které neukládaly data na internet. A že k prohlížení webu sloužil program zvaný prohlížeč (ano, děti, tehdy jsme webkitu říkali různými jmény; a nebyl jenom webkit – nebudou věřit). A že jsem jako malej kluk dokonce chvilku „programoval“ na tzv. osmibitech (jmenovitě na stroji PMD-85), ke kterým celá generace geeků přede mnou měla úzce nostalgický vztah. A když mi nahlas ujede staromilské „wtf“, děcka mě budou mít za vykopávku. :)

Přezdívka je povinná

gr8, ale tak nějak to fakt bude :)

Murdej

To mě připomíná jak jsem instaloval autoškolu na jeden „dinosauří“ (nejaké pentium I, 32MB RAM) počítač.
Celkem sranda je že Quake (bez hw grafické akcelerace) tam jel plynule v pohodě a nastartoval za pár sekund. Kdo někdy zkoušel programovat 3D bez openGL, D3D, … ví kolik toho musí CPU spočítat na jeden frame.
Narozdíl od toho program „Autoškola“, program co vykreslí jeden obrázek napíše pár řádků textu a čeká a uživatel klikne, startoval 10 minut stránku vykresloval 2 minuty a zpracovával výsledky dalších 5 minut.
To je „daň“ za rychlé počítače nenažrance typu .net a podobně.

Tomix nepřihlášen

Zkus občas použít čárku. Možná to pak bude k přečtení.

Pavel2

Vždyť je to naprosto čitelné.

snehuliak

Ano, bolo to citatelne, nevsimol som si ze by ciarky chybali.
Dobry clanok!!!

Radovan

Jo, to byla možná ta samá Autoškola co jsem instaloval před pár lety u sousedů. Procesor necelých 300 MHz, 96 MiB RAM, osmadevadesátky tam jely docela pohodově… Samotný program Autoškola se nainstaloval za nějakých pět minut, ale pak si začal instalovat .NET, a to trvalo třičtvrtě hodiny!!! Dokonce sám instalátor uznal že to „trvá déle než je obvyklé“, a zeptal se jestli se na to radši nechceme vykašlat :-D

Jen si tak říkám, je velký rozdíl mezi tím co dělá .NET dneska a tím, co dělal BASIC na osmibitech v těch báječných časech osmdesátých let?

zd.valek

Není :)

Azmodan

No něco pravdy na tom bude, ale zase na druhou stranu v osumdesátých letech počítače řešili rádově snažší úlohy než dnes s řádově nižší složitostí dat. Zkuste si představit jak vypadal takový ERP systém v té době a jak dnes. Na druhou stranu prográmek typu autoškola, který počítá výsledek 5min… to bych tipoval spíše na lajdáckého programátora než na .net :)

Radovan

Těch pět minut trvala instalace toho programu, ne jeho činnost ;-) I když žádný zázrak to nebyl, v podstatě to dělalo to samé, co jsem viděl u prehistorické Autoškoly ze Slušovic, která se vešla na jednu disketu.

Biktop

Základní otázkou ovšem je, proč dnes ty počítače řeší řádově složitější úlohy s řádově vyšší složitostí dat. Opravdu musejí? Obávám se, že nemusejí – že to řeší prostě proto, že mohou – proto se nikdo neobtěžuje s pořádnou analýzou, jež by nepochybně vedla k závěru, že 90% informačních systémů by se dalo zredukovat na tu samou složitost, jako v 80. letech, aniž by byla z uživatelského hlediska narušena jejich funkcionalita. Je opravdu nezbytné, aby se každé číslo tisíckrát přechroupalo mezi různými formáty a standardy, aby se nakonec přechroupalo zpět na normální číslo, s tím se provedl výpočet a výsledek se opět přechroupával mezi různými formáty, standardy, XMLky apod.? Je opravdu nezbytné, aby se kvůli generování jednoho řádku HTML musel sto padesátkrát vznést SQL dotaz do nějaké super komplikované databáze, provést tisíc a jedno volání mezi různými knihovními funkcemi a celé to bylo doprovázeny dalšími dvěma sty padesáti přepnutími kontextu kvůli kooperaci několika vláken?
Až do 80. let se programovalo tak, jakoby se zdilo z cihel. Dnes se aplikace vyvíjejí tak, jako by se stavěly už ani ne z panelů, ale dokonce z celých prefabrikovaných bloků. Pokud je třeba postavit z těch prefabrikátů budovu tak, jak si to představoval autor těch prefabrikátů, bude to mnohem snazší, rychlejší, levnější a efektivnější, než z cihel. Pokud bude třeba dělat sebemenší dílčí změny, odchylky, stává se to kvůli rigidnosti toho systému elegantně prakticky neřešitelný problém. Zákazník si přeje propojit dvě kanceláře v sousedních patrech schody? Aj, aj, tak to se musí vedle celé budovy postavit další schodiště s výtahem (dílce bez výtahu se nedělají), které bude celé nevyužité s výjimkou těch dvou pater, protože neexistuje dílec, kterým by se takový problém řešil. Zákazník si přeje dveře mezi ředitelnou a sousední kanceláří svého zástupce, nacházející se ve 20. poschodí? Problém – s tím náš systém nepočítá, ten to řeší přes interní poštu a interní podatelnu… Ale můžeme extra vybudovat expresní výtahy mezi inkriminovanými kancelářemi a podatelnou, nacházející se v přízemí, takže můžete sjet dolů a tam se domlouvat přímo v podatelně. Nebo můžeme vybudovat pomocnou podatelnu přímo v 20. poschodí pro potřeby těch dvou kanceláří, k tomu upgradovat telefonní ústřednu (aby to zvládala) a zvýšit kapacitu schodišť a výtahů kvůli zvýšené zátěži… Takovým způsobem vzniknou překombinované, super komplikované stavby, náročné na materiál, energie i údržbu, ačkoli by se to celé dalo vyřešit nesrovnatelně jednodušším způsobem. Můžeme pak tvrdit, že dnes už se nedá stavět z cihel, protože dnes se stavějí takovéto obludnosti, které by z cihel nikdo v rozumném čase nepostavil. Což je pravda, protože by se o to ani nepokoušel a ani by mu to nijak nechybělo.
Abych parafrázoval Chucka Moora – ukažte mi libovolný průměrný program z posledních 10 let a já vám přesně tu samou věc udělám tisíckrát menší, rychlejší a jednodušší.

To nejlepší není někdy dost dobré!

Zlatá slova, pane. Zlatá slova !

Michael

Presne tak…
+1

noFlame

Nostalgický brek a nefunkční analogie se stavbou domů..bez urážky. Celá filozofická debata o tom, proč se dělají složité programy je naprosto zbytečná, dělají se jednoduše proto, protože jsou potřeba. Myslím, že kdyby se pan Moore pustil do přepisování nějakého velkého programu do céčka, asi umřel v polovině projektu na zavaření mozku.

Pletiplot

Nemyslím si, že ta analogie je nefunkční. Analogie je naprosto funkční. Smyslem je to, že přilepit další „blok“ k programu je levnější než něco upravovat. Já sám taky občas použiju nějakou funkci, která za mě udělá to co chci, ale ve 20 násobným čase, než kdybych to napsal pořádně a musel při tom myslet, ladit, padesátkrát chybovat, opravovat a mít výsledek za 2 měsíce. A to je přesně ten důvod, že už se nedá stavět z cihel a taky to autor příspěvku říká. Dnes musí procesor obcházet ten blok a chodit z jedné kanceláře do druhé kolem celé budovy a někdy i venkem, protože původní bloky s tím nepočítaly. Ale procesor je rychlý, že to nikomu nevadí.

qix

Házíš rozumy ale nevíš že se píše pořád a ne pořát.

Ivan Nový

Je fajn být nezávislý. Nebo mít otevřeno najednou více programů. Přehrávat si filmy na počítači, prohlížet si fotky, stříhat video z dovolené.

Ivan Nový

začít tvořit distribuované aplikace jinak. Začít přes Javascript v prohlížeči, tak aby dalším logickým krokem bylo opuštění Javascriptu a prohlížeče. To bude další zásadní inovace, na kterou teprve čekáme. Bude to něco jako objevení PC v 80. letech. Tehdy taky panovaly názory, že běžný člověk počítač nepotřebuje. A vidíte, jak se to změnilo.

Ivan Nový

Ano, samozřejmě. Ale PC bylo v 80. letech symbolem osobní svobody. Dnešní člověk, ale o svobodu trochu ztratil zájem. Protože ji zatím má.

Tisnovsky

a nebo oprasit stary dobry(?) X-protokol a spoustet aplikace vzdalene, u sebe mit jen graficky terminal. Ony k tomu stejne rich-client aplikace postupne smeruji

Kit

Běžně to tak dělám a určitě nejsem sám. Má to ovšem své mouchy.

Bukaj

Myslím, si, že by to v globálnějším využití neprošlo. Přeci jen ty aplikace někde musíš spustit. A pokud to budou ty samé aplikace a budou se spouštět jen někde jinde, pro víc lidí, tak ve výsledku tu máš režii navíc pro přenos velkýho počtu dat přes síť.

František Kučera

„nechat prohlížeče na prohlížení a udělat aplikační runtime pro distribuované aplikace“
Takhle funguje desktopová Zimbra – běží lokálně, ale nepoužívá GTK, Qt ani Swing – místo toho vykresluje GUI pomocí prohlížečového jádra. Časem se možná dopracujeme k nějakému zobecnění, aplikace bude ZIP obsahující HTML, JavaScript, SVG atd. a poběží v libovolném systému. Na jednu stranu je to fajn, ale mám z toho trochu smíšené pocity – klasické aplikace nepovažuji za zlo, toolkity jako Qt nebo GTK pořád nabízejí více možností a instalace těchto klasických aplikací pomocí linuxových balíčkovacích systémů je velice pohodlná – snazší už to snad ani být nemůže, vrcholem je asi Ubuntu Software Center, ale ani ostatní distribuce se nenechají zahanbit, i ten nejprostší uživatel jednoduše jen klikne dvakrát na hezkou barevnou ikonku a pak na tlačítko „Instalovat“. S těmi webovo-desktopovými aplikacemi to bude podobné, ale zas tolik mne to nebere…

Přezdívka je povinná

Java web start?

Například. Je to má oblíbená technologie, má široké možnosti a promyšlené zabezpečení… Ale řada lidí má nějaký mentální blok, averzi k Javě, a taky je dost vývojářů/webařů, kteří ji neumí nebo dokonce nechtějí umět – pro ně by se hodila jednoduchá možnost vytvořit nějaké to HTML/CSS/JS/XML… a zabalit do ZIPu a mají „aplikaci“ – podobně jako se teď dají dělat zásuvné moduly pro Google Chrome/Chromium – možná by šel použít i ten jejich formát (nebo ten Firefoxu), akorát se na to dívat jako na samostatnou aplikaci, ne jen jako doplněk k prohlížeči.

pas

„nějaké to HTML/CSS/JS/XML… a zabalit do ZIPu“
== Adobe AIR.
Ten ale zřejmě pomalu pozbyde smyslu, protože všechno to, co řeší (app cache, local storage, connection notification, drag and drop spolupráce s OS, …) má ambice vyřešit samotné HTML5, resp. samotné browsery.

František Kučera

Pokud bude plně otevřená implementace, tak proč ne…

prezjivka


> Jawa web start ...
> ... Je to má oblíbená technologie, má široké možnosti a promyšlené zabezpečení…

Opravdu, neni to ta kde byla ta bezpecnostni chyba ?

František Kučera

Jaká?

Madi

Souhlasím s Vámi, na psaní mají tužku nebo psací stroj, na hraní kuličky v parku a na práci se mohou drbat třeba za uchem, že …? Ale asi jste myslel, že na to všechno nějaký ten počítač potřebují nebo ne?!

Mintaka

Takových aplikací existuje přeci spousta. Například klient k Ultima Online. Rozdíl je ovšem v tom, že určeny pro specializované využití zatímco prohlížeče se zaměřují na obecné.

Ivan Nový

No ano, ale jde o to, jak vytlačit obecné prohlížeče založené na HTML. Jinak se dál nedostaneme. HTML, DOM, CSS je rozšířený paskvil. Vychází totiž z papírového dokumentu. V budoucnosti budeme potřebovat prostředky jejichž základ vychází z obrazovky, či tabletu. Nemusí emulovat papírový dokument na obrazovce. Obecný klient ano, ale bez HTML.

Kit

Je však nutné odstínit aplikaci od zbytku operačního systému, aby aplikace nemohla zasahovat do nepřidělených lokálních prostředků. Z multiplatformních běhových prostředí se asi nejlépe osvědčila Java.

pas

Ano, Java, rychle ji ale dohnal Flash, dále je tu už také vyzrálý a výkonný Silverlight, potom oborově specifické platformy (Unity na hry)… na výběr je toho dost, a tak se mi pořád jeví trochu nadbytečné, že se najednou i HTML rozhodlo, že půjde tímto směrem. Logicky to musí skončit určitou technologickou splácaninou, tak jak se to teoretikovi dnes musí jevit. Podle mě by bylo přínosnější, kdyby se browsery zaměřily na co nejlepší (výkonné, bezpečné, …) hostování pluginových technologií v rámci svého sandboxu. Říká se jim sice „proprietární“ a stalo se z toho sprosté slovo, ale jejich volná konkurence by nakonec přinesla stejný užitek pro všechny, jako se očekává od konsensuálního a všeobjímajícího HTML5. Ale třeba se pletu a každopádně fandím jak HTML5, tak i pluginům a těším se na ChromeOS. Oproti trápení s nativními aplikacemi a klasickými OS to bude pro běžné uživatele balzám na nervy.

v6ak

Doplním asi celkem opomíjené JavaFX.
„Říká se jim sice „proprietární“ a stalo se z toho sprosté slovo, ale jejich volná konkurence by nakonec přinesla stejný užitek pro všechny, jako se očekává od konsensuálního a všeobjímajícího HTML5.“
No nevím, aby to zas nedopadlo jako s IE.

pas

Formát pro publikování dokumentů potřebuje jasný standard, který musí všechny prohlížeče přesně dodržovat. Stejně jako jiné formáty pro výměnu dat.
Ale v oblasti běhových prostředí pro aplikace může krásně existovat volná konkurence technologií, stejně jako je konkurence programovacích jazyků, operačních systémů, atd.

František Kučera

To by chtělo, aby takový plugin běžel např. pod AppArmorem a měl by zakázané všechno kromě zápisu do ~/abcd a čtení z ~/efgh atd., tahle omezení by uživatel viděl předem a odsouhlasil by je. Pak by mohl být plugin napsaný jako běžný program v libovolném jazyce, to by bylo fajn.

Ivan Nový

ti kromě jídla a místa ke spaní a trochu oblečení nepotřebují nic dalšího, když na to přijde, ale o produktivitu práce, a ta je v případě HTML, DOMu a prohlížečů malá.

Ivan Nový

Proč? No protože o tom rozhodl trh, rozšířily se prohlížeče založené na HTML. A HTML efektivitu vylučuje, protože má stromovou strukturu, listy se opakují vkládáním. Nemá podprogramy. Prosadit na trhu něco jiného nebude snadné. Proto bude třeba využít toho co je, tedy „enginů“ stávajících prohlížečů. Až budou existovat dostatečně rozšířené aplikace nového druhu, bude možno opustit staré prohlížeče a nahradit je jinými, které budou ještě nějakou dobu umět emulovat ty staré. Něco podobného probíhá s Facebookem, ten pomalu nahrazuje internet. Může se stát, že internet se uzavře (zhroutí) do FB, uživatelé se nebudou přihlašovat do internetu, ale rovnou do FB, časem může vzniknout klientská aplikace jen pro FB. Obchod, „www stránky“, vyhledávání to vše může být adoptováno FB, mimo FB se pak běžný člověk ani nepodívá.

Ivan Nový

a tam, kde je běžný člověk, tam jsou i peníze.

Kit

HTML není a nebude programovací jazyk. Pokud někdo má potřebu podprogramů, použije JavaScript nebo PHP (ostatní mi snad prominou), případně kombinaci.
Něco podobného jako uzavírání do FB je pozorovatelné i na Google. Google Chrome OS je už jen samostatným rozhraním, které bez přihlášení do služeb Google zřejmě ani nefunguje.

Ivan Nový

Ano, ale kombinace jiný jazyk na clientovi a jiný na serveru, není příliš efektivní. Psaní aplikací tak, že vlastně generujete výstup v HTML a javascriptu vede k tomu, že kód je nepřehledný a nefektivní. Chtělo by to jiné paradigma, které by ovšem muselo být tak chytlavé, jako svého času bylo HTML.

Kit

Java?

František Kučera

Přesně to mne napadlo. Stejný jazyk na serveru jako na klientovi, EJB komponenty publikované přes CORBA-IIOP protokol, když se ze serveru pošlu objekty určité třídy/rozhraní, můžu se na klientovi spolehnout, že bude objekt mít patřičné metody a proměnné, odpadá spousta práce…

Srigi

Něco podobného probíhá s Facebookem, ten pomalu nahrazuje internet. Může se stát, že internet se uzavře (zhroutí) do FB
Nieco podobne podla mna nehrozi ani omylom. Je to ako tvrdit, ze Linux smeruje k jedinej distribucii. V oboch pripadoch zakonite dojde k tomu, ze niekto spravi alternativnu stranku/distribuciu s velkou (konkurencnou) user zakladnou.
Inak povedane, keby FB bola jedina stranka Internetu, protokol, technologia HTTP a TCP stale umoznuje vznik inej stranky, kde odidu vsetci nespokojny s FB. V pripade Linuxu je tym co umoznuje vznik alternativy open source software.

Karel

Kolem roku 1994 se také někteří domnívali, že HTTP nahradí internet. A mnozí oponovali, že to je nesmysl, že IRC, Gopher, Usenet, LISTSERV jsou natolik populární, otevřené, široce podporované, že HTTP s velmi omezenými možnostmi (umí jen zobrazit text a obrázky a to ještě všude jinak) prakticky nemá šanci stát se majoritní platformou. No a kde je dneska Gopher, Usenet a LISTSERV? A i to IRC už dnes vypadá jinak než dřív… Pro řadového uživatele byl internet již dávno nahrazen webem. FTP nepoužívá, email obsluhuje přes webové rozhraní a DNS sice používá, ale neví o tom. Takže veškerá jeho komunikace je v HTTP. Takže osobně bych nevylučoval, že se internetem časem stane něco dalšího (ať již http://www.google.com, http://www.facebook.com nebo něco jiného). Ostatně, pro řadu mých známých je internetem http://www.seznam.cz :-) Dokud nevidí jeho úvodní stránku tak internet nefunguje…

Tisnovsky

Nojo, ale kdyz se nad tim zamyslis, tak se vlastne vsechny ty prenosove protokoly pouze posunuly o jednu vrstvu vyse – co se drive resilo na vrstve TCP/UDP, tak ted bezi nad HTTP, takze se napriklad nejak obchazi jeho bezstavovost (tim, ze se nad HTTP vybuduje dalsi protokol), chybova kontrola atd., takze vlastne zadna extra nova technologie v tom ve vysledku neni.
Coz neznamena, ze HTTP je spatne (spis naopak), ale jen chci rict, ze nektere problemy, ktere se jeho pouzitim ukazuji, uz napriklad byly davno vyreseny protokoly primo nad TCP ci UDP.
Pravda je, ze napriklad Gopher jakozto predchudce prohlizecu, celkem popravu umrel, ale IRC se drzi, FTP taky + samozrejme POP3, IMAP, SMTP a dalsi – mozna nejsou vsechny „videt“ na koncovych pocitacich, ale bez nich by ta posta do weboveho rozhrani e-mailu nedosla :-)

nmbmnbm

Pohybuji se trochu po stavbach a http je z pohledu me soucasne profese jedna z moznosti, jak nakonfigurovat nektere krabicky, ktere se dnes v budovach vyskytuji. Jinak krabicky spolu po internetu komunikuji uplne jinymi protokoly. V tomto smeru jsem naprosto v klidu. (O neco mene v klidu jsem pri predstave, co se bude dit, az zacnou byt tyhle krabicky zajimave pro hackery.)

Ivan Nový

No ale jeden příklad tu existuje, dominace MS v operačních systémech na desktopu.

Kit

Jenže to ztrácí na významu. Aplikace stále častěji využívají různá běhová prostředí, která fungují na všem možném. Přibližuje se to stavu, kdy bude jedno, na jaký operační systém daný program nainstaluji. Ostatně to byl jeden z důvodů, proč byl stvořen UNIX.

lacik

Nestrašte s Facebookem; jednou jedinkrát jsem tam vlezl a když jsem zjistil, jaké údaje to po mně chce, tak jsem odtamtud fofrem utekl, smazal co se dalo, zablokoval kdeco, dveře za sebou zatloukl hřebíky a zalil betonem. A po čase se povalilo, že z FB zmizely údaje o 108 osob.
Ale nemyslím, že k tomu dojde; tak jako nástup kina neznamenal konec divadel, nástup televize konec kin, tak nástup facebooku nebo google nebude znamenat konec klasického anonymního internetu.

phi

není nutné tam psát pravdu :)

volani.webnode.cz

A není nutné číst pravidla? :)
Také internet využívám hodně a facebook pouze pro prohlížení toho co tam dávají ostatní…

em

Ja na Facu nejsem a jsem zatim celkem spokojeny

ZdenekJi

Facebook je kravina pro puberťáky, nemůže konkurovat celému internetu.

František Kučera

Celému ne, ale tomu běžnému konzumnímu docela konkuruje, resp. podařilo se vyvolat mánii, že každá firma „musí“ být na facebooku a twitteru, jinak má pocit, že o něco přichází a utíkají jí zákazníci… vznikají i firmy zaměřené na „social marketing“, které poradí, jak si vytvořit stránku na facebooku a jaké kydy tam psát… Nicméně je jen otázka času, kdy to praskne a ukáže se, že firmy nalily peníze do konzultací a sociálních sítí obecně, ale v důsledku nula z nuly pojde, trh nevzrostl, potenciálních zákazníků nepřibylo, akorát je tu nový způsob, jak se o ně přetahovat s konkurencí – tzn. až tam budou všichni dodavatelé a situace se vrátí do původního stavu, resp. tržby budou stejné, jako by byly, kdyby žádný facebook neexistoval.

pas

Kravina pro puberťáky aspoň naznačila, jak by se mohl dělat sémantický web (viz OpenGraph), usnadnila práci malým firmám v tom, že nahradila vlastní implementaci diskusních fór, alternativu k RSS kanálům, kalendáře akcí, atd. Proč by vše muselo být černobílé – buď užitečná věc nebo kravina pro puberťáky?

honza

Moje žena (a její kamarádky + rodina) je podle mě typický uživatel FB a puberťák už dávno není.

Dřív používala ICQ pro rychlou komunikaci, rajče na fotky, vlastní web jako blog, hrála hry …

Dnes ji na všechno stačí pouze FB… Můžeme o tom diskutovat, ale reálně FB prostě pohlcuje do sebe ostatní služby, ať se nám to líbí nebo ne… Určitě se vždy najde „underground“ mimo FB, ale nic masového.

František Kučera

Za to můžou zlí administrátoři – zakazují nám porty na firewallu, takže aplikace nemůže komunikovat „normálním“ protokolem a všechno se valí přes HTTP, zakazují nám instalovat aplikace, takže ty běží v prohlížeči… a taky za to můžou Windows jejich DLL hell, problémy s kompatibilitou atd. Z obchodního hlediska je prostě webová aplikace nejsnazší cesta, jak překonat všechny tyhle těžkosti* a dostat program k co největšímu počtu zákazníkům.
*) a tady je právě otázka, jestli se s jejich existencí smířit a brát ji jako fakt, nebo se místo obcházení problému snažit vyřešit jeho příčinu…

pas

Já bych řekl, že ani revoluce, ani smíření, ale prostě evoluce – vždyť stačí vyřešit pár problémů, jako je prosazení těch pár doplňujících komunikačních řešení, aby se jich administrátoři nebáli (WebSockets, RTMP pro Flash, apod.) a pak už jen těžit z výhod webových aplikací, které rozhodně nejsou malé.

František Kučera

Jak nebáli? Vždyť jak už tu někdo psal – protokoly se akorát posunuly o jednu vrstvu výš – místo aby stavěly na TCP/UDP staví teď na HTTP. A začalo to tím, že administrátoři omezovali provoz jiných služeb a povolili jen „prohlížení webu“ – celkem přirozenou reakcí bylo, že aplikace začaly komunikovat po aplikačním „webovém“ HTTP protokolu a tak se z něj stal protokol víceméně transportní jako byl (je) TCP. Důvod je jednoduchý: když děláš aplikaci (a zvlášť má-li být výdělečná), potřebuješ, aby se dostala k co nejvíc lidem – když bude stavět na jiném (třeba technologicky vhodnějším) protokolu a komunikovat např. na portu 1234, tak se k těm lidem nedostane, protože jejich admin povolil jen 80/443. A lidi si řeknou, že tvoje aplikace je blbá, protože „nefunguje“. Chyba je ve skutečnosti někde jinde, ale to BFU nechápou. Dalším krokem je vznik různých transparentních proxy a filtrování webu, resp. HTTP provozu – zatímco dřív stačilo zablokovat určitý TCP port a omezit tak IM nebo P2P komunikaci, dneska administrátoři analyzují HTTP provoz a filtrují vybrané domény nebo vybraný obsah, aby zabránili lidem třeba v tom chatování. Dělá se prostě totéž co dřív, jen na vyšší síťové vrstvě (HTTP místo TCP). Celé IT se tak točí v kruhu a požírá samo sebe. Plýtvá se energií, která mohla být využita k něčemu smysluplnějšímu, jedni vymýšlejí, jak lépe filtrovat a zakazovat, druzí vymýšlejí, jak tyto zákazy obcházet, jak dostat svoji aplikaci k uživatelům i přes firewally (protože jinak by byla obchodně neúspěšná), např. Skype, Jabber BOSH, nebo obcházet zákazy instalovat aplikace → přesun aplikací na web nebo vytváření různých „portable“ verzí aplikací. WebSockets – fajn, ale opět je to typická ukázka problému, který si IT vytvořilo a pak IT na něj našlo řešení – lépe řečeno. záplatu, bastl, místo aby se odstranila příčina problému. Místo aby si aplikace prostě navázala TCP nebo UDP spojení, vytvoří jakási jejich emulace nad HTTP protokolem.

pas

Však ano, já tomu rozumím… nebo aspoň myslím. :) Proto píšu, že by bylo potřeba doplnit všeobecnou důvěru v HTTP důvěrou v pár dalších protokolů na standardních portech (v oblasti Flashe, do které vidím, to je RTMP nad TCP, resp. RTMFP nad UDP) a bylo by to – žádná revoluce (pořád se tomu ještě dá říkat webové aplikace), jen vyřešení toho nejhoršího bastlení a plýtvání. Snad k tomu dojde, až se ukáže, že všemožně filtrovat HTTP nic neřeší trvale.

František Kučera

P.S. jaké že to jsou ty nemalé výhody?

pas

Tak to se doufám nejlíp ukáže na Chrome OS. Právě jsem po dlouhé době dělal své mámě údržbu stařičkého PC – nechal jsem Outlook komprimovat poštu, v půlce to spadlo a po dalším spuštění chyběly maily za poslední 3 měsíce. Chvíli jsem se hrabal v nějakých souborech, pak jsem to vzdal a naučil ji používat GMail. Běžnému uživateli prostě pomůže, když bude odstíněný od souborového systému a od instalování a údržby aplikací. Můžeme sice snít o nějaké technologické revoluci, ale jediná cesta, jak toho dnes dosáhnout, je web.

mixal11

myslim ze nejaky dll hell vo windowse je nic oproti dependency hell v linuxe :)

Kit

Jenže dependency hell je v Linuxu řešitelné, např. úpravou zdrojových kódů. Případně celkovou refaktorizací, pokud nám ta aplikace za to stojí. Můžeme tak získat i řádově výkonnější systém, kterým se vrátíme do kýžených osmdesátých let.
Ovšem k Assembleru či C bych se jen nerad vracel. Každý z nás raději sáhne po nějakém vývojovém prostředí a vhodném jazyku. Pokud však programátor nezvládne paradigma zvoleného nástroje, stane se z aplikace polofunkční líný moloch.

bauglir

Wow, takže protože jeden program na Linuxu je závislý na jedné verzi knihovny a druhý na jiné, budu předělávat program :)
Zlatý winka, nahraju si požadovanou verzi knihovny do adresaře, kde je program a problém vyřešen…

František Kučera

Jako uživatel tohle neřešíš – to je práce distributora nebo autora programu, aby aplikace fungovaly s aktuálními knihovnami. Pokud to jako programátor nechceš řešit, můžeš i v GNU/Linuxu linkovat knihovny staticky (místo dynamicky) a máš po „problému“ – nemusí tě trápit, jaká verze knihovny je instalovaná v systému – ale je to primitivní řešení na úrovni Windows. Většinou je lepší program udržovat a aktualizovat, kromě jiného tak, že bude kompatibilní s aktuálními knihovnami.

michal

LD_LIBRARY_PATH

František Kučera

jj, to taky, ale Windowsáři většinou nechápou, o čem je řeč – tak je dobré říct, že i v Linuxu to jde dělat jako ve Widnows a mít všechny knihovny u programu – kdo chce kam… :-)

hany

To je trochu zkreslená (zastaralá) představa. Od Windows XP a výše se více verzí téže sdílené knihovny řeší přes tzv. Side-by-side assemblies (WinSxS).

snehuliak

Odpoved je jednoducha. Uzivatelske rozhranie je navrhnute pre „bezneho“ cloveka.
Beznemu cloveku staci nedokonale HTML, copy/paste a neustale klikanie na web-formulare a natahovanie java apletov trvajuce niekolko sekund… Dalej to radsej nebudem rozvadzat…

thr

Tak jistěže je spíš mrháním výkonem to, že na emulaci Spectra v Javě je třeba možná až 1000× vyšší výkon, než mělo původní Spectrum. Zrovna tak lze polemizovat o efektivitě x věcí. Na druhé straně ale třeba pro práci s obrazem a videem se bez pořádné dávky výkonu CPU neobejdete. Měl jsem možnost věnovat se třeba DV videu už v době, kdy to nebylo zdaleka tak obvyklé a vrcholem techniky (myslím reálně dostupné pro jednotlivce) bylo něco jako Pentium III na 500MHz – popravdě řečeno se na podobném stroji fakt moc rozumně pracovat nedalo. A nešlo jen o CPU – na hraně byl tehdy i disk, prakticky bylo pro nějaké operace žádoucí mít samostatný disk, který se před prací zformátoval, aby odpadla fragmentace. Když to srovnám se situací dnes, tak je to opravdu totálně někde jinde – prostě připojím kameru (mimohodem s podstatně vyšším rozlišením než dříve) k jen o trochu lepšími notebooku bez nějaké optimalizace a vše jede v pohodě…
No a podle mě je tohle propojeno – je dost důvodů k růstu výkonů skutečně smysluplnému, bohužel ale to má jako vedlejší efekt i určité plývání, kdy se řada aplikací dělá dost neefektivně, protože se spoléhá na to, „že to CPU stihne“.

Petr

Pche, amatére stříhat video na PC. Kdo byl IN tak samozřejmě pro střih využíval specializovaný počítač Casablanca ;-)

David Ondřich

Arthure, skoro vždycky mě tvoje postřehy potěší, dnešek nebyl výjimkou. Myslím, že první krok správným směrem, bude možnost předkompilovat JavaScript. Tuším, že je to za dveřmi…
A ještě poznámku: moje bývalá žena by správně podotkla, že ta křivka, kterou v úvodu popisuješ, se jmenuje šroubovice.

Kit

Pokud dnes spouštíme nějakou aplikaci, tak ve své podstatě většinou spouštíme virtuální operační systém, který se stará o své mini aplikace, případně další mini operační systémy. Komunikace mezi těmito subprocesy je již v plné režii tzv. běhového prostředí. Na tvůrci aplikace leží rozhodnutí, které běhové prostředí se mu bude hodit nejlépe. Buď jednoduché a rychlé, anebo komplexní a pomalé.

Já

Já ještě nikdy neměl nový počítač, teď mám P4 1,8GHz a neustále na něco čekám. A z většiny flashových videí mám slideshow. Nenávidím flas na webu.

Kit

Jedu na Atomu 1,6 GHz a nečekám. Obvykle stačí si nainstalovat plugin FlashBlock.

Dr Meduza

Ale video ve flashy si nepustite, to je prave o tom pohodli
Ja si treba poustim playlist z youtube s pisnickama na pozadi misto radia (krasna ukazka plejtvani vykonem a konektivitou) a k tomu mam prak pracovni virtualni stroje s VMWarem (v podstate jedinej zpusob jak resit pripojeni do mnoha siti najednou), takze ja sem vdecen za obrovskej vykon a mnoho GB pameti
Ale jak jiz bylo receno, vsechno by se dalo delat na nekolika starejch pocitacich ale s mensim pohodli

Kit

Ale spustím. FlashBlock mezi web a flash pouze vloží jedno kliknutí. Pokud tedy nějaký flash chci spustit, stačí na něj kliknout nebo mu udělám výjimku. Ostatní zůstanou v klidu a nezdržují.
Existuje mnoho způsobů, jak se připojit do mnoha sítí najednou. WMWare je jen jedním z nich, primárně je však určen k něčemu jinému.

Twiguard

Já mám netbook s 1.6 Atomem Inteláckou „grafikou“ a jedu na něm HD videa z YouTube a offline videa až 1280p. To už sice není bez problému, ale se správným softwarem (Linux + Xine) a uklizenou RAMkou to jde.

Loyssa

Od určitého bodu se kvantita promění v kvalitu. Takže nakonec, až budou počítače maximálně výkonné, dostatečně malé a přizpůsobené, tak zjistíme, že jsou zbytečné.

Tisnovsky

Ahoj Martine, kruh se zacina uzavirat, tady
http://www.6502asm.com/
je emulator osmibitoveho mikroprocesoru 6502 (docela dobra studijni pomucka) a ja se, jen tak pro zabavu, chystam udelat Basic a Forth v JavaScriptu (Basic uz existuje, ale ne ten klasicky „osmibitovy“), takze dalsi vrstvy na JS (ktery je sam tak na 5–6 vrstve nad HW) uz jsou na ceste :-)

Tisnovsky

Díky za odkaz, to je opravdu jako skutečný Forth :-), tedy samozřejmě s tím rozdílem, že klasický Forth běžel s 1 kB paměti na 1 MHz procesoru a tento má jak paměti tak i výpočetního výkonu zhruba 1000× víc, to je pokrok :-)

senior

Já pořád jen čekám na počítač. Nejdřív se startuje windows, potom se spouštějí nějaké aplikace, pak se spustí ten norton a skenuje a než to všechno doběhne, zapomenu, co jsem vlatně chtěl a počítač vypnu.

Kit

Na rychlé poznámky se hodí PDA. Zapnu, do 2 sekund mám spuštěnou potřebnou aplikaci a pracuji. Je až k nevíře, jak rychlé jsou PDA s pomalými procesory ve srovnání s moderními PC a moderními OS.

em

dve sekundy je dlouho. Musim mit tuzku a papir u ruky a jeste si vec neustale opakovat. Kdyz jsou dve tak je to pru………

Kit

Uvedené 2 sekundy jsou samozřejmě maximální čas. Pokud je ta aplikace již spuštěna nebo je v aktivním menu, tak to samozřejmě trvá mnohem kratší dobu.
Za 2 sekundy ovšem člověk nestačí ztratit myšlenku. Kritických je prvních 10–20 sekund, během kterých většina notebooků nestačí nabootovat.

Radovan

Abych pravdu řekl, někdy jsou pro mě i ty dvě sekundy pamatování moc, zvlášť když se valí víc průserů najednou :-D

em

Me fakt staci ty dve sekundy. Nebo pohled z okna.

SRG

řešením je nevypínát, nýbrž dávat do režimu spánku/hiberna­ce.. ;-)

-=RYS=-

Jeste, ze jsem mel ATARI ST/Falcon/TT/ATW ABAQ (ano, ten s transputery Inmos).
OS byl v ROMCe a konfigurace Os na diskete/HDD a v mem pripade na PEROM (28LV512…4kb paralelni EEPROM, ma konstrukce), takze po zapnuti jsem za 3s mohl zacit pracovat.
Toto schazi na dnesnich PC.
Idealni by bylo, kdyz by OS byl na flesce spolu s BIOSEm na jedne sbernici k radici MB u CPU. Nabeh Win XP Profi (nemam Linux) by mohl byt za 5–8s.
Na MB by mohlo byt 2GB flash pameti pro BIOS+OS, 256MB PEROM pameti pro konfiguraci OS + „neco“ a 8GB SDRAMky a to vse rizene a pripojene k radici MB stejne jako je BIOS ve FLASH/PEROM pameti do 4MB velikosti typu 29×320/28×320 (4MB binarky), 29×640/28×640 (8MB binarky). Zkratka systemove zrychlit nabehm a pouzitelnost PC po zapnuti.
To by byla parada.
Samozrejme nemam na mysli neco jak netbook, kde SD karty/ USB flesky/ interni ic flash jsou napojene na radic periferii a teprve pak je to tahane do RAMky atd…, melo by to byt napojene na interni sbernici primo jako flash ic s BIOSEM kvuli podobne dobe nabehu jako nabiha BIOS po zapnuti. Melo by to byt tak, ze se obsah flash+PEROM+EEPROM (ano treba i 93c46/24c08 pro konfiguraci ETH jako je MAC, autonego atd pro kazdy LAN procak typu RealTec apod., v podstate u kazdeho PC/switche/sitovky je LAN procak+EEPROM) se vybavej do RAMky a tam zustava obsah po dobu zapnuti PC. Takovej RAMdisk, je to rychlejsi pricemz zmena dat se ulozi jak do RAM, tak nasledne bez prodleni a zpozdeni v zapisech i do FLASH/PEROM/EEPROM, takze pri vypadku energie se nesmazne cfg, protoze byl o par milisekund po zapsani do RAM zapsan i do flash ic.

Já

deletuji, tedy jsem!

Deafboy

Paradny clanok… optimalizovat, optimalizovat, optimalizovat !

Deafboy

Sry za doublepost, ale este ma napada jeden postreh urceny java vyznavacom.
Akekolvek riesenie postavene na jave je najbohapustejsie plytvanie ake si clovek moze predstavit. Prave java robi z dnesnych PC kalkulacky. V praci pouzivam niekolko programov napisanych prave v jave. Cim novsi, tym dlhsie startuje, pomalsie reaguje a viac mrzne. Kym vsetko nastartujem, cakam niekedy aj 20 minut.

Kit

Javu také nemám v oblibě, zmínil jsem ji jen jako odpověď na potřebu jednotného prostředku na klientovi i serveru.
Myslím si, že Java je ve své podstatě rychlá, ale velké množství nabalených knihoven na každou aplikaci z ní dělá líného molocha. Také překlad do nativního kódu procesoru nemusí být ve všech pípadech výhodnější, než jeho přímá interpretace. Nespornou výhodou je, že je multiplatformní.
S velkou oblibou však používám konzolové nástroje, které jsou velmi rychlé i na velkých objemech dat. A to bez indexování!
Byly tady zmíněny molochy typu .NET a Java. Za ty miniaturní (a rychlé) bych uvedl třeba Lisp a Forth. Používá je ještě někdo? Osobně si nejčastěji vystačím se skripty v Bashi, ale na některé úlohy se nehodí.

Karel

Java je velmi univerzální jazyk. Dají se s ním dělat neuvěřitelné prasárny a protože vás moc nehlídá, dá se s tím udělat úplně mrtvá aplikace. Populární chyba je začít ve vlákně, které se stará o grafické rozhraní, provádět výpočty a nejlépe databázové dotazy. Člověk pak klikne a ono je to celé mrtvé, přestane se překreslovat obrazovka a člověk netuší co se děje. Nebo to alespoň začne být takové líné a pohybovat posuvníkem vypadá jak vyvolávání filmu. Další populární věc je přibalit ke svému programu hromadu cizích knihoven na všechno možné. A navíc java je objektová, takže všechno musí být objekt. Pokud sebejednodušší aplikace nesestává ze stovek tříd a nevytváří statisíce instancí, tak to není správná Java! No a pak člověk najednou narazí na aplikaci, jejíž autor nebyl nebil a kolikrát ani nepozná, že to je Java. Jako zajímavou inspiraci doporučuji hru Runescape. Je to javovský aplet, běží to full screen, detailní 3D akcelerovaná grafika a hýbe se to velmi slušně i na 4 roky starém PC. Pak se člověk skutečně ptá, kde autor nějaké drobné utility udělal chybu, když startuje půl minuty, sežere 64MB paměti a prakticky se s tím nedá pracovat, protože odezva na kliknutí je v sekundách… A přitom je to taky ta java…

em

Já používám javové aplikace na destkopu a jsem spokojený. On i blbý OpenOffice nebo IE, Mozila a Opera startují dost dlouho. V práci máme několik javových aplikací, a jsou OK. A třeba NetBeans je dost rychlé na to, co vše dělá v pozadí – syntaxe, verzování atd. Jen je potřeba vypnout moduly, které člověk nepoužívá.

pas

Přesně tak. Ještě lepší (horší? :)) příklad je Flash. Není výjimkou, že pár animovaných bannerů sežere 100 % procesoru. A pak člověk narazí na nějakou svižnou složitou vizualizaci nebo hru a šokovaně kliká pravým tlačítkem, jestli je to vážně Flash.
Je nějaká technologie, která vám dovolí psát jen kvalitní kód?

Kit

Programovat jako čuně je možné v jakémkoli jazyku. Viděl jsem v Pythonu napsanou aplikaci na 90 řádcích. Když jsem se autora zeptal, co to má dělat, podle jeho odpovědi jsem napsal totéž v Perlu na 65 znacích. Čitelněji. Určitě by to i v tom Pythonu šlo napsat lépe.

Bambus Maximus

Pche, to já jednou napsal takovou animaci v javascriptu, že z thoho každýmu zatuhnul prohlížeč na půl hodiny!

XDpz

:D ha

Tisnovsky

Forth se jeste pouziva, ale uz to samozrejme neni tak popularni jazyk jako v osmdesatych letech, kdy v nem spousta lidi (i v CSSR – tady to dokonce jednu dobu byl „oficialni“ nazor) videla budoucnost. Je to trosku skoda, protoze je v tom jazyku spousta zajimavych myslenek.
Java skutecne sama o sobe neni pomala, staci si udelat benchmarky pro ruzne typy uloh, jen se v ni proste da snadno „lepit“ kod s pouzitim mnoha dalsich knihoven a frameworku, jak pisete.

I/O

Jistě. Existují množiny problémů, pro něž ty jazyky vyhovují prostě nejlépe – ikdyž se dají použít i jiné nástroje. Lisp všude, kde se dá s výhodou použít jeho homoikoničnost, umožňující metaprogramování, Forth všude, kde se zúročí jeho nenáročnost a jednoduchost – dnes obvykle v embedded aplikacích; mít možnost pomocí JTAGu krokovat přímo laděné zařízení je sice skvělé, ale jakmile se v tom začnou vyskytovat přerušení a je třeba ladit z hlediska daného mikrořadiče asynchronní události, zas tak moc to nepomůže – zde je Forth pomocníkem k nezaplacení. Navíc při použití Forthu není třeba dané zařízení odpojit a rozdělat, co víc – v podstatě je možné ladit nebo upgradovat ho třeba přes Internet nebo přes rádio, což se dá s úspěchem aplikovat třeba u kosmických sond ( http://forth.gsfc.nasa.gov/ ) – zde hraje roli i to, že zásobníkové procesory jsou velmi jednoduché a při své jednoduchosti velmi rychlé a energeticky nenáročné, což zvyšuje jejich odolnost v náročných podmínkách a eliminuje pravděpodobnost výskytu nějaké nepodchycené chyby.
Takže ano – používají se hojně. Stejně jako se dodnes hojně používá Fortran. Jen to není zrovna v těch nejširších kruzích – přeci jen se jedná o nástroje využívané lidmi, jejichž IQ přesahuje průměr současné normální IT komunity, matlající webovky v Javě nebo .NETu. Ale oč menší je koncentrace výskytu, o to větší je obvykle důležitost problémů, jež se v těchto jazycích řeší. Když spadne server telefonního operátora, je to malér. Ale když spadne řídící soft meziplanetární sondy, je to průser za miliardy dolarů. :-)
BTW – jen taková zajímavost – asi před hodinou jsem řešil jakýsi problém s jedním starším kolegou z Ruska, autorem programu na rozpoznávání typů a energií částic ionizujícího záření podle stop jimi zanechaných v rastrových polovodičových detektorech. Dodnes programuje ve FORTRANu 66, celý program má vždycky v jednom souboru a ten program neobsahuje jedinou řádku komentáře (nepočítám-li vykomentovávání částí kódu a komentáře typu C———–). K přehlednosti nepřispívá ani fakt, že implicitní typování používá, kde je to jen možné, a o existenci logických IFů mu za 50 let asi nikdo neřekl. Jistě to není nic následováníhodného, ale k údivu mne přivádí fakt, že při svém věku se ve svých tisíciřádkových programech bez nejmenších problémů orientuje. Na tvrzení „pořádek je pro blbce, inteligenta chaos nerozhází“ asi fakt něco je. :-)

Kit

V sondách bych nečekal zrovna Forth. No dobrá, však to není špatný jazyk. A je rychlý. Jen mě to překvapilo. Co jiného bych však mohl na sondě čekat?
S Fortranem jsem kdysi začínal. Hned po výukovém Pascalu, což byla tenkrát ideální kombinace. Myslet v Pascalu a programy psát ve Fortranu.
Kolega z Ruska asi ještě nezkusil Matlab nebo Octave. V mnohých případech mohou být efektivnější, než programy ve Fortranu. Přitom je práce s nimi mnohem jednodušší.

I/O

Co jiného bych však mohl na sondě čekat? – ColorForth – to až nám sem jednou spadne nějaká sonda mimozemského původu. :-)

S tím ruským kolegou – to je relativní. Ruský kolega je mnohem produktivnější ve svém F66 než jeho mladí kolegové v Matlabu. Navíc – přeložený fortranský program přeci jen běží několikrát rychleji, než jeho analogie v Matlabu. Což je u problémů, na něž se Fortran dodnes nasazuje především, argument dosti silný. ;-)

Tisnovsky

Pokud ten rusky kolega dela v F66 uz tolik let, tak bych se nedivil, kdyby v nem byl opravdu hodne rychlej – muze mit v hlave „seznam“ vsech algoritmu, ktere kdy vytvoril, takze je muze znovupouzit a pro vypocty Fortran vubec neni spatny jazyk (dokonce i aritmeticky IF tam vyuzije lepe nez „booleovsky“).
Me by zajimal vypis alespon casti jeho programu, nekteri lidi maji totiz takovy „pravopis“, ze se jejich programy daji poznat jen pri nahlednuti do zdrojaku.

Radovan

Řekl bych že tenhle kolega je skutečný Programátor, dokonale ovládající problematiku kterou zpracovává i ten „svůj“ jazyk, ve kterém to dělá. A takové imlicitní typování má i svoje výhody, na první pohled je vidět jestli je proměnná int nebo float ;-)

„God is real, unless declared integer.“

Tisnovsky

To ovsem ani tak nebyla chyba programu nebo programatora (ten naseka chyby vzdycky, je to jen clovek) ale toho, ze se ta aplikace bud neotestovala nebo otestovala spatne. I kdyz tady jde pravdepodobne skutecne o legendu, ktera pekne vystihuje to, ze v syntaxi Fortranu se puvodne ignorovaly mezery a nemusely deklarovat promenne, takze se DO 17 I = 1.10 chapalo jako prirazeni do nove promenne DO17I.
Priklad spatneho pristupu k testovani a celkovemu inzeniryngu – sonda, ktera hodne tvrde „pristala“ na Marsu kvuli tomu, ze se dva tymy nedomluvily na tom, v jakych jednotkach si mezi sebou budou predavat udaje. To se neda svest na programovaci jazyk nebo programatory :-)

em

Predstavte si, že já jsem vůbec neměl počítač! Párkrát jsem viděl PMD nebo Sinclaira, na IQko jsem si i sáhnul. Na škole jsem měl Fortran a dost primitivní Basic na ADT.
A předtím? Představte si, že počítače NEBYLY VUBEC !

Substance242

Dobrý článok, pripomína mi jeden môj, napísaný pod vplyvom frustrácie z toho, ako je všetko stále zložitejšie, keď niečo nefunguje tak nikto okrem „mne to ide“ nevie poradiť, na nič už sa nedá spoľahnúť a kto sa vlastne komu prosil aby vývoj išiel týmto blbým smerom. Je to všetko na prd, chcem revolúciu!

snehuliak

posli linku na ten clanok…

Já
2. 8. 2010 20:23 smazal Petr Krčmář, důvod: Pubertální výlev provokativního typu.
Já

ještě, že má Martínek takové věrné nohsledy!

mmad

To mi připomíná → LiveCD, terminál a „ssh -D 88 -l ghost -p 88 -X 127.0.0.1“
Na Kerberosu se zpravidla taky nehlídá, avšak prznit HTTP protokol taháním X-session je drzost nejvyšší :).

bp

…za dobu, než mi na současném počítači nastartuje Word nebo textový editor OpenOffice, jsem už na starém dobrém XT (4,77 MHz) měl z diskety spuštěnou T602 a vesele jsem psal. ;-)

r0b0t

srovnáváte nesrovnatelné ;-)

Twiguard

Než byste na svém starém dobrém XT spustil z diskety T602, já bych měl už po obnově systému v Notepad++ nebo gEditu napsanou hlavičku a importy. ;-)

macan

Dal bych tomuto clanku jednicku, zaslouzi si ji :-)

Já

Text názoru je povinný

void

Zcela nesouhlasím s tím, že výkon není potřeba. A co třeba náročné renderování 3D scén s osvětlením, výpočty radiozity, stínů? Co například tvorba pokročilých 3D modelů v CAD/CAM aplikacích? Kde je využití pro výpočty s obrazem, animace, střih videa? Medicína a aplikace neurovýpočtů? To jsou všechno oblasti, kde je třeba velký výkon a rozhodně to není činnost, jak autor uvádí, bleskurychle. Některé výpočty mohou trvat třba celý den i déle. Výkon je potřeba, jen je ho třeba správně využít.

Kit

Renderování 3D scén mimo videokartu není zrovna typické využití počítače. Nelineární střih videa také nedělám každý den. Ano, pro tyto účely je výkon nutný. Pokud by mě to mělo živit, zkusil bych k navýšení výkonu CUDA, HW střižnu nebo clustering. Ale cestou zvyšování frekvence CPU bych určitě nešel.
V článku bylo spíše kritizováno, že mezi vlastní aplikací a HW počítače bývá příliš mnoho mezivrstev. Tyto mezivrstvy jsou sice zajímavé při vytváření aplikace, ale samy o sobě odebírají značnou část prostředků. Pokud bychom tyto mezivrstvy nepoužívali, nepotřebovali bychom takový výkon počítače.

BazMyslik

No, ja pouzivam stale textovy editor MAT 3.0, jenze s prichodem Intel Core 2 Duo koncim :-( Na techto procesorech jiz pustit nejde – hlasi: NTVDM CPU obsahuje neplatnou instrukci CS:0000 OP:f0 37 05 0c
Neumim, ale asi by slo prekompilovat mat.exe aby to chodilo. Nevite o nekom? robin@free.cz

Mintaka

Jo MAT byl/je pěkný texťák. Kdysi na Invexu jsem řešil pár věcí s jeho autory, ale to už je hodně dávno.
Až někdo udělá javacriptový editor MS DOSu tak si ho půjde spustit tam. Ani bych se nedivil, kdyby něco takového už existovalo :-)


S tím MATem by snad šlo:
* spouštět ho v emulátoru
* ve virtuálu
* disassemblovat a opravit
* …

Martin

Tak napiste do Cybexu, jeden z autoru tam jeste porad je, mozna by Vam poradil

Sigi

Ad. prekladace v predposlednim odstavci: neni soucasti Google Wave prave takovy prekladace Java (jeji podmnozina?) ⇒ HTML + JS ?

Kasha Fataal

S tímhle článkem zrovna moc nesouhlasím. Já osobně používám počítač ke skládání hudby a filmové postprodukci. Na počítačích v 80. letech (Např. Atari) bylo sice pár takových programů, ale co se týče kvality zpracování zvuku, byli naprosto nepoužitelné. Čím výkonnější počítač, tím složitější programy (využívající např. Fyzickou syntézu, Složitější algorytmy, nebo Multisampling), a tím také věrnější a kvalitnější zvuk a tím pádem lepší a použitelnější výsledek. Čím výkonnější mám počítač, tím větší mám (skutečně využitelné) možnosti. O zpracování videa ani nemluvím, to tenkrát na běžném osobním počítači nešlo vůbec. Takže ano, pokud se tedto článek týká psaní dokumentů a databází, jistě na tom něco bude, ale zdaleka to neplatí na všechny obory využití počítače.

Martin

Je vidět, že jste hudebník :) Ale slovo „Algorytmus“ není odvozeno od slova „rytmus“ – píše se „algoritmus“ ;)

Tom

Az bude sw dostatecne dobry a hw dostatecne vykonny a PC konecne zvladne porozumet mluvenemu slovu a tvorit vety a spravne prekladat v realnem case dosadime PC misto „sekretarky“ :) -zatim je na to moc malo vykonne

retrt

tak…grafici, střihači, 3déčkaři a další dokážou furt i ty nejvýkonější mašiny zavařit…..čím větší možnosti, tím větší nároky…

jarop

Ano, ale aspoň je tam progresia výsledkov vidieť.
A nie ako napr. v editovaní textu – napíšeme texteditorík v intepretri DHTML, ktorý sám beží nad X vrstvami API a Y vrstvami OS. Bude sa to vliecť ako starý reumatik pomaly na superpočítači, ale čo. Najsamprv dôležité je, že to bude univerzálne spustiteľné.
Za univerzálnosť spustenia programov na akejkoľvek platforme sa často platí príliš veľká daň v podobe straty výkonu (a často aj straty funkčnosti). Konkrétne u web aplikácií – to je výsledok používania technologie úplne nevhodnej na tento účel (celý DHTML a HTTP protokol).
Vrchol biedy je, ak sa kaskádne budujú interpretre, virtuálne počítače a runtime prostredia jeden nad druhým.

tupphantomscz

dnesni doba neni limitovana hardware ale software!k novym pocitacovym sestavam se dodava moderni software ktery nedokaze potencial dobove techniky vyuzit naplno.dnesni technologie je tak na vysoke urovni ze na trhu nachazime spise polotovary z existujicich moznosti sveta.kdyby vyrobci chteli,mohli by obrovskym skokem pekrocit veskerou nyni prodavanou pocitacovou vybavu na trhu a nejednalo by se o zadne prototypy.ale vyuzije dnesni clovek takovou vec?odpoved zni ne!nikdo si ani zatim nedokaze predstavit jaky software by ho pohanel aby mu byl s prinejmensim roven a dostatecne prizpusobujici jeho potencialu.software dokaze udelat se zarizenim divy a stary pomaly pocitac beha rychleji s modernim programatorskym prostredim o dost lepe nez ve sve dobe vubec mohl fungovat.potom muzou pribyt i nove funkce aniz byste cokoliv noveho Upgradovali a menili stare soucastky za nove.naopak novy pocitacovy procesor nedokaze svuj vykon pouzit naplno a v praxi jej promenit k predpokladanym pozadavkum.myslim si ze zatimco drive byl programator limitovan hardwarem a musel se prizpusobit omezenim svych predstav vysledneho soft produktu,nyni nemusi vubec brat v uvahu nejake vykonove nedostatky kvuli nimz nebyly urcite aplikacni instrukce mozne zrealizovat v praxi.dnes se v tomto odvetvi sleduje trzni nabidka a poptavka
ktere se snazi prumysl vyhovet pricemz si vystacit s kapitalem jez je k dispozici.skoda jen ze vse se zatim spise toci kolem lepsich textur a rozsahlejsich scen v grafickem ci audio prostredku.vsechen vykon je pak utopen v techto zalezitostech a jen to lepe vypada atd.nic prevratne necekaneho se nekona a jde vlastne o to same co tu uz bylo.staci jen vytvorit pozadovany program a technika bude delat cokoliv a jakkoliv nas napadne.jen ne a neprijit neco co tu jeste nebylo a bude teprv prevratnou zmenou kdy nasadi novou pricku prinasejici dalsi zatim nepredstavitelne funkce nekoncicich moznosti.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.