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

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1082919)

Zitat:

Da Delphi PRISM so gar nichts mit Delphi for .NET gemein hat, solltest Du da nicht allzu viel erwarten.

Im Gegenteil. Von Prism kannst du mehr verwarten

Ich bin sicher, die Aussage bezog sich auf das Buch über Delphi for .Net.

[mkinzler]

Das bringt ihm dan natürlich nichts

[jfheins]

Zitat:

Zitat von Insider2004 (Beitrag 1082918)

Ich glaube es ließen sich noch zig .net-Techniken finden, warum man .net nehmen sollte.

Fakt ist, dass man ein sehr schnelles und unheimlich flexibles Programmiersystem hat (Delphi) und ein sicheres, langsameres und unflexibleres Programmiersystem (Prism, C#, Whatever).

Ich brauche ersteres für meine Kunden-Anforderungen. Es kommt einfach immer wieder vor, dass man was casten muss oder mal direkt in die CPU-Register rein muss. Und da zieht .net einfach den kürzeren.

Der Resourcenverbrauch ist im Vergleich zu Native einfach sehr viel größer. Meine Kunden haben teiweise PCs von 2002. Was soll ich da mit net ankommen? Die zeigen mir den Vogel, wenn ich sage, sie sollen das net-Framework vorher installieren.

Ah, ein "Fakt ist" am Anfang ist natürlich gut. Wir diskutieren zwar die ganze Zeit darüber, aber schon dass das mal wer gesagt hat *g*

Fakt ist: Ich halte .net für flexibler als Delphi. Zum Beispiel kann ich eine Klasse anlegen und dann in minimaler Zeit eine List<Klasse> anlegen und das in eine Listbox einfügen. Wenn man noch die toString() Methode überschreibt hat man sofort eine Objektliste die angezeigt wird. Kein casten, nichts. Wenn man dann auf die Idee kommt, man würde gerne und einfach manipulieren können nimmt man stattdessen eine BindingList<T> und schon wird alles was man an der Liste macht sofort in der Listbox gespiegelt.

Casten ist natürlich kein Problem. Und direkten Zugriff auf die CPU Register ... okay, da hat inline Assembler die Nase vorn. Ich kann aber kein Assembler, weil nie gebraucht. Sorry.

Ressourcenverbrauch, okay. Der Punkt geht an native. Und wenn du noch Krücken aus 2002 supporten musst, dann ist das eben so, da kann man nur selten etwas dran ändern.

[Phoenix]

Ich gehe jede Wette ein, dass ich jedes Programm welches Insider2004 in Delphi schreibt, mindestens genauso performant, wenn nicht sogar performanter auf Basis von .NET implementieren kann. Voraussetzung ist, dass zum Vergleich die Sourcen offen liegen - und er sich überhaupt auf die Wette einlässt.

Dass native Code generell schneller sein soll als managed Code ist ein immer wieder propagiertes Gerücht, dass schon zigfach widerlegt wurde, sich aber immer noch hartnäckig hält - und ich will diese verbohrte falsche Annahme endgültig und ein und für alle Male aus der Welt schaffen. Diese Halbwissen und auf seinem (falschen) Standpunkt verharren geht mir so langsam echt derbe auf den Keks.

Edit Nachtrag: Zum Thema Flexibilität: Ich würde zudem darauf tippen, dass ich dazu weniger Code brauche als er und dass mein Code wiederverwendbarer ist - und zudem auch noch auf iOS, Android, Linux, Mac und - dank Cooper - auch auf Java läuft. ;-) (Wobei ich auf der Java-Plattform nicht für mehr Performanz garantiere).

[Insider2004]

Zitat:

Zitat von Phoenix (Beitrag 1082930)

Ich gehe jede Wette ein, dass ich jedes Programm welches Insider2004 in Delphi schreibt, mindestens genauso performant, wenn nicht sogar performanter auf Basis von .NET implementieren kann. Voraussetzung ist, dass zum Vergleich die Sourcen offen liegen - und er sich überhaupt auf die Wette einlässt.

Dass native Code generell schneller sein soll als managed Code ist ein immer wieder propagiertes Gerücht, dass schon zigfach widerlegt wurde, sich aber immer noch hartnäckig hält - und ich will diese verbohrte falsche Annahme endgültig und ein und für alle Male aus der Welt schaffen. Diese Halbwissen und auf seinem (falschen) Standpunkt verharren geht mir so langsam echt derbe auf den Keks.

Edit Nachtrag: Zum Thema Flexibilität: Ich würde zudem darauf tippen, dass ich dazu weniger Code brauche als er und dass mein Code wiederverwendbarer ist - und zudem auch noch auf iOS, Android, Linux, Mac und - dank Cooper - auch auf Java läuft. ;-) (Wobei ich auf der Java-Plattform nicht für mehr Performanz garantiere).

Diese Wette brauchen wir gar nicht aufziehen!

.net ist ein zusätzlicher Layer zwischen der Windows API und deinem Prism/C#-Programm. Beim Native-Ansatz greift dein Programm direkt auf die Windows-API zu. Der gesunde Menschenverstand sagt einem, dass die Native-Lösung schneller sein muss (was sie natürlich auch ist).

Jeder Integer und jeder andere Krümmel ist bei .net ein Objekt. Das alles aufzuziehen und hochzufahren braucht unheimlich viel Resourcen (genauso wie bei Java). .net-Programme sind im Schnitt 5-15 Mal langsamer als Native-Programme.

[Daniel]

OMG :roll: STOPP! Warum tappt Ihr immer wieder in diese Falle?

Es ging in diesem Thema um die Frage nach den Perspektiven für .NET - und ich denke, dass aus den Beiträgen offensichtlich geworden ist. dass diese recht vielfältig sind.



... und ganz am Rande ist es weder den einen noch den anderen bisher gelungen, ein Programm zu skizzieren, das nativ oder managed per se schneller oder langsamer sein muss. Nur die alleinigen Behauptungen, dass dem so sei, findet man im Netz zuhauf - die brauchen wir hier nicht zum x-ten Mal wieder holen. Reicht also jetzt mit dem Gezeter.

[MGC]

Diesen Schlagabtausch fand ich persönlich dennoch sehr interessant. Es hat mir einen kleinen Einblick in einige grundlegende Unterschiede zwischen native und .NET gegeben.
Da ich bei uns im Betrieb noch eine gewissen Zeit lang Altsysteme die an Analysengeräten hängen betreuen muss, werde ich demnach mit dem vertrauten Delphi W32 weiterarbeiten (in der Hinsicht ist es mir auf sogar noch längere Sicht egal ob demnächst Delghi W64 herausgebracht werden sollte/könnte).
Auf längere Sicht bin ich mir aber nun sicher, das ich mich auch dringend intensiver mit .NET-Entwicklung auseinandersetzen muss und mich in der Richtung fortbilde (So wie ich auch nicht um, C++ und JAVA herumgekommen bin).
Desweiteren werde ich mich also mit C# und Delphi Prism beschäftigen, falls in der Analysentechnik Handheltgeräte hinzukommen werde ich .NET ggf. benötigen, da diese möglicherweise (wenn nicht auf JAVA aufgesetzt) ähnlich dem WP7 ausgestattet sein könnten udn ich somit mobile Geräte genauso wie Workstations betreuen kann.

Dennoch ist nicht zu vergessen, das die Wahl der Umsetzung immer auf die Plattform und die Projektspezifikationen abgestimmt sein sollte.

Puh, dafür das ich nur ein Quereinsteiger bin, habe ich in den letzten Jahren doch einiges schultern dürfen. Ich wünschte, ich hätte mich damals doch für ein Studium entschieden.:warn::glaskugel:

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1082931)

.net ist ein zusätzlicher Layer zwischen der Windows API und deinem Prism/C#-Programm. Beim Native-Ansatz greift dein Programm direkt auf die Windows-API zu. Der gesunde Menschenverstand sagt einem, dass die Native-Lösung schneller sein muss (was sie natürlich auch ist).

Wie hoch ist der Anteil der Rechenzeit auf API-Ebene bei komplexeren Programmen? Und wieviel davon basiert noch auf nativen Win32-Controls? Z. B. jeder der ein großen Tree/Listview mit vielen einträgen benötigt und auf jede ms angewiesen ist wird die Win32-API vermeiden (ElPack, VirtualTreeView, ...)

Zitat:

Zitat von Insider2004 (Beitrag 1082931)

Jeder Integer und jeder andere Krümmel ist bei .net ein Objekt. Das alles aufzuziehen und hochzufahren braucht unheimlich viel Resourcen (genauso wie bei Java).

Wer in .NET/Java jedesmal wenn er ein skalares int benötigt aber ein Integer-Objekt verwendet (selbst bei Schleifen) ist selbst Schuld. Der sollte sich mit den Grundlagen beschäftigen.

Zitat:

Zitat von Insider2004 (Beitrag 1082931)

.net-Programme sind im Schnitt 5-15 Mal langsamer als Native-Programme.

Beispiele? Wenn's man richtig macht dann hat man in managed Umgebungen keine Performance oder Ressourcenprobleme. Es existieren einige Fallgruben die man kennen muss (z.B. Stringbuilder statt String-Operationen).

[Thom]

@Phoenix

In der Regel halte ich mich von der aktiven Teilnahme an solchen Diskussionen zurück - aber hier kann ich einfach nicht anders... :-D

Daß Du - bedingt durch deine Arbeit und Deinen Brötchengeber bereit bist, alles zu schwören, was die Leisungsfähigkeit und Vorteile EURER Software anbelangt, ist irgendwie verständlich und nachvollziehbar. :wink:

Ungeachtet dessen ist gut programmierter nativer Code systembedingt schneller als ein gleich gut programmierter interpretierter (managed) Code. Denn ein Prozessor kann eben keinen prozessorunabhängigen Code (z.B. NET) ausführen - denn das ist ja genau die Philosophie, die dahinter steckt: Die Hardware-(Prozessor-)unabhängigkeit. Und diese Übersetztung benötigt Zeit - egal wie klein sie auch sein mag.

Natürlich ist ein optimiertes NET-Programm schneller als ein schlampig programmiertes und/oder umständlich compiliertes natives Programm - egal ob Delphi, C oder sonstwas.

Ich habe schon unter Windows 3.1 auf einem 220MHz-Rechner (oder waren's 230MHZ?) halbtransparente Fenster über den Desktop gezogen (das war ein Programm zur Vorbereitung von Dia-Shows). Dazu hatte ich handoptimierten Assemblercode (inline mit Delphi) und jede Menge Tricks benutzt. Mach' das bitte mal mit NET... 8-) Natürlich ist das heute mit Prozessoren oberhalb der 2GHz-Grenze kein Problem mehr. Es stehen Mehrkern-CPU und die entsprechenden Grafikbeschleuniger zu Verfügung.

Genau aus diesem Grund programmiere ich schon immer mit Rechnern der unteren Leistungsklasse: Wenn meine Programme dort laufen, habe ich die Gewißheit, daß sie auch auf schnelleren PC's ohne Leistungseinbußen funktionieren.

Noch eine Bemerkung zur NET-Philosophie: Logischerweise ist der integrierte Funktionsumfang einer Laufzeitbibliothek von hunderten Megabyte größer als bei einem nativen Programm von meinetwegen 2MByte (wenn ich's noch einmal durch den Delphi 5-Compiler jage, bleiben davon noch ca. 500kByte übrig).
Wenn ich zum Beispiel auf einem virtuellen Server mit einem Windows-System ein kleines Datenbanktool von ca. 1MByte Größe nutzen will und anschließend erst noch NET nachinstallieren soll, um das Progrämmchen überhaupt nutzen zu können, dann kocht es in mir - und ich suche nach dem erst besten nativen Tool.

Wozu - um alles in der Welt - soll ich zu einer interpretierten Sprache greifen, wenn ich ausschließlich für Windows programmiere? Weil es "moderner" ist? "Cooler"? Weil haufenweise neue Sprachkonstruktionen enthalten sind, die ich nicht mal ansatzweise benötige!?

Nenne mir bitte nur eine einzige Sache, die ich mit nativem Delphi nicht hinbekomme, sondern nur mit NET (abgesehen von der - eingeschränkten - Plattformunabhängigkeit! :gruebel:

[Bernhard Geyer]

Zitat:

Zitat von Daniel (Beitrag 1082932)

... und ganz am Rande ist es weder den einen noch den anderen bisher gelungen, ein Programm zu skizzieren, das nativ oder managed per se schneller oder langsamer sein muss.

In der c't wurde vor ein paar Jahren ein Vergleich zwischen C/C++, Delphi, Java u. .NET im Bezug auf Performance der Sprachbasis gemacht.

Zusammengefasst war das Ergebnis (wenn ich's noch hinbekomme):
C/C++ ist im Bereich "Number-Crunsher" unschlagbar. Sobald jedoch objektorientierte Techniken (Vererbung/Oveloading/...) ins Spiel kommen ist C/C++ der abgeschlagene Letzter. Delphi/Java/.NET nehmen sich nicht viel.