.net-Strategie von Microsoft (?)

[JasonDX]

Zitat von bodenheim:

Warum dann .net, warum nicht Win32?

Plattformunabhängigkeit ist ein Faktor. Produktivität ein anderer. Unter keiner (kaum einer) nativen Sprache konnte man Klassen und ganze Bibliotheken einfach so verwenden, und dabei eine so große Klassenbibliothek als gegeben voraussetzen. Es ist Programmiertechnisch ein Fortschritt, genauso wie es ein Konkurrent zu Java sein soll.
Und was die Plattformunabhängigkeit betrifft, so gibts hier 2 unterschiedliche Seiten zu betrachten.
Einmal die Hardware-Seite: Dadurch, dass man Bytecode, und kein endgültiges Kompilat hat, sind immer Optimierungen auf die Zielplattform möglich. (Multi-CPU, Speicher vs. Geschwindigkeits-Auslastung, 32 vs. 64Bit). In der Hinsicht also hauptsächlich für alle von Vorteil.
Von der BS-Seite betrachtet ist auch hier eine gewisse Unabhängigkeit von Vorteil, wenn sie sich durchsetzt - auch für Microsoft. Man nutzt ihr Technologie, und unterstützt damit mehere Plattformen. Sie verkaufen einen geringen Prozentsatz an Versionen von Windows weniger, aber ich möcht gern wissen, wieviele Leute andere MS-Programme auf anderen Systemen gern nutzen (=kaufen) würden. Office:mac lässt dies nur erahnen

greetz
Mike

[Khabarakh]

Zitat von bodenheim:

Also geht es bei der Strategie um Plattformunabhängigkeit, [...]

Dann würde Microsoft Mono doch wohl selbst entwickeln . Mit dem zweiten Punkt hast du allerdings genau ins Schwarze getroffen: Java und .Net sind die zwei großen Managed Code Runtimes.
Natürlich wird man immer Kritikpunkte gegen eines der zwei Frameworks finden, aber ganz allgemein sollte eigentlich jeder Entwickler zustimmen: Wenn es nicht um höchste Performance geht, ist managed Code gegenüber unmanaged Code im Vorteil. Dieses Gebiet wollte Microsoft Sun natürlich nicht kampflos überlassen.

Zitat von NamenLozer:

Ich glaub eher, es geht darum, Mitbewerber für IDEs auszugrenzen.

W..t..f?
Abgesehen davon, dass es keinen .Net-IDE-Markt gibt oder je gab (frag einmal die .Net-3.5-Entwickler, ob sie schon einmal was von RAD Studio gehört haben, das Ergebnis würde mich interessieren. Und Sharp/MonoDevelop wird (leider) auch nie eine ernsthafte Konkurrenz sein), was soll das für eine Logik sein? "Wir gründen eine neue Plattform, um dort alle anderen zu verdrängen"?
Es gibt nur zwei Gründe, warum die Entwicklung so schnell vonstatten geht, dass sogar manche Entwickler nicht mehr hinterherkommen: .Net ist jung und Microsoft kann es sich leisten. Und ich freue mich drüber.

Zitat von NamenLozer:

Wenn es etwas gibt, was Microsoft unbedingt vermeiden will, dann dürfte das wohl Plattformunabhängigkeit (außer natürlich bei Sachen wie Pocket PC, die ja wiederum mit Windows betrieben werden) sein

Wohl nicht komplett, warum würden sie sonst Mono unterstützen ? Und mit Silverlight 2.0 wird bald sogar höchst offiziell ein .Net-Subset auf MacOS und Handys laufen.

[edit]Das wären dann 7 unsichtbare rote Kästen. Jo . [/edit]

[Bernhard Geyer]

Zitat von NamenLozer:

Java auch nicht. Trotzdem ist es langsamer.

Komisch? Ich kenn ein paar Java-Anwendungen bei denen ich keine native-Anwendung kenne die genauso schnell ist. Liegt wohl eher an den Programmen die du kennst die inperformant entwickelt wurden.

Zitat von JasonDX:

[Einmal die Hardware-Seite: Dadurch, dass man Bytecode, und kein endgültiges Kompilat hat, sind immer Optimierungen auf die Zielplattform möglich. (Multi-CPU, Speicher vs. Geschwindigkeits-Auslastung, 32 vs. 64Bit). In der Hinsicht also hauptsächlich für alle von Vorteil.

Theoretisch stimmt das, aber AFAIK hat in diesem Bereich MS noch nichts implementiert.

[Reinhard Kern]

Zitat von Bernhard Geyer:

Zitat von bodenheim:

Läuft doch auch schneller.

Falsch! .NET Programme sind teilweise schneller als Delphi-Progamme. Kinderkrankheiten von Java darf man nicht einfach auf .NET umsetzen.
.NET ist kein Interpreter-System!

Falsch ist es sicher nicht - wie immer das technisch begründet ist, ich kenne verschiedene Software, z.B. eine bekannte einfache Buchhaltung, die nach Umstellung auf .NET etwa die 20fache Zeit zum Start benötigt. Die Software ist funktionell mit der vorherigen Version ansonsten so gut wie identisch, schliesslich kann man in eine Buchhaltung nicht beliebig Features einbauen.

In allen Fällen, in denen es vergleichbare Lösungen in Win32 und .NET gibt, z.B. wegen einer Umstellung, ist .NET um mindestens den Faktor 10 langsamer.

Gruss Reinhard

[Bernhard Geyer]

Zitat von Reinhard Kern:

Falsch ist es sicher nicht - wie immer das technisch begründet ist, ich kenne verschiedene Software, z.B. eine bekannte einfache Buchhaltung, die nach Umstellung auf .NET etwa die 20fache Zeit zum Start benötigt. Die Software ist funktionell mit der vorherigen Version ansonsten so gut wie identisch, schliesslich kann man in eine Buchhaltung nicht beliebig Features einbauen.

In allen Fällen, in denen es vergleichbare Lösungen in Win32 und .NET gibt, z.B. wegen einer Umstellung, ist .NET um mindestens den Faktor 10 langsamer.

Dann haben die Verantwortlichen einen der Grundfehler der SW-Entwicklung gemacht: Die Umstellung eines System auf eine andere Plattform bei der gleichen Architektur nur um der Umstellung willen läuft eigentlich immer schief.

Wir selbst lösen gerade eine .NET-Anwendung ab (mit einer Delphi-Win32 und Java-Lösung) welche erst in den letzten Jahren von einer alten Win32-Lösung "1:1" auf eine .NET-Lösung portiert wurde. Die .NET-Lösung hatte den Charm einer Win3.1-Anwendung und war dementsprechend schlecht bedienbar da die veraltete Bedienphilosophie ebenfalls übernommen wurde.

[s-off]

Zitat von Reinhard Kern:

In allen Fällen, in denen es vergleichbare Lösungen in Win32 und .NET gibt, z.B. wegen einer Umstellung, ist .NET um mindestens den Faktor 10 langsamer.

Wobei ich mir gut vorstellen kann, dass bei einer Umstellung nicht unbedingt in den Maßen auf Performanceoptimierung geachtet wird wie es bei einer Neuentwicklung der Fall wäre.

[OregonGhost]

Zitat von Reinhard Kern:

Zitat von Bernhard Geyer:

Zitat von bodenheim:

Läuft doch auch schneller.

Falsch! .NET Programme sind teilweise schneller als Delphi-Progamme. Kinderkrankheiten von Java darf man nicht einfach auf .NET umsetzen.
.NET ist kein Interpreter-System!

Falsch ist es sicher nicht - wie immer das technisch begründet ist, ich kenne verschiedene Software, z.B. eine bekannte einfache Buchhaltung, die nach Umstellung auf .NET etwa die 20fache Zeit zum Start benötigt. Die Software ist funktionell mit der vorherigen Version ansonsten so gut wie identisch, schliesslich kann man in eine Buchhaltung nicht beliebig Features einbauen.

In allen Fällen, in denen es vergleichbare Lösungen in Win32 und .NET gibt, z.B. wegen einer Umstellung, ist .NET um mindestens den Faktor 10 langsamer.

Gruss Reinhard

Ich kann dir ohne weiteres ein Win32-Programm schreiben, das langsamer ist als jedes .NET-Programm. Und nun? Wenn die Software um den Faktor 10 langsamer ist, dann ist sie schlecht programmiert. Die einzige Schwäche von .NET ist die Kaltstartzeit. Sobald man die hinter sich hat, kann man damit Code schreiben, der genauso schnell ist oder sogar schneller läuft (z.B. konstruiere und zerstöre mal 100.000 Objekte in schneller Folge - du wirst überrascht sein, wie langsam hier C++ und Delphi sind und wie schnell .NET und Java sind). Tut mir leid, aber diese ewigen Verallgemeinerungen, weil irgendjemand mal irgendwo was gesehen oder gesagt hat, werden langsam langweilig. John Carmack hat auch mal gesagt, dass Direct3D die schlechteste und langsamste 3D-API ist, die es gibt... und wieviele Spiele werden jetzt nochmal in Direct3D entwickelt? Hoppla.
Ich weiß, dass es immer noch eine Menge Leute gibt, die diesen ulkigen "Tests" glauben, in denen Java und .NET um den Faktor 15 langsamer sind als nativer Code. Aber das stimmt einfach nicht. Natürlich kann man in C++ noch schneller sein. Aber dafür sitzt man dann Wochen an der Optimierung, nur um hinterher 5% gewonnen zu haben. Supi. Und übrigens selbst gesehen. Und wenn ich mir so die Performance von z.B. der VCL und Qt angucke im Vergleich zu .NET, dann steht letzteres noch nicht einmal so schlecht da.

Also nochmal in Kurzfassung meinen beiden Vorrednern folgend: Wenn man sein Programm durch die Portierung nach .NET um den Faktor 10 langsamer macht, dann hat man das Programm den Paradigmen der alten Entwicklungsumgebung folgend umgesetzt und hat damit schlampig gearbeitet.

Weiter zum Thema: Warum sollte man ein Win32-Programm schreiben wollen, wenn man ein .NET-Programm schreiben kann?

[bodenheim]

Zitat:

Weiter zum Thema: Warum sollte man ein Win32-Programm schreiben wollen, wenn man ein .NET-Programm schreiben kann?

Weil viele das net Framework gar nicht installiert haben; schon gar nicht Mono.
eine Java RE hat aber jeder.

[OregonGhost]

Zitat von bodenheim:

Weil viele das net Framework gar nicht installiert haben; schon gar nicht Mono.
eine Java RE hat aber jeder.

Falsch. Java muss man auch installieren. Jeder gekaufte PC mit XP SP2 hingegen hat .NET 2.0 vorinstalliert. Unter Vista kann man .NET 2.0 nicht mehr deinstallieren, ausgeliefert wird es mit 3.0. Man bekommt es davon abgesehen per Windows Update (als empfohlenes Update)

Mono unter z.B. Linux ist genauso trivial zu installieren wie eine JRE.

Aber das war bei meiner Frage gar nicht der Punkt. Der Punkt war, warum man sich mit Win32 herumärgern sollte, wenn man .NET benutzen kann, aus reiner Entwickler- und nicht aus Vertriebssicht.

[bodenheim]

Zitat von OregonGhost:

Zitat von bodenheim:

Weil viele das net Framework gar nicht installiert haben; schon gar nicht Mono.
eine Java RE hat aber jeder.

Falsch. Java muss man auch installieren. Jeder gekaufte PC mit XP SP2 hingegen hat .NET 2.0 vorinstalliert. Unter Vista kann man .NET 2.0 nicht mehr deinstallieren, ausgeliefert wird es mit 3.0. Man bekommt es davon abgesehen per Windows Update (als empfohlenes Update).
Mono unter z.B. Linux ist genauso trivial zu installieren wie eine JRE.

Dann hat Microsoft sein Monopol mal wieder gut genutzt, und es spricht nichts dagegen
Thx.