Delphi 2011 heißt jetzt Delphi XE

[blackfin]

Zitat:

oder die Herren sind weiterhin der Meinung das Programmierer Teddies wollen

Waren das nicht Pinguine?

[mkinzler]

Tux ist out, Äpfel sind in

[HeikoAdams]

Zitat von mkinzler:

Tux ist out, Äpfel sind in

Dann ist Delphi megaout - es unterstützt weder Tux noch die Äpfel

[xZise]

Zitat von HeikoAdams:

Zitat von mkinzler:

Tux ist out, Äpfel sind in

Dann ist Delphi megaout - es unterstützt weder Tux noch die Äpfel

Oder was dazwischen: Es unterstützt glücklicherweise kein Tux aber leider keine Äpfel. Das ist zwar nicht meine Meinung über Delphi, Linux und Apple, aber wollte nur ein alternatives Beispiel zeigen.

MfG
Fabian

[Neutral General]

Zitat von xZise:

Zitat von HeikoAdams:

Zitat von mkinzler:

Tux ist out, Äpfel sind in

Dann ist Delphi megaout - es unterstützt weder Tux noch die Äpfel

Oder was dazwischen: Es unterstützt glücklicherweise kein Tux aber leider keine Äpfel.

Wenn schon, dann andersrum Tux ist mir da irgendwie doch sympathischer als der Apfel-Verein mit seinem iKram

[HeikoAdams]

Wie auch immer man es ausdrücken mag, fakt ist doch, das der fehlende Support für x64, Apple und *nix Delphi zum Verhängnis wird, wenn sich da nicht bald etwas dran ändert. Wer kauft schon ein Programmierwerkzeug für über Tausend Euro, wenn er damit nur auf eine Plattform und eine Prozessorarchitektur festgelegt ist?
Wenn die Jungs bei Emba nicht total unterbelichtet sind, dann spendieren Sie Delphi hoffentlich auch Support für ARM-Prozessoren (am besten in Verbindung mit dem Crossplattform-Support), bevor der Zug völlig abgefahren ist.

[Hansa]

Ich muss jetzt auch mal meckern. Aber in etwas anderer Richtung. Wer braucht denn 64 Bit ? Gut, ein Architekt, der komplette Häuserpläne abspeichern muss, der könnte das schon brauchen, oder eben CAD-Anwendungen. Könnte aber auch gut sein, dass es wegen 64 Bit die Datenbank sprengt, neue Rechner gekauft werden müssen etc.

Das letzte mal wars Unicode. Wer braucht das ? Nun ja, wohl etwas mehr Leute, als das 64 Bit. Z.B. Versicherungsvertreter der einem Chinesen Lebensversicherung verkauft. Da wärs vielleicht schon gut, wenn der originale chinesische Name auf der Police steht. Jetzt versetze man sich aber mal in die Lage dieses Versicherungsvertreters. Der sitzt jetzt bei dem Chinesen im Wohnzimmer und soll den original geschriebenen Namen in sein Notebook eingeben. Haha.

Wie hoch ist da jetzt der Anteil der Delphi-Programme, die 64 Bit / Unicode zwingend brauchen ? Wohl <5%.

Es ist ja schon legitim, Anregungen für Erweiterungen/Verbesserungen eines Programmes, also auch für Delphi anzumelden. Aber ehrlich gesagt, mir wärs lieber, wenn sie das Augenmerk mehr auf Verbesserungen legen würden, anstatt dauernd Erweiterungen für relativ kleine Gruppen zu machen. Baustellen gibts ja wirklich noch genug. D8 war aber auch schon genug der Zumutung. Die sollen sich mal besser hinsetzen und sich überlegen, was noch gut wäre, anstatt mit immensem Aufwand eine eierlegende Wolfsmilchsau zu machen, die im Endeffekt doch nicht geht.

Ich kann mir z.B. bis heute nicht erklären, warum sie keinen Compiler-Schalter Für Unicode-Ein/Aus gemacht haben. Einzige Vermutung : Zeitdruck. Werde DavidI in Berlin mal fragen, warum sie das so gemacht haben.

[HeikoAdams]

Das Problem bei Unicode/native x64/Crossplattform dürfte eher sein, das es Konkurrenzprodukte wie z.B. Visual Studio haben. Und damit stellt sich weniger die Frage, ob es jemand wirklich braucht, sondern eher die Frage

Zitat:

Wie erklären wir dem Kunden, das wir Feature XY nicht haben, die Konkurrenz aber schon?

Und abgesehen davon: native x64 und Crossplattform wurden ja bereits mehrmals als Features angekündigt. Sie ohne Begründung weiterhin von einem Release auf das nächste zu verschieben ist auch nicht die feine Art.

[blackfin]

Zitat:

Wie hoch ist da jetzt der Anteil der Delphi-Programme, die 64 Bit / Unicode zwingend brauchen ? Wohl <5%.

Ich sehe das etwas anders. Wie bereits gesagt wurde, kann man mit Delphi derzeit keine Plugins für manche neueren Anwendungen mehr schreiben, da so ziemlich alles derzeit auf 64 Bit umgesattelt wird.
Noch dazu verbreiten sich 64 Bit Systeme wie nie zuvor. Es heisst also, auf kurz oder lang stirbt 32 Bit genauso aus wie damals 16 Bit.
Was würde man sagen, wenn Delphi derzeit nur 16 Bit-Programme erstellen könnte?
Was jedoch am meisten zu Beachten ist, ist die Vorlaufzeit, die ein Entwicklerteam hat.
Es kann schon sein, dass derzeit noch 64Bit-Anwendungen einen sehr geringen Anteil haben.
Was ist aber, wenn ein Entwicklerteam plötzlich muss? Dann kann man schlecht von einem Moment auf den anderen das Programmierwerkzeug wechseln wie die Hose jeden Tag, sondern muss sich schon vorher mit den Werkzeugen vertraut machen.
Das ist es, was die meisten Entwickler wohl am meisten Angst macht: Der Gedanke, ob das derzeitige Zugpferd nicht bald in einer Sackgasse landet und man nicht jetzt schon umsatteln sollte, um nicht irgendwann dazustehen und sagen zu müssen: "Nein, kann ich nicht".

Jetzt kommt sicher das Argument: "Ja, dann benutze halt z.B. C# parallel". Sicher eine Idee, allerdings wird das bei den meisten wohl dazu führen, sich dann von Delphi zu verabschieden, sobald man darin firm ist. Ich denke mal, die meisten verwenden Delphi noch wegen dem persönlichen Erfahrungswert und wegen der relativ grossen Hemmschwelle, alles zu portieren / neu zu lernen. Embarcadero könnte aber diese Leute noch bei sich halten, wenn sie mit ihrem Werkzeug konkurrenzfähig wären. Gehen aber auch diese Leute weg, dann ist Delphi wirklich bald tot.

Und wenn man schon die Relevanz betrachtet...
Was hat höhere Zukunftsaussichten?:

- 64 Bit
- Cross Platform
- Facebook-Support (der Hype könnte nächstes Jahr schon wieder vorbei sein)
- SVN-Integration (SVN ist auch derzeit am Sterben weil schon überholt)

Mir stinkt es ehrlich gesagt langsam gewaltig, immer das Gefühl zu haben, mit einem Oldtimer rumzufahren, der mir als 3-Liter-Auto mit Hybridtechnik verkauft wird, in Wirklichkeit wurde aber ins Armaturenbrett nur ein iPod-Dock eingebaut.

[Bernhard Geyer]

Zitat von Hansa:

Ich muss jetzt auch mal meckern. Aber in etwas anderer Richtung. Wer braucht denn 64 Bit ? Gut, ein Architekt, der komplette Häuserpläne abspeichern muss, der könnte das schon brauchen, oder eben CAD-Anwendungen. Könnte aber auch gut sein, dass es wegen 64 Bit die Datenbank sprengt, neue Rechner gekauft werden müssen etc.

Und was ist mit den Office-Plugins wenn ein 64-Bit MS-Office installiert ist? oder den Windows-Explorer-Plugins auf 64-Bit Systemen. Auch wird in einiger Zeit für IE-User auch die 64-Bit-Version des Browsers standard sein (mus nur noch Adobe nachziehen). dann sind alle Delphi-IE-Plugins tod.
Und dann die ganzen Treiberanbindungen. Oracle installiert bei verwendung von 64-Bit Oracle nur den 64-Bit OCI-Treiber. Also nix mit DB-Zugriff auf Oracle wenn dort der 64-Bit Treiber nur vorliegt (Lässst ich bei oracle aber per Instant-Client + Umgebungsvariable lösen).

Zitat von Hansa:

Jetzt versetze man sich aber mal in die Lage dieses Versicherungsvertreters. Der sitzt jetzt bei dem Chinesen im Wohnzimmer und soll den original geschriebenen Namen in sein Notebook eingeben. Haha.

Ist doch unter Windows seit Jahren keine Problem. Oder glaubst du das alle Chinesen sich nur auf Englisch per Mail/Twitter/... unterhalten? Diese können problemlos chinesischen Text eingeben. Übrigens können chinesiche Texte auch mit alten Delphi-Programmen auf chinesischen Systemen eingegeben werden.

Zitat von Hansa:

Wie hoch ist da jetzt der Anteil der Delphi-Programme, die 64 Bit / Unicode zwingend brauchen ? Wohl <5%.

Ohne Unicode würde es unsere Firma nicht mehr geben. Hatten aber Glück das mit ElPack (und Zeitweise TNTWare) entsprechend Komponenten am Markt waren und wir rechzeitig die Unterstützung begonnen hatten.

Zitat von Hansa:

Aber ehrlich gesagt, mir wärs lieber, wenn sie das Augenmerk mehr auf Verbesserungen legen würden, anstatt dauernd Erweiterungen für relativ kleine Gruppen zu machen. Baustellen gibts ja wirklich noch genug. D8 war aber auch schon genug der Zumutung. Die sollen sich mal besser hinsetzen und sich überlegen, was noch gut wäre, anstatt mit immensem Aufwand eine eierlegende Wolfsmilchsau zu machen, die im Endeffekt doch nicht geht.

Der IDE-Hersteller muß seine Hausaufgaben machen. Das war/ist Unicode/Win64 wenn man noch ein bischen relevanz bezüglich "Beste Windows-IDE" haben will. "Gimicks" wie SVN-Integration (hier reicht eine Tools-API-Interface), sind nicht das was einen Neukauft sinnvoll macht (wer SVN & Co. benötigt hat schon seit Jahren entsprechende Lösungen im Einsatz).

Zitat von Hansa:

Ich kann mir z.B. bis heute nicht erklären, warum sie keinen Compiler-Schalter Für Unicode-Ein/Aus gemacht haben. Einzige Vermutung : Zeitdruck. Werde DavidI in Berlin mal fragen, warum sie das so gemacht haben.

Wurde doch schon öfter erklärt. Ich sehe auch keine notwendigkeit dafür. Einfach darauf aufpassen das der Code vernünftig implementiert ist dann gibt es auch keine größeren Problem mit dem Port nach D2009/2010.