DeHL Entwicklung eingestellt

[mjustin]

Die Projektseite http://code.google.com/p/delphilhlplib/ sagt:

Zitat:

DeHL is discontinued. You can reuse parts of this project for whatever particular needs you have. The source code is BSD licensed.

In seinem Blog (http://alex.ciobanu.org/) schreibt der Entwickler am 3. Januar 2012:

Zitat:

DeHL — A collection of code built around the concept of “type objects”. Unfortunately, DeHL only stirred some architectural interest in the Delphi community. It did not actually attract many active users or contributors. ... But, unless someone steps up and takes over, DeHL is effectively dead.

[Insider2004]

Das wundert mich jetzt nicht. DEHL läuft nur mit den neuen Delphi-Compilern und ist ziemlich kompliziert. Das widerspricht dem Pascal-anstatz. Die neuen Delphi-Sprachfeatures (anonyme Methoden etc.) haben sich bisher sowieso weniger durchgesetzt. Der Pascal-Programmierer liebt es halt einfach.

[jaenicke]

Zitat:

Zitat von Insider2004 (Beitrag 1147093)

Die neuen Delphi-Sprachfeatures (anonyme Methoden etc.) haben sich bisher sowieso weniger durchgesetzt. Der Pascal-Programmierer liebt es halt einfach.

Gerade diese Features machen es ja sehr viel einfacher. Theoretisch zumindest...

Das Problem war nur, dass es relativ viele Bugs gab, z.B. dass in anonymen Methoden als Parameter bei XE generell die erste Ebene der Syntaxvervollständigung nicht funktionierte. Viele solcher Probleme sind aber bei XE2 behoben, so auch dieses.

Zumindest in unseren Quelltexten nutzen wir seit XE dennoch häufig Generics, anonyme Methoden, die aktuellen Rtti-Features, ...
Und wenn ich so die Posts von himitsu und anderen lese, sieht das bei anderen ja wohl auch ähnlich aus. ;-)

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1147097)

Das Problem war nur, dass es relativ viele Bugs gab, z.B. dass in anonymen Methoden als Parameter bei XE generell die erste Ebene der Syntaxvervollständigung nicht funktionierte. Viele solcher Probleme sind aber bei XE2 behoben, so auch dieses.

Für Komponentenhersteller wird aber eher das Problem bestehen das sie noch bis D6/7 dies Sammlungen anbieten.
Und da wird man dann alle Quellcode ohne entsprechende Sprachfeatures verwenden.

Zitat:

Zitat von jaenicke (Beitrag 1147097)

..., die aktuellen Rtti-Features, ...

Diese erweiterte Rtti hat aber den Nachteil die Exe's riesig werden zu lassen :-(

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Für Komponentenhersteller wird aber eher das Problem bestehen das sie noch bis D6/7 dies Sammlungen anbieten.
Und da wird man dann alle Quellcode ohne entsprechende Sprachfeatures verwenden.

Das sehe ich z.B. als ein großes Manko an!

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Diese erweiterte Rtti hat aber den Nachteil die Exe's riesig werden zu lassen :-(

Na und? Die Größe einer Exe-Datei ist doch sowas von egal, wenn ich damit im Gegenzug einen deutlichen Programmiervorteil erreichen kann. Die Zeiten von 640kB Hauptspeicher sind doch lange vorbei.

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1147125)

Das sehe ich z.B. als ein großes Manko an!

Das die Komponentenanbieter das so machen, oder was meinst du damit genau?

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Na und? Die Größe einer Exe-Datei ist doch sowas von egal, wenn ich damit im Gegenzug einen deutlichen Programmiervorteil erreichen kann. Die Zeiten von 640kB Hauptspeicher sind doch lange vorbei.

Unsere D6-Exe ist 12-15 MB groß. Eine 50 MB Exe wäre nicht gerade von Vorteil (konnte bisher noch nicht das Hauptprogramm erfolgreich mit XE2 compilieren um den genauen Großenzuwachs mit und ohne Extended RTTI zu sehen

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Für Komponentenhersteller wird aber eher das Problem bestehen das sie noch bis D6/7 dies Sammlungen anbieten.
Und da wird man dann alle Quellcode ohne entsprechende Sprachfeatures verwenden.

Wenn sich die Hersteller den Produktivitätsverlust leisten können und wollen ist ja alles ok. Schlecht ist nur, dass die dadurch entstehenden Entwicklungskosten sich nicht in den Versionen für die alten Delphiversionen wiederspiegeln, sondern meistens auf alle Käufer umgelegt werden...

[Uwe Raabe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147127)

Zitat:

Zitat von Uwe Raabe (Beitrag 1147125)

Das sehe ich z.B. als ein großes Manko an!

Das die Komponentenanbieter das so machen, oder was meinst du damit genau?

Genau! Wenn sie es denn so machen. Es gibt schon ein paar Bibliotheken, die die neuen Features nutzen und somit auch nur mit den neuen Delphi-Versionen verwendet werden können. So ist z.B. Asphyre Sphinx in der neuen Version nur für XE2 verfügbar - und das ist auch gut so! Wer unbedingt auf älteren Delphi-Versionen entwickeln will, kann ja dazu auch die älteren Versionen der Bibliotheken nehmen. Neuentwicklungen sollte man eh nicht mit veralteten Werkzeugen ausbremsen - meine Meinung.

Die Krux liegt m.E. in der Gepflogenheit vieler Entwickler, die neuen Features oder Vorgaben neuer Versionen sozusagen mit "einzupatchen", anstatt direkt darauf aufzubauen ("deprecated" Warnungen beim Compileren). Wenn denn unbedingt ältere Versionen unterstützt werden müssen, dann muss man eben diese "einpatchen", über IFDEF anderen Code ausführen oder bestimmte Features eben dort ganz weglassen. Dann sieht man auch sofort, welche Versionen zu aufwändig mitzuziehen sind, und gibt deren Support vielleicht eher auf. Als Ergebnis hätte man wesentlich besser auf neue Versionen abgestimmte Bibliotheken. Auf der anderen Seite könnte das auch den Druck auf die Verwender älterer Versionen erhöhen, endlich ein neues Delphi zu erwerben und auch einzusetzen.

Natürlich ist das jetzt meine reine Entwicklersicht auf die Dinge - kaufmännisch mag es da noch andere Kriterien geben, auf die ich in meiner Betrachtung hier keine Rücksicht genommen habe.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1147109)

Unsere D6-Exe ist 12-15 MB groß. Eine 50 MB Exe wäre nicht gerade von Vorteil (konnte bisher noch nicht das Hauptprogramm erfolgreich mit XE2 compilieren um den genauen Großenzuwachs mit und ohne Extended RTTI zu sehen

Und wenn es nun 50MB werden, wo lägen dann ganz konkret die Nachteile? Würden diese Nachteile den Verzicht auf ein so mächtiges Werkzeug wie RTTI wirklich rechtfertigen? Kannst du abschätzen, was dir das alles für Möglichkeiten eröffnet? Womöglich kannst du deinen Sourcecode damit ganz gehörig eindampfen.

Nur mal als Vergleich: bei einer meiner Anwendungen ist die Exe ausgehend von D7 bis nach XE2 (trotz RTTI und Unicode) gerade mal 25% größer geworden (9 -> 11,3 MB). Den erzeugten Mehrwert kann ich hier jetzt nicht beziffern, aber anhand der Kundenreaktionen würde ich ihn sicher über 25% ansiedeln. Als "Nebeneffekt" ist der Code auch wesentlich übersichtlicher und leichter wartbar geworden. Man muss nur mal den Mut haben, alte Zöpfe abzuschneiden.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1147128)

Und da wird man dann alle Quellcode ohne entsprechende Sprachfeatures verwenden.

Wenn sich die Hersteller den Produktivitätsverlust leisten können und wollen ist ja alles ok. Schlecht ist nur, dass die dadurch entstehenden Entwicklungskosten sich nicht in den Versionen für die alten Delphiversionen wiederspiegeln, sondern meistens auf alle Käufer umgelegt werden...[/QUOTE]
Die meisten Komponentensammlungen werden wohl nicht mit 2010/XE(2) Neuentwicklungen sein sondern Weiterentwicklungen. D.h. man wird schrittweise neue Features einbauen und bei diesem Einbau sich überlegen ob man wegen dieser (erstmal verglichen mit dem Rest der Kompos) kleinen Features gleich D6-D2009 von den neuen Versionen abschneidet.

[Furtbichler]

Wobei man keins der "neuen" Features wirklich benötigt. Es erleichtert vielleicht etwas die Arbeit und in einer Softwareproduktion wird man effektiver arbeiten, aber ein Framework entwickeln geht auch mit den Sprachfeatures von Delphi 3. Wobei ich natürlich nicht von der IDE rede.

[Bernhard Geyer]

Zitat:

Zitat von Uwe Raabe (Beitrag 1147137)

Wer unbedingt auf älteren Delphi-Versionen entwickeln will, kann ja dazu auch die älteren Versionen der Bibliotheken nehmen. Neuentwicklungen sollte man eh nicht mit veralteten Werkzeugen ausbremsen - meine Meinung.

Bis vor 2-3 Jahren war auch Win98 auch noch zu unterstützen. Damit war alles > D2007 außen vor...

Zitat:

Zitat von Uwe Raabe (Beitrag 1147137)

Die Krux liegt m.E. in der Gepflogenheit vieler Entwickler, die neuen Features oder Vorgaben neuer Versionen sozusagen mit "einzupatchen", anstatt direkt darauf aufzubauen ("deprecated" Warnungen beim Compileren). Wenn denn unbedingt ältere Versionen unterstützt werden müssen, dann muss man eben diese "einpatchen", über IFDEF anderen Code ausführen

Was mehr Code und mehr potentielle Fehlerquellen darstellt.

Zitat:

Zitat von Uwe Raabe (Beitrag 1147137)

Und wenn es nun 50MB werden, wo lägen dann ganz konkret die Nachteile?

Nicht überall hast du Gigabit-Ethernet oder neue Prozessoren/HW zur verfügung.

Zitat:

Zitat von Uwe Raabe (Beitrag 1147137)

Kannst du abschätzen, was dir das alles für Möglichkeiten eröffnet? Womöglich kannst du deinen Sourcecode damit ganz gehörig eindampfen.

Klar weiß ich das. Bei unserem Java-Port nutzen wir gleich die Möglichkeiten die Java schon lange bietet :-)

Zitat:

Zitat von Uwe Raabe (Beitrag 1147137)

Nur mal als Vergleich: bei einer meiner Anwendungen ist die Exe ausgehend von D7 bis nach XE2 (trotz RTTI und Unicode) gerade mal 25% größer geworden (9 -> 11,3 MB).

25% sind akzeptabel. Unicode wären bei uns keine Faktor da wir mit ElPack Unicode schon seit ca. 10 Jahren einsetzen.

[Thom]

Zitat:

Zitat von Uwe Raabe (Beitrag 1147137)

Man muss nur mal den Mut haben, alte Zöpfe abzuschneiden.

Noch mehr Mut gehört dazu, nicht jede neue Frisur mitzumachen, nur weil irgend jemand sagt, sie sei modern, in, hip, angesagt, cool... 8-)

[mkinzler]

Aber auch nicht auf nützliche Features zu verzichten, nur weil man sie früher auch nicht gebraucht hat

[Thom]

Das zeugt aber meist - nicht immer - nur davon, daß man die "alten" Möglichkeiten nicht genügend beherrscht und meint, das Problem nur mit den "neuen" Features lösen zu können... :lol:

[jaenicke]

Zitat:

Zitat von Thom (Beitrag 1147175)

Das zeugt aber meist - nicht immer - nur davon, daß man die "alten" Möglichkeiten nicht genügend beherrscht und meint, das Problem nur mit den "neuen" Features lösen zu können... :lol:

Wie das in Delphi gehen soll, ist mir nicht wirklich klar.

Aber es macht halt einen Unterschied, ob man etwas in 10 Stunden in Delphi 7 implementiert oder mit einem Bruchteil an Code in 6 Stunden in Delphi XE2. Natürlich könnte man auch mit alten Delphiversionen alles entwickeln. Wie ich schon sagte: Wer sich das leisten kann, bitte, aber im Normalfall ist Entwicklungszeit dafür zu teuer.

Deshalb würden wir nie auf die Idee kommen wieder die alten Versionen auszupacken. Die Produktivität hat bei uns seit dem Kauf von XE einfach drastisch zugenommen, und noch dazu ist der Code schon alleine durch Generics um einiges kürzer und besser wartbar.

Manche Projekte sind noch in Delphi 5 oder 2006 geschrieben und nicht aktualisiert, so dass es auch manchmal in gemeinsamen Units IFDEFs dafür gibt. Das sieht dann typischerweise so aus, dass für XE eine oder wenige Zeilen da stehen und für die alten Versionen die 3-5 fache Menge an Code.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1147179)

Aber es macht halt einen Unterschied, ob man etwas in 10 Stunden in Delphi 7 implementiert oder mit einem Bruchteil an Code in 6 Stunden in Delphi XE2. Natürlich könnte man auch mit alten Delphiversionen alles entwickeln. Wie ich schon sagte: Wer sich das leisten kann, bitte, aber im Normalfall ist Entwicklungszeit dafür zu teuer.

Ich habe kürzlich erst ein altes Projekt auf XE2 gezogen ohne dies dem Kunden in Rechnung zu stellen. Dabei wurde auch gleich ein Haufen alter Komponenten (z.B. Orpheus) rausgeschmissen, die zwar noch leidlich unter XE2 laufen, aber mit neuen Features (z.B. VCL-Styles) nicht mithalten können. Die Anwendung sieht nun bei nahezu identischer Funktionalität wesentlich moderner und frischer aus. Der Kunde war hellauf begeistert und seitdem bekomme ich deutlich mehr Änderungs- und Ergänzungsaufträge für dieses Projekt, da ich diese nun wesentlich preisgünstiger realisieren kann. Früher war ihm jede Änderung einfach zu teuer für das, was sie gebracht hätte. Der Kunde ist nun zufrieden und mir macht die Arbeit an dem Projekt wieder Spaß. Den Portierungsaufwand habe ich längst wieder raus. In der Zeit, die ich früher in D7 für ein Feature gebraucht habe, schaffe ich heute in XE2 zwei bis drei vergleichbare. Ich kann Terminzusagen machen (und auch einhalten), bei denen meine Mitbewerber (und manche Kunden selbst) nur den Kopf schütteln.

Ach übrigens: was meine Frisur betrifft, gelte ich gemeinhin als ziemlich konservativ. Die unübersehbaren Veränderungen sind rein biologischer Natur.

[himitsu]

Zitat:

Zitat von Furtbichler (Beitrag 1147153)

Wobei man keins der "neuen" Features wirklich benötigt. Es erleichtert vielleicht etwas die Arbeit und in einer Softwareproduktion wird man effektiver arbeiten, aber ein Framework entwickeln geht auch mit den Sprachfeatures von Delphi 3. Wobei ich natürlich nicht von der IDE rede.

Ja, man kommt auch ohne aus, aber die Vereinfachung liegt nicht immer nur im Aufwand des Schreibens.
Einige Features vermeiden auch Fehler.

Mein Cheffchen hat es grade auch gemerkt. Generigs z.B. sind ganz nett, aber man muß sich schon etwas umgewöhnen.
Vorteil einer generischen TObjektList ist z.B. der, daß man selber nicht mehr wild rumcasten muß, da der Typ direkt schon vorgegeben ist.

weniger unsichere Casts = mehr Typ-Sicherheit im Code
und der Code wird auch teilweise etwas übersichtlicher, da Code letztendlich kürzer wird.

[Stevie]

Wenn man Alex' Blog verfolgt hat, wird man wissen, welche anderen Gründe dazu führten, dass er letztlich DeHL eingestellt hat.

Der Größenanstieg der EXE ist auch nicht allein der enhanced RTTI zuzuschreiben (welcher natürlich auch eine Rolle spielt), sondern auch den Generics. Durch die Art der Implementierung dieser wächst bei jedem neuen generischen Typ die Binary, auch wenn der Code für TList<TAuto> genauso ist wie bei TList<TFahrrad>. Das führt bei Source wie bei DeHL (und auch bei Collections) der Fall zu exorbitanten Größen (und wir reden hier bei massiver Nutzung von Generics über Größen jenseits der 50MB).

Nichtsdestotrotz hat Alex schon vor einiger Zeit ein Spin-Off Projekt für das meist genutzte Feature von DeHL (die mir persönlich auch etwas zu klobig erschien), nämlich die generischen Listen, angelegt. Auch bei diesem haben sich des öfteren mal die Grenzen von Delphi gezeigt, was Closures und Generics angeht (allem voran natürlich 2010).