Ist Delphi so Bedeutungslos ?

[sh17]

Vielleicht sollte man doch mal einen Fork von FPC erstellen, wo man direkt vom aktuellen Delphi migrieren kann. Ist das alles wirklich so komplex?
RemObjects schaffen das ja auch. Und wieviel arbeiten dort am Compiler? Wieviele Plattformen unterstützen die?

[JamesTKirk]

Zitat von sh17:

Vielleicht sollte man doch mal einen Fork von FPC erstellen, wo man direkt vom aktuellen Delphi migrieren kann. Ist das alles wirklich so komplex?

Ein Fork würde dir da nicht all zu viel nützen, da dennoch viele der aktuellen Delphi Features erst implementiert werden müssten. Hier ist die Liste derer, die ich weiß ("*" bedeutet, dass daran aktuell mehr oder weniger aktiv gearbeitet wird):

• Delphi kompatible Generics*
• Extended RTTI (+ RTTI Unit mit deren ganzen Spielereien)
• Anonymous Functions*
• Attributes*
• Dynamic Runtime Packages
• Unicode-fähige RTL/FCL* (damit wir bestimmte Plattformen von String=AnsiString auf String=UnicodeString umstellen können)
• Units der RTL/FCL Delphi kompatibel erweitern (z.B. Unit SyncObjs)

Da ist es geschickter diese gleich in FPC statt in einem Fork zu implementieren, dann haben alle was davon... Die Arbeit sich in FPC reinzuarbeiten hätte man so oder so und wir akzeptieren übrigens durchaus Patches für solche Features oder richten einen SVN Branch ein, wo man sich austoben kann (die Anonymous Functions werden zum Beispiel von jemanden implementiert, der kein Core Entwickler ist). Man sollte nur ein paar Kleinigkeiten beachten, aber ansonsten hat man da relativ freie Hand.

Zitat von sh17:

RemObjects schaffen das ja auch. Und wieviel arbeiten dort am Compiler? Wieviele Plattformen unterstützen die?

Wichtigster Punkt: Sie werden dafür bezahlt an sowas zu arbeiten. Im Gegensatz dazu arbeiten wir alle in unserer Freizeit als Hobby an FPC. Zu den unterstützten Plattformen von Oxygene (bitte korrigiert mich, falls ich falsch liege) zählen .NET, JVM und iOS (inwieweit hier Native kompiliert wird und ob i386 auch unterstützt wird kann ich nicht sagen).

Im Gegensatz dazu unterstützt Free Pascal die folgenden Plattformen:

• i386
• x86_64
• PowerPC(64)
• Sparc(64)
• Mips(64) (in Entwicklung)
• AVR (16 bit)
• AVR (32 bit) (in Entwicklung)
• M68k (inklusive Coldfire) (in Entwicklung)
• JVM/Dalvik
• ARM
• AArch64 (aka ARM 64) (in Entwicklung)

und die folgenden Betriebssysteme:

• Win32
• Win64
• WinCE
• DOS
• OS/2
• Linux
• FreeBSD
• NetBSD
• OpenBSD
• AIX
• Mac OS
• Mac OS X
• Amiga
• MorphOS
• Haiku
• Native NT API
• GameBoy Advance
• Nintendo DS
• Wii
• Android (native + Dalvik)
• Solaris
• Embedded (Entwicklung direkt auf der CPU)

Theoretisch haben wir noch ein paar weitere Betriebssysteme, aber deren Zustand weiß ich gerade nicht (Netware, QNX, BeOS, Watcom, PalmOS, Symbian).

Gruß,
Sven

[sh17]

meinetwegen auch direkt mit FPC. Aber eben halt weitestgehend kompatibel zum aktuellen Delphi (in erster Linie um gute externe Komponenten weiter nehmen zu können, VirtualTreeView als prominentes Beispiel) Ich würde da auch gar nicht soviel Russ um Rückwärtskompatibilität machen. Stand XE3, der Rest weg. RTTI, na gut, muss aber nicht primär.
Meinetwegen kann sich auch eine Firma dahinter klemmen, die dann das Geld mit der IDE verdient. Aber so bekommt man eine Alternative

[JamesTKirk]

Du würdest aber nicht FPC allein nehmen können. Wenn du Komponenten wie VirtualTreeView (von dem es übrigens einen Lazarus Port gibt) mit ansprichst, dann musst du auch die LCL mitbeachten. Und hier gibt es ein paar Punkte, die by-design nicht Delphi kompatibel sind, da im Gegensatz zur VCL die LCL nicht nur auf Windows lauffähig ist. Du kannst zwar rein prinzipiell die VCL nach ein paar Korrekturen mit FPC kompilieren (habe ich mal mit der VCL von Delphi 6 gemacht), aber was nützt es dir großartig? Du bist dann weiter an Win32 (vlt auch Win64) gebunden und hast nur den Compiler ausgetauscht. Außerdem sind GUI Komponenten für Delphi auch sehr gerne mit der Windows API verwoben. Da würde es so oder so schwer werden sie auf andere Plattformen zu portieren, solange die Komponentenentwickler da nicht mitmachen.

Gruß,
Sven

[sh17]

Ich würde in der Form auch auf mehrere Plattformen verzichten. Ich möchte ja nur mein Win32/64 Projekt von Delphi nach FPC(lcl,vcl2,..) migrieren. Aber das wird hier offtopic.

[QuickAndDirty]

Zitat von sh17:

Ich würde in der Form auch auf mehrere Plattformen verzichten. Ich möchte ja nur mein Win32/64 Projekt von Delphi nach FPC(lcl,vcl2,..) migrieren. Aber das wird hier offtopic.

Es ist Open Source! Wo ist das Problem ein eigenes Projekt als Fork dazu aufzumachen? Ich verstehe nicht was das angeblich verhindern soll.

[BUG]

Zitat von QuickAndDirty:

Ich verstehe nicht was das angeblich verhindern soll.

Der Aufwand einen Fork zu betreuen, sollte wohl auch nicht unterschätzt werden ... schon das Einpflegen der Patches aus dem Hauptprojekt sollte einem zu tun geben.

[cookie22]

Zitat von JamesTKirk:

...Und hier gibt es ein paar Punkte, die by-design nicht Delphi kompatibel sind, da im Gegensatz zur VCL die LCL nicht nur auf Windows lauffähig ist. Du kannst zwar rein prinzipiell die VCL nach ein paar Korrekturen mit FPC kompilieren (habe ich mal mit der VCL von Delphi 6 gemacht), aber was nützt es dir großartig? Du bist dann weiter an Win32 (vlt auch Win64) gebunden und hast nur den Compiler ausgetauscht...

Genau das ist das größte Problem von FPC/Lazarus. Cross-Platform auf Biegen und Brechen.

Einen der größten Vorteile von Delphi, nämlich die Unmenge an Komponeten kann Lazarus nicht für sich nutzen. Die meisten Kompos laufen gar nicht oder müssen mühevoll angepasst werden. Damit schießt sich Lazarus selbst ins bein.

[QuickAndDirty]

Zitat von BUG:

Zitat von QuickAndDirty:

Ich verstehe nicht was das angeblich verhindern soll.

Der Aufwand einen Fork zu betreuen, sollte wohl auch nicht unterschätzt werden ... schon das Einpflegen der Patches aus dem Hauptprojekt sollte einem zu tun geben.

Ein überzeugendes Projekt sollte, wenn erstmal ein initialer Aufwand geleistet wurde ein Community entwickeln die den entsprechenden Aufwand leistet, zumal wenn die Zielgruppe Unternehmen sind, die ja schon mal jemand Bezahltes abstellen Features in ein genutztes Open Source Tool einzupflegen. (Siehe QT bindings in Lazarus)

[Medium]

Bei FPC kommt jedoch auch wieder in Spiel, dass es eigentlich ja keine Konkurrenz zu Delphi ist. EMB will Delphi als Enterprise Produkt vertreiben, bzw. führen sie sich zumindest so auf. Leider vergessen sie dabei, dass das Kunden umsorgen genau der Teil ist, den man in diesem Segment gerne bezahlt wenn es passt. Das Produkt selbst ist doch nur Werkzeug. Ich muss jemandem haben, bei dem ich mich darauf verlassen kann, dass er mir mit Rat und Tat 24/7 auf's Pferd helfen kann, insbesondere beim Bugfixing. Das ist der Teil, der mein Zeitkontingent schont, und der echten Geldwert hat. FÜr beide Seiten.

Bei FPC kommt dieser ganze Gedanke ja überhaupt nicht zum tragen, das liegt auch in der OS-Natur. Eine Firma, die OS als Tools einsetzt, muss sich darüber im Klaren sein, dass sie sich selbst eine interne Support- und Pflegeabteilung halten muss um die Endprodukt-Entwickler bei Laune zu halten. Auch ein Geschäftsmodell, tun manche auch, aber der überwiegende Teil möchte doch für ein Produkt bezahlen, bei dem er den Nutzen der Zeitersparnis durch Abgabe dieser Verantwortungen erhält. Welches Tool jetzt genau dahinter steht ist fast schon zweitrangig. Das ist aber der graduelle Unterschied zwischen Hobby, Business und Enterprise.
Wir könnten uns FPC z.B. nicht leisten. Wir brauchen eine Umgebung, die einfach läuft, mit der wir unsere Software zügig bauen können, mit deren Erlös wir unsere Kaffeekasse aufbessern. Der administrative Aufwand für FPC passt einfach nicht rein, und wenn es hakelt - ja sollen dann einfach mal eben alle Projekte für X Zeit angehalten werden, bis die Community zumindest schon mal auf das (hier fiktive) Problem aufmerksam wurde? Wenn man keinen hat, der an soetwas intensiv in Vollzeit arbeitet, oder jemanden, den man dafür bezahlt, stelle ich mir das als Softwarehaus schwierig vor.

FPC zielt auf Hobby oder Enterprise (mit eigener FPC-Abteilung), Delphi zielt zumindest dem Anschein nach auf Business und Enterprise, kann aber die dafür nötige Qualität im Moment nicht liefern. Sowohl im Produkt, als auch im ganzen Drumrum.