Ist Delphi so Bedeutungslos ?

[Robotiker]

Zitat von Medium:

U
Das ganze Thema ist doch eigentlich sowas von Zentral! Wenn diese Dinge alle passen würden, da würde doch kein Hahn mehr nach Preisen krähen - dann wäre Delphi im Enterprise-Segment "der Shit", egal ob Neulinge jetzt mit Java, C# oder Python groß geworden sind. Business würde dann Delphi sprechen.

Das stimmt.

Ich frag mich immer wieder, welchen "Business" eigentlich Produkte wie den C++ Builder benutzt. Da gibt es jetzt endlich in XE3 einen 64-Bit Compiler. Der versteht endlich auch den aktuellen ISO-Standard. Gleichzeitig lässt man den 32-Bit Compiler so wie er ist, er unterstützt nicht mal den vorletzten Standard richtig. Wenn man also 32 und 64 Bit Versionen seiner Software herausbringen will, ist man gezwungen zwei Codebasen zu pflegen, oder einen Weg des kleinsten gemeinsamen Nenners zu finden.

Wenn ich die Newsgroup Beiträge von Emba Mitarbeitern richtig interpretiere, soll das auch erst mal so bleiben, bis irgendwann nach einem neuen Delphi Compiler auch ein neuer 32 Bit C++ Compiler kommt. Außerdem verweist man darauf, die meisten Windows PCs hätten heute sowieso 64 Bit. Sinnigerweise kann man aber für den Mac nur den alten 32 Bit Compiler liefern.

Zum Glück gibt es genügend andere C++ Entwicklungstools, der Builder spielt eigentlich keine Rollle mehr. Trotzdem frage ich mich weiter, welche Großkunden sich so ein Trauerspiel bieten lassen, irgendwer muss das Zeug doch kaufen ?

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

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

[Unx]

Zitat von 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.

Schon mal probiert deine unmengen an Komponenten in FireMonkey zu nutzen?
Damit schießt sich Delphi wohl nach deiner Ansicht auch selbst ins bein.