Delphi ist eigentlich eine ganz angenehme Programmiersprache für die kleinen und großen Aufgaben des Programmierers. Leider haben Borland/Inprise/CodeGear wohl ungefähr 10 Jahre geschlafen.
Vornweg, ich habe mit Delphi auf Windows angefangen, nachdem ich zuvor auf DOS mit Assembler und Turbo Pascal schon einige Erfahrungen gesammelt hatte. Das hält mich allerdings nicht davon ab inzwischen fast ausschließlich C/C++ für jene Aufgaben zu benutzen bei denen als Ausgabe ein Binärprogramm erwartet wird. Wie kommt das? Nunja, fairerweise muß man vorwegschicken, daß ich beruflich natürlich ohnehin C/C++ benutzen muß und bei der Treiberprogrammierung Delphi ohnehin Unsinn ist. Allerdings ist zu einem nicht unwesentlichen Teil auch Delphi selbst dafür verantwortlich (bzw. der Hersteller).
Hier meine Hauptgründe:
- Die Unicode-Unterstützung in Delphi ist gelinde gesagt räudig. Da helfen auch keine Verweise auf Komponenten anderer Hersteller!
- Kein standardisierter Präprozessor (würde auch beim ersten Punkt helfen), dadurch keine Möglichkeit global einen Compiler-Schalter zu setzen und an alle Units weiterzureichen ohne Include-Dateien zu benutzen.
- Delphi kennt keine Stackobjekte. Alle Konstruktoren müssen explizit aufgerufen werden. Stackobjekte kann man nur mit Interfaces “emulieren” oder durch die Benutzung von Sprachelementen erreichen, welche aus Kompatibilitätsgründen noch enthalten sind – beides ziemlich eklige Angelegenheiten.
- Keine Operatoren und damit konsequenterweise kein Überladen von Operatoren.
- Keine Templates für Klassen und/oder Funktionen.
Da Delphi ja inzwischen zur Sprache geadelt wurde – “Delphi Language” eben – kann man durchaus einige Innovationen vom Hersteller erwarten, die sich allerdings bisher nicht zeigen. Stattdessen werden immer mehr immer neue Komponenten in das Programmpaket reingebrezelt und das zeigt sich auch schon bei vielen Amateurprogrammierern und Anfängern – die sind schon garnicht mehr in der Lage ohne Komponenten zu programmieren. Wohlgemerkt, die Tatsache es zu können bedeutet ja nicht, man müsse es immer anwenden (also ohne Komponenten zu programmieren). Allerdings bedeutet diese Fähigkeit, daß man sich mit dem darunterliegenden Betriebssystem auseinandersetzen muß. Inzwischen ist es nicht mehr so schlimm, aber vor einiger Zeit war ich immer wieder schockiert wie wenig einige selbsternannte Programmierer von dem System wissen für welches sie angeblich “programmieren”. Aber das ist wieder eine ganz andere Geschichte …
// Oliver
Hallo Oliver,
das ist ja dann wohl der Grund, warum man Dich im Delphi-Spotlight-Forum nicht mehr antrifft. Schade eigentlich. “Assas Geist” ist dort nämlich immer noch zu spüren…
Ciao
CodeGier
Hm, ich habe aus dem Artikel noch nicht mal alles verstanden.
Zum Glück war Olli vor Ort und hat es mir per IM erklärt 😀
Punkte 3 und 4 kann Delphi doch bereits seit der Version 2006…?
Ich könnt auch noch 100 Punkte aufzählen, die mir an Delphi nicht gefallen. Aber die beiden gehören eben nichtmehr dazu 🙂
Grüße
Dani
Dann erzähle mal zu Punkt drei wo ich gucken muß. Scheint mir zu entgehen. Und bitte nicht “object” sagen 😉
// Oliver
Records mit Funktionen?
type
TDateTime = record
private
FTicks: Int64;
public
function ToUTC: TDateTime;
property TotalSeconds: Double;
end;
So in der Art. Ich mach davon viel Gebrauch beim Emulieren von .Net Klassen unter Win32:
http://www.daniellehmann.net/net4native/
Grüße
Was hat das jetzt mit Stackobjekten zu tun?
{ CWaitCursor temp(hourGlass); // Mach was }Aufräumen passiert beim Verlassen des Scopes. Das ist ein Stackobjekt. Es wurde nicht mit new erzeugt oder wie in Delphi mit
bla := TKlasse.Create();
// Oliver
Nun der Unterschied ist halt, dass man sich in C++ beim Erzeugen eines Objektes entscheiden darf, während es in Delphi der Entwickler der Klasse entscheiden darf.
Vom Ergebnis her trotzdem das selbe, denn records mit Funktionen fühlen sich an wie Objekte und liegen auch nur auf dem Stack…?
Okay okay. Wo ist der Konstruktor bei den records? In C++ sind class und struct auch das gleiche, bis auf die Tatsache, daß bei class implizit alles private ist und bei struct implizit alles public. Aber dort habe ich eben auch einen (oder mehrere) Konstruktoren und einen Destruktor, wenn ich ihn brauche. Das ist ziemlich handlich, wenn man objektorientiert um eine C-API herumprogrammiert.
// Oliver
Okay, gerade gefunden:
Destructoren fehlen bei Records. Konstruktoren gibt es, allerdings müssen sie Parameter haben. Und man kann einen Record auch ohne Constructor benutzen.
🙂
Also im Prinzip alles da. Bei D2006 machen allerdings Compilerfehler die Benutzung recht kompliziert:
TDateTime.Create(2006, 1, 1).AddDays(1).TotalSeconds
sowas in der Art kann er nicht (unter Win32) 🙁 In D2007 gefixed, aber nur wegen dieses Fixes kauf ich mir kein Update…
Das sollte eben natürlich “DateTime” nicht “TDateTime” heissen, weil man sonst ja den nativen Delphi Typ bekommt
“Alles da” nennst du das? Wenn wir mal weglassen, dass es da diesen kleinen Bug gibt der in Delphi 2007 gefixt ist, haben wir noch:
Uebrigens interessiert mich immer nur Delphi for Win32, den Rest koennen’se knicken. Na gut, BCB vielleicht noch. Aber der Rest ist fuer mich mal eben uninteressant.
… das alles verstaerkt ja ehrlich gesagt meinen Eindruck, dass sich Delphi als ObjectPascal-Sprache in eine total falsche Richtung entwickelt. Tut mir leid, aber bei OOP erwarte ich ein wenig mehr als die Grundlagen. Ich meine C++ entwickelt sich auch staendig weiter. Aber vielleicht ist das gerade das Problem, Borland/Inprise/Borland/CodeGear/was-auch-immer-die-sich-gerade-schimpfen die einzigen sind die ueber die Sprache entscheiden (insbesondere seit man “Delphi” in den Rang einer Sprache erhoben hat). Bei C++ sind sowohl Anwender als auch die die es implementieren und diverse Experten involviert. Bei Delphi sind es ein paar Hanseln bei Borland/…, die natuerlich nur an ihr eigenes Produkt denken und keinen Deut weiter. Als Lohn werden sie dann auf Community-Treffen als Vordenker, Visionaere und Evangelisten … yaddayadda … gehypt, aber leisten tun die eigentlich nur was fuer ihre eigenen Produkte. Alles in allem schwach.
// Oliver
PS: Das mit dem Praeprozessor muss ich mal im Laufe des Abends testen.
Finde ich uebrigens eine Frechheit das nicht auch in BDS 2006 zu fixen. Immerhin ist das nicht gerade billig.