Quo vadis Embarcadero?

[jensw_2000]

Zitat:

Zitat von franktron (Beitrag 1248987)

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". :wink:

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. :wink:

[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. :-D

[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.

[michaelthuma]

Oxygene funktioniert seit Jahren.

Zitat:

Zitat von franktron (Beitrag 1248987)

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.

[cookie22]

Zitat:

Zitat von mquadrat (Beitrag 1248704)

Die Geschäftspolitik
Kurze Release-Zyklen sind inzwischen Industriestandard. Damit hat man immer ein Problem mit den Major-Versionen. Die gibt es bei den kurzen Zyklen ja eigentlich nicht mehr, aber man braucht sie um das Geschäftsmodell aufrecht zu erhalten. Ein Major pro Jahr passt. Für Firmen, die mit Delphi ihr Geld verdienen ist der Preis auch in Ordnung. Das hin und her bei Mobile war natürlich suboptimal.

Wo hast du das denn her? Du Vergleichst hier Äpfel mit Birnen. Delphi ist eine Entwicklungsumgebung und kein Browser. Den Standard stellt hier ja wohl M$ auf und guck dir mal deren Zyklen an. Bei Apple ist es egal, weil man dort nicht für die Tools zahlen muss. Leuten buggy Sortware zu verkaufen und für Bugfixes nochmal Geld zu verlangen ist schlichtweg eine Frechheit.

Zitat:

Zitat von mquadrat (Beitrag 1248704)

Die Preise
Wie schon geschrieben sind die Preise für mich kein Problem. Auch nicht für die Community. Schauen wir uns doch mal an wie OpenSource-Projekte/Komponenten aufgestellt sind. Alles was sich länger am Markt hält hat große Supporter. HHVM kommt von Facebook, Bootstrap von Twitter, Angular.JS von Google, Firefox von der Foundation. Projekte sind inzwischen so komplex, dass gute OS-Komponenten eigentlich nicht mehr von Privatpersonen als Hobby entwickelt werden können und werden.

Die Preise sind kein Problem für die Community? Arbeitest du für Emba? Welche Community überhaupt? Die paar Leute die hier noch aktiv sind? Delphi hatte mal eine riesen Community, die nun langsam aber sicher stribt, weil die Leute immer älter werden und Emba der Nachwuchs komplett ignoriert. Geh mal in eine beliebige Uni und frag dort nach Delphi. Als Antwort wirst du Dinger zu hören bekommen, wie: "Damit hab ich mal was in der Schule gemacht. Gibts das überhaupt noch?"

Zitat:

Zitat von mquadrat (Beitrag 1248704)

Delphi ist für Desktop-Windows immer noch erste Wahl. Und wenn mit dem nächsten Update die Grenze von Modern-UI und Desktop weiter verwischt wird, dann kann man sich auch mit Metropolis blicken lassen ohne ausgelacht zu werden. Der X-Plattform-Ansatz ist in der Strategie richtig, der Markt mit der größten Bewegung ist Mobile also ist auch das richtig gewählt. Einzig der Coolness-Faktor scheint Emba so komplett zu fehlen und das macht es schwierig bei den Mobile-Entwicklern zu punkten. Reine Windows-Entwicklung mit Fat-Clients ist einfach kein Zukunftskonzept mehr.

Es gibt wohl kaum noch etwas, dass mit C# nicht genauso schnell oder sogar schneller ginge als mit Delphi.

Es ist wohl mehr die Lieblosigkeit mit der FMX umgesetzt wurde, als dort irgendwo der Coolness-Faktor fehlt. Warum sollte man viel Geld für ein schlecht umgesetztes System zahlen und sich herum ärgern, wenn man kostelos nativ entwickeln kann.

[Harry Stahl]

Zitat:

Zitat von jensw_2000 (Beitrag 1249036)

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.

[Phoenix]

Zitat:

Zitat von jensw_2000 (Beitrag 1249015)

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:

Zitat von jensw_2000 (Beitrag 1249067)

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.

[mquadrat]

Zitat:

Zitat von cookie22 (Beitrag 1249040)

Wo hast du das denn her? Du Vergleichst hier Äpfel mit Birnen. Delphi ist eine Entwicklungsumgebung und kein Browser. Den Standard stellt hier ja wohl M$ auf und guck dir mal deren Zyklen an. Bei Apple ist es egal, weil man dort nicht für die Tools zahlen muss. Leuten buggy Sortware zu verkaufen und für Bugfixes nochmal Geld zu verlangen ist schlichtweg eine Frechheit.

Auch bei MS werden die Zyklen kürzer und kürzer. Jedes Jahr eine Major und die Minors kommen in immer kürzeren Zyklen.

Zitat:

Die Preise sind kein Problem für die Community? Arbeitest du für Emba? Welche Community überhaupt? Die paar Leute die hier noch aktiv sind? Delphi hatte mal eine riesen Community, die nun langsam aber sicher stribt, weil die Leute immer älter werden und Emba der Nachwuchs komplett ignoriert. Geh mal in eine beliebige Uni und frag dort nach Delphi. Als Antwort wirst du Dinger zu hören bekommen, wie: "Damit hab ich mal was in der Schule gemacht. Gibts das überhaupt noch?"

Das an den Unis kein Delphi mehr genutzt wird, hat aber weniger mim Preis zu tun. Da wird auch kaum .NET verwendet, obwohl die Express nix kosten. Bei der JVM kannst du halt an allem rumdrehen.

[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:

Zitat von Harry Stahl (Beitrag 1249034)

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 ...

[cookie22]

Zitat:

Zitat von mquadrat (Beitrag 1249091)

Auch bei MS werden die Zyklen kürzer und kürzer. Jedes Jahr eine Major und die Minors kommen in immer kürzeren Zyklen.

Nein, werden Sie nicht. 2013 war eine Ausnahme und hing eng mit Windows 8 Änderungen zusammen, die nächste Version ist VS 2015.

Ganz davon ab, zahlt man bei M$ nicht für Updates. Dazu kommt wie unsäglich die Updates bei Delphi ausgeliefert werden. Da muss man eventuell neu installieren damit alles wieder läuft. Bei anderen IDEs drück ich auf "Update Now" und das Ding wird in 5 Minuten gepatcht und alles läuft.

Zitat:

Zitat von mquadrat (Beitrag 1249091)

Das an den Unis kein Delphi mehr genutzt wird, hat aber weniger mim Preis zu tun. Da wird auch kaum .NET verwendet, obwohl die Express nix kosten. Bei der JVM kannst du halt an allem rumdrehen.

Ich habe nie behauptet, dass an den Unis .Net verwendet wird. Ich sagte:"Frag mal nach Delphi". Das kennt dort keine Sau mehr. Mit .Net haben aber 2/3 aller Studenten schon mal in ihrer Freizeit gearbeitet. Und warum? Weil M$ halt nicht auf den Nachwuchs kackt. Ich sag nur Dreamspark. Von sowas kann Emba nur träumen. Wenn der letzte Delphi-Opa gestorben ist, werden immer noch Kinder und Jugentliche .Net verwenden. Eben, weil es nichts kostet. Mittlerweile ist C# genauso produktiv wie Delphi, ja in einigen Bereichen entwicket man mit C# sogar viel schneller.

Schau dir doch nur mal die default FMX Skins an. Die Programme sehen unter Windows und MacOS X einfach nur gruselig aus. Emba hat es seit 5 Versionen nicht hingebracht, Skins anzubieten die annäherd nativ aussehen. So etwas will doch keiner freiwillig benutzen.

Nur mal so eine Frage am Rande. Gibt es eigentlich nur ein einziges wirklich erfolgreiches Programm, dass mit FMX entwickelt wurde?

Ich kann hier nur immer wieder meinen Respekt unseren beiden Stahlis aussprechen, die sich den Käse seit Jahren antun und immer noch nicht die Geduld verloren haben.

[Stevie]

Zitat:

Zitat von cookie22 (Beitrag 1249140)

Zitat:

Zitat von mquadrat (Beitrag 1249091)

Auch bei MS werden die Zyklen kürzer und kürzer. Jedes Jahr eine Major und die Minors kommen in immer kürzeren Zyklen.

Nein, werden Sie nicht. 2013 war eine Ausnahme und hing eng mit Windows 8 Änderungen zusammen, die nächste Version ist VS 2015.

Da hat wohl jemand die Build 2013 verpasst, wo Steve Ballmer sagte: "We are moving to an absolutely rapid release cycle."

[jensw_2000]

Zitat:

Zitat von Stevie (Beitrag 1249141)

Zitat:

Zitat von cookie22 (Beitrag 1249140)

Zitat:

Zitat von mquadrat (Beitrag 1249091)

Auch bei MS werden die Zyklen kürzer und kürzer. Jedes Jahr eine Major und die Minors kommen in immer kürzeren Zyklen.

Nein, werden Sie nicht. 2013 war eine Ausnahme und hing eng mit Windows 8 Änderungen zusammen, die nächste Version ist VS 2015.

Da hat wohl jemand die Build 2013 verpasst, wo Steve Ballmer sagte: "We are moving to an absolutely rapid release cycle."

Der hat auch gesagt "In 2 Jahren werden alle Computer Touch basiert sein. Alle Displays ohne Touch werden sich abfühlen wie ein 'broken device'". Und... "Metro ist großartig. Die Leute werden es lieben".

[stahli]

Schnelle Releases finde ich unsinnig. Vor allem, wenn diese an Stelle von Fehlerbeseitigungen rausgebracht werden.

@cookie22
Ich habe mit FMX aufgegeben und teste gerade mal einen etwas anderen Ansatz.
Wenn das nix wird und Emba sich nicht grundlegend ändert bin ich wohl weg von Delphi.
Vermissen würde ich die alten Zeiten :thumb: und die DP! :love:

[Stevie]

Zitat:

Zitat von jensw_2000 (Beitrag 1249142)

Zitat:

Zitat von Stevie (Beitrag 1249141)

wo Steve Ballmer sagte: "We are moving to an absolutely rapid release cycle."

Der hat auch gesagt "In 2 Jahren werden alle Computer Touch basiert sein. Alle Displays ohne Touch werden sich abfühlen wie ein 'broken device'". Und... "Metro ist großartig. Die Leute werden es lieben".

Man sollte nicht seine Versuche, die Zukunft vorrauszusagen, mit einer Aussage über die Ausrichtung der eigenen Firma verwechseln.
MS war schon immer gut darin, alle anderen hinterher hechten zu lassen, weil sie ihnen so oft neue Technologien vorgeworfen haben, und sie ebenso schnell wieder als veraltet fallen zu lassen.

Wenn man außerdem auf die Product Roadmap schaut, wird man sehen, dass schon bald Update 2 für VS2013 kommen soll - und das ca ein halbes Jahr nach Release. Ich nenn das ziemlich "rapid".

P.S. Ich seh gerade, dass es die CTP davon ja schon ne Weile gibt.

[cookie22]

Zitat:

Zitat von Stevie (Beitrag 1249144)

Wenn man außerdem auf die Product Roadmap schaut, wird man sehen, dass schon bald Update 2 für VS2013 kommen soll - und das ca ein halbes Jahr nach Release. Ich nenn das ziemlich "rapid".

P.S. Ich seh gerade, dass es die CTP davon ja schon ne Weile gibt.

Ich seh da aber keine 2014er Version oder bin ich blind?

[Bernhard Geyer]

Zitat:

Zitat von cookie22 (Beitrag 1249175)

Zitat:

Zitat von Stevie (Beitrag 1249144)

Wenn man außerdem auf die Product Roadmap schaut, wird man sehen, dass schon bald Update 2 für VS2013 kommen soll - und das ca ein halbes Jahr nach Release. Ich nenn das ziemlich "rapid".

P.S. Ich seh gerade, dass es die CTP davon ja schon ne Weile gibt.

Ich seh da aber keine 2014er Version oder bin ich blind?

Die CTP bezieht sich auf das Update 2

[Phoenix]

Microsoft ist mit dem Visual Studio inzwischen bei einem Jährlichen Release-Zyklus angekommen.
Damit aber die Entwickler nicht ein Jahr auf Support und neue Updates warten müssen, kommen in der Zeit zwei bis drei größere Servicepacks raus, die aber auch gerne neue Features mitbringen. Im übrigen gibts immernoch Bugfixes für alte VS-Versionen..

[vagtler]

Und mal ganz ehrlich: das Handling der Updates ist bei Microsoft auch wesentlich problemloser. Die verschiedenen Versionen beeinflussen sich gegenseitig nicht und Package-Abhängigkeiten werden mit NuGet aufgelöst - auch von vielen kommerziellen Packages. Für Delphi ist mir nur http://owlyci.com/ bekannt, was immerhin ein Anfang ist...

[michaelthuma]

Es kommt jedes Jahr eines 'neues' Studio so in etwa. War mal eine Aussage. Ob man viel davon halten kann ...

Eine Versionsnummer ist an sich egal.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1249176)

Zitat:

Zitat von cookie22 (Beitrag 1249175)

Zitat:

Zitat von Stevie (Beitrag 1249144)

Wenn man außerdem auf die Product Roadmap schaut, wird man sehen, dass schon bald Update 2 für VS2013 kommen soll - und das ca ein halbes Jahr nach Release. Ich nenn das ziemlich "rapid".

P.S. Ich seh gerade, dass es die CTP davon ja schon ne Weile gibt.

Ich seh da aber keine 2014er Version oder bin ich blind?

Die CTP bezieht sich auf das Update 2

[hanspeter]

Bei den zur Zeit erheblichen Umstellungen in der RTL habe ich ein bischen die Befürchtung, dass die VCL als Collateralschaden auf der Strecke bleibt.
Der Umstellungsaufwand von VCL auf Firemonkey dürfte ähnlich dem Aufwand einer Umstellung auf Oxygene liegen?
Ich habe mir jetzt mal die Demo-Version von Oxygene installiert.
Hat wer einen Tip, wo ich ein Demoprojekt für Oxygene (Windows) finde und herunterladen kann?
Mit einem funktionierenden Quelltext kommt man schneller vorwärts als wenn man ohne alles bei null beginnt.

Gruß
Peter

[sh17]

Könnte man nicht mal alle deutschen Nutzer von Oxygene irgendwie sammeln? G+ Gruppe oder was weiss ich ( bitte kein FB) Ich würde auch eine aufmachen, wenn genug Interesse haben.
Ich brauch irgendwie Feedback / Erfahrungsaustausch.

[michaelthuma]

Im Remobjects\Oxygene Verzeichnis sind links auf die Demos zu finden. Die liegen im

C:\Users\Public\Documents\RemObjects Samples\Oxygene for .NET

bei mir.

Links zum Wiki.
http://www.elementswiki.com/en/HowTos

F12 Goto Implementation

Zitat:

Zitat von hanspeter (Beitrag 1249265)

Bei den zur Zeit erheblichen Umstellungen in der RTL habe ich ein bischen die Befürchtung, dass die VCL als Collateralschaden auf der Strecke bleibt.
Der Umstellungsaufwand von VCL auf Firemonkey dürfte ähnlich dem Aufwand einer Umstellung auf Oxygene liegen?
Ich habe mir jetzt mal die Demo-Version von Oxygene installiert.
Hat wer einen Tip, wo ich ein Demoprojekt für Oxygene (Windows) finde und herunterladen kann?
Mit einem funktionierenden Quelltext kommt man schneller vorwärts als wenn man ohne alles bei null beginnt.

Gruß
Peter

[divBy0]

Zitat:

Zitat von sh17 (Beitrag 1249269)

Könnte man nicht mal alle deutschen Nutzer von Oxygene irgendwie sammeln? G+ Gruppe oder was weiss ich ( bitte kein FB) Ich würde auch eine aufmachen, wenn genug Interesse haben.
Ich brauch irgendwie Feedback / Erfahrungsaustausch.

Geht mir ähnlich. Die DP würde sich dazu eigentlich anbieten.

[michaelthuma]

Das mit VCL tut weh. So schwarz sehe ich die Lage noch nicht.

Von der Güte der .net GUI Ideen bin ich persönlich nicht überzeugt. Beim WPF ist Einarbeitungszeit angesagt und wenn man angekommen ist lacht das Gipfelkreuz . Sobald dir fad wird ist der Zenith erreicht - dahinter wirds blutig - nachher geht es ans Eingemachte. Dann schreibt man schell viel und genauso unter Winforms. Aber in beiden Fällen weniger in Winforms wichtig im Verfeld genauest die Unwegsamkeiten ausloten - ein Designfehler respektive Entscheidung kann sich bitter rächen nach Monaten. WPF kleine anfangen und schrittweise ausbauen. Damals haben selbst wir, die wir nicht so feige an sich sind extra 2 Studenten 3 Monate angesetzt mal ins WPF hineinzugraben. Das war unter Vista und .net 3.x respektive 3.5 - nicht mehr ganz vergleichbar. Ist heute nicht mehr so im Tücke im Detail versehen.

Aber auf der Commandline oder serverseitig ist .net mittlerweile durchaus brauchbar. In dem Umfeld ist .net wirklich massiv von Vorteil. Aber das selbe kann man im SharpDevelop genauso machen. Es ist überhaupt sehr viel aus .de nützlich, wenn es um .net geht.

Zitat:

Zitat von hanspeter (Beitrag 1249265)

Bei den zur Zeit erheblichen Umstellungen in der RTL habe ich ein bischen die Befürchtung, dass die VCL als Collateralschaden auf der Strecke bleibt.
Der Umstellungsaufwand von VCL auf Firemonkey dürfte ähnlich dem Aufwand einer Umstellung auf Oxygene liegen?

[jensw_2000]

Zitat:

Zitat von divBy0 (Beitrag 1249271)

Zitat:

Zitat von sh17 (Beitrag 1249269)

Könnte man nicht mal alle deutschen Nutzer von Oxygene irgendwie sammeln? G+ Gruppe oder was weiss ich ( bitte kein FB) Ich würde auch eine aufmachen, wenn genug Interesse haben.
Ich brauch irgendwie Feedback / Erfahrungsaustausch.

Geht mir ähnlich. Die DP würde sich dazu eigentlich anbieten.

+1
Lieber in der DP als anderswo.
Für Hepler Klassen, Extensions und andere Quellcodes Github oder BitBucket. Ich bin echt dafür, dass bei solchen allgemeinen "Helferlein" nicht jeder das Rad alleine neu erfinden muss. Vielleicht sollten wir da aber nochmal die RemObjects Jungs zu befragen. Marc Hoffmann hat schon für andere Projekte passende Repositories bereitgestellt. Eventuell kann man sich da mit dem Rest der Welt zusammenschließen.

[jensw_2000]

Zitat:

Zitat von hanspeter (Beitrag 1249265)

Bei den zur Zeit erheblichen Umstellungen in der RTL habe ich ein bischen die Befürchtung, dass die VCL als Collateralschaden auf der Strecke bleibt.
Der Umstellungsaufwand von VCL auf Firemonkey dürfte ähnlich dem Aufwand einer Umstellung auf Oxygene liegen?
Ich habe mir jetzt mal die Demo-Version von Oxygene installiert.
Hat wer einen Tip, wo ich ein Demoprojekt für Oxygene (Windows) finde und herunterladen kann?
Mit einem funktionierenden Quelltext kommt man schneller vorwärts als wenn man ohne alles bei null beginnt.

Gruß
Peter

Wenn Du in dem Welcome Screen auf Oxygene klickst, dann findest Du dort zu jeder unterstützten Plattform weitere kleine Beispiele in diversen Kategorien.
Falls Du das Fenster bereits mit "Beim Start nie wieder anzeigen" ins Nirvana verbannt hast, dann kannst Du im Visual Studio über "Hilfe > Everwood Welcome Screen" noch darauf zugreifen.

[michaelthuma]

Oh Danke. Das ist mir bis heute entgangen ... :shock:

Zitat:

Zitat von jensw_2000 (Beitrag 1249274)

Wenn Du in dem Welcome Screen auf Oxygene klickst, dann findest Du dort zu jeder unterstützten Plattform weitere kleine Beispiele in diversen Kategorien.
Falls Du das Fenster bereits mit "Beim Start nie wieder anzeigen" ins Nirvana verbannt hast, dann kannst Du im Visual Studio über "Hilfe > Everwood Welcome Screen" noch darauf zugreifen.

[hanspeter]

Zitat:

Zitat von sh17 (Beitrag 1249269)

Könnte man nicht mal alle deutschen Nutzer von Oxygene irgendwie sammeln? G+ Gruppe oder was weiss ich ( bitte kein FB) Ich würde auch eine aufmachen, wenn genug Interesse haben.
Ich brauch irgendwie Feedback / Erfahrungsaustausch.

Im Delphi-Forum, hier C# Unterforum ist ein Forum für Prism vorhanden.
Da ist der letzte Eintrag aber mehr als 2 Jahre alt.

[jensw_2000]

Die DP hat Prism auch in den Unterforen ".Net Sprachen" und ".Net Framework" mit drin.
Die Foren ich aber heutzutage wirklich nur für den .Net Part von Oxygene anwendbar. Oxygene ist heute sooo viel mehr. "Prism" war auch nur ein Branding Produkt, das EMBT wegen der "Delphi .Net Schmach" eingekauft und später wieder fallen gelassen hat, wie viele andere RAD Studio Komponenten zuvor auch. Prism gibt es also nicht mehr. Daher hält sich die Anzahl der Posts vermutlich auch in Grenzen.

Hier in der DP wäre Oxygene vermutlich in einem eigenen Unterforum am Besten aufgehoben. Mit Tags .Net, iOS, OSX, Java, Android, WinRT, ...). Oder einfach mit im Cross Plattform Forum untergegracht. Jedoch mit zeitgemäßen Tags: Oxygene.Net, Oxygene.iOS usw.). Aber da wird unseren DP "Vorturnern" schon das Richtige einfallen.:wink:

[sh17]

Dann wäre es schön, ein Unterforum zu bekommen.

[Daniel]

Dafür. :thumb:

[Memnarch]

Zitat:

Zitat von Codehunter (Beitrag 1248550)

[...] der für Android arbeitet mit dem NDK statt dem SDK (nur gelesen, keine eigenen Erfahrungen) [...]

Das liegt daran, dass sich das SDK nur um Java dreht und keinen nativen Code erlaubt. Für einen Compiler (oder einen Entwickler), der nativen Code erzeugen will/muss (siehe Echtzeitanwendungen wie Spiele), ist dass NDK unerlässlich. IIRC enthält nämlich nur dieses auch die entsprechenden low-level assembler und die Bibliotheken zum linken.

Grüße
Memnarch

[Buddelfish]

Was war jetzt nochmal der große Vorteil von Oxygene ggü. C#?

[mkinzler]

-basiert of Object Pascal
http://edn.embarcadero.com/article/41697

[Phoenix]

Zitat:

Zitat von Buddelfish (Beitrag 1249296)

Was war jetzt nochmal der große Vorteil von Oxygene ggü. C#?

Es hat mehr Sprachfeatures
Es kann nicht nur .NET IL-Code sondern auch Java Bytecode (Android) und nativen Mac- und iOS-Code generieren