Giga Research: Vývoj webových portálů je s Microsoftem levnější

Diskuze čtenářů k článku

zdenda  |  10. 09. 2003 01:30  | 

jestli funguje vsechna MS reseni jako www.zive.cz (ma vypadek snad kazdy tyden) tak je to dost smutny...
majinko mimo tema: Pripada mi, ze spousta firem vubec nepremejsli a kupujou drahe a nevyuzite databaze jako je Oracle nebo MSSQL, pritom by jim stacilo PotgreSQL.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  10. 09. 2003 05:36  | 

Bohuzel Zive neni zrovna ukazkovej priklad MS reseni. Ale ty studii se da verit, v praci ja delam serverovy veci jak na Win tak na J2EE a neda se to cenove (ani vykonove) srovnavat. BEA maj ceny za ktery by se i Microsoft cervenal ;) A ten vykon je ubohej, ale to je obecne problem Javy, zvlast kdyz clovek porovnava s nativne kompilovanym .Net kodem...

Jinak je samozrejme pravda ze spousta firem kupuje veci ktery nepotrebujou, ale to je spis dusledek firem prodavajicich "ucelene" reseni, a zdaleka se to netyka jen Microsoftu (kde uzivatele na e-mail server koupi i SQL Server), vubec vsechny velky firmy timhle trpi, Sun, IBM, SAP, BEA, a nakonec i Oracle s jejich pristupen ze vsechno (vcetne UI) je databaze...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jery  |  10. 09. 2003 08:09  | 

Da sa a neda sa verit. BEa sa nemusi vobec pustit na mensie veci do hry. Na mensie veci mozem pouzit JBoss + Tomcat + PostgreSQL a eliminoval som cenu SW. Takze uz tym by som to posunul vyrazne nizsie.

Inak suhlasim s druhym odstavcom.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Richard  |  10. 09. 2003 10:06  | 

Takyto nezmysel mohol napisat iba clovek, ktory NIKDY nepracoval ani s JAVA ani s .NET:

1. JAVA je na serverovej strane prakticky rovnako rychla ako programy v C++

2. .NET nema nativny kod, pouziva velmi podobnu technologiu ako JAVA

Souhlasím  |  Nesouhlasím  |  Odpovědět
Karel Ludanek  |  10. 09. 2003 10:41  | 

>>JAVA je na serverovej strane prakticky rovnako rychla ako programy v C++

To plati pouze pro urcity casti kodu, ve kterym je minimalizovanej beh garbage. Pokud zacnete vytvaret objekty ve velkym, pak java podstatne ztraci na native.

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
xX  |  10. 09. 2003 11:17  | 

Proto jsou taky v novych VMkach ruzny algoritmy behu GC. Aby si kazdy vybral to co potrebuje. Nemluve o nutnosti vhodneho nastaveni heapu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 11:24  | 

ad 1) Java se může maximálně rychlosti C++ přiblížovat. Můj názor je asi takový, že pokud je program v C++ dobře napsaný, tak nechává Javu dost za sebou. Java dokáže být rychlá hlavně v malých speciálních kouscích, ale jakmile začnete vytvářet a rušit objekty ve velkém, tak jde Java IMHO rychlostně hodně dolů.

ad 2) Runtime .NETu má podobnou technologii jako Java, a přesto to není totéž.

Souhlasím  |  Nesouhlasím  |  Odpovědět
xX  |  10. 09. 2003 11:26  | 

Zajimave ale muze dopadnou Java na Itaniu a vubec procesorech, kde kompilator dela velke optimalizace kodu. Tady muze Java (a i .NET) tezit z moznosti rekompilovat kod podle konkretnich dat. To by mohlo beh proti standardnimu statickemu kompilovani zrychlit. Nicmene je porad asi treba napsat JIT compilery ktere to budou umet.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 11:53  | 

Zatím se pořád ukazuje, že staticky kompilovaný kód je vždy optimalizovanější. Alespoň potud praxe. Abych řekl pravdu, stále vidím snahy, jak vysvětlit národu, že Java je nejrychlejší na celém světě. Už to přestávám považovat za seriózní.

Smiřte se s tím, že nejrychlejší programy budou vždy v nativním strojáku a assembleru.

Pak to budou o něco málo pomalejší vyšší programovací jazyky kompilované do strojáku, ať je to C, C++, Pascal, a další. Vzhledem k účelům, pro které bylo C a C++ vytvořeno, a vzhledem k péči, jaká je dávána optimalizačním algoritmům těchto kompilátorů, je asi dvojice C, C++ favoritem.

Interpretované jazyky, nebo mezikód, byť kompilovaný, bude vždy pomalejší, než stroják, assembler, C a C++. Možnost rekompilovat kód pomocí dat IMHO možná přinese určitý nárůst rychlosti, ale stále ještě bude daleko pomalejší, než slušně napsané programy v C, C++. Java se nepoužívá z důvodu rychlosti běhu a rychlá obecně ani není!!!

Navíc začínám podezírat lidi, kteří srovnávají rychlost programů v Javě s C++, že neumějí v C++. Že totiž srovnání s C++ je provedene na velmi špatně a neefektivně napsaném C++ programu.

Takto si představuji seriózní srovnání rychlosti: Uveřejněný zdrojový kód programu v C++, použitý kompilátor, a volby kompilátoru, kde byla vidět snaha o maximální optimalizaci. Totéž by se mělo být pro Javovský program. V ideálním případě srovnat na několika kompilátorech a pro několik problémů, tedy programů. Takto seriózní srovnání rychlosti Javy a C++ jsem ještě nikde neviděl. Asi se toho zastánci Javy opravdu bojí. Buď toho, že by vyšla pravda najevo, to jest, že s rychlostí Javy oproti C++ to zdaleka není tak růžové. Prostě tezi o podobnosti rychlosti Javy a C++ považuji za mýtus.

Souhlasím  |  Nesouhlasím  |  Odpovědět
xX  |  10. 09. 2003 13:14  | 

S tim statickym kompilovanim to neni prave docela pravda v pripade Itania, kde zmena implementace (napr. Itanium I na Itanium II) vede k nutnosti prekompilovat kod, jinak je velice neefektivni. V pripade dynamicky prekladanych jaziku staci naimplementovat pouze JIT compiler pro danou implementaci a vse bude fungovat optimalne. A jak jsem jiz rikal - v pripade optimalizace kodu na zaklade zpracovavanych dat muze byt JITted kod rychlejsi nez staticky prekladany, jelikoz se muze prizpusobit konkretni mnozine dat.

BTW v pripade ze mezikod bude zpracovany pomoci JIT, neni duvod proc by C++ melo byt rychlejsi nez Java nebo .NET. Snad jen diky pouziti garbage colectoru a diky neobjektove orientovane optimalizaci kodu v C++.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 13:52  | 

Předpokládáme samozřejmě, že program v C/C++ budu zkompilovaný pro daný procesor. Mám zájem bavit se pouze o optimálních podmínkách pro Javu, nebo C++. Vytvořit nevýhodné podmínky pro jednu platformu a výhodné pro druhou, to se dělá, když někdo chce, aby testy dopadly určitým způsobem.

Víte, to je pořád samé, může být rychlejší, může se ... atd.. Já bych rád, aby to už někdo na konkrétním případě změřil, dokázal. Žádnou seriózní recenzi jsem ještě ale neviděl.

Kód zpracovaný pomocí JIT je dvoustupňový. Nejdřív kompilace do byte kódu a optimalizace pro virtuální asm používaný JVM. JIT pak vezme byte kód a přeloží ho do nativního strojáku. Tento dvoustupňový proces je podle mého pro optimalizaci méně výhodný, než přímý překlad zdrojový kód do strojáku. Protože se zbytečně přizpůsobujete byte kódu, který pak nepoužijete, ale "ohýbáte" optimalizaci na něj. Já tedy naprosto jasně vidím důvod, proč by Java měla být i přes JIT pomalejší, než C++.

Existují dokonce i přímé kompilátory Java zdrojový kód do nativního strojáku. Tuším, že to dělá třeba kompilátor z GCC rodiny. Ale to už se velmi blíží kompilátoru.

Samozřejmě garbage collector shazuje výkon Javy velmi dolů.

Nechápu poznámku o neobjektové optimalizaci kódu v C++. Zkuste mi vysvětlit, prosím, co tímto termínem myslíte.

Závěr: Osobně si myslím, že Java se snaží o něco, kam nepatří. A to rozhodně nepatří tam, kde honíte rychlost. Každý jazyk má svá plus i mínus, a to je důvod, proč existuje více možností. Tam, kde budu honit rychlost, nebudu používat Javu, ale půjdu do C/C++, případně, je-li to hodně akutní ve vyjímečných případech, až do asm. Velké podnikové systémy je sice také možné napsat v C++, ale určitě budu zase Java vhodnějším kandidátem. Atd.. Nechť se každý švec drží svého kopyta, tj. ať se každý jazyk používá pro své přednosti.

A o rychlosti Javy si každý prakticky udělá závěr sám, pokud si spustí nějaký program v Javě a ekvivalentní v klasickém jazyku. Nejvíce to vynikne na nějakém slabším procesoru, řekněme kolem 200 - 400 MHz.

Každá abstrakce v programovacích jazycích má své režie. Proto není žádná ostuda, že Java je výrazně pomalejší, než C++. C++ nabízí něco a Java nabízí něco. Pro každý projekt se pak vybere to, co je výhodnější.

Souhlasím  |  Nesouhlasím  |  Odpovědět
xX  |  10. 09. 2003 14:08  | 

Nativni kompilatory pro Javu v mnoha pripadech vubec nedokazaly ze jsou az o tolik rychlejsi nez JIT. Prikladem muze byt zminovany GCJ - podle benchmarku provedenych IBM, je nativni kod z gcj pomalejsi nez kod v JITu. - zde je clanek i se zrojovymi kody:

Ohledne neobjektovosti v C++ - diky tomu ze C++ je pouze a jenom nadstavba nad Cckem a metody tridy nejsou by default virtualni, muzu aplikaci snadno naprogramovat mene objektove nez v Jave (v podstate pouziji pouze zapouzdreni). A prave diky tehle vlastnosti ziskam na druhou stranu rychlost. Samozrejme se nesnazim tvrdit, ze je to spatne nebo dobre, ale tato vlastnost v C++ existuje a je velice casto vyuzivana - nakonec je to mozna i duvod proc pouzivat C++.

BTW s posledni vetou souhlasim - Java pro me projekty ma tolik pridane hodnoty oproti C++, ze se mi ji vyplaci pouzivat i kdyz je pomalejsi.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 14:44  | 

Problém je, že i gcj musí stále počítat s tím, že se třeba dotáhne třída z webu a budou jí muset interpretovat, apod.. Ale o odkaz bych měl eminentní zájem.

Režie volání metod virtuálně oproti statickému volání je dost malá. Kdysi jsem to sám pro sebe měřil, a samotného mě překvapilo, jak malý vliv na rychlost to má. Na druhou stranu se dají použít inline funkce, dají se použít šablony a další věci.

Co se týká poslední věty, o tom to je. Java vůbec nemá proč se měřit rychlostně s C++. Její přednosti jsou jinde. Ohledně rychlosti to prostě Java s C++ bude prohrávat. A to bez ohledu na to, co se kde, většinou nepodloženě tvrdí.

Java má určité přidané hodnoty a určité odebrané hodnoty oproti C++. Navíc lze očekávat její určitý vývoj, zejména pokud se teď musí jistým způsobem srovnat s konkurencí .NET prostředí. A já jsem rád, že existuje obojí, jak Java, tak C++, a lze si vybrat.

Souhlasím  |  Nesouhlasím  |  Odpovědět
xX  |  10. 09. 2003 15:29  | 

Sakra ten link Zive sezralo - jsem zvedav jestli se to povede ted - http://www-106.ibm.com/developerworks/java/library/j-native.html



Souhlasím  |  Nesouhlasím  |  Odpovědět
tomik  |  10. 09. 2003 13:20  | 

Já spíš pořád slyším jak je ta Java strááááášně pomalá, jako by to na ní bylo to nejdůležitější.

Když si vemu rozumně napsanou webovou aplikaci v Javě a porovnám o kolik bych ji zrychlil přepsáním do něčeho jiného s přihlédnutím k výkonu spotřebovanému na čtení dat z databáze a ostatní režie, myslím že to bude tak nepatrný přínos, že se divím všem, kteří tady nad tím mudrují.

Pořád se kdekdo snaží porovnávat neporovnatelné tj. C++ a Javu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 14:02  | 

Přesně tak! Java je v principu pomalá, ale to není zase tak důležitý fakt. Spousta aplikací prostě rychlost zase tak moc nepotřebuje, a v případě práce s databází dost často nejvíc maká databáze samotná. Prostě Java má své výhody, pro které se používá.

Když někdo se snaží uvádět, že Java je stejně rychlá, ba i rychlejší, než C++, tak mi to zavání neseriózností a komplexy. Tak trochu mi to připomíná volání femististek, které na každém kroku se chtějí vyrovnávat mužům za každou cenu. Přitom to nejpřitažlivější na ženách, to jest ženskost, nechávají ladem.

Já myslím, že je blbost měřit se rychlostně s C++, to obecně musí Java prohrát. Ale Java se přeci napoužívá na psaní ovladačů grafiky, ani na psaní operačních systémů. Java se používá na podnikové systémy, apod..

Souhlasím  |  Nesouhlasím  |  Odpovědět
tomik  |  10. 09. 2003 14:17  | 

Ještě bych dodal, že vzhledem k tomu, že knihovny z C++ a dalších jazyků lze zabalit do Java tříd, je možné se v určitých případech C++ značně přiblížit. Pochopitelně se musí zase něco obětovat, např. přenositelnost. 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 14:49  | 

Ono by bohatě stačilo, kdyby Sun napsal v C++ základní knihovny. Takhle je podle mě zbytečně slušná část výkonu Javy věnována na to, že kihovny Javy jsou opět z větší části Javovské.

Souhlasím  |  Nesouhlasím  |  Odpovědět
tomik  |  10. 09. 2003 16:11  | 

Já se obávám, že tak asi 83% všech standardních knihoven v C++ je. Stačí prolistovat deklarace.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 16:30  | 

Já se obávám, že není. Zvláště, když přímo vidíte zdrojové kódy těch knihoven.

Souhlasím  |  Nesouhlasím  |  Odpovědět
tomas  |  10. 09. 2003 16:58  | 

Vazeny pane Ponkrac,

musim Vas vyvest z omylu. Jiz delsi dobu je Java diky hotspot kompilaci do nativniho kodu rychlejsi nez C++. Rozdil je sice pomerne maly a na Linuxu je Java zatim o chloupek pomalejsi nez C++, ale to uz neni vyznamne. Java (a C#) nabizi programatorovi oproti C++ takovy komfort, ze nasazeni C++ musi byt silne oduvodnene.

Samozrejme na to existuji empiricke dukazy, treba <A HREF="http://dada.perl.it/shootout/craps.html">zde je vyborny test asi pro 10 uloh.
Java samozrejme pomaleji startuje a jeji okenka jsou pomalejsi nez nativni volani treba Win32.

Jazyk C++ je samozrejme pro nektere veci vhodnejsi (nasazeni na slabem HW, kernel, apod).

Nezapomente prosim: casy se meni.

Mejste se hezky, Tomas

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 17:55  | 

Pořád jde o základní otázku. Věřím, že dobře napsaný Java program je rychlejší, než špatně napsaný C++ program. Pokud bude napsán program v C++ dobře (a přiznejme si že i na kvalitě standardních knihoven toho kterého kompilátoru záleží), pak osobně nevěřím tomu, že by Java program byl rychlejší.

Někdy mám pocit, že Java programátoři opakují mýtus o rychlejší Javě oproti C++ hlavně proto, že stokrát opakovaná lež se stává pravdou. Je hezké, že to nikdo nepodložil, alespoň nikdo z těch, kdo mi to tvrdil.

I ve Vámi zmiňovaném odkaze se Java nepředvedla jako rychlejší, než C++, a rozdíly v rychlosti byly takové, že C++ bylo několikanásobkem rychlosti Javy. Přiznám se, že jsem to neproklikal všechno, ale odkaz je moc moc zajímavý a já za něj děkuji.

To, že nějaký program pomaleji startuje, neberu za podstatné.

Časy se sice mění, ale základní principy zůstávají. Stejně tak, jako se nemění gravitační zákon, a pokud vím, ani třeba rychlost světla se nějak nezměnila bez ohledu na vroucná přání lidí a podobně. C++ má obecně mnohem lepší a účinnější prostředky, jak vytvořit rychlejší program, než Java. Dokonce i samotná Java bývá napsána za pomoci C/C++.

To, že Java nabízí programátorovi určitý komfort je bez diskuse. Kvůli tomu se přeci Java používá.

Pokud chcete mermomocí dokázat, že C++ je pomalejší, než Java, mám pro Vás návod. Nejdříve musíte použít ten nejhorší C++ překladač z hlediska optimalizace, co existuje. Momentálně z těch známějších jsou to Borlandské překladače C++, které jsou na tom z hlediska optimalizace výrazně špatně. Pak napište C++ program s použitím těch nejhorších algoritmů, ideální je třeba bublinkové třídění, a podobné věci. Snažte se i přesto ten program napsat špatně, jak to jenom jde. Samozřejmě přeložte program s takovými volbami, aby výsledek byl co nejhorší. Myslím, že se Vám pak podaří, aby program v C++ byl pomalejší. Ovšem varuji Vás, nesmíte použít dobrý překladač C++!!! Ne, aby Vás napadlo použít kompilátor od Intelu, nebo GCC!!! Ty kompilátory mají výbornou optimalizaci překladu, a mohlo by stát, že přes veškerou Vaši snahu byste dostal program v C++ vždy rychlejší, než v Javě. A to přeci není cílem.

Zkrátka a jednoduše. Pokud bude knihovna Javy psaná v C++, dobře napsaný JVM (Sun třeba zrovna nevyniká rychlou Javou, pokud sahají mé znalosti) a bude slušně napsaný program v Javě, může se rychlostně blížit k C++. Ovšem dobře napsaný program v C++ musí být za použití dobrého kompilátoru, a dobrých knihoven alespoň o chloupek rychlejší, maximálně dosáhnout stejné rychlosti.

Zatím mě nikdo, <b>kromě nepodložených sebevědomých výroků</b>, nepřesvědčil, že je Java rychlejší, než C++. Znovu opakuji, že IMHO je to možné jen tehdy, pokud srovnávací program v C++ píše nějaký nedouk, který C++ neumí. Nejsem tvrdohlavec, a jsem přístupný důkazům, ale samotný princip běhu Javovského a C++ programu mluví proti tomu.

Já si taky umím přečíst někde kdejakou polopravdu, či lež a vydávat jí za pravdivou. To není žádné umění. Ale tomu, že dobře napsaný program v C++ je pomalejší, než Java, tomu věřit nehodlám, kdyby mi to říkala sebevětší autorita. A to do té doby, dokud někdo nepřinese důkazy a seriózní podklady, že to tak skutečně je.

A až to tak bude, tak MS přepíše svoje jádro Windows systému z velké části do Javy, a totéž uděláme s Linuxovým jádrem, abychom tak získali rychlejší operační systémy. Pošleme C++ na smetiště dějin, protože Java bude rychlejší a komfortnější, a C++ už nebude mít skoro co nabídnout. Protože to by byl nejlogičtější krok po takovém zjištění.

Souhlasím  |  Nesouhlasím  |  Odpovědět
sss  |  10. 09. 2003 20:21  | 

mno procetl jsem si to tu co pisete a mam dojem ,ye to jste naopak vz ,kterz trpi komplexz ,jakmile nekdo pronese neco kacirskeho = že by mohlo mit konkurenta... - java neni to co byla před 8 lety a hodně se zlepšila - možná další systémy z důvodu nutné vetší abstrakce budou muset být psány ve vyšších jazycích
ohledně té rychlosti - vubec není nikde řečeno ,že systém ,který je enormně rychlý na urovni niykých urovní bude nejrychlejší v globalu a ve výsledku - přenos neuronů v lidském mozku je několikrat pomalejší ,než běhají data po optice - ale přesto...

Souhlasím  |  Nesouhlasím  |  Odpovědět
sss  |  10. 09. 2003 20:23  | 

blbost prenos neuronu - myslel jsem tím přenos vzruchu mezi neurony

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 21:09  | 

Java není, co byla před 8 lety. Na to je jednoduchá odpověď, C a C++ taky není co bylo před 8 lety, stejně tak, jako jiné jazyky. Java není jediné, co se vyvíjelo, zatímco ostatní věci na světě zůstaly stát a s otevřenou pusou koukaly na to, jak se vyvíjí Java.

Já netrpím komplexy, ani netvrdím, že by se mohly prosadit vyšší jazyky. Naopak je vítám, ale tady se bavíme hlavně o rychlosti.

A s těmi neuronu je to o paralelnosti. Až bude mít optika tolik vláken a spojů jako neuron, bude rozhodovat zase ta rychlost na nízké úrovni.

Ale jádro pudla je v tom, že netrpím komplexy, ani strachem z něčeho "kacířského". Ale pouze netrpím tím, že když někdo prohlásí nějaké marketinkové heslo, že tomu hned uvěřím. Zatím někdo nepodložil tvrzení o Javě rychlejší, než C++. Zatím to bylo pouze "Java je rychlejší, než C++", "Java už není to, co bývala před 8 lety", a podobná tvrzení, ale důkaz, či studie, to ne. Prostě jsem kacíř jen proto, že někdo něco tvrdí hubou, aniž by to měl podloženo. Pokud to chápete v tomto smyslu, pak jsem hrdý na zakomplexovanost ve smyslu předchozí věty. Mimochodem, až vám někdo bude tvrdit, že je zdravé jen tak s holýma rukama bez jištění vyskočit s 30. patra, tak ho taky poslechnete?

Javu jako jazyk uznávám, ale zase nemusím trpět iluzemi. Má prostě své silné i slabé stránky, jako všechno na tomto světě. Java nemusí být pomalá, ale rychlost Javy není její nejsilnější vlastnost, to rozhodně ne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
tomas  |  11. 09. 2003 11:41  | 

Zacnu od zadu, protoze si to lepe pamatuji. Kernel Linuxu a myslim i MS Windows neni psan v C++, ale v C, ktere je samozrejme rychlejsi nez Java a asi to tak i zustane. Takze prepisovani do Javy nehrozi. Pokud vim, tak jedna verze jadra Linuxu byla LT prepsana do C++ a potom se vratil zpet k C.

Tvrzeni, ze staticka a dynamicka kompilace podobnych jazyku jako je Java a C++ vychazi ve prospech staticke kompilace jiz davno neni pravda. Pokud by to tak bylo, neplanoval by MS prenos vsech svych produktu s vyjimkou OS do C#. At si o Microsoftu kdo chce co chce rika, idioti to nejsou. Je prece jasne, ze pokud kompiluji za chodu programu, tak jsem schopen dosahnout lepsich vysledku. Dynamicka kompilace umoznuje mnohem lepsi praci programu. Kompilator muze optimalizovat casto pouzivane casti kodu a naopak casti, ktere se pouzivaji malo odsunout "dozadu" apod. Nic neni zadarmo. Stoji to samozrejme cas pri startu aplikace a optimalizace nemuze byt tak dokonala jako pri statickem preklad - trvalo by to moc dlouho.

Je samozrejme pravda, ze dynamicka kompilace je oproti staticke v plenkach, ale domnivam se, ze az na nejake malickosti je staticka kompilace na konci svych moznosti. Naopak dynamicka kompilace (Java, C#, apod.) ma pred ssebou velkou budoucnost.

Na jiz uveden strance http://dada.perl.it/shootout/craps.html je Java oproti C++ asi v 10-ti testech o 1.5% rychlejsi. Pripada mi to jako dostatecny empiricky dukaz. Tim nechci rici, ze 1.5% je nejak vyznamnych, ale doba, kdy se dala Java povazovat za pomaly jazyk je pryc.

Vubec nechci jazyk C++ odsuzovat. Ma pred ssebou budoucnost v nativnich aplikacich. Jenom si myslim, ze pro tyto ucely je mozna jazyk C vhodnejsi, ale vim jak nepohodlne se v nem nektere veci pisi.

Dovolim si osobni poznamku k Vam pane Ponkrac: volate pro argumentech, ktere jsem Vam jiz 2x prinesl (URL) a ignorujete je. Sam ovsem sva tvrzeni zakladate pouze na dogmatech, bez jakohokoliv dukazu. Takto se prece nediskutuje.

Mejte se hezky.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  11. 09. 2003 14:06  | 

Jádro Linuxu je psáno v C. C++ ja v podstatě nadstavbou jazyka C, a až na několik málo výjimek v sobě celý jazyk C obsahuje. V jazyce C++ se dá psát stejně efektivně, beru-li to z hlediska rychlosti, jako v jazyce C. Z jiných pohledů dokonce i mírně efektivněji. Proto tyto jazyky pro potřeby rychlosti nijak striktně nerozlišuji.

Rozhodnutí MS přepisovat produkty do C# je určitě chytré. Jenomže toto rozhodnutí určitě není děláno kvůli rychlosti. Celý sw průmysl pase po rychlejším, efektivnějším a levnějším vývoji, a o to primárně jde. Rychlost se v tomto případě obětovává. Cílem je zejména úspora peněz, nikoli rychlost výsledných programů.

Prostě já sám tíhnu k používání vyšších jazyků, než je C++, a nebo alespoň lepších knihoven, protože vím, co mi to přináší. Rychlejší vývoj, výhody vyšší abstrakce, spoustu věcí nemusím řešit, apod.. Na druhé straně ztrácím určitě alespoň část rychlosti oproti řešení psaní v nízkém programovacím jazyce.

Je naprosto přirozené, že vývoj vyšších jazyků se veden snahou mimo jiné po vyšší rychlosti. Dynamická kompilace je jedním z cest. Souhlasím, že vývoj dynamické kompilace určitě ještě poběží, ale vývoj statické kompilace také. Koneckonců všechny operační systémy, všechny runtimy pro Javu, .NET, spousta knihoven, apod.. bude stále psaná přednostně v jazycích typu asm, C, C++, apod..

Konečným cílem obojího je totéž. Dosáhnout rychlého běhu ve strojovém kódu. Tedy v konečném cíli se to k sobě přibližuje. Dynamická kompilace samořejmě bude mít navrch, pokud nebude staticky kompilovaný program zkompilován pro daný procesor. Abych řekl pravdu, dost dobře si nedokážu představit případ, kdy by kvůli datům byla Java nějak rychlejší, než C++.

Co se týká testů, je tam testováno mnoho programů. Budu to brát jedno po druhém. První bude čas C++, druhé čas Javy. Čím menší číslo, tím je program rychlejší. Vybral jsem programy, kde se testovalo Visual C a Java společně, což taky nebylo všude.

1) 0.05, 0.53
2) 0.46, 1.60
3) 0.07, 3.93
4) 0.62, 2.55
5) 0.11, 0.76
6) 0.12, 2.89
7) 0.04, 0.55
8) 1.03, 0.76
9) 0.10, 0.90
10) 0.32, 9.65
11) 0.84, 2.92
12) 0.02, 0.48
13) 0.32, 9.65
14) 0.02, 0.48
15) 0.60, 3.92
16) 0.06, 0.62
17) 0.19, 0.62
18) 2.08, 2.85
19) 1.04, 86.59
20) 0.07, 0.72
21) 0.01, 0.75
22) 0.16, 1.18
23) 0.46, 1.87
24) 0.89, 2.55

Tedy téměř všude jsou výsledky dost podstatně horší pro Javu, než pro C/C++ z hlediska rychlosti. S výjimkou program číslo 8 - Object Instantiation. Po skouknutí testovaných zdrojáků pro C a pro Javu jsem ale zjistil, že nedělají totéž, takže jsem toto měření nebral v úvahu.

Když jsem chtěl skouknout metodologii, naskočila chyba 404. Mám podezření, že do běhu programu započítávají i dobu natažení programu, což by zase mírně zvýhodňovalo C++ a mírně znevýhodňovalo Javu. Ale protože metodologie nebyla dostupná, je to jenom moje domněnka.

Zároveň naprosto nechápu, jak v některých pokusech mohli dosáhnout rozdílných výsledků pro C a C++, a to tak, že C++ je dost pomalejší. Co se dá napsat v C, se totiž dá napsat stejně i v C++. Pak se to zvrhává nikoli v testování jazyků, ale v testování objektovosti/neobjektovosti. A nebo v to, že někdo program v C++ neumí napsat.

Nechci odsuzovat ani C++, ani Javu. Ani jiné jazyky. Jen má každý jazyk své určení a svou oblast, kde může ukázat nejpřívětivější tvář. A rychlost není nejsilnější stránkou Javu.

A jen tak mimochodem, zajímavé bylo, že .NET byly velmi výrazně v testech rychlejší, než Java.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Richard  |  10. 09. 2003 11:28  | 

ad 1) Tak ci tak nebude v C++ nikdo vytvarat rozsiahlu firemnu aplikaciu. A keby aj, tak neverim, ze by bola principialne rychlejsia ako .NET alebo JAVA

ad 2) .NET a JAVA maju podobnu technologiu (a ked no nie je to iste) a vykonostne su velmi podobne (prakticky je vykon rovnaky)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  10. 09. 2003 17:20  | 

Richarde dekuji ze si mi ujasnil na cem to vlastne v praci delam. A to ze je prakticky vykon rovnaky - ja sem si delal testy a identicky kod, na identickym zeleze, vcetne pristupu do databaze (ktera IMHO nehraje takovou roli jak ji vsichni davate, pokud pouzivate MySQL tak to bude pomaly, ale poradny databaze nejsou pokud je dokazete poradne navrhnout) byl primitivni Tomcat (predpokladam ze WebLogic by byl jeste pomalejsi) schopnej servirovat asi 1/3 toho co IIS s .Net kodem. Mozna tobe to prijde jako prakticky rovnaky vykon, ale mne ne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Radim  |  10. 09. 2003 11:33  | 

Ad 2 - Na .NET pochopitelne bezi NATIVNI kod. Aplikace po vytvoreni je sice zkompilovana v mezikodu, ale pri behu je uz zkompilovana do nativniho kodu, nejde o zadny interpret, jak by se snad nekdo mohl mylne domnivat. Moznosti, kdy dojde ke kompilaci do nativniho kodu, je na .NET vic, ale pri behu aplikace jiz vzdy jde o nativni kod.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Richard  |  10. 09. 2003 17:16  | 

Ved to iste robi JAVA ! Pri behu je zkompilovana do nativneho kodu. Co myslis odkial to MS odkukal ???

Dnes sa tu teda zisli znalci :(

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dan M.  |  10. 09. 2003 20:49  | 

A není to náhodou tak, že .NET je přeložen ze MSIL do nativního kódu, pod kterým pak běží celou dobu a to narozdíl od javy, která celou dobu využívá služeb virtual machine? Skutečně věřim, že MS tuhle brzdu neokoukal.

DaM

Souhlasím  |  Nesouhlasím  |  Odpovědět
meno  |  10. 09. 2003 15:25  | 

Java je fakt pomalá, na serverový i klientský straně, navíc nejrychlejší implementace Javy je na Windows, kde nemá oproti ASP.NET žádnou výhodu.

Ale největší výkonnostní problém Javy je způsob, jakým parsuje a zpracovává scriptlety. Od toho rovnou pryč....

Souhlasím  |  Nesouhlasím  |  Odpovědět
Salvador Limonez  |  10. 09. 2003 17:28  | 

Co se ti nelibi na tom, ze z nich vygeneruje zdrojaky servletu ktere zkompiluje? Jak si myslil, ze to dela MS?

Souhlasím  |  Nesouhlasím  |  Odpovědět
RS  |  10. 09. 2003 07:05  | 

Oba výzkumy jsou součástí nové strategie společnosti Microsoft, která místo kontraproduktivního agresivního postupu vůči Linuxu zvolila přesvědčovací kampaň založenou na faktech...a na síle peněz.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Milan Křepelka  |  10. 09. 2003 07:48  | 

Hmm, osobne se mi .NET technologie libi, ale studiim, ve kterych vyhraje zadavatel, se preci neda moc verit. Alespon podle meho H nazoru . Aneb zdravim Jezevce.

Souhlasím  |  Nesouhlasím  |  Odpovědět
fettgesicht  |  10. 09. 2003 07:52  | 

A vůbec, kde je IMHO Jezevec?

Souhlasím  |  Nesouhlasím  |  Odpovědět
renik  |  10. 09. 2003 08:06  | 

IMHO je uz dnes vybitej, protoze v jedne diskuzi pouzil BTW.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Rudidlo  |  10. 09. 2003 08:27  | 

Tak to je mi ho IMHO líto

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jarry  |  10. 09. 2003 08:16  | 

"Důvodem, proč se pracovníci Giga Research srovnáním s MySQL a PHP nezabývali je fakt, že tyto prostředky nepoužívá ani jedna z pěti „linuxových“ společností, které sloužily jako vzor pro případovou studii."

Myslim, ze na takyto argument skoda vobec nejako reagovat. Je to jednoducho neobjektivna a tendencna studia. Asi kazdemu je jasne, ze vysledky ani nemohli byt ine: vsak zaplatil si to Microsoft. Ale asi sa pani z Giga Research museli dobre snazit, kym nasli tych 5 (az tolko?) firiem, ktore vdaka svojej hluposti nakupili drahe linuxove riesenia (hoci mohli mat porovnatelne zadarmo) a teraz nariekaju...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Salvador Limonez  |  10. 09. 2003 15:50  | 

Tady se mluvi o portalech. Trochu jina liga.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vlasta  |  10. 09. 2003 23:20  | 

Jenom bych rozvedl to o tech portalech... Dulezita na aplikaci neni jenom jeji rychlost, ale take znovupouzitelnost kodu, moznost jednoduche spravy a uprav kodu apod.... jinymi slovy je dobre pouzivat neco jako 3 vrstvovou architekturu, MVC apod. proste oddelit logiku od view  a od databaze. S PHPkem se na tohle asi nechytas... Dalsi vec ktera myslim nebyla zminena je to ze je dulezite aby byl co nejmensi cas mezi analyzou a hotovym produktem a pro tohle je myslim idealni Java, pripadne C#.

Jinak mam pocit ze puvodni knihovny javy byly v C nebo C++  a ted se diky rychlosti prepisuji do javy...

S pozdravem

Souhlasím  |  Nesouhlasím  |  Odpovědět
Karel Vales  |  10. 09. 2003 08:25  | 

Microsoftem zaplacený případová studie ukazuje....

Vloudila se chybicka, spravne melo byt "Microsoftem zaplacený pan Případová Studie ukazuje..."

Souhlasím  |  Nesouhlasím  |  Odpovědět
kk  |  10. 09. 2003 08:39  | 

To je zase narez
MS sponzoruje nejakou studii a my se mame divit, ze v ni vyhraje
Prosimvas, tohle uz radsi ani nezverejnujte, protoze je to smesne...
Samozrejme vybrali to co se jim hodi
Kdyz nedelam neco velkeho - nepouziji BEA server, ale napr. Tomcat, pripadne PHP .... Pak jsou ceny uplne nekde jinde....
Jezismarja, to je neco...

Souhlasím  |  Nesouhlasím  |  Odpovědět
akela  |  10. 09. 2003 08:57  | 

Necudujem sa, ze ani jedna z firiem nepouzivala prave toto spojenie.
PHP sa stale este len snazi dostat do enterprise firiem. Ale urcite to nebude v spojitosti s MySQL. MySQL je v tomto pripade dost brzda pre PHP. Mozno sa PHP podari presadit prave 5-kovou verziou. V sucastnosti badat odkolon od MySQL, ktora prestava stacit pre stredne firmi. Pre enterprise firmy je uplne nepouzitelna. Mozno aj preto vzrasta obluba PostgreSQL, ktora je velmi casto porovnavana s Oracle. V kazdom pripade drzim PHP palce.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Ivan  |  10. 09. 2003 09:40  | 

PostgreSQL bych s Oracle nesrovnval, obe databaze maj odlisnej transakcni model. PostgreSQL bych srovnaval spis se Sybase nebo MSSQL
vzdyt maj vsechny tri stejnyho predka.


Ivan

Souhlasím  |  Nesouhlasím  |  Odpovědět
tomik  |  10. 09. 2003 10:12  | 

Já bych to klidně srovnával. Tomu kdo má za úkol vybrat prostředí ve kterém se něco bude vyvíjet musí být srdečně jedno, jaký má transakční model, důležité je aby to vyhovovalo jeho požadavkům.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Kotek  |  10. 09. 2003 12:55  | 

He? Kteryho? Co vim, tak Sybase byla navrzena od piky (Virtual server architecture...). Dokonce v prvnich verzich nepotrebovala zadny OS - bezela na cistem zeleze. Pote Sybase udelala svou nejvetsi chybu a prodala licenci sveho kodu MS. A co MS uchvati... to vyviji dal a po svem takze mame vedle Sybase SQL (ASE) take MS SQL.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Richard  |  10. 09. 2003 10:09  | 

Ked staci MySQL pre YAHOO alebo GOOGLE, tak pre ake velke firmy nestaci ??

Souhlasím  |  Nesouhlasím  |  Odpovědět
xX  |  10. 09. 2003 10:35  | 

MySQL zdaleka neobsahuje vsechnu funkcionalitu Oracle, nemluve o tom ze spoustu dalsich komercnich produktu je delanych primo na oracle. Takze nekdy je Oracle proste nutnost.

Souhlasím  |  Nesouhlasím  |  Odpovědět
meno  |  10. 09. 2003 15:27  | 

Google běží na MySQL.. ?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Dan M.  |  10. 09. 2003 20:54  | 

Cože  Google používá MySQL ? Já doteď myslel, že jede nad nějakou databází  I když třeba si vystačí s pouhou sadou tabulek

DaM

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 14:15  | 

To je trochu mimo, ne? Co Vám brání používat jiné databáze, třeba i tu Vámi uváděnou PostgreSQL v PHP verzi 3, nebo 4? Vůbec nic!!!

PHP je prostě určená na jednodušší řešení, to je její určení. A vůbec to není žádnou MySQL, to s tím nemá nic společného.

Prostě koncepce, nebo spíše nekoncepčnost PHP je taková, že ani ve verzi 5 nebude mít velký vliv na enterprise segment.

Mimochodem, jsem zvědav, kdy standardní součástí PHP bude kompilátor do binárního tvaru a alespoň jednoduchý debugger, to jest základní věcí, které dnes mají prakticky i ty nejzaostalejší interpretované jazyky jako základní součást.

PHP je záměrně ořezáváno kvůli komerčnímu podnikání autorů. Pak se není co divit.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Akela  |  10. 09. 2003 15:07  | 

Nesuhlasim. Myslim, ze ludia si prilis casto spajali PHP s MySQL, kvoli ich jednoduchosti. Podla mna nieje dolezite, ci ma dany nastoj debuger alebo nie. Napriklad ked pisete web aplikacie v Oracle v PL/SQL tak tiez nemate debuger a musite si premenne vypisovat na obrazovku. Co sa tyka kompilovania staci si stiahnut kniznicu php_bcompiler.dll pripadne *.so. PL/SQL je na urovni pascalu ci basicu. To znamena ziadne OOP. Ide skor o doveru v technologie. Napriklad PHP ma velmi caste releasy, ci nie velmi prospieva prave enterprise systemom.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Miloslav Ponkrác  |  10. 09. 2003 15:42  | 

Pokud máte pocit, že hlavním problémem PHP je, že lidé spojují PHP s MySQL, pak Vás uklidním, protože v takovém případě jto bude naprosto stejné i v PHP verze 5 a i nadále bude PHP používáno mohutně s MySQL databází tak, jako předtím.

Ad debugger. Ano, bez debuggeru se v nejhorším případě obejdu, ale s ním může být práce daleko příjemnější, a mnohdy efektivnější. Debugger toho dokáže víc, než jen výpis proměnných.

Ad kompiler, proč nekompiluje základní balík? Na stránkách autora jsem našel, že jde o EXPERIMENTÁLNÍ projekt v současné verzi 0.5. Tedy nic, co by se dalo doporučit pro vážné projekty. Navíc píšou, že je to jen pro třídy.

PHP má časté releasy, ale taky nekoncepční strukturu. Nikdo vlastně neví, kam PHP míří, co je jeho prioritou, kromě toho, že je to jako když pejsek s kočičkou vařili dort.

Souhlasím  |  Nesouhlasím  |  Odpovědět
t.t.  |  10. 09. 2003 09:19  | 

Aj ja si chcem zalozit firmu, kde za par melonikov zistim, pre hocikoho, ze existuju pripady, v ktorych je ich riesenie lepsie ako hocijake ine hocikoho ineho.. Pliz... MS, alebo aj hocikto iny... ozvite sa do mailu.. (Uz ma nebavi chodit do prace a programovat za par kSk)...

 

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan  |  10. 09. 2003 10:15  | 

Nechapu proc se Zive snizuje k publikaci takovych reklamnich letaku z dilny MS a jejich ocasku. VZDY se da ohnout studie tak aby vyslo to reseni, ktere si zadavatel objednal. Pokud spoctu vsechny naklady spojene s vyvojem na dotNet a SunONE nemuze nikdy vyjit Malymekky levneji :) Ale coz ... kdyz rozhoduje ve firme management, ktery byl na rautu Mrkvosofta pak je asi jasne pro koho lobuji. Blby je pak ze to vsichni uzivatele co si kupuji predrazene licence zatahnou. Ale to je jejich volba ze ;)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tomáš Holčík  |  10. 09. 2003 13:57  | 

Ale vždyť to v tom článku je moc dobře napsané.  Stejně kriticky bereme i třeba obrácené studie, tvrdící třeba, že Linux je výhodnější. Nemáme zkreslenou optiku. Jo a mimochodem, včera jsme s Otou skutečně na rautu Microsoftu byli, to jen tak na okraj

Souhlasím  |  Nesouhlasím  |  Odpovědět
Otakar Schon  |  10. 09. 2003 14:15  | 

Dekuji ti, nacelniku, ze ses me zastal (To je na tomase, ktery ma vzacny talent odpoviat do diskusi drive, nez ja).

Cos e tyka vasich vytek, musim se stejne ohradit. Naprosto s vami souhlasim - pokud dobre zadam predmet studie, na 95 procent dostanu presne ty vysledky, ktere chci. To vime vsichni, vi to i microsoft. A vi to i Forrester Research - jejich vice president to v podstate sam priznal a v textu clanku to najdete. Nejsem vyvojar a tudiz nedokazu porovnat ani naklady ani naroznost prace v prostredi .Net a JavaOne, ale rozhodne vim, ze designovani web portalu v MS SharePoint Portal Serveru je velice rychle a efektivni - opet zvlastni, ze tento produkt studie nezminuje.

Jinka na oslavach 20 let mysky snad ani management nebyl, jen my, pesaci. A jestli vas to uklidni, tak svou Smirnoff Ice jsem si zaplatil sam. Stala 95 Kc a moc mi chutnala :)

 

A pokud mate pocit, ze ve svych clancich lobbuji za MS, doporucuji vam podivat s ena prehled mych clanku a porovnat. co tam najdete.

Souhlasím  |  Nesouhlasím  |  Odpovědět
t.  |  12. 09. 2003 16:57  | 

s placenymi vyzkumy je to imo osemetne. vetsina renomovanych firem - a giga mezi ne rozhodne patri - si da sakra pozor, aby vysledky sveho vyzkumu nejak zkreslily ci zatizily vedomou preselekci ucastniku nebo necim podobnym. na druhe strane pokud je zadani vhodne formulovano (o cemz v pripade komercniho projektu, zejmena pokud je zadavatelem takovy marketingove ostrileny hrac jako je microsoft, nepochybuji), tak i seriozni firma velmi pravdepodobne dojde ke "spravnemu" vysledku.

resume - tak jak je presentovano i zde na zive.cz - je jednoduche: existuji problemy, pro ktere je ms technologie vhodnejsi, nez konkurencni zkoumana. to nic nerika o kvalite ani jedne, ani druhe. vsechno ostatni, co se na to nabali, je uz jen prace marketeru - a ty ma microsoft (jak je videt z jeho vysledku) jedny z nejlepsich ...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin Povolny  |  10. 09. 2003 10:56  | 

Microsoft VBScript runtime error '800a000d'

Type mismatch: 'UPTIME'

/_Includes/Cache_INC.asp, line 55

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tom  |  10. 09. 2003 12:20  | 

nebo

Microsoft OLE DB Provider for SQL Server error '80004005'

[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.

/mod_ListOfArticles/ListOfArticlesTITLE_INC.asp, line 45

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jakub  |  10. 09. 2003 14:18  | 

MS technologie nebo aplikace ktera MS technologii pouziva? Kdyz napisu prasackej kod na jakoukoliv technologii tak nebudu ocekavat ze to bude fungovat na 100%.

Souhlasím  |  Nesouhlasím  |  Odpovědět
JT  |  10. 09. 2003 23:28  | 

No jo, ale kdyz Vam chcipne server,
(viz asi pripad vyse)
tak sebelepsi kod to nevytrhne.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  12. 09. 2003 09:04  | 

Lepsi kod da pristupy do databaze do try bloku a zobrazi normalni chybovy hlaseni pokud chcipne server (nebo cokoli). Zive sou bastliri...

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin Povolny  |  12. 09. 2003 12:52  | 

No ja tyto chyby vidivam na ZIVE, IDNES a na novem e-shopu MIRONETu
vsechno z meho pohledu ne nevyznamne servery a zaroven jedny z mala
co navstevuju bezici na widlich.

Takze se mi nabizi dva mozne zavery:
1) IDNES, ZIVE i MIRONET jsou neschopni zabari
2) technologie MS nestoji ani za zlamanou gresli

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jerry III  |  13. 09. 2003 07:59  | 

Ty ses fakt dement. ASP (i .Net) tohle osetrit umi. Neni to dokonce ani nic tezkyho. Jestli tomu neveris tak tomu never, a najdi si proto milion ruznejch duvodu. V kazdym pripade to znamena ze "programatori" tech tri tebou zminenych serveru sou zabari, osobne to vidim na deti budto porad ve skole nebo v jejich prvni praci po skole. Tohle sou detsky chyby (kdo ve svym prvnim programu poradne osetroval vsechny chyby, ze), ktery dobri koderi s praxi proste nedelaj. Ale ti taky "neprogramujou" redakcni systemy v CR, natoz prezentace firem (BTW neni Mironet ta firma co je silne proti Microsoftu?). Jestli ma Zive trochu odvahy at sem postnou kus kodu, klidne ti to okomentuju co kde delaj mizerne ;)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin Povolny  |  13. 09. 2003 10:50  | 

Mily Jerry III,
nevim, proc jsi presel na uroven osobnich urazek.

Ale abych shrnul posloupnost uvah:
0. zive a dalsi ceske weby na MS casto vraci chybova hlaseni
1. napsal jsem 2 mozna vysvetleni
2. naznacil jsem, ze jedno mi pripada pravdepodobnejsi
3. ty si myslis (**vis**), ze je pravdepodobnejsi to druhe
4. z toho jsi dostal (implikaci?), ze ja jsem dement

No, muj zaver je, ze jsi hlupak a sprostak

Souhlasím  |  Nesouhlasím  |  Odpovědět
t.  |  12. 09. 2003 16:59  | 

posunuto jen o jednu uroven "niz" - kdyz kdyz prasacky nakonfiguruju jakykoliv server, tak nebudu ocekavat ze to bude fungovat na 100%.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Martin Povolny  |  12. 09. 2003 20:33  | 

Vase uvaha je chybna.

Jestlize navstevuji 3 servery na MS a na 3 z nich maji problemy
mohu z toho neco usuzovat.

Ted jsem si vzpomnel jeste na dalsi: mapy.atlas.cz, ale tam jsem
uz podobnou hlasku videl taky.

Souhlasím  |  Nesouhlasím  |  Odpovědět
tomas  |  10. 09. 2003 11:12  | 

Myslim, ze jste v clanku ignoroval jednu dulezitou vec. Giga Research porovnaval Microsoft NET versus Oracle a BEA. Je pravdou, ze lze porovnavat MySQL a Oracle (oba jsou databazove servery), ale nelze porovnavat PHP a BEA aplikacni server. Proti BEA aplikacnimu serveru existuje aplikacni server JBoss. PHP je programovaci jazyk, Java je programovaci jazyk, BEA a JBoss jsou plikacni servery.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Richard  |  10. 09. 2003 11:33  | 

To je fakt. Cele to bolo vedene tendencne ako MS a NET vs Linux a JAVA:

1. JAVA vobec nemusi bezat nad Linuxom
2. Oproti MSSQL mozem pouzit aj lacnejsie databazy ako Oracle
3. Tie mozem pouzit lacnejsi AS ako BEA

Tiez pocet porovnavani bol prilis maly (5), vzhladom na to, ze teraz sa vacsina serverovych aplikacii pise v JAVA

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Kotek  |  10. 09. 2003 13:00  | 

Plus se nikde nic nerika o portalovem SW. Slo o portaly vyvijene na kolene nebo byl pouzit nejaky portalovy framework? A jaky - MS ma SharePoint, ale na Oracle DB a v BEA app serveru muze bezet Oracle Portal, BEA Portal, Sybase Portal... (vsechny jsou J2EE aplikace). Skutecne solidni portalovy framework muzu sehnat od 170.000 KORUN na CPU vcetne databaze a aplikacniho serveru, nemluve o velmi kvalitnich OpenSource variantach.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Jan Kotek  |  10. 09. 2003 13:00  | 

Plus se nikde nic nerika o portalovem SW. Slo o portaly vyvijene na kolene nebo byl pouzit nejaky portalovy framework? A jaky - MS ma SharePoint, ale na Oracle DB a v BEA app serveru muze bezet Oracle Portal, BEA Portal, Sybase Portal... (vsechny jsou J2EE aplikace). Skutecne solidni portalovy framework muzu sehnat od 170.000 KORUN na CPU vcetne databaze a aplikacniho serveru (mňau), nemluve o velmi kvalitnich OpenSource variantach.

Souhlasím  |  Nesouhlasím  |  Odpovědět
vp  |  10. 09. 2003 17:22  | 

"2. Oproti MSSQL mozem pouzit aj lacnejsie databazy ako Oracle" ... zaujimave ... MS SQL(ktore?) je drahsie ako Oracle(ktore?)?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Mach  |  11. 09. 2003 20:18  | 

ako != jako
ako == nez

Takze si to precti znova a snad to pochopis

Souhlasím  |  Nesouhlasím  |  Odpovědět
Vita  |  13. 09. 2003 05:42  | 

A to druhe je true nebo false? Ma tam byt jedno rovnitko, ne?

Souhlasím  |  Nesouhlasím  |  Odpovědět
Salvador Limonez  |  10. 09. 2003 16:27  | 

Mozna vas pobavim svyma soucasnyma zkusenostma s j2ee produkty firmy Oracle. Zatim jedine reseni pro Linux zahrnujici portal je Oracle AS 9i 9.0.2 Jde o sracku neumejici ani j2ee 1.3. (Lidi vi o co jde jiste pobavi treba fakt, ze to neumi ani local interfejsy) Tato technologicka zkamenelina (a to jeste uvintr tika licencovany Orion ktery Oracle ani nedelali, jen to zkurwili a oblepili nalepkama Oracle) neni schopna korktne bezet ani na zeleze s 1GB pameti bez toho aby se na ni dala korektne deploynout aplikace. Je nutno prvne postrilet vetsinu komponent, deploynout a pak zase je nahodit. Obcas se stane, ze pri vyhozeni vyjimky v Session beanu ji tise sezere a vrati klientovi null. A na zaver vas uz jen naseru tim, ze jste za tohle zaplatili svymi danemi. Dokonce ted kdyz tohle pisu cinim tak jen diky tomu, ze deployment trva asi pet minut a uz jsem prekoureny.

Souhlasím  |  Nesouhlasím  |  Odpovědět
zdenda (nebo take tsunami)  |  10. 09. 2003 16:44  | 

salvadore, nedelej z zive dalsi popelnici

Souhlasím  |  Nesouhlasím  |  Odpovědět
Salvador Limonez  |  10. 09. 2003 17:12  | 

Vzdyt jsem nepouzil ani jedno sproste slovo a dokonce ani obrazek pohlavne zneuzivaneho leguana nepripojil.

Souhlasím  |  Nesouhlasím  |  Odpovědět
regent  |  10. 09. 2003 12:20  | 

Hodnotí nabízenou cenu nebo koncovou. Zadali jsme vývoj intranetového portálu s předběžným rozpočtem 2,5 mil a měl být hotov za 1/2 roku. Dodnes není dořešen a už stojí o půl miliónu víc. Předběžný odhad koncové ceny už vychází o 30% vyšší.

Obdobně vyskakují ceny i u jiných projektů a nebo se projekt zastavuje.

Cau.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Tonda  |  10. 09. 2003 14:49  | 
radek cervinka  |  10. 09. 2003 18:23  | 

Ja jsem zastancem pro male reseni Myslq+Php, pro vetsi Kylix + libovolny sql server (treba firebird). Vysledny kod z Kylixe je nativni kod, navic primo jako samostantny modul pro Apache. Co chcete vic. Navic je tam vynikajici podpora pro webove programovani (samozrejme take RAD). Ale samozrejme nemusite pouzit RAD .

Onehda jsem o tom psal na rootu.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Zasílat názory e-mailem: Zasílat názory Můj názor
Aktuální číslo časopisu Computer

Megatest: 20 powerbank s USB-C

Test: mobily do 3 500 Kč

Radíme s výběrem routeru

Tipy na nejlepší vánoční dárky