Ist RemObjects die Zukunft von Delphi?

[Lemmy]

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

[Der schöne Günther]

Zitat von Lemmy:

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

[stahli]

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 www.RO-Praxis.net denkbar. ?

[Lemmy]

Zitat von Der schöne Günther:

Zitat von Lemmy:

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

Wie meinen?

[Phoenix]

Zitat von Lemmy:

Zitat von Der schöne Günther:

Zitat von Lemmy:

[...] mit Hydrogene ködern - ist immerhin C#. Zwar deutlich erweitert,[...]

Ich dachte, genau anders herum?

Wie meinen?

Hydrogene ist C# (für .NET) bzw. ein Subset von C# für die Cocoa/Objective-C Runtime (z.B. gehen dort keine Generics, da das die Runtime nicht kann). Das was hier erweitert wurde ist z.B. der für Cocoa benötigte Support für Multipart-Method Names.

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.

[sh17]

Zitat von stahli:

Vielleicht ist mittelfristig auch eine www.RO-Praxis.net denkbar. ?

Vielleicht schreibt mir Marc ja noch was dazu - aber ein deutsches Forum wäre in jedem Fall vorteilhaft zum Austausch.

[Phoenix]

Zitat von Furtbichler:

Ist RemObjects die Zukunft von Delphi?

Nein. Wollen sie aber auch nicht sein. Müssen sie auch nicht.

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 von Entwickler:

Vorher habe ich ein TDingsbums da drauf gezogen, mit TBummens verbunden und hatte meine Daten auf dem Form - wo ist hier mein Formdesigner?

Der Entwickler wird sozusagen gezwungen, sich mit der Zielplattform intensiv auseinanderzusetzen, und sich im Umfeld der Zielplattform ggf. mit dort verfügbaren Libraries auseinanderzusetzen. Der Entwickler lernt so mehr über das Umfeld und kann es mittel- bis Langfristig daher auch intensiver ausnutzen.

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.

[jaenicke]

Zitat von Phoenix:

Diese Möglichkeit haben von der Plattform weg abstrahierte Entwickler niemals in diesem Umfang

Das gilt aber auch für .NET auf der Windows-Plattform. Und das ist es genau was mich an der Stelle stört.

[Lemmy]

Zitat von Phoenix:

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.

ähm.. Oxygene wird ja z.B. mit "Futures" beworben - ich bin davon ausgegangen dass solche Sprachfeatures auch in c#-Hydrogene dabei sind... auf das bezog sich das erweitert....

[Phoenix]

Zitat von Lemmy:

ähm.. Oxygene wird ja z.B. mit "Futures" beworben - ich bin davon ausgegangen dass solche Sprachfeatures auch in c#-Hydrogene dabei sind... auf das bezog sich das erweitert....

Nein, sind sie nicht. C# wurde so nach am ECMA-Standard belassen wie möglich.