Delphi vs. Free Pascal

[IBExpert]

Zitat von Stevie:

Zitat von IBExpert:

In neuen Lazarus Projekten fehlt mir dort gar nichts, was das leben in Delphi angeblich so unnachahmlich besser macht

Debuggen und komplexe verschachtelte Objekte inspekten musst du vermutlich in deinen Projekten nicht?

Durchaus debugge ich da ziemlich komplexe Objekte und reichlich TList instanzen, die damit gefüllt sind, aber auch da ist der code, der von mir selbst geschrieben wurde, keinewegs so verschachtelt, das ich damit eine eigene vcl noch mal irgendwo oben drauf bau, bei dem mir schon die basisobjekte suspekt sind.

Meine objektklasssen gehen in der regel auf Ebene TObject los und selten auch mal banal erweiterten TWinControls o.ä..

Abstruse Ableitungen zum Beispiel von TDatasets auf mehreren Ableitungsebenen hab ich schon oft als consultant gesehen und es gruselt mich, wenn mir da jemand erst mal lang und breit erklären muss, warum der da wo in welcher code ebene zB Haltepunkte setzt und der dann trotzdem nicht aktv ist, weil der Entwickler wieder irgendeine Zwischeneben vergessen hat.

Und mit irgenwelche späteren Updates der Basisklassen zB durch neuen delphi/vcl version liefern fehler, die man erst mal finden muss, weil die ggf erst nachträglich den eigenen Code inkompatibel machen.

Das liegt aber auch daran, das eine Anwendungsarchitektur bei mir zum großen Teil auf dynamische Interpretation von Datenbankstrukturen basiert.

Dafür hab ich mir relativ simple Klassen gebaut und die in den letzen 25 Jahren erst mit Delphi später dann mit Lazarus immer mehr erweitert hab, aber weiterhin auf der selben architektur basieren, die vom code her weiterhin mit allen delphi und lazarusversionen compilierbar und benutzbar sind.

Aber zurück zum debuggen: wenn ich irgendwo in meinem code haltepunkte setze, werte auswerten möchte, aufrufstack überwachen will oder bedingungen für die haltepunkte setze, mit F7 oder F8 step by step weitergehen will, funktioniert das bei mir in lazarus einwandfrei. Empfinde ich daher für meine Ansprüche keineswegs als einschränkend. Nicht immer sind funktionale Einschränkungen im Werkzeug begründet, der selbst geschrieben code ist oft teil des Problems.

Ich versuche aber schon immer, meinen Pascalcode einfach zu halten und erzeuge sowieso nahezu alles an visuellen kram auch nur zur Laufzeit. Das hat sich in den letzten 25 Jahren immer bewährt.

wie sagte schon Hannibal lector: "Oberste Prinzipien Clarice. Simplifikation"

[himitsu]

Wir haben mehrfach abgeleitete TDataSource, wo die mehrfach abgeleiteten QueryKomponenten direkt eingebaut sind.

[IBExpert]

Zitat von himitsu:

Wir haben mehrfach abgeleitete TDataSource, wo die mehrfach abgeleiteten QueryKomponenten direkt eingebaut sind.

ist leider genau das was ich meine, was mich gruselt.

[himitsu]

das ist ja noch garnichts, z.B. gegenüber DevExpress

[atari1040]

Zitat von himitsu:

das ist ja noch garnichts, z.B. gegenüber DevExpress

und da gruselt es mich bei Delphi und dem OI. DevExpress sind super Komponenten aber auch ein Teil von denen, wo ich manchmal gefühlte Ewigkeiten im ObjektInspektor nach Properties suche, andere Komponenten treiben das manchmal noch weiter. Das ist der Teil, wo die Entwicklung mit dem RAD heute langsamer ist als mit anderen Entwicklungsumgebungen und wo ich angefangen habe mein XCode oder VSCode zu lieben. Ich finde das Komponentensystem hat lange ausgedient, was natürlich auch für Lazarus gilt.

[DieDolly]

Zitat:

Delphi und FMX wird immer besser in der nativen Unterstützung von iOS/Android Libraries, leider wird noch nicht alles 100 % unterstützt,
aber zumindest das, was ich brauche.

Man könnte auch schreiben "Delphu und FMX wird immer brauchbarer" (weil weniger Bugs).
Ich lese hier im Forum und woanders oft von so gravierenden Bugs in der IDE, da frage ich mich: warum kostet so ein übertrieben gesagt verbuggter Schrott vierstellige Summen?
Und wo bleiben Hotfixes? Nein, ist ja zu kompliziert.

Pascal ist eine tolle Sprache, aber was Embarcadero daraus macht, schadet der Sprache nur.

[Rollo62]

Zitat von DieDolly:

Zitat:

Delphi und FMX wird immer besser in der nativen Unterstützung von iOS/Android Libraries, leider wird noch nicht alles 100 % unterstützt,
aber zumindest das, was ich brauche.

Man könnte auch schreiben "Delphu und FMX wird immer brauchbarer" (weil weniger Bugs).
Ich lese hier im Forum und woanders oft von so gravierenden Bugs in der IDE, ...

"Gravierende Bugs" in der IDE sehe ich eigentlich seit Jahren gar nicht bei mir.
Nur die Libraries und Unterstützung der Plattformen ( außer Windows) wäre verbesserungswürdig.
Das liegt aber wohl daran, dass diese Plattformen ein moving target sind,
und ständig alles von unten nach oben gekrempelt wird von Google/Apple.

[atari1040]

Zitat:

Delphi und FMX wird immer besser in der nativen Unterstützung von iOS/Android Libraries, leider wird noch nicht ...
und ständig alles von unten nach oben gekrempelt wird von Google/Apple.

was für mich ein guter Grund ist, immer auf die "kostenlosen" Tools der Hersteller zu setzen, in meinem Fall XCode/Swift. Die bringen pünktlich vor jedem neuen iOS eine neue XCode Version incl. SDK's/Libraries heraus, so das man neue Features auch direkt nutzen kann und nicht warten muss, bis diese in Delphi implementiert wurden.
Swift ist auch eine tolle Sprache, die man schnell erlernen kann! Genial auch mit SwiftUI.

[DieDolly]

Zitat:

"Gravierende Bugs" in der IDE sehe ich eigentlich seit Jahren gar nicht bei mir.

Da wurde doch vor kurzem hier im Forum dieser Bug erwähnt, der die Formulare korrumpiert hat.
Sowas "darf" bei einem kostenlosen Programm ja mal passieren. Aber nicht bei einem Programm im vierstelligen Bereich.

[bcvs]

Zitat von atari1040:

was für mich ein guter Grund ist, immer auf die "kostenlosen" Tools der Hersteller zu setzen, in meinem Fall XCode/Swift.

Das endet aber spätestens dann, wenn man den selben Quellcode auf verschiedenen Plattformen verwenden will. Bei mir werkeln exakt die selben Units in den Android- und iOS-Versionen der App und im Windows-Backend, evtl. mit ein paar ifdefs drin.