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.

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

[Robotiker]

Na das artet hier ja wieder in eine tolle Diskussion aus ...

Da ich seit Turbo Pascal 3.0 für C/PM und .net seit der 1.0 beta1 arbeite, erlaube ich mir mal meine bescheidene Meinung einzubringen.

Ja natürlich stimmt es, native Programme sind kleiner und laufen deshalb auch unter beschränkten Resourcen effizienter. Trotzdem ziehe ich heute für die meisten Anwendungen auf halbwegs aktuellen Rechnern (XP ab 1 GB Arbeitsspeicher) .net-Anwendungen vor. Ich arbeite damit effizienter und signifikante Performanceunterschiede sehe ich in der Praxis nicht.

Bei Anwendungen mit komplexen Rechnenoperationen (Simulationen, Bildverarbeitung) hat nativer Code deutliche Geschwindigkeitsvorteile. Aber hier ist nicht der native Code allein der Schlüssel, sondern der Compiler. Und da sieht es bei Delphi & Co nicht so gut aus. Ich benutzte teilweise den selben Code im C++ Builder und in Visual Studio. Da sind Geschwindigkeitsunterschiede von 50% ganz normal. Wenn man das ganze durch den Intel Compiler schickt, kommt teilweise noch mal der gleiche Unterschied raus.

[Daniela.S]

Ich bin gerade dabei ein größeres Projekt in asp .net mit Delphi Prism zu erstellen. Im Prinzip ist .net nicht so unterschiedlich von der vcl. Man merkt schon wer da seine Hände im Spiel hatte. Teilweise kann man nicht vcl Code von Delphi 1:1 übernehmen oder mit geringfügigen Anpassungen.

Was aber ein nicht unerheblich wichtiger Punkt bei der Entwicklung ist und uns in der Produktivität stark einschränkt ist Visual Studio. Fürchterlich langsam und unhandlich. Würde Prism in der Delphi XE-IDE laufen wäre das echt traumhaft. Noch nie konnten wir so schnell und produktiv arbeiten.

[Assarbad]

[OT]

Zitat von Robotiker:

Wenn man das ganze durch den Intel Compiler schickt, kommt teilweise noch mal der gleiche Unterschied raus.

Oh supi. Wenn du damit Erfahrungen hast. Der Code den man per ICC bekommt läßt sich doch danach üblicherweise auf AMDs auch noch ausführen, oder?

Haste ihn mal als Ersatz für GCC benutzt, oder nur in VS? War er gut zu handhaben als GCC-Ersatz?
[/OT]

Zitat von Daniela.S:

Was aber ein nicht unerheblich wichtiger Punkt bei der Entwicklung ist und uns in der Produktivität stark einschränkt ist Visual Studio. Fürchterlich langsam und unhandlich. Würde Prism in der Delphi XE-IDE laufen wäre das echt traumhaft. Noch nie konnten wir so schnell und produktiv arbeiten.

... echt? Ich benutze seit fünf Jahren Visual Studio nur mit Visual Assist X (VAX) und bin mit den Versionen ab VS 2005 eigentlich sehr zufrieden.

Mit Delphi + Castalia ist das leider nicht zu vergleichen, obwohl Castalia üblicherweise als die Delphi-Alternative zu Visual Assist X angesehen wird.

Naja, aber VAX hilft natürlich mit Prism nicht (gehört nicht zu den unterstützten Sprachen).

[MGC]

Es ist faszinierend wie schnell ich hier innerhalb sehr kurzer Zeit einen recht umfassenden Eindruck von momentanen Vorgängen in der IT-Welt kurzgefasst vorgefunden habe.
Ich habe auch festgestellt, dass ich mich in den letzten Jahren zusehr auf meine eigenen betriebsinternen kleinen Projekte konzentriert habe und daher kaum etwas von den Umbrüchen, die ich bei Vista noch nicht so deutlich wahrgenommen habe, mitbekommen habe, die anscheinend jetzt durch Win 7 forciert werden.

Da ich von Zeit zu Zeit auch mal kleine Seitenabstecher mit betriebsexternen Projekten habe (bei denen ich bisher nur Zuarbeit im Kleinen zu erledigen hatte), sehe ich nun durch diese Diskussion bei mir sehr großen Nachhol- und Weiterbildungsbedarf.

Um mir endlich mal einen Eindruck von den Unterschiedenen zwischen Delphi für .NET und Prism zu verschaffen, lade ich mir mal die Trial runter und probier einfach mal ein wenig herum.
Ausserdem scheint es für mich auch mal an der Zeit zu sein meine Heimtechnologie ein wenig aufzurüsten (Werde aber die Altrechner für Testzwecke am Leben erhalten).

Zitat von 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

Die "aufgeschlossenen Technologiestürmer" kenne ich, habe zeitweilig in jüngeren Jahren mal selbst dazugehört und bin dabei in einige Sackgassen geraten, die mich zum Umdenken gezwungen haben.
Doch die andere Seite? Gut, es gibt immer mal die ein oder andere Sprache die man lieber auswählt, da sie einem möglicherweise vertrauter ist, doch sollte man auch ehrlich zu sich selbst sein und die Anforderungen an ein zu entwickelndes System prüfen bevor man eine Sprache wählt.
Die Sache mit den "Entscheidern" kenne ich da schon eher wieder, wobei (muss ich mal Kleinlaut zuegeben) manchmal auch tatsächlich Leute mit einem guten Händchen und Feingefühl dabei sind.

Zitat von Assarbad:

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

Natürlich befreit einen die GC nicht vom Freigeben des Speichers, es sei denn man möchte es sich gern in einem größeren Projekt mal richtig mit den anderen Teilnehmern oder dem Auftraggeber verscherzen.
Ein Problem der GC ist vielleicht eher, dass man seine Fehlerchen bei Unachtsamkeit erstmal gar nicht recht bemerkt, bis einem mal jemand bescheid gibt, warum nicht mehr benötigte Objekte noch elends lang im System herumgeistern oder sogar erst freigegeben werden, wenn das Programm beendet wird. Dabei mal von anderen sicherheitsrelevanten Speichernutzungen ganz abgesehen, die man ohnehin vollkommen anders behandelt.

[Insider2004]

Soviel ändert sich gar nicht, wie man meint. Schaut euch mal Windows 2000 an. 12 Jahre alt. So viel Interfaceänderungen zu Windows 7 z.b. hat es gar nicht gegeben. Ich sehe zwischen den beiden OSen kaum einen Unterschied. Klar, Quickie-Bunti hat sich verändert, aber der technische Rest unter der Haube ist fast gleich geblieben.

Genauso mit Delphi. Seit Delphi 2 bis Delphi XE hat sich kaum was getan. Z.B. ist in Delphi XE immer noch der gleiche Floating-Point-Generator drin wie schon bei Delphi 2. Der Code ist der gleiche. Auch das Win32-Backend ist nahezu identisch. Im Prinzip alles nur Kosmetik. Einen Schub wird natürlich Delphi Win64 bringen.