Delphi vs. Free Pascal

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

[dummzeuch]

Zitat von Rollo62:

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

Also wenn ich sehe, wie bei mir das Fenster der Delphi 12 IDE ständig hin und her springt, weil es die Positionen der einzelnen Desktops auf meinem 2-Monitor System nicht vernünftig gespeichert bekommt, wie die Toolbars ständig kaputt gehen und reset-et werden müssen, dann sehe ich darin schon einen gravierenden Bug. Das ist seit Delphi 11 so. Ich würde ja gern auf eine IDE mit HighDPI Unterstützung umsteigen, aber das Rumgehüpfe nervt. Wenn das Quality-Portal endlich wieder verfügbar ist, werde ich mir nochmal die Mühe machen, dazu einen Bug-Report mit Screenshots zu schreiben, in der Hoffnung, dass Embarcadero das Problem nur deshalb nicht angeht, weil es keine oder nur ungenügende Reports dazu gibt.

(Oder wenn ich viel Zeit finde, werde ich einen eigenen Fix dafür schreiben.)

Aber selbst dann bleibt immer noch das sattsam bekannte Problem mit dem Form-Designer unter High DPI, der so meiner Ansicht nach auch unbrauchbar ist.

Beide Probleme bestehen, wie schon gesagt, seit Delphi 11!

[himitsu]

Zitat von dummzeuch:

Beide Probleme bestehen, wie schon gesagt, seit Delphi 11!

Also diese resetetwerdenwollenden Toolbars gibt es schon im XE.

[atari1040]

Ich bin auch gespannt, welcher FPC/Lazarus Debugger aus der Windows 3.11 Zeit stammt und angeblich dort stehen geblieben ist. Ich benutze ja häufig meinen Mac und debugge dort mit LLDB, der auch von XCode eingesetzt wird. Ich kann mir nicht vorstellen, dass der aus der Win3.11 Zeit stammt. Wenn man von DEM Debugger spricht, welchen meint man denn bei FPC/Lazarus eigentlich? Delphi ist ja meines Wissens nach nur eine Windows only IDE. Bei Lazarus ist das Debugging eine größere Herausforderung. Lazarus setze ich mit MacOS, Linux, Windows, Android und auch für Architekturen wie AMD64, ARM also auch RaspberryPi usw. ein. Es gibt keinen Lazarus Debugger sondern den Debugger, den man auf dem entsprechenden System installiert hat. Das kann LLDB, FpDebug, GDB, usw. sein. Mir persönlich ist es auf keinem System passiert, dass Variablen nicht angezeigt wurden, so wie es beim Delphi Debugger manchmal der Fall ist.
Die Ursprungsfrage war ja: Lohnt es sich noch, seine Delphi Lizenzen zu verlängern und von mir kommt da ein klares Nein. Dieses Jahr werde ich unsere letzte große Delphi Applikation auf zeitgemäße Architektur und Entwicklungsumgebung umstellen und dann seid ihr mich los. Es bleiben gute Erinnerungen an die 90er Jahre, wo Delphi wirklich unbestritten das Beste für die Windows Entwicklung war!
Warum OpenSource heute besser ist als proprietäre Software kann ich nicht sagen. Schon bei Interbase vs Firebird hätte ich das nicht für möglich gehalten, dass Firebird so konsequent weiter entwickelt und mit sehr guter Qualität die Nase vorn hat.
Am Ende ist aber immer die Aufgabenstellung entscheidend und da gibt es für mich keine mehr, die eine teure Entwicklung mit Delphi erfordert.

[dummzeuch]

Zitat von himitsu:

Zitat von dummzeuch:

Beide Probleme bestehen, wie schon gesagt, seit Delphi 11!

Also diese resetetwerdenwollenden Toolbars gibt es schon im XE.

Nicht bei mir. Die kenne ich erst seit Delphi 11.