Java 6x populárnější než .NET

Na www.neo.cz/~tomas/java.net/ vyšel článek TIOBE: Java 6x populárnější než .NET.

9.3.2006 17:03 | tomas kouba | Zajímavý článek

Komentáře

[Ignác]

Tak jiste, .NET je sracka nejvetsi

[Lukáš Zapletal]

Ze všech technologií, které kdy MS vyprodukoval, je tato ze všech nejpoovedenější.

[Jirka]

Mam jednu blbou otazecku, mozna trochu btw. . Jak jsem pochopil, .NET je neco jako Java, tedy vyuziva nejakou VM, ale neni omezen jen na jeden jazyk, vyber je praticky neomezeny.(Pokud je to tedy pravda). Takze ta otazecka je: pokud ma byt .NET konkurence k Jave, tedy co do multiplatformnosti, tak proc neexistuje nejaka .NET VM i pro Linux (muselo vzniknout Mono)? (Pokud je to tedy pravda). A dalsi souvisejici otazka: proc by mela mit firma, ktera ma temer monopol v urcitem segmentu, zajem na psani multiplatformnich aplikaci a tedy na podpore konkurencnich systemu?

[Honza "tux" Friesse]

Teď teda budu vypadat jako nějaký zastánce M$ produktů, ale co už.

Přímo M$ vyvynul jakousi implementaci pro BSD (tuším, že se dá sehnat pro FreeBSD). Ale myslím, že MS netouží po nějaké multiplatformnosti napříč OS, ale spíš napříč platformami. Tj. stejně jako je plná j2re a j2me, tak má MS plný .NET a nějaký mobil .NET. To je zřejmě ten hlavní důvod. Aby jedna aplikace napsaná v .NET mohla běžet i na mobilech, PDA, ...

MS zájem o podporu ostatních OS asi nemá, ale sám pochopil že WinAPI is dead. Když jsem se o to ještě zajímal (cca 4 roky zpět), tak jsem na Invexu na jejich stánku vyloudil takovou tlustější brožurku o .NETu. Když pominu reklamní kecy (kterých tam mnohem méně, než je obvyklé a spíš to byla fakta), tak dokonce psali, že nové Windows nebudou už mít WinAPI a pod tím .NET, ale bude to na stejné úrovni (nebo dokonce přesně naopak).

Navíc se MS asi moc nelíbilo, že většina aplikací vzniká v produktech Borlandu, místo jejich skvělého MFC a WinAPI. Tak si koupil pár vývojářů ,shodou okolností taky od Borlandu (to je ale náhoda, že?) a ti navrhli .NET.

No a poslední důvod pro .NET by mohla být dominance PHP na malé weby, a J2EE na velké weby. Přece jen, jejich ASP nebylo to pravé a .NET ASPX je přece jen trošku lepší (lépe řečeno, je to přímá konkurence J2EE).

Osobně si myslím, že .NET je jeden z technologicky nejlepších MS počinů (no aby ne, když je to okopírovaná Java).

[Michal Vyskočil]

No úplně ne, Javovský bytecode je dělaný jen pro Javu. dotNET má svůj mezijazyk MSIL, nebo jak se jmenuje. Ale to je jen pro staticky typované jazyky, chystaný Parrot bude něco podobného, ovšem pro jazyky typované dynamicky (Perl, Python, Ruby, ...).

[Honza "tux" Friesse]

Jestli to měla být reakce na to, že je to okopírovaná Java, tak jsem myslel koncepčně, ne že je to kopie 1:1.

Jinak napsat kompiler jiného jazyka než Java do java bytecode by neměl být celkem problém. Otázka je ... k čemu? Java je dobrý jazyk, kdo chce volnost C, nechť použije C. Kdo chce volnost Perlu, nechť použije Perl.

Jestli je MSIL pro staticky typované jazyky nevím, ale mám takový pocit, že někde v demo příkladech k .NET SDK (nějaká hodně postarší verze) viděl překladač Lispu do MSIL. A Lisp mi moc staticky typovaný nepříjde.

Větší rozdíl mezi Parrotem a JVM bych viděl v tom, že JVM je zasobníková VM, mezitím co Parrot je registrová VM. No uvidíme co z Parrotu nakonec vyleze.

[Michal Vyskočil]

Což o to, v MSIL běží i IronPython, ale podle ohlasů to není zcela bez problémové . Ad zásobní a registry, to máš pravdu. Taky jsem na Parrot zvědavý (i když více na pypy).

[Miloslav Ponkrác]

Teď možná budu taky trochu nahrávat Microsoftu. Microsoft strašně moc věcí zprznil a poslal ke dnu, ale .NET se mu podle mě povedl.

On .NET je tak trochu reakce na soud ze strany Sunu ohledně použití Javy, takže si to Microsoft zařídil tak, aby Javu nepotřeboval vůbec. Povedlo se mu přitom koncepci Javy podle mě výrazně vylepšit.

Java je možná dobrý jazyk, ale IMHO trpí tím, že je to strašně osekaný jazyk. Také javovská VM má byte kód přímo šitý na míru Javy. Microsoft to udělal tak, že nechal odborníky na kompilátory, které zaměstnal vytvořit nový byte kód, který je podstatně univerzálnější. Není naprosto problém přeložit byte kód Javy do byte kódu .NET, a takový převaděč dokonce Microsoft přímo dodává. Naopak je to prakticky nemožné, protože byte kód Javy nemá takovou "výrazovou schopnost" jako byte kód .NETu. Tím Microsoft dosáhl toho, že implementace jiných jazyků je daleko efektivnější.

Microsoft navíc netrpí snahou o co nejosekanější programovací jazyk a ani nezastává tendence, že pokud programovací jazyk dovolí jen trochu volnosti, tak všechno sletí na ústa, jak si představují vývojáři Javy v Sunu. Takže Microsoft okamžitě zavedl operátory, delegáty, události, možnosti řízení chování jazyka a spoustu dalších věcí.

Já kdybych si mohl vybrat mezi Javou a .NET, tak o Javu ani nezavadím.

[Martin]

Mam podobny nazor, Java ma velkou vyhodu v podpore vice OS, i kdyz Mono je take velmi pouzitelne(jedine, co je trosku problem je windows forms, ale i to se jiste vylepsi, napr. ASP.NET jede v Monu pod Apache paradne).

[Honza "tux" Friesse]

Sice jsem se do bytekódu (BC) .NETu nedíval, ale zase na druhou stranu nevím, co je na Java BC tak osekaného. Jedinou věc, o které vím, je, že do kódu není možné přidávat nativní kód (tak jak to umožňuje .NET). To bych viděl spíš jako obrovskou nevýhodu (hlavně co se týče přenositelnosti).

Když se člověk podívá na rozdíli mezi Javou 1.4 a 5, tak je jich hodně. Ale pouze co se týče jazyka (syntaxe). Většinou syntaktický cukr (autoboxing,...). Ale rozdíl v BC? Troufám si říct, že žádný.

Takže s těch vlastností, co jste vyjmenoval.

Operátory - Pokud to má být možnost předefinování, tak to je jen syntaktický cukr (SC). Šel by bez problémů implementovat.

Delegáty - No moc o tom nevím, nicméně se mi nezdá, že by s tím šlo něco víc, než s Interface a zase mi to příjde jako SC (nebo by to tak šlo implementovat).

Události - V Javě jsou.

[Miloslav Ponkrác]

Já to řeknu zcela bez obalu, Java není tak skvělá, jak by si spousta lidí přálo.

Bytekód Javy se od bytekódu .NETu liší v mnoha věcech. Nejen tím, že lze přidat nativní kód, ale už samotný virtuální assembler obou se výrazně liší. A to tak, že u .NETu je mnohem komplexnější, promyšlenější, než u Javy. Proto jsem napsal, že konverze Java byte kód -> .NET byte kód je triviální, zatímco konverze opačným směrem je téměř nemožná. A nemluvě už vůbec o bohatosti metadat v .NETu a uživatelských atributech. Jinak .NETovský framework má obrovsky silný verzovací systém, podstatně propracovanější, než Java,která vlastně nic takového vůbec nemá a Javovská mašina tohle naemulovat nedokáže. Dalším rozdílem je, že .NET na rozdíl od Javy nevyžaduje žádný vztah mezi třídou a souborem. Těch rozdílů je mnohem více, ale je tady na tomálo prostoru.

Kolem Javy je bohužel hodně propagandy a kolem Javy se bohužel hodně razí heslo, že co neumí Java je špatné a nečisté.

Co se týká syntaktického cukru, tak to je to, co Javě moc moc chybí. Ale na úrovni byte kódu je pravda, že operátory by nejspíš šly naprasit do Javovského byte kódu. Delegáti jsou ovšem něco úplně jiného, než se domníváte.

Sun při konkurenci .NETu dost věcí do Javy 1.5 doplnil, protože jeho řeči typu, že toto není dost čisté a toto není potřeba začaly být dost chatrné a při srovnání .NETu a Javy hrozilo Javě dost fiasko. Takže už jen to, že .NET probral Sun z usínání na vavřínech je dobrá zpráva i pro Javu.

[Kyosuke]

Komplexnější možná, ale přišlo mi, že C++oidním směrem... K čemu value typy? Kvůli optimalizaci? Kterou Java 1.6 bude dělat automaticky? Java se snaží o jednoduchost, to jí docela jde. Ale osobně mi přijde o dost jednodušší a přitom mocnější Objective C a OpenStep, respektive jeho potomek. Ať se tím probírám, jak chci, smalltalkovský model mi z dnes široce používaných věcí přijde stejně nejmocnější...a přitom není nijak složitý.

Když už něco jako CIL, tak pořádného. Kamarád má vizi v podobě jisté formy typovaného lambda kalkulu, který by umožňoval brutální optimalizace (kdo zná Stalina, ví, o čem mluvím... ), přitom by mohl být abstraktní a přenositelný. Jen si nejsem jistý, jak moc náročný by byl...ehm..."linker"... Pravda je, že takovýhle prostředek by umožňoval slušně implementovat opravdu snad všechny jazyky (které se obejdou bez pointerů), nejen "staticky objektové, single-inheritance s rozhraními".

[Miloslav Ponkrác]

Já bych Vás poopravil, Java se ani tak nesnaží o jednoduchost, ale hlavně o ideologii a jakousi politickou čistotu realizující ideály zvolené Sunem. Jednoduchost, nebo použitelnost Javy je až na druhém místě za "čistotou". Mě osobně přijde psát v Javě složitější a náročnější, než třeba v Objective C, nebo C++, nebo C#. Je to možná můj osobní pocit, že Java je až tak jednoduchá (ve skutečnosti není jednoduchá, jen brutálně osekaná, což je rozdíl), až člověk musí trapně ohýbat a přizpůsobovat myšlení Javě, zatímco v jiných jazycích se cítím mnohem volnější a přirozenější.

Mě jakýkoli dynamický jazyk založený Smalltalkovským směrem přijde dost úchylné srovnávat s Javou už z principu, a je jedno jestli se mluví o Objective C, a nebo jde o Smalltalk samotný. S jazyky posílajícími zprávy se zachází jinak a přistupuje se k nim s jinou filozofií, než s jazyky volajícími metody jako to dělá Java.

Ale abych reagoval na Váš úvod. Myslím si, že C++oidní směr je správnější. Rozhodně je to správnější cesta, než cesta Javy, která oseká jazyk až na kost až je ten jazyk jen o kousek výš nad hranicí zvanou totální nepoužitelnost a aby to tak nebilo do očí nazve se to "čistotou" a tato vlastnost se začne vychvalovat na všechny strany. Srovnávání Javy se Smalltalkem, Objective C, nebo dokonce s čímkoliv funkcionálním je jen nepochopení faktu, že srovnávat se má srovnatelné, a že jak pojetí typů, tak pojetí objektů něřku-li celá filozofie těchto jazyků je úplně jinde, než stojí Java.

Jen tak mimochodem, víte o tom, že C++ je jedním z jazyků, který je možné používat pro vývoj v .NETu? Jedním z vynikajících vlastností .NETu je perfektní integrace s již existujícími kódy.

Je strašně hezké, že Java bude automaticky optimalizovat, ale o výsledku této optimalizace si povíme až to Sun vypustí. Silně pochybuji, že to bude lepší, než řešení z .NETu. Mě se řešení z .NETu líbí víc, programátor to má pod kontrolou. V .NET můžete mít víc kontrol kódu za běhu, než provádí Java, chcete-li mít největší bezpečnost, nebo můžete ubrat, chcete-li mít maximální rychlost. Tuhle možnost samozřejmě máte, nemusíte se jí vůbec zabývat, nechcete-li.

Já bych třeba rád, aby Java skutečně udělala něco s tou jednoduchostí. Třeba aby se objekty nechovaly úplně jinak, než primitivní typy a abych mohl začít psát třeba výrazy typu 12.ToString(), jako to jde v C#. Proč celé číslo v Javě nemá metody? Proč Java nemá operátory? Nebo snad chcete proklamovat jenoduchost stylem, že při matematickém výpočtu s maticemi Java ukáže svojí "jednoduchost" tímto:

vysledek = (a.add(b).mul(c)).add(d).mul(b.add(c));

Já tedy rozhodně dávám přednost jednoduchosti C#/C++/ a každého rozumného jazyka:

vysledek = (a + b * c) + d * (b + c);

Vůbec s tou jednoduchostí Javy bych mohl pokračovat dál.

Jinak souhlasím s tím, že jak Java, tak i celý .NET je jen na půli cesty. Existují určitě lepší technologie a stejně se jednou všichni vrátíme k LISPu.

[Kyosuke]

Ale já neřekl, že všechno v Jave jě jednodušší a hezčí... Value typy nechápu u .NETu, primitivní typy zase u Javy.

Mimochodem, nesrovnávám nesrovnatelné, srovnávám to, co mi je nabízeno k použití, pokud chci něco vyvinout. Nevím, proč bych měl brát nějaké ohledy na filosofii, v tomhle směru jsem pragmatik - prostě sáhnu po něčem, co mi přijde výhodnější...

Přesto trvám na tom, že úplně nejlepší je podle mě mít kompilátor, který odstraní všechny kontroly, o kterých je schopný prokázat, že nejsou zapotřebí. Java tyhle vlastnosti přidává, C++ a C# kvůli tomu nabalují hromadu věcí ("umění pro umění" podle mého soudu). Opravdu mi přijde ideální jazyk (nenarážím na nějaký konkrétní, jen ty optimalizace musí sémanticky podporovat, což C ani C++ ani styl práce v nich leckdy neumožňují), ve kterém abstraktně napíšu algoritmus, odladím ho v méně dokázal vyprodukovat. Je to o jeden nebo dva řády náročnější úkol než udělat kompilátor C/C++, třeba i s optimalizacemi, ale věřím, že jednou tyhle věci budeme mít. Ono nám totiž ani nic jiného nezbyde, pokud bude složitost softwaru tímhle tempem narůstat.

[Miloslav Ponkrác]

Stručně: Mám pocit, že máme naprosto stejné názory.

Já jsem také pragmatik, ale možná se lišíme v tom, že si uvědomuji, že svět není černobílý a slovo výhodnější může mít v závislosti na okolnostech různé výsledky.

Po 20 letech programátorských zkušeností mohu říci, že jsem dospěl k názoru, že žádný ideální jazyk neexistuje. Setkal jsem se s jazyky, které obdivuji (Smalltalk, C++, LISP, Ada), protože něco přinášely a jazyky, které pro mě byly obrovským zklamáním (Java, Pascal). Časem jsem si začal uvědomovat, že ty jazyky, které mě zklamávají mají až významně často jednoho společného jmenovatele - snaží se v první řadě o "čistotu", kterou někdy dotahují až ad absurdum. Ty jazyky, které obdivuji něco přinesly a posunuly laťku programování někam dál, zatímco ty druhé, které mě zklamaly většinou nejsou ničím jiným, než plagiátem. Java je vykradené a osekané C++.

V čem se shodujeme je Váš cíl. Podle mého je nejlepší kompilátor, který nezatěžuje člověka ničím, co není nezbytně nutné. Chce to samozřejmě brutální optimalizátor. Na druhé straně ale jazyk, který neumožňuje nepovinně zapsat další kontroly a optimalizační informace podle mě je špatný. Ale konečný cíl, o kterém mluvím já a Vy je shodný.

Já jen si neodpustím poznámku, proč nemám Javu rád a mám raději C++. C++ je logický a konzistentní jazyk, zatímco Java je zmršenina. Mohl bych mluvit dlouho, ale třeba jen to, že operátor = v Javě jednou kopíruje hodnoty, podruhé zase jen odkazy na hodnoty je nelogické. Operátor porovnávání == někdy porovnává hodnoty, jindy zase jen odkazy na objekty. Java se brání přetěžování operátoru a má všude plno řečí, jak je to špatné, aby zavedla operátor + pro stringy jako výjimku.

Na jedné straně mluvíte o automatické optimalizaci Javy, kterou má dělat kompilátor a jazyk sám, ale samotná Java na bedra programátora přenesla určité zbytečné optimalizační kroky, které je potřeba udělat ručně. Jen jeden pitomý příklad, pro práci se stringy existuje String a StringBuffer, které obojí znamenají řetězce, ale programátor je nucen podle způsobu práce ručně optimalizovat práci se stringy použitím jednoho, či druhého a případně se starat o konverze mezi nimi.

Tak bych mohl mluvit dál a dál, ale na to není prostor. Žádné z výše uvedených nelogičností není v C++ a podle mě je C++ možná trochu přeplácaný, ale daleko lépe postavený jazyk, než Java.

C# bohužel některé věci opsal od Javy. Některé programovací jazyky by se podle mě neměly používat za vzor, protože jen kazí (Java, Perl).

[Kyosuke]

Jo, taky jsem si myslel, že "expresivita" CILu je bezva. Než mi došlo, o kolik důležitější je výkonný runtime. Podle mě si na kvalitní univerzální (!= statickou objektovou) meziformu ještě počkáme.

[Miloslav Ponkrác]

Souhlasím, toto ještě není poslední slovo. Já si dokonce myslím, že kdyby Microsoft si nedal jako jeden z koncepčních vzorů Javy, že by .NET dopadl mnohem lépe. Java je bohužel dost špatný a omezený vzor.

[VícNežNic]

Pokud se druhý odstavec zabývá tímto, pak můžete na první pohled vidět, že jde pouze (?) o výzkumný projekt a ke skutečné multiplatformní verzi .NETu to má dost daleko.

[Spike]

Jak, neexistuje? To by se měla objevit sama od sebe, z ničeho? Prostě vzniklo mono... Jako multiplatformní implementace CIL/konkurence .NET Framework od Microsoftu.

[Jirka]

Tak treba proto, ze kdyz uz delam nejakej produkt, tak se ho budu snazit rozsirit. Sun treba udelal Java VM i pro linux, bsd, a snad vsechny pouzivanejsi architektury. A nikdo se mu neprosil.

[Jirka]

A ani ne rozsirit, ale spis udelat to, co slibuji, tedy multiplatformnost. Linux a cele FSF je pro ne realna konkurence a hrozba, jinak by nevyhazovali miliony na kampane jako "Get the facts", tudiz je pro ne neprehlednutelny a ne nezajimavy.

[cronin]

Sun treba udelal Java VM i pro linux, bsd, a snad vsechny pouzivanejsi architektury.

Tak minimálne ten VM od Sun-u pre BSD by som chcel. Kde sa dá stiahnuť? Plácaš nezmysly, kámo.

[Jirka]

http://www.freebsd.org/java/

placas nesmysly kamo

[Jirka]

http://www.freebsd.org/java/

placas nesmysly kamo

[cronin]

Ahááá, tak toto je VM od Sun-u pre FreeBSD. Sun portuje VM na 3 (slovom tri) platformy: Solaris, Windows a Linux. Plácaš nezmysly, kámo.

[Lukáš Zapletal]

navíc já pamatuji doby, kdy Linux byl naprosto stranou. jre a nástroje ve verzích pro Linux vycházely pozdě atd...

sun je fajn, ale k dokonalosti má daleko

[Jirka]

The FreeBSD Foundation has negotiated a license with Sun Microsystems to distribute FreeBSD binaries for the Java Runtime Environment (JRE™) and Java Development Kit (JDK™).

Takze to asi znamena, ze nekdo si doma zbastlil Java VM pro FreeBSD, ze jo? Podobne jako Mono.

placas nesmysly kamo

[cronin]

The FreeBSD Foundation has negotiated a license with Sun Microsystems to distribute FreeBSD binaries for the Java Runtime Environment (JRE™) and Java Development Kit (JDK™).

A vieš, aký je tento reťazec starý a koľkokrát sa veci odvtedy zmenili? To, že vyjednali licenciu, ešte neznamená, že existuje JVM od Sun-u pre FreeBSD. Sun svojím prístupom popiera existenciu BSD sveta tak v Java technológiách, ako aj v Solarise (ZFS vs. Vinum, zony vs. jaily, projekt Janus vs. Linux ABI vo FreeBSD, ...). Jediná zmienka o BSD je u Sun-u nanajvýš v článkoch o histórii Solarisu.

Používam FreeBSD denne a nič by ma viac nepotešilo, ako JVM pre FreeBSD, nakoľko ma Java živí. Skús vo FreeBSD použiť napr. GZIPOutputStream() alebo GZIPInputStream() a nebudeš sa stíhať čudovať, alebo si nainštaluj Sun Java System Application Server či nebodaj IBM WebSphere Application Server.

Java pod FreeBSD nemá šancu prejsť compatibility testami. To, že nejaká Java pod FreeBSD vôbec existuje, je heroické úsilie dvoch ľudí, ktorých už voľakedajšie nadšenie portovať Javu pod FreeBSD opúšťa. Absencia produkčne použiteľnej Javy pod FreeBSD je dôvod, prečo momentálne uvažujem o prechode na notebook-u na Solaris, i ked mi FreeBSD inak veľmi vyhovuje.

Sun portuje Javu na Linux len a len preto, že tak urobilo IBM; musia držať krok s konkurenciou.

[Taky Jirka]

A proc SUN udelal JVM pro vic platforem? Protoze jestli chtel, aby se java rozsirila, tak proste musel, ze.... M$ staci widle a pokud chce nekdo portovat .NET jinam, NIKDO mu nebrani. Sami borci od Mona rikaji, ze jim chlapci z M$ obcas pomuzou...

[cronin]

A proc SUN udelal JVM pro vic platforem? Protoze jestli chtel, aby se java rozsirila, tak proste musel, ze....

Nie. Sun urobil JVM pre tie platformy, pre ktoré existujú [vážne] konkurenčné JVM, t.j. Window$ a Linux.

[Karel]

Jo M$ udela .NET pro linux a lidi pak Widle nebudou potrebovat... chlapce nestastnej, ty toho moc v hlave asi nemas...

[Jirka]

V hlave ma prazdno nekdo jinej. Co asi lidem chybi v Linuxu? Photoshop, ucetnictvi,... APLIKACE a ne Windows.

[Karel]

Chlape, ty si ze me delas srandu, toto neni mozny. Chapes, ze kdyz nekdo udela Photoshop(ucetnictvi....) pod .NET a M$ udela .NET pod linuchem(stejne kvlitne), tak ti photoshop pojede i pod linuchem a od M$ pak widle nikdo nekoupi. Vis proc ten photoshop nejede ted? Protoze na linuxu neni Win32API(je wine, ale pro nazornost, vite jak :) a .NET je neco jako Win32API(z pohledu aplikace, ktera vola fce systemu a kdovi ceho). Takze tak.