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

[MGC]

Zitat von Bernhard Geyer:

Zitat von MGC:

[Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Nein. Unter Delphi.Prism steht dir nur FCL zur Verfügung. Die VCL.NET war nur in Delphi for .NET verfügbar und ist mit Delphi 2007 entgültig gestorben.

Hm, das ist schade, diese Entwicklung ist mir leider ein wenig abhanden gekommen. Somit hätte sich eine Portierung von Altprojekten nach Prism für mich dann ohnehin erledigt.
Aber wenigstens erklärt das für mich jetzt den deutlichen Preisunterschied zwischen Prism und Delphi W32, da ja allem Anschein nach die Forms-Entwicklung zu MS ausgelagert wurde.

[Memnarch]

Wenn ich das was ich verstanden habe kurz zusammenfassen darf: .NEt bringt keine "AHA" vorteile. Je nach komplexität ist mein Programm wie immer an eine Plattform gebunden, "Portierungen" müssen selbst erledigt werden. Einige stellen sind schneller, einige stellen sind langsamer als beim NAtiveCode. Fragt sich welche? CPU lastige berechnungen für z.B Physic&Co (ati nutzer bleiben halt softwaregefangen)?

Hab ich was vergessen?


MFG
Memnarch

[Bernhard Geyer]

Zitat von MGC:

Hm, das ist schade, diese Entwicklung ist mir leider ein wenig abhanden gekommen.

Das hast du dich wohl in den letzten Jahren sehr Rar im Codegear-Forum gemacht ...

Zitat von MGC:

... da ja allem Anschein nach die Forms-Entwicklung zu MS ausgelagert wurde.

Die Form-Entwicklung ist nicht ausgelagert. Prism verwendet halt als das was MS im Framework als IDE-Unterstützung bereit stellt und setzt auch auf den VS.NET-Kern auf. Sinnvoller als wie bei Delphi.NET zwanghaft mit Mannjahren versuchen das nochmal nachzuimplementieren aber die nötigen Spracherweiterugen zu verschlafen. Partial-Classes war der Tod des WinForms-Support in Delphi for .NET.

[MGC]

Zitat von Bernhard Geyer:

Das hast du dich wohl in den letzten Jahren sehr Rar im Codegear-Forum gemacht ...

Ja, das gebe ich zu, war ein wenig eingefangen von meinen Projekten an der Arbeit und habe mich immer nur mal kurz um die .NET-Entwicklung gekümmert, da diese zum damaligen Zeitpunkt für mich kaum eine Relevanz für meine Projekte hatte.

Ich fasse hier also nochmal kurz für mich zusammen:
Es wird für mich auf jeden Fall interessant sich mit .NET mal richtig auseinanderzusetzen, insbesondere da ich im wissenschaftlichen Bereich tätig bin und auch wir über kurz oder lang mal unsere alten Rechner (Pentium 4) abschiessen werden und sich mir dann über das .NET-Framework mögliche Zusatzoptionen ergeben die ich unter W32 nur schwer umgesetzt bekomme.
Für meine kleinen Applikationen an Messgeräten die nichts anderes tun als Daten auszulesen und nach kleineren Verrechnungen über eien bereits vorhandene Schnittstelle in laufende DBMS einzupflegen brauche ich allerdings kein .NET, da alles inHouse läuft und keine Webunterstützung von Nöten ist.

Würdet Ihr mir nun raten mich eher mit Delphi Prism oder lieber mit C# auseinanderzusetzen? Immerhin ist C# ja eine Sprache die eigens für .NET entwickelt wurde, wenn ich das noch recht im Kopf habe.

Übrigens, vielen Dank an alle die bisher schon mitdiskutiert haben. Allmählich kommt Fahrt in die Sache und ich plane schonmal meine nächsten Fortbildungen ein.

[Phoenix]

Zitat von MGC:

Würdet Ihr mir nun raten mich eher mit Delphi Prism oder lieber mit C# auseinanderzusetzen? Immerhin ist C# ja eine Sprache die eigens für .NET entwickelt wurde, wenn ich das noch recht im Kopf habe.

Prism ist halt Object Pascal, und zudem noch fortgeschrittener als C#.

Die wichtigsten Beispiele bisher: LINQ gab es gut ein dreiviertel Jahr bevor C# es hatte, die Parallel Extensions hatte Prism auch über 12 Monate vor C#. Beim DLR-Support waren wir zugegebenermassen nur 3 Monate voraus, haben aber auch parallel an Cooper gearbeitet

Stand heute kann Prism von Haus aus aus auch Aspektorientierte Programmierung mittels einer zusätzlichen Assembly (Cirrus), wozu man in C# noch etliche Zusatztools und vor allem Post-Build-Prozesse benötigt (die dann u.a. auch das unmittelbare Signieren von Assemblies schwer machen). Bis C# AOP kann wird noch einige Zeit vergehen.

Daneben bietet Prism mit Interface delegation dann auch noch Language-Support, die man als C#'ler sehr schnell und sehr schmerzlich vermisst.

Nichtsdestotrotz bin ich der Meinung, dass ein .NET-Entwickler C# zumindest lesen können muss. Der Einzige Vorteil den C# geniesst ist der bessere Support von Drittherstellern.

Im übrigen kann ich Stahli gar nicht nachvollziehen. Ich bin mit .NET inzwischen bei jeder Anwendung schneller fertig als mit nativem Delphi, vor allem weil die API sehr eingänglich ist, das Debuggen viel effizienter geht und das Framework in nahezu jedem Bereich von Standardanwendungen schon etwas mitbringt, dass sich mal kurz ableiten bzw. bei Interfaces implementieren lässt um damit schneller ans Ziel zu kommen.

[stahli]

Da sind sie wieder ... Begriffe und Technologien, die ich nicht verstehe.

Na ja, ich habe mir Prism schon angesehen, aber keinen wirklichen Zugang gefunden. Es ist halt alles irgendwie so komisch...

Mit Delphi komme ich gut zurecht. Prism erfordert einige Umgewöhnung und erst einmal ein grundsätzliches Verständnis von .NET
Autodidaktisch ist das (für Hobbyprogrammierer mit wenig Tagesfreizeit) schon eine Herausforderung. Ich will ja auch mit meinem Projekt weiter kommen.

Wenn es Videotutorials für Prism gäbe, würde ich die gern abonnieren. Die meisten Beispiele, die man so findet sind aber natürlich für C#, eine zusätzliche "Erschwernis".

Bisher bleibe ich daher lieber bei meinem geliebten Delphi - der Weg des geringsten Widerstandes.
Und meine Nutzer sparen sich das ganze .NET-Geraffel.

Ob und wann ich das mal bereue, wird sich zeigen.

[Phoenix]

Zitat von stahli:

Prism erfordert einige Umgewöhnung und erst einmal ein grundsätzliches Verständnis von .NET
Autodidaktisch ist das (für Hobbyprogrammierer mit wenig Tagesfreizeit) schon eine Herausforderung. Ich will ja auch mit meinem Projekt weiter kommen.

Wenn es Videotutorials für Prism gäbe, würde ich die gern abonnieren. Die meisten Beispiele, die man so findet sind aber natürlich für C#, eine zusätzliche "Erschwernis".

Wie gesagt, ich bin der Meinung als .NET Entwickler sollte man auf jeden Fall C# lesen können. Und ja: Das .NET Framework ist sehr umfangreich. Das ist natürlich für den Einsteiger erstmal überwältigend, aber natürlich auch ein Riesen-Vorteil für den produktiven Einsatz.

Wobei man sich am Anfang erstmal auf ein paar Namespaces und die Sprachfeatures beschränken kann. Ohne LINQ z.B. will ich heute gar nicht mehr programmieren (das ist auch der Grund, warum ich natives Delphi inzwischen für unproduktiver halte). Es geht doch eigentlich immer darum irgendwelche Daten irgendwie durchzunudeln, und um Daten zu selektieren und ggf. in einem einzigen Schritt gleich durchzunudeln ist LINQ halt echt grandios.

[stahli]

Zitat von Phoenix:

Ohne LINQ z.B. will ich heute gar nicht mehr programmieren (das ist auch der Grund, warum ich natives Delphi inzwischen für unproduktiver halte). Es geht doch eigentlich immer darum irgendwelche Daten irgendwie durchzunudeln, und um Daten zu selektieren und ggf. in einem einzigen Schritt gleich durchzunudeln ist LINQ halt echt grandios.

Ok, LINQ ist schon interessant (mich würde allerdings eher nur die Objekt-Variante interessieren (LINQ to Objects)).

Seinerzeit habe ich mich für Prism in Verbindung mit ECO interessiert, das ja ähnliche Möglichkeiten bieten sollte.
Leider lief das nach meinen Erfahrungen nicht stabil und ich hätte es gern in Delphi genutzt.

Mal angenommen, ein LINQ würde es auch in Delphi geben (grundsätzlich sollte das ja machbar sein), wie würdest Du dann argumentieren?
(Ich meine das nur als ganz grundsätzliche Überlegung - also den Aufwand für Emba und Schwierigkeiten der Umsetzung etc. einfach mal außen vor lassen.)

Also ein Vergleich Delphi+LINQ mit Prism, sozusagen...

[MGC]

Nun wendet sich der Zeiger wieder eher zu .NET...
Ich glaube ich werde mir mal Prism im Privatbereich zulegen und das ganze mal genauer untersuchen (Lässt sich ja auch eher mal nebenher in der Prof-Version zahlen als D-W32).
Durch einige Erfahrungen im Randbereich mit Delphi für .NET 2005 (Damals war es noch nicht ganz so ausgereift wie heute) ist mir auch die Vorgehensweise nicht vollkommen unvertraut. Und ich hoffe mal das sich nichts grundlegendes an der FCL geändert hat, so dass ich auch jeder Zeit meinen Elmar Warken-Schmöker Delphi für .NET 2006 zu Rate ziehen kann.

Höchstwahrscheinlich wird es erstmal auf eine zweigleisige Delphi-Geschichte herauslaufen. Auf diese Weise bin ich dann auch in Zukunft eher gerüstet, wenn es mal eine Änderung in nur eine von beiden Richtungen gibt.

[rwachtel]

Zitat von MGC:

[...] so dass ich auch jeder Zeit meinen Elmar Warken-Schmöker Delphi für .NET 2006 zu Rate ziehen kann. [...]

Da Delphi PRISM so gar nichts mit Delphi for .NET gemein hat, solltest Du da nicht allzu viel erwarten.