Patří budoucnost kromě aluminia také Javě?

29.9.2007 13:27 | Přečteno: 1807× | Programování

Hned na začátku přiznávám, že nejsem žádný zkušený programátor - až asi na jednu výjimku jsem nikdy jsem nepřekročil hranice domácího bastlířství. Čas od času se začtu do vyjadřovaných zkušeností těch pokročilejších a v téhle souvislosti bych se rád zeptal na jednu věc, které bych moc rád přišel na kloub: kde se bere ta neutuchající kritika Javy?

Jestli tomu dobře rozumím, tak programátoři se v zásadě dělí na ty, kteří...

• programují operační systémy, drivery, knihovny a podobné věci, kde hodně záleží na rychlosti
• využívají práce těch předešlých a sestavují aplikace, kde se po většinu času počítač fláká, čekajíc na uživatelův vstup

Pokud se chci orientovat do té druhé skupiny (mám subjektivní pocit, že poptávka právě po ní by měla být větší), zdá se mi, že jazyk překládaný do bytecodu, rozumně zjednodušený a vybavený garbage collectorem, je pro ně lepší volbou z následujících důvodů:

• multiplatformní výsledky
• kratší doba návrhu
• s rozšiřováním stále nabouchanějších počítačů, klesá handicap větších nároků na strojový čas a paměť. Navíc ten rychlostní rozdíl se zdá dost zanedbatelný.

Ta multiplatformost mi přijde jako docela silný argument, který musí s přehledem přebýt argument nějakých elegantních vychytávek platformy NET. Celkově mi přijde, že je pro tuto oblast budoucnost v nějakém standartizovaném společném virtuálním stroji, do jehož bytecodu budou mít všechny slušnější jazyky možnost překladu - a této myšlence je virtuální stroj Javy zřejmě právě nejblíž. Na nedávném blogu však přesto zazněla slova "menší zlo", "obloukem vyhni". Dříve jsem si podobná odmítání spojoval s tím, že se nejednalo o otevřený sw, ale i tato námitka teď padla.

Předem děkuji případným lidem, kteří nebudou litovat času na vyvrácení, poopravení, nebo potvrzení mých názorů.

       

Komentáře

[Luboš Doležel (Doli)]

Jenže ten výkonnostní rozdíl není vůbec zanedbatelný a je mi jedno, co říká nějaká analýza. Javové GUI aplikace jsou něco tak nechutně pomalého, že se to nedá vydržet.

[jalinh]

Jestli to opravdu všechno leží jen na té rychlosti (jak se mohu domnívat z vašeho příspěvku), tak se to časem umlátí silou HW. Dnes už přece také nikdo nemá potřebu vyvíjet hratelné gamesky do pamětí řádů kB a procesorů typu Z80, ne?

[kyknos]

Já nevím, nemám nijak slabý počítač a přesto (s výjimkou textového editoru) snad na každou aplikaci občas nebo dokonce často čekám. A to se javovým aplikacím vyhýbám jako farář prezervativu. V některých oblastech (grafika...) asi výkonu nebude nikdy nazbyt.

[multi]

farář to bere na ostro?

[Lukáš Zapletal]

faráři jedině maso na maso

[atan]

Kdyby Javu zakazali, tak spotreba elektriny celosvetove klesna aspon o 10%.

[Lukáš Zapletal]

Kdyby abíčko umělo sémanticky rozeznat, který příspěvek je jen text někoho, kdo si ani pořádně nepřečetl původní zápisek a odkazy v něm a přístup takovýmto lidem by ábíčko zakázalo, pak by bylo hnedka veselejc.

Java je dneska ve složitých výpočtech stejně rychlá jako C++. Výkonostní rozdíly jsou zanedbatelné, ať už je v konkrétním případě Java pomalejší nebo rychlejší, a programátor by měl raději upřednostňovat rychlost vývoje.

Nastartování programu v Javě je pomalejší z důvodů nahrávání knihoven. U serverů je toto nerelevantní, u desktopu se to momentálně řeší a situace se zlepšuje s každou novou verzí. Mnoho rozsáhlých programů se totiž dělá v Javě (proč asi?), velký program = pomalý start. V Javě 6 nastartuje notepad v mžiku.

Swing mívá pomalejší odezvy. Někteří uživatelé pamatující staré Java 1.1 programy na Javu na desktopu zanevřeli, ale situace se opět zlepšuje. Swing není jediná možnost, jak dělat tlustého klienta.

[Kyosuke]

Java je dneska ve složitých výpočtech stejně rychlá jako C++. Výkonostní rozdíly jsou zanedbatelné, ať už je v konkrétním případě Java pomalejší nebo rychlejší, a programátor by měl raději upřednostňovat rychlost vývoje.

Ano, a proto Peter Norvig prohlašuje, že výkon Javy je žalostný i v 21. století? Proč tedy Google na ty složité výpočty používá kombinaci C++ a Pythonu a ne Javu?

[Lukáš Zapletal]

Proč banka XY má určitý systém napsanej v COBOLu? No asi proto, že když něco funguje dobře, není důvod to měnit. Tady jde o pochopení toho, že kdyby se to (dneska) napsalo v Javě, fungovalo by to stejně rychlé. A že se snad píší systémy i v něčem jiném, než je Java, je přirozené. To nelze brát jako argument.

Jsou benchmarky, které dělají céčkaři, lispáci, jsou i takové, které dělají javisti. A jsou dobře zpracované benchmarky a špatně. Ten od Petera Norviga odkazuje na srovnání od céčkaře. Povšimněte si, kolik úsilí věnoval autor optimalizačním parametrům pro C++ (g++ -c -pipe -O3 -fomit-frame-pointer -march=pentium4 binarytrees.gpp-2.c++ ...) a kolik pro Javu (způsob překladu autor vůbec neuvádí - jaký byl cílový bytecode? stripnul debug informace? jaký použil překladač? způsob spouštění: java $JDKFLAGS -server -Xbatch). Nemluvě o tom, že tihle autoři znají akorát sunovskou Javu...

[Kyosuke]

Que? Nemohu na Norvigově stránce najít žádné "gpp-2". A Norvig, ten určitě není céckař, ani omylem. To dává asi takový smysl, jako tvrdit, že Andrei Alexandrescu je lisper.

[Lukáš Zapletal]

Dobře není céčkař, ale Javě moc asi nerozumí, nebo jí nevěnoval patřičnou pozornost úmyslně.

[Miloslav Ponkrác]

Tady jde o pochopení toho, že kdyby se to (dneska) napsalo v Javě, fungovalo by to stejně rychlé. A že se snad píší systémy i v něčem jiném, než je Java, je přirozené. To nelze brát jako argument.

Hezká demagogie. Nevím kolik má google serverů, ale je jich hodně. Jediné, čím jsem si naprosto jistý, že pokud vyhodí C++ jádro za Java jádro - bude těch serverů potřebovat daleko více - a vzhledem k tomu, že dnes už spotřebovávají opravdu hodně proudu, Java by jim neposloužila. Stejně tak argument, že v něčem jiném to bude stejně rychlé jako v Javě je demagogie nejhrubšího zrna.

Povšimněte si, kolik úsilí věnoval autor optimalizačním parametrům pro C++ (g++ -c -pipe -O3 -fomit-frame-pointer -march=pentium4 binarytrees.gpp-2.c++ ...) a kolik pro Javu (způsob překladu autor vůbec neuvádí - jaký byl cílový bytecode?

Neznám ten benchmark a ani ho nebudu hledat, neboť již těch málo informací co jste dal znamená, že ten benchmark pro C++ byl proveden špatně. g++ je velmi mizerně optimalizující kompilátor, a můžete nacvakávat parametry pro g++ jaké chcete. Ale jakmile někdo pro srovnávací benchmark použije g++ - je to diletant. Pokud by se použil Intel, či Microsoft kompilátor - i bez nějakého hraní si s optimalizačními parametry by dostal velmi výrazně rychlejší kód, než ten nejlepší možný z g++ i poté, co jste si dva měsíce hráli s optimalizací g++. Proto také jsem nikde v komerční praxi neviděl benchmarky pro programy postavené na g++ na rozdíl od různých diletantských testů - vždy se testovalo v 99% na Intelu, občas na Microsoftu.

[Lukáš Zapletal]

A proč by ta Java jakože neměla posloužit? Tohle je imho demagogie

Já mám za to, že g++ generuje docela kvalitní kód téměř na úrovni Intelu nebo microsoftího překladače. Byly by nějaké zdroje, docela mě to zajímá...

[Miloslav Ponkrác]

Já mám za to, že g++ generuje docela kvalitní kód téměř na úrovni Intelu nebo microsoftího překladače.

No to máte dost mylné informace. I nejnovější g++ a super zoptimalizovaný kód přeložený g++ generuje velmi výrazně horší a pomalejší kód, než Microsoft Vistual Studio 6 z roku tuším 1996 bez jakéhokoli nastavování optimalizačních parametrů. A Intel kompilátor to oproti Microsoftu dokáže zrychlit ten kód ještě až o dalších 10-15%.

gcc/g++ je velmi mizerný z hlediska optimalizace. Jejich význam je jiný - prostě gcc/g++ dává standardní prostředí pro řadu platforem v rámci gnu projektu. Ale rychlost výsledného kódu tedy rozhodně není jeho silnou stránkou.

[Luk]

I nejnovější g++ a super zoptimalizovaný kód přeložený g++ generuje velmi výrazně horší a pomalejší kód, než Microsoft Vistual Studio 6 z roku tuším 1996 bez jakéhokoli nastavování optimalizačních parametrů.

Vzpomínám na jeden výpočetně orientovaný program v C++. Zkusil jsem ho zkompilovat (vždy s maximální optimalizací) na MSVC++ a na g++. Microsoftím kompilátorem zkompilovaný program byl o cca 7 % rychlejší.

[MJ]

Nějaký konkrétní příklad? Před časem jsem si s ICC hrál a rozdíly jsem pozoroval minimální (tedy pokud se kompilovalo pro Intel, pro AMD generoval intelovský překladač kód výrazně horší než GCC).

[Miloslav Ponkrác]

Tak to jste asi jediný na světě, kdo tohle pozoruje.

[MJ]

Neptal jsem se Vás na důkaz své jedinečnosti, nýbrž na nějaký konkrétní příklad

Pokud je to tak, jak říkáte, měla by jich být spousta, a tedy by pro Vás mělo být snadné vybrat nějaký jeden konkrétní. Nebo snad jsem jediný na světě, komu nestačí velkohubá obecná tvrzení a chtěl by důkaz?

[Miloslav Ponkrác]

A proč by ta Java jakože neměla posloužit? Tohle je imho demagogie

Java sloužit bude. Asi tak jako třeba sandál jde taky použít jako kladivo, když na to přijde. Ale vyhledávací engine google v Javě - to by konkurence google velmi zajásala.

[Radek Miček]

Java je dneska ve složitých výpočtech stejně rychlá jako C++.

Tak tomu snad sám nevěříte... Docela by mne zajímalo, jak jste na to přišel. Z osobních zkušeností si jsem naprosto jist, že ve složitých výpočtech je Java pomalejší.

Například, když pracuji s neuronovými sítěmi, tak jsem první implementaci projektu napsal v C, trénování sítě trvalo mezi 20-21 hodinami, následně jsem chtěl s kódem trochu experimentovat, což se mi s céčkovou implementací zdálo nepohodlné, tak jsem kód přepsal do Javy a doprogramoval nějaká rychlostní vylepšení - dnes mi Javová aplikace seběhne v čase většinou o půl hodiny pomalejším.

Tu samou zkušenost mám s kompresními algoritmy, kterým se dnes sice až tak nevěnuji, ale opět třeba Range kodér s modelem řádu nula byl v C++ vždy znatelně rychlejší, než stejná implementace v C# v .NET Frameworku 1.1 a později i 2.0 ve Windows.

Musím však uznat, že co se pohodlí týká, tak Java a C# vedou nad C a C++, ale to asi není nic nového.

[Lukáš Zapletal]

V průměru je opravdu téměř stejně rychlá. Dokonce jsem četl články, kdy byla Java rychlejší (a autor také rozebíral, proč). Ale je to věta vytržená z kontextu, spíše jsem tím chtěl říci, že rychlost vývoje převáží tento mírný výkonostní nedostatek. Zkrátka a dobře není to tak, že by to bylo něco rychlostně méněcenného, tak jsem to myslel...

[Heron]

Kdyby Javu zakazali, tak spotreba elektriny celosvetove klesna aspon o 10%.

A co potom takové Gentoo

[Luk]

Nebo i GTK

[Heron]

Pozor, porovnává subjektivní výkon GUI, nikoliv objektivní výkon celého programu.

Java je rychlostně srovnatelná s ostatními jazyky. Pochopitelně, někde je rychlejší jeden, jinde druhý.

Někdo napsal Q2 engine v Javě a ten je dokonce rychlejší než origoš v C++. Takže ani s těmi hrami to není pravda. Navíc, to že na time critical se používá ASM nám vymlátili z hlavy už v prvním ročníku MI před šesti lety. Nevím, proč to stále někdo používá jako argument.

Averze proti Javě může být způsobena podobně, jako averze některých linuxáků vůči Windows. (Nejčastěji) mladí hoši dostanou nakládačku od Winů, zkuší linux a hned křičí, co v tom všechno funguje a co vše ve Win vůbec není (často tak prokazují pouze své chabé znalosti). C a C++ možná májí nálepku jako jazyky expertů a každý co používá něco jiného (nebo nedej bože používanějšího - C#, Java) je okamžitě looser. Ukažte jim třebas Scheme a sklapnou .

[Petr "Glubo" Sýkora]

Nicméně vzhledem k původnímu zápisku blogu odhaduji, že řeč byla především o GUI aplikacích, které většinu času spí a čekají na vstup od uživatele. A ať si kdo chce co chce říká, já mám pocit, že subjektivní dojem rychlosti je u většiny GUI aplikací jeden z důležitých faktorů.

Samozřejmě, pokud se přesuneme od těchto spáčů k nějakým aplikacím, které provádějí něco, na co je opravdu potřeba čekat, důležitost subjektivní vnímání reakceschopnosti GUI ustupuje za důležitostí, za jak dlouho to bude hotové. Současný stav Javy mi připadá, že GUI trochu pokulhává, ale ostatní je nejspíš na velmi použitelné úrovni.

A existuje nějaký způsob, jak třeba usvižnit Javové GUI oproti vanilkové instalaci té od Sunu? Javu používám jen vyjímečně z pohledu BFU, tak uvítám nakopnutí směrem, kde mi už nebude Javovské GUI lízt krkem.

[Heron]

Neumím odpovědět jinak, než zde. Nejsem expert na GUI, píšu raději věci, které nejsou vidět

[Jirka]

Jednoducha odpoved - NetBeans v.5+ - GUI aplikace napsana v Jave, ktera si v nicem nezada s jinymi bratricky (vyvojovymi platformami) co do slozitosti a obsahlosti a funkcnosti atd. Jeste se mi nestalo, ze bych na nejakou operaci v GUI cekal. Na stejne masine obcas provozuji VisualC++ a tam (svete div se) se pri naskladani "prilis mnoha" (rozumej >20) komponent do designeru okna nevim proc ceka na editor vazeb az 10s .

[Miloslav Ponkrác]

Java je rychlostně srovnatelná s ostatními jazyky. Pochopitelně, někde je rychlejší jeden, jinde druhý.

Ano, souhlasím. S tím, že ty jiné jazyky dosahují stejnou rychlost jako Java za výrazně nižší spotřeby systémových zdrojů - především paměti.

Navíc, to že na time critical se používá ASM nám vymlátili z hlavy už v prvním ročníku MI před šesti lety.

Jenže pro skutečně a opravdu kritické věci prostě jen asm umožňuje opravdu vymáčknout maximum. Druhá otázka je, že to co je time critical není až tak na hranici možností dnešních procesorů - tudíž lze opustit asm a přejít na vyšší jazyk. Ale pokud bude dělat něco na hranici možností procesoru (což se třeba u jednočipáku stane docela snadno) - může se Vám stát (i když připouštím, že je to dost řídká situace), že prostě jen asm na to stačí.

Nemám rád jednostranné závěry typu "vymlátili nám z hlavy". Celá pravda je prostá: máte-li alespoň pár procent rezervu výkonu, jste za vodou a time critical píšete ve vyšším jazyce, nemáte rezervu výkonu - nutné použít asm. Ač uznávám, že ta potřeba použít asm je v 0,01%, MI asi nebude moc dobrá škola, pokud prohlásí jednoznačný nepravdivý závěr bez dalšího.

Averze proti Javě může být způsobena podobně, jako averze některých linuxáků vůči Windows. (Nejčastěji) mladí hoši dostanou nakládačku od Winů, zkuší linux a hned křičí, co v tom všechno funguje a co vše ve Win vůbec není (často tak prokazují pouze své chabé znalosti). C a C++ možná májí nálepku jako jazyky expertů a každý co používá něco jiného (nebo nedej bože používanějšího - C#, Java) je okamžitě looser. Ukažte jim třebas Scheme a sklapnou

A nebo to s averzí vůči Javě není tak ostré - a spousta lidí chápe Javu docela objektivně - a odmítá jí přisuzovat ty super hyper super extra mega vlastnosti, jako jí zastánci Javy neustále přisuzují a brání se proti tomu.

Jinak šablonujete - pohybuji se mezi komunitou C/C++ dvacet let a jen minimálně jsem slyšel odsuzování Javy. Na druhé straně od javovské komunity počínaje samotným Sunem pokračuje přes mnoho Java evangelistů přes běžné javisty slyším neustálé nadávky na C++ a snahu C++ zdiskreditovat a to i když se o ní nezačne řeč. Takže ze své profesionální praxe musím říci, že je to přesně naopak.

[Heron]

Ano, souhlasím. S tím, že ty jiné jazyky dosahují stejnou rychlost jako Java za výrazně nižší spotřeby systémových zdrojů - především paměti.

To musí být opravdu silná nenávist, když v každé větě, který by jinak vyzníval pro Javu alespoň neutrálně, uvedete nějaké negativum.

Ač uznávám, že ta potřeba použít asm je v 0,01%, MI asi nebude moc dobrá škola, pokud prohlásí jednoznačný nepravdivý závěr bez dalšího.

Matematická Informatika, Přírodovědecká fakulta University Palackého v Olomouci. Že to není dobrá škola jim řeknete Vy, nebo to mám udělat za Vás?

Byla řeč o x86 PC, které tehdy měli 512MB RAM a za rok budou mít 8GB. S procesory, které si přehazují instrukce podle aktuální situace. S instrukční sadou doplňovanou s každým dalším modelem. Psát 100% odladěný kód v ASM, to bych nedělal nic jiného, než nonstop studoval změny v nových CPU. Naopak jsem rád, že to za mě na 80% udělá překladač. U jednočipů jsem měl vždy větší problém se vejít do paměti, proto jsem ASM optimalizoval na velikost, rychlost byla taky důležitá, ale vejít se to tam prostě muselo.

[Miloslav Ponkrác]

Matematická Informatika, Přírodovědecká fakulta University Palackého v Olomouci. Že to není dobrá škola jim řeknete Vy, nebo to mám udělat za Vás?

Klidně jim to řekněte Vy. Mimochodem, dělal jsem profesorům programování na této univerzitě konzultace, když jsme spolupracovali na praktickém softwarovém projektu.

Byla řeč o x86 PC, které tehdy měli 512MB RAM a za rok budou mít 8GB. S procesory, které si přehazují instrukce podle aktuální situace. S instrukční sadou doplňovanou s každým dalším modelem. Psát 100% odladěný kód v ASM, to bych nedělal nic jiného, než nonstop studoval změny v nových CPU. Naopak jsem rád, že to za mě na 80% udělá překladač. U jednočipů jsem měl vždy větší problém se vejít do paměti, proto jsem ASM optimalizoval na velikost, rychlost byla taky důležitá, ale vejít se to tam prostě muselo.

Nebyla tu o ničem konkrétním řeč. Jen o tom, že asm se na time critical apliakce napoužívá bez jakékoli další konkretizace z Vaší strany. Tak jak jste to napsal s Vámi souhlasím a to do puntíku. Přesto vím, že i na x86 existují aplikace, které jsou tak kritické, že jsou perfektně odladěny v asm - například kódování videa.

[Hynek (Pichi) Vychodil]

Byla řeč o x86 PC, které tehdy měli 512MB RAM a za rok budou mít 8GB.

Hmm, a těch 8GB do paměti dostanete jak? A z paměti do procesoru? A to všechno je zadarmo?

[Heron]

Nechápu smysl těch tří dotazů v kontextu diskuse.

[Hynek (Pichi) Vychodil]

Nechápete? Takže polopatě, stejný algoritmus napsaný delším kódem se z disku do paměti nahraje pomaleji. To za prvé. Za druhé, tentýž algoritmus pracující s daty méně efektivně uloženými v paměti poběží pomaleji, protože bude častěji generovat výpadky stránek z L2 cache. To je k té druhé části. Ještě to stále není jasné? Představte si, že jsou úlohy, které je to sakramentsky znát. Tam se s celou javou můžete jít zahrabat, protože jen špatným uspořádáním dat vám výkon může klesnout až 10x proti programu v C, jen proto, že dojde ke stejnému efektu jako rozdíl mezi sekvenčním a náhodným čtením z disku, jenže tady vám k tomu efektu dojde při čtení z paměti. Jo hošánku, není ten svět jednoduchej.

[Heron]

Zaprvé si odpusťtě osobní invektivy na ty není nikdo zvedavej.

To co ste právě napsal mi bylo jasný už u předchozího komentáře. S původním threadem to nemá nic společného.

Prapůvodní kořen tohoto vlákna zněl takto:

Jestli to opravdu všechno leží jen na té rychlosti (jak se mohu domnívat z vašeho příspěvku), tak se to časem umlátí silou HW. Dnes už přece také nikdo nemá potřebu vyvíjet hratelné gamesky do pamětí řádů kB a procesorů typu Z80, ne?

Na to jsem reagoval, že není pravda, že Java je pomalá a že ani neplatí rovnítko ASM=rychlé. Pak došlo na HW (a týkalo se to především CPU). Přečtěte si to sám.

Nikde jsem nepsal o jednom stále stejném algoritmu hůře a hůře napsaném nebo přeloženém a proto vyžadujícím více RAM a CPU. Naopak. Jestli má někdo pocit, že dnešní programy umí stejně jako ty co před šesti lety, ale potřebují k tomu šekrát větší výkon, tak nechť otevře oči.

[Kyosuke]

"Jestli má někdo pocit, že dnešní programy umí stejně jako ty co před šesti lety, ale potřebují k tomu šekrát větší výkon, tak nechť otevře oči."

Ehm, v mnoha případech tomu tak je. Ba co hůř, najdou se i situace, kdy nespokojený uživatel (ovšem hard-core power user) sedne a napíše vlastní SW - tisíckrát (vím i o extrému, kde byla nula navíc) menší, ale překvapivě i použitelnější a lepší. Opravdu mě nenapadá moc věcí, které by před šesti lety s šestinovým výkonem principielně nešly, tedy s výjimkou aplikací opravdu náročných na výkon, jako jsou lepší kodeky, grafické filtry a podobné blbosti. Určitě se to netýká kancelářských balíků, většiny zakázkových aplikací, databázových věcí... V mnoha případech by určitě stačil výkon i desetinový, třicetinový... Případně před šesti lety mohl někdo napsat aplikaci, která je podobně rychlá i funkční, jako obdobná aplikace někoho jiného, ovšem psaná na dnešní železo. Požadavek na odezvu ~1.5 s maximálně tu zůstává, jen nám nakynuly knihovny, runtimy, disky...a lidi, pokud jim v tom něco nezabrání, se prostě roztáhnou. Přijde mi to skoro přirozené.

[Heron]

Zrovna "principiálně" šlo totéž co dnes i před 30 nikoliv šesti lety.

Mě tu toho běží rok co rok více, pokud jsem si k programování před šestli lety poušťel mp3, tak dnes je to HDTV seriál s multikanálovým zvukem. Programuji v pořádném IDE a nad DB o velikostech, o kterých tehdejší disky jen snili. Atd.

Ano, v mnoha případech je tomu naopak, souhlas. Ale neporovnáváme špičkové programy z minulosti s brakem součastnosti (kteréhož je s špříchodem takyprogramátorů stále víc), že.

[Petr "Glubo" Sýkora]

Bohužel se musím připojit. Benchmark mne nezajímá, zajímá mne to, proč mi sakra všechno v javě (především GUI) připadá subjektivně tak strašně líné.

[jalinh]

Zajímavé - já používám asi 2 java aplikace (ač mám možnost používat nativní) a nepozoruji žádné velké zpomalení oproti těm nativním - navíc mám možnost používat prakticky stejné prostředí v obou systémech, ve kterých se pohybuji.

[Petr "Glubo" Sýkora]

Možná to bude železem, Duron@900Mhz, 512 MB RAM v dnešní době je považováno za vykopávku, nicméně tu pomalost pozoruji i u vcelku nekomplexních aplikací, jejichž nativní alternativy běhají svižně, mnohdy s komplexnějšími funkcemi. Přemýšlel jsem nad tím, že bych mohl mít špatně nainstalovanou javu, nicméně pokusy s jinými distribucemi vykazovaly dost povědomé výsledky. Argument, že bych si měl koupit nové železo zatím neberu, jelikož zatím ke svému využití počítače nové železo nepotřebuju

[Josef Kufner]

Tohle je na desktop víc než dostačující stroj. Mám tu jednoho Athlonka na stejné frekvenci a se stejným množstvím paměti s /home na NFS a bohatě to stačí. KDE 3.5 na tom nijak líné není a filmy to zvládne taky.

Když se tak kouknu na to, kolik výkonu si vzaly programy před pár lety a co berou teď, tak mi je z toho chvílema poněkud nevolno. A přitom dělají prakticky pořád totéž.

[Luk]

Když se tak kouknu na to, kolik výkonu si vzaly programy před pár lety a co berou teď, tak mi je z toho chvílema poněkud nevolno.

Když se kouknu na to, jak pomalé je dnešní GTK, je mi chvílemi opravdu nevolno

[Petr "Glubo" Sýkora]

Zvláštní je, že na tomtéž stroji s rychlostí GTK nemám problém.

[petr_p]

Třeba zpožděné rozbalovaní podnabídek je záměrné (gtk-demo ⊳ Menus). Ovšem obecně souhlasím, že proti FLTK nebo Tk je GTK pomalejší.

[Pavel Kysilka]

poslete mi vypis

java -vesion

thx gf

[Luboš Doležel (Doli)]

java version "1.6.0_03"
Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)

[Petr "Glubo" Sýkora]

java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b05)
Java HotSpot(TM) Client VM (build 1.6.0_02-b05, mixed mode)

[Heron]

Tohle bych o Tebe čekal tak před rokem a půl. Ne a ne dospět.

[Luboš Doležel (Doli)]

Jenže, co mám Herone dělat, když je to opravdu pomalé? Možná je to špatně napsanými programy, ale ať používám jakýkoliv Java GUI program, tak mé obavy o nevyužití výkonu systému rázem končí...

[Heron]

Záleží co je pomalé. Jaký to má Look&Feel. Nepřekládá se to přes GTK? Předpokládám, že ty máš QT nějak hodně dobře zkompilované a na míru, nemůže to být tím, že Java je standardě rychlá ale tvé GUI daleko rychlejší (díky tvým úpravám)? Zkoušel jsi -server k JVM? Možností je mnoho.

[Luboš Doležel (Doli)]

Jestli má program Swing GUI nebo SWT (GTK+) GUI na výkonu nepoznám - je jedno, jestli použiju Eclipse nebo Netbeans, Azureus nebo.... hmmm Jubler . Kdykoliv použiju nativní program, ty rozdíly jsou vidět nejen na grafu zátěže CPU, ale i na odezvě.

GTK+ programy oproti Qt pomalejší mám, ale určitě ne podobným způsobem. -server zkusím.

[Heron]

Hmm, všechno to jsou pořádní macci (teď nemyslím toho politika ). Někde na Eclipse fóru bylo něco jak nastavil GC tak aby GUI nelagovalo. Nezažil jsem, nezkoumal jsem.

[saly]

Ano, výkon počítačů se zvětšuje. Ale je to jako u her, na P4 si zahrajete bez problémů Need For Speed 2, ale co nejnovější NFS? Dle mého názoru se zvyšuje jak výkon PC, tak i náročnost programů(Javy také) a proto je to celkově stejně rychlé. Například Azureus, nebo Eclipse jsou nechutně pomalé, že se nedají skoro ani používat. Ovšem je zvláštní, že Zend Studio je použitelné, asi je to vyjímka. Co se týče výpočetních aplikací, nebo ne-GUI aplikací, je to možná na dobré úrovni, proč by jinak ABC stíhalo vše v pohodě a bylo v kafi?

[David Watzke]

Například Azureus, nebo Eclipse jsou nechutně pomalé, že se nedají skoro ani používat

Azureus se nedá používat? Mně tu běží rovnou 2x a používat se dá dost dobře

[saly]

Mno, oproti nativním klientům je dost pomalý a na mém PC(P4 2,8Ghz,512MB RAM žral docela dost). Pravda, použít se dá, ale moc bych to nedoporučoval.

[mimi.vx]

jeho vyhodou jsou jeho technicke vychytavky .....

[Heron]

Pomalý v čem? Ještě jsem neviděl Azureus žrát více než 10% CPU a to ani na Athlonu 2400.

[Kyosuke]

To musel být datový tok jako vodopád, když to při síťové komunikaci a nějakých těch checksumech žralo celý výkon Pentia II (nebo ekvivalentu).

[Heron]

Toho je mnohem víc, než "nějaké ty checksumy". Zrovna Azureus je jeden z nejpromakanějších BT klientů vůbec.

[Kyosuke]

Co má teda tak skvělého, že to žere tolik výkonu navíc? Raytracuje to graf datových toků od všech peerů?

[Heron]

Raytracuje to graf datových toků od všech peerů?

To se obávám, že by to žralo několikrát tolik.

[saly]

Na mém PC žral i 30% CPU ...

[David Watzke]

Žere hodně RAM, ale že by byl pomalej, to jsem nezaregistroval. Každopádně jsem před chvílí přešel na uTorrent. Asi u něj zůstanu.

[Miloslav Ponkrác]

Ano, přesně díky takovým argumentacím se bere ta neustálá kritika Javy. Já osobně nic proti Javě nenamítám, leccos jsem v ní programoval. Ale už mi opravdu leze krkem ta nekritičnost, že se všechno kolem Javy vydává jako plus. Když uslyším vedle sebe rozumně - toto je výhoda Javy, toto nevýhoda - ani nehlesnu, a nebudu mít sebemenší tendenci říct proti Javě ani slovo.

Pravda je taková, že Java se mockrát obhajuje i lživými argumenty, které nezkušený programátor snadno přehlédne. Takových lží už tu bylo včetně zfalšovaných testů, že Java je rychlejší, než C++, dokonce než assembler. A to je to nejmenší.

Za druhé, pravověrný javista se bude navážet do všech ostatních programovacích jazyků, to že to pak schytají jakožto důsledek této namyšlenosti je jen logická zpětná vazba.

Zkusme třeba jen ty Vaše argumenty rozebrat:

"multiplatformní výsledky"

Skutečně? Ano, Java je multiplatformní, ale ne zase tak absolutně. Když jsem programoval mobily, bylo daleko přenositelnější programovat v C++, než v Javě. Co Javovský program, to neustálá nutnost úprav při přechodu na jiný mobil.

Ale i když zůstanu na normálních počítačích - mám pocit, že existuje daleko více jazyků, kde přenositelnost je vynikající. Takový Python je například naprosto a bez problémů přenositelný. PHP je třeba přenositelné. Smalltalk je přenositelný par excellance. LISP je přenositelný co vím bez problémů. Velmi dobře přenositelných jazyků je spousta akorát to tak nekřičí do světa.

Jinak .NET je také slušně multiplatformní, když už jsme u toho.

K tomu bych ještě dodal, že skutečná multiplatformovost se vyžaduje jen dost zřídka v reále. Protože udělat multiplatformní program neznamená mít multiplatformní Javu či jiný jazyk, ale také _multiplatformově_ _programovat_ a být si vědom toho, co to obnáší. Tudíž i v Javě je spousta programů, které multiplatformní nejsou a nebudou.

"kratší doba návrhu"

Předpokládám, že jste chtěl říci kratší doba vývoje, protože s návrhem je to poněkud jinak. Ano, v Javě program naprogramuje programátor v průměru určitě rychleji, než v C/C++ třeba. Ale třeba zase v Pythonu bude určitě rychleji s vývojem hotovi, než v Javě. Ve Smalltalku nejspíš také. A tak bychom mohli pokračovat dále.

"s rozšiřováním stále nabouchanějších počítačů, klesá handicap větších nároků na strojový čas a paměť. Navíc ten rychlostní rozdíl se zdá dost zanedbatelný."

To je velmi optimistické. Já bych toto netvrdil. Ale řekněme, že obecně je větší tolerance vůči nenažraným programům, než byla dříve. Přesto bych řekl, že Java to dost přehání - a mnoho lidí prostě Javu odmítá vůči pomalosti/žravosti. Pro jistotu napíšu, že je jedno, jestli za to může Java, nebo neschopný Javista co to naprogramoval - uživateli je to zcela jedno. Javovské programy mají speciální pověst - a mnoho lidí, kteří ani neumí programovat odmítne program v Javě, má-li náhradu v čemkoli jiném.

Celkově mi přijde, že je pro tuto oblast budoucnost v nějakém standartizovaném společném virtuálním stroji, do jehož bytecodu budou mít všechny slušnější jazyky možnost překladu - a této myšlence je virtuální stroj Javy zřejmě právě nejblíž.

To je naprostá ptákovina. Virtuální storj Javy je prostě navržen pro Javu a s ničím jiným moc nepočítá. Samozřejmě, že to sem tam jakž takž jde - ale žádná sláva.

To virtuální stroj .NETu je navržen daleko univerzálně - a i jeho bytekód je složitější a rozsáhlejší a byl už s účelem multijazykovosti navržen.

Ale v globále ani jeden z výše zmíněných virtuálních strojů se příliš nehodí na dynamicky typované jazyky, takže třeba pro Perl, nebo pro Python se vyvíjí Parrot a další virtuální stroje.

A pan Kyosake by si asi taky rval vlasy, kdyby se někdo pokusil jeho oblíbený LISP přechroustávat na Java mašině a on to musel používat.

[jalinh]

Díky za obsáhlé vysvětlení - lecos jsem si uvědomil - ale co se týče té multiplatformosti - obdobu swingu konkurenti Javy přeci zatím nemají a když může existovat Jython, proč by to měla být "ptákovina" pro další jazyky?

[Josef Kufner]

A co třeba Qt?

[Luboš Doležel (Doli)]

a wxWidgets

[jalinh]

QT sice není úplně free, ale o wxWidgets jsem netušil. Máte pravdu, trochu jste mi mé představy o jedinečnosti javy poopravili

[Miloslav Ponkrác]

Díky za obsáhlé vysvětlení - lecos jsem si uvědomil - ale co se týče té multiplatformosti - obdobu swingu konkurenti Javy přeci zatím nemají a když může existovat Jython, proč by to měla být "ptákovina" pro další jazyky?

Protože Javovská virtuální mašina je prostě šitá na jazyk ve stylu Javy. Čím více se bude jazyk lišit od Javy, tím obtížnější bude udělat nějaký rozumný překlad toho Javy do Javovské virtuální mašiny. Java je totiž jazyk velmi osekaný a striktní - sám Sun se chlubí tím, že Java je "čistá" a "obsahuje jen nezbytné minimum, není tam nic navíc". A tato osekanost jazyka (a v důsledku i Javovské virtuální mašiny) vlastně způsobuje nesmírné obtíže při implementaci čehokoli jen trochu rozdílného od Javy. V podstatě prakticky pro každý jazyk kromě Javy vždycky něco v Javovské virtuálnéí mašině chybí co ten jazyk potřebuje a musí se to velmi složitě a ne vždy s úspěchem obcházet.

Jython znám - v zásadě oproti Pythonu není úplný, obsahuje některá sporná místa a kompromisy, které bylo nutné udělat, aby šlo vůbec naroubování na Javovskou virtuální mašinu provést. Nakonec to dopadlo tak, že Jython dokonce rezignoval i na standardní knihovnu Pythonu a pythonisté Vám ho používat prostě nebudou, protože proti skutečnému Pythonu je hodně slabý a nekompatibilní brácha. Z Jythonu se v podstatě stala Java s pythonovskou syntaxí. A to se ještě Jython uvádí jako jeden z největších úspěchů při portaci cizího jazyka na Javovskou virtuální mašinu.

Co se týká přenositelného grafického prostředí - vyberte si: Qt, wxWidgets, Tk, FLTK, a další ještě existují.

[Kyosuke]

Reakci viz níže, nějak se mi to zmotalo.

[Boris Dušek]

Ale v globále ani jeden z výše zmíněných virtuálních strojů se příliš nehodí na dynamicky typované jazyky, takže třeba pro Perl, nebo pro Python se vyvíjí Parrot a další virtuální stroje.

A co DLR?

[Heron]

To je velmi optimistické. Já bych toto netvrdil. Ale řekněme, že obecně je větší tolerance vůči nenažraným programům, než byla dříve. Přesto bych řekl, že Java to dost přehání - a mnoho lidí prostě Javu odmítá vůči pomalosti/žravosti. Pro jistotu napíšu, že je jedno, jestli za to může Java, nebo neschopný Javista co to naprogramoval - uživateli je to zcela jedno. Javovské programy mají speciální pověst - a mnoho lidí, kteří ani neumí programovat odmítne program v Javě, má-li náhradu v čemkoli jiném.

Tohle jsem tu četl už tolikrát, že na to konečně musím reagovat. Podívejte se to poradny a najděte si tam dotazy ohledně spotřeby paměti v Linuxu. Dotaz je typu: "Mám 768MB RAM a volný jen 52MB, přitom mám spustěný jez Firefox. To jsou ty linuxi tak žravý na paměť???" Následuje vysvětlení, že 600MB je cache.

Na tom samém portálu se neustále dočítám, že Java je náročná na paměť. Přečtěte si prosím něco o tom, jak JVM hospodaří s pamětí. Linux má své cache, JVM taktéž (akorát se to jmenuje jinak). Pokud ván Java app žere moc paměti, změnte si parametry JVM.

[Kyosuke]

"Pokud ván Java app žere moc paměti, změnte si parametry JVM."

To jsem zvědav, jestli mi zrovna tohle to využití paměti XEPem srazí z těch 1.4 GB někam rozumně dolů.

[Heron]

Nevím, co to je XEP, ale pokud opravdu vyžaduje tolik paměti, nevidím důvod, proč mu je nedat.

[Kyosuke]

Něco jako TeX, akorát je to psané v Javě a žere to o dva řády více paměti.

[Heron]

Mno zrovna původní TeX odolává snad všem přepsání .

[Miloslav Ponkrác]

Tohle jsem tu četl už tolikrát, že na to konečně musím reagovat. Podívejte se to poradny a najděte si tam dotazy ohledně spotřeby paměti v Linuxu. Dotaz je typu: "Mám 768MB RAM a volný jen 52MB, přitom mám spustěný jez Firefox. To jsou ty linuxi tak žravý na paměť???" Následuje vysvětlení, že 600MB je cache.

Ano, jednak není jen Linux, je i Windows, Mac a další. A jednak pokud systém začíná zřetelně swapovat - tak chcete tvrdit co? A opravdu si myslíte, že všichni kromě Herona jsou nýmandi, co nejsou schopni zjistit skutečnou spotřebu paměti procesem?

Na tom samém portálu se neustále dočítám, že Java je náročná na paměť. Přečtěte si prosím něco o tom, jak JVM hospodaří s pamětí. Linux má své cache, JVM taktéž (akorát se to jmenuje jinak). Pokud ván Java app žere moc paměti, změnte si parametry JVM.

Ano, skvělé - a když Vám doma nejde televize, otevřete jí, chytněte pájku a zkoušečku, otestujte desku a vyměňte vadnou součástku. V nějakém příspěvku výše se rozplýváte, jak g++ je třeba nastavovat s optimalizačními parametry, zatímco o Javu se není třeba starat - byl to případ benchmarku. A teď z Vás vypadne, že g++ stačí nastavit jednou při kompilaci a uživatelé to mají bez práce, zatímco Javu aby si nastavoval každý uživatel včetně posledního BFU, jinak mu pojede špatně.

Můžete nastavovat co chcete - pokud Javě nedáte dostatek paměti, tak sletí na výjimku nedostatku paměti. Pokud se bude potřebná paměť blížit té, které jste JVM dal, bude gc makat jak vzteklé a efektivita jde prudce dolů. Prostě Java potřebuje plýtvat pamětí - je to podmínka efektivního běhu javovského procesu.

[Heron]

V nějakém příspěvku výše se rozplýváte, jak g++ je třeba nastavovat s optimalizačními parametry, zatímco o Javu se není třeba starat - byl to případ benchmarku. A teď z Vás vypadne, že g++ stačí nastavit jednou při kompilaci a uživatelé to mají bez práce, zatímco Javu aby si nastavoval každý uživatel včetně posledního BFU, jinak mu pojede špatně.

Spletl jste si uživatele, o g++ jsem nic nepsal.

A opravdu si myslíte, že všichni kromě Herona jsou nýmandi, co nejsou schopni zjistit skutečnou spotřebu paměti procesem?

To rozhodně ne a ani to z mého komentáře neplyne. Jen jsem se pozastavoval nad tím, že na stejném portálu lidi vysvětlují jak je to se spotřebou paměti v linuxu (a že je to takto dobře) a na druhé straně nadavájí na "stejně" spotřebovanou pamět v JVM (kde je to podle nich špatně).

Pokud se bude potřebná paměť blížit té, které jste JVM dal, bude gc makat jak vzteklé a efektivita jde prudce dolů. Prostě Java potřebuje plýtvat pamětí - je to podmínka efektivního běhu javovského procesu.

Totéž co výše. Dejte Linuxu, Windows, Macu 1GiB RAM a spusťtě tam program (třeba v C++), který reálně potřebuje 1000MB. Uvidíme, jak to pojede.

[Miloslav Ponkrác]

Spletl jste si uživatele, o g++ jsem nic nepsal.

Ano, omlouvám se, psal to někdo jiný.

To rozhodně ne a ani to z mého komentáře neplyne. Jen jsem se pozastavoval nad tím, že na stejném portálu lidi vysvětlují jak je to se spotřebou paměti v linuxu (a že je to takto dobře) a na druhé straně nadavájí na "stejně" spotřebovanou pamět v JVM (kde je to podle nich špatně).

Ano, v tom s Vámi souhlasím - máte pravdu. Nicméně určitě to nelze generalizovat.

Totéž co výše. Dejte Linuxu, Windows, Macu 1GiB RAM a spusťtě tam program (třeba v C++), který reálně potřebuje 1000MB. Uvidíme, jak to pojede.

Pokud dáte programu v C++, který potřebuje 1 GB RAM přesně 1 GB RAM - pojede naprosto bez problémů a stejně rychle jako když mu dáte třeba 20 GB RAM. Program v C++ nepotřebuje nadbytek paměti pro efektivní běh. Pokud dáte programu v Javě, který potřebuje 1 GB RAM přesně 1 GB RAM, JVM se umlátí na častém spouštění garbage collectoru - což znamená nejen projít graf závislosti používání paměti, ale také pozastavení všech threadů v Javě - tudíž značné snížení efektivity programu. Program v Javě potřebuje pro efektivní běh nadbytek paměti. Nehaním tu Javu, prostě tohle jsou vlastnosti vyplývající z architektury a totéž bude platit pro jakýkoli jazyk postavený na automatickém gc - .NET, Python, atd...

[Heron]

Pokud dáte programu v Javě, který potřebuje 1 GB RAM přesně 1 GB RAM, JVM se umlátí na častém spouštění garbage collectoru

Tohle snad děláte schválně

Program v C++ nepotřebuje nadbytek paměti pro efektivní běh.

Ale potřebuje. Jenže se to maskuje jako buffers a cache v systému pod ním. Pod programem v javě je co? Ano správně JVM. Má-li OS pro C++ program k disposici 600MB cache, dopřejme to i JVM.

[Miloslav Ponkrác]

Ale potřebuje. Jenže se to maskuje jako buffers a cache v systému pod ním. Pod programem v javě je co? Ano správně JVM. Má-li OS pro C++ program k disposici 600MB cache, dopřejme to i JVM.

Myslím, že hnát to až na úroveň samotného systému, není nutné. Jednak mluvíme obecně o programu, a pokud nespecifikujeme detaily, může být program na velikosti buffers a cache málo, vůbec, více, nebo hodně závislý. Jakýkoli program, který uvnitř běží bez gc nepotřebuje v zásadě nadbytek paměti, program s gc ho potřebuje, jinak běží špatně. Abych byl zcela konkrétní - program s gc potřebuje hodně extra paměti navrch oproti tomu co chce systém + systémové struktury pro proces + vlastní paměť pro proces.

[Heron]

Ano, stím lze souhlasit. Jenže i v Javě napíšu program, který bude recyklovat stále stejné objekty tak, že gc se ukouše nudou. Napadá mě třeba jakýkoliv aritmetický výpočet se základními typy.

Obecný program v Javě potřebuje gc stejně jako obecný program v čemkoliv nativním potřebuje cache OS.

[MJ]

Ale potřebuje. Jenže se to maskuje jako buffers a cache v systému pod ním. Pod programem v javě je co? Ano správně JVM. Má-li OS pro C++ program k disposici 600MB cache, dopřejme to i JVM.

Opravdu si myslíte, že se JVM obejde bez té cache v systému pod ním?

[Heron]

Do jisté míry ano, i JVM má IO cache. Každopádně já tu nejsem ten, který chce brát programům paměť. Právě naopak, nechť ji mají co nejvíc.

[ajikdpoe]

Java aplikacie su nechutne pomale, typicke su pol az niekolko sekundove lagy pri trivialnych operaciach (napr. kliknutie na menu) a celkovo to je take pomale. Pred tyzdnom som skusal jeden javovsky program na navrh interierov. Pouzivat sa to dalo, ale vobec som nemal prijemne pocity ked som to pouzival. Akoby mali vsetky programy taku velmi blbu latenciu. Ked uz nieco vykonava tak to ide relativne rychlo, ale prave interakcia s gui je o nicom. S nativnymi aplikaciami sa to neda porovnavat.

Celkovy dojem s rychlosti java gui aplikacii je ako porovnanie Firefox vs. Opera. Opera je velmi rychla, veci ako prepinanie zaloziek, a celkova praca je o 1 rad rychlejsia, ale ked stahujete 100 MB subor co trva par sekund tak uz to ide na oboch rovnako, hoci kym zacne stahovat firefox tak to trva chvilku. A taky isty pocit mam s javovskymi aplikaciami.

Inak ked sa ti zda ze java aplikacie su rovnako rychle, skus si nainstalovat solaris kde ich je podstatne viac a potom nam o tom nieco povedz.

[Luk]

Inak ked sa ti zda ze java aplikacie su rovnako rychle, skus si nainstalovat solaris kde ich je podstatne viac a potom nam o tom nieco povedz.

Pokud vím, tak zrovna na Solarisu je Java nejpomalejší a nejžravější. Je to docela pikantní, vzhledem k tomu, že je obojí produktem téže firmy a mělo by to tedy být nejlépe sladěno.

[Miloslav Ponkrác]

Ono je to právě tou "optimističností", že Java je multiplatformní. Javisti zapomínají na to, že na každou platformu je potřeba udělat Javovskou virtuální mašinu, a pokud se ta mašina moc nepovede, je Java na této platformě v háji.

A protože kvalita Javovské virtuální mašiny prakticky stojí a padá s kvalitou JIT kompilace - a tu je velmi náročné doladit a udělat skutečně dobře - nedělám si iluze, že by Java opravdu dobře běhala jinde, než na jedné/dvou (no dobrá ukecali jste mě, na třech) procesorových platformách. Na zbytku Java poběží naprosto příšerně neefektivně, protože nikomu nebude stát moc zato, aby si vyhrál s tím udělat tam dobrou Javovskou mašinu a za moc to stát nebude.

Ale už opravdu mlčím.

[frEon]

Javisti zapomínají na to, že na každou platformu je potřeba udělat Javovskou virtuální mašinu, a pokud se ta mašina moc nepovede

a proto je jeste vice zarazejici ze na sunackym solarisu se ta virt. masina zrovna moc nepovedla

[Luk]

Možná je to tak, že každé vyvíjí naprosto jiný tým a vůbec spolu nekomunikují. A ten tým, který vyvíjí Javu, se zaměřil hlavně na Windows, a proto je Java nejefektivnější právě tam.

[Kyosuke]

A pan Kyosake by si asi taky rval vlasy, kdyby se někdo pokusil jeho oblíbený LISP přechroustávat na Java mašině a on to musel používat.

Zase mně przníte. Ne, nerval bych si nic, protože pro mě by to byla jen další implementace Lispu. Jenže jakýkoli jazyk se pro JVM dá snadno kompilovat pouze tehdy, pokud je víceméně ekvivalentní Javě. Pokud ne, stojí implementátor před úkolem "napsat kompilátor z jazyka A do bajtkódu navrženého pro jazyk B", což je nevděčné, netriviální, a nefunguje to nijak dobře.

Implementátoři JRuby se potýkají s implementací výjimek, a to by člověk řekl, že to bude "trivka", když JVM je má taky. Kompilátor Common Lispu pro JVM sice taky existuje, ale jen za cenu spousty nekompatibilit a omezení, protože jazykový model Javy je z pohledu implementátora Lispu žalostně neúplný. (Generic functions, anynone? Closures? Migrace tříd objektů v živém systému na novější verzi? Když už ne v produkci, tak aspoň pro interaktivní vývoj...)

A kdybych stál před úkolem to někam naportovat, čekalo by mě v případě SBCL, které má asi tak 20000řádkový Cčkový kernel (dokonce věřím, že i já bych mu byl po čase schopen porozumět ) a nad ním přísně oddělených 200000 řádků vyšší vrstvy runtimu, kompilátoru a standardní knihovny (to vše v čistém Lispu), o dost méně práce, než v případě Suní Javy, která má pro Intel pečlivě vyladěný runtime o milionech řádků kryptického kódu, a přitom výkon je srovnatelný, občas v případě SBCL i lepší, a to ani zdaleka není nejlepší implementace, protože je zadarmo. A kdybych to nedokázal já, každý port SBCL měl na svědomí jeden člověk za pár týdnů, maximálně měsíců. U suního runtimu si to nějak nedokážu představit. Tolik k té "přenositelnosti".

Myslím si tedy, že Java je ta nejlepší Java, jakou můžete sehnat, a pokud Javu nepotřebujete, je lepší se podívat po vhodnějším řešení.

[Kyosuke]

Safra, tohle mělo patřit pod tohle.

[nightfish]

JAVA is good because it works on all OSes is like saying anal sex is good because it works on all genders.

[frEon]

ROFL

[Franta Gajdůšek]

Java kombinuje nevyhody kompilovanych a skriptovacich jazyku:
1) Pise se v ni temer tak pomalu jako v C++, na nejake Ruby nebo treba Python proste nema.
2) Je minimalne tak pomala a pametove nenazrana jako skriptovaci Python(uznavam, toto je taky bytecode ale v nem se pise lip), Ruby je mozna o neco pomalejsi ale zase min pametove narocny.

[zde]

1) Souhlas. Ale ono to jak se v tom blbě píše není až tak vlastnost jazyka, spíš tím že je zvykem používat uhozená API. Začalo to už u C++, ale Java přivedla velmiDlouheIdentifikatoryKtereSeBezIdeTemerNedajiNapsat k dokonalosti.

2) Když pominu startup, Java je jednoznačně rychlejší než Python i Ruby (a to faktorem 2-3). Python patří mezi nejpomalejší jazyky, vývojáři několikrát opakovali že rychlost pro ně není na prvním místě. Jenže když zjistím že můj program v Pythonu musí běžet rychleji, byl bych šílenec abych ho přepisoval do Javy, protože by to sice bylo 3x rychlejší, ale byla by to děsná onanie, kód by se nafoukl na trojnásobek, a prase by se v tom vyznalo. Raději vezmu 10% kódu v kterém se tráví 95% času, ten s minimálním úsilím přepíšu do C modulu, a aplikace bude ne 3x, ale 20x rychlejší.

[Heron]

velmiDlouheIdentifikatoryKtereSeBezIdeTemerNedajiNapsat

Příklad z praxe bude?

[Luk]

Třeba FormatFlagsConversionMismatchException

Na druhou stranu je to (hlavně u méně používaných věcí) názornější než mít identifikátor ffcmex, který bez manuálu nikdo nerozluští.

[Heron]

Čéče, vyjímky mě nenapadly, tam je toho hodně

Na druhou stranu je to (hlavně u méně používaných věcí) názornější než mít identifikátor ffcmex, který bez manuálu nikdo nerozluští.

No to každopádně.

[Franta Gajdůšek]

ad 1) ja jsem myslel vseobecne ukecanost jazyka. VelmiDlouheIdentifikatory jsou pry(neznam) domenou hlavne C#. Ale treba jaky je postup k precteni textoveho souboru? Matne si vzpominam ze to byly nejake 3 prikazy za sebou z nichz kazdy generoval nejaky proud ktery se (samozdrejme ne objektove ale jako parametr) predaval dalsimu prikazu. A vstupy? V knizce kterou jsem mel radej autor napsal vlastni tridu ktera to resila...
ad 2) spatne jsem se vyjadril, neslo me o rychlost ale celkovou zatez systemu, rychlost(cpu) javy rychlejsi je, ale co to pomuze kdyz takovy program sezere 3x vic ram? Obzvlaste v (dnes jiz ustupujicimu) trendu co nejrychlejjsi cpu a ram az co "zbyde".

[Luk]

Obzvlaste v (dnes jiz ustupujicimu) trendu co nejrychlejjsi cpu a ram az co "zbyde".

Tohle bývalo (a ještě do značné míry je) doménou PC v hypermarketech. Dají do letáku údernou hodnotu rychlosti procesoru a k tomu nízkou cenu. Šetří samozřejmě na grafice, disku, a hlavně operační paměti.

[Kyosuke]

"samozdrejme ne objektove ale jako parametr"

Fuj, za tohle bych střílel lidi u zdi. Co jiného je příjemce zprávy, než skrytý (v případě Smalltalku, Javy, C++ a podobně - v případě CLOSu/Dylanu je naopak viditelný) parametr, nad kterým se dispatchuje? Až tyhle jazyky konečně budou umět dispatch podle více parametrů, budou "méně objektové" či co?

[frEon]

s rozšiřováním stále nabouchanějších počítačů, klesá handicap větších nároků na strojový čas a paměť.... tak todle je presne argument kterej neberu! prece si nebudu kupovat novy stroj jenom kvuli tomu aby mi to bezelo zase stejne pomalu (to je vec, ktera me stve, na starem SGI Indy s Irixem 5.3, jsem udelal stejnou praci stejne rychle jako na dnesnich strojich, akorat s tim rozdilem, ze dneska si k tomu muzu pustit mp3). to je prece blbost.

[Heron]

s rozšiřováním stále nabouchanějších počítačů, klesá handicap větších nároků na strojový čas a paměť....

tak todle je presne argument kterej neberu! prece si nebudu kupovat novy stroj jenom kvuli tomu aby mi to bezelo zase stejne pomalu...

Donekonečna omýlaný argument. Podle Moora (nebo jak se jmenuje), se výkon PC zdvojnásobí za jeden až dva roky. A to platí i o paměti. PC se většinou tak často nekupuje. Nevšiml jsem si, že by na stejném PC stejná aplikace (pravidelně aktualizovaná) jela stále a stále pomaleji - většinou se optimalizuje a jede lépe.

Naopak, když už koupím nový stroj, většinou na něj naložím mnohem víc, než co běželo na tom původním starém, nebo je to výrazně kvalitnější (teď mám výkon, tak zkusím 16xFSAA - třeba).

[frEon]

myslim ze moore mluvi o poctu tranzistoru v procesoru, coz ovlivnuje i vykon.
mel jsem na mysli spis nez jednu aplikaci, nove technologie.

[User682]

zdravim,

proc ?

Jednoduche.

- neiformovanost lidi

- blbe napsane programy

- lidi neupgraguji

- lidi pouzivaji jazyk na neco, co na co ne vzdycky dany jazyk neni vhodny

- hodne lidi vede akademicke diskuse, jak C-ecko resi lepe pointery, ale uz se nekouka na to, ze to treba stoji cas.

- hodne lidi se s Vami bude bavit o tom, jak funguje VM manager, ale uz neumi ani spojovat retezce a pouzit optimalizovane tridy a metody.

- hodne lidi nevidi, ze jazyk tvori treba podpora a knihovny a IDE

- je treba nejaka vetsi znalost od programatora a tak clovek, ktery se nechce ucit, tak bude nadavat stejne.

- hodne lidi nikdy nepsalo nejaky vetsi projekt a kouka na ruzne jazyky a projekty pohledem sve 100-radkove aplikace.

Dam tu jeden priklad. Hodne lidi bude nadavat na javu. Ten pomaly nenezrany srot. A tak si na masinu hodi .NET, dokoupi novou masinu a jsou spokojeni. I presto, ze nadavat budou stejne. I presto, ze to bude zrat vice pameti, bude to pomalejsi ,vice zabugovane, bude to dost veci neumet.

Paradox ? Ale funguje to tak.

Java neni vselek, ale podle me jeden z nejlepsich velmi funkcnich kompromisu vseho mozneho co se tyka vyvoje v IT. A ten kompromis dovede malokdo najit.

bye gf

[Miloslav Ponkrác]

neiformovanost lidi

Prosím rozvést.

lidi neupgraguji

Proč to nedělá Java sama? Průměrný uživatel má dnes ve Windows (majoritní systém pro bfu) haldu věcí, které je potřeba upgradovat a tyto věci se o upgrade postarají samy, max. to oznámí a umožní upgrade schválit/odložit/zamítnout. Jen Java je zase sto let pozadu oproti tomu co je zvykem.

hodne lidi se s Vami bude bavit o tom, jak funguje VM manager, ale uz neumi ani spojovat retezce a pouzit optimalizovane tridy a metody.

Wow! Teď jste trefil hřebíček na hlavičku! Spousta lidí používá Javu, protože je _jednoduchá_, ale to je jen klam. Psát v Javě dobře je stejně složité, jako třeba psát dobře v C++, jen javisté si to nechtějí stále přiznat.

hodne lidi nevidi, ze jazyk tvori treba podpora a knihovny a IDE

Ano, naprosto v každém jazyce je znalost syntaxe nic proti tomu, že je potřeba ovládnout knihovny, technologie a další věci, které kolem toho jazyka jsou. To platí pro každý jazyk.

Dam tu jeden priklad. Hodne lidi bude nadavat na javu. Ten pomaly nenezrany srot. A tak si na masinu hodi .NET, dokoupi novou masinu a jsou spokojeni.

To bohužel ani vzdáleně nebude pravda. Stejně tak, jako .NET udělal několikrát rychlejší JVM oproti Sunu, kterou dodával než mu to Sun soudně zatrhnul. Tak bohužel JVM od Sunu má téměř celou standardní knihovnu v Javě, zatímco .NET v C/C++. Navíc Microsoft svoji .NETovskou virtuální mašinu neudělal špatně, takové vývojové prostředky do vývoje mašiny jako Microsoft Sun prostě nalít nemůže. Ne, tenhle scénář by pro Javu nedopadl až tak dobře.

Java neni vselek, ale podle me jeden z nejlepsich velmi funkcnich kompromisu vseho mozneho co se tyka vyvoje v IT. A ten kompromis dovede malokdo najit.

To je subjektivní názor zastánce Javy. Nemyslím si to, ač neříkám, že nejsou oblasti, kde Java skutečně bude. Ono toto Vaše tvrzení koliduje s tím, že lidé Javu používají i na co není vhodná.

[andree]

Proč to nedělá Java sama? Průměrný uživatel má dnes ve Windows (majoritní systém pro bfu) haldu věcí, které je potřeba upgradovat a tyto věci se o upgrade postarají samy, max. to oznámí a umožní upgrade schválit/odložit/zamítnout. Jen Java je zase sto let pozadu oproti tomu co je zvykem.

aspon toto nastastie uz vie...

inak tiez - nemam rad Mrkvosoft, ale 100x radsej by som robil nieco v .NET/Mono, ako v Jave... uz len preto, ako si nizsie pisal, ze aplikacie vyzeraju nativne, (v podstate) mozem pouzit jazyk ktory chcem... skratka flame

[User682]

Odpovim zitra.

Nicmene kratce okolo .NET.

Jsem javista, ale byl jsem donucen obcas delat asi rok v .NET a #C. .NET je sice hezky navrzeny a nektere veci hezke.

Bohuzel zacina to pokulhavat na funkcnosti a nedodelanosti i zakladnich veci, tak jako vsechny veci od Microsoftu, ktery vi, co je schopen uzivatel tolerovat a kam az muze zajit.

Stravit hodne casu nefunkcnosti a dost vecmi predelanymi, aby slabsi programator byl uspokojen(cilova skupina), neni jaksi vzdy ono.

Takze od 1.10. jedu opet ciste v jave a v jine firme.

\\add informovanost -

o tezsich vecech se nebude tolik psat a malokdo bude ochoten do nich prijit. A lide spise prijmou lepe ty negativni informace.

vice pozdeji

gf

[brk]

Ta multiplikativnost mi připomněla jednu hlášku, která mne kdysi hodně pobavila. Dnes už má sice v Googlu 133k výskytů, nicméně si neodpustím ji nezopakovat.

"Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders."

A teď trošku vážněji, proč já osobně nemám rád Javu a proč mi nevadí .NET/Mono, které je v zásadě velmi podobné, i když tam navíc ten "anální sex" není tak horký.

Když začínala Java tak desktopovou aplikaci v Javě šlo poznat na první pohled. Tyhle aplikace měly příšerné GUI, které absolutně nezapadlo mezi ostatní aplikace a výkon taky nic moc. Jak zaznělo v blogpostu, výkon dnešního hardware je úplně někde jinde a pokud nejde o nějaké rozsáhlé business apliakce, které samy o sobě žerou klidně 1GB RAM, tak to docela jde. Jenže i když se GUI dnes již značně zlepšilo, pořád to není ono a Java aplikace jdou poznat. Poznám aplikaci v Javě a okamžitě se mi vybaví z dřívějška zažité Java=hnusné a pomalé.

Naopak když začínal .NET, tak to sice chtělo do Windows doinstalovat "nějaký framework", ale dál to vypadalo jako běžné aplikace a nic jsem neviděl. Nevloudila se mi žádná asociace .NET = hnusné a pomalé, protože pokud po tom nepátrám, tak to nepoznám. Podobné to je u Mono a GTK#. To že tím GUI utrpěla multiplikativnost je jasné, ale to je druhá věc.

[Miloslav Ponkrác]

Ano, to je přesně ono!!! Java totiž kašle na všechno a všechno si dělá po svém - jinak, protože ona to přeci dělá nejlépe. A na tom GUI je to asi nejmarkantnější.

Prostě Java jede stylem - všichni se přizpůsobte Javě, nikoli aby se Java přizpůsobila zvykům systému a nenápadně zapadla mezi ostatní aplikace.

[Lukáš Zapletal]

To je sice hezké, až na to, že Java se pro vývoj desktop aplikací moc nevyužívá. Programují se v ní hlavně servery a web...

[brk]

A o tom to celé je. Abičko je taky napsané v Javě a spokojenost. U těchto aplikací člověk s GUI do styku nepřijde, pokud to vůbec nějaké má, a ani nevnímá většinou nepříjemně zdlouhavý start aplikací v bytecodu, takže se tady spíš nebavíme o averzi vůči Javě jako takové, ale o minimálně sporném využívání Javy na některé věci.

[elviin]

Naprosty souhlas.

[zde]

"Saying that Java is nice because it works on all OS's ...

Až na to že Java nikdy neběhala na všech OS. Dokonce dodnes není ani kompatibilní sama se sebou, a to ani dopředně, ani zpětně. Případy kdy pro rozběhání aplikace X je třeba downgradovat JRE na konkrétní verzi jsou velmi běžné. Jako vtip dobrý, ale Java saje z úplně jiných důvodů- 1) nevhodná licence 2) nikdy nepřinesla to co slibovala.

[bubak]

Skvelej flamewar, uz chapu proc je tak tezke najit programatora, kteri resi problem a ne tyhle p*coviny.

V Jave nedelam kvuli nejake krase jazyka ci co, ale protoze ma zdaleka nejlepsi knihovny a IDE. A nez si ve svem Ccku/Lispu/Pythonu atd vyresite data storage, konfiguraci, formulare apod ja mam hotovy tri dalsi programy.

[kyknos]

Problém je, že já radši jeden pořádný program v céčku, lispu nebo pythonu než 10 programů v javě :)

[Hynek (Pichi) Vychodil]

... A nez si ve svem Ccku/Lispu/Pythonu atd vyresite data storage, konfiguraci, formulare apod ja mam hotovy tri dalsi programy.

Ano, někdo potřebuje sekat programy jako baťa cvičky a někdo potřebuje psát programy o kterých se vám zjevně ani nezdálo ať už co do požadované komplexity, spolehlivosti, nebo výkonu.

[Kyosuke]

Data storage? Něco jako AllegroCache nebo jiné lispí implementace on-disk heapu s ACID transakcemi, živou migrací schématu zcela za chodu, naprosto transparentní integrací do jazyka (vše, čím se perzistentní objekty liší od neperzistentních, je metatřída - persistent-class místo standard-class), nulovou konfigurací...co proti tomu postavíš, Hibernate? Chm. Lidi jen leckdy nevědí, co pro tyhle jazyky existuje. (Samozřejmě, Franz si účtuje za tyhle věci šílený prachy. Ale taky poskytuje dokonalý služby...)

[Hynek (Pichi) Vychodil]

Jojo, Hibernate To se povedlo. Chceš-li projekt zabít na výkonu, použij Hibernate. To by si mohli dát do reklamního sloganu.

[elviin]

Kdyz uz jsem se zacetl:

- Po uvedeni Javy se Sun nechal slyset, ze C/C++ do peti let vymizi. Nestalo se.
- Java je skvela v nekterych oblastech. Je komplementarni. Neni to vseresici nastroj.
- Java ma marketing.
- JVM (Java Virtual Machine) ~ VMware (Virtual Machine Ware)
- Java je platforma sama o sobe
- Java je proprietalni platforma
- GUI programy v jave jsou na desktopu pomaly. Rad se necham presvedcit o opaku.
- Narocnost "large scale" projektu diky permutaci pres OS, pocet bitu, verze Javy je stejne narocna jako v nativnim kodu
- Myslel jsem si, ze heslo "Write ones, debug everywhere" je jen zesmesnujici heslo, ze zkusenosti musim napsat: je to pravda
- Co se tyka vyhody bytecodu: Visty byly puvodne napsane v C#. Kvuli kompatibilite a vykonu se vse prepsalo znova v C++.
- Steve Jobs se vyjadril dost nelichotive o Jave. Zrejme jsou kapesni zarizeni i* na Javu stale pomala.

[Heron]

Visty byly puvodne napsane v C#. Kvuli kompatibilite a vykonu se vse prepsalo znova v C++.

Což je docela škoda.

[elviin]

Diky tomu vznikl C++\CLI .Net s lepsi vazbou na ISO C++ a dosavadni implementace v C/C++. Managed C++ byla slepa ulicka. Konec koncu si dovedu predstavit veselou koexistenci C/C++/C#.

[Miloslav Ponkrác]

Tato koexistence je docela běžná a velmi luxusní. Samotný Microsoft deklaruje, že nejrychlejší jazyk pro .NET platformu je C++.