Was kommt nach XE5?

[Alex_ITA01]

Hallo zusammen,
endlich ist das XE5 da, welches ich (leider) überhaupt nicht benötige.
Sicherlich gibt es genug Leute, die darauf gewartet haben und es sei Ihnen auch gegönnt.

Nur würde mich jetzt echt mal interessieren, ob irgendeiner schonmal was über die weitere Vorgehensweise bei Embarcadero nach XE5 gehört hat?

Am Delphi Produkt als solches, wurden ja keine Änderungen mehr großartig seit XE3 gemacht und beim XE4 gibt es auch keine Updates zur Delphi Umgebung.

Kommt da irgendwann mal wieder was oder wird jetzt nur noch auf Mobil-Programming (IOS/Android usw.) geguckt?
Wenn ich mir die Quality Central angucke im Bereich Delphi, wird einem ja ganz "anders" beim lesen der Beiträge.

Ich würde mich echt freuen, wenn jetzt die vorhandenen/gemeldeten Bugs/QC's endlich mal abgearbeitet werden und der Endkunde damit zufrieden gestellt wird.

Ihr könnt ja gerne mal eure Gedanken hierzu loswerden ;-)
Gruß
Alex

[jaenicke]

Auf dem Plan stehen ja noch Windows RT, Android für Intel CPUs (ich glaube noch nicht offiziell angekündigt), Linux Server, ...
Dafür dürfte ein großer Teil der Ressourcen draufgehen.

[Bernhard Geyer]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1229407)

Hallo zusammen,
endlich ist das XE5 da, welches ich (leider) überhaupt nicht benötige.

Dann las es bleiben.

Zitat:

Zitat von Alex_ITA01 (Beitrag 1229407)

Nur würde mich jetzt echt mal interessieren, ob irgendeiner schonmal was über die weitere Vorgehensweise bei Embarcadero nach XE5 gehört hat?

Primär wirds weiter im Mobilen Bereich gehen.
Für den Desktop-Windows-Bereich wüsste ich nicht was man machen müsste.
Für den Serverbereich hat man eh gegen .NET, Java und PHP verloren.

Zitat:

Zitat von Alex_ITA01 (Beitrag 1229407)

Wenn ich mir die Quality Central angucke im Bereich Delphi, wird einem ja ganz "anders" beim lesen der Beiträge.

Die Anzahl sollte man nicht überbewerten. Vermutlich könnte 50+% geschlossen werden da dies alte Versionen betrifft. Hab erst vor ein paar Tagen 2-3 von mir geschlossen das sie noch zu V6/7-Zeiten aufgemacht wurden.

Zitat:

Zitat von Alex_ITA01 (Beitrag 1229407)

Ich würde mich echt freuen, wenn jetzt die vorhandenen/gemeldeten Bugs/QC's endlich mal abgearbeitet werden und der Endkunde damit zufrieden gestellt wird.

Vermutlich könnte man 50+% einfach schließen wenn man versuchen würde den Fall mit neuer Version nachzustellen. Aber ob das jemand machen wird.

[Morphie]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1229412)

Für den Desktop-Windows-Bereich wüsste ich nicht was man machen müsste.

Also mir fallen da so einige Sachen ein, wenn man nur mal zu .NET rüberschaut...
Neue Sprachfreatures (LINQ z.B.)
Oder da Delphi ja hauptsächlich für die schnelle Erstellung von Datenbankbasierenden Anwendungen gedacht war, könnte man den Teil auch mal modernisieren. Z.B. durch ein ORM-Framework.
Oder generell moderne Architektur-Muster einführen wie z.B. MVVM oder ähnliches...

Denn das wird in den nächsten Jahren ein großes Problem von Delphi sein. Andere Programmiersprachen / Programmierumgebungen laufen Delphi einfach davon, weil sie moderne Entwicklungsmuster erfinden / implementieren

[jaenicke]

Zitat:

Zitat von Morphie (Beitrag 1229422)

Neue Sprachfreatures (LINQ z.B.)

Gearbeitet wird daran ja durchaus, aber das ist in Delphi mit dem One-Way-Compiler nicht so einfach umzusetzen. Normalerweise geht man bei LINQ von innen nach außen vor, von den bekannten Datentypen ausgehend. Das ist in Delphi aktuell im Compiler so nicht vorgesehen.
Das ist auch der Grund weshalb der Delphicompiler (also der Win32/Win64, nicht der mobile...) um Größenordnungen schneller ist als z.B. der von C++.

Zitat:

Zitat von Morphie (Beitrag 1229422)

Oder da Delphi ja hauptsächlich für die schnelle Erstellung von Datenbankbasierenden Anwendungen gedacht war, könnte man den Teil auch mal modernisieren. Z.B. durch ein ORM-Framework.

Die Modernisierung ist bei den Livebindings ja durchaus erfolgt, nur leider ohne Compilerunterstützung...

Zitat:

Zitat von Morphie (Beitrag 1229422)

Oder generell moderne Architektur-Muster einführen wie z.B. MVVM oder ähnliches...

Damit so etwas in Delphi zu implementieren hatte ich bisher keine Probleme, mir fällt auf den ersten Blick nicht ein was Delphi selbst dabei tun sollte. Die direkte GUI-Logik bringe ich im Formular unter, der Rest passiert über beiderseitige Interfaces (Eventhandler-Interface und GUI-Interface).

[Bernhard Geyer]

Zitat:

Zitat von Morphie (Beitrag 1229422)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1229412)

Für den Desktop-Windows-Bereich wüsste ich nicht was man machen müsste.

Also mir fallen da so einige Sachen ein, wenn man nur mal zu .NET rüberschaut...
Neue Sprachfreatures (LINQ z.B.)
Oder da Delphi ja hauptsächlich für die schnelle Erstellung von Datenbankbasierenden Anwendungen gedacht war, könnte man den Teil auch mal modernisieren. Z.B. durch ein ORM-Framework.

Ok. Du meinst nicht spezielle für den Desktop. Ich bin jetzt von Features ausgegangen die nur für Win32/64 nötig wären.
Den diese Sprachfeatures sollte ja überall verfügbar sein und nicht nur für Win32/64.

Ich denke solche grundsätzlichen neuen Sprachfeatures werden (sollten?) nur mit dem neuen LLVM Compiler. Hier jetzt für mehrer Compiler Sprachfeatures zu implementieren wird zu lange dauern bzw. die Kapazitäten den Emba überfordern. Vor allem wenn man bedenkt das der Win32-Compiler eigentlich schon lange durch eine komplette neuimplementierung abgelöst werden müsste. Die Frage ist jedoch bis wann auch der WinXX-Compiler darauf umgestellt wird.

Zitat:

Zitat von Morphie (Beitrag 1229422)

Denn das wird in den nächsten Jahren ein großes Problem von Delphi sein. Andere Programmiersprachen / Programmierumgebungen laufen Delphi einfach davon, weil sie moderne Entwicklungsmuster erfinden / implementieren

Die Frage ist aber welche nötig Erweiterung man erst angeht. Man kann eine Super Sprache haben, sie wird aber trotzdem nicht eingesetzt da sie nur für WinXX existiert.
Oder man kann versuchen alle relevanten Plattformen zu unterstützen und dann basierend auf der neuen Technik (Compiler) Schrittweise neue Sprachfeatues einzubauen.
Ich denke der Weg ist schon richtig erstmal Lösungen für iOS, MacOS und Android (und bald WinRT) anzubieten als sich nur auf WinXX zu konzentrieren. Vor Jahren zu Zeiten von Windows CE und Mobile konnte man das Thema noch Halbwegs ignorieren. Jetzt mit dem Erfolg von iOS/Android und der Verbreitung von großen Smartphones/Tablet ist das nicht mehr möglich.

[Der schöne Günther]

Ich persönlich fände WinRT-API-Unterstützung sehr spannend. Könnte ich, frei nach Embarcadero Marketing-Sprech, mit einer einzigen Codebasis Win8, WinRT und WinPhone (und mehr) erreichen - ¡Hola!

Als "sein" Feature hat sicher jeder etwas anderes, aber bislang ist doch nur der C++/64er-Compiler auf einem neuen LLVM-Backend, oder? Geschwindigkeitsmäßig fällt Delphi auf Win32 bei reinen Berechnungen wahrscheinlich schon gegen JIT-Gegenstücke wie C# und Java hinten runter. Eine Modernisierung des reinen Delphi-Compilers ist ja ein wirkliches Muss.

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1229435)

Geschwindigkeitsmäßig fällt Delphi auf Win32 bei reinen Berechnungen wahrscheinlich schon gegen JIT-Gegenstücke wie C# und Java hinten runter.

Gerade bei 64-Bit sieht es da bei Delphi gar nicht schlecht aus.

[Robotiker]

Zitat:

Zitat von Der schöne Günther (Beitrag 1229435)

aber bislang ist doch nur der C++/64er-Compiler auf einem neuen LLVM-Backend, oder?

Und da hakt es dann. Offenbar kann der auch in XE5 noch keine Packages erzeugen.
https://forums.embarcadero.com/threa...9800&tstart=45

Auch der Android C++ Compiler bekommt, nach einem anderen Thread aus dem Emba Forum, erst im Winter einen Fieldtest und kommt wohl wohl frühestens in XE6.

Da der Win32 C++ Compiler sicher erst nach Delphi auf LLVM umgestellt werden kann, er hängt ja davon ab, würde ich da mal mit noch einigen Jahren rechnen ...

[Der schöne Günther]

Aber besser als nichts :-)
Und in letzter Zeit hatten die Jungs ja eine Menge zu tun. Wenn so etwas nach XE5 erklärtes Hauptziel ist geht das sicher schneller.

Ich bin wirklich mal gespannt, was für die nächsten Jahre auf die Roadmap kommt. WinRT haben sie ja offiziell auch nur in Betracht gezogen, nie versprochen (oder?).

[Insider2004]

Da wird nix modernisiert. Der Win32 Compiler ist die Referenz. Daran muss sich jeder neue Compiler messen lassen. Und im Moment liegen da die LLVM-Compiler meilenweit zurück. Nicht mal der Win64 Compiler kommt da ran. Allen Bauer hat gesagt, dass am Win32 nichts gemacht wird, solange der Rest so "schlecht" läuft. Win32 ist die Butter auf dem Brot!

Zitat:

Zitat von Der schöne Günther (Beitrag 1229435)

Ich persönlich fände WinRT-API-Unterstützung sehr spannend. Könnte ich, frei nach Embarcadero Marketing-Sprech, mit einer einzigen Codebasis Win8, WinRT und WinPhone (und mehr) erreichen - ¡Hola!

Als "sein" Feature hat sicher jeder etwas anderes, aber bislang ist doch nur der C++/64er-Compiler auf einem neuen LLVM-Backend, oder? Geschwindigkeitsmäßig fällt Delphi auf Win32 bei reinen Berechnungen wahrscheinlich schon gegen JIT-Gegenstücke wie C# und Java hinten runter. Eine Modernisierung des reinen Delphi-Compilers ist ja ein wirkliches Muss.

[Der schöne Günther]

Ich bin da kein Spezialist, weder in Theorie noch Praxis. Ich habe nur irgendwie das Gefühl, dass auch ein aktuelles XE4/5-Kompilat noch unnötigerweise auf einem 486er lauffähig wäre, man für die Ausnutzung moderner Befehlssätze wie SSEx allerdings wieder den Assembler auspacken müsste.

Vielleicht bekomme ich auch nur das falsche Hörensagen mit, keine Ahnung.

[Insider2004]

Zitat:

Zitat von Der schöne Günther (Beitrag 1229458)

Ich bin da kein Spezialist, weder in Theorie noch Praxis. Ich habe nur irgendwie das Gefühl, dass auch ein aktuelles XE4/5-Kompilat noch unnötigerweise auf einem 486er lauffähig wäre, man für die Ausnutzung moderner Befehlssätze wie SSEx allerdings wieder den Assembler auspacken müsste.

Vielleicht bekomme ich auch nur das falsche Hörensagen mit, keine Ahnung.

Das liegt nicht in der Hand vom EMBA. Alle CPUen, die vom OS unterstützt werden, müssen auch vom Compiler unterstützt werden. Und wenn das der 486 ist, dann ist es halt der 486 bzw. dessen Instruktionen.

[hoika]

Hallo,

Unter c++ konnte man zumindestens die Mindest-CPU einstellen.

Heiko

[Insider2004]

Zitat:

Zitat von hoika (Beitrag 1229468)

Hallo,

Unter c++ konnte man zumindestens die Mindest-CPU einstellen.

Heiko

Alles gut und schön. Lustig vor allem, wenn es beim Kunden dann nimmer läuft.

[Der schöne Günther]

Jeder hat andere Anwendungsgebiete. Ich muss bsp. keine 486er mehr bedienen, wir liefern die PCs auf denen der Kram läuft selbst mit aus, da weiß ich genau was drinsteckt. Mir persönlich wäre es sympathisch sagen zu können "Nur zu, Compiler, benutze SSE3. Denn wenn dieser Part hier 10% schneller läuft, freue ich mich."

Auf StackOverflow war neulich einmal jemand wohl bald den Tränen nahe, als er ein paar arithmetische Tests in verschiedenen Sprachen laufen ließ und manche Dinge schon per JavaScript im Browser schneller liefen als in einer nativen Delphi Win32-Anwendung mit was weiß ich für einem CPU-Befehlssatz.

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1229478)

Zitat:

Zitat von hoika (Beitrag 1229468)

Hallo,

Unter c++ konnte man zumindestens die Mindest-CPU einstellen.

Heiko

Alles gut und schön. Lustig vor allem, wenn es beim Kunden dann nimmer läuft.

Wenn 99,9% der Kunden damit eine x% schneller Anwendung bekommen - Was solls.
Den 0,1% der "ich hab Uralt-Rechner" kann man ja ein Nicht Optimierte Anwendung geben.

[Alex_ITA01]

@Bernhard Geyer: Also das man im QC ca. 50% streichen / schließen kann will ich mal dahin gestellt lassen aber ok.
Mir gehts aber in erster Linie mal darum, dass im QC ja genug Einträge stehen, die mit XE3 und XE4 zu tun haben welche das Delphi Produkt betreffen. Hier würde ich mich einfach mal über Updates auf dieser Schiene freuen. Klar müssen die auch neue Features für irgendwelche neuen Systeme erstellen aber man sollte sich doch auch mal um seine vorhandenen Produkte kümmern oder?

Finde die Beiträge hier sehr konstruktiv, weiter so...

Gruß
Alex

[Delphi-Laie]

Zitat:

Zitat von Insider2004 (Beitrag 1229463)

Das liegt nicht in der Hand vom EMBA. Alle CPUen, die vom OS unterstützt werden, müssen auch vom Compiler unterstützt werden. Und wenn das der 486 ist, dann ist es halt der 486 bzw. dessen Instruktionen.

Nein, müssen sie nicht.

Delphi-32-Bit-Compilate (ab welcher Delphi-Version, weiß ich jetzt nicht, es ging damals aber um XE2-Compilate) sollen den Pentium voraussetzen (schrieb mir mal jemand in einer privaten Nachricht). Windows 2000 setzt jedoch keinen Pentium voraus.

Ergänzung: Ich gebe Dir doch recht, wie Du es formuliertest.