Quo vadis Embarcadero?

[jensw_2000]

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.

Da Du schon direkt danach fragst, antworte ich auch hier mal direkt drauf.

Ja, nur Gute.
Für die Entwicklung von iOS, Android und Windows Phone 8 & Co ist es super.
Ich habe damit kommerzielle Sachen für iOS umgesetzt und arbeite gelegentlich an meinen beiden Apps für den Store. Das geht traumhaft gut. Man muss aber selbst bereit sein, sich mit den iOS SDKs zu befassen und ObjectiveC zumindest "lesen" zu lernen. Anders geht es kaum. Bei Android Apps muss man verstehen wie die SDKs dort ticken und wie Java funktioniert. Programmieren tut man selbstverständlich mit Pascal. Man muss sich also nicht mit den ganzen ObjC Pointern und der schrägen Syntax herumschlagen. In der Java Welt kann man mit Oxygene Properties und Delegates verwenden. Oxygene ist wirklich "Not your Daddy's Pascal".

Ich arbeite immer mit der aktuellen Oxygene Betaversion, weil RemObjects, anders als andere IDE Anbieter, sehr agil auf Userwünsche eingeht und an Features arbeitet. Mit jeder Beta kommen neue interessante Dinge dazu. Man sieht, wie das System mit jedem Freitagsbuild großartiger wird.

Für codelastige "Programmteile" in .Net ist Oxygene auf Grund der coolen Sprachfeatures auch sehr gut zu gebrauchen. Sobald Du im .Net Bereich aber mit der GUI (WinForms, WPF, ASP.Net) arbeiten willst, wirst Du vermutlich auch das eine oder andere GUI Framework benutzen wollen (z.B. DevExpress Komponenten für .Net). Dann wirst Du schnell feststellen, dass viele große Komponentenhersteller, wie DevExpress, oft nur C# und VB Beispielprojekte und Project Wizards anbieten, und dass man als Oxygene User deutlich mehr selbst coden muss.
Dies ist unter .Net jetzt kein großes Manko. Man kann sich ja einfach eine Oxygene Asselbly für die codelastige Sachen (Modules und Controller) in die Solution hängen und den "GUI Kram" in C# machen. Am Ende ist unter .Net ja intern alles "nur" IL Code.

[stahli]

So, ich habe jetzt schon mal den Emba-Newsletter abbestellt.
Zumindest darüber muss ich mich künftig nicht mehr ärgern.

Ich werde an meinem aktuellen Projekt weiter mit XE3-VCL arbeiten aber wenn es irgendwann etwas neues werden soll, dann werde ich mich wohl doch mal mit Oxygene beschäftigen. Hoffentlich findet sich - wenn es dazu kommt - jemand, der mich dann an die Hand nimmt...

[jensw_2000]

Warte mal noch ein Jährchen, dann mach ich das. Hier im Forum gibt es aber auch ganz viele echte .Net Spezis.
Mit .Net stehe ich auch noch nah am Anfang und Cross Plattform machst Du ja nicht so viel ..

Vielleicht braucht man für Oxygene in einem Jahr aber auch gar kein .Net mehr. Hier mal ein kleiner übersetzter Ausschnitt aus einem nicht näher bezeichneten Forum .

Wir haben große(größere) Pläne für Pascal (und C #), ungefähr das, was EMBT als "echte native" Entwicklung bezeichnet. Also das Kompilieren von CPU-nativem Code ohne - NET-Runtime -.
Aber wir machen das von unserer Seite mit den beiden großen Sprachen, die wir bereits haben. (Und das ist alles, was ich sagen kann, wirklich, es sei denn ich will, dass ..... mir ein Killerkommando schickt).

Also. Da geht bestimmt noch was.

[Buddelfish]

Ich hab auch die Hosen voll gehabt, als ich gewechselt bin. Aber das geht schnell vorbei (aller Anfang ist schwer). Nach ein paar Wochen will man einfach nicht mehr zurück. Gut, für Quick&Dirty-Sachen ist Delphi echt zu gebrauchen, aber auch nur, wenn Du für irgendwelche XP-Krücken entwickeln musst, die kein oder nur ein altes .NET drauf haben.

Bei VS-Express muss man übrigens nichts zahlen und bekommt trotzdem Datenbankanbindung frei haus. Ebenso bei Eclipse/Java und so ziemlich jeder anderen Programmierumgebung. Nur Emba macht daraus eine große magische Zauberei.

[Phoenix]

Zitat von jensw_2000:

Vielleicht braucht man für Oxygene in einem Jahr aber auch gar kein .Net mehr.

Naja, das kannst Du - in gewissen Grenzen - schon heute haben. Jag das Ergebnis einfach durch

Code:

mono --full-aot your.exe

.
Du musst halt alle verwendeten anderen Assemblies auch AOTen und mit deiner .exe shippen, aber das ist dann alles 'to the metal' durchkompiliert und liegt nur noch als rein nativer CPU-Code dort. Du gibts halt alle Vorteile von Plattformspezifischem JIT-compiling auf.

[jensw_2000]

Das kannte ich noch nicht, und ehrlich gesagt sehe ich bei den CPU nativen Binaries auch nur den Vorteil, dass man auf alten Systemen nicht zwangsläufig passende .Net Versionen nachinstallieren muss.
Ich hatte jedoch mit dem Gedanken gespielt, häufig genutzte Assemblies mit NGen direkt auf der Zielmaschine vorzukompilieren. Hast Du damit positive oder eher negative Erfahrungen gesammelt?

[Phoenix]

Zitat von jensw_2000:

Ich hatte jedoch mit dem Gedanken gespielt, häufig genutzte Assemblies mit NGen direkt auf der Zielmaschine vorzukompilieren. Hast Du damit positive oder eher negative Erfahrungen gesammelt?

Das macht z.B. Paint.NET bei der Installation. NGen bringt Dir primär was, wenn Du die Startup-Time Deiner Anwendung reduzieren willst (es wird lediglich das JITen vorweggenommen). Das Ergebnis von NGen sollte auf dem gleichen System binär identisch mit geJITtetem Code sein.

Wenn Du viel IL hast und Du davon ausgehst das das eher auf nicht ganz so schnellen Rechnern ausgeführt werden soll, dann kann Dir NGEN vielleicht wirklich was bringen - ich würde das aber vorab mal austesten. Kann auch sein dass das in Deinem Fall vielleicht auch nur einen vernachlässigbaren Vorteil bringt.