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
)