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

[Daniel]

Das ist aber mal ein spannender Aspekt: Wenn ich also eine .NET-Anwendung habe und die "Amok" läuft, dann ist das Risiko, dass sie dabei den gesamten Rechner runterreißt geringer als bei einer nativen Anwendung? Lässt sich das pauschalieren oder gibt es auch hier wieder gewisse Rahmenbedingungen, die diese Sicherheit erst ermöglichen?

[Phoenix]

Zitat von Daniel:

Das ist aber mal ein spannender Aspekt: Wenn ich also eine .NET-Anwendung habe und die "Amok" läuft, dann ist das Risiko, dass sie dabei den gesamten Rechner runterreißt geringer als bei einer nativen Anwendung? Lässt sich das pauschalieren oder gibt es auch hier wieder gewisse Rahmenbedingungen, die diese Sicherheit erst ermöglichen?

Ja, diese Rahmenbedingungen sind die sogenannten Application Domains, die es in .NET gibt.
Stürzt ein .NET Programm ab, betrifft das nur die einzelne Application Domain, in der es läuft. Natürlich kann man mehrere Applications in einer Domain laufen lassen, aber man kann sie auch isolieren.

Bei ASP.NET ist es z.B. besonders interessant, da man hier mehrere Webanwendungen parallel laufen lassen kann und keine von diesen den gesamten Prozess des Webservers betrifft sondern nur die einzelne Applikation. Das funktionierte in älteren IIS-Versionen so gut, dass inzwischen mit IIS 7 und 7.5 die komplette Pipeline des IIS in Managed code läuft und sogar ISAPI-Extensions inzwischen von Managed code aus in unterschiedlichen Appdomains geladen werden, damit diese nicht den gesamten Webserver abschiessen können.

[hanspeter]

Passt nicht ganz dazu aber sicherlich interessant.
Auf der Maschine liefen 128 VM. In jeder VM konnten 64 Application Domains laufen. Maximal eine Application Domain konnte (fast) zum Absturz gebracht werden.
Wobei eine Art Supervisor die Applicationen überwacht hat und gnadenlos rausgekickt hat, wenn sie sich nicht benehmen konnten.

[Insider2004]

Zitat:

Die, die an Delphi allein festhalten, entwickeln oft noch für "alte" Systeme und die, die auch mit C#/.Net zu tun haben und sich interessieren, sind auch modernen Software Architekturen und Techniken gegenüber offen.

Das stimmt doch gar nicht. Wenn ich jetzt ein neues Projekt starten würde, dann würde ich mir Delphi XE Architect kaufen und native loslegen. Es gibt nicht besseres. Vor allem wegen der Produktivität und Freiheitsgrade.

[Meflin]

Zitat von Insider2004:

Es gibt nicht besseres. Vor allem wegen der Produktivität und Freiheitsgrade.

In welchen Communities - neben der Delphi / FPC - warst du in deinem Leben schon unterwegs? Können nicht viele gewesen sein, unterstelle ich mal...

[MGC]

Jetzt mal vollkommen Sprachunabhängig (Delphi gibt es mit Prism schließlich auch für .NET, zumindest eine Art moderner Delphi-Dialekt und mal abgesehen davon, das die FCL aus Erfahrungen der VCL heraus entstanden sind) und daher nur mal auf den momentanen Markt geschaut.

Es mag sein, dass Mammut-Projekte für Mammut-Unternehmen tatsächlich auf neue Technologien setzen sollten und das mit .NET auch ältere Systeme bis zu einem gewissen Grad eingebunden werden können, aber aus eigener Erfahrung weiss ich das es zahlreiche Klein- und Mittelstandsunternehmen gibt, die eben nicht alle Nase lang Ihre Rechner auf den neusten Stand bringen oder bringen können und auch in Großunternehmen ist dies nicht unbedingt der Fall, da z.B. Maschinen angeschafft wurden die ihren Lifecycle noch nicht beendet haben und dennoch auf ältere Systeme angewiesen sind.
Wenn diese nun über Netzwerk gesteuert oder kontrolliert werden sieht es mit .NET schon wieder anders aus. Hier müssen zumindest auch geeignete Schnittstellen geschaffen werden.
Und mal ganz abgesehen davon, die Qualität eines Produkts ist bei weitem noch nicht durch die Wahl einer Plattform oder einer Sprache gegeben.
Bei uns läuft leider ein .NET basiertes DBMS, welches bei weitem nicht so performant und sicher ist wie Non-.NET gestaltete Konkurrenzprodukte. Andererseits kenne ich jedoch auch ein österreichisches DBMS für den Laborbereich (.NET-basiert) und dieses ist in Performance und Sicherheit, sowie Kundenfreundlichkeit (auch die Kunden des DBMS nutzenden Unternehmens) momentan unschlagbar, wie man mir auch aus erfahrenen Anwenderkreisen bestätigt hat.

Auch vertriebene Laborgeräte mit internem OS sind nicht unbedingt an die modernsten Technologien gebunden, da z.B. für kleinere oder mittlere Unternehmen nicht unbedingt in kurzen Abständen in Neuentwicklungen investiert werden kann. Da jedoch die Geräte und deren interne Software ansich sehr zuverlässig arbeiten, werden sie gekauft, inkl. auf Lager gehaltenen Rechnern älterer Generationen, die mit Ihrer Gerätesteuerungssoftware (das externe Gegenstück) in eine bestehende IT-Landschaft eingepflegt werden müssen um Automatisierung zu erreichen.

Hierbei mal ganz abgesehen von gewünschten oder benötigten Indiviuallösungen für Betriebe, die dann Geld in eine Entwicklung stecken. Wenn als Ergebnis verlangt wird, das Unternehmen muss etwa die Hälfte der vorhandenen Arbeitsplatzrechner (z.T. sind dann da ggf. auch noch W98-Systeme dabei, aber auf jeden Fall noch W2K) durch neue ersetzt werden müssen, führt dies unweigerlich zu einem Interessenkonflikt zwischen Auftraggeber und Auftragnehmer.

Um zum Abschluss doch noch einmal auf die Sprachauswahl zu kommen. Wenn ich bedenke, dass ich in meinem Betrieb zum Programmieren gekommen bin wie die Jungfrau zum Kind und mich dennoch bereits mit verschiedenen Sprachen auseinandersetzen musste um bestimmte Vorgaben zügig und stabil umsetzen zu können, dann kann ich mir nicht vorstellen, dass vollberufliche Entwickler nur an einer Sprache oder Plattform "kleben".

Fazit für mich ist bisher:
Wer hauptsächlich für die Windows-Plattform (insbesondere ab VISTA aufwärts) entwickelt und dabei auch mobile Geräte (mit WP7 standard) mit der gleichen Software bestücken möchte, die auch auf PCs läuft, dann ist .NET eine hervorrande Wahl (anscheinend ebenso bei Spieleprogrammierern die auch für die XBoX entwickeln).
Sobald man für ein anderes OS entwickelt und nicht Windows-kompatibel sein muss, dann entscheidet man sich möglicherweise für komplett andere Entwicklungssysteme.
Der Hauptvorteil von .NET scheint darin zu liegen, das es als Sprachunabhängige Laufzeitumgebung Möglichkeiten schafft, die es (gerade für BASIC-Programmierer) ohne .NET nicht gegeben hätte. Nicht zu vergessen, der managed Code, der durch den Laufzeitcompiler auf das jeweils genutzte System compiliert wird und daher ein gewisser Fehleranteil, der Systemspezifisch war, nicht mehr auftreten sollte. Darüber hinaus steht dem Entwickler ein schier unüberblickbares Angebot an Komponenten zur Verfügung, wie es dies anscheinend nur unter .NET gibt (dabei von Redundanzen mal abgesehen).
Und der letzte Clou ist dann die GC, die es auch dem unerfahreneren Proggern (zu denen ich mich auch dazuzähle) erlaubt sich mal einen Lapsus zu gönnen und ein schönes Speicherleck zu produzieren, das dann lächelnd von der GC beseitigt wird und das System nicht bis zum Neustart zumüllt.

(Entschuldigt bitte die etwas platte ausdrucksweise. Es war schon spät )

[Assarbad]

Zitat von MGC:

[...] dann kann ich mir nicht vorstellen, dass vollberufliche Entwickler nur an einer Sprache oder Plattform "kleben".

Doch, auch die gibt es. Es gibt auch das genaue Gegenteil: jene die immer dem neuesten Trend hinterherlaufen ohne die Vor- und Nachteile abzuwägen.

Aber die neuesten Buzzwords finden sich eben auch in Zeitschriften die von "Entscheidern" gelesen werden, so daß man ggf. beim Bullshit Bingo gewinnen kann

Zitat von MGC:

Und der letzte Clou ist dann die GC, die es auch dem unerfahreneren Proggern (zu denen ich mich auch dazuzähle) erlaubt sich mal einen Lapsus zu gönnen und ein schönes Speicherleck zu produzieren, das dann lächelnd von der GC beseitigt wird und das System nicht bis zum Neustart zumüllt.

Das kommt auf den GC-Typ an. Allerdings ist es ein Mythos (wenn auch ein sehr beliebter), daß GC einen davon befreit sich um Speicher Gedanken zu machen ...

[Assarbad]

Zitat von Daniel:

Das ist aber mal ein spannender Aspekt: Wenn ich also eine .NET-Anwendung habe und die "Amok" läuft, dann ist das Risiko, dass sie dabei den gesamten Rechner runterreißt geringer als bei einer nativen Anwendung?

Nein. Es gibt keinen Unterschied. Relevant wäre es erst wenn eins von beiden im Kernelmode ausgeführt würde.