Mit all dem Gerede über das Delphi-Team, das an der plattformübergreifenden Entwicklung arbeitet, ist eine Stimmung, die immer wieder aufkommt: "Ich hoffe, sie machen es diesmal richtig, nicht wie Kylix." Ich habe Kylix nicht wirklich bemerkt, als es da war, denn Linux war damals noch nicht so ausgereift wie damals und es war einfach kein Betriebssystem, an dem ich Interesse hatte. Jetzt wird es wieder ein Problem , Frage ich mich, was hat Kylix falsch gemacht und wie konnte CodeGear es dieses Mal besser machen?
Es muss eine abstraktere Möglichkeit geben, Steuerelemente in Dialogen zu erstellen, nicht die pixelbasierten Elemente, die die VCL jetzt verwendet. Unter Windows mit hohen DPI-Einstellungen oder Nicht-Standard-Fonts bricht dies zusammen, bei Multi-Plattform-Programmen wird es viel schlechter. Nehmen Sie zum Beispiel die Sizer-Klassen in wxWidgets oder die Layoutklassen / -manager in GTK, Java oder QT - sie alle viel besser beim Ändern der Schriftarten oder Kontrollgrößen. Ein weiterer Vorteil besteht darin, dass übersetzte Texte in Steuerelementen, die kürzer oder länger sind, transparent arbeiten.
Machen Sie die Bibliotheken nur Unicode. Idealerweise würde es eine spezielle String-Klasse geben, die UCS-16 intern unter Windows, aber UTF-8 für Linux und Mac OS X verwendet. Ein Programm sollte mit der plattformeigenen Unicode-Codierung arbeiten können und keine Konvertierungen dafür benötigen jeder Dateisystemzugriff oder Bildschirmausgabe. Aber vielleicht haben sie schon den Ball mit der Unicode-String-Änderung für Delphi 2009 fallen lassen.
Die GUI sollte native Steuerelemente auf allen Plattformen verwenden, damit und richtig aussehen. Das wären die Standardsteuerelemente unter Windows, Cocoa auf dem Mac und unter Linux sollte idealerweise entweder GTK oder QT verwendet werden, je nachdem, welcher Desktop GNOME oder KDE ist.
Der Remote-Debugger muss ein erstklassiges Tool werden, nicht das Bug-Ridd und das Halb-Versteckte, was es jetzt ist. Die Entwicklung für verschiedene Plattformen findet häufig in VMs statt, manchmal gibt es nur Fernzugriff auf Maschinen.
Kylix hatte zwei Dinge dagegen: Die weit verbreitete Akzeptanz von Linux auf dem Desktop war einfach noch nicht da und Kylix selbst war sehr teuer. Werfen Sie Kylix's fragwürdige Qualität (besonders die erste Version) und Sie haben Ihre Antwort.
Wenn CodeGear eine andere Version von Delphi unter Linux ausführen möchte, sollte er sich Lazarus / p>
Ich habe zu der Zeit (und noch immer) an der Free Pascal Unix RTL gearbeitet, die Pascal vor * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * vor Kylix hatte, und wir haben es von der ersten Beta an genau beobachtet. Man könnte also sagen, dass ich eine gute und einzigartige Perspektive auf den Aufstieg und Fall von Kylix hatte.
Ein Hauptproblem ist, dass es nicht auf die Verwendung von Server-Apps ausgerichtet war, die Hauptsache, die die Leute zu der Zeit unter Linux machten, aber IMHO, die den Fehler nicht erklärt.
Während es verschiedene andere Probleme gab (Wine, Deployment, sehr Linux / x86-zentrisch, so dass es schwieriger war, auf den "nächsten" * nix zu portieren, Borland schob es nicht genug), denke ich immer noch, dass Kylix gescheitert ist ein Beweis für die Probleme von Linux zu dieser Zeit als ein direktes Ergebnis von Kylix-Problemen. Einige davon (wie die langfristige binäre API-Stabilität) wurden noch nicht behoben.
Trotzdem hätte es funktionieren sollen IMHO, da es eindeutig den anderen vorausging, und praktikabel, und wenn die Nachfrage wirklich da gewesen wäre, wären die Leute aufgestanden (und einige haben, wir bekomme immer noch monatliche Leute auf den FPC-Listen, die große Kylix-Codebasen konvertieren).
Eine serverorientierte Version könnte ein größerer Erfolg gewesen sein, und sie vermarkteten ein bisschen zu stark auf der Single-Source-Sache (was die Erwartungen falsch weckte), aber das GUI-Prinzip, wie es ist, hätte IMHO funktionieren sollen, und ich beschuldige Linux und der Linux-Markt. Zu früh, Markt zu gehypst, und noch nicht bereit für die Vermarktung nach einem Windows-Modell.
Meiner Meinung nach gehen plattformübergreifende native & amp; gehostet (VM) wäre gut für Delphi; Es gibt jedoch den Haken, dass es vor der Umsetzung gut durchdacht sein muss. (Im Allgemeinen waren die Turbo Pascal-Versionen IMO ... obwohl einige der Zusätze zur Delphi-Sprache nicht waren; Fall-in-Punkt kann man Eigenschaften in Schnittstellen nicht deklarieren, um gelesen zu werden und / oder nur zu schreiben, ohne auch WAS zu erklären Die Quelle der Eigenschaft war entweder ein Feld oder eine Methode, die in der Schnittstelle deklariert werden musste. IE war / war eine gute Idee ... aber sie vergaß die Schnittstelle / Implementierung vollständig zu trennen.)
Also, IMO, was benötigt wird:
1 - Eine VCL- / TurboVision- / GeneralPurpose-ähnliche Bibliothek, die plattformunabhängig ist. (Die VCL ist wirklich ein gutes Beispiel für objektorientierte Hierarchien; genau wie Turbo-Vision [für seine Zeit] ... hat auch das Fernsehen Streams eher interessant eingeführt und benutzt.) Um es nochmals zu sagen:
a) Eine gute objektorientierte Hierarchie sichtbarer Komponenten ... vielleicht auch ein "Prozent" / relatives / vektorgraphisches Schema als das aktuelle Pixel eins. (Dadurch werden die Disparitäten der Bildschirmauflösung ausgeglichen.)
b) Objekte, die "wissen", wie sie ihre enthaltenen Objekte initialisieren und freigeben (obwohl Zeiger auf Objekte ausgenommen wären, da wir Objekte "teilen" möchten), also die Einrichtung von Konstruktoren, die initialisiert werden sollen Destruktoren zum Freigeben der enthaltenen Objekte werden nicht benötigt. {IE, Optimieren Sie den häufigen Fall.}
c) Die nicht-visuellen Komponenten wie TList, TStringList und so weiter sollten implementiert werden ... obwohl ADTs wie Stack, Queue, PriorityQueue, Heap, Tree & amp; BTree. Als eine persönliche Frage, können wir sie 1-basiert und nicht 0-basiert machen? Ich frage das, weil es bei der Suche durch sie schöner wäre, wenn 0 "nicht gefunden" wäre und eine positive Zahl der Index wäre, während man vorzeichenlose Zahlen verwendet, viel Stil von ShortStrings. Dies hat auch den Vorteil, dass die maximal zulässige Größenbeschränkung nicht halbiert wird, wie dies bei Verwendung von vorzeichenbehafteten Zahlen der Fall wäre.
d) Objekte sollten in der Lage sein, auf der niedrigsten möglichen Ebene selbst zu senden und sich selbst in einen Stream zur Rekonstruktion am anderen Ende zu senden / zu löschen. {Schwer zu implementieren, vielleicht; aber die TurboVision API hat es mit seinem Registrierungsschema gemacht ... mit RTTI involviert sollte es etwas einfacher sein.}
e) Die oben genannten ADTs sollten auch eine allgemeine Spiegelungsschnittstelle heirchy haben, so dass etwas wie TStringList Ihnen eine Liste von Strings gibt, deren übereinstimmende Objekteigenschaften Objekte vom Typ TIntergerObject sind.
f) Container-Typen, wie der Stack oder StringList, sollten auch ihren enthaltenen Typ kennen; und ob sie homogen sind oder nicht.
g) Ein Parser-Objekt-Unterbaum auf dem nicht-visuellen Objektbaum, der vererbbar und verallgemeinert ist (vielleicht einen, der BNF "isst" und die Eingabe entsprechend analysiert ... ein HUGE-Projekt an sich.
Ich weiß, dass das eine große Aufgabe ist und viel Arbeit. Allerdings wäre die Auszahlung auch immens. Eine JVM könnte ein Stack-Objekt und ein Parser-Objekt sein, das den Quellcode in die entsprechenden Objekte übersetzt, die auf den Stack geschoben werden sollen. Ein Forth-Compiler / Interpreter könnte auf dieselbe Weise mit mehreren Stacks und einem Forth-Parser-Objekt implementiert werden . Sie sehen offensichtlich, wo das hinführt: eine vielseitige und verallgemeinerte ADT-Bibliothek an der Basis zu haben und damit den Rahmen zu bilden, dass die nächste Iteration von RAD Studio auf einen Schlag nicht nur ein Konkurrent von .NET für seine "jede Sprache" werden könnte. Idee, aber auch für mehrere Archetkturen im Backend. (Ja, es gibt das Sizing- und Endian-Problem, aber die Idee von High-Level-Sprachen besteht darin, den Programmierer von diesen Problemen zu entfernen, es sei denn, er konzentriert sich besonders auf sie. Diese Probleme könnten gut gelöst werden, indem das Delphi-Byte, Integer, LongInt-Größen stabil, wie es derzeit ist [möglicherweise NativeInteger, NativeLongInteger usw. verwenden, wenn die maschinenabhängigen Typen / Größen benötigt werden] und indem die TStream-Nachkommenobjekte für Dateien das Speichern und Abrufen von Delphi- / RAD-nativen App-Daten verarbeiten und abgeleitet von denen, wenn ein bestimmter Endian für das Format benötigt wird.)
Ich kaufte Kylix, als es zuerst herauskam - es lief sehr langsam, sah klobig aus und unterstützte tatsächlich nur einige spezifische Versionen von Linux. Ehrlich gesagt gab und gibt es bessere Linux-Tools. Aber ich denke, es wird für jeden immer schwieriger, mit dem Verkauf von Entwicklungswerkzeugen Geld zu verdienen, egal welche Plattform - die kostenlosen Alternativen sind einfach so gut.
Was ich an Kylix und VCL für Web (Intraweb) hasste, ist, dass sie Komponenten haben, die wie die Standardkomponenten aussehen ....
Die VCL ist selbst ziemlich allgemein (mit Ausnahme der Handles) ... Also würde ich den gleichen Quellcode haben wollen, den gleichen pas, dfm, dpr .... und durch Auswählen einer Compiler-Option wählen Sie die zu erstellende Plattform für oder mit unterschiedlichen Quellprotokollen für jede Plattform mit den gleichen Quelldateien.
Linux war nicht bereit, Software kommerzieller Qualität zu handhaben. Das bemerkenswerteste Problem ist die fehlende Binärkompatibilität. Es galt dann, es gilt noch immer.
Danny Thorpe, Delphi / Kylix R & amp; D, schrieb 2001 einen emotionalen Artikel:
Problem: Linux-Bibliotheken können ' t Fail
Tags und Links delphi cross-platform