Sind wir veraltet?

[ggscholz]

Wenn man sich die Statistik dieses Forums ansieht, scheint es offensichtlich, das es neben Delphi vieles anderes gibt. Gegenüber 2005 sind hier nur 10% engagiert. Die Programmierer würde ich sagen, werden eher nicht weniger geworden sein, sie sind aber in anderen Sprachen unterwegs.
Die hier ja wirklich mit viel Engagement und Sachverstand geschriebenen Beiträge und der neue Tread zur vorhandenen oder nicht vorhandenen Roadmap https://www.delphipraxis.net/members...7-ronaldk.html würde ich als Aufhänger für eine Einladung an Embarcadero nutzen, sich auf den geplanten Delphi Forum Tagen der Diskussion zu stellen.
Irgendwie wird Emba sich ja auch mit den Anforderungen aktueller Betriebssystemen und Geräten auseinander setzen und wissen, für wen sie in Zukunft Delphi als Programmierwerkzeug sehen.

Grüße Gerd

[Stevie]

Zitat:

Zitat von ggscholz (Beitrag 1524606)

eine Einladung an Embarcadero nutzen, sich auf den geplanten Delphi Forum Tagen der Diskussion zu stellen.

Es werden doch eh die üblichen Verdächtigen von Embarcadero Deutschland anwesend sein, die sind aber nicht verantwortlich, und können auch nur beschwichtigen und "wir werden das Feedback weiterleiten" antworten.

[ernschd]

Ich würde an der Stelle mal meinen Senf dazu geben. Ich habe "erst" 2007 mit Delphi angefangen (damals mit Delphi 2007) und benutze es immer noch. Aktuell verwenden wir ein älteres Delphi 10.
Daneben arbeite ich an unserer Website - dort wird der Code mit Visual Studio Code geschrieben (und diversen Plugins), und seitdem bin ich jedes mal erstaunt, wie langsam und träge Delphi dagegen wirkt.
Würde Embarcadero eine schnelle, moderne IDE auf den Markt bringen, die die bereits mehrfach angesprochene Plattformunabhängigkeit mitbringt, könnte es möglicherweise die jüngeren Kollegen dazu bringen, sich Delphi anzuschauen. Ich denke, die Sprache an sich ist nicht das Problem, sondern eher das Werkzeug.

[freimatz]

schnelle, moderne IDE? Ich wäre froh die würde einfach mal einigermassen funktionieren bei uns. :evil:

[jaenicke]

Zitat:

Zitat von ernschd (Beitrag 1524608)

dort wird der Code mit Visual Studio Code geschrieben (und diversen Plugins), und seitdem bin ich jedes mal erstaunt, wie langsam und träge Delphi dagegen wirkt.

Mit Visual Studio Code kann man übrigens auch Delphi-Code schreiben:
https://marketplace.visualstudio.com...gies.delphilsp

Zitat:

Zitat von ernschd (Beitrag 1524608)

Würde Embarcadero eine schnelle, moderne IDE auf den Markt bringen, die die bereits mehrfach angesprochene Plattformunabhängigkeit mitbringt, könnte es möglicherweise die jüngeren Kollegen dazu bringen, sich Delphi anzuschauen. Ich denke, die Sprache an sich ist nicht das Problem, sondern eher das Werkzeug.

Ja, leider ist die IDE immer noch nicht gut, so sehr bei diversen Releases betont wurde, dass man sich dort auf Fehlerbehebung konzentriert. Die Probleme mit Code Insight / LSP sind nur die offensichtlichsten, aber es gibt ja noch einige andere (Refactoring, ...).

Das in Kombination mit diversen konstruktions- und qualitätsbedingten Problemen in neueren VCL- und RTL-Quelltexten (nicht oder schlecht nutzbare Funktionalität, fehlende Kapselung, fast schon Spaghetticode teilweise, ...) macht leider keinen guten Eindruck. Leider hat man an manchen Stellen keine Wahl als die komplette Klasse oder Unit zu kopieren und zu korrigieren oder mit Hooks und anderen Tricks zu arbeiten, nur damit die vorgesehene Funktionalität möglich ist. Und man sitzt dann davor und denkt nur noch: "Wie um alles in der Welt kann man auch nur auf die Idee kommen das so umzusetzen?"

Ein Beispiel:
Die CustomTitleBar. Da kann man eigene Buttons definieren, bekommt aber keinen Zugriff auf die Positionen der Buttons. Man kann also andere Controls nicht ohne Tricks daneben platzieren. Denn man bekommt nur ein paar wenige Informationen, der Rest ist nur in dem Buttonobjekt selbst drin und das steht unter protected. Das Buttonobjekt bekommt man im OnPaint als Sender übergeben. Die Ermittlung der Darstellungsinformationen wie die Farben ist aber nicht gekapselt, sondern stattdessen sind die Zeichenroutinen in überlangen unstrukturierten Methoden untergebracht. Ich sage nur "separation of concern", "clean code" Prinzipien, was früher auch mal in den RTL- und VCL-Quellcodes beachtet wurde. Jedenfalls kommt man an diese ermittelten Farben nicht ohne Tricks heran, so dass man den Code im Grunde kopieren muss, damit die Buttons genauso aussehen. Ach ja, die Custom Buttons sind übrigens einen Pixel höher als die anderen Buttons.
Dazu kommt, dass die Standard-Buttons sich nur deshalb korrekt verhalten, weil diese das Fenster manipulieren. Wenn man aber etwas anderes auslöst, klappt schon der Hovereffekt usw. nicht mehr korrekt.
Ach ja, und die Colormap vergisst manchmal plötzlich alle Farben, so dass ich diese im Quelltext setzen muss.

Wie habe ich es korrigiert? Ich habe die Instanz der CustomTitleBar über den Schreibtrick auf Properties ohne Getter ausgetauscht und bekomme so z.B. das Rechteck, in dem sich die Buttons befinden. Und ich greife über den üblichen Trick auf die Protected-Elemente zu. Und noch ein paar andere Sachen...
Wenn das nun alles funktioniert, kann ich mal schauen, wofür es schon Quality-Einträge gibt.

Die Titelleiste der Delphi-IDE hat diese Probleme alle nicht, aber offensichtlich wurde nicht die gleiche Komponente auch veröffentlicht. So funktioniert dann auch "eat your own dog food" nicht.

Ich mag Delphi, aber wenn ich andere Sprachen nutze, mögen zwar manche IDEs weniger Features haben, aber sie laufen sehr viel stabiler und schneller. Leider.

[Codehunter]

Wenn man mal die oben erwähnte 10% Statistik bedenkt, wird das bei den Kundenzahlen von Emba wohl so ähnlich sein. Entsprechend viel - oder wenig - wird dann noch in die Verbesserung gesteckt werden. Die letzten großen Updates enthielten so wenig für unsere VCL-lastige Verwendung greifbare Verbesserung. Code Insight stürzt bei mir in den Riesenprojekten gefühlt immer noch alle 30 Minuten ab. Also sind wir nach einer Evaluation letztendlich doch bei der 10.4 geblieben, auch um Migrationsaufwand und Folgekosten für Devexpress etc. zu sparen.

So kann mann ein Ökosystem auch kaputt machen: Einfach durch Unterlassen der immer wieder versprochenen Verbesserungen "unsexy" machen. Ich habe manchmal den Eindruck, am Gesamtprodukt Delphi wird seitens Emba gerade noch so viel investiert, um zu verhindern dass die Kunden in Scharen die Subscriptions kündigen. Es bräuchte IMHO schnell ein großes Update dass sich nur auf die IDE konzentriert.

[dummzeuch]

Zitat:

Zitat von ernschd (Beitrag 1524608)

dort wird der Code mit Visual Studio Code geschrieben (und diversen Plugins), und seitdem bin ich jedes mal erstaunt, wie langsam und träge Delphi dagegen wirkt.

Hm, komisch. Ich muss seit ein paar Wochen teilweise mit MS Visual C++ arbeiten (weil ich eine Bilbliothek verwende, die es nur für C++ gibt) und ich bin jedes Mal froh, wenn ich wieder mal was mit Delphi machen kann. MSVC kommt mir immer unnötig kompliziert und langsam vor. Vermutlich liegt es einfach daran, dass es anders ist und ich Funktionen, die ich in der Delphi IDE "in den Fingern" habe, bei MSVC erstmal mühsam im Menü suchen muss. Z.B. habe ich bisher vergeblich nach einem Äquivalent des Evaluate & Modify Dialogs gesucht. Vermutlich macht man das in MSVC ganz anders.

Außerdem ist das, was ich mit den jeweiligen Tools mache, sehr unterschiedlich. Ich habe in MSVC z.B. nur ein Commandline-Programm (aus dem später eine DLL werden soll, die ich dann von Delphi aus aufrufe), also weiß ich gar nicht, wie es wäre, damit eine GUI zusammenzubauen. In Delphi hingegen schreibe ich fast ausschließlich VCL-Programme.

Die Delphi IDE ist allerdings definitiv seit den Zeiten von Delphi 7 von Release zu Release träger geworden, ohne dass in meinen Augen die zusätzliche Funktionalität das rechtfertigt. Wenn ich für GExperts mal wieder Delphi 7 starte, ist das immer eine Offenbarung. Nicht, dass ich wieder dauerhaft mit Delphi 7 arbeiten wollte. Schon alleine die Refactoring-Funktionen würden mir fehlen, hauptsächlich das Umbenenen von Variablen.

[dummzeuch]

Zitat:

Zitat von jaenicke (Beitrag 1524610)

Die Titelleiste der Delphi-IDE hat diese Probleme alle nicht, aber offensichtlich wurde nicht die gleiche Komponente auch veröffentlicht. So funktioniert dann auch "eat your own dog food" nicht.

Das ist ja nicht erst seit Gestern so, schon die Docking-Komponenten der Delphi 5 IDE sind definitiv andere als die, die in der VCL mitgeliefert werden. Die der VCL sind meiner Ansicht nach völlig unbrauchbar, da sie ruckelig zu bedienen sind und bei der Darstellung ständig Artefakte übrig bleiben. Wenn man bedenkt, dass gerade Docking heutzutage eine in fast allen Programmen genutzte Funktion ist, frage ich mich, was Embarcadero sich dabei denkt (Oder sollte sich das in den neuen Versionen geändert haben? Ich habe sie schon lange nicht mehr ausprobiert, so seit Delphi 2007 nicht mehr...)

[jaenicke]

Zitat:

Zitat von dummzeuch (Beitrag 1524631)

Die Delphi IDE ist allerdings definitiv seit den Zeiten von Delphi 7 von Release zu Release träger geworden, ohne dass in meinen Augen die zusätzliche Funktionalität das rechtfertigt.

Die IDE selbst ist finde ich gar nicht das Problem. Die Codevervollständigung ist das Problem. Die wurde immer langsamer und funktionierte immer schlechter.

Dass sie gar nicht funktioniert, konnte ich mit dem Entfernen vieler Kreuzbeziehungen zwischen Units zwar weitestgehend beheben, aber die Trägheit leider nicht. Es dauert oft gefühlte Ewigkeiten, bis die Ergebnisse der Codevervollständigung aufgehen. Je mehr ich weitere Kreuzbeziehungen entferne, desto mehr bessert sich das aber auch. Aber das stellt man halt eben nicht mal eben komplett um...

Zitat:

Zitat von dummzeuch (Beitrag 1524631)

Wenn ich für GExperts mal wieder Delphi 7 starte, ist das immer wieder eine Offenbarung.

Wenn ich dran denke, dass ich damit selbst auf einem 486 DX2 gut arbeiten konnte...
Gut, der Start hat ca. 15 Minuten gedauert :lol:, aber danach lief es wie geschmiert und ist auch nicht abgestürzt.

Zitat:

Zitat von dummzeuch (Beitrag 1524632)

Das ist ja nicht erst seit Gestern so, schon die Docking-Komponenten der Delphi 5 IDE sind definitiv andere als die, die in der VCL mitgeliefert werden. Die der VCL sind meiner Ansicht nach völlig unbrauchbar, da sie ruckelig zu bedienen sind und bei der Darstellung ständig Artefakte übrig bleiben.

So schlimm ist es nicht mehr, aber es sieht halt nicht modern aus und ist wenig intuitiv, aber das gilt auch für die IDE selbst. Da braucht man sich nur mal Visual Studio anzuschauen. Da sieht das wirklich gut aus.

Es gibt dafür zwar Lösungen von Drittanbietern, aber eine wirklich gute haben wir damals nicht gefunden. Alle waren irgendwo nicht schön gelöst.

[TiGü]

Zitat:

Zitat von jaenicke (Beitrag 1524610)

Die Titelleiste der Delphi-IDE hat diese Probleme alle nicht, aber offensichtlich wurde nicht die gleiche Komponente auch veröffentlicht. So funktioniert dann auch "eat your own dog food" nicht.

Zumindest ist aber der Name gleich, aber schon die darin verwendeten Komponenten sind nicht in der normalen Palette verfügbar (TGlassPanel, TDesktopComboBox).
Anhang 56141