Ausgehend von diesem Blogpost muss an sich doch glatt überlegen, weshalb man Emba noch die Treue halten soll. RemObjects ist so viel volatiler und besser in eigentlich allem, was sie anpacken. Der Preis ist -unterm Strich- auch nicht viel höher als eine brauchbare Delphi-Version aber dafür bekommt man doch viel viel mehr (von einer sehr stabilen IDE mal ganz abgesehen).

Ich habe bisher die Delphi-Welt (auch rückblickend mich selbst) belächelt, weil sie Listen noch in Steinzeitmanier in Schleifen durchlaufen, obwohl LINQ einem 99% dieser Arbeit abnehmen kann. Nun baut RemObjects das einfach selbst und bietet es -soweit ich das verstanden habe- plattformübergreifend an. Ach, und wer den Delphi-Dialekt ablehnt, der kann trotzdem zu RemObjects, weil die nun auch ihr C# auf den Markt werfen. Respekt Leute, weiter so.

Wenn sie jetzt noch ein natives Compilerbackend für Windows anbieten würden, wäre das auch wirklich interessant für mich.

So hätte ich zwar eine schöne Sprache und auch viele Möglichkeiten, kann z.B. sogar Java-Bytecode für Android erzeugen, aber ohne .NET geht es trotzdem unter Windows nicht. Solange sich das nicht ändert, wird zumindest unsere Hauptanwendung sicher nie mit Oxygene geschrieben werden.
Auch wenn wir einzelne DLLs auch schon mit Prism umgesetzt hatten, aber das war keine schöne Erfahrung. Das Deployment enthält deutlich mehr Ballast und ohne Setup geht auf den Zielrechnern gar nichts. Ein No-Go in manchen Bereichen.

Auf lange Sicht wird Oxygene unsere Delphi-Ablösung.

Pascal, sicher. ("In der Tat.")
Aber Delphi? Delphi ist für mich immer ein Synonym für das Embarcadero-Produkt sowie das Pascal-Derivat (analog Oxygene).

Oder verstehe ich schon das falsch?

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

Zitat von Der schöne Günther:

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

Schreibfaulheit, wie bei Generics. Und damit man sich abhängig macht und nicht mehr weiß, was im Hintergrund tatsächlich passiert.

Zitat von Union:

Zitat von Der schöne Günther:

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

Schreibfaulheit, wie bei Generics. Und damit man sich abhängig macht und nicht mehr weiß, was im Hintergrund tatsächlich passiert.

Eher, damit man seine Zeit nicht mit diesem Schleifenmumpitz verplempert. Ich habe wirklich Besseres zu tun, als irgendeinen Filter, Suche, Umsortierung, Umformung etc. schon wieder als For-Schleife zu implementieren. Mir reichen schon die ganzen IF-Schleifen
Heute schreibt man ja auch kein Assembler mehr, verwendet die Win-API, diverse Frameworks etc. Wieso nicht einfach mal ein 'Listen-Framework'?

Im Ernst: Wer einmal mit Linq gearbeitet hat, wird es einfach nie wieder missen wollen.

Zitat von jaenicke:

...aber ohne .NET geht es trotzdem unter Windows nicht. Solange sich das nicht ändert, wird zumindest unsere Hauptanwendung sicher nie mit Oxygene geschrieben werden.
Auch wenn wir einzelne DLLs auch schon mit Prism umgesetzt hatten, aber das war keine schöne Erfahrung

Ich verstehe die Problematik zwischen Win32 und .NET DLL, aber wieso keine reine .NET-Anwendung?

Diskussionen über Sprachfeatures sind zumeist ideologisch motiviert. Indoktrination und MS Fanboyism gehört zusammen. Das ändert mal nichts an der Nützlichkeit von LINQ. .net kann sich nicht auf viel Ruhm stützen. LINQ für ERP beim Zugriff auf mystische Welten ist schon gut. Mich stört die Integration in die Sprache, genauso wie die Generics.


Man bekommt mit WPF und Teilen von .net für Komplexe GUIs selbst über mehrere Forms ein relativ konsistentes verhalten auf schmaler Codebasis hin. Auf der anderen Seiten sind viele Konstrukte eher dem Manko - alles ist ein Objekt geschuldet. Es scheint nach außen so.

Für jeden Windows Programmier ist .net eine Entgegenkommen auf bekanntem Terrain. Delphi Pascal solange man in der eigenen Welt bleibt ist es friktionsfrei. Remobjects hat den Vorteil der Zugang zur Problemlösung ist straight.

Die Probleme die Remobjects löst sind ganz andere. In dem Sinne kann RO nicht die Nachfolge antreten. Auf einer 400m Laufbahn sind die schon eher beim Überrunden. Die laufen dann zwar wenn der Schlusspfiff kommt möglw. knapp vor den anderen ins Ziel, aber die anderen hätten noch eine Runde. Ob das subjektiv betrachtet so segensreich ist, ich als Hobbyist lege eher Wert auf Gemütlichkeit. Man kann den Fortschritt nicht einholen, aber er holt einen ein. Das ist das Paradox und deswegen ist eine Technologie nicht zu wechseln nie falsch.

Wenn in der Welt zum selben Problem viel Lösungen existieren wird über die Einengung des Geistes - das ist bei Frameworks schwingt eine Denke mit - gearbeitet. .net Progammierer tragen ab dem 2ten Jahr ein Holzfällerhemd Mir wäre dann der eher puristischere Zugang lieber. Die BASH ist eh schon genug an sich. Man bekommt mit den RO Features ganz nette Vorschläge den Code zu verbessern. So XCode like und eigentlich mehr. Das ist recht nützlich.

Zitat von Union:

Zitat von Der schöne Günther:

(PS: Warum grade immer LINQ als Heilsbotschaft von .net?)

Schreibfaulheit, wie bei Generics. Und damit man sich abhängig macht und nicht mehr weiß, was im Hintergrund tatsächlich passiert.

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.

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.

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

.NET IST die Windows-Plattform. Noch nativer als einheitlich über alle Windows-Varianten - inklusive RT - (wo steht da nochmal das Windows-"Native" Delphi?) geht es nicht.