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

[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.

[Assarbad]

Zitat von Phoenix:

@Oliver: Nein. Bereits Mitte 2008 war der Marktanteil von Windows 2000 bei 2,25 %. Ende letzten Jahres taucht es schon gar nicht mehr in der Auflistung der Marktanteile auf.

Wow. Ich merke ihr entwickelt für ein komplett anderes Marktsegment. Wenn bei uns ein großer Kunde sagt daß sie gern eine Lösung für's komplette Netzwerk hätten und dort Windows 2000 das Ausschlußkriterium auf unserer Seite wäre, dann wäre das Geschrei aber groß. Ja, wenn bei insgesamt 2000 Rechnern zwei dabei sind die Windows 2000 haben, dann wäre dies genug unserer Produkt nicht zu nehmen.

Und Statistiken glaube ich ohnehin nur wenn ich sie selber fälschen dufte.

Zitat von Phoenix:

Mit Windows XP kann ich leben, und ob nun ein- oder Mehrkernprozessor ist mir persönlich schnuppe, und auch auf 1/2 GB ram kann ich arbeiten, wobei ich der Meinung bin dass es solche Sachen im Consumer-Markt nicht mehr gibt. 2 sind wahrscheinlich schon eher Standard.

Bei neuen Rechnern ganz sicher. Und genau darauf wollte ich hinaus.

Zitat von Phoenix:

Mir geht es zudem nicht um fühlbare, sondern um faktisch messbare Performance. Von mir aus darf auch gerne jeder für sich festlegen, wo die Performance gemessen wird.

Sobald sie fühlbar wird, ist sie einfach auch ohne Profiler objektiv meßbar. Nicht mehr und nicht weniger war in dieser Aussage enthalten.

Zitat von Phoenix:

Die .NET Plattform ist eine vom System bereitgestellte Laufzeitumgebung, genauso wie die Delphi RTL eine einkompilierte Laufzeitschicht ist.

Irrtum. Das ist sie erst seit Windows Vista. Wenn du dich so intensiv damit beschäftigt hast, sollte dir dies bewußt sein.

Zitat von Phoenix:

Wieso eines von beiden schneller oder langsamer sein soll ist mir unklar.

Mehr Abstraktion, weniger Abstraktion ... eigentlich mit der von dir zitierten Logik einfach zu begreifen

Zitat von Phoenix:

.NET hat gegenüber einem vollständigen nativem Kompilat den Vorteil, dass es aus einem Vorkompilat erst auf dem eigentlichen Zielsystem ein für genau dieses System optimiertes Endkompilat erzeugt welches letztlich auch in nativem Code resultiert und als solcher ausgeführt wird. Warum sollte ein für ein Zielsystem optimiertes Kompilat langsamer sein, als ein Einheitsbrei-Zeug in One-fits-it-all Size?

Hohoho. Jetzt mal langsam. Entweder wir reden hier von nativen Anwendungen oder wir reden von Delphi-Anwendungen. Leg dich mal fest.

Es gibt genügend Compiler die in der Lage sind sehr gut optimierten Code zu erzeugen. Es gibt sogar "CPU-Weichen" in derlei optimiertem Code. Einfach mal nen Disassembler zur Hand nehmen und selber gucken ...

Wenn Delphi das alles nicht so perfekt beherrscht, ist dies noch kein Argument für deine Behauptung

Zitat von Phoenix:

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.

Was aber nichts mit Systemabstürzen zu tun hat, denn dazu existieren ganz andere Mechanismen für die man sich ein wenig mit dem Windows-Kernel beschäftigen sollte.

Wenn ich unfair wäre, würde ich noch schnell ein paar der Mechanismen erwähnen, die dann greifen wenn das System wenig Speicher hat. Und daß das .NET Fx dafür der Grund sein könnte, würde ich dann ganz unschuldig anfügen ...

Aber es geht uns ja hier darum die Wahrheit herauszuarbeiten ...

Zitat von Phoenix:

Ganz und gar nicht. Ich mag natives Delphi Aber ich kann es auf den Tot nicht ausstehen, wenn hier jemand so penetrant einen absoluten geistigen Dünnschiss von sich gibt, der beweisbar falsch ist. .NET ist nunmal nicht pauschal 5-10 mal langsamer als nativer Code.

Pauschale Aussagen sind immer Unsinn, aber die Kernaussage war, daß .NET-Code langsamer läuft. Und mit einem hinreichend genauen Profiler ließe sich dies auch nachweisen, nur kenne ich leider keinen Profiler der die .NET-VM als das betrachtet was sie ist und bei dem man dann die Messungen absolut auf gleicher Ebene (nämlich Win32) durchführen könnte. Nur damit ließen sich derlei Aussagen entkräften oder unterstützen.

Zitat von hanspeter:

Wobei eine Art Supervisor die Applicationen überwacht hat und gnadenlos rausgekickt hat, wenn sie sich nicht benehmen konnten.

Klingt ein wenig nach dem Microkernel-Prinzip.

[MGC]

Also bei uns im Unternehmen stehen hauptsächlich Pentium 4, einige Pentium 3 und Celeron-Systeme. Die Dual- und Quad-Core stehen nur in den Büros der Unternehmensspitze, sowie bei den Admins. Die Server sind allerdings auf aktuellem technischen Stand. Bei einem Bundeslandweit verzweigtem Unternehmen kommen da schon einige Rechner zusammen.
Und bei mir zu Haus siehts momentan auch nicht so rosig aus (1 Pentium 4 mit XP Prof., 1 Celeron Lappy mit XP Home und 1 Celeron mit Win 2000). Ersteren hab eich mir mal vor einigen Jahren neu gekauft, zweiteren gebraucht und dritteren zu Testzwecken kostenlos abgegriffen. Immer wieder aktuell mit der Heimtechnik zu sein übersteigt ein wenig mein Budget, da ich schließlich auch noch ein wenig Geld für Familie und Hausbau ausgeben muss/möchte.
Höchstwahrscheinlich tauche ich damit nicht mehr wirklich in der Statistik auf, ausser im Vergleich eine ähnliche Haushaltssituation vorweisen zu können, die auch beruflich in meinem Sachgebiet vorherrscht.

[hanspeter]

Microkernel?
Ist IBM glaube Z9 mit 512 Prozessoren.

[Stevie]

Für mich persönlich zeichnet sich in diesem Thread mal wieder das Bild ab, was ich allgemein von der Delphi Community habe (sorry, subjektive Verallgemeinerung). 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. Und genau deshalb sehe ich noch ein Riesenpotenzial in .Net. Schonmal vernünftige IoC Container oder GUI Frameworks (nur mal als Beispiel genannt) in Delphi gesehen? Geschweige denn welche, die open source und hoch qualitativ sind. Oder Diskussionen über Design Pattern in nem Delphi Forum? Fast nicht vorhanden - und wenn, dann von besagten Personen, die sich auch in anderen Sprachen umschauen.

[Assarbad]

Zitat von Stevie:

Für mich persönlich zeichnet sich in diesem Thread mal wieder das Bild ab, was ich allgemein von der Delphi Community habe (sorry, subjektive Verallgemeinerung). 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.

Dann sollte ich nach meinen sehr langen Beiträgen vielleicht noch klarstellen, daß ich seit 2006 kaum noch mit Delphi zu tun habe. Obwohl ich erst letzte Woche einem FLOSS-Projekt beigetreten bin, welches überwiegend in Delphi entwickelt wird und die Kenntnisse alle noch da sind.

Interessanterweise ging es hier aber um die quantifizierbaren Vor- und Nachteile von .NET und nicht um die (subjektive) "Aufgeschlossenheit" gegenüber diversen Technologien. Die Tatsache, daß alte Systeme noch existieren und unterstützt werden müssen, läßt sich auch mit allen Vorteilen von .NET und unter Ausblendung aller Nachteile nicht kleinreden.

Wenn ich dir sage, daß ich Lisp lerne, bedeutet dies, daß ich in deinen Augen rückwärtsgewandt bin, oder stehe ich damit wieder auf einer Stufe mit denen die F# regelmäßig benutzen? ...

[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.

[Stevie]

Zitat von Assarbad:

Interessanterweise ging es hier aber um die quantifizierbaren Vor- und Nachteile von .NET und nicht um die (subjektive) "Aufgeschlossenheit" gegenüber diversen Technologien. Die Tatsache, daß alte Systeme noch existieren und unterstützt werden müssen, läßt sich auch mit allen Vorteilen von .NET und unter Ausblendung aller Nachteile nicht kleinreden.

Das Thema steht oben auf der Seite...
Und dazu gehört nunmal auch die Entwickler, die es nutzen. Innovationen und Ideen fördern die Weiterentwicklung. Und die sehe ich persönlich stärker auf .Net Seite als auf Delphi Seite. Gründe habe ich im vorherigen Post angeschnitten.

Zitat von Insider2004:

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.

Ja, Delphi XE ist bei weitem die beste Delphi Version ever und ich bin auch bekennender Delphi Jünger. Aber dass es nichts besseres gibt, wage ich mal in Frage zu stellen. Und dass die Produktivität damit so hoch sei auch. Vorrausgesetzt, du hast dir schon für Unsummen diverse kommerzielle Komponenten gekauft vielleicht.

[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 )