Namiesto vymyslania blbosti a dohadovania sa mohli javascript nahradit Pythonom. Ten ma vsetko co potrebovali a navyse jednotnu/neroztriestenu implementaciu, ktora sa lahko integruje do browserov. Navyse ma bytecode co by mozno vyhovovalo komercnym firmam. Som z vyvoja Webu a jeho technologii dost sklamany. :(
Myslim, ze toto je najrozumnejsi nazor, co som na roote cital za poslednych niekolko dni. Uplne suhlasim, hoci python vobec neviem. Ale urcite to nebude horsie ako JS.
no ani nie ;-)
uvedom si, ze hoci je (podla mna) Python vyborny a cisty programovaci jazyk,
tak sa to s prichodom P3000 (hnusi sa mi nazvat dalsiu verziu Python 3000, lebo nema s Pythonom NIC spolocneho.) pominie, stary-dobry Python zakrpatie a vyhynie.
Web (imho) potrebuje nejaky dynamicky programovaci jazyk, ktory sa NEBUDE menit, ako sa jednemu debilovi zachce. Treba tu nieco pekne, KOMPATIBILNE a jednoduche. Tym by bol Python, ale teraz take nieco neexistuje.
Momentalne by som mal 2 riesenia:
1) pouzival by sa Python 2.5, resp. by sa odsiepil a nezavisle vyvijal.
2) Java. Ano, Java :-)
samozrejme toto vsetko po boku Javascriptu.
mozno by sa zislo zasunut, ako moduly do browsrov par interpretov roznych jazykov, aby si vyvijar mohol vybrat.
a poucenie na zaver:
Zbytocne velka komunita, ked sa nezhodne a neukaja potreby developera :-)
prosim ta co si take v pyhone napisal ked tak nadavas na python 3.0, ktory sa bude pouzivat mozno az za 2-3 roky ?
velka vyhoda pythonu je prave v jeho velkej komunite, v ktorej je vela odbornikov ktory su aj ochotny pomahat, na rozdiel od tych v komunite Ruby, napriklad
ja som nic take v Pythone nenapisal. a co si Ty take v Pythone napisal?
myslim, ze clovek nemusi byt genius, staci mu len sedliacky rozum, aby prisiel na to, ze robit stale nekompatibilne veci je to najhorsie, co sa da...
rozmyslal si niekedy, preco je Python taky pomaly a neoptimalizovany? vies co? ja Ti to poviem: je to tym, ze ked koderi Pythonu konecne nakodili nieco, tak to Ten Nemenovany **** vyhlasi za deprecatnute, alebo si rovno zmysli, ze to dalsia verzia Pythonu obsahovat nebude a programatori mozu kodit/pracne prepisovat svoje kody odznova...
Co myslis, preco Python komunitu tolko ludi opustilo? Preco upustil od Pythonu Google?
A povedz mi taktiez: keby sa vytvarala stale nova a nova NEKOMPATIBILNA verzia napr. Ccka, C++su, alebo Javy, tak boli by to take popularne jazyky, ake su teraz?
detto napr. bash a miliony dalsich prokladov, ktore nebudem pisal, lebo by som preplnil databazu na rootovi :-).
Taktiez si vsimni, ze Perl tiez chcel spravit nekompatibilnu novu verziu - a ako to skoncilo... Do zahuby sa podobnou cestou ruti aj Python... vdaka samotnemu autorovi...
PS: mohol by si prosim Ta napisal aj svoje meno/nick? nerad pisem s niekym, kto sa hambi za svoju identitu(alebo len zabudol vyplnit nick;-) )...
No neviem, ale sedliacky rozum ti nepomaha.
Deprecated veci sa stavaju vtedy ked sa osvecili, ze sa stavaju neucinne a nahradili sa lepsimi, ktore vsak popri sebe existovali. Co si vsimam tak vacsina zaciatocnikov pouziva deprecated techniky, lebo knihy pre novacikov su stare. U profi koderov sa nieco podobne moze stat maximalne na 3-4 starom projekte, ktory sa uz nevyvija.
Odkial mas ze Google upusta od Pythona ?
C a C++ a dokonca Java su verziovo nekompatibilne. Jedine tak zaklad ASCII C je medzi sebou kompatibilny, no s nim uz nieco velke nevytvoris. Zaberie to vela casu. Java je taktiez verziovo nekompatibilna. Samozrejme tesime sa na verziu 7.
Perl sa chcel zbavit starych zavislosti a priniest novy vanok. No nepadarilo sa mu to zatial, lebo je to neverending story. A to ze neni popularny az tak moc nie je chyba pripravovanej novej verzie. Skapalo to uz pri verzii 5.
Python 3 sa neruti do zahuby, tak ako Ruby 2, ktore je tiez v urcitych castiach nekompatibilne. Ak ti vsak vyhovuje stale pracovat na starych principoch, tak prosim. No pri dynamickych jazykoch to od nich neocakavaj.
Ja si nic nechvat nemusim. Kazdy, opakujem kazdy skok verzie o jeden celociselny bod prinasa take zmeny, ktore nieco potlaci a nieco nove zavedie. Na udrzanie 100% kompatibility je desatinny bod. Konec
ja som v Pythone robil uz par rokov, takze myslim, ze mozem si dovolit sudit veci.
tiez ma Python zatial nesklamal.
nikto ma v nom nenuti pisat.
nie som zaujaty.
ide o to, ze python sa preraba privelmi casto... pocul si uz o uspesnom jazyku, ktory sa vkuse preraba?
niekedy je kompatibilita viac, ako nove a nove features...
odpovede pre Radovana:
> Co si vsimam tak vacsina zaciatocnikov pouziva deprecated techniky, lebo knihy pre novacikov su stare. U profi koderov sa nieco podobne moze stat maximalne na 3-4 starom projekte, ktory sa uz nevyvija.
ano a o tom hovorim. ked napisem program(a povedzme, ze nejaky profi koder napise obrovsky programisko ;) ), tak som rad, ze ide a koniec - viac sa o neho nestaram. nemam ani najmensi zaujem upravovat ho, ked pekne slape... a prave k opaku ma nuti filozofia Guida. Predstav si napriklad Ty, ze by si nakodil nejaku stranku v PHP(trebars nejaky eshop) a po 3 rokoch by prestala klientovi fungovat. Nezmenil by si vtedy nazor? Toto je ten isty pripad.
aporopo neviem o ziadnem vacsej(rozumej klucovej) _nekompatibilnej_ zmene Javy, Ccka, ani C++su, ktora sa udiala behom poslednych 5tich rokov
> Ak ti vsak vyhovuje stale pracovat na starych principoch, tak prosim.
NEvyhovuje mi pracovat na starych principoch, no nemam ani najmensiu chut polemizovat o funkciach redice() a filter(), alebo sa hadat, ci ma mat print zatvorky, ci nie...
> Odkial mas ze Google upusta od Pythona ?
jeden typek v mailingliste raz pisal, ze zucastnil "vyberoveho konania"(ci jak sa vola to onee, ked sa uchadzas o pravu) Googlu a napisal, ze tam Python vobec nepozadovali.
ano pouziva, lebo ked uz nieco naprogramoval a funguje to, tak nema zmysel to prepisovat. ja som len napisal, ze na tych vyberovych konaniach pre novych google programatorov google uz upustil od Pythonu a dava doraz na Javu(ked uz vyvinuli GWT, tak bodaj by nie ;-) ).
pozri, toto som cital, viac o tom povedat neviem. tusim chcel byt dotycny radovy programator ;-)
ide len o to, ze sa pamatam, ze nieco take sa hovorilo, ze Google od Pythonu upusta + som si to sam sebe vysvetlil tak, ze je vkuse nekompatibilny, tak je to preto.
nepisal som to, aby som od Pythonu niekoho odhovaral, ale aby som dopisal informaciu, ktoru som sa dozvedel a nech si citatel vyvodi vlastne zavery. ale od toho, ze jeho nekompatibilita serie zacina kazdeho srat(prinajmensom mna), ma nikto neodhovori :-)
1. Python 3.0 sice porušuje zpětnou kompatibilitu v řadě aspektů, ale nikdo tě nenutí na něj přejít. I GvR doporučuje přechod na 3.0 jen u nových aplikací. Pro ostatní je zde Python 2.6 který přináší řadu věcí z 3.0, ale zpětnou kompatibilitu neruší (tedy ne mimo obvyklé meze drobných změn, náhrad a deprekací). A nikdo také nikdy netvrdil, že nebude Python 2.7, 2.8 atd. V podstatě je Python 3.x nový jazyk nebo spíš větev jazyka, experiment, a teprve se uvidí jak se prosadí. Nikdo tě nenutí ho používat, můžeš se držet staré větve 2.x i do budoucna.
2. Pokud máš fungující aplikaci např. v Pythonu 2.4, nikdo tě nenutí k jejímu provozování používat jinou verzi Pythonu. Není problém udělat aplikaci soběstačnou (freeze) nebo mít nainstalováno i několik verzí Pythonu pokud je to třeba.
Praveze Python sa neprerabal privelmi casto. Python verzie 2 je tu s nami tak dlho aby sa zmenili urcite principy. Tzn. potlacili tie prekonane a zaviedli efektivnejsie.
Priklad ktory si dal tak nezahrnuje terajsiu situaciu, ktora sa rozobera. Musis si presne uvedomit s desatinnou zmenou verzie sa kompatibilita nenici a vsetko co je deprecated zostava stale funkcne, ale je to neodporucane. Priklad $HTTP_SERVER_VARS (ci jak to bolo) vs $_SERVER. Funkcne ale neodporucane. A ked pises program tak ho pises pre nejaku platformu. Ze sa zmeni tak ty tym negarantujes. Ver mi, ty to dodas, ze funguje to na tomto a tomto. Zmena moze znicit funkcnost. O tom musi byt ziadatel informovany.
"aporopo neviem o ziadnem vacsej(rozumej klucovej) _nekompatibilnej_ zmene Javy, Ccka, ani C++su, ktora sa udiala behom poslednych 5tich rokov"
Borland C++ vs MS C++ atd. MS Java vs SUN Java. A tak dalej.
"jeden typek v mailingliste raz pisal, ze zucastnil "vyberoveho konania"(ci jak sa vola to onee, ked sa uchadzas o pravu) Googlu a napisal, ze tam Python vobec nepozadovali."
Inak hla, mohli sme tu mat o generaciu lepsi jazyk, no mame tu len jeden desatinny bod. Smutne, lobby pracuje dobre. Aspon Adobe ked uz poriadne nikto iny.
Nuz, web ako taky pojde rychlou cestou do sraciek (pochop interaktivna cast), kedze nikto nedokaze ponuknut taku vyhodu ako bude vo Flash / Flex
myslim, ze by se mel system tvorby webu predelat, aby to bylo vice jako
normalni programovani. webovy prohlizec s programem, ktery vytvari vzhled
stranky/klientskou cast programu a volani nejakych funkci na serveru pro ziskavani dat, volani bussines objektu/serverova cast.
Jakožto pythonistovi by se mi ta myšlenka docela zamlouvala (kdysi s ním, mám dojem, koketoval i Netscape a existuje i pythonovský browser Grail, který umí client side pythonovské skripty), ale podle mě je to utopie a nemá v současné době valný smysl se jí zabývat. Většina vývojářů zná a většina z většiny bude preferovat JavaScript, stávající stránky nikdo předělávat nebude a v případě duality by asi na Python skoro nikdo nepřešel a možná by podporu Pythonu někteří výrobci odmítli implementovat. Navíc nemá současný Python vyřešený sandboxing apod., takže by se musely vyřešit bezpečnostní aspekty předtím, než se o nasazení začně vůbec uvažovat. V současné době bych preferoval vyřešení problémů JavaScriptu jakožto relativně jednotného a otevřeného klientského skriptovacího jazyka.
Python má šanci prorazit na jiných frontách - podpora Pythonu v Epiphany a připravovaná podpora Krossu v Konqueroru umožní vytvářet rozšíření browseru v Pythonu a blížící se jedničková (konečně) verze Djanga přinese obrovskou příležitost vylepšit pozici Pythonu na poli webových frameworků.
Namiesto vymyslania blbosti a dohadovania sa mohli javascript nahradit LISPem. Ten ma vsetko co potrebovali a navyse jednotnu/neroztriestenu specifikaciu, ktora sa jednoznacno implementuje do browserov. Navyse lze kompilovat do nativniho kodu co by mozno este vjacero vyhovovalo komercnym firmam. Som z vyvoja Webu a jeho technologii dost sklamany. :(
P.S.: Sorry za me slovenske-neslovenske vlozky, ale chtel jsem, aby to bylo vtipne. :):)
Vsak ja jsem o implementaci nic nepsal, ale o specifikaci. To je IMHO sila, takove ty kvazijazyky, co si vyviji na kolene par vyvolenych a diktuji smer, jsou jedine smerem do pekel.
Doufám že to nikoho nenapadne skutečně udělat. Bloky definované odsazením - IMHO fuj zvláště při použití v html dokumentech. Zpětná nekompatibilita - python 3.0. Nekonzistentni api základních knihoven, nízký výkon ...
kazdy argument ktory tu pises svedci o tom ze si python nikdy nepouzil v ozajstej aplikacii,
a inak ako dlhorocny programator by som si nikdy nedovolil tvrdit o jazyku ktory nepouzivam taketo blbosti !
zase nepodlozene tvrdenie
ja mam zase info ze python je v niektorych oblasiach vykonnejsi,
hlavne ked sa pouziju rozsirenia ako Psyco, vtedy sa blizi rychlost az k skompilovanemu kodu v C
osobne ale nemam nic proti JavaScriptu, ten ma svoje misto ako embedded jazyk v prehliadaci, nevyhoda je ze sa mimo prostredia prehliadaca neda pouzit, ale na to ani nebol vytvoreny
ok, to beriem, na druhej strane verim ze ste s tym nemali vacsie problemy :) python ma vyborne c-api na vytvaranie balickou v c/c++, a su tu aj pomocky a SWIG :)
toto som myslel v celkovom kontexte - Pythonu ako jazyka vseobcne.
Javascript je jazyk ktory bezi v prostredi browsera, tak to je a tak to aj ma byt.
Ak by mal python nahradit JavaScript by mal tiez bezat v prostredi browsera a teda budu pristupne len tie balicky ktore budu pouzitelne len v browsery teda napr. nebudu pristupne funkcie na otvaranie suborov. Z toho vyplyva ze prakticke dovody na vymenu JavaScriptu za Python ani nie su. Iba tolko som chcel, aby sa vedelo ze nie som fanaticky zastanca Pythonu :-)
O tom by mohli uzivatele pythonu na x86_64 architekture vypravet ...
ale ne pohadky na dobrou noc.
(je tam bug co vyhani spotrebu pameti cca 4x oproti 32bit)
sam si napisal ze python nepoznas, tak nechapem cim chces dokazat svoje tvrdenia, vies je rozdiel ked si nieco len precitas na webe a ked to denne pouzivat v praci, to je sakra velky rozdiel
napriklad to odsadzovanie, moze sa to zdat prinajmensom cudne chciet od programatora aby dodrziaval odsadzovanie, ale ma to obrovsku vyhodu, kod je citatelnejsi. Az potom ked "zdedis" kod po niekom inom, alebo studujes nejaku kniznicu to ocenis.
spatna nekompatibilita - napjprv si treba precitat dovody preco k nej pristupili a tiez konkretne pripady, a ako je rieseny prechod, na to je prave verzia 2.6, ktora ma zlusit ako premostenie medzi verziami 2.x a 3.x
Bloky definované odsazením - a to je vada na kráse?
Nekompatibilní nová verze - irelevantní, pokud by se nasadil hned Python 3000
Nekonzistentní základní knihovny - oproti neexistujícím Javascriptovým je to pokrok. Kdovíjak hrozné to ale fakt není.
Nízký výkon - proti JavaScriptu?
Bloky definovane odsazenim - ano v pripade webu (HTML, XML a do toho zamichany Python) je to podstatna vada na krase. Zavadi se tam zavislost na koncich radku, to neni dobre. Uz jen proto, ze mnoho JS kodu je generovanych, ruzne transformovanych atd.
Generovanej kod je pekna prasarna. Je pravda se kdysi sem to taky delal, ale vetsinou jako naky zjednodusseni nebo kvuli omezeni JS. V Pythonu sem nic takovyho nikdy nepotreboval, i kdyz to taky podporuje.
Zasadne nesouhlasim, ze bloky definovany odsazenim je jakakoli nevyhoda pro Python. Naopak mi to pride jako jedna z jeho nejvetsich vyhod.
Na generování kódu není nic špatného. Metaprogramming je jeden z velmi dobrých způsobů jak předcházet chybám a zjednodušovat údržbu kódu. Nemluvě například o generování parseru. Nicméně v případě JS mi přijde, že ke generování kódu je jediný důvod a to výkon. Vzhledem k tomu, že JS je plnohodnotný funkcionální jazyk!
S tim odsazenim je to slozitejsi. Jasne, normalne to nevadi a vyvojar by odsazovat mel tak jako tak, ale co treba sablony, treba ve stylu ERB souboru v Ruby ci PHP souboru s HTML? Tam odsazeni krute saje ...
Coze? Hmmm, ne. Ta zobrazovaci logika se nekam nacpat musi. O lepsim reseni nevim. Ty ano? A oddeleni od grafiky, to teda sorry, ale od SEMANTIKY, ta grafika patri do CSS.
to uz je slovickareni, jednoduse receno at uz pises server side(PHP) nebo client side(JS) logika se pise do jinyho souboru nez html, jinak v tom je peknej bordel, kdyz je to neco vetsiho.
Sorry, ale fakt musím. Co prosím tě plyne z toho, že zrovna ty jsi něco v životě nepotřeboval?
K odsazování - já myslím, že to nevýhoda je, i přesto že Python používám jak v práci tak i mimo ni. Nutnost "odentrovat" a odsazovat tě nepotěší, když chceš napsat jen něco krátkého např. do atributu HTML tagu. Dokážu si ale představit syntaxi podporující definování bloku jak odsazováním, tak např. složenými závorkami :-) (to sice už není Python, jak ho známe teď, ale ten se beztak nedá jen tak vzít a hned použít místo JS).
Generovaný kód že je prasárna? Generovaný kód je naopak vždycky lepší než kód psaný ručně. Pokud lze něco (rozumně) vytvořit generátorem, mělo by se to tak udělat.
Ty se chovej slušně anonyme a pokud máš dlouhé vedení, tak polopatě, některé JS implementace dnes vákonem hravě strčí Python do kapsy. Zaspal jsi dobu.
Kdo je u Tebe anonym, bambulo? Jsem asi takový anonym jako Ty. Navíc jsem netvrdil, že nemůže být některá implementace JS rychlejší než Python, jenom jsem se ptal. Chováš se jako kretén.
Teda Pichi, ja myslel ze jsi slusnej clovek a ty jsi hovadko :-(. Mezi interpretovanymi jazyky ma Python vysoky vykon a chtel bych videt komplexni benchmark, ve kterem JS strci Python do kapsy.
Ja bych nerikal "fuj", alespon by 50% webovych "vyvojaru" prislo o praci (a mne by jejich "produkty" nechybeli), ale jinak mne predstava ze nekteri lepici webu spravne odsazuji kod a vubec napisou v pythonu neco co funguje prisla dost legracni.
Ja myslim ze hlavni sila webu a jscriptu je prave v tom, kolik toho snese a co vse prekousne. Diky tomu muzou tvorit web i lide kteri by jinak s klasickym programovanim meli minimalni sanci. A to je nakonec myslim dobre.
On sice vsechno prekousne, ale pak nedela to co se po nem chce a clovek pak stravi dost casu hledanim zakopanyho psa.
Mozna je to subjektivni pocit, ale i kdyz Python sezere taky kde co (krome toho odsazovani), hledat chyby v nem zabere zlomek casu o proti Jave nebo JS (o C/C++ vubec nemluvim). Nevim cim to je, ale od ty doby co sem potkal Python, tak se do jinych jazyku poustim jen s velkou nechuti a to sem predtim vystridal Basic, Pascal, Assembler, C/C++, Javu, Perl, Javascript, ASP (VBScript i JScript) a ASP.NET (C#).
"Bloky definované odsazením" - nejak zabudas, ze ide previest na byte code
"Zpětná nekompatibilita - python 3.0" - kym by sa vyrobcovia prehliadacov rozhybali mali by sme tu verziu 3.5
"Nekonzistentni api základních knihoven, nízký výkon" - tak isto prekonal isty historicky cyklus, ktory pred sebou tlaci. a ten zisky vykon mate odkial ?
Python je velmi oblibeny jazyk designovany pro psani aplikaci. Oblibeny je prave pro to, ze se vyviji a prizpusobuje se novym potrebam a pranim uzivatelu. Ja Python pouzivam dlouho, udrzuji nekolik mensich aplikaci (cca 10 000 - 20 000 radku) v nem napsanych a problemy s kompatibilitou nemam. Python sice zavadi nekompatibilni zmeny, ale dela to velmi rozumne a tak setrne, ze to nepredstsavuje prakticky problem. Treba takovy prechod z textovych na objektove vyjimky byl postupny proces trvajici radu let pres nekolik verzi pythonu. Na prechod z dvojkove rady pythonu na trojkovou se dela specialni verze pythonu 2.6 a opet to bude proces na nekolik let. Tyto zmeny prinesou visi cistotu a logicnost jazyka a ja s nimi jako programator pouzivajici dlouhodobe python souhlasim a vitam je.
Ono ja chapem ten princip vydavania verzii. Majoritna verzia X.0 prinasa zmeny, kde sa nekompatibilita prejavit moze, co je logicke, kedze ide o celkom novu vetvu. V minirotinych verziach X.Y je kompatibilita zachovana tym, ze sa ponechaju aj stare veci + zavedu nove alebo postupnymi zmenami medzi niekolkymi minoritnymi verziami sposobom, ze to bude oznamovane co sa zmenilo + sa zavedu take opatrenia, ze vysledok stareho kodu zostava rovnaky.
Len holt, vysvetli to niekomu, kto krici, ze nova verzia nebude kompatibilna, je to bastl a ine kraviny. Taky ludia by radi zostali v pocitacovom praveku alebo v casopriestorovej bubline, kde sa nic nemeni. Holt, tym to nevysvetlis.
Jako vývojář webových aplikací pevně doufám, že JavaScript už se nikam vyvíjet nebude a bídně zhyne. Nahrazování těžkého klienta stále složitějšími konstrukcemi kolem HTTP je prasárna. V tomto směru nebrzdí vývoj žádný Microshit, ale naopak všichni ostatní, kteří žádný široce rozšířený klientský OS nemají.
Ať žije Silverlight, Moonlight nebo aspoň Flex.
Souhlasím s Vámi. Součastný vývoj webu je něco se co se nemělo stát. Sám jsem webový vývojář a nemohu se dočkat masovějšího nasazení Silverlightu. Flex má také své výhody, ale nikdy jsem mu nepřišel úplně nachuť.
Udělat z HTML+js skutečné webové aplikace je nejen zbytečně složité a nákladné, ale také pomalé a potenciálně nebezpečné
Web svoje místo má, ale rozhodně ne jako náhrada tlustého klienta. Silverlight zas tak proprietární není, je nyní implementován i jako open source na unixové os.
Navíc s JavaScriptem, AJAXem, JSONem atd. jsou probémy i ve stávajících browserech a některé stránky na některých z nich prostě nefungují. Někdy se dokonce vyvíjí verze pro každý prohlážeč, což není moc efektivní.
No jasně, až na ty patenty apod. je to v pohodě. A až na to, že Microsoft už se třese, aby v případě, že se Silverlight prosadí, začal hrnout nové verze, na které se Moonlight (pokud ho MS nezařízne u soudu, aspoň v USA) bude pomalu a s vyplazeným jazykem dotahovat a které každý MS-positive idiot začne hned plně využívat, protože se mu už přece před měsícem stáhly z Windows Update.
Většina stránek ve Flashi, které znám, jsou odporné, špatně ovladatelné, na efekt dělané prezentace; užitečných aplikací je minimum. Silverlight nebude podle mě lepší, spíš naopak. Mezi klasickým webem a tlustým klientem (který se dá napsat v Javě a spouštět přes JWS) snad není taková díra, aby tam bylo nutné tlačit další technologii, která má navíc tolik otazníků.
Proč by MS zařezával Moonlight u soudu, když ho sám financuje a podporu ve spolupráci s Novellem?
Proč se dělají stránky ve Flashi? Asi proto, že HTML + JavaScript to neumí.
Tlustý klient v Javě? Děkuji, jedna zkušenost mi stačila. Silverlight je, co se týká realizace UI o generaci před Javou, se standardními a ošklivými kontrolprvky (Win32, GTK, QT) si donekonečna nevystačíme - zvlášť na webu, kde jde opravdu také o prezentaci.
Microsoft uz pohrbil hodne projektu, na kterych spolupracoval. Viz slavny projekt farenheit nebo jak se to jmenovalo, ktery mel spojit open gl a direct x a udelat jednotnou platformu pro vyvoj 3D aplikaci, tuto spolupraci nakonec zrusil a SGI to odnesla krachem. Microsoftu nejde verit, je to agresivni firma, ktere neni zadna spina cizi.
Samozrejme. Muze za to MS. A v cem je problem? Ze prozirave zamezil tomu, aby se ze dne na den zmenil, takrka vymenil prumyslovy standard. OMG. Vem si lopaticku a nezlob.
Chcel by som sa spytat trosku off-topic otazku: Existuje nejaka technologia, ktora by vedela prelozit existujucu aplikaciu pre nejaky operacny system tak, aby bezala (mozno s minimalnymi zmenami) v browseri? Pripada mi uplne kontraproduktivne mrhat energiu na vyvijanie aplikacii v jazykoch, ktore na to nie su prisposobene, ked uz mam aplikaciu hotovu....
Bola to hypoteticka otazka. Zaujima ma, ci nieco take existuje. Ak chcete byt konkretny, napr. aplikacia v Objective C pouzivajuca cocoa API (resp. GNUstep), teda beziaca v standardnom prostredi Mac OS X.
Kdybychom tohle uměli, tak bychom nepotřebovali OS a stačily by nám jenom browsery.
Nenechte se nachytat na nesmysly "tenký klient na všechno". Browser neumí ani setinu toho, co OS, nehledě na nekompatibilitu meio browsery a úžasnou pomalost javascriptu.
No ved ale podla toho co citam, vsetci sa snazia napchat plnohodnotne aplikacie do browsera. Ak uz chce nieco niekto take spravit, pripadalo by mi logickejsie umoznit beh aplikacii, ktore uz existuju namiesto prepisovania aplikacii do niecoho, co sa na danu vec vobec nehodi (alebo vymyslania 1567 467-teho jazyka). Browser nemusi predsa vediet vsetko co OS, ved backend nech bezi v OS pre ktory je aplikacia napisana, browser musi len zobrazit co uzivatel vidi. Nie som programator (na stastie ;)), ale take riesenie by mi pripadalo omnoho logickejsie. Preto sa pytam, ci take nieco existuje / da sa spravit / preco sa neda, ak sa neda ?
no, rozmyslal som prave na niecom podobnom, ale trosku z ineho uhla.
podla mna vyvoj smeruje tym smerom ze sa bude robit coraz viac aplikacii typu klient-server, aj tych jednoduchych, a GUI by bolo renderovane v browsery.
staci sa pozriet na vyvoj renderovacych jadier ako Gecko alebo WebKit. Obe mozte pouzivat vo svojich aplikaciach ako embdedded, proste namiesto klasickych GUI kniznic pouzijete na vytvorenie/vyrenderovanie GUI prave embdedded engin.
Samozrejme aj serverova cast by mala byt dostatocne nenarocna a optimalizovana aby sa dala spustat cela aplikacia ako klasicka desktopova.
Vyhoda takeho sposobu programovania by bola napr. v tom ze jednoducho viete oddelit serverovu cast a nasadit ju na web server ako cisto web aplikaciu.
No ved ale v aplikaciach je aj dnes (casto) oddeleny backend od vykreslovania obrazovky. Napr. v OS X (alebo v Unixoch a Linuxe s pouzitim GNUStep-u) spavis logiku aplikacie zvlast a potom navrhnes GUI v Interface Builderi. Pritom GUI cast mozes spustit aj bez zvysku aplikacie (na otestovanie). Nemohlo by toto gui jednoducho bezat v brovseri (napr. pomocou Java scriptu)? Klucove by bolo, ze zvysok aplikacie sa pouzije ten isty a GUI by nejaky automaticky nastroj prelozil do jazyka, ktory zvlada browser. Programator by ale vyrabal aplikaciu len raz, a to nativne pre lokalny beh na desktope.
ano take desktopove aplikacie sa robia, ale nemaju az tak oddelenu serverovu cast od tej klientskej.
idelne by bolo (podla mna :)) keby serverova cas bola naozaj samostatna (a bezala by v samostatnom procese), len by odpovedala na poziadavky klienta, potom moze byt klient napisany teoreticky v hocicom, staci dodrzat protokol pri komunikacii so servrom.
Myslim si ze takto budu vyzerat aplikacie v buducnosti, umozni to napriklad aj pripajanie jedneho klienta na viacej servrov a kombinovanie funkcii z viacerych servrov.
Vlastne toto uz dnes exituje a vola sa to internet :), len by sa to prenieslo na desktop
To co popisujete, přesně splňuje už hezkou řádku let protokol X. Proč se Xka nepoužívají více na klient-server aplikace, je mi také záhadou. Místo toho se to všecko cpe přes web, kodéři ohýbají HTML+CSS+JS, aby v něm vykreslili krásné ovládací prvky "jako v normální wokýnkové aplikaci", a výsledek je ve většině případů naprosto nepřehledný bastl (zrovna jeden takový musím upravovat... :))
Ono je to v tom, ze webova stranka nie je len aplikacia, ale je to dokument, ktory obsahuje text, obrazky, audio/video a iny vlozeny obsah.
HTML/CSS/JS nie je strasiak, len "profici" ho z neho robia. Kto to vie, ten to vie, kto to nevie, ten sa musi ucit. Ale po druhej skupine by som nic upravovat nechcel. To by som si radsej cele napisal odznova.
no v poslednej dobe nastastie vznikaju a zacinaju sa pouzivat take frameworky ako YUI, jQuery, a ine.
ak sa spravne pouzivaju daju sa s ich pomocou robit celkom slusne (aj co sa zdrojoveho kodu tyka) aplikacie
a mame tu aj take enginy ako gecko a webkit, ktore sa daju tiez do istej miery prisposobit a pozuit ako embdedded browser, takze aplikacia sa dokaze tvarit ako desktopova aplikacia.
Mozno k niecomu takemu smeruje aj novy browser Chrome od Googla - celkom sa tesim kde to s nim az Google dotiahne :)
Ak napises aplikaciu v Jave tak sa da dostat na web v priebehu niekolkych hodin. Ale v podstate to bude tucna aplikacia beziaca z webu. Vdaka tomu ze Jave je dobre prenosna, mas skoro zarucene ze to bude bezat na Win, Lin, Mac, Sun.
Ak to ma byt od zaciatku web aplikacia skus gwt a nezabudni si pozriet komponenty gwt-ext.
Brendan Eich poznamenává zpravu, protoze zpravuje. Pochybuji, ze neco spravuje ve smyslu 'starat se o neco'. Chybejici carka pred ale: 'kopírovat současné trendy, ale budují'.
Hmm a dalsi, prestalo me to bavit.
no as3 je mezi nami uz cca rok a bezi na kompletne jiny virtualMachine nez as2, takze by bylo fakt komplikovany zaradit zpatecku. Vcelku na me pusobi dobre ale vadi mi priserna ukecanost a pocit "hrani si na neco", tj. presne to co me zralo na jave (cecko ktery si hraje na smalltalk). stejny kod je o polovinu delsi, clovek musi neustale importovat miliony trid, pricemz mnohe z nich treba jen definuji jednu dve konstanty, pripadne implementuji jednu jedinou metodu. proc musi byt metoda stop(), kterou se zastavi prehravany zvuk, v jine tride nez metoda start, kterou se ten zvuk spousti? Notabene kdyz je to jedina metoda dane tridy? rozcleneni do objektu je supr (popravde si neumim predstavit jak by se bez toho delalo), ale vseho s mirou... (a taky me nebavi obalovat bloky do try..catch - ja coby programator prece vim jakych hodnot muze ta ktera promenna nabyvat a rucim za to, ze tam chyba nevznikne - catch blok nechavam prazdny...)
je mi vcelku lito ze flash zustane soliterni aplikaci ECMA4 (jiz se do znacne miry prizpusobil prave kvuli kompatibilite s javascriptem) a rozhodne nevidim sebemensi duvod, proc z javascriptu vyskrtnout zrovna "class" a "package" - i kdyby mely slouzit jenom jako syntakticke pozlatko kolem prototypovych retezcu jako tomu bylo v as2 - pracuje se s tim mnohem prijemneji. Jsem zvedav jestli k nim js vyhledove doevoluuje - dle meho nazoru do kazdeho moderniho programovaciho/scriptovaciho jazyka jednoznacne patri a ono "Jedná se o finální rozhodnutí, nebudou zvažovány ani do budoucna." me dost vydesilo. To uz se muzou rovnou vratit k fortranu...