Was ich an Delphi überhaupt nicht mag

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:

  1. Die Unicode-Unterstützung in Delphi ist gelinde gesagt räudig. Da helfen auch keine Verweise auf Komponenten anderer Hersteller!
  2. 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.
  3. 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.
  4. Keine Operatoren und damit konsequenterweise kein Überladen von Operatoren.
  5. 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

This entry was posted in DE, Programming, Software. Bookmark the permalink.

13 Responses to Was ich an Delphi überhaupt nicht mag

  1. CodeGier says:

    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

  2. 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 😀

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

  4. Oliver says:

    Dann erzähle mal zu Punkt drei wo ich gucken muß. Scheint mir zu entgehen. Und bitte nicht “object” sagen 😉

    // Oliver

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

  6. Oliver says:

    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

  7. 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…?

  8. Oliver says:

    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

  9. Oliver says:

    Okay, gerade gefunden:

    Though records can now share much of the functionality of classes, there are some important differences between classes and records.

    Records do not support inheritance.
    Records can contain variant parts; classes cannot.
    Records are value types, so they are copied on assignment, passed by value, and allocated on the stack unless they are declared globally or explicitly allocated using the New and Dispose function. Classes are reference types, so they are not copied on assignment, they are passed by reference, and they are allocated on the heap.
    Records allow operator overloading on the Win32 and .NET platforms; classes allow operator overloading only for .NET.
    Records are constructed automatically, using a default no-argument constructor, but classes must be explicitly constructed. Because records have a default no-argument constructor, any user-defined record constructor must have one or more parameters.
    Record types cannot have destructors.
    Virtual methods (those specified with the virtual, dynamic, and message keywords) cannot be used in record types.
    Unlike classes, record types on the Win32 platform cannot implement interfaces; however, records on the .NET platform can implement interfaces.

  10. 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…

  11. Das sollte eben natürlich “DateTime” nicht “TDateTime” heissen, weil man sonst ja den nativen Delphi Typ bekommt

  12. Oliver says:

    “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:

    • Records do not support inheritance.
    • Records allow operator overloading on the Win32 and .NET platforms; classes allow operator overloading only for .NET.
    • Record types cannot have destructors.
    • Virtual methods (those specified with the virtual, dynamic, and message keywords) cannot be used in record types.
    • Unlike classes, record types on the Win32 platform cannot implement interfaces; however, records on the .NET platform can implement interfaces.

    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.

  13. Oliver says:

    Finde ich uebrigens eine Frechheit das nicht auch in BDS 2006 zu fixen. Immerhin ist das nicht gerade billig.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.