Zitat von Sherlock:

Und bitte nicht vergessen, das Fixen hört auf, sobald die Entwicklung der nächsten Version in die Beta-Phase gegangen ist.

und bitte nicht vergessen: genau das soll sich jetzt ändern: http://blog.marcocantu.com/blog/2015...scription.html

Zitat:

On-going maintenance, that is updates and hot fixes for versions before the last so you can keep working on a version and have critical bugs fixes for much longer time (up to 2 years) than today

kann man mögen oder nicht.

Und ja: Ich bin auch nicht ganz glücklich über die Situation. Aber Emba hat halt keine Mrd Umsätze mit denen sie eine IDE quer finanzieren können. Und ich bin auch am überlegen ob ich noch weiter auf Delphi setze.

Fakt ist aber: auch als "normaler" Desktop-VCL Entwickler geht ohne Subscription fast nichts mehr. Wenn ich alle 2-3 Jahre eine Delphi-IDE kaufe (erst dann würde es irgend wann billiger als die Subscription werden) - was soll man denn machen wenn die so instabil ist, dass ein arbeiten kaum möglich ist (XE7).

Ich grätsche mal mit einer anderen Frage zu XE8 rein: Der "GetIT"-Paketmanager:

• Das was ich angezeigt bekomme wird von wem verwaltet?
• Wie könnte ich, als Gutmensch für die ganze Welt meine Freeware-Komponente da mit aufnehmen lassen?
• Ist das nur für Freeware gedacht oder kann ich damit rechnen, auch Dinge wie TeeChart oder FastReport darüber beziehen zu können?

Zitat von Der schöne Günther:

Ich grätsche mal mit einer anderen Frage zu XE8 rein: Der "GetIT"-Paketmanager:

• Das was ich angezeigt bekomme wird von wem verwaltet?
• Wie könnte ich, als Gutmensch für die ganze Welt meine Freeware-Komponente da mit aufnehmen lassen?
• Ist das nur für Freeware gedacht oder kann ich damit rechnen, auch Dinge wie TeeChart oder FastReport darüber beziehen zu können?

Aktuell wird das von Emba verwaltet. Der Submission-Prozess ist noch nicht festgelegt. Laut Marco wird das jetzt vorgezogen, weil so viele Leute danach gefragt haben. Meine Frage was da überhaupt rein soll, wurde noch nicht beantwortet

Zitat von Der schöne Günther:

Der "GetIT"-Paketmanager:

• Wie könnte ich, als Gutmensch für die ganze Welt meine Freeware-Komponente da mit aufnehmen lassen?

Gedacht ist es für die größeren Komponenten-Sammlungen oder für bekannte Einzelkomponenten (wie etwa den VirtualTreeView). Ein weiteres Datengrab wie Torry mit gefühlten 4 Millionen Komponenten für Delphi 1-3 soll ausdrücklich nicht entstehen. Zudem muss es für alle Einträge einen verbindlichen Ansprechpartner geben, der den Code (weitgehend) aktuell hält. Damit sind nicht unbedingt tägliche Updates gemeint, aber doch die mittlerweile halbjährlichen Anpassungen an die Releases.
Für einen Individual-Entwickler einer ... sagen wir ... "Durchschnittskomponente" sehe ich da wenig Chancen - und als GetIt-Nutzer finde ich diese grobe Richtung auch prinzipiell richtig.

Zitat von Daniel:

Für einen Individual-Entwickler einer ... sagen wir ... "Durchschnittskomponente" sehe ich da wenig Chancen - und als GetIt-Nutzer finde ich diese grobe Richtung auch prinzipiell richtig.

Ich finde das sehr schade. Wenn ich mir anschaue, was ich im .NET-Umfeld über NuGet-Packages alles beziehen kann, dann bringt mich der GetIt-Paketmanager nicht weiter. Unter Delphi wird es sich dann wohl weiterhin wie in den neunziger Jahren anfühlen, wenn man mit Fremdbibliotheken arbeitet.

Ich habe mir XE8 jetzt auch mal angeschaut und bin entsetzt. Castalia wirkt reingeklatscht. In der Feature-Matrix wird Castalia in etwa zehn Einträgen direkt oder indirekt erwähnt. Die Refactoring-Methoden sind weiterhin unbrauchbar. Der Test in einem realen großen Projekt einen Methoden-Parameter um zu benennen, führt zuverlässig zu einem IDE-Absturz. Die "Extract-Method"-Funktion produziert weiterhin Müll. Was bringt mir eine Prozedur mit einem Var-Parameter? Wer will denn damit arbeiten?
Positiv ist, dass die IDE nicht mehr wegen zu wenig Speicher abstürzt, wenn eine große Projektgruppe (>=3 Echte-Welt-Projekte) kompiliert. Das war es dann aber auch. Die Liste gefixter Bugs beinhaltet nur einen Bruchteil der jahre alten Compiler- und VCL-Fehler.
Bei der DUnitX-Integration war ich zunächst sehr erfreut. Ich hoffte es kommt endlich ein Testrunner, der in die IDE integriert ist und vielleicht eine CodeCoverage-Analyse für meine Testfälle. Stattdessen gibt es ein Projekttemplate für den DUnitX-Command-Line-Testrunner.
Was gibt es also für große Neuerungen für einen Nur-Windows-Entwickler?
- Ein minimalistischer nicht offener Paketmanager
- Ein vorinstalliertes Editor-Plugin, das nicht richtig funktioniert
- Direkte DUnitX-Unterstützung ohne moderne IDE-Integration

Habe ich etwas vergessen? Wahrscheinlich nicht, wenn selbst Embarcadero die überarbeitet Startseite mehrfach in der Feature-Matrix nennt. Offenbar mussten sie krampfhaft nach nennenswerten Einträgen suchen, damit die Liste nicht so leer aussieht. Insgesamt wirkt auch die neueste Version von Delphi völlig veraltet und fehlerhaft. Wer mal mit Visual Studio oder NetBeans ein Projekt C# oder Java umgesetzt hat, wird wissen, in welchen Bereichen Delphi in Puncto IDE und Sprachfeatures hinterher hinkt.

Mir kommt es ehrlich so vor als ob es Embarcadero völlig egal ist, wie oft das Produkt noch verkauft wird. Den Bestandskunden wird das Geld aus der Tasche gezogen ohne dass es dafür eine echte Gegenleistung gibt. Über viele Jahre war ich ein Delphi-Enthusiast aber was Embarcadero veranstaltet, schreckt mich davor ab, irgendeinem meiner Kunden Delphi zu empfehlen. Mal ganz ehrlich: Selbst wenn die Professional-Version nur 200€ kosten würde, warum sollte ich Delphi XE8 gegenüber anderen IDEs vorziehen?

Zitat von Wosi:

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

Zitat von Wosi:

Castalia wirkt reingeklatscht. [..] Die "Extract-Method"-Funktion produziert weiterhin Müll. Was bringt mir eine Prozedur mit einem Var-Parameter?

Da muss ich leider zustimmen. Nachdem ich es mittlerweile ausprobiert habe, ist es qualitativ leider nicht besser als das integrierte Refactoring, im Gegenteil, es funktioniert sogar noch schlechter. Ich dachte vorher nicht, dass das möglich sei...
In einem Projekt mit nicht einmal 29.000 Zeilen...
"Castalia exceeded its allowed memory threshold for parse trees"
"No current file found. Prepare for an EIndexOutOfBounds error."
Und dann Schutzverletzung...

Aber schlimmer noch:
Im Gegensatz zum internen Refactoring wurde das Refactoring hier versucht trotzdem durchzuziehen. Teilweise werden Extraktionsmethoden erstellt, bei denen konstante Werte als var-Parameter weitergegeben werden, teilweise wird der extrahierte Code einfach ein paar Zeilen darüber in die gleiche Methode an zufälliger Stelle eingefügt (z.B. nach dem Semikolon einer SQL-Anweisung innerhalb eines Strings!!) und die Parameter blieben leer, ...

Beim "Surround with..." wird Code erzeugt, bei dem die Einrückung nicht stimmt, manchmal lässt sich die Aktion auch nicht per Strg + Z rückgängig machen, teilweise wird ein end zu wenig eingefügt, ...

Beim Methode umbenennen:
"No current file found. Prepare for an EIndexOutOfBounds error."
Schutzverletzung...

Ich dachte dann das läge eventuell am Projekt, aber das gleiche passiert bei zwei anderen ähnlich großen Projekten auch. Sorry, aber ich habe immer wieder Positives zu Castalia gehört. Das kann ich leider absolut nicht nachvollziehen, ich bin nur froh, dass wir dafür vor der Integration in Delphi kein Geld ausgegeben haben.

Man nehme ein Manifest, dass die Delphi-Version angibt (dann fliegen bei neuen Versionen automatisch die nicht gepflegten Komponenten in der Auswahl raus), dann einen Download-Counter und auch gerne noch ein Sterne-System. Und fertig ist ein System, dass sich selbst halbwegs aktuell hält, einen Indikator für Qualität hat und trotzdem mit Fremdpackages bestückt werden kann.

Bei PHP gibt es nur noch Composer / Packagist. Wenn was nicht auf der Plattform vorhanden ist, wird es schlicht nicht mehr verwendet. Da kann eine neue Bibliothek noch so gut sein. Im Frontend-Bereich läuft alles über Bower. Bei Node ist npm ein absolutes Muss.

Zitat von mquadrat:

[...] Bei PHP gibt es nur noch Composer / Packagist. Wenn was nicht auf der Plattform vorhanden ist, wird es schlicht nicht mehr verwendet. Da kann eine neue Bibliothek noch so gut sein. Im Frontend-Bereich läuft alles über Bower. Bei Node ist npm ein absolutes Muss.

Zitat von jaenicke:

Zitat von Wosi:

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.

Zitat von Stevie:

Zitat von Wosi:

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.

Praktisch wäre es ja, wenn man mehrere Quellen verwenden könnte,

Für Firmen wäre es bestimmt interessant, wenn sie so unter ihren Entwicklern die hauseigenen Komponenten ebenso verteilen könnten,
bzw. man selber so sein eigenes Zeugs zwischen den eigenen Rechnern/Schlepptops/usw..