Delphi Prism XE

[mkinzler]

Wenn man in Pascal Syntax für .Net entwickeln will, ist Delphi.Prism die richtige Lösung.

@himitsu: Es geht um Delphi.Prism XE(2) nicht Delphi XE(2)

[Phoenix]

Zitat von Stevie:

Welche Argumente (bitte kein Marketing Gefasel und das "Du kannst Delphi Syntax verwenden" Argument) gibt es eigentlich, mit Delphi Prism zu entwickeln?

Nun.. eigentlich war "Du kannst (für .NET) Delphi Syntax verwenden" einer der Hauptgründe Hauptgrund für die Entwicklung von Chrome, und ist damit eigentlich auch einer der Hauptgründe für Prism.

Wobei sich hier aufgrund der zugrunde liegenen Sprache Object Pascal natürlich ganz neue Dimensionen für Plattformunabhängigkeit auftun. Der wichtigste Punkt ist, dass man Business-Logik wiederverwenden und zwischen Delphi und Prism (und zukünftig auch Cooper für Java)sharen kann. Das erlaubt es einem Delphianer, die Logik-Teile seiner Anwendungen ungeheuer effizient nach .NET und damit auf alle anderen Plattformen wie Linux, Mac OS X, andere Unixoide, ins Web, in die Cloud und auf alle relevanten mobilen Geräte zu bringen. Die Alternative wäre, entweder seine Delphianer teuer auf C# zu schulen oder sich neue C#-Entwickler zu suchen und diese dann die ganzen Sachen nochmal neu schreiben zu lassen. Das ist in aller Regel nicht wirtschaftlich.

Mal davon abgesehen dass man massiv weniger Code zu schreiben braucht als mit C# (z.B. durch so nette Sprachfeatures wie den : -Operator oder einen besseren Support von Nullables). Daneben werden einem dann noch einige Sachen vom Compiler abgenommen, wie z.b. die vollständige Implementierung von INotifyPropertyChanged. In C# schreibt man sich hier einen Wolf mit Events, in Prism ist das ein einziges Keyword nach dem Property. Auch inline properties sparen ungeheuer viel Code. Ich habe letztes ein DB-Update-Framework von C# nach Prism portiert und habe ca. 1/3 Code gespart. Ein Drittel weniger schreiben zu müssen heisst in aller Regel schneller fertig zu sein und vor allem auch ein Drittel weniger potentielle Fehlerquellen zu haben.

Dann kann man mit Prism viele Sachen von Haus aus machen, für die man mit C# nochmal externe Frameworks und aufwändige Infrastrukturen braucht, wie z.B. Aspektorientierte Programmierung oder Class Contracts.

Class Contracts sind z.B. eine Sache, die ungeheuer gerne von Prism Usern verwendet werden, und die schon seit 'Chrome'-Zeiten in der Sprache verfügbar waren. C# kam erst Jahre später (also seit 4.0) mit einem änlichen, aber nicht so flexiblen Feature um die Ecke.

Alles in allem ist es für ein Unternehmen letzlich eine Frage, wo man sparen will. Am Schulungsaufwand der Delphianer auf C# oder an neuen Entwicklern und am Portierungsaufwand von Delphi nach C#, oder an Lizenzen. Prism ist für Delphianer einfach die effizienteste Möglichkeit, in der .NET Welt Fuss zu fassen.

Zitat von Stevie:

Das Netz quillt über von C# Code für fast jedes Problem

Den kannst Du einfach kopieren und als Oxygene-Code in Dein Prism-Projekt pasten.

[Stevie]

Danke für die Infos. Einiges davon klingt plausibel. INotifyPropertyChanged. Allerdings hab ich noch arge Problem das zu glauben:

Zitat von Phoenix:

Wobei sich hier aufgrund der zugrunde liegenen Sprache Object Pascal natürlich ganz neue Dimensionen für Plattformunabhängigkeit auftun. Der wichtigste Punkt ist, dass man Business-Logik wiederverwenden und zwischen Delphi und Prism (und zukünftig auch Cooper für Java)sharen kann. Das erlaubt es einem Delphianer, die Logik-Teile seiner Anwendungen ungeheuer effizient nach .NET und damit auf alle anderen Plattformen wie Linux, Mac OS X, andere Unixoide, ins Web, in die Cloud und auf alle relevanten mobilen Geräte zu bringen. Die Alternative wäre, entweder seine Delphianer teuer auf C# zu schulen oder sich neue C#-Entwickler zu suchen und diese dann die ganzen Sachen nochmal neu schreiben zu lassen. Das ist in aller Regel nicht wirtschaftlich.

Das trifft meiner Meinung nach auf "Bilderbuch" Code zu, aber in .Net programmiert man doch komplett anders, hat andere Möglichkeiten etc. Wenn ich dann einfach meinen Delphi Code nehme und den 1:1 portiere, hab ich doch nix gewonnen, oder? Allein die GC Geschichte ist doch nen ganz anderer Hut. Ich hab schon Code von Delphianern gesehen, die C# Code geschrieben haben und mir haben sich die Fußnägel gekräuselt, was da für Anstalten gemacht wurden teilweise (und ich selber programmiere nicht in C#)
Nicht, dass ich es nicht glauben will, aber ich hab schon so vielen gewachsenen und verfrickelten Delphi Code gesehen, der niemals im entferntesten auch nur in Prism laufen würde.

[stahli]

Etwas OT: Wofür steht eigentlich das "XE"?

[Phoenix]

Zitat von Stevie:

Das trifft meiner Meinung nach auf "Bilderbuch" Code zu, aber in .Net programmiert man doch komplett anders, hat andere Möglichkeiten etc. Wenn ich dann einfach meinen Delphi Code nehme und den 1:1 portiere, hab ich doch nix gewonnen, oder? Allein die GC Geschichte ist doch nen ganz anderer Hut. Ich hab schon Code von Delphianern gesehen, die C# Code geschrieben haben und mir haben sich die Fußnägel gekräuselt, was da für Anstalten gemacht wurden teilweise (und ich selber programmiere nicht in C#)
Nicht, dass ich es nicht glauben will, aber ich hab schon so vielen gewachsenen und verfrickelten Delphi Code gesehen, der niemals im entferntesten auch nur in Prism laufen würde.

Wenn man extrem verfrickelten Code, wo alles in OnClicks drin steht und auf VCL Komponenten zugreift hat man freilich verloren. Da muss man aufräumen.
Aber selbst in dem Fall ist massives 'Refaktorieren' vermutlich weniger aufwändig als neu zu schreiben. Und dabei kann man dann eine saubere Architektur reinziehen.

Aber im Prinzip geht es auch nicht um das retten von 100% Altcode. Wenn man eben die Anforderung hat, seine Anwendung ins Web und auf Mobile Geräte zu bringen wird in aller Regel eh nicht das komplette featureset benötigt, sondern immer nur Teilbereiche. Und wenn man die einzeln anpackt und entsprechend aufbereitet hat man eben mit einem mal seinen Altcode aufgeräumt und gleichzeitig nochmal ein paar Plattformen damit bedient. Das erfordert natürlich etwas Disziplin, ist aber erfahrungsgemäß sehr effizient und erfolgreich.