Delphi 13 Florence wurde veröffentlicht

**Sinspin**

Erstmal

, weil der TE hier mal ganz anders auftritt als sonst. Geht doch

!

Weniger kann auch mal mehr sein. Wenn bei weniger, der eingedellte Kotflügel ab ist der am Rad geschliffen hat, dann nehme ich das Auto auch so zur Erfüllung seines Zwecks.
Eine ordentlich stabil funktionierende IDE ist auf jeden Fall eine feine Sache. Dazu noch ein stabil laufender Debugger und ich bin fast zufrieden.

...fast zufrieden, denn ich kann seit anbeginn meiner Zeit mit Delphi (D4) nicht verstehen warum es mehr als eine IDE Lizenz gibt!
Warum sind die Komponenten nicht separat? War das nicht der Grund warum man sich für Packages entschieden hat?
Dann könnte man die Komponenten und die IDE separat vermarkten und auch aktualisieren.

Für alle die ihre Software nur inhouse einsetzen und keine vorkompilierten Komponenten verwenden ist FPC/Lazarus schon jetzt eine alternative.
Ich hatte auf der Pascalconferenz die Chance die neuste Lazarusversion anfassen zu können. Da fehlt mir nichts mehr außer die Komponenten einiger Hersteller.

**himitsu**

Also bezüglich FMX sehe ich auch in der 13 noch schöne Bugs.
* beschissener extrem unoptimaler Code
* unsicherer Code
* und mehrere Stellen knallen (da hätte ein if-Assigned bestimmt geholfen)
* die FMX-Styles wurden teilweise überarbeitet ... sie stehen aber immernoch auf Version 1.0 ... werd diese Woche dann bestimmt mal sehen, was sich da wirklich geändert hat (falls ich Zeit finde)
* ...

Der Debugger ist schlechter, als 12.3
Eine Exception im OnCreate der Form, da tauchen die Event-Methode und Andere nicht im Stack auf (dachte erst da knallt was beim DFM-Laden weg)

**Cypheros**

Zitat von DeddyH:

P.S.: Auch wenn Ian Barker etwas anderes sagt/sagen muss: wenn das so weitergeht, ist Delphi mittelfristig wirklich tot. Den Nachwuchsbereich hat man durch frühere Entscheidungen wahrscheinlich komplett verloren, d.h. wenn wir alten Säcke demnächst in Rente gehen, interessiert sich niemand mehr für das Produkt. Man versuche doch nur mal, eine beliebige verbreitete aktuelle Bibliothek einzubinden. Da bekommt man Code für C#, Rust, Python und teilweise sogar für Sprachen, von denen ich nie gehört habe, aber nichts in Pascal. Daraus kann man den Stellenwert von Delphi im Rest der Welt ganz gut ableiten, finde ich, daran ändert auch der Tiobe-Index nichts.

Das würde ich nicht ganz so negativ sehen. Delphi stammt aus einer Zeit, als das Delphi-Wissen noch in Foren/Newsgroups verbreitet wurde. Diese Foren/Newsgroups sterben aber seit einigen Jahren Stück für Stück und damit geht viel "Sichtbarkeit" verloren. C#, Rust, Python sind "relativ" neue Sprachen, die besonders für den aktuellen Hype um KI genutzt werden und darum sehr präsent sind.

Da Source-Code auf Github und andere Open-Source Hoster offenbar nicht mehr richtig geindext wird, findet man Delphi Sourcecode nicht mehr so einfach über die Google/Bing-Suche wie früher. Vor ein paar Jahren konnte man eine Codezeile bei Google eingeben und man bekam eine Liste, wo exakt diese Codezeile vorkam. Das funktioniert aber nicht mehr und die Google/Bing-Suche ist für Sourcecode nahezu unbrauchbar geworden.

https://www.google.com/search?q="unp...ame.format));" sollte eigendlich Zeile 180 in

https://github.com/DelphiForBroadcas...g/demuxing.dpr finden, tut es aber nicht mehr.

Das gilt auch für Bing und Co.

Doch wenn man wirklich schau, gibt es auf Github wirklich sehr viel Delphi-Code:

https://github.com/search?q=delphi&type=repositories

Leider ist Embarcadero seit einiger Zeit sehr träge geworden und Delphi rennt den Trends hinterher, statt Schritt zu halten. Der Versuch alle wichtigen Betriebssysteme (Windows, MacOS, IOS, Android, Linux) über eine Entwicklungsumgebung bedienen zu wollen, ist möglicherweise zu aufwendig. Wenn man schau, wie schnell sich allein die mobilen Betriebssysteme weiterentwickeln, da wird einem schwindelig.

IDE, Debugger und Windows sind von der Priorität leider offenbar recht weit unten.

**johndoe049**

Zitat von stahli:

1)

3)

Wie ist denn eigentlich der Stand mit FastReports und der Lizensierung?
Dürfte man jetzt mit der in GetIt enthaltenen Emba-Version z.B. eine kommerzielle Kundenverwaltung verkaufen?

Da wir FastReport nicht mehr verwenden, unsere letzten Erfahrungen mit der GetIt Version für 12.2:

Bei der GetIt Version ist der Endkunden-Designer nicht dabei. Dafür will FastReport immer noch eine extra OEM Lizenzierung. D.h. man kann mit der Version die Reports nur innerhalb
der IDE Editieren/Erstellen.

**johndoe049**

Zitat von Sinspin:

Für alle die ihre Software nur inhouse einsetzen und keine vorkompilierten Komponenten verwenden ist FPC/Lazarus schon jetzt eine alternative.
Ich hatte auf der Pascalconferenz die Chance die neuste Lazarusversion anfassen zu können. Da fehlt mir nichts mehr außer die Komponenten einiger Hersteller.

Lazarus hat im Moment mit dem Forum ein Problem. Die hatten zuviele Bots und versuchen die auszuschließen. Dabei schließen die auch einige reguläre Benutzer aus.

Die haben auch Ihre Baustellen.

**fisipjm**

Zitat von Cypheros:

Doch wenn man wirklich schau, gibt es auf Github wirklich sehr viel Delphi-Code:

https://github.com/search?q=delphi&type=repositories

Das kommt auf die Perspektive an. Im Vergleich zu nix sind 21.6k schon recht viel aber die Realität sieht halt so aus:

Cobol = 7.400
Delphi = 21.600
Flutter = 901.000
Python = 5.400.000
React = 6.400.000

**DeddyH**

Ich habe nicht gesagt, dass es keine Bibliotheken für Delphi gibt, sondern dass deren Hersteller Delphi meist nicht mehr berücksichtigen. Natürlich gibt es Enthusiasten, die sich die Mühe der Übersetzung machen und diese dann freundlicherweise auch veröffentlichen, das sind aber meistens keine Mitarbeiter der Herstellerfirma. Was bedeutet, dass die Delphi-Übersetzungen dann wieder zwangsweise hinterherhinken, weil sie ja erst wieder aktualisiert werden müssen. Und wenn das wie in vielen Fällen nur eine Einzelperson macht, ist die Gefahr groß, dass diese irgendwann keine Lust mehr hat oder aus anderen Gründen die Arbeit einstellt.

**cltom**

Spannende Diskussion, die zur Frage führt: was ist die Strategie für Delphi, die weiter reicht als das Melken von Legacy-Projekten und die Zuwendung durch eine (Verzeihung vorweg, schließe mich ein) gealterte Generation? Man kann das Bemühen erkennen, dass man die Begeisterung in Delphi mit Webinaren und dergleichen hoch hält. So ganz klar ist mir aber die Zielgruppe da nicht und auch fehlt mir die Konsistenz.

Was Delphi an Vorteilen mitbringt ist vermutlichen allen hier besser bewusst, als mir, das braucht wohl keine Aufzählung. Was mir aber nicht klar ist, warum man ein paar Themen nicht aktiv adressiert:

- Wenn man sich schon zu einer Community-Edition entschließt, um neue Entwickler einzuladen, warum lässt man die dann immer hinterher hinken? Warum kommt nicht eisern mit Erscheinen einer neuen bezahlten Version auch die Community heraus? Und die kann man dann auch einfach installiert lassen, die läuft nicht ab, die kann man sogar einfach auf die neue Version aktualisieren.

- Es gibt zahlreiche Webinare von Embarcadero, ich hab viele davon angesehen. Ich persönlich (!) kann den Sinn dahinter nur bedingt verstehen. Ja, die sollen Begeisterung versprühen, aber ein Raumschiff-Enterprise-UI in Ehren, das denke ich bringt wenigen Nutzern viel. Wenn ich neue Entwickler ansprechen will, dann wäre das doch ein schöner Weg, gute Projekte umzusetzen. Die Idee ist: Delphi ist ein schönes Werkzeug, um schnell Applikationen mit herzeigbarer UI bauen. Also, zeige ich genau das: Wie baue ich gute funktionstüchtige Applikationen in einer Tiefe, dass dabei sinnhafte Applikationen herauskommen. Wenn ich bei mir in der Firma anschaue, wie Leute mit Begeisterung Low-Code-Tools propagieren, weil man da Buttons ganz einfach auf die UI ziehen kann ... meine Güte - alles da, seit 30 Jahren!

Konkret wären folgende Formate interessant (frei dahingesponnen):
- An application in less than one hour. Eine Stunde, eine Applikation, die was Sinnhaftes macht. Rapid Application Development. Kein Furz-Showcase, der nichts bewirkt. Irgendwas Zählbares. Wenn ich denke, wie viele gute Tutorials es für andere Applikationen gibt, wo Leute in deutlich wenig Zeit irre gute Ergebnisse erzielen. Das schafft Begeisterung für eine Plattform. Da braucht man nicht bei der Installation anfangen oder beim Runterladen einer Komponente oder beim Aufzählen von Vorteilen für die Plattform. Das kommt dann intrinsisch, wenn nach den ersten 10 Minuten eine Oberfläche fertig ist, die was kann und die Datenbank-Verbindung auch schon steht.

- Business Case Development: größere Projekte in mehreren Teilen, in denen gezeigt wird, wie man ein größeres Projekt angeht mit allen typischen Anforderungen: Datenbanken, Reporting, Charts, Office-Export, etc. Aber eben zu einem kohärenten gesamten Bild. Wie baue ich das auf? Wie trenne ich Business-Logik und UI? Wie krieg ich meine Klassen ins Reporting, in Charts und in Excel-Dateien? Ganz konkret anhand typischer Anwendungsfälle.

Wenn ich selber nur Code produzieren könnte, den man herzeigen kann ...

- Es gibt bestimmt Analysen dazu, vermutlich liege ich falsch: aber tut man sich mit den drei Versionen wirklich einen Gefallen? Braucht es wirklich Profession/Enterprise/Architect? Gerade mit der Unterscheidung von Professional und Enterprise hadere ich. Ergibt das echt Sinn? Aus der Historie heraus, dass Delphi stark mit Datenbanken ist, ja, verständlich, dass gewisse Features in eine höhere Bezahlschranke verschoben werden, aber auch nein, wäre es nicht schick, wenn eine Delphi-Version einfach alles mitbringt, insbesondere in der Kernstärke Datenbanken?

- Warum gibt es noch immer keinen Installer, der einem bei der Installation die Wahl lässt: Upgrade der existierenden Version oder Parallel-Installation inkl. Anpassen der Path-Einstellungen.

- Es gibt zahlreiche gute Komponenten. Die hängen oft an Einzelpersonen. Fair enough. Das ist nicht Delphi-spezifisch. Aber könnte man es nicht zu einer Delphi-spezifischen Stärke machen, indem man Entwickler auf die ein oder andere Weise miteinbindet? Bei Skia ist es zuletzt passiert, dass man eine Komponente eingebunden hat. Das mag eine Variante sein. Ich weiß nicht, wie man das kommerziell gelöst hat. Aber wär das nicht ein Feld, wo beide (engagierte Komponenten-Schreiber) und Embarcadero gewinnen könnten? Die Plattform kriegt hochwertige Komponenten, der Entwickler eine Plattform. Das ist nicht zu Ende gedacht, es kann und muss nicht jede Komponente zu Embarcadero wandern. Aber Fakt ist, dass das Potential ist, aus einer fragmentierten Landschaft das beste herauszuholen. Die Vision kann ja durchaus sein: die hochwertigsten Packages reinholen und damit den Lieferumfang von Delphi ständig verbessern. Eine gute Reporing-Komponente, eine Chart-Komponente, ... alles unter dem Titel, Applikationsentwicklung einfach und angenehm zu machen.

Was denkt ihr?

**jaenicke**

Zitat von Sinspin:

Für alle die ihre Software nur inhouse einsetzen und keine vorkompilierten Komponenten verwenden ist FPC/Lazarus schon jetzt eine alternative.
Ich hatte auf der Pascalconferenz die Chance die neuste Lazarusversion anfassen zu können. Da fehlt mir nichts mehr außer die Komponenten einiger Hersteller.

Wenn man einfach nur alten Pascalcode schreibt, ist das kein Problem. Da ich z.B. sehr gerne Generics einsetze, um deutlich kürzeren und übersichtlicheren Code zu schreiben, müsste ich bei FPC schon einige Kröten futtern.

Mag sein, dass der generierte Code am Ende besser ist, aber wenn ich immer wieder tausende Zeilen Code zusätzlich schreiben muss, der auch noch deutlich unübersichtlicher ist, dann ist das für mich nicht erstrebenswert. Und ich finde es schade, dass die aktuelle Qualität bei Delphi dazu führt, dass es bei vielen in diese Richtung geht.

Bei Generics ist der Featureumfang bei Delphi dank umfangreicher constraints usw. sehr gut (auch wenn mir constraint propagation massiv fehlt). Und da gibt es ja auch neue Features mit Delphi 13, die interessant klingen.

**stahli**

Zitat von cltom:

Konkret wären folgende Formate interessant (frei dahingesponnen):
- An application in less than one hour. Eine Stunde, eine Applikation, die was Sinnhaftes macht. Rapid Application Development. Kein Furz-Showcase, der nichts bewirkt. Irgendwas Zählbares. Wenn ich denke, wie viele gute Tutorials es für andere Applikationen gibt, wo Leute in deutlich wenig Zeit irre gute Ergebnisse erzielen. Das schafft Begeisterung für eine Plattform. Da braucht man nicht bei der Installation anfangen oder beim Runterladen einer Komponente oder beim Aufzählen von Vorteilen für die Plattform. Das kommt dann intrinsisch, wenn nach den ersten 10 Minuten eine Oberfläche fertig ist, die was kann und die Datenbank-Verbindung auch schon steht.

- Business Case Development: größere Projekte in mehreren Teilen, in denen gezeigt wird, wie man ein größeres Projekt angeht mit allen typischen Anforderungen: Datenbanken, Reporting, Charts, Office-Export, etc. Aber eben zu einem kohärenten gesamten Bild. Wie baue ich das auf? Wie trenne ich Business-Logik und UI? Wie krieg ich meine Klassen ins Reporting, in Charts und in Excel-Dateien? Ganz konkret anhand typischer Anwendungsfälle.

Genau das hatte ich mir vor Jahren schon mal gewünscht als hier Trennung von GUI und Logik öfter Thema war.
Deshalb hatte ich mir weiter oben auch eine Fortsetzung von Olfs Datenbankvideo gewünscht, um ein paar praktische Tipps zu erhalten, wie andere etwas lösen.

Zitat von cltom:

- Es gibt zahlreiche gute Komponenten. Die hängen oft an Einzelpersonen. Fair enough. Das ist nicht Delphi-spezifisch. Aber könnte man es nicht zu einer Delphi-spezifischen Stärke machen, indem man Entwickler auf die ein oder andere Weise miteinbindet? Bei Skia ist es zuletzt passiert, dass man eine Komponente eingebunden hat. Das mag eine Variante sein. Ich weiß nicht, wie man das kommerziell gelöst hat. Aber wär das nicht ein Feld, wo beide (engagierte Komponenten-Schreiber) und Embarcadero gewinnen könnten? Die Plattform kriegt hochwertige Komponenten, der Entwickler eine Plattform. Das ist nicht zu Ende gedacht, es kann und muss nicht jede Komponente zu Embarcadero wandern. Aber Fakt ist, dass das Potential ist, aus einer fragmentierten Landschaft das beste herauszuholen. Die Vision kann ja durchaus sein: die hochwertigsten Packages reinholen und damit den Lieferumfang von Delphi ständig verbessern. Eine gute Reporing-Komponente, eine Chart-Komponente, ... alles unter dem Titel, Applikationsentwicklung einfach und angenehm zu machen.

Was denkt ihr?

Auch das finde ich wichtig. Offenbar bestehen erhebliche Unklarheiten, wie z.B. die Stabilität und Lizenzen der Reportkomponenten einzuordnen sind.
Emba sollte hier klare und stabile Verhältnisse schaffen, auf die man sich verlassen kann. Ein Reportgenerator gehört m.E. zu den zwingenden Bestandteilen eines Entwicklungswerkzeugs.
Wenn jemand sich für eine Alternative entscheidet, ist das natürlich kein Problem.
Aber Delphi sollte eine wenigstens grundlegende, stabile und lizenztechnisch saubere Lösung an Bord haben.