![]() |
AW: Ist RemObjects die Zukunft von Delphi?
Hi,
ich persönlich finde Oxygene bzw Hydrogene sehr interessant. Mit Prism/Oxygene bin ich aber nicht warm geworden - die Sprache gleicht zu sehr Delphi, das Backgroud ist aber ein komplett anderes. Der Umgang mit c# ist mir da wesentlich leichter gefallen, obwohl ich an c angelehnte Sprachen überhaupt nicht gerne mag. Vor allem plattformübergreifend sehe ich RemObjects mit ihrem Toolset ganz klar vor Embarcadero. Leider habe ich aber Probleme damit meine Begeisterung (z.B. an Futures) an meine Kollegen weiter zu geben: die wollen nicht aus einer Nische in eine noch kleinere Nische wechseln :-) aber vielleicht kann ich die jetzt mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert, aber mir käme ein Framework sehr gelegen das die Hauptplattformen abdeckt - das wäre mit Oxygene/Hydrogene gegeben. Zumindest für mein privates Zeugs werden Alternativen zu Dephi immer interessanter - so leid es mir auch um Delphi tut.... |
AW: Ist RemObjects die Zukunft von Delphi?
Zitat:
|
AW: Ist RemObjects die Zukunft von Delphi?
Ich bin noch an einem Projekt, bei dem ich weiter bei XE3 und VCL bleibe.
Etwas neues werde ich bei Emba nicht mehr kaufen. RemObjects wirkt deutlich attraktiver und kompetenter. Mir graut etwas vor einem Wechsel, insbesondere wegen meinem schlechten Englisch. Mit .NET wollte ich mich zwar ursprünglich nicht anfreunden, aber wenn es keine gute Alternative gäbe...!? Vielleicht ist mittelfristig auch eine ![]() |
AW: Ist RemObjects die Zukunft von Delphi?
Zitat:
|
AW: Ist RemObjects die Zukunft von Delphi?
Zitat:
Ansonsten ist das "nur" ein Compiler mit 3 Backends (.NET, Java Bytecode, Obj-C) für die Sprache C# - da ist nichts "deutlich" erweitert, sondern nur minimal wo unbedingt nötig. |
AW: Ist RemObjects die Zukunft von Delphi?
Zitat:
|
AW: Ist RemObjects die Zukunft von Delphi?
Zitat:
RemObjects bietet für Pascal (und jetzt C#) sprechende Entwickler einen sehr individuellen Zugang zu neuen Plattformen, nämlich indem sie die Zielplattformen ohne Abstraktionen 1:1 an den Entwickler durchreichen. Der Entwickler wird bewusst auf die Problematik Plattform <--> Code reduziert. Es gibt - auch wieder bewusst - keine zusätzlichen Libraries wie die RTL oder VCL die einen von der nativen Zielplattform weg bewegen würden. Man arbeitet mit dem Bare Metal. Man muss viel von Hand machen. Das ist ein Ansatz, der dem typischen Delphi-Entwickler (RTL, VCL, freie Komponenten, ggf. zugekaufte Komponenten die alles irgendwie für einen schon erledigen) sehr befremdlich vorkommt und ihn zum Teil etwas Hilflos dastehen lässt: Zitat:
Das ist meiner Meinung nach per se ein sehr intelligenter und lobenswerter Ansatz. Nur ist der eben nicht unbedingt mit jeder Entwicklermentalität kompatibel. Das heisst im großen Stil wird das (leider?) nicht funktionieren (auch wieder meine persönliche Meinung). Auch wenn es wünschenswert wäre. Nichts desto trotz ist das ein Ansatz, der denjenigen denen er zusagt, viel Erfahrung bringen kann und es ihnen ermöglicht, wirklich das letzte Quäntchen an UX, Performance und Plattformüberlegenheit aus seiner App zu quetschen. Diese Möglichkeit haben von der Plattform weg abstrahierte Entwickler niemals in diesem Umfang, und dieser Vorteil wird die, die sich darauf einlassen, zu einer sehr elitären Truppe machen. |
AW: Ist RemObjects die Zukunft von Delphi?
Zitat:
|
AW: Ist RemObjects die Zukunft von Delphi?
Zitat:
|
AW: Ist RemObjects die Zukunft von Delphi?
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz