Wie schätzt Ihr die Weiterentwicklung von .NET ein?

[MGC]

Zitat von Phoenix:

Wieso sprichst Du da eigentlich in der Vergangenheit bzw. im Konjunktiv? Ist doch alles gesetzt und schon lange Wirklichkeit.

Auif eine Weise stimmt dies, aber in letzter Zeit häufen sich auch gegenteilige Meinungen zur Zukunft der .NET-Plattform und daher habe ich die Vergangenheit und den Konjunktiv gewählt.

Zitat von Phoenix:

Zudem: Es gibt keinen 'Leistungsverlust' durch .NET. Die Runtime verwaltet den Speicher in aller Regel effizienter als man es selber machen könnte und ist daher sogar performanter als man es ohne zusätzliche Optimierungen von Hand hinbekommen würden.

Aber wie sieht es mit dem Leistungsverlust durch die "Restkompilierung" des managed Code aus? Welche Performance-Einbußen erhält man hieraus? Das würde mich interessieren, habe mit .NET noch nicht allzuviel gearbeitet. Daher auch mein Interesse. Die GC allerdings ist eine hervorragende Entwicklung, die einen Entwickler bei der Vermeidung von Speicherlecks sehr gut unterstützt.

Zitat von Phoenix:

Genauso wie Java hat .NET seine Stärken vor allem im Server-Bereich: Enterprise-Anwendungen, Webanwendungen, Services, Kommunikation, Plattformunabhängigkeit. Im Gegensatz zu Java gibt es für .NET mit Silverlight, WPF und Windows Forms allerdings auch taugliche GUI-Frameworks.

Die FCL haben wir ja Anders Hejlsberg zu verdanken, der die VCL mit Weiterentwicklung zu Microsoft gebracht hat.

Wie aber sieht es mit Cross-Platform aus, wie es zu Beginn der .NET-Ära angekündigt wurde? Ein Java-Runtime-Environment gibt es ja für nahezu jede Plattform.

[cookie22]

Zitat:

Aber wie sieht es mit dem Leistungsverlust durch die "Restkompilierung" des managed Code aus? Welche Performance-Einbußen erhält man heiraus? Das würde mich interessieren, habe mit .NET noch nicht allzuviel gearbeitet. Daher auch mein Interesse.

Den gibt es kaum, hat Phoenix ja auch schon geschrieben. Zum Teil ist .Net schneller als Nativ Code zum Teil etwas langsamer. Die Zeiten wo .Net langsam war, sind schon lange vorbei.

[MGC]

Zitat von cookie22:

Zitat:

Aber wie sieht es mit dem Leistungsverlust durch die "Restkompilierung" des managed Code aus? Welche Performance-Einbußen erhält man heiraus? Das würde mich interessieren, habe mit .NET noch nicht allzuviel gearbeitet. Daher auch mein Interesse.

Den gibt es kaum, hat Phoenix ja auch schon geschrieben. Zum Teil ist .Net schneller als Nativ Code zum Teil etwas langsamer. Die Zeiten wo .Net langsam war, sind schon lange vorbei.

Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Meine alten Anwendungen die ich in Delphi produziert habe, würde ich jedoch vorerst noch nicht portieren. (Nach dem Motto: Never change a running System)

[Bernhard Geyer]

Zitat von MGC:

[Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Nein. Unter Delphi.Prism steht dir nur FCL zur Verfügung. Die VCL.NET war nur in Delphi for .NET verfügbar und ist mit Delphi 2007 entgültig gestorben.

[MGC]

Zitat von Bernhard Geyer:

Zitat von MGC:

[Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Nein. Unter Delphi.Prism steht dir nur FCL zur Verfügung. Die VCL.NET war nur in Delphi for .NET verfügbar und ist mit Delphi 2007 entgültig gestorben.

Hm, das ist schade, diese Entwicklung ist mir leider ein wenig abhanden gekommen. Somit hätte sich eine Portierung von Altprojekten nach Prism für mich dann ohnehin erledigt.
Aber wenigstens erklärt das für mich jetzt den deutlichen Preisunterschied zwischen Prism und Delphi W32, da ja allem Anschein nach die Forms-Entwicklung zu MS ausgelagert wurde.

[Memnarch]

Wenn ich das was ich verstanden habe kurz zusammenfassen darf: .NEt bringt keine "AHA" vorteile. Je nach komplexität ist mein Programm wie immer an eine Plattform gebunden, "Portierungen" müssen selbst erledigt werden. Einige stellen sind schneller, einige stellen sind langsamer als beim NAtiveCode. Fragt sich welche? CPU lastige berechnungen für z.B Physic&Co (ati nutzer bleiben halt softwaregefangen)?

Hab ich was vergessen?


MFG
Memnarch

[Bernhard Geyer]

Zitat von MGC:

Hm, das ist schade, diese Entwicklung ist mir leider ein wenig abhanden gekommen.

Das hast du dich wohl in den letzten Jahren sehr Rar im Codegear-Forum gemacht ...

Zitat von MGC:

... da ja allem Anschein nach die Forms-Entwicklung zu MS ausgelagert wurde.

Die Form-Entwicklung ist nicht ausgelagert. Prism verwendet halt als das was MS im Framework als IDE-Unterstützung bereit stellt und setzt auch auf den VS.NET-Kern auf. Sinnvoller als wie bei Delphi.NET zwanghaft mit Mannjahren versuchen das nochmal nachzuimplementieren aber die nötigen Spracherweiterugen zu verschlafen. Partial-Classes war der Tod des WinForms-Support in Delphi for .NET.

[MGC]

Zitat von Bernhard Geyer:

Das hast du dich wohl in den letzten Jahren sehr Rar im Codegear-Forum gemacht ...

Ja, das gebe ich zu, war ein wenig eingefangen von meinen Projekten an der Arbeit und habe mich immer nur mal kurz um die .NET-Entwicklung gekümmert, da diese zum damaligen Zeitpunkt für mich kaum eine Relevanz für meine Projekte hatte.

Ich fasse hier also nochmal kurz für mich zusammen:
Es wird für mich auf jeden Fall interessant sich mit .NET mal richtig auseinanderzusetzen, insbesondere da ich im wissenschaftlichen Bereich tätig bin und auch wir über kurz oder lang mal unsere alten Rechner (Pentium 4) abschiessen werden und sich mir dann über das .NET-Framework mögliche Zusatzoptionen ergeben die ich unter W32 nur schwer umgesetzt bekomme.
Für meine kleinen Applikationen an Messgeräten die nichts anderes tun als Daten auszulesen und nach kleineren Verrechnungen über eien bereits vorhandene Schnittstelle in laufende DBMS einzupflegen brauche ich allerdings kein .NET, da alles inHouse läuft und keine Webunterstützung von Nöten ist.

Würdet Ihr mir nun raten mich eher mit Delphi Prism oder lieber mit C# auseinanderzusetzen? Immerhin ist C# ja eine Sprache die eigens für .NET entwickelt wurde, wenn ich das noch recht im Kopf habe.

Übrigens, vielen Dank an alle die bisher schon mitdiskutiert haben. Allmählich kommt Fahrt in die Sache und ich plane schonmal meine nächsten Fortbildungen ein.

[Hisoka]

Zitat von MGC:

Wie aber sieht es mit Cross-Platform aus, wie es zu Beginn der .NET-Ära angekündigt wurde? Ein Java-Runtime-Environment gibt es ja für nahezu jede Plattform.

Naja es läuft auf allen "Windows" Systemen mehr oder weniger gut.

Aber von Hause aus ist nur die Basis(also der Teil der ISO Standardisiert ist) Plattform unabhängig. Der Rest ist es nur bedingt( als Windows.Forms läuft großteils, WPF läuft gar nicht). Moonlight ist nur brauchbar wenn du auf DRM verzichtest, denn das darf auf einem Linux Desktop nicht verwendet werden(sagen die Lizenzbedingungen von MS für Play 4 Sure)


Also ein Java ist es nicht. Man kann nicht eben mal eine Anwendung mit GUI schreiben und sie läuft auf allen Systemen ohne Probleme. Die meisten .NET Anwendungen die ich bisher gesehen hab sind Plattform gebunden. Also sie laufen entweder auf Win oder unter Linux oder auf dem Mac. Einige wenige laufen mit erheblichen Aufwand und Win und OSX oder unter Lin und OSX. Anwendungen die gut unter allen Plattformen laufen sind selten.
Windows.Forms wird nicht auf jeder Plattform mitgeliefert, daher müssen die passenden Pakete extra ausgeliefert werden.

[MGC]

Zitat von Hisoka:

Also ein Java ist es nicht. Man kann nicht eben mal eine Anwendung mit GUI schreiben und sie läuft auf allen Systemen ohne Probleme. Die meisten .NET Anwendungen die ich bisher gesehen hab sind Plattform gebunden. Also sie laufen entweder auf Win oder unter Linux oder auf dem Mac. Einige wenige laufen mit erheblichen Aufwand und Win und OSX oder unter Lin und OSX. Anwendungen die gut unter allen Plattformen laufen sind selten.
Windows.Forms wird nicht auf jeder Plattform mitgeliefert, daher müssen die passenden Pakete extra ausgeliefert werden.

Also im Prinzip das gleich wie immer.
Eine Eierlegende-Wollmilchsau wird es leider wohl nie geben.

Aber da ich hauptsächlich für Windows-Plattfromen entwickle dürfte dies für mich eine eher untergeordnete Rolle spielen (ansonsten gibt es ja noch JAVA, mal ganz abgesehen davon, das sich Delphi ohnehin auch nicht für jedes eignet - egal ob W32 ode .NET).

Aber da meine Wurzeln bei Pascal liegen komme ich auch nicht einfach so von Delphi los.