.NET aneb cesta tam a zase zpátky

Chudáci lidé, co nemají rádi C++...
Znamená to, že bez C++ se pro Windows vyvíjet nedá?

Dá, .NET a JavaScript mají "projekce" (tak to nazývá MS) do WinRT. Nad WinRT totiž může běžet CLR nebo Chakra. Ale je to myšlené jen pro prezentační vrstvu. Trochu bych se bál výkonu JIT pro ARM.

Aha, už jsem si ujasnil pojmy, už tomu alespoň trochu rozumím... staré dobré COM (o kterém nemám ani páru) - dalo by se říci že jeto něco podobného XPCOM ve firefoxu?

Dalo. Prostě komponentový model.

Protože jsem kdysi musel s technologií COM/DCOM dělat, dovolím si opravit větu "stará dobrá" na "stará špatná". Myslím, že snad není nic ohavnějšího, než tato nepřehledná a překombinovaná technologie.

Jinak odklon od .NET jako příznivec C++ a rychlých programů kvituji pozitivně.

Mrkvosoft již mnohokrát prokázal, že slovem vizionář se nemůže označovat ani náhodou. A souboj dvou koncepcí/sekcí uvnitř firmy to jen dokazuje.

Peněz na vývoj zbytečností, které sežerou v součtu milióny hodin práce jak jejich tvůrcům tak i všem, kdo je chtějí/musí používat, měl vždy víc než dost. Však mu jej ovce, používající Widle, zaplatí. Stačí občas vydat novou WOW-verzi a přestat podporovat starou, která už byla konečně jakžtakž zbavená bugů a se servicepacky mohla klidně fungovat dalších 10 let.

pravdokop: +1

Problém není v tom, že obecně virtuální počítače jsou vyžrané, ale že vyžraný je dotnet. Je to obrovský, splácaný, nakynutý, vyžraný bastl. Např. javový VM funguje na kdejakým malým, podělaným telefonku a jde to (tím se nezastávám Javy jako jazyku). Takže předpokládám, že až bude existovat Winrt, bude to zase (jak je u MS zvykem) obrovský, splácaný, nakynutý, vyžraný bastl.

Správně je v článku řečeno, že .NET zvítězil na (web) serverech, tam se jasně chytil, vznik Azure to jen potvrdil. Takže kdo dělá s MS technologií server side záležitosti, tak je myslím v klídku, tam bych žádnou revoluci ve stylu WinRT nečekal. C# samotný je určitě životaschopná věc ať s MS nebo bez něj, Anders Hejlsberg odvedl a odvádí výbornou práci, poslední ukázky compiler as service jsou pecka. Spíš se divím, že pořád přežívá VB.

Ještě dotaz k tomu ObjC, ty "tlusté binárky" mají také nějaký runtime/vm? Takže to nejsou klasické binárky, která by se daly staticky slinkovat jako jeden soubor bez dalších externích závislosí? Možná to nějak souvisí s tím LLVM.

@9 S LLVM to nesouvisí, fat binary obsahuje kód z linkeru, ale pro různé procesory. Runtime má ObjC, ten je součástí systému (i když šel by přilinkovat i staticky).

@10 Nevím, mít binárku přenositelnou tímhle způsobem mi tedy nepřijde jako nějaká výhoda, spíš mi to přijde jako pitomost. Normální uživatelé to nevyužijí a zbytečně to nafukuje soubory. A pokud by se runtime přilinkoval staticky, ten je přenositelnost stejně v háji.

@11 Applu se to osvědčilo a MS by měl ve WinRT udělat to samé, když už podporuje ARM, jinak bude jen zbytečně buzerovat vývojáře.

Vcelku dobre popsane. Problemem nativnich aplikaci je (alespon jeste po nejaky cas) nutnost distribuce 32bit a 64bit verze. Toto by v pripade .NETovych aplikaci odpadlo. Jinak souhlas s clankem, vcetne toho ze Java je o nekolik generaci pozadu :-)

Spíš by měl už MS umožnit používat "spustitelné adresáře" (jako .app), protože koho zajímají soubory potřebné pro běh aplikace? Ty mohou být uložené v tom adresáři. Ať se tam klidně nachází binárky pro všechny možné platformy a nechť si operační systém vybere.

... nebo spustitelné archivy (bez komprese, chápu, že komprimovaný archiv může být pro system těžko stravitelné sousto)

@13 Nově i ARM :-/

A jeste jedna vec ohledne WinRT. Jak "bohate" je vlastne to WinRT, neni urcene jen pro nejake primitivni tabletove-dlazdicove-mobilni aplikace ? Lze pomoci neho napsat nejakou opravdu komplexni GUI aplikaci typu MS Office ci ucetnictvi, nebo tam zbyva opet jen WinAPI pripadne .NET + WPF + kopa koupenych komponent ?

@17 Office sotva. Je to pro jednoduché věci. Nebo hry s DirectX.

@18 Pak se nabizi otazka, v cem tedy vyvijet tento typ aplikaci ? V MFC ?

@19 Pro Metro je jen WinRT. Jinak se nic nemění, takže MFC, .NET apod.

Takze ve Windows na PC hraje cele WinRT jen roli emulatoru mobilu, aby bylo mozne spoustet i tyto primitivni aplikace :-) Ono se tedy nemeni vubec nic, ani zadna cesta zpatky, pokud za GUI aplikace pocitame nejake opravdu komplexni aplikace.

@22 Těžko říct, kam MS míří. Sotva si můžou dovolit vykašlat se na zpětnou kompatibilitu, takže Windows 8 bude v podstatě Windows 7 s dlaždicovou nadstavbou. Na zařízeních s ARM (většinou tablety, ale třeba i nějaké netbooky nebo ultrabooky, to ještě uvidíme) ale bude jen Metro, a tedy jen aplikace postavené nad WinRT. Apple vždy při změně procesoru dodával emulátor předchozí architektury, takže staré aplikace běžely pomalu, ale aspoň šly použít, než vývojáři svůj výtvor překompilují. MS nic takové neohlásil.

@22 Tady ale nejde o alternativu ani o zpetnou kompatibilitu, WinRT zkratka neni nastupcem WinAPI, jak bylo obcas prezentovano, pro komplexni desktopove GUI aplikace (a to je stale typicke vyuziti Windows na PC). Coz je fakt, ktery se asi ne dostatecne objasnuje a nahrava tak nekterym prvoplanovym blabolum typu ".NET konci". Ohledne .NETovych desktopovych aplikaci, dobrym prikladem ze to jde je napriklad Paint.NET

Spise se desim smeru, kterym se vydavaji konzumni edice Windows. Zda se, ze jako "workstation" system na praci s klavesnici a monitorem (vyvoj serverovych .NET aplikaci ve VS) bude v budoucnu pouzitelny asi jen Windows 2008 Server Standard z MSDN ve virtualu :-/

@22 Apple nemal problém dodať emulátor, lebo menil architektúru zo slabšej na výkonnejšiu (ppc -> intel). Staršie osx programy potom na výkonnejšom hw inej architektúry bežali relatívne uspokojivo v emulácii (emuláciu na iOS pod ARM neriešil, len nové natívne programy). MS si toto ťažko dovolí pri prechode z výkonnejšieho intelu na slabší, ale úspornejší arm.

@24 Win8 bude až za rok, to už budou výkonnější ARM.

@11 Pitomost to není. Jak autor zmiňuje, fat binary se používá pro ARMv6 a ARMv7, což jsou architektury používané mimo jiné pro starší (ARMv6) a novější (ARMv7) modely telefonu iPhone.

"ale bude jen Metro, a tedy jen aplikace postavené nad WinRT" - pre metro sa da pisat v html5, .net, c++

@27 a to všechno běží nad WinRT

tak hlavne ze si rozumite ...

ohledně office jsem někde zahlédl nějaké spekulace, že office by pro Metro UI snad být mělo, vypadaly by nějak jako ty dnešní office pro web.

@30 Jestli to bude jako Pages a Keynote pro iOS tak nic moc.

Jestli ono to není trochu jinak. .NET Framework měl nahradit hromadu těch VBRUNů, MFC, OWL, VCL a dalších wrapperů nad Win32. A to se celkem povedlo, v .NETu dnes jede veliká spousta aplikací. Jenže zatím co napsat účetnictví v .NETu není problém, je daleko větší výzvou napsat HTML layout engine, databázi nebo multimediální codec. Tady byli vývojáři nadále odkázaní na Win32, navíc spojení Win32 a .NETu nebylo tak úplně bezešvé. Teď MS nahrazuje Win32 pomocí WinRT. Ve WinRT budou psány výkonově kritické komponenty, například ty databázové stroje, html layout engine, multimediální komponenty. Většina front-end aplikací bude nejspíš nadále psaná v .NETu/C#/VB.NET, který má lepší interoperabilitu se světem WinRT, než míval se světem Win32.

@32 Dobrý postřeh. XAML+C#+C++/CX bude asi typická aplikace.

Ach jo, proc MS dela vzdy vse tak komplikovane...

BTW, nebylo by od Jabka chytrejsi, kdyby misto tlustych binarek davali instalace pro ruzne architektury, vse v ramci jednoho instalacniho media? Kompilovat se to stejne musi pro kazdou architekturu, tak proc to cpat do jedne binarky a ne do vice oddelenych, kdyz pulka toho pak akorat zabira misto a disku? Tlusta binarka by pak byl akorat instalator nebo cim se to na Jabku instaluje, ktery by vybral, co je potreba. Ze jsou dnes disky velke a relativne levne neni duvodem plytvat mistem. Zadny disk neni nadmerne velky a zadarmo.

@34 Vlastně to není tak komplikované, vývojáři mají konečně rozumně navržené OO rozhraní. To C++/CX kašle na standard, ale dokonale skryje všechny složitosti COMu, takže jednoduchostí kódu pak aplikace se neliší od .NETu. Celé to je velká změna, ale UI jde pořád naklikat ve VS, které taky vygeneruje potřebné třídy. A hlavně už má VS zase intellisense.

@35. Jo, ale proc je neco navrhovano tak, ze z toho lidi sili a musi se to schovavat za jinou vrstvu, aby se to dalo pouzit? Co takle udelat lidsky jiz prvotni navrh te spodni vrstvy? Kdyz uz nic jineho, tak by se tomu lidi aspon nesmali.

@36 COM pochází někdy z roku 1993 a pokud se nepletu, napsali ho v C (ani ne C++), takže to snad vysvětluje, proč je to celé tak složité k použití. Schovali to v C++/CX asi proto, že se jim to nechtělo celé přepisovat, tak vzali starý COM a vymysleli si nad ním svoji variantu C++. Netvrdím, že to je ideální postup, ale tlačí je čas, tak prostě udělali to, co bylo nejrychlejší na implementaci.

Ted jsem byl minuly mesic na seminari Delphi/C++Builder. Nativni kod pro Intel/ARM, pro Windows/iOS/MAC, pry bude i Linux, 32/64 bitu. Knihovny FireMonkey renderuji formulare na graficke karte, pokud menim velikost formulare, tak se mi plynule meni velikost fontu, graficke efekty jsou tam perfektni a bez programovani. To jsem docela koukal, co to umi, proti tomu je WinAPI a COM+ neprehledny moloch. Ukazky chodily na PC, MACach, tabletech, mobilech. K cemu mi bude COM+, kdyz to bude zase jen moloch pod Windows a za 2 az 3 roky ho zase poslou do kytek. Trapna a pomala komunikace pres COM je kapitola sama pro sebe. COM melo OS zbavit problemu s verzemi DLL, aby kdyz se zmeni DLL, tak s tim nebyly problemy, pokud nastala zmena v predavani parametru, bohuzel podle me je prinos nulovy. Typicka ukazka je vytvoreni zastupce na plose, parametry jsou ve strukturach, co jim pomalu nikdo nerozumi, je to mizerne popsane v helpu, jako kdyby k tomu nemohla byt obycejna funkce v C/C++.

Vývoj Javy není tak překotný, což je na druhou stranu dobře. Autoři Javy zastávaji názor, že překotným vývojem trpí robustnost jazyka/platformy. Je lépe, když je jazyk ne nějakou feature připraven od začátku, než když se tam dodatečně naroubuje. NET moc neznám, ale mám pocit, že MS se tam snaží nacpat všechny možné novinky které zrovna letí. A to neni dobře.

@39 "NET moc neznám, ale mám pocit, že MS se tam snaží nacpat všechny možné novinky které zrovna letí"

V podstatě to tak je, viz např. "dynamic" v .NET 4.0 (nebo await/async v nejnovější verzi). Ono se to hodí, problém je, že většina instalací .NETu je nějaká stará verze (na desktopech). Další z důvodů, proč se .NET šíře prosadil jen na serverech (tam si každý dá verzi, jakou chce).

@32 To se jim právě moc nepovedlo. Dřív na člověka vyskočila hláška, že si musí nainstalovat nějaký balíček, který měl pár mega. Dneska si musí s každou novou aplikací instalovat nějaký balíček, který má pár stovek mega. Protože nové aplikace nevznikají tak rychle jako nové verze dotnetů. Navíc dodnes ty instalátory neprovádí kumulativní instalace, některé verze se musí instalovat postupně, třeba postup .NET 3.5, .NET 3.5 SP1, .NET 3.5 SP1 critical update, .NET 4.0 (pak to teprve funguje).

Chudák uživatel!

@41 nemam ten pocit. Windows si updatujem a k tomu dopstavam vzdy poslednu verziu .NET a nemam problem.

@42 no mé zkušenosti vyplývají ze stížností různých uživatelů a v reprodukci jimi nahlášených problémů při hledání nejjednoduššího řešení jako problém vyřešit. V postu @41 jsem uvedl postup, jak na čerstvě aktualizovaném Windows XP SP2 nainstalovat .NET pro MusicJet :-)

@43 no neviem, Windows XP SP2 nie su aktualizovane :) Ale budiz, to ze nove verzie .NETu so sebou automaticky nenesu predchadzajuce verzie tiez povazujem za divne

@43: Od Windows 2003 obsahuje každá verze Windows nějakou verzi .NET Frameworku. Samozřejmě když máte starší verzi Windows, nový framework se musí doinstalovat. .NET Framework si může setup aplikace táhnout s sebou, nebo může uživateli nabízet linky na jeho download. Aktualizace se instalují automaticky přes Windows Update.
.NET 3.5SP1 lze stáhnout jako kumulativní package.
.NET 4 je nezávislý na .NET 3.5, takže se opravdu instaluje zvlášť. Je ovšem neobvyklé, aby jedna aplikace vyžadovala dvě verze .NET Frameworku.

@44: .NET Framework 3.5 podporuje běh aplikací psaných pro verze 2.0 a 3.0. Verze 1.1 podporuje běh aplikací psaných pro verzi 1.0.

@41: Instalovat .NET (2, 3,) 3.5 (SP1) opravdu pro MusicJet nebylo nutné, funguje i bez nich. Stačí fakt jen ten 4.0 z webu.

@39 "Je lépe, když je jazyk ne nějakou feature připraven od začátku, než když se tam dodatečně naroubuje"

Souhlasim, Java byla od zacatku navrzena jako interpreter. JIT tam musel udelat az Symantec, protoze Sun byl zrejme neschopny takovou vec technologicky vubec uchopit. Stejne tak jsou tam velmi "dobre" udelane treba (ne)generika na urovni JVM atd ...

@39 "NET moc neznám, ale mám pocit, že MS se tam snaží nacpat všechny možné novinky které zrovna letí"

Spise maji cloveka, ktery je schopen s temi novinkami vubec prijit :-) Ne vsechno se mi taky libi, napriklad defaultni hodnoty parametru ve spojeni s pretezovanim je zmatek. Stejne tak ono "dynamic", to melo byt vypinatelne v kompilatoru podobne jako "unsafe" (protoze to svym zpusobem je). Jedine smysluplne vyuziti vidim v COM interop pro MS Office, coz je tak strasne rozhrani, ze se ho zrejme nikdy nepovedlo striktne typove popsat :-)

Vetsinu ostatnich novinek jako LINQ (obecne), WCF Routing nebo Task Parallel Library vnimam velmi pozitivne.