Quo vadis Embarcadero?

[michaelthuma]

Oxygene funktioniert seit Jahren.

Zitat von franktron:

Hat eigentlich irgend jemand Erfahrungen mit Oxygene gemacht.

Wir möchte auch weg von Delphi das mit FMX ist nicht gerade der Bringer und Tablets sind im kommen.

[Harry Stahl]

Hier ein Auszug aus Wikipedia zur Beschreibung von Oxygene:

Zitat:

Criticism[edit]

Some people would like to port their Win32 Delphi code to Oxygene as is. This is not possible because while Oxygene looks like Delphi there are enough changes to make it incompatible for a simple recompile. While the name appears to give it the appearance of another version of Delphi that is not completely true.[6]

On top of the language differences the Visual Component Library framework is not available in Delphi Prism.[7] This makes porting even more difficult because classic Delphi code relies heavily on the VCL.

Wenn man nur wenige (kleine) Projekte hat, dann kann man vielleicht an einen Umstieg denken und seine Projekte noch mal neu aufsetzen.

Wenn man aber umfangreiche und langjährige Projekte hat (für meinen Fall komme ich durchaus auf einige Mio. Zeilen selbst erstellen Source-Code), dann sehe ich eine sinnvolle Zukunft definitiv bei Delphi (und bei FMX, auch wenn das zugegebener Maßen derzeitig noch deutliches Verbesserungspotential nach oben hat).

Delphi hat sich im Übrigen sehr wohl in den letzten Jahren weiter entwickelt, zum einen sei dazu auf die Beschreibungen von Marco Cantu in seinen Delphi Manuals verwiesen, zum anderen auf die Delphi Hilfe, dort unter RAD-Studio, RAD Studio Themen, "Neuerungen". Da kann man schon einige Stunden damit verbringen, um zu erfassen, was neu in den letzten Jahren hinzugekommen ist.

Was ich mir allerdings - wie viele andere auch hier in diesem Forum wünsche - ist, dass Bugs schneller (bzw. überhaupt) beseitigt werden.

[jensw_2000]

Das stimmt. Es gibt keine VCL und nur eine sehr schlanke RTL (vergleichbar mit der Foundation bei iOS).
Ergo muss man all seinen Code, der auf der VLC oder der riesigen Delphi RTL basiert anpassen.
Wir habe das alle (ansatzweise) auch schon innerhalb von Delphi hinter uns, weil RTL und VCL auf Grund der von Firemonkey, iOS und Android komplett umgemodelt wurden. Bei Oxygene muss man halt die GUI neu machen, da es keine VCL mehr gibt. Das ist analog zu der Umstellung VCL zu FMX, richtig? Nur dass man anstatt FMX eben WinForms, Silverlight oder WPF benutzt und die RTL Dinge aus den .Net Namespaces holt, bzw. aus den IOS- oder Android SDKs bzw. Sugar.
Da ist es sehr hilfreich, wenn man seine Projekte zuvor in Delphi so aufgebaut hatte, dass UI und Implementation weitgehend voneinander getrennt waren. So ist es auch bei der VCL-FMX Migration.
Für den verbleibenden Delphi Code hat Oxygene dann zwei grundlegende Sachen zu bieten. Zum Einen gibt es den Oxydizer (Delphi Code in die Zwischenablage kopieren und in Oxygene als Oxygene Code wieder einfügen.). Solche Oxydizer gibt es für Java, C#, Delphi und (aktuell noch Beta) ObjectiveC. Zum Anderen hat Oxygene einige Kompatibilitätsoptionen, die dafür sorgen, dass der Kompiler "klassische" Delphi Syntax eher "gerade rückt".
Beide Migrationshilfen machen natürlich keinen 1:1 kompilierbaren Code. Aber es hilft sehr.

Also zusammengefasst.
- UI wegwerfen (wie beim VCL/FMX Wechsel)
- eingebundene RTL Units rauswerfen und durch .Net Namespaces ersetzen (anstatt "uses DateUtils, SynObjcs" nun "using System, using System.Threading") (ähnlich wie beim RTL Umbau für FMX & Co.)
- .Net, iOS oder Java Klassen anstatt Delphi Klassen benutzen (dafür hat Delphi keinen leider keinen richtigen Ersatz)

Ich habe seit Montag einen in Delphi geschriebenen Service weitgehend migriert (reine Größe in PAS Dateien 4,8 MB, keine Lust jetzt Zeilen zu zählen). Zugegeben, so ein Service hat keine Formulare. Daher war es nur "Code schupsen". Trotzdem ist es leichter als ich erwartet hatte. Nachdem der Code wieder kompilierbar ist wird das Refactoring aber sicher einige Wochen dauern. Unter Delphi sind viele Sachen einfach codelastiger als unter .Net. Mit der Oxygene Syntax kann man das Ganze nochmal gegenüber vergleichbarem C# Code deutlich zusammenkürzen.

[Harry Stahl]

Zitat von jensw_2000:

Bei Oxygene muss man halt die GUI neu machen, da es keine VCL mehr gibt. Das ist analog zu der Umstellung VCL zu FMX, richtig?

...- UI wegwerfen (wie beim VCL/FMX Wechsel)

Das stimmt nur bedingt. Mit dem MIDA-Converter kann man zumindest sehr gut die Programm-Oberfläche konvertieren.

Ich mache das jetzt überwiegend so, dass ich einfach in der VCL-Form alle Controls auswähle, kopiere und in eine neue Form einfüge. Dann habe ich also nur VCL-Oberfläche ohne Source-Code. Bei einzelnen "Kandidaten" (z.B. TNotebook) funktioniert die Konvertierung (noch) nicht, da ändere ich die dann schnell in Controls um, wo ich weiß, dass es funktioniert (in diesem Fall also ein TPageControl). Dann lasse ich dort den MIDA-Converter drüber laufen und habe ratz fatz meine Oberfläche unter FMX wie unter der VCL. HIer könnt Ihr Euch das mal in meinem Video-Blog ansehen (Tipp: Vollbild und 720 DPI).

Dann kann ich Schritt für Schritt wieder die einzelnen Ereignisroutinen "befüllen", wobei es sich dort anbietet, UI und Code mehr zu trennen, falls man es eh nicht schon getan hat. Das schöne daran ist, dass man von Anfang an ein lauffähiges Programm hat und es schrittweise vervollständigen kann.

Da man in umfangreicheren Projekten ja durchaus 100 Formulare oder deutlich mehr hat, sehe ich da die größere Arbeit (und hier nimmt einem der MIDA-Converter wirklich viel Arbeit ab), als den Source-Code zu portieren. Delphi- und FMX-Funktionen sind eh schon in vielen Bereichen gleich (insbesondere der nicht visuelle Bereich), so dass der meiste Code, der unter Windows VCL/RTL funktionierte, ohne viel Änderungen auch unter Windows FMX/RTL funktioniert (also z.B. Streams, Stringlisten, eigene Klassen, usw). Nebenbei funktioniert das Meiste sogar auch schon so unter MAC OS X, ohne dass IFDEFS zwischen Windows und MAC OS X für unterschiedlichen Source-Code sorgen müssten.

Außerdem kann man das eine oder andere unter FMX auch mit deutlich weniger Zeilen Source-Code erreichen. In meinem VCL-PixPower-Programm brauche ich zur Anzeige (Owner-Draw) von Grafiken unterschiedlichen Formats aus einem Verzeichnis in einer Listbox ("Dialiste") ca. 200 Zeilen Sourcecode. Daneben kommen noch mehrere 100 Zeilen, um die Dateien einzulesen, daraus Thumbnail-Dateien zu machen und für den Zugriff bereit zu halten.

In FMX brauche ich für ALLES das (also einlesen und Anzeige) nur ca. 80 Zeilen!!! Und das ist ein Crosscompile-Lösung, die ohne ein einziges IFDEF sowohl unter Windows als auch unter MAC OS X funktioniert.

[michaelthuma]

Das ist eine Diskussion um neue Projekte. Es macht weder Sinn, wenn der alte Gaul lahmt, gleich den Gnadenschuss zu verpassen noch ihn zu Tode zu reiten.

Die IT Welt lebt nicht von Utilities allein ... in dem Sinne ist die Entscheidung sehr individuell.

Aber kein Mensch wird hergehen und Mio. Lines of Code außer wenn Gefahr im Verzug ist portieren. Ansonsten schade um die Zeit.

Zitat von Harry Stahl:

Wenn man nur wenige (kleine) Projekte hat, dann kann man vielleicht an einen Umstieg denken und seine Projekte noch mal neu aufsetzen.

Wenn man aber umfangreiche und langjährige Projekte hat ...