Innovationen bei Lazarus vs Borland/Embacadero und co

[jaenicke]

Der Fokus wurde auf andere Sachen gelegt. Und wenn man sich die IDE anschaut, sieht man das ja auch sofort. Die IDE von Lazarus ist gar nichts gegen die von Delphi XE. Und auch die Compilerintegration und die Umsetzung von Komponenten ist bei Lazarus nicht wirklich intuitiv und einfach. Ob die bei Delphi optimal ist, sei dahingestellt, aber besser als bei Lazarus allemal...

Auch wurden Sprachfeatures umgesetzt, die es bei Lazarus so entweder gar nicht gibt (anonyme Methoden, ...) oder die dort für den Entwickler unnötig umständlich umgesetzt wurden (Generics, ...).

Davon abgesehen ist das cross compiling unter Lazarus relativ kompliziert, so dass die Empfehlung eher lautet auf dem System zu entwickeln, für das man kompilieren möchte. Das wird mit Delphi nicht notwendig sein. Siehe das Vorschauvideo zu 64-Bit mit XE 2.

Der jetzige Compiler von Delphi wurde komplett neu aufgebaut von der Architektur her, damit das Frontend immer das gleiche ist und je nach Zielplattform nur das Backend ausgetauscht wird. Außerdem gibt es bei Delphi viel mehr Komponenten und Zusatztools, die auch weiterentwickelt wurden.

Trotzdem ist es aber richtig, dass es sehr lange gedauert hat. Wenn man sich aber die aktuellen Entwicklungen anschaut, sieht es für die Zukunft von Delphi sehr gut aus.

// EDIT:
Von bei Lazarus fehlenden Features wie Remote Debugging, verbinden zu laufenden Prozessen, die ganzen anderen Debuggingfeatures, ... mal ganz abgesehen. Bei Delphi ist das selbstverständlich und leicht nutzbar in die IDE integriert. Als ich wegen 64-Bit mit Lazarus gearbeitet habe blieb mir bei einem Dienst echt nichts anderes als Debugausgaben übrig... das dauert...

[marcoX]

@jaenicke

Danke für die Antwort, das erscheint mir sehr logisch.

Dennoch glaube ich, dass trotz aller Zustimmung zu deinen Thesen der unnötige "politische Hickhack" im Hintergrund zu der Verzögerung auch maßgeblich beigetragen hat. Aber da muss man eben Embacadero sehr loben. Sie haben es nicht nur gekauft, um es irgendwie abzuwickeln oder zu verramschen, sie geben sich a asehr viel Mühe. Ich glaube, eines Tages wird Borland bereuen, sich so sehr von seinem "Baby" abgewendet zu haben.

[jaenicke]

Zitat von Teekeks:

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

Eine Garantie im rechtlichen Sinne natürlich nicht, aber es wird immer versucht so kompatibel wie nur möglich zu sein. Was z.B. zu inkonsistenten Bezeichnungen in der StrUtils.pas bezüglich Unicode geführt hat. Aber es war nicht anders möglich ohne auch bei gut geschriebener Software einen großen Portierungsaufwand zu produzieren. Denn wenn man sich von Anfang an im Stile der Windows API um Unicode und Ansi Gedanken gemacht hat, insbesondere bei Strings als Datencontainern, ist der meiste Code einfach 1:1 auch mit Delphi 2009+ nutzbar.

Selbst wenn etwas durch einen Fehler überhaupt nur funktioniert und so nie gedacht war (ja, worauf wir Entwickler so alles kommen... ), wird es nach Möglichkeit so beibehalten, damit darauf basierender Code nicht gebrochen wird. Deshalb funktionieren manche Sachen nicht für alle Anwendungsfälle, einfach weil manche Features so gar nicht vorgesehen waren.

Und deshalb kann man auch nicht einfach alle Fehler fixen, weil sich viele Workarounds gebastelt haben, die dann plötzlich nicht mehr funktionieren würden.

Natürlich führt so etwas dazu, dass es länger dauert bis alles nach dieser Maßgabe umgesetzt ist.

Zitat von marcoX:

Dennoch glaube ich, dass trotz aller Zustimmung zu deinen Thesen der unnötige "politische Hickhack" im Hintergrund zu der Verzögerung auch maßgeblich beigetragen hat.

Vor allem gab es eben nicht so den Drang zu mehr Fortschritt. Es wurden zwar kleinere Sprachfeatures neu eingeführt und die neue IDE war ein Riesenfortschritt, aber die war eben leider in Delphi 2005 auch noch sehr buggy und hat sich erst entwickelt.
Ein typischer Fall von Bananensoftware: reift beim Anwender. Und ansonsten hat sich da nicht so viel getan in den Jahren.

Wenn man sich dagegen anschaut was sich jetzt in den letzten 3 Jahren alleine getan hat... Da sind so unglaublich viele neue Features hinzugekommen und das setzt sich mit XE 2 und XE 3 ja fort...
Was viele, die die größeren Versionen nicht kennen, auch nicht sehen sind die Fortschritte im Bereich Business Logik, Multi-Tier, Datenbanken, ...
Das sind Enterprise Features, aber die sind auch für die Verwendung in Firmen unglaublich wertvoll, weil man viel an Kosten spart.

Und in der Hinsicht hat Lazarus rein gar nichts zu bieten.

Der Fokus liegt bei Delphi klar auf Business Kunden, leider zuletzt zu sehr. Dadurch fehlt der Nachwuchs. Es ist nicht so einfach gute Leute zu finden, das dauert immer ein wenig. Ich denke aber, dass die XE Starter dazu beitragen wird, dass sich das in Zukunft entschärfen wird.

Es ist jedenfalls schlicht eine andere Zielgruppe und eine andere Zielsetzung. Lazarus will in erster Linie plattformunabhängig sein und auch auf anderen Plattformen als IDE laufen und zudem kostenlos und eher für Hobbyentwickler sein. Und das ist auch schon fast alles was Lazarus zu bieten hat.

Zitat von marcoX:

Ich glaube, eines Tages wird Borland bereuen, sich so sehr von seinem "Baby" abgewendet zu haben.

Das glaube ich nicht, denn profitabel war die Sparte soweit ich weiß auch für Borland trotz aller Schwächen. Dass sie sie ausgegliedert und verkauft haben, hatte nach dem was von außen zu lesen war, strategische Gründe.

Und ich glaube nicht, dass die Entwicklung wie sie jetzt mit Embarcadero stattfindet mit Borland möglich gewesen wäre.

[marcoX]

Wahrscheinlich ist auch, dass Borland unglaublich viel Energie in Unsinn gesteckt hat. Man erinnere sich nur an C++ Builder X und allen möglichen Quatsch, der wohl nur in Nieschen genutzt wurde und sicher sehr sehr unprofitbel war.

[himitsu]

Bei Lazarus/FPC ht man es auch einfach ... wenn etwas auch nur in den Grundzügen (halbwegs) funktioniert, kann man es sofort hochladen und den Usern zum "Spielen" geben.

Delphi hat (da es verkauft wird) einen etwas längeren Update- Upgradezyklus (Bugfixes äh neue Funktion muß/soll man ja schließlich kaufen).
Außerdem hat, bei soeinem bezahlten Feature, dieses auch möglichst zu funktionieren. (Gibt's eigentlich auch eine Art Funktionsgarantie?)

Bei Lazarus/FPC muß es ja nicht sofort funktionieren, da sich eh jeden dritten Tag etwas ändert.

Und am Delphi arbeiten vermutlich weniger Programmierer, als Hobbycodetipper am Lazarus/FPC rumpfuschen.


Erstellt FPC/Lazarus eigentlich immernoch leicht größere/langsamere vergleichbare Kompilate gegenüber Delphi?
(die DelphiEXEn wachsen ja auch immer mehr, von Version zu Version)

[jaenicke]

Zitat von himitsu:

Bei Lazarus/FPC muß es ja nicht sofort funktionieren, da sich eh jeden dritten Tag etwas ändert.

Wobei es bei Lazarus auch Probleme gibt, die jahrelang auf Halde liegen um das mal dazu zu sagen. Ein Beispiel, über das ich selbst gestolpert bin als ich Lazarus beruflich nutzen musste:
Wenn man einen Dienst implementiert, musste man eine bestimmte Unit manuell einbinden, sonst startet der schlicht nicht. Das Problem stand im Bugtracker seit einem Jahr und soweit ich mich erinnere als behoben drin. Trotzdem war es noch nicht in der aktuellen Version korrigiert.

Zitat von himitsu:

Erstellt FPC/Lazarus eigentlich immernoch leicht größere/langsamere vergleichbare Kompilate gegenüber Delphi?
(die DelphiEXEn wachsen ja auch immer mehr, von Version zu Version)

Nicht nur das, auch die Compileroptimierungen sind bei Delphi etwas schlechter geworden, vermutlich wegen der zunehmenden Plattformvielfalt, aber so schlecht wie bei Lazarus wird die Optimierung nie werden...
Und die paar Zyklen oder Bytes, die da an manchen Stellen verschwendet werden, machen in 99,9% der Fälle heutzutage ja auch nichts mehr aus.

Nebenbei habe ich gelesen, dass bei Lazarus auch über eine erweiterte RTTI nachgedacht wird. Dann würde die Größe der Exe da sicher auch nochmal deutlich zunehmen wie bei Delphi (wahrscheinlich mit dem Unterschied, dass es bei Lazarus von Anfang an konfigurierbar sein würde).

[mleyen]

Zitat von jaenicke:

Nebenbei habe ich gelesen, dass bei Lazarus auch über eine erweiterte RTTI nachgedacht wird. Dann würde die Größe der Exe da sicher auch nochmal deutlich zunehmen wie bei Delphi (wahrscheinlich mit dem Unterschied, dass es bei Lazarus von Anfang an konfigurierbar sein würde).

Delphi-Quellcode:

{$IF CompilerVersion >= 17.0} 
  {$SetPEFlags 1}
{$IFEND}
{$IF CompilerVersion >= 21.0} 
  {$WEAKLINKRTTI ON} 
  {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} 
{$IFEND}

[JamesTKirk]

Zitat von jaenicke:

Nebenbei habe ich gelesen, dass bei Lazarus auch über eine erweiterte RTTI nachgedacht wird. Dann würde die Größe der Exe da sicher auch nochmal deutlich zunehmen wie bei Delphi (wahrscheinlich mit dem Unterschied, dass es bei Lazarus von Anfang an konfigurierbar sein würde).

*meld* Ja, ich denke darüber nach. Es steht auf meiner Agenda, sobald ich die delphikompatiblen Generics fertig habe (braucht man ja für ein kompatibles TRTTIContext Record). Ich will endlich mit Attributes arbeiten

Zitat von jaenicke:

Ein Beispiel, über das ich selbst gestolpert bin als ich Lazarus beruflich nutzen musste:
Wenn man einen Dienst implementiert, musste man eine bestimmte Unit manuell einbinden, sonst startet der schlicht nicht. Das Problem stand im Bugtracker seit einem Jahr und soweit ich mich erinnere als behoben drin. Trotzdem war es noch nicht in der aktuellen Version korrigiert.

Kann sein dass du da eine Phase erwischt hast, in dem grad kein neues Release rauskam, weil der Trunk in einem etwas schlechten Zustand war... kommt halt hin und wieder doch mal vor, dass die Entwicklungsversion nicht anzuraten ist

Zitat von implementation:

Zitat von Stevie:

Gibt's bei Lazarus bzw besser gesagt FPC auch die Garantie, dass noch vor 15 Jahren erstellte Programme kompilieren

Die Garantie hast du beim FPC sogar noch deutlich (!) mehr als bei Delphi!

Probier mal, ein TP-Programm ohne Codeänderungen mit Delphi zu kompilieren.
Für den FPC null Problem.

Oh ja... und wenn dann mal doch was kommt, was das beeinflusst, dann findet man dies hier im Wiki. Auch bezüglich der irgendwann anstehenden Einführung von Delphi2009+-kompatiblen Strings werden auf den Mailinglisten entsprechende Diskussionen bzgl Abwärtskompatibilität geführt.

Regards,
Sven

[joachimd]

Zitat von marcoX:

Wahrscheinlich ist auch, dass Borland unglaublich viel Energie in Unsinn gesteckt hat. Man erinnere sich nur an C++ Builder X und allen möglichen Quatsch, der wohl nur in Nieschen genutzt wurde und sicher sehr sehr unprofitbel war.

und genau das - wenn man Volker Hillmann als ausgesprochenem C++ Experten Glauben schenken darf - war eine der größten Innovationen auf dem C++-Markt und wurde aus _politischen_ Gründen eingestampft. Der C++Builder X konnte nämlich schon einiges (zB Backend austauschen), was alle anderen Produkte vermissen liessen.

[JamesTKirk]

Zitat von marcoX:

Hallo,

mich würde interessieren, warum Lazarus eigentlich um es mal übertrieben zu sagen "jeden dritten Tag" den Nutzern die Möglichkeit bieten kann, für eine neue Architektur zu compilieren, während man sich damals Borland bzw. nun bei Embacadero da sehr schwer tut. Es hat sich vieles zum positiven gewendet und es soll ja definitiv auch für OSX /Linux kommen, doch es erstaunt mich, warum eine "Bande von Hobbytüftler" das Jahre vor einem großen Unternehmen schafft. Und warum die das so "über Nacht" schaffen und Embacadero dazu einen riesen Aufwand betreibt und das als riesen Neuerung ankündigt.

Kann mir das jemand erklären?

Warum es bei Embarcadero und Co nicht so schnell gelang, haben die anderen schon dargelegt. Warum es jedoch bei Lazarus bzw. Free Pascal so vergleichsweise schnell geht kann ich dir sagen: Dadurch das beide Open Source sind, kann jemand, der sich dafür interessiert und das nötige Wissen hat (oder es sich nebenbei aneignet), den Compiler bzw. die IDE einfach erweitern. Ich habe genau das gemacht. Vor über einem Jahr habe ich FPC dazu gebracht Anwendungen für die native NT API zu generieren (Treiber zählen hier auch dazu, mein Schwerpunkt liegt allerdings im Usermode) und vor kurzem habe ich FPC auf das Mikrokernelbetriebssystem der Firma portiert, bei der ich meine Bachelorarbeit schreibe
Der Punkt ist eben, dass viele Leute an den beiden Projekten arbeiten und sie (natürlich nicht ohne ein wenig Organisation) in den Bereichen arbeiten, die sie interessieren.

Zitat von jaenicke:

Davon abgesehen ist das cross compiling unter Lazarus relativ kompliziert, so dass die Empfehlung eher lautet auf dem System zu entwickeln, für das man kompilieren möchte. Das wird mit Delphi nicht notwendig sein. Siehe das Vorschauvideo zu 64-Bit mit XE 2.

Es kommt auf die Kombination von Host- und Zielsystem an. Win32 auf WinCE ist ein no-brainer (bei mir in der Arbeit läuft das auf ein einfaches Setzen des Buildmodes heraus) und auch Linux => Win* läuft ohne Probleme. Schwieriger ist es schon von Windows nach Linux oder OS X zu kompilieren, da die letzteren beiden andere Vorraussetzungen haben als Windows. So muss der Linker (für ELF und MACHO existiert noch kein interner Linker) alle verwendeten Bibliotheken vorfinden und deshalb ist es leichter auf dem Zielsystem zu kompilieren (FPC bietet hierfür auch ein "link on target" Script an, das bei Bedarf generiert werden kann).

Zitat von himitsu:

Erstellt FPC/Lazarus eigentlich immernoch leicht größere/langsamere vergleichbare Kompilate gegenüber Delphi?
(die DelphiEXEn wachsen ja auch immer mehr, von Version zu Version)

Bzgl Geschwindigkeit kann ich dir nichts sagen (ich habe hierzu noch keine Tests gemacht), aber die Größe ist immer noch leicht größer als die von Delphi, aber das ist für mich ganz natürlich, da ja die ganze Plattformabstraktion da noch drinsteckt (vor allem, wenn man die LCL verwendet).

Gruß,
Sven