C# 4.0 és azon túl

Programozás

Habár a hír nem éppen új, de kiválósága miatt ajánlom mindenki figyelmébe.

Anders Hejlsberg két nagyon élvezetes előadást tartott 2010 áprilisában a Microsoft DevDays hágai konferenciáján. Anders Hejlsberg 2000 óta a Microsoft C# szakmai vezetője. Korábban hasonló pozíciót töltött be a Borlandnál, ahol a Delphi fejlesztéséért felelt.

A két előadás lazán kapcsolódik. Az első a C# 4.0 újdonságaira fokuszál, mint a dinamikus típusosság és használata, a ko- és kontra-variancia, nevesített és opcionális paraméterek és végül a COM interoperabilitás. A második előadás fő témája a programozási nyelvek jövője és azok a trendek, melyek többek között a C# jövőjét is formálják.

Az előadások letölthetők, illetve megtekinthetők itt:

C# 4.0 and beyond
Trends and Future Directions in Programming Languages

- Süni

( Chain-Q v | 2010. 09. 02., cs – 22:40 )

Korábban Delphi? Az semmi. Ez a fószer csinálta a Turbo Pascalt. Szóval igyátok szavait, mint Angster Erzsébetét tennétek... :)))

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Baszki, tíz éve még szomszédtól kölcsönkapott két "barna-könyv"-ből (többek között) tanultam Pascal-t, nagyon szerettem, gyerekfejjel is halál érthetően és logikusan le volt írva minden, de később az istennek se jutott eszembe a címe, most rákerestem a névre, és ez az, köszönöm :)

( gabim | 2010. 09. 02., cs – 22:56 )

We should systematically arrange to depend on the free C# implementations as little as possible. In other words, we should discourage people from writing programs in C#. Therefore, we should not include C# implementations in the default installation of GNU/Linux distributions or in their principal ways of installing GNOME, and we should distribute and recommend non-C# applications rather than comparable C# applications whenever possible. -- http://www.fsf.org/news/dont-depend-on-mono

Igen, ez alapján a C# valóban nem optimális választás arra, hogy GNU/Linux disztribúciókba szánt programokat írjunk benne.Ellenben azt nem mondja az idézett részlet, hogy a C# rossz lenne, azt meg pláne nem, hogy nem lehet az erősségeiből/hibáiból tanulni. Ezek a videók a tanulást szolgálják, és arra nagyon jók is.

valóban nem rossz a C#, csak jobb kerülni a használatát ha van választási lehetőség. már a Borland is híres volt a standardokra fütyülő implementációiról. mára jobb helyeken már az oktatásból is száműzték a Pascal vonalat.
imho ez a legrosszabb, amit egy programnyelvvel tenni lehet.
nem volt számomra szimpatikus amit a Google csinált a Java platformmal. de a Dalvik legalább forrásszinten tökéletesen kompatibilis a Java nyelvvel.

1. A C#/.NET szabvanyossagarol es kompatibilitasarol ma csak almodozhatnak a C++-os kornyezetek. Akar forras, akar binaris oldalrol nezve.

2. Az, hogy a Borland mire futyult a standardokkal kapcsolatban, az meg hol relevans a C#-al kapcsolatban? Egyebkent Borland C++ nem altalanos C++ forditonak volt szanva, a szabvany szigoru implementalasanal fontosabb kerdes volt, hogy integralni lehessen a VCL-el.

Nem ismerem a C#-ot (és a .NET-et sem), így nem kötözködni akarok, csak kíváncsi vagyok. Mit jelenet a bináris kompatibilitás? Ha írok Windowson, a .NET keretrendszert használva egy programot, akkor a kapott bináris kód Linux alatt is fut, a monot használva?

-----
"Fontosabb egy jó szomszéd, mint egy távoli rokon." (Árvízkárosult, 2010)

"akkor a kapott bináris kód Linux alatt is fut, a monot használva?"

Igen, sőt, továbbmegyek, ugyanaz a kód fut x86 és x64-n architektúrától föggően 32 vagy 64 bites kódként*, vagy akár ARM-ként is futhatna. (itt mondjuk bejön az, hogy WinMo-ra .NET Compact Framework van, ami picit megnehezíti a dolgot).

* Persze lehet, és néha muszáj tenni kikötést, hogy x86 vagy x64-ként fusson csak.

----------------
Lvl86 Troll

Több program honlapján olvasható, hogy C# nyelven írták, a .NET framework használatával. De általában csak a különböző Windows verziók szerepelnek az operációs rendszerek felsorolásában. Ennek ellenére Linuxon is fog futni egy ilyen program?

-----
"Fontosabb egy jó szomszéd, mint egy távoli rokon." (Árvízkárosult, 2010)

Amennyiben nem használ semmi olyat, amit a mono nem tud/nem hív be valami natív windowsos kódot, igen.

Egyszer próbáltam OpenSUSE-n valami tisztán .NET 2-ben írt konzolos alkalmazást, minden további nélkül futott. Egy ismerős ubuntuján meg egy WinFormsos cuccom, az is. Annyi szépséghibája volt, hogy a windows classic témához hasonló kinézete volt az egész ablaknak és nem vette fel a GTK témát, de erre valahol olvastam egy blogbejegyzést, hogy miért így csinálták. Mondjuk ez orvosolható a GTK#-l.

----------------
Lvl86 Troll

Az első része a Mono implementáció lemaradása, a natív Windowsos kódok meg nem tartoznak bele a .NET-be. Ettől még maga a CLI bájtkód képes futni monon.

Ez olyan, mintha a Java-t fikáznánk, mert az egyik fejlesztő meghív valami C kódot vagy OS specifikust belőle.

Bele lehet magyarázni itt sokfélét, de a kérdés ettől még ez volt:

"Ha írok Windowson, a .NET keretrendszert használva egy programot, akkor a kapott bináris kód Linux alatt is fut, a monot használva?"

Ez pedig lehetséges. Kérlek, csináld utána ugyanezt egy C-s binárissal.

----------------
Lvl86 Troll

Figyi, a desktop felhasznalot baromira nem erdekli am, hogy te fejlesztokent mit tudsz megcsinalni es mit nem. A ma piacon levo .Net -ben irt programok (oke, optimista leszek) 80%-a _NEM_ fut Mono alatt. Pont.
A Wine jelenleg sokkal tobb programot tamogat Linuxon, mint a Mono. Es sokkal kevesebb szopas mellett tamogatja. Ezek tenyek.
Arrol nem is beszelve, hogy mar ott eltorik a Windows-Linux portabilitas, ha valami extrat szeretnel a systray-en levo ikonnal, pl. extra buborekkezelest. Egy rakas WinAPI-t kell hivni hozza, hogy e kore epitesz-e osztalyrendszert vagy sem, az mellekes. Szoval igen, egy calc.exe szintu progi valtoztatas nelkul fog futni, de minden mas esetben le kell kezelni az eltero platformok kozti problemat.

Talan meg a Mono API-lemaradasa a legkisebb problema.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Azt jelenti, hogyha leforditasz egy C++ osztalyt tartalmazo forrast, es kapsz egy .so-t vagy egy .dll-t, akkor azt milyen forditoi kornyezetben tudod felhasznalni komponenskent.

Csak egy par dolog peldakent, ami ezt megakadalyozhatja:

- parameteratadas modja
- kivetelkezeles implementacioja
- adatmezok igazitasa
- name mangling
- visszateresi ertek felszabaditasa
- beepitett tipusok merete es abrazolasa

... de lehetne meg sorolni, a memoriakezeles kornyeken is van egy ket vidam momentum.

> csak a C++, mint desktop app programozasi kornyezet eleg szerencsetlen.

Három kérdésem lenne:
1. A naponta használt alkalmazásaid közül melyik milyen nyelven íródott? Nyílván nem egy listára vagyok kíváncsi, csak statisztikákra (pl.: Cisz: 80%, minden egyéb: 20%, stb.)
(Nemcsak FOSS-ra gondolok, minden szoftverre, legyen az nyílt, vagy zárt, Windows-only, vagy sem)

2. A C-t (gnome) is szerencsétlen desktop programozási nyelvnek tartod?

3. Melyik programozási környezetet nem tartod szerencsétlennek desktop appok létrehozásának céljára?

1. passz, nem tudom a valaszt. De abban biztos vagyok sokevnyi alkalmazasfejlesztes utan, hogy Qt-ben vagy MFC-ben (a Gnome-ot nem ismerem, de szerintem az meg rosszabb) sokkal nehezebb es szoszolosebb GUI alkalamazast fejleszteni, mint Delphi/VCL-ben, C#/WinForms-ban vagy Objective-C/Cocoa-ban. Az altalad emlitett statisztika csak az igazsag elfedesenek az eszkoze. A Cisz folenye csak annak koszonheto, hogy a piacon levo alkalmazasok irtozatos meretu legacy kodbazist cincalnak magukkal, amit nem tudnak vagy nem akarnak portolni az uj kornyezetekre. Persze korabban csak MFC volt, nyilvan minden abban keszult. Ma viszont nem lepodnek meg, ha az ujonnan indulo fejlesztesek nagyobb aranyban valasztananak WinForms-t, mint MFC-t.

2. Egeszen pontosan egy viccnek tartom, hogy valaki komolyan C-ben akarjon nagy desktop rendszert fejleszteni. Penzbol elo fejleszto nem is igen vallalkozik ilyesmire.

3. VisualStudio 2005+ (WinForms), XCode(Cocoa) az, amit en ismerek es korszerunek tartok. A QT-vel keves kapcsolatom volt, a QTCreator talan a legjobb altenativ C++ IDE, de a Qt sem menti meg a C++ eziranyu hianyossagait. A Delphi is nagyon jo volt, kar, hogy marginalizalodott.

Ami azt illeti, meglepodnel, hany komoly alkalmazast fejlesztenek Qt-ben manapsag. Nyilvan vannak hatranyai egy C++ iranyu alkalmazasfejlesztesi strategianak, de a Qt pont az a platform, ahol eleg sok minden lehetsegesse valik. En, aki amugy se a C/C++ -hoz magahoz, se a Qt-hez nem ertek komolyabban, eleg hamar at tudom latni egy Qt alkalmazas mukodeset, majdnem olyan hamar, mint egy Rails-os alkalmazaset, pedig ez utobbiban sokkal melyebben benne vagyok. Ez azert eleg sok mindent elmond.

Ugyanakkor biztos vannak olyan problemak, amiket egyszerubb mas nyelven megirni, de ha mar valamiert az ember nem akar Java/C# iranyba elmenni, a Qt egy jo valasztasnak tunik nekem.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Hat, aki a C-ben akar objektumorientaltan programozni, az mar eleve erdekes ember, szoval... hmmm... Szerintem a C-t baromira nem arra talaltak ki, amire a Gtk/Gnome hasznalja.
Ha ezen felulemelkedunk, akkor viszont tenyleg egesz jo lib rendszert rittyentettek ossze, noha ossze sem lehet hasonlitani a Qt szolgaltatasaival.
-- 


Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nem azt mondtam, hogy nem dolgozhatsz es nem lehetsz elegedett QT-s programokkal.

Sot csavarhuzoval is lehet szoget beverni. Nincs semmi baj azzal, aki nehanapjan csavarhuzoval uti be a szoget, lehet, hogy akkor eppen az esik kezre. Ezalatt azt kell erteni, hogyha valamiert kokemeny requirement a C++-os desktop alkalmazas, akkor a Qt nem egy rossz valasztas. Ellenben keves befekteto adna neked penzt arra, hogy alapits egy ceget nehany die-hard Qt-s arccal, hogy desktop alkalmazasokat fejlesszetek, es betegre keressetek magatokat.

Lehet, de tapasztalt C++ programozokat es tapasztalt .Net programozokat feltetelezve a grafikus feluletet igenylo feladatok megoldasa kb. 3-4x tovabb tart C++-ban. Ez ilyen.

Ize, mondjak par peldat, hogy miert tud nehezkes lenni a Qt?

- hiaba van tipusos SIGNAL/SLOT rendszer, templatek eseten nem mukodik a dolog. .Net-ben siman hasznalhatsz generikus delegate-ket. Az egesz Qt-s RTTI egy joval primitivebb rendszer, mint a .Net reflection.
- En meg nem lattam Qt alapu kompozit UI keretrendszert. Talan ez az egyik legfajobb reszlet.
- _Sokkal_ nehezkesebb C++-t debuggolni, mint bytecode alapu nyelveket. .Net alatt a release kodhoz is siman csatlakoztatod a debuggert, es latsz (majdnem) minden erteket. C++-ban optimalizalt kodot debuggolni nemileg maceras (nincsenek rendes stack tracek, etc.)
- menedzselt heap elonyei eleg jelentosek (foleg GUI alkalmazasban, ahol a real-time mukodes es az aritmetikai teljesitmeny nem kritikus)
- Qt ala _sokkal_ kevesebb widget letezik. Mutass olyat Qt ala, mint pl. az Infragistics, a Syncfusion vagy a ComponentOne. Egyszeruen nincs. Van a KD eszkoztar, ami egy rakas k*.

Ezek kozul van, amelyikkel nem ertesz egyet?

----------------------
while (!sleep) sheep++;

A legutolso ponthoz csak annyit tennek hozza, hogy az egesz abbol a problemabol ered, hogy nincs a C++-nak meg adott platformra sem binaris szabvanya. Ertem ezalatt azt, hogy egy C++-ban irt konyvtar binaris formaban korlatozottan hasznalhato. Nem eleg, hogy kulonbozo forditoprogramok maskeppen kezelik a dolgokat, de meg forditon belul is eleg lehet egy compiler flag, ami hibas mukodest eredmenyez a komponensek integralasakor.

Ehhez kepest a .NET-es assembly-k integralasa konnyebb, mivel az ABI szabvanyos.

Szerintem eleg keves komponensgyarto akarja azt felvallalani, hogy kismillio forditot, beallitast es egyeb kornyezetet tamogasson.

Nagyjából igaz. De a QT az nem az a tipikus C++ nyelv. Egy 60 ezer soros programban lehet vagy 3 delete parancs, a többit automatikusan kezeli.

A QT-ben megírt programnál a java 1.5-ször hosszabb.

A QT nemcsak egy ablakozó könyvtár, hanem alapjaiban felforgatja a C++-t is az event handling-gel. Közelebb áll az önálló nyelvhez, mint a C++-hoz.

Nem allok neki egzakt definicionak, de gondolom ha nem kotozkodni akarnal, te is ki tudnad talalni.

En ezalatt azt ertettem, hogy a nyelv es a hozza tartozo szabvanyos konyvtar megtervezesekor figyelmbe vettek es priorizaltak azokat a tenyezoket, amik a GUI alkalmazasok fejleszteset, hibakereseset, telepiteset es futtatasat segitik.

A C++ es az STL kereken semmilyen tamogatast nem adott GUI programozashoz. A QT fejlesztoi szerintem a munka oroszlanreszet abba oltek, hogy ezeket a hianyossagokat korbeprogramozzak (Slot rendszer ugye).

Ja, még kettő, elolvasva a hozzászólásokat.

1. A Qt-t a következők indokolják:
- Ha valami miatt C/C++-t kell használni, akkor nincs más valós alternatíva, mint a Qt.
- az alkalmazás teljesítménykritikus (pl. multimedia), és kell a speed, akkor jó választás
- erős az igény a cross-platformságra

Minden más esetben jobb kerülni a C++-t.
Ne a Qt-t szídjuk. A Qt jó. A Qt szép. Maga a C++ az, ami nehézkes. Az MFC-t pedig felejtsük el, nem egy kategória a Qt-val, szvsz.

2. A Qt-t írjuk már helyesen, és ne használjuk az idegesítő QT-t.

C#-bol is meg lehet hivni nativ kodot es nativbol is menedzseltet. Nem egy helyen lattam, hogy a teljesitmenykritiku reszeket megirtak C/C++-ban, a GUI-t meg ozekattintgattak valami menedzselt nyelvben.

Nameg ott az unsafe kod, ott lehet pointerekkel jatzadozni, ha sebesseg kell.

----------------
Lvl86 Troll

Azert ez sem teljesen igy van. Menedzselt / nem menedzselt kod kozott marshaling van, ami majdhogynem olyan lassu, mint az IPC, tehat ha sok az adat, akkor nem feltetlen mukodik a dolog.

Hiaba az unsafe kod, nem szokas olyan sebesseget elerni, mint C++-ban. Ennek a legfobb oka egyebkent az, hogy mashogy programozol C++-ban. Folyamatosan gondolkozol a const correctnesszen, copy-by-value vagy referencia, RAII, stb, szoval elvileg meg lehet kozeliteni a C++ sebesseget, de nem jellemzo.

----------------------
while (!sleep) sheep++;

Tudom, nálunk is használják, na erre mondom, hogy ennél jobb a Qt. :-)
Feltéve, hogy a C++ rész eléggé jelentős.

Ráadásul vannak hibák a .Net-ben. Nem tudom, hogy a legújabb verzióval mi van, de régebben ettől a C++ kódtól minden .Net-es progi elszállt futásidőben:

void Fv() {
static MyClass object;
}

Az unsafe kódot hagyjuk. Többször lassabb, mint a C++, mértük.

Figyu, én képfeldolgozást tolok: a C++-nak, illetve a C-nek ott nincs alternatívája.

Összekattintgatni a GUI-t Qt-ben is lehet; tudtommal komolyabb alkalmazásoknál éri meg újabb nyelveket használni.

( blah-blah | 2010. 09. 03., p – 06:11 )

Aaaah, most már érthető a C# igazi evoluciós iránya. Turbo Pascal -> Delphi -> C#. Ez mindent problémát megmagyaráz :::))))

Látom újszülöttnek minden vicc új. Emlékszem, mikor a C# bejött, akkor pár "hithű" C/C++ programozó, ennek megfelelően Pascal-gyűlölő ismerősöm is úgy üdvözölte, mint a(z akkor még) felsőbbrendű(nek gondolt), árja C/C++ vonal következő evolúciós lépcsőjét, és a terjesztéséért vérre menő flame-eket folytatott különböző Delphi és Java fórumokon. Mi inkább csak békésen mosolyogtunk rajtuk.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

+1: kedvencem, hogy "de a pascal egy fos, az egy tanulónyelv", "a középsuliban rámerőszakolták a turbopascalt" (-> kb. semmit nem láttak belőle) emberek mondják, hogy hát ez a C# egész jó, aztán értékelhető Delphi tudás hiányában észre se vették, hogy mennyi minden onnan gyökerezik.

Mikor kb. 2006 környékén először írtam C#/WinForms-ban valamit, az első benyomásom az volt az egészről, hogy ez egy lepucolt Delphi egy Java szerű nyelvben és épp csak annyit változtattak rajta, hogy elsőre minden picit más legyen, mint a megszokott.

----------------
Lvl86 Troll

Na hát akkor neked van egy jó hírem. A C# egy erőszakos bűnben fogant gyermek. Ez volt az MS válasza arra, hogy a Sun kifizetett vele 80 milko dolcsit a J++ miatt.

Én osztom RMS véleményét abban, hogy a Java egy csapda, illetve mindenki aki .Net alapú nyelvben fejleszt önmagát lövi lábon.

De a valóság sajnos az, hogy az ember programozóként abban kódol, amit elé tesznek. Egy projekt indulásakor az ember hangosan hőböröghet, hogy milyen környezetet használjon, de utána már csak kódfaragó iparos meló van.

--
GPLv3-as hozzászólás.

RMS-nek fogalma sincs az elet egyeb oldalairol, o csak radikal-szabadsagharcos-oshacker szemszogebol tudja nezni a dolgot. Egy a programozasbol elo fejleszto szamara a C# maga a Kanaan. Bizonyos celjaival egyet tudok erteni, de a csavo ugy ahogy van nem ebben a vilagban el, es a velemenye is igen torz.

> Egy a programozasbol elo fejleszto szamara a C# maga a Kanaan.

Ezzel vitatkoznék. Pölö fejlesztő: Linus Torvalds, John Carmack, Ted Tso, szerény személyem is, és gondolom esetleg te is.

Na most ezen fejlesztők mindegyike (kivéve téged) a halál faszára meg vissza kívánja a C#-ot és vele együtt a .Net-et.

--
GPLv3-as hozzászólás.

Nem akarom feleslegesen terhelni a szálat és nagyon sajnálom ha nem neked nem esik le.

Nincs olyan, hogy átlag fejlesztő. Ha felteszed a nagy kérdést, hogy tegye fel a kezét aki átlagos fejlesztőnek érzi magát, nem sok kezet látnál a magasba!

Tehát c# != kánaán minden fejlesztő számára!

--
GPLv3-as hozzászólás.

Akár Kánaán, akár nem, a C# jelenleg teljesen alkalmatlan egy csomó feladatra.

pl. komoly crossplatformos alkalmazások írása, beágyazott rendszerek, + az igázán teljesítménykritikus alkalmazások.
Az egyetlen igazán használható implementációja tudtommal a .Net. RMS-nek nincs mindig igaza, de meg kell fontolni, amit mondd.

Személy szerint az egyetlen "hely", amihez C#-t választának, az a Win-only, nem teljesítményigényes desktop alkalmazások írása.

"a Win-only, nem teljesítményigényes desktop alkalmazások"

Ami mellesleg kb. a szoftveripar beveteleinek kb. 80%-at hozza, ha nem szamoljuk a webes alkalmazasokat.

Tovabba a beagyazott szoftverek keszitoi is a managelt kornyezetben fele mocorognak: Android, Compact Framework, leven mar a hardver lassan felno ehhez.

Ezeket egyre kevésbe hívhatjuk beágyazott rendszernek.

Egy androidos kütyüt ugyan mi tesz beágyazottá? Az hogy kicsi?
Egy HTC Desire-nek jobb a teljesítménye, mint a pécémnek amit tavalyelőtt adtam el 3e Ft-ért.

Én beágyazott szoftver tájékon real-time kerneleket látok, spéci processzorokat. Olyan fordítókat, amiknek a C++-szal is gondjuk van.

( s3r3nity | 2010. 09. 03., p – 06:31 )

M$ hír a HUP főoldalán? Basszus tényleg változnak a dolgok...ők is beszálltak az oldal üzemeltetésébe a Profession.hu mellé? :p

--
When your mind is empty of prejudices you can see the Tao.
When your heart is empty of desires you can follow the Tao.

( therion | 2010. 09. 03., p – 15:19 )

A Java 7 jöjjön már végre, és minden fasza lesz! :)