XE und XE2 - was ist so attraktiv daran?

[Progman]

Ich hatte die Trial-Version von Delphi XE2. Mein Chef machte, um die Vollversion zu kaufern, zur Bedingung, eine Test-App für iOS zu erstellen. War natürlich nicht möglich.
Dann wenigstens mal was mit FireMonkey zu erstellen, klappte auch nicht wirklich außer belanglosen Forms mit ein paar Komponnenten. Eine Hilfe war schlichtweg nicht vorhanden und es wurde gebeten, doch selbst was dazu beizutragen.
Also Prinzip Bananen-Software: reift beim Kunden :lol:
Ergebnis war, dass mein Chef sich nicht erweichen ließ, es zu kaufen. So arbeite ich weiterhin mit dem guten alten Delphi 2007. Meine Programme laufen auf XP, Vista und Win7, das genügt mir.
Win8 ist für mich kein Thema, denn bis das rauskommt, bin ich in Rente :)

[jaenicke]

Zitat:

Zitat von Progman (Beitrag 1135358)

Ich hatte die Trial-Version von Delphi XE2. Mein Chef machte, um die Vollversion zu kaufern, zur Bedingung, eine Test-App für iOS zu erstellen.

Die wichtigsten Erweiterungen seit Delphi 2007 liegen woanders. Durch Generics und andere Sprachfeatures ist die Produktivität einfach deutlich höher. Insofern macht es nicht unbedingt Sinn die Kaufentscheidung von iOS oder FireMonkey abhängig zu machen, wenn man das nicht unbedingt gerade braucht. Sinnvoller ist die eingesparte Entwicklungszeit hochzurechnen und dann zu überlegen, ob ein Kauf Sinn macht.

Zitat:

Zitat von Progman (Beitrag 1135358)

Win8 ist für mich kein Thema, denn bis das rauskommt, bin ich in Rente :)

Ich bin nächstes Jahr noch nicht in Rente. Windows 8 wird für mich definitiv ein Thema, ARM auch. ;-)

[Progman]

Zitat:

Zitat von jaenicke (Beitrag 1135416)

Zitat:

Zitat von Progman (Beitrag 1135358)

Ich hatte die Trial-Version von Delphi XE2. Mein Chef machte, um die Vollversion zu kaufern, zur Bedingung, eine Test-App für iOS zu erstellen.

Die wichtigsten Erweiterungen seit Delphi 2007 liegen woanders. Durch Generics und andere Sprachfeatures ist die Produktivität einfach deutlich höher. Insofern macht es nicht unbedingt Sinn die Kaufentscheidung von iOS oder FireMonkey abhängig zu machen, wenn man das nicht unbedingt gerade braucht. Sinnvoller ist die eingesparte Entwicklungszeit hochzurechnen und dann zu überlegen, ob ein Kauf Sinn macht.

Zitat:

Zitat von Progman (Beitrag 1135358)

Win8 ist für mich kein Thema, denn bis das rauskommt, bin ich in Rente :)

Ich bin nächstes Jahr noch nicht in Rente. Windows 8 wird für mich definitiv ein Thema, ARM auch. ;-)

Nunja, mein Chef richtet sich nach den Wünschen unseres Providers. Und der will halt Apps, Apps, Apps und PC-Programme mit tollen Oberflächen.
Und ich bekomm ab nächsten Monat Rente. Werde zwar noch stundenweise weiterwerkeln, aber ich muss nicht mehr die tollen Features haben, die ich wahrscheinlich nie brauche :-D

[DSCHUCH]

also nach vielen versuchen in anderen versionen von delphi funktioniert xe bei uns als erste seit d7 sehr gut. wobei ich sagen muß das wir seit d2009 den eindruck hatten das es wieder funktioniert, allerdings haben wir dann lange gebraucht bis wir das unicode und komponententheater (externkomponenten) gerichtet hatten.

xe ist mit sicherheit stabiler und produktiver als d7.

abstürzen tut es bei uns nachvollziehbar wenn man zuviel in die ide lädt, was quasi selbst teil des projekts ist. heißt: componente entwickeln, installieren, form öffnen, package conpilieren während das form offen ist (evtl noch 1-2 dynamische querverbindungen) -> crash.

arbeitet man rein im projekt ohne packages anzufassen läuft es wirklich stabil und sehr gut. schliesst man alle forms im designer läuft es gut... solange man keine bpl's compiliert.

trotzdem werden wir xe2 überspringen. ich traue den neuen sachen einfach nicht übern weg und unser projekt ist zu komplex und anfällig für seiteneffekte. so ist xe wesentlich anfälliger für nicht sauber entladene bibliotheken. d7 war da problemloser. im xe kracht es bei uns häufig, wenn irgendwelche querreferenzen existieren währen etwas entladen wird. problem ist dann immer eine sich nicht richtig beendende anwendung. hatten wir im d7 nie.

kaufen werden wir testhalber trotzdem xe2. die umstellung über x versionen hat uns einen mega aufwand gekostet, das möchten wir in zukunft etwas eingrenzen, indem wir mehr auf die weiterentwicklungen der "lieferanten" rücksicht nehmen /soweit möglich und wir nicht nur mit testen beschäftigt sind... bei xe3 sind wir sicher dabei, vor allem da wir uns weiterentwicklungen zb von sprachfeatures, im datasnap etc erhoffen, was wir doch inzwischen recht intensiv verwenden.

[jaenicke]

Zitat:

Zitat von DSCHUCH (Beitrag 1135430)

bei xe3 sind wir sicher dabei, vor allem da wir uns weiterentwicklungen zb von sprachfeatures, im datasnap etc erhoffen, was wir doch inzwischen recht intensiv verwenden.

Da sind auch bei XE2 bereits wichtige Neuerungen dabei.
http://cc.embarcadero.com/item/28542
Bei 14:53 werden z.B. die Events für Heavyweight Callbacks gezeigt. Das heißt man hat jetzt überall, auch in JavaScript, Events, mit denen man auf einen Serverdisconnect usw. reagieren kann. Genau so etwas habe ich bei XE sehr vermisst.

[mquadrat]

Zitat:

Zitat von jbg (Beitrag 1135349)

Das Problem der Beta-Tester wird wohl auch sein, dass sämtliche Drittkomponenten noch nicht verfügbar sind und sie somit ihre eigenen Projekte gar nicht zum Testen nutzen können. Und fiktive Testprojekte sind sehr eingeschränkt auf das was zu testen ist.

Stimmt, daran hatte ich nicht gedacht. Hatte das Problem ja selbst als ich XE2 am ersten oder zweiten Verkaufstag gekauft hatte. Und das obwohl die meisten Komponentenhersteller doch im Beta-Programm sein müssten (als Emba Tech Partner?!).

[Uwe Raabe]

Zitat:

Zitat von mquadrat (Beitrag 1135454)

Zitat:

Zitat von jbg (Beitrag 1135349)

Das Problem der Beta-Tester wird wohl auch sein, dass sämtliche Drittkomponenten noch nicht verfügbar sind und sie somit ihre eigenen Projekte gar nicht zum Testen nutzen können. Und fiktive Testprojekte sind sehr eingeschränkt auf das was zu testen ist.

Stimmt, daran hatte ich nicht gedacht. Hatte das Problem ja selbst als ich XE2 am ersten oder zweiten Verkaufstag gekauft hatte. Und das obwohl die meisten Komponentenhersteller doch im Beta-Programm sein müssten (als Emba Tech Partner?!).

Das muss aber nicht unbedingt etwas heißen. Wenn ich als Bibliotheksanbieter am Beta-Programm teilnehme, dann kann ich zwar meine Bibliotheken an die Beta-Versionen anpassen, aber auch das braucht etwas Zeit. Erst wenn alle Bibliotheken angepasst sind, kann mit der Portierung der Anwendung begonnen werden. In einigen Fällen ist das sogar jetzt noch nicht möglich, da es noch viele nicht portierte Bibliotheken gibt (viele Anbieter verbinden das auch gern mit einem kostenpflichtigen Update und neuer Funktionalität). Insofern sind einige komplexere Anwendungen, die genügend Fremd-Bibliothekenn nutzen, nicht oder nur bedingt mit einer Beta-Version zu verwenden.

Viele Beta-Tester gehen auch den sicheren Weg und installieren die Beta nur in einer sauberen VM (wer riskiert schon gern seine Produktivumgebung). Das macht das Auffinden von Integrationsfehlern mit anderer Software, bestimmter Hardware und insbesondere älteren Versionen natürlich deutlich schwieriger.

Dann muss man ja auch bedenken, daß die einzelnen Beta-Versionen z.T. noch nicht alle geplanten Features implementiert haben, bzw. diese noch fehlerhaft sind. In vielen Fällen ist das auch ein Ausschlusskriterium für einige Projekte.

Mit der neuen monatlichen Update-Strategie wird man die noch bestehenden Unzulänglichkeiten aber deutlich besser in den Griff bekommen, als bei den früheren Versionen.

[franktron]

Da muss ich Uwe zustimmen Komplexe Projekte kann man nicht in einer Beta testen, da diese meisten Fremdkomponenten nutzen.

Als Bsp. wir haben eine ca 250.000 Zeile grosse Konsolen App (oder Dienst) die konnte ich erst 4 Wochen nach erscheinen von XE2 auf XE2 Kompilieren weil die Fremdkombos erst dann alle lauffähig wahren obwohl das nur 4 Stück wahren(und alle von grossen Herstellern).

Außerdem das Gejammer mit umstellen von XE nach XE2 ging ohne Probleme bei uns. (es hilft ungemein schönen sauberen Code zu haben)

[Uwe Raabe]

Zitat:

Zitat von franktron (Beitrag 1135487)

Außerdem das Gejammer mit umstellen von XE nach XE2 ging ohne Probleme bei uns. (es hilft ungemein schönen sauberen Code zu haben)

Das kann ich auch bestätigen (auch für ältere Versionen). Das Portieren des Projekts selbst ist meistens nur wenig Aufwand, wenn überhaupt. Das Problem ist immer die Wartezeit auf die Komponenten. Meistens habe ich aber alle Projekte nach spätestens drei Monaten umgestellt und kann mich dann ganz den neuen Möglichkeiten widmen.

[bernhard_LA]

wir brauchen grosse Array's in unserer Anwendung, ohne Delphi XE2 hätten wir jetzt die Portierung auf LAZARUS oder gleich C++ gemacht