Ein Lob an Embarcadero

[greenmile]

Nachdem ich nun 2 Projekte mehr oder weniger erfolgreich in Firemonkey portiert habe, muss ich einfach mal ein Lob an Embarcadero loswerden: Mit XE2 ist wirklicher ein Meilenstein geschaffen wurden, um es auf den Punkt zu bringen: Hammer! Hiervon können sich andere Hersteller eine Scheibe abschneiden. Wenn die Roadmap wirklich umgesetzt wird und ich ein Projekt nur durch einen Doppelklick in die Projektverwaltung mal eben für eine andere Plattform compilieren kann, geht einer meiner uralter Träume in Erfüllung. Schon jetzt bin ich mehr als begeistert. Geschwindigkeit hin oder her, aber unterm Strich kann nun jeder Delphi Entwickler eine App für den Mac schreiben. Was will man mehr? Da darf es dann ruhig ein wenig langsamer laufen. In Zeiten, in denen es x Plattformen gibt und jeder sein eigenes Süppchen kocht braucht es dringend eine Sprache (neben C und Java), die Plattformübergreifend funktioniert. Embarcadero scheint das erkannt zu haben.

Aaaaber ... Mit der Entwicklung, die positiv abgeschlossen ist, muss ich auch ein "aber" loswerden. So toll Firemonkey auch ist habe ich das Gefühl, es wurde mit heißer Nadel gestrickt. Hat den niemand bei der Entwicklung daran gedacht, dass Anchors eine durchaus nette Sache sind? Oder dass es durchaus sinnvoll ist, wenn ein OpenDialog Modal angezeigt wird? Sooo schwer kann es doch nicht sein, sowas umzusetzen, zumal ich die Probleme mit wenigen Codezeilen selbst beheben kann.

Die Informationspolitik sollte ebenfalls durchdacht werden. Ich habe während der Entwicklung x Mails wegen irgendwelchen Sonderangeboten bekommen. Aber nicht eine in der drin stand: Es gibt ein Hotfix. Und ich surfe nicht täglich bei Embarcadero vorbei und schaue, ob es nicht rein zufällig ein Update gibt. Das eingebaute Update hat mir nix gemeldet, nicht mal das Hilfeupdate.

In Summe muss ich sagen: Toll gemacht Embarcadero, Delphi wurde lange genug durch viele Fehler fast tot getreten. Jetzt aber bloß nicht aufhören, dann wird das was!

[WladiD]

Meine Meinung deckt sich fast 1:1 mit deiner, auch wenn ich FM noch nicht produktiv eingesetzt habe, so sehe ich dennoch, dass es in die richtige Richtung geht. Aus diesem Grund gebe ich Delphi noch Zeit bis 2015 (XE6?), bevor ich mich entscheide: Bei Delphi bleiben oder zu Java wechseln.

Besonders Spannend finde ich, was Emba. aus dem LLVM-Compiler (Gerüchte mehren sich) macht. Damit könnte man den letzten Nachteil der statischen Compilierung ausmerzen. Ich fühle mich doch etwas auf den Schlips getreten, wenn ich lese, dass bei bestimmten Tests Java/.NET/JavaScript überwiegend bessere Ergebnisse erzielt. Ist Klar, die können einfach besser die verfügbaren Features der CPU durch dynamische bzw. Hot-Spot-Compilierung nutzen.

[Insider2004]

was ist "...statischen Compilierung" ???

[KWolf]

Hallo,

@Insider2004: Gute Frage, wüsste ich auch gern.

@WladiD: Du schreibst "Java/.NET/JavaScript" würden bessere Ergebnisse erzielen? Wo kann man dies nachlesen bzw. sich allgemein schlau machen? Ich dachte immer der Code, der vom Delphi Compiler erzeugt wird, sei recht gut, da nativ für Windows?

Ein interessanter Tread, ich würde es schön finden wenn noch etwas Licht ins Dunkel kommen würde

Gruß

[mjustin]

Zitat von KWolf:

@WladiD: Du schreibst "Java/.NET/JavaScript" würden bessere Ergebnisse erzielen?

Zu JavaScript vs Delphi gab es letztes Jahr diesen Vergleich FireFox 4 / Delphi XE

http://delphitools.info/2011/03/24/k...cemonkey-team/

die Mandelbrot Grafik wurde von FireFox in 124 ms gerendert, Delphi benötigte 200 ms.

[himitsu]

64 Bit SSE gegen 32 Bit FPU?

Äpfel und Birnen

[Meflin]

Zitat von Insider2004:

was ist "...statischen Compilierung" ???

Steht doch quasi im Satz danach was er meint. Das Gegenteil von JIT.

[JamesTKirk]

Zitat von WladiD:

Besonders Spannend finde ich, was Emba. aus dem LLVM-Compiler (Gerüchte mehren sich) macht. Damit könnte man den letzten Nachteil der statischen Compilierung ausmerzen. Ich fühle mich doch etwas auf den Schlips getreten, wenn ich lese, dass bei bestimmten Tests Java/.NET/JavaScript überwiegend bessere Ergebnisse erzielt. Ist Klar, die können einfach besser die verfügbaren Features der CPU durch dynamische bzw. Hot-Spot-Compilierung nutzen.

Du bist dir bewusst, dass die Verwendung von LLVM nicht zwangsweise bedeutet, dass JIT Code eingesetzt wird? Die Möglichkeit Code in der VM von LLVM auszuführen ist optional und sogar gar nicht mal unbedingt der normale Anwendungsfall, da die meisten LLVM basierten Programme (vor allem von Clang) doch wieder statisch kompiliert werden.

Gruß,
Sven

[mkinzler]

Für den eigentliche (Sprach-)Compiler (Clang) ist das eh egal, da er LLVM-Bytecode erzeugt. Ob dieser dann von einem JIT-Compiler ausgeführt wird oder von einem anderen Backend in nativen Code überführt wird ist dann egal.