Delphi vs. Free Pascal

[johndoe049]

Hallo,

bei uns stehen einige Lizenzen zur Verlängerung an.

Wegen den Problemen mit Getit, etc. will ich mal so in die Runde fragen, ob es sich derzeit lohnt, Embarcadero zu verlängern.

Wir verwenden beides. RAD Studio und Lazarus/Free Pascal.

Was setzt Ihr ein, wechselt Ihr zu Lazarus, etc.

Vielen Dank für eure Meinungen im voraus.

[Uwe Raabe]

Zitat:

Zitat von johndoe049 (Beitrag 1534136)

Wegen den Problemen mit Getit, etc. will ich mal so in die Runde fragen, ob es sich derzeit lohnt, Embarcadero zu verlängern.

Die Entscheidung für eine Verlängerung hat meiner Meinung nach nichts mit einem Server-Ausfall zu tun. Mit D11 und D12 gibt es aktuell auch keine nennenswerten Probleme mehr mit GetIt.
Wobei sich die Frage stellt, ob man bei professioneller Entwicklung nicht besser ohne GetIt auskommen sollte. Die Installation kann von der ISO gemacht werden und was es im Paketmanager gibt kann man meistens auch woanders bekommen - in der Regel sogar in einer aktuelleren Version. Für alles was man nur bei GetIt bekommt, sollte man sich dann eh besser lokale Kopien des Installationsverzeichnisses sichern.

Zitat:

Zitat von johndoe049 (Beitrag 1534136)

Was setzt Ihr ein, wechselt Ihr zu Lazarus, etc.

Ausschließlich Delphi, also mit Sicherheit auch kein Wechsel.

[himitsu]

Prinzipiell geht GetIt ja wieder. (D12 angeblich komplett und D11 halbwegs)
Es soll auch mehr dran gearbeitet werden Pakete als Offline-Version bereitzustellen, womit es dann zukünftig ausfallsicherer wird (wenn man persönlich rechtzeitig untergeladen/gebackupt hat)

Auch das Delphi-Setup sollte man sich dringend speichern (als ISO, aber geht auch der Online-Installer), da nach Ablauf der Subscription das Downloadportal gesperrt wird (super nett).

[Sinspin]

Wir verwenden in der Firma nur Delphi.
Privat nutze ich nur noch Lazarus/FPC.
Es wäre toll wenn ich privat Delphi verwenden könnte. Aber auf die CE habe ich aktuell keine lust mehr.
Andererseits ist es auch mal ganz schön zu sehen was andere Object Pascal IDE und Dialekte können.

[IBExpert]

in allen neuen Projekten seit 2010 nur noch lazarus, daher hab ich damit auch seit dieser zeit einige
tausend stunden persönliche Erfahrung und das nie bereut.

Ich versuchte aber auch schon in den Jahren davor, möglichst wenig fremdkomponentenkram einzusetzen
und da wo es mir schon immer sinnvoll erschien, auch nicht jedes neue Sprachelement zu benutzen, weil
das gerade wieder als neue Sau durchs dorf getrieben wurde.

Businesslogik ist 100% in Firebird Datenbanken und die exe ist eigentlich nur noch so was wie ein
webbrowser, die das was da in der Datenbank zu finden ist, nach passenden Regeln visualisiert.

Konvertierung vorhandener Projekte sind wir dran (ibescript.exe mit ca 1.5 millionen zeilen code
ist zu ca 90% (über directives) quellcodekompatibel zu d5 und lazarus32/64 compilierbar, aber ist
auch "nur" eine konsolenanwendung.

Konvertierung eines existierenden GUI Delphi Projekts ist nur in sehr wenigen fällen erfolgversprechend,
wenn man wie üblich alles mögliche an delphicode komponentenabhängig in seinem dfms referenziert hat.
Wäre zwar auch nur eine Fleissaufgabe, das ggf durch passende wrapper klassen beidseitig benutzbar
zu machen, aber zwischen benutzbar und funktionsgleich ist ein ganz weiter weg.

In neuen Lazarus Projekten fehlt mir dort gar nichts, was das leben in Delphi angeblich so unnachahmlich
besser macht, Kunden zeigten mir da einiges, was die daran toll fanden, ging aber aus jeder diskussion
dazu meistens mit einer simplen demo in lazarus raus, wo ich gezeigt hab, wie ich das da mache.

[jsheyer]

Ich bin da auch eher bei Delphi in der aktuellen Version, ich habe in der Vergangenheit auch das ein oder andere mit Lazarus umgesetzt vor allem wenn es nicht unter Windows sondern unter Linux laufen sollte (Als Delphi noch keine Linux Unterstützung hatte).
Wobei mich eher die IDE von Lazarus stört, da fühle ich mich immer in alte Delphi 7 Zeiten oder älter zurückversetzt und ich mag die aktuelle IDE von Delphi deutlich mehr.

[Rollo62]

Zitat:

Zitat von johndoe049 (Beitrag 1534136)

Was setzt Ihr ein, wechselt Ihr zu Lazarus, etc.

Mich reizt die angebliche Multi-Plattform-Kompatibilität ( iOS, Android, Linux, Intel/Arm, RaspPI, ...).
Ich hatte das mal vor Jahren gecheckt, war aber leider von dem fehlenden Support etwas enttäuscht.
Bei Delphi gibt es zumindest eine sehr aktive Community, bei Lazarus hatte ich den Eindruck nicht, zumindest wenn es anders als Windows sein sollte.
Außerdem schien mir die Multi-Plattform-Lösung sehr "Desktop-Orientiert", wo man dann schnell an Grenzen stößt.

Für Desktop mag Lazarus eine Überlegung Wert sein, für Mobile meiner Meinung nach eher nicht.
Es kann aber sein, dass sich in den letzten Jahren auch etwas getan hat, habe es lange nicht mehr gecheckt.

[himitsu]

Joar, beim Delphi gibt es Linux ja erst ab der Enterprise.
Wobei viele wohl eher irgendwo was mit einem Tier hätten, anstatt so vergammeltes Obst.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1534159)

Wobei viele wohl eher irgendwo was mit einem Tier hätten, anstatt so vergammeltes Obst.

Du weißt doch, Entscheider stehen besonders auf teures, vergammeltes Obst, was soll man da machen? :stupid:

[himitsu]

Ihr dürft gern voten. (wenn es wieder geht)

Im Qualli gibt es einen Bugreport, da das D12-Setup auch Linux zur Installation anbietet, die Installation dann aber leider defekt ist. :duck:

[dummzeuch]

Ich habe nur wenig Erfahrung mit Lazarus und die letzte Version, die ich mir angeschaut habe, hatte gegenüber der Delphi IDE noch deutliche Nachteile, auch wenn es von Release zu Release besser wird. Ich liebäugle immer wieder damit.

Auf Arbeit gäbe es genau einen Grund, auf Lazarus umzusteigen: Linux-Unterstützung, wobei es da lediglich um Commandline-Programme geht, die auf einem bzw. mehreren Servern laufen würden. Delphi Enterprise ist uns dafür schlicht zu teuer. Aber es wäre sehr aufwändig, unseren Code auf Lazarus zu portieren, deshalb wird das vermutlich nichts.

(OK, es gibt noch einen möglichen zweiten Grund: Embarcadero hat manchmal sehr seltsame Vorstellungen von deutschem Recht und ob es auf sie zutrifft. Damit haben sie mich bei der Verlängerung der Wartungsverträge schon mehrfach ziemlich verärgert. Und da jetzt Matthias die Missverständnisse nicht mehr klären kann, kann es irgendwann sein, dass ich die Faxen dicke habe.)

[atari1040]

Ich mache seit 2012 keine "neuen" Projekte mehr mit Delphi. Mit Verlaub gesagt passt aus meiner Sicht Preis/Leistung überhaupt nicht mehr. Im Zeitalter von OpenSource muss ich nicht viel Geld für wenig Leistung bezahlen (ich würde aber viel Geld für gute Qualitität bezahlen, wenn die vorhanden wäre!).
Wenn es unbedingt Pascal sein muss, dann ist Lazarus eine hervorragende Wahl. Ich verstehe überhaupt nicht, was man da vermisst. Sehe es so wie der User IBExpert.
Was Mac/iOS/Android angeht kann ich wirklich nur jedem raten, sich mit XCode/Swift oder Android Studio zu beschäftigen. Das ist überhaupt nicht schwer (nur anders) und bringt einem am Ende viel weiter weil näher am System.

[Rollo62]

Zitat:

Zitat von atari1040 (Beitrag 1534165)

Was Mac/iOS/Android angeht kann ich wirklich nur jedem raten, sich mit XCode/Swift oder Android Studio zu beschäftigen.

Das ist nur eben mindestens 2-/3-facher Aufwand man bräuchte dann doppelte Teams oder eben auch viel mehr Aufwand.
XCode und Android sind eine eigene Welt, die Lernkurve ist nicht Null.

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.
Wenn FMX und entsprechende Libraries gut designt sind, dann ist One-Source für alle Plattformen in greifbarer Nähe oder zu 85-95 % möglich,
da sehe ich den Riesenvorteil von FMX.
Auch, dass Windows, Macos und möglicherweise Linux quasi als Abfallprodukt mit abfällt.
Sehr schnelle Entwicklung und Test unter Windows unterstützt alle Plattformen, auch wenn man die dann separat noch austesten muss.

Bedauerlicherweise tun Google und Apple immer alles, um immer wieder möglichst inkompatibel zu werden, das betrifft aber sehr oft ihre eigene Entwicklergemeinde genauso, nur bei Delphi ist es meistens verschärft.

Andere, externe IDE/Frameworks (Xamarin, .NET MAUI, React Native, etc.) haben auch die gleichen Anpassungsschwierigkeiten wie Delphi,
das sehe ich auch immer wieder.
Die guten, alten Zeiten von Windows, wo von WinXP bis Win11 alles mit der gleichen Binary und API läuft, sind bei Multiplattform wohl leider vorbei.

[Stevie]

Zitat:

Zitat von IBExpert (Beitrag 1534143)

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?

[totti14]

Zitat:

Zitat von Stevie (Beitrag 1534230)

Zitat:

Zitat von IBExpert (Beitrag 1534143)

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?

Das ist einer der Hauptgründe, das ich Lazarus immer wieder zur Seite lege.
Der Debugger stammt noch aus Win 3.11 Zeiten und kann auch nur sehr wenig.

Da liegen noch Welten zwischen.

[atari1040]

Ich benutze Lazarus häufig auf dem Mac aber mir fehlt weder unter Windows noch auf dem Mac etwas auch in Bezug auf den Debugger. Vielleicht habe ich nicht so viel zu debuggen :-)
Ist das bei Euch nur eine Erinnerung an alte Zeiten oder kommt ihr wirklich mit den aktuellen Debug-Möglichkeiten unter Lazarus nicht klar?

[IBExpert]

Zitat:

Zitat von Stevie (Beitrag 1534230)

Zitat:

Zitat von IBExpert (Beitrag 1534143)

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. :stupid:

[IBExpert]

Zitat:

Zitat von totti14 (Beitrag 1534258)

Der Debugger stammt noch aus Win 3.11 Zeiten und kann auch nur sehr wenig.

wovon redest du da? bitte konkret: Was stammt da noch aus win 3.11 zeiten? gdb? lldb? fpdebug?

Mal ein offener Aufruf an alle Lazarus Kritiker:

Natürlich muss man das nicht toll finden und darf bei Diskussionen auch gerne pro und contra Argumente bringen.
Schwerpunkt dabei aber: Argumente!

Irgendwelche Behauptungen sind aber keine Argumente. Wenn man das also nicht selber konkretisieren kann, dann
lieber einfach mal den Kommentar verkneifen.

ich lass mich aber gerne überraschen was da noch von win311 drin sein soll?

[IBExpert]

Zitat:

Zitat von himitsu (Beitrag 1534266)

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

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

[himitsu]

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

[atari1040]

Zitat:

Zitat von himitsu (Beitrag 1534270)

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

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:

Zitat von DieDolly (Beitrag 1534273)

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.

[Der schöne Günther]

Um zur ursprünglichen Frage

Zitat:

bei uns stehen einige Lizenzen zur Verlängerung an.

Wegen den Problemen mit Getit, etc. will ich mal so in die Runde fragen, ob es sich derzeit lohnt, Embarcadero zu verlängern.

zurückzukehren:

Wir beziehen die Lizenzen seit zehn Jahren im Abo, werden nun aber sehr wahrscheinlich auch die Verlängerung beenden.

Wenn eine Firma mehrere tausend Euro pro Arbeitsplatz aufruft und dann

• einen geschlagenen Monat braucht, um Installationen oder den angepriesenen Package Manager wieder ans Laufen zu bekommen
• Der Bugtracker nach 7 Wochen (51 Tage) immer noch nicht läuft
• Es mittlerweile normal ist, dass man eine Major-Version nach vielleicht einem Jahr für den Produktivbetrieb einsetzen kann (wenn man mutig ist)
• Immer wieder offensichtlich wird, dass für die Standardbibliothek eine nicht ausreichende (falls überhaupt existente) Test-Abdeckung besteht
• Es anscheinend normal ist, dass man auf dem vor fast 5 Monaten erschienenen iOS 17 noch nicht einmal debuggen kann

dann sind da aus unserem Eindruck wirklich schon so viele Lichter ausgegangen, dass man da für die Zukunft nicht mehr drauf bauen möchte.


Wir haben einen Neuen an Delphi gesetzt und an den Fragen wird einem immer wieder schmerzhaft klar, an was man sich mittlerweile gewöhnt hat - "Warum geht die Code-Vervollständigung plötzlich nicht mehr?" - "Ja, das ist leider oft normal, musst du die IDE neu starten"
"Warum bekomme ich in der IDE plötzlich eine Meldung 'Cannot focus an invisible or modal window' - Was heißt das, und was muss ich machen?"
"Warum zeigt der Debugger diese lokalen Variablen nicht an?" - "Oh ja, weil das in einer Closure steckt, der Bug ist beim Hersteller seit 10 Jahren offen, der Debugger kann das einfach nicht"


Delphi/RAD Studio kann viel, aber eigentlich nichts davon kann es wirklich gut. Delphi mag sich früher noch durch Dinge abgehoben haben, aber heute nutzen wir Delphi auch wirklich nur noch da, wo wir müssen, wo zu viele Altlasten am Leben gehalten werden. Es ist weiterhin ein sehr brauchbares Tool für Quick & Dirty und Prototyping, aber ich mache Delphi jetzt lange genug um jedes mal zu sehen, wie viel Zeit (und Nerven!) es einen teilweise kostet, je länger und größer das Projekt wird.

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.

tl;dr: Wir werden Delphi weiterhin nutzen, aber über die letzten Jahre wirklich arg ernüchtert. Neue Entwicklungen werden mit Delphi/RAD Studio nicht mehr umgesetzt.

[DieDolly]

Wenn ich mit Delphi arbeite, kommt es mir manchmal vor als ob ich mit anderen Editoren arbeite dessen Namen ich nicht nennen möchte.
Ein Editor der gut aussieht aber überhaupt nix richtig kann - verglichen zu aktuellen Editoren.
Die Visual Studio oder VS Code vergleichsweise sind dagegen ein kleiner Traum.

[dummzeuch]

Zitat:

Zitat von Rollo62 (Beitrag 1534274)

"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:

Zitat von dummzeuch (Beitrag 1534279)

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

Also diese resetetwerdenwollenden Toolbars gibt es schon im XE.

[bcvs]

Zitat:

Zitat von atari1040 (Beitrag 1534275)

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]

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.

[atari1040]

Zitat:

Zitat von bcvs (Beitrag 1534284)

Zitat:

Zitat von atari1040 (Beitrag 1534275)

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:

Zitat von himitsu (Beitrag 1534282)

Zitat:

Zitat von dummzeuch (Beitrag 1534279)

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.

[himitsu]

Können nicht genau sagen wann oder durch wen, aber ist wohl eine Kombination auf RDP und lokal, vielleicht noch mit AnyDesk.

Mit der Zeit wandern einige Buttons in der ToolBar nach unten. Wenn die Leisten schon doppelt so hoch eingestellt sind und es erneut unten verschwindet, wird es langsam echt nervig.
Beim letzten Reset war bei mir der Desktop-Speichern-Knopf ganz verschwunden und ich brauchte ewig, um ihn wiederzufinden.

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1534293)

Können nicht genau sagen wann oder durch wen, aber ist wohl eine Kombination auf RDP und lokal, vielleicht noch mit AnyDesk.

Mit der Zeit wandern einige Buttons in der ToolBar nach unten.

Ich nutze Delphi sowohl lokal als auch via RDP. Anydesk setzen wir allerdings nicht ein, bei uns wird stattdessen Fastviewer verwendet, auch darüber habe ich Delphi schon benutzt, incl. Delphi 10.2, allerdings nur selten. Die Toolbars machen erst seit Delphi 11 Ärger, da aber massiv. Ich habe schon überlegt, ob ich nicht ein Programm vorschalten soll, das vor jedem Start die Einstellungen für die Toolbars in der Registry löscht. Dann kann man sie zwar immer noch nicht konfigurieren, aber sie bleiben wenigstens benutzbar.

[himitsu]

die letzten Jahre war es nur bei zwei Kollegen aufgefallen.

Einer der die Eingabesprache öfters auf rusisch umstellt
und später bei unserem Georgier, der sowas aber nicht macht (glaub ich).

Aber seit Ende letztem Jahr tritt das Problem auch manchmal bei mir auf. (aktuell sieht es noch OK aus, aber 2-3 Wochen hatte ich das Verschobene erst reseten müssen)

[jaenicke]

Zitat:

Zitat von totti14 (Beitrag 1534258)

Zitat:

Zitat von Stevie (Beitrag 1534230)

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

Das ist einer der Hauptgründe, das ich Lazarus immer wieder zur Seite lege.
Der Debugger stammt noch aus Win 3.11 Zeiten und kann auch nur sehr wenig.

Da liegen noch Welten zwischen.

Ich arbeite nicht gern mit Lazarus. Das hat aber ganz andere Gründe. Der Debugger ist im Gegenteil meiner Meinung nach grundsätzlich gut gemacht und kann teilweise mehr als der von Delphi. Zum Beispiel werden dort Strukturen wie Records als solche mit allen Feldern und Werten direkt angezeigt.

Dabei gibt es zwar kleinere Probleme, z.B. kann man in dem per Mouseover angezeigten Fenstern nicht scrollen, weil es bei einer Mausbewegung darüber direkt wieder verschwindet, aber insgesamt funktioniert das schon sehr gut.

Was z.B. sehr schön ist:
Datenhaltepunkte halten in Delphi nur an, wenn der Wert geschrieben wird. In Lazarus kann man wählen, ob man beim Lesen, Schreiben oder beidem anhalten möchte. Man muss damit aber vorsichtig sein, da wenig geprüft wird.

Die Lazarus IDE ist standardmäßig mit den freien Fenstern ein Graus. Leider gibt es aber auch keine wirklich schöne Dockinglösung. Da ist Delphi weit voraus.

Schlecht an Delphi ist, dass es mit dem neuen LSP nur mit sehr sauberem Quelltext gut läuft. Mit Kreuzbeziehungen, with und ähnlichem kommt es nicht so gut klar.

[Sinspin]

Zitat:

Zitat von jaenicke (Beitrag 1534297)

Die Lazarus IDE ist standardmäßig mit den freien Fenstern ein Graus. Leider gibt es aber auch keine wirklich schöne Dockinglösung. Da ist Delphi weit voraus.

Ich hatte mir neulich eine neue Version installiert und dabei gesehen das es einen weiteren, neueren, Dockingadapter gibt. Deutlich besser. Macht jetzt richtig Spass.
Ich erinnere mich noch wie sauer ich war als Delphi das erste mal im Ein-Fenster-Design kam. Mittlerweile kann ich mir auch nicht mehr vorstellen mit den lose rumfliegenden Fenstern zu arbeiten.