Wo der Vorteil von Delphi gegenüber Net liegen soll, ist im Moment schwer zu begründen.
Das stimmt leider. Man kann (wenn man es kann
) auch in .NET eine
DB-Oberfläche zusammenklicken wie mit Delphi.
Da gibt es eigentlich nur zwei Begründungen. Einmal riesige Altlasten an vorhandenen Programmcode und zum anderen ein fortgeschrittenes Lebensalter beim Programmierer.
Zweiteres zählt eigentlich auch nicht mehr. Wer sich von der
VCL an das .NET Framework - zumindest mal im Bereich Windows Forms - umgewöhnen möchte kann das sehr schnell tun, denn die Frameworks sind sich zumindest dort sehr ähnlich.
Um mit Delphi wieder neue Projekte anzufangen, müsste sich nach meiner Meinung konzeptionell einiges mehr tun.
Das beginnt bei der nicht threadsicheren
VCL, geht über das
BPL Konzept, was nur noch ein Klotz am Bein ist und endet nicht zuletzt bei der fehlenden Kompatibilität zu Net.
Auch in .NET gibt es sehr vieles, was nicht Threadsicher ist. Und manches muss man leider am eigenen Leib erfahren (ich mache viel ASP.NET, da fällt das schneller auf weil da je nach Serverkapazität schonmal etliche hundert Threads gleichzeitig losrattern können).
BPL's: Muss niemand nutzen. Kompatibilität: Wäre für mich hier kein Argument. Mann kann (reverse) P/Invokes machen und gut ist. Und auch hier gibts fertige Tools für - wenn es wirklich notwendig ist.
Wenn wenigstens in der
IDE die lästigsten Fehler langsam behoben würden.
Selbst wenn: Das kommt dann aber dank der Embc.-Politik wieder als 'neue Version' raus und nicht als SP.
Wenn man zumindest aus Delphi heraus ein Assembly aufrufen könnte oder ein Delphiprogramm problemlos in Net einbinden könnte.
Hydra?
Allein schon die Entschärfung der
Dll - Hölle durch das Assemblykonzept wäre ein Gewinn.
Prism sehen wir auch nur als Zwischenschritt zu C#. Dazu sind die Sprachelemente zu unterschiedlich.
Yikes. Von Prism dann der Rückschritt zu C#?
Wartet nochmal ein halbes Jahr ab, und überlegt Euch dann nochmal ob ihr mit den Features-To-Come wirklich auf Prism verzichten wollt
(nein, ich darf nicht verraten welche ich meine) 
Auch wenn
GUI und Code strikt getrennt sind, kann man nicht einfach die
GUI in Net neu schreiben und Delphi-Code über Prism ohne erhebliche Anpassungen weiterverwenden.
Der gleiche
VCL - freie Quelltext in Prism und Delphi ist Illusion. Prism hat die moderneren Sprachkonstrukte. Warum diese nicht in Delphi nachziehen?
Weil viele von diesen Sprachkonstrukten auf
IL-Internas basieren. Ich rede hier insbesondere von LINQ. Zumal der (neue) Prism-Compiler auch zu 100% managed ist. Das kann man nicht einfach so in einen nativen Compiler nachimplementieren ohne die Rückwärtskompatibilität zu opfern. Und wenn Embc. das macht, dann ist Delphi wirklich tot.
Multiplattform ist sicherlich interessant, darf aber nicht überbewertet werden.
In unserem Betrieb gibt es unter Java ein Projekt, welches auf Windows, Linux und Mac laufen soll.
Daraus sind inzwischen fast drei Projekte geworden. Eins für Window, eins für Linux ...
Fat clients sind auch kein Multiplatform-Ziel.
Wenn man so eine Anforderung hat, dann sollte man einen Application Server hinstellen der auf (mindestens) einer Platform läuft (die verbreitetste ist ein guter Ansatz, wobei man hier mit .NET bzw. Mono tatsächlich unabhängig sein kann), man packt eine X-Platform Bibliothek hin die den Zugriff auf diesen Application-Server abhandelt und baut für jede Platform einen *nativen* thin-client, der über diese Bibliothek mit dem Server spricht.
Was solche Diskussionen immer wieder aufkommen läßt, ist die mangelhafte Planungssicherheit und Informationspolitik.
Wenn Embacadero endlich mal Butter bei die Fische tut und eine belastbare Roadmap veröffentlicht wäre schon viel gewonnen.
Im Moment sind zu viele Fragezeichen, als das ich mich bei Entscheidungen zu Neuprojekten mit Delphi durchsetzen könnte.
Wahr. Leider zu wahr.