Jak já to vidím tak se nám to pomalu v Microsoft/Nokia/Windows, Google/Android/ChromeOS, Apple začíná rýsovat budoucnost megakorporací, které budou kecat do všeho od toustovače přes pracovní noťas po domáci server, kterej bude řídit i zámky na dveřích.
Google mi z těch třech přijde zatím nejsympatičtější (Jo, saje z vás údaje, ale aspoň všichni víme co s nimi dělá.) a pokud by Google vymyslel jak pod svoje křídla dostat appky od Adobe ... (Koneckonců od pronájmu licence k plně cloudovému řešení už je to jen pár kroků, viď Adobe.)
Ale no tak. Myslíte, že to má zapotřebí?
Že mu ke štěstí nestačí nejpersonalizovanější reklamní systém na světě, který díky Google glass možná přeskočí i do offlinu. Nestačí mu, že nám bude moc nabízet přesně to po čem v skrytu toužíme, aniž bychom to i snad vědomě věděli, že se díky jeho datům vyvíjí marketing takovým tempem jako nikdy? Myslím, že bohatě.
Suhlasim.
Neverim, ze Google predava informacie o uzivateloch reklamnym spolocnostiam. To by sa rychlo presiaklo a bol by z toho neuveritelny pruser. To by neriskovali.
Laskavo ziadam kazdeho kto teraz zatuzi zakricat, ze Google velmi ochotne chodi bonzovat NSA, tak nech sa zdrzi komentovania, pretoze Google nechodi bonzovat NSA. NSA posiela do Googlu ziadosti a Google vyhovie iba niekolkym.
Obchodny model Google je cely zalozeny na spionazi, vsetky sluzby poskytuju zadarmo preco asi? ono to zadarmo nie je ani nahodou. Hrabu sa vam v sukromi a predavaju ho dalej, kto ma informacie ako prvy ten ma konkurencnu vyhodu - preto sa google tak rychlo rozrastol. Sluzby ako Google Search, Gmail, Chrome, Google Maps, Android, Google Docs, Google Drive (dokonca aj Ad-sense) to vsetko je urcene na nase sledovanie. snad si viete aj sami domysliet ako sa bude zneuzivat Google Glass. Urcite si pamatate na 90te roky ked to vsetko zacinalo - spionazne sluzby ako Gator.com / Claria pomocou roznych freeware programov (najznamejsi bol GetRight) zbierali o uzivateloch data a predavali ich dalej liekom proti nim boli programy ako ad-aware a spybot. Google dnes tento business model vylepsil a doviedol ho k dokonalosti. Premna osobne je Google najvacsie zlo IT sveta - vacsie ako MS a Apple dokopy, aj ked nerobim si iluzie ze oni tie data o uzivateloch nezneuzivaju. Kazdy ich zneuziva.
Google Chrome... Native Client, který vývojářům umožňuje vedle obvyklých webových technologií... požívat ve svých aplikacích také nativní kód napsaný v jazyce C++ nebo v klasickém C - OMG. Jako by nestačila ta spousta děr v prohlížečích a dalším C/C++ SW. Ještě necháme dělat stejné příšernosti vývojáře webových aplikací, aby byly děravé nejen browsery, ale i webové aplikace.
Dnešní webové technologie jsou jedna velká tragédie. Otevřete pár tabů v browseru, sežere to giga paměti (po pár hodinách díky resource leaks i výrazně víc), a ta spousta na pozadí běžících skriptů vám div nezavaří CPU. K tomu se webové aplikace ovládají výrazně hůř než ty desktopové, a když mají vypadat alespoň trochu slušně, tak se i dost obtížně píšou (HTML na to prostě není stavěné).
Ale musí se nechat, že evangelisté webových technologií přišli na to, jak dnešní nadupané počítače vytížit věcmi, které bez problémů zvládaly desktopy s Windows XP a 128MB RAM :)
Webové technologie byly, jsou a budou tragédie a to už z podstaty věci, neboť potenciál HTML a lehkého skriptovacího jazyka JS je vyčerpán.
Například ani po 18-ti letech existence webových technologií dosud neexistuje plnohodnotný emailový klient, dosud jim kdykoliv dá na p*del průměrný desktopový.
Situace se nezlepší ani do budoucna, pokud se nestane nějaký zázrak a neprovede se upgrade na něco solidnějšího než HTML a JS.
A mě zrovna připadá Native Client jako velmi dobrý krok. Je to podmnožina C/C++ a není s tím možno dělat všechno a sockety mi tam určitě budou chybět.
Ale pokud se podíváme na Windows, tak tam se těží z binární kompatibility (ne 100%) a to Linuxu vyloženě chybí. Pokud tedy Google přišel s SDK, které má interface k javascriptu a bude zajištěna přenostitelnost a relativní bezpečnost (je strojově prověřen výsledný binární kód a podezřelé části vedou k odmítnutí celku) takto pouštěných aplikací, tak je to krok kupředu.
Ještě čekám na podporu dalších jazyků a nejsem si jist, jak se toto bude stavět k externím knihovnám, protože se obávám, že budou muset také projít validací - tj. bude je možno asi jedině přímo zakompilováním do kódu.
Když se podíváme na Microsoft, tak tam lze pozorovat také určité vystřízlivění z velkého nadšení k skriptovacím jazykům (typu C#) a návrat k C/C++ - protože jen s kompilací do strojového kódu lze dosáhnout maximálního výkonu.
Jde o provokaci, nebo to opravdu myslíte vážně?
- C# je skriptovací jazyk?
- návrat MS ke kompilaci do strojového kódu?
Google může jen těžko zajistit binární kompatibilitu, když s tímto paskvilem míří na x86 i ARM. Binární kód pluginů a rozšíření je všude opouštěn, protože je jeho běh špatně kontrolovatelný a způsobuje nestabilitu. Tady se k němu budeme zjevně s velkou slávou vracet. A na schopnosti Googlu kontrolovat kvalitu aplikací ukazuje již jeho úspěšnost při filtraci malware na Google Play...
A co se týče celkového nápadu s dalším desktopovým prostředím, integrovaným do prohlížeče, před lety jsme nadávali Mozille, že balí do stejnojmenného prohlížeče i mailového klienta a spoustu dalšího balastu. A teď přijde Google ještě s větším zvěrstvem, přibalí nám k tomu pro jistotu i kancelářský balík. Mám bohužel pocit, že Google má sílu to prosadit.
O tom se přít nehodlám, ale to označení má dehonestující charakter a víceméně jím autor původního příspěvku nakreslil čáru mezi C++ a C#, přičemž v podstatě položil rovnítko mezi C# a například shell skripty. A to pomíjím takové detaily, jako je to, že aktuální překladač MS C++ generuje implicitně stejný kód, jako C#, tedy spravovaný.
Naprosto abstrahujete od tématu, původní autor zcela zjevně neměl na mysli sémantiku jazyka, jako spíše jeho standardní implementaci. Ta je u C# v podstatě jediná a je od obecně zaužívané představy skriptovacího jazyka dost daleko.
Osobně nemám nejmenší chuť pouštět se do akademické diskuze ohledně rozdělení programovacích jazyků.
Mate pravdu. Ve Windows se moc neskriptuje, takze narknuti C# z toho, ze je to skriptovaci jazyk, neni uplne trefne. Spis je to jazyk na jednoduche GUI aplikace na ktere nama cenu plytvat casem nekoho kdo umi c++.
Dokud C# nezacne pouzivat sam Microsoft na veci jako je Office, je to jen moc hezka hracka kterou mozna za par let pokazi, nebo nahradi necim jinym.
Bohužel C++ má řadu nevýhod. Můžete to vidět na té obrovskéo spoustě bezpečnostních problémů, které dnešní SW průmysl má.
MS samozřejmě interně C# používá. A přepisovat více než 30M řádků fungujícího zdrojáku MS Office jiného jazyka jen aby vám to udělalo radost? To asi není pro MS dostatečná motivace :)
Já proti skriptovacím jazykům nic nemám, ostatně veětšina kódu, co jsem kdy napsal, je v Perlu, na který nedám dopustit. Ale označení C# jako skriptovacího jazyka mě skutečně podráždilo. Ke skriptovacím jazykům obecně patří slabá typová kontrola a velké množství implicitních konverzí, což tedy C# rozhodně nesplňuje.
Upřímně řečeno netuším, co má C# společného s tvorbou GUI. Kromě toho, že jde o jeden z desítek jazyků, v němž se GUI dá programovat. C# vychází syntakticky a principiálně z C++, podobně jako Java. A pocit programátorů v C++, že jsou "něco lepšího" než javisti či "síšarpisti" jsem nikdy nechápal. Stejně jsme všichni jen pojídači koláčů.
Pokud vím, tak se za skriptovací jazyk označuje jazyk, u kterého se zdroják interpretuje vždycky přímo, bez ukládání nějakého mezi kódu.
Problém je ovšem v tom, že ten termín je už pěkně fousatý a technologie překladačů se vyvíjí a vyvíjí a na nějaké škatulky neberou ohled.
Každopádně C# není a nikdy nebyl skriptovací jazyk, protože, stejně jako java, se překládá do speciálního kódu a teprve ten se interpretuje.
Doplním. C# a ostatní .NET jazyky se převádějí do Common Intermediate Language, což je řekněme obdoba Java bytecode. Následné provádění kódu se dělá buď za pomoci JIT překladu, nebo převodem CIL "bytecode" na binárku. Ta druhá možnost je výrazně častější, protože při instalaci CIL Assembly se v naprosté většině případů vygeneruje nativní image.
Nevím o tom, že by .NET vůbec kdy fungoval jako interpreter CIL kódu. Nakonec MS má s JIT překladem spoustu zkušeností; jeho verze Java Runtime Environment (předpříchodem .NETu) byla díky tomu rychlejší než ta od Sunu.
C# - asi jsem se nevyjádřil dost přesně, ale kompiluje se tam jen do mezikódu, ten se potom interpretuje - což je určitě pomalejší než nativní kód procesoru.
MS - sorry, na zdroj si nevzpomenu, ale někde jsem četl, že po Vistách, které byly v C# se v W7 zase kód přepsal do C++ (ne 100%, ale že se ten poměr zase posunul směrem k C++).
Pokud má Google v rukou kompilátor, tak může celkem všechno - včetně výstupu dvou binárek pro odlišné architektury a může také zajistit, že na klienta půjde jen ta správná.
"protože je běh špatně kontrolovatelný" - ale toto je jen technologgický problém a google si myslí, že se mu jej podařilo překonat.
Něco jiného je udělat kompilátor, který zkompiluje obecný C/C++ kód a ten bude vždy pojede "správně a nezávadně" (a toto zřejmě NaCl neumí) a něco jiného je říci, že "tato konstrukce není povolena - napiště to jinak (odkaz na vzor)". Já neříkám, že bude možné zkompilovat tam linuxový kernel - nepůjde. Bude to podmnožina C/C++ a bude těžit z rychlosti.
Google bude mít k dispozici i svůj operační systém (Linux based), takže může zajistit dostatečnou izolaci prostředí běžící aplikace (když to jde u VPS, tak to půjde i v menším měřítku). Kompilátor pravděpodobně binárku podepíše, takže s ní nepůjde dále manipulovat a možná ten podepisovací kompilátor poběží jen na serverech googlu, aby se jim do toho někdo nenaboural (spekulace).
Mezikód nemusí být nutně pomalejší, než nativní kód. Mezikód je u většiny VM kompilován do nativního za běhu (JIT), čímž lze docílit mnohem lepší optimalizace na cílové CPU, než když zkompilujete klasickou aplikaci tak, aby běžela na většině dostupného HW.
U běžných aplikací je to ve výsledku stejně jedno, někdy je rychlejší to, někdy ono. Kde nativní kód poráží spravovaný na celé čáře, jsou paměťové nároky (bavíme se o korektně napsaných aplikacích).
Ohledně C# a interpretované režimu jsem psal výše, že takhle to v .NETu nejspíš nikdy nefungovalo, a určitě to tak nefunguje dnes.
Ad bude to podmnožina C/C++ a bude těžit z rychlosti - jaká podmnožina? Pokud jsem správně pochopil co jsem vygooglil, tak NaCl prostě zkompiluje jakýkoliv C/C++ zdroják pro cílovou architekturu, a spustí výsledek s nějakým sandboxingem. Běžící kód může dělat veškeré příšernosti včetně pointerové aritmetiky, OpenGL ES 2.0, sandboxovaného local file storage, full screen mode a mouse capture (vyjma toho prvního vše pomocí knihoven browseru Chrome).
Proč mě to děsí? Zkuste si v libovolném recentním browseru otevřít pár tabů Youtube nebo Facebooku, tedy velikých a známých webů. Pak zkuste sledovat, kolik paměti a CPU vám browser sežere. Zkuste to sledovat po 24 nebo 48 hodinách - spotřeba paměti vás asi udiví. Ty JavaScripty mají resource leaks, a browsery mimochodem často také. Některé příčiny resource leaks najdete tady:
http://www.ibm.com/developerworks/library/wa-memleak/
Takhle dneska vypadají velké a známé weby. A určitě jsem viděl i vyloženě špatné weby, které mají daleko větší resource leaks, zacyklené skripty nebo absurdně vytěžují CPU.
Teď si představte, že lidem, kteří nejsou schopní napsat slušně ani web v JS, dáte do ruky C/C++ s pointerovou aritmetikou, nejspíš i threadingem (aby mohli ten CPU vytížit ještě lépe), přístupem k OpenGL/WebGL (které při troše snahy dokáže provést DOS, zhavarovat systém, přečíst obsah obrazovky, vytvořit falešné security dialogy apod.), a zavřete to do sandboxu, který se pochopitelně dříve či později ukáže jako děravý. Aplikace napsané pro NaCl budou děravé stejně jako ty napsané v C/C++, vytěžovat CPU jako ty v JavaScriptu a Flashi, a jako bonus budeme mít spoustu nových bezpečnostních zranitelností. A co nám to celé má přinést? Věci které desktopy umí už minimálně 10 let.
Tohle je něco, s čím musím souhlasit. Naposledy včera jsem musel restartovat prohlížeč kvůli nemocnýmu JavaScriptu. Jediný, co bylo v prohlížeči otevřený, byl GMail :(
U Javascriptu je jediná možná výhoda při jeho použití, parsování na straně klienta. Požadavek se zakóduje jako číslo a podle něho se pak na serveru najde v tabulce akce, ketrá se má udělat. Do toho čísla se těžko propašuje třeba nějaký SQL příkaz při pokusu o SQL injection. Ale má to několik omezení:
- Pokud programátor webu není prase, stejný postup může zvolit i na straně serveru a předávat požadavky mezi modulama PHP na serveru.
- Ne všechno jde předat jako číslo (i když věřím, že šílenec, který pošle tabulku zákazníků v JavaScriptu do prohlížeče, aby se vybralo jméno uživatele a dostal zpátky číslo doopravdy žije), takže stejně se musí vstup na serveru kontrolovat.
- JavaScript na klientovi nemusí fungovat a v tom případě je web nepoužitelný.
Takže bych byl pro ty JavaScripty a podobný nesmysly omezit. Ať si to běhá na serveru a vrací do prohlížeče popis, co má zobrazit. Omezený výkon serveru by ty pazgřivce naučil, jak se má efektivně programovat bez zacyklení a podobných zrůdností...
„Tohle je něco, s čím musím souhlasit. Naposledy včera jsem musel restartovat prohlížeč kvůli nemocnýmu JavaScriptu. Jediný, co bylo v prohlížeči otevřený, byl GMail :(“
Gmail, alespoň dle mého názoru, opravdu není příklad, na základě kterého by šlo zavrhnout webové technologie. Jak nabalování stále nových funkcí přináší chaos do uživatelského rozhraní, přináší ho i do zdrojového kódu. To se prostě musí projevit.
Třeba Google Keep tzv. na plochu je IMHO velmi sympatická aplikace. Tím samozřejmě neříkám, že webové aplikace by namísto těch nativních měly být nějakým ternem. Ale stejně jako máte nativní aplikace, které napsalo nějaké s prominutím prase, tak máte i webové aplikace vznikající ve chlívku ;-)