Miguel de Icaza o Moonlight, Mono a Microsoftu

Miguel de Icaza se v rozhovoru pro derStandard.at vyjádřil k vývoji Moonlightu, Mono a k otevřenosti Microsoftu. Dotýká se také dokumentace microsoftích API, podpory a financování projektů a plánů vývoje.

5.8.2008 07:57 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[Sid]

Z citanie toho co by rad urobil mi naskakuje husia koza - jedine co potrebujem je zrovna aby kazdy applet v GNOME mal 20MB a pritom vykonaval absolutnu trivialitu - ok nech robia mono ale nech ho netlacia stale do GNOME :(.

[Dent]

Těch 20MB dosáhne asi těžko. Mono bude velké, ale samotné aplety snad budou mít normální velikost - jako každý C# program.

[stick]

Presne tak, programy v C# su naopak pomerne male, cize ak si myslel 20MB na disku, tak to nie je pravda. Ak si myslel 20MB v pamati, tak to asi tiez nebude take zle, pretoze velka cast Mono runtime bude v pamati iba raz.

[JoHnY2]

Linuxari maj o .NETu pomerne zkresleny predstavy. V zivote nevideli normalni aplikace .NET na widlich a vetsina ani tu samou aplikaci pod Monem a soudej podle fam.

[xindl]

Jop třebas takovej smarteam je lahudka. Doporučuji všem blbečkum na mangerských křeslech aby objednávali jak o život. )) . Ale co, já gnomákum MONO přímo doporučuji, brzo se GNOME přejmenuje na windows desktop a bude po prdeli. ))

[Sid]

akych fam??? nevidim ziadny rozumny dovod preco nieco previazat dokopy (gnome a mono) ked to pouziva zopar programov (beagle,f-spot,tomboy). Ci podla vas hociktora z tychto veci je tak uzasna ze stoji za tych xyz MB pamate pre mono? nabuduce snad aj bash niekto napise v .net osobne proti mono a .net nic nemam len proste sa mi nepaci taketo miesanie. nabuduce niekto zo Sun zase prida nejaky applet v jave a bude to mega gulas

[mutable]

Nač .NET když je tu Java?

V zivote nevideli normalni aplikace .NET na widlich a vetsina ani tu samou aplikaci pod Monem a soudej podle fam.

Viděl, co je na nich tak skvělýho? Klasický GUI aplikace, stejný jako ty napsaný pomocí Qt, Gtk nebo v Javě.

[Vašek Lorenc]

Protože pro .NET se dá zvolit poměrně dost programovacích jazyků, nejen C#. Byl pro to ostatně i navržen.

[mutable]

Pro JVM dnes už taky (Java, Groovy, JRuby (, Scala?)).

[luky]

Zatimco javovsky (nebo jakykoliv jiny) bytecode nejde vytvaret v jinem jazyce? Vy jste opravdovy odbornik.

[Kyosuke]

JVM má pro jiné jazyky mnohem menší podporu. CLR má třeba tail call prefix, takže se do CIL kódu dají kompilovat jazyky s povinnou optimalizací tail callů, jako je třeba Scheme. (Ale upřímně si myslím, že přechod z JVM na CLR pro spoustu jazyků znamená přechod "z bláta do louže". )

[Ladicek]

Nevíš o nějakém přehledu rozdílů mezi CLR a JVM v tomhle ohledu? Nebo sis přečetl a porovnal obě specifikace?

Celkem by mne to zajímalo. Před časem se na tohle téma objevilo pár slov v komentářích k blogovému zápisku Gilada Brachy invokedynamic a odnesl jsem si z toho, že žádné velké rozdíly mezi JVM a CLR nejsou:

On the subject of language generality in the .NET CLR versus the JVM, my understanding from discussions with Jim Miller and other principals involved in developing the CLR is that the CLR offers only a few features that are missing in the JVM. The only two that I recall are: (i) mandated support for tail-call optimization and (ii) an interface method naming scheme that implicitly includes the interface name as part of the method signature (so two methods with the same explicit signature in different interfaces do not collide if they are in herited by the same class). Of course .NET 2 includes explicit support for generics, but this support is specifically directed at C#. There is no explicit support in CLR for continuations.

Pravda, už to jsou dobře tři roky, možná v DLR byly nějaké změny, nevím.

Ostatně mám za to, že největší rozdíl mezi Javou a .NETem z pohledu podpory více jazyků je marketingový, např. překladače Ady do javovského bajtkódu existovaly dřív než první verze .NETu

Mimochodem tail cally v Javě s největší pravděpodobností budou (když je vyžadují ve Fortressu, který má být implementován na Javě).

[Kyosuke]

Když jsem byl mladý a blbý, měl jsem přednášku na OpenWeekendu, na kterou jsem si tyhle věci nastudoval. (Ale když jsem se na to video pak podíval, tak jsem si řekl, že už nikdy přednášet nebudu, nebo aspoň ne před přístrojem, který tu hrůzu vošklivou vodpornou zachová pro další generace. ) Takže jo, tak trošku jsem studoval specifikace. Ale už si to sám moc nepamatuju, protože jsem krátce poté dospěl k názoru, že nativní kompilátory jsou prostě nativní kompilátory, a navíc jtra měl velice přesvdčivou přednášku o Common Lispu, který se ale nad JVM/CLR snad ani v úplnosti udělat nedá.

[Ladicek]

Když jsem byl mladý a blbý, měl jsem přednášku na OpenWeekendu, na kterou jsem si tyhle věci nastudoval. (Ale když jsem se na to video pak podíval, tak jsem si řekl, že už nikdy přednášet nebudu, nebo aspoň ne před přístrojem, který tu hrůzu vošklivou vodpornou zachová pro další generace. )

Je to někde k vidění? Považujme mne za tu další generaci

[Michal Vyskočil]

gg: openweekend Common Language Runtime - někde to tam je

[Ladicek]

Jasně, už to mám, díky

[Kyosuke]

Zrada!

[Vašek Lorenc]

Ale jistě že jde.. ale byla Java navržena pro jiné jazyky? Ostatně už to řekl kolega výše.. A co se JVM týče -- teď se mi třeba líbí implementace Lispu pro JVM. Otázka ale zněla trochu jinak.

Odborník ale pochopitelně nejsem, to máte pravdu.

[Kyosuke]

Nač .NET když je tu Java?

Protože pro použití na desktopu je Mono asi poněkud vhodnější než suní Java, která dává smysl možná tak na server? (Hint: sdílení předkompilovaného kódu mnoha současně spuštěnými procesy)

[Ladicek]

Tím se myslí něco jako Class Data Sharing?

[Kyosuke]

Nemyslí, protože Class Data Sharing funguje jen na x86, funguje jen pro třídy "předbalené" Sunem (nelze předgenerovat mezi procesy sdílené nativní .so-čko pro zcela libovolnou knihovnu, jako to umí Mono) a nejsem si vůbec jistý, co HotSpot dělá pro to, aby ty základní třídy později nerekompiloval. Možná to o něco málo pomůže aplikacím, co nepoužívají o moc víc, než rt.jar, ale co takové NetBeans na AMD64? JBoss/Spring/BEA na serveru ať se spouští třeba čtvrthodinu, ale uživatel desktopu to tolerovat nebude. Je ostuda, že i desktopové aplikace psané v Pythonu a podobných jazycích jsou svižnější než Java.

[Ladicek]

Takže v podstatě implementační detaily Ne že by nebyly důležité.

S tím Pythonem a spol. je to vůbec zajímavé. Hádal bych, že důvodem je použitý grafický toolkit, jak by na tom asi byly ty Pythony ve srovnání s javovským programem s GUI napsaným v Qt Jambi?

[Sid]

Troska som to nespravne napisal - ide mi o to ze bud nech cele gnome pouziva mono alebo nech tie zavislosti tam nie su - len tak pre srandu si skuste pozriet taku blbost ako tomboy - kvoli takejto "obrovskej" funkcionalite mat zavislost na mono mi pride uletene.

[Dent]

Ale tuto závislost vás nikdo nenutí instalovat. Gnome bude bez mono fungovat dál, jen nebude využívat dané applety, které to mono vyžadují. Na tom nevidím nic špatného. Pokud se to někomu nebude líbit, nebude to používat.

Takhle je to se vším, také nemusíte v Gnome používat aplikace psané v QT (například). Tady je cítit anti-MS nálada. Mono je částečně produkt MS - je tedy špatné.

[Luboš Doležel (Doli)]

Spíš je to další nenažraný software, který se snaží vecpat na desktopy. Opravdu snadnost vývoje v GTK# ve srovnání třeba s GTKmm dokáže odůvodnit nutnost VM pro Mono? Jako člověk, který dělal v GTKmm, musím říct, že ne. Je to jen zbytečné břemeno pro systémy uživatelů, protože někdo chtěl využít cool technologii.

[Ivan]

Ja bych rekl ze urcite ano. Cas CPU je cim dal levnejsi, zatimco cas lidi(treba muj) se neustale zdrazuje. GTKmm jsem pouzival cca pred 5ti lety ve verzi 1.2 a muzu rict, ze jsem z toho malem zesedivel. GTK 1.2.7 opravovalo furu chyb, ale GTKmm fungovalo jen oproti 1.2.6 a misto toho abych neco vyvijel jsem backportoval fixy v GTK. To ze nejake prostredi setri cas vyvojarum pri vyvoji znamena, ze jim to setri cas i pro odhalovani chyb. Kouknete si na tuhle moji oblibenou chybu. Vice nez 2 roky se evolution tvaril, ze se umi pripojit k exchange, akorat ze nevytrzel bezet dyl nez 10 minut a pak spadnul na segfault. Chyba byla v jedny z cca 30ti knihoven, ktery evolution pouziva. Kvuli race condition jedna knihovna prepsala kus pameti a evolution po nejaky dobe spadnul v uplne jiny knihovne. Vyvoj aplikaci v gcc,g++ ma tu chybu, ze muzete udelat chybu, ktera je prakticky neodhalitelna. A cim dele aplikaci vyvijite, tim vice takovych chyb mate. Casto se mi stavalo, ze jsem stravil tyden v gdb-cka abych nakonec nakam pripsal jednu radku. Neco takoveho se lidem, kteri pouzivaji v javu, c#, perl, python, ... nestava.

[Käyttäjä 11133]

Neco takoveho se lidem, kteri pouzivaji v javu, c#, perl, python, ... nestava.

A víš co je nejlepší? Že lidem co neprogramují se nestává, že by museli přemýšlet nad tím kterou použít datovou strukturu a lidé, kteří nejezdí autem neřeší, že jim dochází benzín, lidé kteří nejezdí na kole z něj nespadnou,...

[Luboš Doležel (Doli)]

Na C/C++ potřebuje programátor více zkušeností, ale se správnými knihovnami je vývoj stejně rychlý. GTKmm jsem používal a na bugy jsem nenarážel.

Cas CPU je cim dal levnejsi, zatimco cas lidi(treba muj) se neustale zdrazuje.

Jenže já si nekupuji nový hardware proto, aby mohli vývojáři více prasit. Já si jej kupuji kvůli výkonu.

Kvuli race condition jedna knihovna prepsala kus pameti a evolution po nejaky dobe spadnul v uplne jiny knihovne.

A v ostatních jazycích je každá drobnost omutexovaná, že nehrozí race condition?

Casto se mi stavalo, ze jsem stravil tyden v gdb-cka abych nakonec nakam pripsal jednu radku.

Tak máte v kódu bordel, co k tomu říct.

[Kyosuke]

A v ostatních jazycích je každá drobnost omutexovaná, že nehrozí race condition?

Jsou jazyky, co takové blbosti jako mutexy nepotřebují. Ale zatím tyhle věci používá tak málo lidí, že argumentovat tím proti Cčku je skutečně hloupé, to je pravda. (No i když zase...možná je to skutečně spíš problém programátorů v Cčku než Cčka samotného. )

[ivan]

Tak máte v kódu bordel, co k tomu říct.

Ten bordel v kodu mame vsichni, kdo pouzivame opensource programy. Vy delate jako kdybyste nikdy nechledal chybu v nejakem opensource projektu. I programatori jsou jenom lide, a dokonce i oni delaji chyby. A pokud jim neco umozni ty chyby snaze opravavat tak je to jen dobre.

Programy napsane v Ccku, mohou obsahovat tezko odhalitelne chyby, ktere by jinde nemohly vzniknout, nic vic nic min. Naposledy jsem narazil na takovyhle problem: Muj program vytvoril 2 PDF soubory. Ty soubory se lisily pouze poradim objektu v cross-reference table. Pomoci ghostcriptu jsem ty PDFka vyrenderoval do bitmapy. A ty bitmapy kupodivu nebyly stejne. Rozdily byly v anti-aliasingu u nekterych pismen. Popr. v osazeni radek. Nejspise nekde nekdo pouzil kus neinicializovane pameti, a kvuli tomu rendering true-type pismen dopadl ruzne. Kdyz sectu pocet radek ghostscriptu knihovny freetype a dalsich, tak mam asi 5 milionu radek kodu, ktery musim projit abych zjistil kde a kdo udelal chybu. valgrind, gdb ani e-fence, mi nepomuze. Muzete mi teda poradit jak se resi takovehle chyby?

[Luboš Doležel (Doli)]

Vy mi tedy tvrdíte, že takovou chybu v jiných jazycích neuděláte? Tam prostě místo neinicializované paměti budete mít v paměti nějaký porouchaný default a jste na tom stejně. A počet řádek nevím jak souvisí s věcí, kterou tu diskutujeme.

[Sid]

blbost - aka MS-antinalada? akurat mi pride ako blbost ze nieco co v pohode moze mat 500KB ma vdaka zavisloti na mono xy MB. tot vsetko. jasne nemusim si to nainstalovat ale to pre mna nie je argument od prostredia cakam konzistentnost (tj. ked napr je gstreamer nebude kazda aplikacia gnome si robit vlastne kniznice pre multimedia) - skor mi to pride ze Novell sa tam hra na svojom piesocku s mono a robi to co Sun v openoffice s java.

[Dent]

Těch xy MB závislostí beru jako daň za to, že aplikaci např. v C# dokáže s trochou snahy napsat i cvičená opice.

Od prostředí očekávám i já nějakou jednotnost, ale nevidím důvod, proč do něj nepřidávat nové vlastnosti.

Možná je mono pomalé, možná je příliš velké a náročné, ale je jednoduché. V C++ bych se svými znalostmi rozhodně nenapsal to, co dokážu napsat v C#.

[Luboš Doležel (Doli)]

Přirovnání: Ber mě jako občana, který je nerad, když mu přes jeho ulici jezdí tanky. Tankista se vymlouvá, že řídit auto by pro něj bylo moc těžké, protože by musel dávat přednost a vůbec se vyhybat okolním překážkám. Navíc říká že se tam člověku nestane nehoda (crash). Tudíž jsou podle něj tanky OK, přece se dělají širší silnice, aby se tam vešly...

Takový přístup se mi vážně nelíbí.

[Dent]

Hezké přírovnání :)) Ale v tomto případě ten tank (mono) do mojí ulice (systém) jezdit nemusí. Je jen na mě, zda si ho tam pustím, či nepustím.

Trochu bych to upravil - do mé ulice je možnost nechat dovážet zmrzlinu (alá Family Frost), ale distribuční firma ji rozváží pouze tanky. Stojí mi za to ta zmrzlina?

[Luboš Doležel (Doli)]

Ale v tomto případě ten tank (mono) do mojí ulice (systém) jezdit nemusí. Je jen na mě, zda si ho tam pustím, či nepustím.

Naštěstí. Bohužel se čím dál více věcí rozváží pouze tanky.

[Dent]

To je druhá stránka věci. Netvrdím, že by se do mono mělo začít přepisovat celé Gnome, ale když v něm budou psány jen některé aplikace a budou psány kvalitně, proč ne? Rozdíl v rychlosti by neměl být až tak drastický (odhadoval bych to na jednotky procent, ale opravdu pouze hádám - nemám to ničím podložené) a těch pár MB zabrané RAM kvůli nahraným knihovnám mono mne taky nezabije. Od toho tu RAM mám :))

Mám zkušenosti pouze s programováním pro .NET (pokud nepočítám těch pár miniskriptíků v BASHi a PHP), takže mono mi umožňuje použít své znalosti i na jiné platformě - a to vítám.

[Martin Böhm]

V C++ bych se svými znalostmi rozhodně nenapsal to, co dokážu napsat v C#.

A co Vám tedy příjde na C++ tak složité, resp. složitější než C#?

[Dent]

Popravdě řečeno - ani nevím. Pokud porovnám dva stejné projekty psané v C++ a C#, přijde mi syntaxe C# čitelnější a jednodušší. Je to pouze subjektivní, někomu to jistě bude připadat naopak.

[Sid]

V poriadku a to je prave problem - programovanie je o programovani a je jedno ci je to C++,C,C#,java alebo hocico ine. Problem je to ze hocikto kto vdaka IDE dokaze urobit jedno okno ktore cosi vypluvne si automaticky mysli ze je programator. To ze dokazem uvarit sackovu polievku zo mna nerobi automaticky kuchara. Nieco take ako efektivita, navrh atd je podobnym ludom uplne ukradnute - ale spat k veci ide o to ze kazdy nadava ake je gnome pomale, pamatovo narocne atd. - jasne ked napr si prihodite na poznamky tomboy namiesto sticky notes. Nie kazdy bude skumat ze ake su zavislosti medzi balickami - a na cestu smerom MS by som nechcel aby sa gnome vydalo - myslim v smere chcete novy OS - ok ale sup sup do obchodu a pekne si doneste novu masinu ktora ma 2x viac pamate a 2x silnejsi procesor

[Dent]

Netvrdím o sobě, že jsem programátor. To zase ne. Trochu se o to zajímám a .NET mi před časem přišel jako dobrá volba. Nestydím se za to, že programuju v IDE. Nestydím se za to, že pokud už dělám okenní aplikaci, okno si navrhnu a naklikám v opět v IDE. Nepotřebuju se cítit jako hacker, když si píšu malou utilitku, která mi ušetří práci.

Souhlasím s vámi v tom, že nechci, aby se Gnome (a ani KDE, či cokoli jiného) vydávalo cestou k MS. Jinak řečeno - nerad bych viděl, jak se základní aplikace těchto prostředí přepisují pod mono. To opravdu ne. Ale na těch pár doplňků, které nejsou nutné pro běh systému, mi to nevadí.

[alblaho]

Neříkám, že bych stál zrovna o gnome-panel v monu, ale současná implementace je šmejd.

Navíc se v poslední době objevují applety v Pythonu a co se týče paměťové náročnosti, tak to vyjde s Monem na stejno.

[Sid]

presne ale ide o to ze ked jedna vec bude v mono, druha v python, tretia v jave tak vznikne ozaj strasnost - nech je kludne zalozene na mono ale potom vsetko :)

[Boris Dušek]

To vyřeší IronPython, nebo Jython ;) - vybere se jeden runtime z množiny {Java,.NET}, a nad tím budou běžet dynamické jazyky a kompilovat se do toho budou exotické statické jazyky (C,C++ bych samozřejmě nechal běžet nativně)

[peter]

existuje aj implementacia Javy pre Mono/.NET - ikvm.net

[Josef Kufner]

Vim vs. Emacs, Qt vs. GTK+,... hm, takže hit letošní sezóny je "JVM vs. CLR" ?

[ashen]

Ja vim, ze mam svobodu volby. Vim, ze tohodle cloveka muzu klidne ignorovat, protoze me ve sve podstate nicim neomezuje. Tim, ze nepouzivam GNOME ani gtk mi muze byt jeste vice ukradeny ....Tak proc mi **** pokazde pri precteni jeho jmena praska zilka v mozku??

[Vláďa]

Asi jste nervák.

[Mandarinka]

^_^

Přesně. Jak jsem si ho četl, mluvil pořád rozumě, k věci, nikoho neurážel. Blbej není ani on, ani to, co tam říká.

[J. M.]

[Pavel]

Pravdepodobne jste netolerantni hovado, co nedokaze respektovat nazor jineho cloveka, tim spis, pokud se tento dotyka oblasti, o ktere si myslite, ze ji rozumite...