Innovationen bei Lazarus vs Borland/Embacadero und co

[marcoX]

Was ich bei Lazarus unmöglich finde, ist dass man beim Installation neuer Komponenten halbe (oder das ganze?) Programm neu compilieren muss. Daran sollten sie auf jeden fall etwas tun.

Also auch Lazarus hängt in einigen Dingen massiv nach.

[cookie22]

Leider werden von der Open-Source Community nur die Sachen implementiert, die sie selbst auch wirklich brauchen. Geht es um betriebssystemspezifische Dinge, gerade im Bezug auf Windows, kann man FPC/Lazarus fast vergessen.

Von der IDE will ich erst garnicht reden, die ist 10-15 Jahre hinter der Zeit zurück.

[JamesTKirk]

Zitat:

Zitat von Stevie (Beitrag 1111420)

Übrigens, wann gibts eigentlich mal nen Lazarus mit FPC 2.6 (delphi kompatible Generics)?

1. muss FPC 2.6 erstmal gebrancht und dann releast werden (letzteres dauert etwa 2, 3 Monate vom Branchzeitpunkt her)
2. werden die delphikompatiblen Generics wohl nicht in 2.6 erscheinen, da meine Änderungen erst nach dem Branchen gemergt werden (da sie doch sehr umfangreich sind)

Das heißt die 2.6 Serie wird wohl nur pseudokompatible Generics haben...

Zitat:

Zitat von marcoX (Beitrag 1111428)

Was ich bei Lazarus unmöglich finde, ist dass man beim Installation neuer Komponenten halbe (oder das ganze?) Programm neu compilieren muss. Daran sollten sie auf jeden fall etwas tun.

Das liegt an der fehlenden Unterstützung für Runtimepackages. Da sich aktuell niemand intensiv darum kümmert, gibt es sie dann, wenn sie fertig sind...

(ich selbst bevorzuge allerdings nach meinen negativen Erfahrungen mit Delphi diesen statischen Weg :mrgreen: )

Zitat:

Zitat von cookie22 (Beitrag 1111429)

Leider werden von der Open-Source Community nur die Sachen implementiert, die sie selbst auch wirklich brauchen. Geht es um betriebssystemspezifische Dinge, gerade im Bezug auf Windows, kann man FPC/Lazarus fast vergessen.

FPC enthält auf jeden Fall den vollen Satz der JEDI WinAPI Header und auch viele plattformspezifische Units (WinCE, Max OS X, etc) sind vorhanden. Lazarus hängt hier jedoch in der Tat etwas nach, aber an der Unterstützung der neuen Vista+ Dialog wird gearbeitet.

Zitat:

Von der IDE will ich erst garnicht reden, die ist 10-15 Jahre hinter der Zeit zurück.

Lazarus enthält viele der Features, die Delphi auch bietet... Code Completion, Synchron Edit, Code Formatter (wer's braucht), Anzeige von Dokumentationstexten als Hints über den dazugehörigen Bezeichern.
So pauschal darf man das also nicht sagen...

Gruß,
Sven

[implementation]

Zitat:

Zitat von Stevie (Beitrag 1111420)

Übrigens, wann gibts eigentlich mal nen Lazarus mit FPC 2.6 (delphi kompatible Generics)?

Mal ganz im Ernst - das ist ein Nonsensargument.
Genauso könntest du Delphi dafür verurteilen, dass die Generics nicht FreePascal-Kompatibel sind. :angel:

Sowohl Delphi als auch der FPC kennen Generics - sie haben lediglich verschiedene Syntax.

[edit]
Wenn es einfach als interessezeigende Frage gemeint ist, nehm' ich das hier natürlich zurück.
Nur irgendwie höre ich da gleich eine Bewertung mit drin.

[Stevie]

Zitat:

Zitat von implementation (Beitrag 1111497)

Zitat:

Zitat von Stevie (Beitrag 1111420)

Übrigens, wann gibts eigentlich mal nen Lazarus mit FPC 2.6 (delphi kompatible Generics)?

Mal ganz im Ernst - das ist ein Nonsensargument.
Genauso könntest du Delphi dafür verurteilen, dass die Generics nicht FreePascal-Kompatibel sind. :angel:

Sowohl Delphi als auch der FPC kennen Generics - sie haben lediglich verschiedene Syntax.

Falsch, die Nonsenseargumente sind auf deiner Seite. Wie ich schon sagte, vergleichen wir hier nicht den Compiler (dcc32 vs fpc) sondern auch die IDE (Delphi bzw RAD Studio vs Lazarus).
Ich beschäftige mich nicht viel mit Freepascal, aber ich kann mich erinnern, dass es anno 2009 ziemlich mau aussah, was Generics in FPC anging. Von daher wär wohl die Frage "Henne oder Ei?" geklärt.

Mag sein, dass sich zwischen den Compilern nicht mehr viel unterscheidet, was den Sprachumfang angeht, aber ich schreib meine Programme nicht im Notepad und lass sie dann über die Kommandozeile kompilieren... deshalb brauch ich eine IDE, die was taugt und auch alle Sprachfeatures unterstützt.

Mag auch sein, dass es einige Masochisten gibt, die mit Lazarus professionell entwickeln, für mich ist es nicht mehr als ein Spielzeug. Dann könnt ich auch noch mit Delphi 7 entwickeln (ok, in der Hinsicht wäre wohl Lazarus etwas vorne)

Zitat:

Zitat von implementation (Beitrag 1111497)

[edit]
Wenn es einfach als interessezeigende Frage gemeint ist, nehm' ich das hier natürlich zurück.
Nur irgendwie höre ich da gleich eine Bewertung mit drin.

Wie ich bereits sagte, Lazarus genügt meinen Ansprüchen nicht. Nichtsdestotrotz schau ich es mir alles halbe Jahr mal an. Immerhin hab ich vor Jahren die Zeos Komponenten auf Lazarus portiert. Bin aber jedesmal wieder enttäuscht, dass ich mit Lazarus nix anfangen kann aufgrund der massiven Mängel, was die Unterstützung der neueren Features von Delphi angeht.

[JamesTKirk]

Zitat:

Zitat von Stevie (Beitrag 1111499)

Ich beschäftige mich nicht viel mit Freepascal, aber ich kann mich erinnern, dass es anno 2009 ziemlich mau aussah, was Generics in FPC anging. Von daher wär wohl die Frage "Henne oder Ei?" geklärt.

Ich merke hiermit mal an, dass der initiale Commit der "fgl" Unit, welche verschiedene Generic-Klassen implementiert August 2006 war... Funktionsfähig war sie dann spätestens Oktober 2006. Das aber auch nur am Rande :wink:

Gruß,
Sven

[Stevie]

Zitat:

Zitat von JamesTKirk (Beitrag 1111923)

Zitat:

Zitat von Stevie (Beitrag 1111499)

Ich beschäftige mich nicht viel mit Freepascal, aber ich kann mich erinnern, dass es anno 2009 ziemlich mau aussah, was Generics in FPC anging. Von daher wär wohl die Frage "Henne oder Ei?" geklärt.

Ich merke hiermit mal an, dass der initiale Commit der "fgl" Unit, welche verschiedene Generic-Klassen implementiert August 2006 war... Funktionsfähig war sie dann spätestens Oktober 2006. Das aber auch nur am Rande :wink:

Mag sein, fraglich ist nur, auf welcher FPC Version Lazarus zu dem Zeitpunkt rumgegurkt ist. Fakt ist, dass ich nichtmal simple generische Listen wie ich sie aus der Generics.Collections kenne, zum Laufen bekommen habe.

[marcoX]

Ich lese gerade, Borland ist mittlerweile nicht mal mehr eigenständig sondern ein Tochterunternehmen von "Micro Focus International". Die haben es wirklich voll *******. Hätten sie sich mal rangehalten wie Embacadero und wären bei ihren Leisten geblieben, anstatt den OpenALM Unsinn zu machen , wäre das nie passiert.

[schöni]

Zitat:

Zitat von Teekeks (Beitrag 1111238)

Zitat:

Zitat von Stevie (Beitrag 1111237)

Gibt's bei Lazarus bzw besser gesagt FPC auch die Garantie, dass noch vor 15 Jahren erstellte Programme kompilieren (ein paar Handgriffe bei bestimmten Migrationen vorausgesetzt), der erzeugte Code sehr performant ist, der Compile und Linker Vorgang schnell ist und die Executable noch relativ klein ist?

Das finde ich jetzt sehr Spannend: gibt es eine solche Garantie bei Delphi? Das natürlich sehr schön.

Das ist keine Rechtfertigung. Macht es mit Freepascal einefach besser und gut is. Mit FReepascal 1.0.10 konnte ich noch Projekte aus Turbopascal mit reichlich Assemblercode ohne Änderungen kompilieren, trotz das Turbo Pascal 16 Bittig und Freepascal 32 Bittig ist. Trotz dieser Tatsache. Und die Programme liefen danach auch. Mit den neueren Freepascal Versionen geht das schon lange nicht mehr. Ständig fehlerhafte Syntax.

[schöni]

Zitat:

Zitat von marcoX (Beitrag 1111957)

Ich lese gerade, Borland ist mittlerweile nicht mal mehr eigenständig sondern ein Tochterunternehmen von "Micro Focus International". Die haben es wirklich voll *******. Hätten sie sich mal rangehalten wie Embacadero und wären bei ihren Leisten geblieben, anstatt den OpenALM Unsinn zu machen , wäre das nie passiert.

Ich wäre mir da nicht so sicher. Auch Hobbyprogrammierer müssen von irgendwas leben und ich habe ach schon oft genug bei Freewareprojekten lesen müssen, das die ersehnten Erweiterungen irgenwann in der nächsten Version folgen werden, der Programmierer aber sagt, das er keine Zeit habe, das Projekt weiter zu entwickeln.