Delphi vs. Free Pascal

[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.

[atari1040]

Zitat von 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.

Ich behaupte, dass ich mit dem Einsatz von Lazarus, Xcode und Android Studio schneller bin als mit dem "Wunschtraum" einen gemeinsamen oder "dem selben" Code für alle Systeme langfristig nahe am System zu entwickeln. Das funktioniert am besten mit Web-Frameworks, Electron, Tauri, usw. (siehe Ergebnisse wie VSCode) aber nicht mit Delphi.
Es funktioniert mit Delphi, es ist aber je nach Aufgabenstellung nicht zwangsläufig schneller oder besser pflegbar. Die EierlegendeWollmilchsau gibt es nicht.

[johndoe049]

Zitat:

Wagt mal den Blick über den Tellerrand, und vergleicht die heutige Delphi-Welt mal mit komplett kostenlosen Umgebungen, mit ihren Tonnen an kostenlosen und gut gewarteten weit verbreiteten Bibliotheken. Das ist mittlerweile eine ganz andere Welt

Unsere Erfahrung ist, dass dies zwar sehr gut für reine Softwareanwendungen funktioniert, egal ob ERP, Graphik/Video, etc. aber sich schnell ändert, wenn man in andere Softwarebereiche geht. Bei einigen Projekten ist auch noch die Frage, wer den Sourcecode für XCode Swift oder Java auditieren will/kann.

Daher ist für uns derzeit die Frage ob wir Delphi verlängern oder uns mehr auf Lazarus verstärken.

Es finden nicht wirklich Informationen, ob man beispielsweise mit XCode/Swift auch direkte Ansteuerungen machen kann. Ich gebe mal ein paar Beispiele, damit das besser erkennbar ist, wo wir so unsere Probleme sehen:
- Ansteuerung von Seriellen Schnittstellen (RS232, RS485) mit Protokollansteuerung bzw. Pegelansteuerung.
- LPT bidirektional angesteuert, jedoch nicht unbedingt mit Datenübertragung sondern mit Pegeländerungen der einzelnen Signalleitungen. (Sehr alte Maschinensteuerung, die wir noch pflegen "dürfen")
- USB oder PCI I/O Adapter mit Direktansteuerung und Programmierung der Sekundärlogik im USB Gerät Stichwort (Watchdog Timer für Kontaktüberwachung PC/USB I/O Adapter und entsprechende Fehlerbehandlung).
- Netzwerkansteuerung, teilweise BSD Kompatibel. (Einge Maschinen verwenden das UDP Protokoll, andere TCP Protokoll, manchmal ist die Paketgrösse nicht im Standart und muss je nach Verbindung angepasst werden)
- Twain Scanner Ansteuerung
- RTSP/Onvif/Webcam Kamera Steuerung

Teilweise haben wir Bibliotheken, die sehr alt sind und Ihren Ursprung in Delphi 7 haben.

Dann kommen noch externe Vorgaben, welche Datenbanken man unterstützen muss, weil der Kunde halt entsprechende Vorgaben von anderen Systemen her hat.