Why now is the best time to upgrade to Delphi XE2

[himitsu]

Zitat:

Zitat von implementation (Beitrag 1158386)

es gibt immer noch Installer, die darauf bestehen (habe aber lange nichts entsprechendes mehr installieren müssen, denn mittlerweile gibt es schließlich für alles freie Alternativen)

Spiele, aber viele setzen inzwischen auf sowas wie Steam oder einen Zwangsonlinezugang, während der Arbeit, oder zumindestens eine Onlineauthentifizierung.

Delphi auch, es sei denn man nutzt die eher selten benutzte Alternative.

[cookie22]

Zitat:

Zitat von EWeiss (Beitrag 1158367)

Zitat:

Wir hatten bei uns auch schon oft den Fall, dass unsere Software gar nicht schuld war

Im grunde magst du ja recht haben.
Aber du mußt auch zustimmen sorry schweife jetzt etwas ab Beispiel Spiele.
Es wird viel mist verbreitet bzw. verkauft was einfach nun mal Unfertig ist das kann niemand von der Hand weisen.
Und genau das ist vor den ganzen Updates von XE2 genauso hier der Fall.

Embarcadero war sich dessen bewußt und hat XE2 trotzdem veröffentlicht das ist eine Masche
die Heute gang und gebe ist. Kann ich einfach nicht in Ordnung finden.
Aber wie gesagt selbst kann ich da nichts machen ist halt schon Standard in der heutigen zeit.

gruss

Bei der heutigen Geschwindigkeit mit der neue Versionen herausgegeben werden (müssen). Kann man das nicht vermeiden. Gerade an so großen Projekten wie Delphi, hängt sehr viel mehr als du dir wahrscheinlich vorstellen kannst. Da haben Versionszyklen eingehalten zu werden, denn ansonsten macht man finazielle Verluste. Da Software von Jahr zu Jahr komplizierter wird, gibt es logischerweise auch neue und mehr Bugs. Auch ich würde mir reifere Releases wünschen, aber solange nachgepatcht wird, geht es doch.

[himitsu]

Zitat:

Da haben Versionszyklen eingehalten zu werden,

Daran ist man aber auch selber Schuld.
Einen prünklich jährlichen Ausgabezüklus hat von uns wohl kaum einer erwartet.

Es ist manchmal eher etwas frustrierend, wenn man sich was kauft und es kurz danach schonwieder Alt ist.

[cookie22]

Das ist wohl war, die Geschwindigkeit mit der neue Versionen rausgekloppt werden ist schon übertrieben. Die Frage ist ob Delphi mit längeren Zyclen wirtschaftlicher wäre, denn um nichts anderes geht es.

[himitsu]

Wirtschafftlicher?
Nee.

Zwei verkaufte halbe/drittel Versionen bringen mehr Gewinn, als eine Ganze.
(Gewinn=Geld, aber nicht unbedingt Ansehn und Co.)


Stell dir mal vor Windows würde jährlich eine neue Version rausbringen und für die alten Versionen sofort die Unterstützung einstellen, das währe ein Chaos,
kommt aber auf's Selbe raus.

[EWeiss]

Zitat:

Bei der heutigen Geschwindigkeit mit der neue Versionen herausgegeben werden (müssen). Kann man das nicht vermeiden.

Gebe ich dir Recht soweit es um Versionen geht
Hier wurde aber ein unfertiges Produkt ausgeliefert. Oder ist XE2 kein eigenständiges Produkt?
Wenn du ne Microwelle kaufst und nach der ersten verwendung feststellen mußt das sie deinen Kaffee nicht erhitzt
dann gehe ich davon aus das du diese im Laden Reklamierst.
Kaufst du eine Software und stellst fest das sie fehler hat mußt du damit Leben weil du abhängig davon bist
andernfalls verdienst du keinen Pfennig mehr wenn du dein Programm nicht mehr Supporten kannst.

Also zusammengefaßt.
Es macht überhaupt keinen Sinn zu dieser oder in nächster Zeit auf XE2 zu aktualisieren noch es zu Kaufen.
Sorry so sehe ich das.
Ich für meinen Teil werde ich das in der zukunft nicht mehr mit mir machen lassen.

gruss

[cookie22]

Eine Microwelle mit Software zu vergleichen, ist Quatsch. Das unfertige Produkte herausgegeben werden und nach gepatcht werden, war bei Software schon immer normal. Das ist nun wirklich nichts neues. ;)

Zitat:

Zitat von EWeiss (Beitrag 1158415)

...Ich für meinen Teil werde ich das in der zukunft nicht mehr mit mir machen lassen.

Dann wirst du bis an dein Lebensende mit Delphi 2010 klar kommen müssen.

[implementation]

Zitat:

Zitat von cookie22 (Beitrag 1158417)

Eine Microwelle mit Software zu vergleichen, ist Quatsch. Das unfertige Produkte herausgegeben werden und nach gepatcht werden, war bei Software schon immer normal. Das ist nun wirklich nichts neues. ;)

Dass es nichts neues ist, macht es besser? Das ist nun wirklich kein Gegenargument, sondern das haben sogar die Plantagenbesitzer bei der Abschaffung der Sklaven gesagt :shock:

Btw. "schon immer" ist aller größter Blödsinn, am Anfang stand die Hackerkultur, wo Software noch nicht einmal als Ware angesehen wurde, ergo auch nicht "rausgebracht" wurde.

[EWeiss]

Zitat:

Das unfertige Produkte herausgegeben werden und nach gepatcht werden, war bei Software schon immer normal.

k.a wann du geboren bist aber ich kenne das noch anders.

Zitat:

Eine Microwelle mit Software zu vergleichen, ist Quatsch.

Hättest du lieber mein Auto mein Boot oder Haus gehabt?
Es geht um das Grundprinziep. Gutes Geld gute Ware.

EDIT:
Und weil es immer so war (deine Meinung) muss es so bleiben?
Die Menschen werden immer mehr zu Puppenspieler wobei man sich fragt wer der Spieler und wer die Puppe ist.
Am Anfang gab es C64, TRS80, Amiga usw. und bei allen ASM/Basic da war nix mit patchen oder updates.
Waren das noch zeiten als ich mit dem TRS80 meine erste Analoge Uhr Programmiert habe. ;)

gruss

[Bummi]

Angebot und Nachfrage ...
wer keine grünen Bananen kauft, zwingt zur Produktion gelber Bananen, XE2 haben wir ausgelassen, mal sehen was kommt ...

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1158421)

Zitat:

Das unfertige Produkte herausgegeben werden und nach gepatcht werden, war bei Software schon immer normal.

k.a wann du geboren bist aber ich kenne das noch anders.

Ja, du hast Recht, früher wurden Fehler oft gar nicht nachgepatcht, da war es eben wie es war bis zur nächsten Version. Da war die Software aber auch noch nicht so komplex, dass das ein großes Problem war. Ich wusste halt, dass ich in bestimmten Situationen einen bestimmten Befehl nicht benutzen darf.

[EWeiss]

Zitat:

Ich wusste halt, dass ich in bestimmten Situationen einen bestimmten Befehl nicht benutzen darf.

Dann hast du irgendetwas falsch gemacht. :)
Oder willst du ernsthaft behaupten das jedes Spiel das für den C64 veröffentlicht wurde fehlerhaft war?
Und das Betriebssystem auf den ROM wurde mit Sicherheit nicht alle 2 Monate gepatscht.

Würde es jetzt um VB gehen hätte jeder was dazu zu sagen und das Teil verteufeln
da es aber um Delphi geht will es jeder irgenwie schön reden und nimmt den Ärger gern in Kauf.
Ist halt so wie es ist. Wie Arm ist soetwas.

gruss

[mkinzler]

Zudem ist es ja nicht so, dass Delphi XE gar nicht funktionieren würde. Es kann endlich 64-Bit-Anwendungen erzeugen und die VCL wurde um VCL-Styles und Databinding erweitert.
FMX ist in der bisherigen Form natürlich kein Ersatz für die in den Jahren gewachsene VCL. Für den einen oder anderen wird diese Bibliothek aber ausreichend sein. Und auch die Einführung von neuen Platformen wie MaxOSX und iOS ist für ein Teil der Kundschaft ein Plus.
Um beim Vergleich mit der Mikrowelle zu bleiben. Bietet diese Mikrowelle nun ein paar Zusatzfeatures, welche zum Teil noch nicht ganz ausgegoren sin. Die normalen Features funktionieren wie beim Vorgängermodell. Hier würde keiner sagen, dass die neue Schrott ist, sondern würde entscheiden, ob die neuen Features eine Neuanschaffung rechrfertigen oder nicht.
Wenn du keine Notwendigkeit für 64-Bit-Anwendungen siehst und MacOSX/iOs auch keine Thema für dich ist bleibst du halt bei der Vorgängerversion.

[Meflin]

Zitat:

Zitat von EWeiss (Beitrag 1158431)

Oder willst du ernsthaft behaupten das jedes Spiel das für den C64 veröffentlicht wurde fehlerhaft war?

Mit Sicherheit. Fehlerfreie Software ist im Großen und Ganzen eine Illusion - aus den verschiedensten Gründen. Dir als Entwickler sollte das aber eigentlich bekannt sein.

[EWeiss]

Zitat:

Zitat von Meflin (Beitrag 1158433)

Zitat:

Zitat von EWeiss (Beitrag 1158431)

Oder willst du ernsthaft behaupten das jedes Spiel das für den C64 veröffentlicht wurde fehlerhaft war?

Mit Sicherheit. Fehlerfreie Software ist im Großen und Ganzen eine Illusion - aus den verschiedensten Gründen. Dir als Entwickler sollte das aber eigentlich bekannt sein.

Logisch, aber nicht so das es nötig gewesen wäre das Betriebssystem zu patchen.
Auf was ich hinaus will ist die Qualität und diese ist bei weiten nicht mehr so wie es früher einaml war.
Warum wurde ja schon mehrfach erläutert.Aber alle diese Scheinheiligen Entschuldigungen fruchten bei mir einfach nicht.
Sorry.
Qualität = Qualität und nicht <> als Schlecht

gruss

[jaenicke]

Zitat:

Zitat von EWeiss (Beitrag 1158431)

Zitat:

Ich wusste halt, dass ich in bestimmten Situationen einen bestimmten Befehl nicht benutzen darf.

Dann hast du irgendetwas falsch gemacht. :)

Ja, na klar...
Die Abstürze waren halt nicht wegen fehlerhafter Software sondern wegen falscher Bedienung. Heute ist das natürlich ganz was anderes, da muss man etwas falsch machen dürfen was ich früher eben nicht hätte falsch machen dürfen oder wie soll ich die Argumentation verstehen? :roll:

Und was C64 & Co angeht: Die Zeiten habe ich nicht mehr miterlebt. Aber das war auch ein Bruchteil des Codes und es haben auch nicht so viele an der selben Codebasis gearbeitet. Den eigenen Code und mögliche Fallstricke überblickt man eben auch besser als Code, den man nicht selbst geschrieben hat.
Ich weiß nicht wie es dir geht, aber ich zumindest merke ständig wie die Komplexität steigt. Wie viel Funktionalität in Projekten eingebaut wird, die man vor 10 Jahren nicht einmal für sinnvoll möglich gehalten hätte.

Jedenfalls hätte Embarcadero bei Delphi 2009 natürlich sagen können, nein, Generics funktionieren noch nicht immer, also lassen wir es erst einmal. Analog bei anderen Features wie 64-Bit. Aber nur weil ich von 100 Fällen in einem Fall eben Generics wegen eines Fehlers doch nicht so verwenden kann wie ich gerne will (und eben den herkömmlichen Weg gehen muss), werden die anderen 99 Fälle dadurch ja nicht wieder schlechter, in denen es eine deutliche Produktivitätssteigerung ist.

Zudem hatte man manche Verwendungen von Generics nie so geplant, aber irgendjemand hat es dann halt versucht und es ging. Aber halt nur teilweise. Nicht weil es ein Fehler im eigentlichen Sinn war, sondern weil die Verwendung so nie geplant war. Und dann wird halt versucht das doch einzubauen. Und so weiter...
Insbesondere bei Programmiersprachen treten viele Konstellationen eben erst bei den Usern auf.

Wenn man die Meinungen in den Foren mal zusammenfasst:
Neue Features hätten in der jeweiligen Form noch gar nicht veröffentlicht werden dürfen, diese Nicht-Veröffentlichung hätte aber schon 10 Jahre früher passieren sollen.

Sprich: Warum wird jetzt nicht endlich ein fehlerfreies Delphi 6 mit Generics und 64-Bit veröffentlicht?
Hmm, könnte eventuell dran liegen, dass du für eine solche Version nicht schon erstens während der Entwicklung etwas hättest zahlen wollen und zweitens nicht so viel...
Uns als Entwicklern sollte das doch am allerbesten klar sein...

Und wie gesagt:
Die schlimmsten Probleme bei Delphi wurden durch Fehler in Fremdprodukten wie Teamviewer verursacht. Alles andere mag ein wenig ärgerlich gewesen sein, wog aber bisher nie die gesteigerte Produktivität auf, die wir z.B. durch XE hatten. Und selbst mit den vielen Abstürzen durch Teamviewer (was wir da ja nicht wussten) war XE noch deutlich produktiver als alte Versionen.

[zeras]

Zitat:

Zitat von EWeiss (Beitrag 1158436)

Qualität = Qualität und nicht <> als Schlecht

Cooler Spruch. Werde ich mal mit in die Firma nehmen. Muss ich da ein Copyright mit dazu schreiben?

[EWeiss]

Zitat:

Zitat von zeras (Beitrag 1158438)

Zitat:

Zitat von EWeiss (Beitrag 1158436)

Qualität = Qualität und nicht <> als Schlecht

Cooler Spruch. Werde ich mal mit in die Firma nehmen. Muss ich da ein Copyright mit dazu schreiben?

NÖ mußt nicht ;)

gruss

[EWeiss]

Zitat:

Jedenfalls hätte Embarcadero bei Delphi 2009 natürlich sagen können, nein, Generics funktionieren noch nicht immer, also lassen wir es erst einmal. Analog bei anderen Features wie 64-Bit. Aber nur weil ich von 100 Fällen in einem Fall eben Generics wegen eines Fehlers doch nicht so verwenden kann wie ich gerne will (und eben den herkömmlichen Weg gehen muss), werden die anderen 99 Fälle dadurch ja nicht wieder schlechter, in denen es eine deutliche Produktivitätssteigerung ist.

Ich bin vielleicht oder sicher bekloppt das ich auf Qualitätsstandard stehe.
Mal weit hergeholt komme aus der F1 Scene.
Stell dir vor ich hätte ein Future zur Karrosserie addiert welches in 99/100 fällen funktioniert hätte.
Was ist mit den 1% ? Hätte dann wohl billigend den Tod von Schuhmacher in kauf genommen.

Dieses 1 Prozent umgelegt auf deine Aussage bei einen großen Konzern der gerade darauf angewiesen ist
wie wird sich das wohl in Millionen auswirken? Unabhängig von den zusätzlichen möglichkeiten die durch zusätztliche Funktionen
wieder Gewinn bringen.

Da wäre dann die Frage ob diese das gerade benötigte 1% wieder aufwiegen.
Wenn es dafür keine alternative gäbe vorrausgesetzt natürlich.

Ich verteufel nicht das XE2 oder die Produkte von Delphi.
Mich stört einfach nur das hier etwas für gut befunden wird was es nicht ist und darauf hingewiesen wird JETZT ein Upgrade gerade
auf dieses Produkt zu tätigen..

Nix für ungut wenn ich euch damit genervt habe.

gruss

[mkinzler]

Der Blog war ja von einem EM Mitarbeiter. ( aus der Marketingabteilung!)
Du willst also einer Firma verbieten, für ihre Produkte zu werben?

Zudem werden deine Vergleiche immer unpassender oder dürfen wir morgen die Bildschlagzeile

"Skandal: Milliarden Tote wegne Fehler in Generics-Implementierung von Delphi!"

erwarten? :stupid:

Nichts für ungut. Aber jeder kann entscheiden, ob die neuen Features eines Softwareproduktes winw Neuanschaffung rechtfertigen oder nicht. Keiner wird gezwungen, dies zu tun!

[EWeiss]

Zitat:

"Skandal: Milliarden Tote wegne Fehler in Generics-Implementierung von Delphi!" erwarten?

Cool ;)
Wie du gelesen hast habe ich es weitergeführt umgelegt auf einen Konzern.
Aber vielleicht wolltest du es aber auch nicht lesen. :)

Zitat:

Nichts für ungut. Aber jeder kann entscheiden, ob die neuen Features eines Softwareproduktes winw Neuanschaffung rechtfertigen oder nicht. Keiner wird gezwungen, dies zu tun!

Aber nein bin dir doch nicht böse wenn du das für dich in Anspruch nimmst.
Auch wenn ich mir ein kichern nicht verkneifen kann. oops..

Wurde alles gesagt von meiner Seite kann man schließen den Thread ;)

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1158415)

Wenn du ne Microwelle kaufst und nach der ersten verwendung feststellen mußt das sie deinen Kaffee nicht erhitzt
dann gehe ich davon aus das du diese im Laden Reklamierst.

Offtopic: Ich kenne keinen Menschen der seinen Kaffee in der Mikrowelle erhitzt! :shock:

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1158529)

Zitat:

Zitat von EWeiss (Beitrag 1158415)

Wenn du ne Microwelle kaufst und nach der ersten verwendung feststellen mußt das sie deinen Kaffee nicht erhitzt
dann gehe ich davon aus das du diese im Laden Reklamierst.

Offtopic: Ich kenne keinen Menschen der seinen Kaffee in der Mikrowelle erhitzt! :shock:

ICH.. ;) Und das im ernst.

gruss

[Daniel]

Sofern die Mikrowelle nicht mit Delphi (XE2) angesteuert wird, haben wir uns wohl eine Idee von der Ausgangsfrage entfernt. ;-)

[EWeiss]

Zitat:

Zitat von Daniel (Beitrag 1158533)

Sofern die Mikrowelle nicht mit Delphi (XE2) angesteuert wird, haben wir uns wohl eine Idee von der Ausgangsfrage entfernt. ;-)

Daniel? :thumb:
Mikrowelle = Qualität!
XE2 = gut genug um für Licht zu sorgen oops..

gruss

[stahli]

Für mich ist XE2 nicht interessant.

- 64bit
brauche ich nicht wirklich. Es reicht, wenn die Exe auf einem 64er Windows lauffähig ist.

- FMX
brauche ich auch nicht. Wenn FM als VCL 2.0 angesehen werden könnte (alle bisherigen Controls als neue Version ohne deren Probleme in Bezug auf Ableitbarkeit, dann gern irgendwann)

- VCL-Styles
ok, aber muss auch nicht (habe außerdem die AlphaControls)

- Live Binding
Das Thema ist wirklich interessant. Ich bin aber noch nicht sicher ob die Umsetzung mit Live Binding als gelungen angesehen werden kann.


Für XE3 würden mich folgende Punkte interessieren:
- überzeugenderes Live Binding
- natives LINQ
- Framework zur Objekt(schnittstellen)erzeugung+Verwaltung sowie ClientServer-Übertragung
- ORM
Mit diesen Dingen will ich mich demnächst befassen und externe Lösungen anschauen, würde mich aber freuen, wenn Delphi dafür schon überzeugende Lösungen mit bringen würde.

[mkinzler]

Zitat:

Für XE3 würden mich folgende Punkte interessieren:
- überzeugenderes Live Binding

Ich bezweifel, dass man hier grundsätzliche Veränderungen erwarten kann, obwohl die abwärtskompatibiltät in letzter Zeit nicht mehr so wichtig zu sein scheint (FMX ändert Interface von Update zu Update)

Zitat:

- natives LINQ

Der Autor von DeHL ist nun bei EM. Da besteht also Hoffnung

Zitat:

- Framework zur Objekt(schnittstellen)erzeugung+Verwaltung sowie ClientServer-Übertragung

Was verstehst du darunter?

Zitat:

- ORM

War ja schon inmal Teil der großen Delphiversion (Bold)

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1158592)

- Framework zur Objekt(schnittstellen)erzeugung+Verwaltung sowie ClientServer-Übertragung

Das erinnert mich doch sehr an DataSnap, das wir auch in unseren Projekten immer mehr benutzen und schon eine Weile in Delphi existiert.

[stahli]

- Live Binding
Es gibt ja gerade bei Emba eine Tutorial-Serie: http://www.youtube.com/user/EmbarcaderoTechNet#p/u
Bin mal auf die nächsten Teile gespannt. Vielleicht erklärt das ja noch einiges...

- Linq
Klingt gut. :-)

- ORM
Alternativ will ich mir demnächst Aurelius + DataModeller von TMS anschauen.

- Framework
Ich meine so etwas Spring+DataSnap.
Im Grunde möchte ich gern im Client ein Objekt/Interface abfordern ohne mich um die Übertragung (Protokolle) und Verwaltung im Detail kümmern zu müssen. Wie das genau aussehen kann weiß ich auch nicht.
Die Controls der Clients sollten an "Objekte" gebunden werden, die durch das Framework dann automatisch bereit gestellt werden.
(Ok, an der Formulierung muss ich nochmal in Ruhe arbeiten. :wink:)

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1158607)

Ich meine so etwas Spring+DataSnap.

Ich hatte durch fremde Quelltexte, die das Spring-Framework nutzen, schon genug Arbeit. Das Debuggen und die Integrationsprüfungen sind da schon umständlich genug. Wenn ich mir jetzt noch vorstelle, dass das noch mit DataSnap kombiniert würde... :shock:

[mkinzler]

Delphi-Spring-Framework