Ist RemObjects die Zukunft von Delphi?

[Furtbichler]

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.

[jaenicke]

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.

[sh17]

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

[Der schöne Günther]

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?)

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

[Furtbichler]

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?

[sh17]

Zitat von Furtbichler:

Mir reichen schon die ganzen IF-Schleifen.

[sh17]

Bei .NET ist mir noch nicht ganz klar, worauf setzt man vernünftiger Weise? WPF (tot) WinRT (hmm) GTK# (+Linux), ...

[Furtbichler]

Zitat von sh17:

Bei .NET ist mir noch nicht ganz klar, worauf setzt man vernünftiger Weise? WPF (tot) WinRT (hmm) GTK# (+Linux), ...

WinForms fehlt in deiner Auflistung. Bloß weil WPF (und WinForms?) nicht weiterentwickelt wird, ist das doch nicht tot. Schau mal bei Microsoft nach, was die darüber schreiben. WinForms, WPF sind einfache Techniken, um Windows-Applikationen mit 'ner GUI zu schreiben. Wenn Du Metro Apps (meinst Du das mit WinRT) schreiben willst, bitte sehr.

Allerdings ist es schon so, das man für WPF etwas vom MVP/MVVM-Pattern verstehen muss, und für Metro/WinRT bestimmte Patterns und Techniken einsetzen muss. Wenn man den Sinn dahinter nicht versteht, dann bleibt man am Besten bei Delphi, Visual FoxPro und ähnlichen.

Ein guter Softwareentwickler macht sich ja mittlerweile doch unabhängig vom Frontend und schreibt seine Anwendungen so, das sie ohne großen Aufwand an andere GUI angepasst werden können. Insofern ist das doch ziemlich egal, was gerade in Mode ist.

[sh17]

MVP/MVVM-Pattern - vollkommen richtig - und WinRT-nein möchte ich eigentlich nicht nutzen.

Wenn ich nun schon versuche alle 3 "wichtigen" Plattformen nativ zu unterstützen, was ist der momentane (technische) optimale Weg?

Windows Linux MacOS
WPF GTK# Cocoa
WinForms WinForms Cocoa