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 :oops: ü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 :roll:

Gruß

[Meflin]

Zitat:

Zitat von Insider2004 (Beitrag 1173897)

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

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

[mjustin]

Zitat:

Zitat von KWolf (Beitrag 1173904)

@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

[BUG]

Der Witz ist doch, das man in JS auch keinen SSE Code schreiben braucht. Der Compiler muss das beherrschen, nicht ich.
Aber wer weiß, ich würde Hoffnungen in ein LLVM Backend stecken :stupid:

[Insider2004]

Das Problem in den letzten 30 Jahren war doch, dass der von TP/Delphi erzeugte FPU code eine Katastrophe war. Nix optimiert, tausendmal wurde das gleiche immer wieder geladen/gespeichert. LLVM sollte hier schnelle Abhilfe schaffen, da hier extrem gute Optimierer arbeiten.

[hoika]

Hallo,

hm, ich arbeite seit D1 (genauer TP5.5) damit.
Bisher hatte ich keine Probleme mit der FPU-Leistung.

Klar könnte die besser sein (SSE x),
aber wer entwickelt mit Delphi High-Performance-Anwendungen ?

Ich benutze Delphi für Datenbank-Anwendungen,
da spielt, FPU keine Rolle.

Wenn jetzt auf eine neue Compiler-Schiene umgestellt wird,
erwarte ich eher Probleme als Vorteile.
Dann heisst es, jaaa, unser Code ist richtig, LLVM macht das was falsch.
Viele Köche ...

Heiko