Budoucnost .NET

S manuálnym uvoľňovaním pamäte sme sa rozlúčili v roku 2001 a nevidím dôvod na návrat. keďže CLR bude súčasťou OS. Jasné že natívny kód bude vždy o pár promile rýchlejší a pamäťovo šetrnejší, ale tých pár promile programátorom nestojí za to aby si robili zo života peklo. Ja osobne som najviac zvedavý na novinky F# 3.0

@1 Ve srovnání s CLR sice není nativní kód rychlejší (určitě ne řádově), ale spotřeba paměti (špička) je řádově vyšší, což je právě na malých mobilních zařízeních problém. Garbage collector součástí WinRT není a zřejmě ani nebude. Pokud napíšete aplikaci nad WinRT v C# nebo Visual Basicu, bude CLR k aplikaci přilinkováno. Při využití WinRT přímo z C++ (resp. C++/CX) se CLR nepoužije (na co taky...). Obecný trend bude používání knihoven ("Metro" knihoven, tj. nativní kód + soubor .winmd s metadaty) napsaných v C++ (a tedy paměťově relativních nenáročných) s nějakým UI nebo "glue" kódem v nějakém jiném jazyku, ideálně v Javascriptu (v kombinaci s HTML5). Vzhledem k tomu, jak CLR nad WinRT funguje, by taková aplikace měla mít náročností blíže k nativní aplikaci (záleží samozřejmě na tom, jak dobře budou napsané použité knihovny).

Zajímavé. Ne že bych se o programování pro Windows nějak zajímal, nicméně vzhledem k tomu, že W8 mají běhat minimálně i na ARMech, tak jsem naopak čekal výrazný vzestup .Net na Windows platformě právě díky tomu bytecódu.

Jinak ano, “Saying Java is good because it works on all operating systems is like saying anal sex is good because it works on all genders.” znám.

"vzhledem k tomu, že W8 mají běhat minimálně i na ARMech, tak jsem naopak čekal výrazný vzestup .Net na Windows platformě právě díky tomu bytecódu."

Zdá se, že Microsoft jde cestou Applu, tj. nativní kód v "tlustých" binárkách (fat binary). Microsoft má kvalitní JIT kompilátor, který produkuje rychlý kód, problémem je ovšem paměťová náročnost.
Nakonec to dopadne tak, že budou existovat různé více či méně univerzální knihovny napsané v C++/CX (tedy rychlé), nad kterými budou postavené aplikace v C# nebo JS (a tedy nezávislé na typu procesoru).

cokoliv od m$ nema dlouohou zivotnost, at je to m$java , ktera uz prakticky neexistuje nebo ten jejich slavnej .Net a c# . M$ je bastl sam o sobe

[5] v dobach Oraclu by som sa obaval skor o buducnost Javy ...

" v dobach Oraclu by som sa obaval skor o buducnost Javy"

Java je evidentně už za zenitem.

Ked startoval .Net bola existencia GC zdovodnena praktickou nemoznostou napisat prekladac, ktory by odbremenil programatora od uvolnovania pamate, najma kvoli kruhovym referenciam. Viem ze na Mac OS X mozem pri preklade zvolit GC, alebo manualne udrziavanie poctu referencii, na iOS je manual povinny. Ako to teda bude pri C++/CX, bude programator musiet udrziavat pocet referencii, alebo bude prekladac tak genialny ze to zvladne, alebo bude v runtime maly GC pre C++ ?

@Peter88
Na iOS (při použití clang/LLVM) je správa paměti automatická, překladač generuje direktivy v kódu pro správu paměti (doporučuju vygooglit ARC, na stránkách vývojářů clangu je poměrně rozsáhlá dokumentace). Správa paměti je tedy automatická, ale deterministická. Microsoft to teď dělá úplně stejně jako Apple, správa paměti je deterministická přes čítač referencí, ale direktivy pro jeho aktualizaci (retain/release v ObjC, v C++/CX to je AddRef a Release) generuje "chytrý" překladač. To se týká pochopitelně jen objektů nad WinRT (což jsou v podstatě COM objekty), o nativní objekty v C++ se musí stále starat programátor sám (např. pomocí chytrých pointerů).

To je dobré, protože to dává naději na to, že se do nového VS konečně vrátí intellisense pro C++/CLI/CX a snad i pořádná podpora pro paralelní programování, která je v současném C++/CLI značně zkriplená.

Nemyslím si, že bude u metro app výrazný ústup .NETu oproti C++. Už teď se pro WinPhone dělá v silverligthu a tam se použává C# a .NET - pravděpodobně nějak odlehčený. Nevím, že by tam s něčím (paměť) měly zásadní problémy, ale možná se mýlím.

Jinak nejvýkonnější Metro aplikace se podle mě nedostanete jako spojení C++ jako "code behind" a UI v HTML, CSS ale C++ a XAML, který byl překopán a je součástí WinRT. Když se použije HTML, CSS tak to podle mě nějakou složitější cestou skončí u toho XAMLU. Mimochodem C# a XAML je i doporučované cesta pro .NET Metro aplikace, zejména pro snadný převod stávajících silverlight aplikací do Metro.

V .NET jsou v souvistosti s Metro také pěkné změny, zejména ta podpora async/await. Docela mě mrzí, že to nezavedli i do C++, když už se do něj stejně vrtali.

Každopádně snaha Microsoftu o renesanci C++ vývoje je naprosto zřejmá - např. na channel9 a osobně jsem za ni rád. Dokonce věřím, že s tím, jak se začíná pomalu nedostávat zdrojů energie a ta se stává dražší a dražší, tak i server side záležitosti se více a více bude směřovat k C/C++, viz. facebook hip-hop a php.

To: doctorX
Jediná kloudná informace plynoucí z tvého příspěvku je, že si idiot a nemáš páru o čem se tady píše ani o čem píšeš sám.

PH nemyslím si že má u bežných aplikácií zmysel nejako extrémne šetriť pamäťou v dobe keď má priemerný telefón 512 MB až 1 GB ram pričom v čase vydania Windows 8 to môže byť aj 2 - 3 GB Ram. A nemalo to zmysel ani pred 5timi rokmi keď sa aplikácie pre embedded zariadenia s využitím GC (Java ME, .Net Compact Framework) už bežne písali pritom v tej dobe mali telefóny rádovo menšiu pamäť. Osobne si programovanie bez GC už neviem predstaviť.

Jsou aplikace a aplikace. Na většinu aplikací stačí pohodlnější .NET. Budou ale jistě pár aplikací, které budou potřebovat vyždímat z HW maximum a tam na efektivitě bude záležet. Nebo minimálně bude část kódu (výpočetně/paměťové náročná) nativní.

To je podle mě cesta, která se poslední dobou uplatňuje a nevidím důvod pro změnu. Nějaké video kodeky, komprese, zpracování obrazu a zvuku, 3D hry, umělá inteligence apod. ... tam půjde o maximální rychlost a tedy nativní kód v C/C++ je přirozená volba.

Pro GUI aplikace s jednoduchým backendem bude stačit cokoli a bude to dostatečně rychlé, ani to nebude spotřebovávat výrazně baterku (poměr výpočetní výkon/spotřeba se pořád zvyšuje a za chvíli pro běžné věci bude spotřeba výpočetního výkonu celkem zanedbatelná oproti např. svícení displeje, bezdrátové komunikaci apod., kde jsou ty rezervy na snižování spotřeby asi výrazně menší).

Tyto proncipy se aplikují jak na desktopech (např. NET Framework + nativní knihovny, kde je to potřeba). Stejně třeba na Androidu (Java + nativní knihovny pro speciální účely). Je ale vidět, že většina je vždy v tom .NETu/Javě a jen u velmi malé části má smysl použití nativního kódu.

Leda, že by nativní kód MS tlačil silou, aby za cenu menšího počtu jednodušších aplikací (vývoj v nativním kódu je typicky pomalejší) měl delší výdrž na baterii a možná nepatrně rychlejší odezvu (třeba při přepínání aplikací). To by podle mě ale byla velká chyba. Na druhou stranu Windows Phone 7, kde není možné používat nativní kód, je také špatná volba (znemožňuje nebo znesnadňuje to výrobu některých typů aplikací).

@13 " Osobne si programovanie bez GC už neviem predstaviť."

Jasně, ne každý je dobrý programátor ;-)

@14 Kde je řečeno, že je .NET pohodlnější?

Fajn blog na to, ze je to na Root.cz. Az je ho tu skoda, dik za popis.

PH no to rozhodne nie je. drahý a pomalý programátor neni dobrý programátor. GC dáva programátorovi slobodu, šetrí jeho čas a programátor je tým pádom lacnejší a lepšie obstojí v konkurenčnom boji viac urobí a viac zarobí.

Honza77 .NET je dostatočne rýchly aj na multimédiá. Spracovanie obrazu a zvuku a veľkých objemov dát, dokonca aj 3D enginy. So spracovaním grafiky a videa mám skúsenosti a nikdy som nemal problém s výkonom.

blizz: Ale předpokládám, že jste obraz a zvuk nezpracovával pomocí kódu psaného v .NETu. Kodeky a spol byly v C/C++, mám pravdu?

IMHO asi tak: HTML5/JS = VHS, NET/C# = VIDEO2000, C++ = BETA, bohužel, grrrr, osobně mám rád .NET, ale Gaussova křivka nás všechny válcuje čím dál tím víc krezevá všeliké sociální síťovky :-D

Nemůžu souhlasit s tím, že rychlý (tím pádem levný?) programátor je dobrý programátor, a řeči o konkurence schopnosti mě unavují. Třeba jsem pomalejší, to ale neznamená, že jsem nutně dražší, protože mám fixní hodinovou sazbu. Zkrátka někdy si utrhnu z výdělku, klidně na tom budu dělat trochu déle. Aplikace může a někdy musí vznikat pomalu ("safety-critical" aplikace). Ale to se neprogramuje v C#.

[21] Pomaly programator je na 99.999999% aj zly programator. Jediny extremny pripad, kde moze byt rychlost zavadzajuca je implementacia nejakeho hotfixu, kde sa moze prejavit casovy rozdiel medzi systematickym riesenim a preplacnutim bez rozmyslu. Ale uz v rozsahu napr. 1 mesiaca je jasne vidiet, ze lepsi programatori su aj rychlejsi. Jednoducho preto, ze su lepsi.