Unter Delphi wird es sich dann wohl weiterhin wie in den neunziger Jahren anfühlen, wenn man mit Fremdbibliotheken arbeitet.
Wenn du mit neunziger Jahre meinst, dass man sich darauf recht gut verlassen kann, dass die Projekte auch gepflegt und für neuere Versionen angepasst werden, bin ich voll dafür.
Was nützt es mir, wenn ich zwar alles abrufen kann, aber wie bei Torry tausende Leichen drin habe, die schon seit X Versionen nicht mehr funktionieren. Oder wenn ich eine Komponente für XE9 downloaden kann, diese aber für XE10 plötzlich nicht mehr verfügbar ist, weil sie niemand dafür angepasst hat.
Weniger ist an der Stelle (finde ich) eindeutig mehr...
Wie von mquadrat bereits angedeutet kann man es über Manifest-Dateien sicherstellen, dass nur die Komponenten angeboten werden, die mit der eingesetzten Delphi-Version funktionieren. Ebenso lässt sich über einen Download-Zähler und ein Bewertungssystem einiges an Frust ersparen, wenn man schon vor dem Download sieht, dass eine Komponente in zwei Jahren nur zehn mal heruntergeladen wurde.
Für den NuGet-Manager kann jeder Pakete hinzufügen und es funktioniert hervorragend. Ein Github-Repository kann automatisch mit NuGet synchronisiert werden und bleibt so stets aktuell. Als NuGet-User kann ich in meinem Projekt nach Updates suchen und erhalte Informationen zu allen eingesetzten Fremdbibliotheken. Der Wartungsaufwand ist gering. Wenn ein Paket nicht mehr passt oder fehlerhaft ist, finde ich für viele Aufgaben schnell eine passende Alternative.
In meinen C#-Projekten setze ich daher viel mehr fremden Code ein als in Delphi. Cryptographie, JSON-Serialisierung, Anbindung an diverse REST-Services,
GUI-Komponenten etc. erhalte ich per Knopfdruck genauso wie die dazugehörigen Aktualisierungen.
Bei Delphi muss ich wie in den neunziger Jahren und den frühen zweitausendern auch weiterhin regelmäßig die Projektseiten der eingesetzten Fremdkomponenten abklappern. Wenn eine Bibliothek nicht mehr weiterentwickelt wird, beginnt die große Suche nach Alternativen in diversen Delphi-Foren und auf Stackoverflow. Das ist mühselig und führt häufig genug dazu, dass in Delphi-Projekten möglichst wenig Fremdsource eingesetzt wird und das Entwicklerteam folglich Dinge implementieren muss, die tausende andere Entwickler bereits vor Jahren geschrieben haben. Ja, es hat auch Vorteile wenn ein Team allen genutzen Source selbst geschrieben hat. Aber mit "Rapid Application Development" hat das nichts zu tun.
RAD war die große Stärke von Delphi in seiner Hochzeit. Damals benötigte man für
RAD nur einen UI-Designer in der
IDE. Heute ist ein UI-Designer vernachlässigbar geworden. Durch automatisches Layouting lassen sich schöne GUIs auch schnell im Code schreiben.
Heute geht es bei
RAD eher darum
- bestehende ausgereifte Komponenten schnell und zuverlässig einsetzen zu können
- Code vernünfitg refactoren zu können
- Schnell durch große Projekte zu navigieren (Wo wird Klasse XY verwendet? Wer ruft Funktion x() auf? Wer implementiert Interface I? etc.)
- Schnell sehen können, ob und wo ein
Unit-Test fehlschlägt und welche Codezeilen gar nicht getestet werden
In all diesen Disziplinen hinkt auch Delphi XE8 der Konkurrenz weit hinterher. Mit
RAD hat das nichts mehr zu tun. Für eine marktreife Applikation (beginnend auf der grünen Wiese) brauche ich mit Delphi aufgrund der oben genannten Punkte heute erheblich länger als mit C# oder Java. Wo ist eigentlich das Alleinstellungsmerkmal von Delphi geblieben? Was ist das große Argument gegenüber C++, C# oder Java?
RAD ist es seit einigen Jahren nicht mehr.
Mit GetIt könnten sie zumindest ein bisschen in Richtung
RAD rudern aber daran haben sie offenbar kein Interesse.
Ich hoffte es kommt endlich ein Testrunner, der in die
IDE integriert ist und vielleicht eine CodeCoverage-Analyse für meine Testfälle.
An dieser Stelle möchte ich dich mal auf
TestInsight verweisen (XE8 Support ist in der nächsten Version in den kommenden Wochen).
Danke für den Link. TestInsight habe ich kurz mit XE6 angetestet als ich auf DelphiFeeds davon erfahren habe. Innerhalb von zwanzig Minuten habe ich es nicht ans Laufen gebracht und wieder entfernt. Vielleicht gebe ich dem Projekt in Zukunft noch mal eine Chance. Die Idee hinter dem Projekt halte ich jedenfalls für richtig.