Wie weiter mit Delphi?

[Bernhard Geyer]

Zitat von Der schöne Günther:

Zitat:

- Keine AnsiStrings mehr
- Zero based string
- ARC

Die Welt ist schon verrückt. Du willst es als zu vermeidende Verschlechterungen darstellen und ich denke mir nur "Ja, bitte. Ich möchte es."

DITO.
AnsiString -> Nur noch bei noch nicht umgestellten Altlasten
Zero Based String -> Stört das irgenwo? Nur wenn man AnsiString als "einfache Alternative" zu richtigen Streams oder Buffern nicht (hatte ich auch mal bei D2 im Einsatz).
ARC: Cool. Endlich kann man (mehr) der Vorteile genießen die man unter .NET und Java schon lange hat.

[Bambini]

Zitat von Bernhard Geyer:

AnsiString -> Nur noch bei noch nicht umgestellten Altlasten

AnsiString sind nicht zu verwechseln mit ShortString. ANSI ist noch sehr gängig und keine Altlast.

Zitat von Bernhard Geyer:

Zero Based String -> Stört das irgenwo?

Delphi-Quellcode:

   AString := '12345';
   AString[1] := 'X ';
   // unter bisherigen Delphi sieht der String dannach so aus 'X2345'
   // mit ZBS so: '1X345';

Es gibt kein Compiler Error oder Laufzeitfehler, man muss seinen Code genau debugger um so etwas zu finden.

Zitat von Bernhard Geyer:

ARC: Cool. Endlich kann man (mehr) der Vorteile genießen die man unter .NET und Java schon lange hat.

Per se nicht schlecht. Für bestehenden Code bringt das jede Menge Nebeneffekte mit. Alleine das neue FMX Framework hat 3 Delphi Versionen gebaucht um alleine eine erzeugte TForm wieder freigeben zu können. Um die VCL ARC kompatible zu bekommen wäre gewaltige Änderungen notwendig. Und nach dem ganzen Ärger hat man was davon?

[Union]

Zitat von Bambini:

Und nach dem ganzen Ärger hat man was davon?

Keine endlosen try..finally Orgien mehr, tolles Arbeiten ohne Free. Aber problematisches Eingreifen, falls man doch mal ein Dispose braucht sowie geringere Peformance. Dafür kann man das dann dem IoT in die Schuhe schieben.

[p80286]

Zitat von Bernhard Geyer:

Zitat von p80286:

Mir sind Strings, die durch das Auftauchen von x00 beendet werden sehr suspekt.

Auch unter "alten" Delphi kannst du String die ein #0 beinhalten auch nur sehr eingeschränkt werden.

Aus den Anfangszeiten der Ansistrings hab ich da noch ein paar "Strings" Eijeijei... (damals war String die Möglichkeit beliebige Daten zu handhaben)

Zitat von Bernhard Geyer:

Alles was zur WinAPI geht wird bei #0 abschneiden.

Und wenn's nicht dahin geht, dann kann man sich benehmen wie eine Wildsau.

Aber das wirklich nur nebenbei, was aus solchen Tricksereien wird, erleben wir ja tagtäglich bei den Fragen nach Unicode und verkürzter Ausgabe und und .....

Gruß
K-H

[Rollo62]

Hallo oldprog,

wenn du mal über den Rand schaust wirst du sehen das andere Sprachen und IDEs sich viel massiver ändern als Delphi und Firemonkey (Javascript, Xcode/Swift, C#/Xamarin, Java/Eclipse/Netbeans/IntelliJ, etc. etc.).
Da geht es doch bei Delphi eher gemächlich zu.

Das Problem ist nur das Embarcadero dafür regelmäßig Geld möchte, um mit dem Tempo der Welt da draussen mitzuhalten
(iOS 6-9, Android 2.3-5.1, Win XP/7,8,8.1,10, WinRT, MaxOS, und hoffentlich bald mehr.).

Entweder du beisst in den sauren Apfel, oder die XE2 wird sehr bald überholt sein (wenn nicht schon jetzt).
Ich würde dir zumindest nehelegen wenigstens nochmal bis XE7 oder XE8 mit Upd1 zu investieren, da sind dann
schon alle Neuigkeiten drin die bis auf Weiteres noch etwas halten werden, XE2 ist schon recht betagt.
Du solltest nur sicher sein XE8 mit Upd1 zu bekommen, weil XE8 für mich extrem buggy war (allerdings unter Firemonkey,
am Besten selber Testen undter VCL).
Wie gesagt besser mal vorher Testen, denn die Umstellung XE2 XE7 ist schon ein Kraftakt bei größeren Projekten.
Ist recht einfach, aber man hat halt an vielen Stellen im Code mit Änderungen zu tun.

Ansonsten bleibt Lazarus, ist auch nicht das Schlechteste.

Rollo

[mensch72]

ich finde die aktuelle Delphi Entwicklungsrichtung gut, denn ich komme von "C/C++"

Pascal ohne TBytes nur mit Strings(ab 1) ist für mich bisher ehr "anstrengend". Ist hier halt ein PascalForum und da kommt NullBasiert und NullTerminiert wohl nicht so gut

Wie heißt es so schön: Die Mehrheit hat recht und es gibt nun mal mehr nicht PascalUmgebungen, welche fix mit [0] anfangen und wenn die Sprache Pointer unterstützt, dann auch Pointer auf Variable = Adresse Element[0] ist...

Ich nehme auch noch gerne XE2 in einer VM. Das wurde noch richtig gepflegt und läuft im letztem UpdateRelease für Win32 incl. der Hausladen-Patches bei mir sehr stabil.
Die aus meiner Sicht erste "brauchbare" Version für Mobile(Android) war XE5... bis Android4.4 kann man per FMX damit gut Mobile was machen.

Aktuell geht XE8u1 auch für Android 5.1 und XCode6.4 (noch). Aber es fühlt sich alles gegen XE5 schon recht träge an. Schön in XE7/XE8 ist die nun einfache Integration von nativ Klassen (bei Android z.B. per externer JARs). Für Apple IOS9 und Android "nicht ARM" kommt hoffentlich im September mit XE9 eine Lösung.

Zurück zum Thema:
- ich bin für "nonUniCode" bei D2007, sonst für Win32 wenn es reicht bei XE2 und bei Mobile (noch)XE5 oder XE8u1, aber mit dem Ziel XE9.
- ich habe Subscription und teils auch die Delphi Betas... die (Zeit)Kosten der ständigen internen Tests neuer XE? Releases/Updates sind viel höher als die paar Euro für die Subscription... ich buche da sogar einiges an Zeit auf "Test/Neugier/privat", weil ich solche Kosten einfach nicht plausibel in Bestandsprojekten unterbringen kann.
- mit Komponenten(Packs) wie die von TMSsoftware reicht auch bei Win10 noch ein D2007 oder XE2 für Win32/VCL Projekte
- als Rentner/Schüler... ich würde ganz frech mich in einer VHS auf irgendeinen IT Kurs anmelden und mir eine XE? Schulversion holen. Die kosten fast nix und man kann zwar alles machen, darf es nur nicht verwenden... aber zum Test "was geht" allemal besser als Raubkopien. Wenn sich was kommerziell gutes ergibt, kann man ja eine neue "richtige" PRO Version samt Subskription mit einkalkulieren... also wenn nochmal XE? als was neues dann wäre diese Variante wohl mein Weg

[oldprog]

Zitat von Rollo62:

wenn du mal über den Rand schaust wirst du sehen das andere Sprachen und IDEs sich viel massiver ändern als Delphi und Firemonkey (Javascript, Xcode/Swift, C#/Xamarin, Java/Eclipse/Netbeans/IntelliJ, etc. etc.).
Da geht es doch bei Delphi eher gemächlich zu.

Das Problem ist nur das Embarcadero dafür regelmäßig Geld möchte, um mit dem Tempo der Welt da draussen mitzuhalten
(iOS 6-9, Android 2.3-5.1, Win XP/7,8,8.1,10, WinRT, MaxOS, und hoffentlich bald mehr.).

Ansonsten bleibt Lazarus, ist auch nicht das Schlechteste.

Rollo

Zitat von Lemmy:

Also: Bleib bei XE2 und schau dir in deiner Freizeit andere Programmiersprachen an - auch wenn die anfänglich nicht so doll aussehen - die schönen Dinge offenbaren sich meistens dann, wenn man die erste Hürden überwunden hat - und seltsamer weise will man die dann nicht mehr missen und findet Delphi auf einmal nicht mehr ganz so doll..

Ich hatte ja bereits geschrieben, dass ich am Ende einer über 50 jährigen Programmierer Laufbahn stehe. Davon die letzten 25 Jahre als Freiberufler.
In meinem Berufsleben habe ich eine Vielzahl von Sprachen verwendet und produktiv eingesetzt.
Eine lose Auswahl der verwendeten Programmiersprachen etwa in zeitlicher Reihenfolge.
MOPS, Assembler, Algol, Fortran. Diplomarbeit in PL/1. Forth, PL/M, Sios, Dbase, C, Turbopascal, Delphi, Modula, Step5, Structurierter Text, Dot.net.
Die Behauptung kennt man eine Sprache, dann kennt man alle, ist prinzipiell ja richtig.
Was aber gerne übersehen wird, zu den meisten hier aufgezählten Sprachen gehört ein Ökosystem bzw. eine Infrastruktur. Was wäre Delphi ohne die VCL und IDE ? Und der Lernaufwand von VCL zu z.B. WPF ist auch nicht zu unterschätzen.
Der eigentliche Aufwand besteht nicht im Erlernen der Sprache, sondern im Beherrschen der Infostruktur. Nach meiner Erfahrung so um ein Jahr, ehe ich eine neue Sprache produktiv einsetzen kann.
In den 80. Jahren war Turbopascal die erste Entwicklungsumgebung, die ein effektives Arbeiten ermöglichte. (64 kbyte Hauptspeicher, davon 32 Kb für Test frei. 16 Kb für Overlays.
Delphi hat diese Entwicklung rasant fortgesetzt. Etwa bis zu dem Zeitpunkt, wo die Entwickler von Mikrosoft abgeworben wurden.
Seit dem Zeitpunkt mehr oder weniger Stagnation. Man hat den Eindruck, dass die Prozesse nicht mehr komplett beherrscht werden.
Wenn ich trotzdem bei Delphi geblieben bin, dann nicht aus Liebe zu Delphi oder Sympathie für die Entwickler, sondern aus reinen Sachzwängen.
Mehrere Millionen Quellzeilen Delphi – Code stellt man nicht mal so auf eine andere Sprache um.
Letztendlich habe ich das gleiche Programm mit neuen und alten Fehlern in einer anderen Sprache.
Für den Kunden null Mehrwert. Von den immensen Kosten, die keiner bezahlt, gar nicht zu reden.
So wie es aussieht, werde ich wohl meine Entwicklung auf dem Stand XE2 einfrieren und neue Programme mit VS2015 beginnen.

[Rollo62]

Sehe ich ja auch so, und die Sprache bedeutet letztendlich nichts, wenn das Framework dazu fehlt.

Deshalb bin ich der Meinung das FMX die natürliche Ergänzung zu VCL ist, weil weitgehend kompatibel und MultiPlatform.
Ich denke das FMX die Zukunft ist, und hoffentlich bleibt Embarcadero auf dieser harten Linie auch wenn sich die meisten damit noch nicht anfreunden können.

Aber ich sehe VCL ganz klar Windows (XP-8), ob es in Zukunft damit auch noch bei Universal app funktionier muss man sehen, bezweifele ich aber stark.
Ob wir wollen oder nicht läuft Microsoft den Bach runter (bitte jetzt keine Argumente wie super es Windows geht).
Die Zukunft ist Tablet/Phone/Phablet, auch wenn meinetwegen noch 80% auf Windows laufen sollte.

Aber an den letzten 20% kommt keiner Vorbei, irgendwann kommt die Frage wie bekomme ich das aufs Tablet ?

Dann kann ich entweder eine komplett andere Umgebung nutzen (Xamarin, Java, Unity3D, was auch immer).
Mit FMX hat man aber den echten, handfesten Vorteil das man erstmal einen Weg zu allen Plattformen unter Delphi offen hat.

Ja, es ist noch nicht 100% stabil, ja es ist nicht nativ (zum Glück, sonst hätte man noch mehr Probleme), ja es könnte manchmal performanter sein, etc. etc.
Aber ich kann erstmal meine Anwendung damit entwickeln.

Das wollte ich nur anregen, das du eine Version als Letztes mitnehmen solltest welche FMX noch möglichst weit in die Zukunft unterstützt (also XE8+).
VCL gibt es da ja auch noch in voller Unterstützung, und ich denke da geht es auch noch lange mit weiter.
Aber was in Delphi kommen wird hängt zunehmend von MS, Apple und Google ab.

Zitat:

So wie es aussieht, werde ich wohl meine Entwicklung auf dem Stand XE2 einfrieren und neue Programme mit VS2015 beginnen.

Ich hatte verstanden das du in die verdiente Rente gehen wolltest, und keinen Fulltimejob


Rollo

[stahli]

Zitat von Rollo62:

Das wollte ich nur anregen, das du eine Version als Letztes mitnehmen solltest welche FMX noch möglichst weit in die Zukunft unterstützt (also XE8+).

Das wird nicht viel bringen. Entweder man nutzt laufend die Subscription oder man ist ganz schnell raus. 5-6 Monate mehr nützen da auch nicht viel.
Eine Investition in XE8 würde ich nicht für sinnvoll halten. Dann könnte er auch in einem Jahr XE9 oder 10 oder später 11 kaufen...

[Bambini]

Zitat von Union:

Zitat von Bambini:

Und nach dem ganzen Ärger hat man was davon?

Keine endlosen try..finally Orgien mehr, tolles Arbeiten ohne Free. Aber problematisches Eingreifen, falls man doch mal ein Dispose braucht sowie geringere Peformance. Dafür kann man das dann dem IoT in die Schuhe schieben.

Das "ohne Free" ist schick, die Einfachheit hört dann aber sehr schnell außerhalb der procedure wieder auf
wenn Referenzen nicht [weak] oder crossover deklariert sind, bleiben die Objekt einfach am Leben. Die Suche wird schnell komplex wenn auch noch dritte Libraries verwendet werden ... vielleicht sogar ohne Source.
Fazit: Try...finally ist gar nicht so schlecht.