Quo vadis Embarcadero?

[jaenicke]

Zitat:

Zitat von Phoenix (Beitrag 1248701)

Ernsthaft: Bei fast jeder anderen Firma gibts Bugfixes auch noch lange nachdem die Nachfolgeversion herauskam. Es sind Fehlerbehebungen, die sollte man nicht kaufen müssen.

Hätte, wäre, sollte, das Leben ist kein Wunschkonzert. ;-)

Davon abgesehen ist es mir deutlich lieber, wenn die dem Anschein nach außen nach ohnehin schon nicht so pralle Manpower für eine kommende Version benutzt wird, als wenn da dann noch Aufwand für ältere Versionen abgezwackt wird. Das sollte man dabei auch nicht vergessen.

Zitat:

Zitat von Phoenix (Beitrag 1248701)

Und als FireDac noch Anydac war, war es im Vergleich gesehen deutlichst günstiger als heute (Professional + AnyDac vs. Enterprise inkl. FireDac).

Da für uns ohnehin nur die Enterprise in Frage kommt (DataSnap, ...), stellt sich dieser Vergleich gar nicht. Im Gegenteil ist es für uns günstiger als vorher.

Zitat:

Zitat von mquadrat (Beitrag 1248710)

Nicht out-of-the-box

Mein Problem bei der Nutzung von Open Source und auch generell 3rd Party Projekten ist der Support für neue Delphiversionen. Eine komplette Integration ist da auch keine Lösung. Aber interessant wäre eine Zusammenarbeit in der Form, dass Embarcadero Projekte aufnimmt, die in Übereinkunft mit den Maintainern ggf. von Embarcadero zwischenzeitlich aktualisiert werden für neue Delphiversionen, wenn das in der Community gerade niemand tun kann (oder auch jemand als Maintainer zumindest vorübergehend einspringt, wenn die bisherigen aussteigen).

Das hätte mehrere Vorteile:

• Die Projekte laufen normal weiter solange alles glatt geht
• Nutzer haben eine höhere Sicherheit, dass sie bei neuen Delphiversionen diese Projekte zeitnah nutzen können
• Wenn Bugs oder Änderungen in einer neuen Delphiversion zu Problemen in den Projekten führen, könnte das frühzeitig erkannt werden, wenn auf diese Projekte ein Auge geworfen wird

[mquadrat]

Zitat:

Zitat von jaenicke (Beitrag 1248711)

Mein Problem bei der Nutzung von Open Source und auch generell 3rd Party Projekten ist der Support für neue Delphiversionen. Eine komplette Integration ist da auch keine Lösung. Aber interessant wäre eine Zusammenarbeit in der Form, dass Embarcadero Projekte aufnimmt, die in Übereinkunft mit den Maintainern ggf. von Embarcadero zwischenzeitlich aktualisiert werden für neue Delphiversionen, wenn das in der Community gerade niemand tun kann (oder auch jemand als Maintainer zumindest vorübergehend einspringt, wenn die bisherigen aussteigen).

Emba sollte einfach einige der Developer als aktive Mitglieder in den OS-Projekten platzieren. Wäre glaube ich die sinnvollere Variante.

Das Problem mit den Versionen wird man nie wegkriegen. Allerdings wäre es schick, wenn es einen Online-Service gäbe, der sich die Sourcen z.B. aus GIT holt und dann automatisiert die Packages für die verschiedenen Delphi-Versionen erstellt. Dann noch ein Repository dazu, die Behandlung von Abhängigkeiten und fertig wäre die Infrastruktur für das schnelle finden und verwenden von Komponenten.

[hanspeter]

Zitat:

Zitat von Stevie (Beitrag 1248708)

Zitat:

Zitat von mquadrat (Beitrag 1248704)

Dazu könnte man aktiver Spring4D / D# unterstützen.

Ich wäre schon zufrieden, wenn sie einige längst überfällige Language Features einbauen würden und sich der "Generics blähen die Binary auf" Problematik annehmen würden (

Kann man die Generics irgendwie abschalten?
Ich habe ein Programm von D7 auf XE2 angepasst. Das enthält keinerlei Generics oder RTTI.
Programmgröße unter D7 17 Mbyte und der gleiche Quellcode mit XE2 übersetzt 64 Mbyte.
Ansonsten hatten wir schon mal die Umstellung von VCL auf FMkey überlegt, sehen darin aber kaum einen Nutzen.

[Stevie]

Zitat:

Zitat von mquadrat (Beitrag 1248710)

Ihr geht ja zum Teil wirklich tief in die Innereien, insofern würde eine engere Zusammenarbeit ja unter Umständen auch der Gesamtsprache helfen.

Es besteht schon seit einiger Zeit ein Dialog zwischen Marco und uns - aber sowas passiert leider nicht von jetzt auf gleich :)

Zitat:

Zitat von hanspeter (Beitrag 1248713)

Kann man die Generics irgendwie abschalten?
Ich habe ein Programm von D7 auf XE2 angepasst. Das enthält keinerlei Generics oder RTTI.
Programmgröße unter D7 17 Mbyte und der gleiche Quellcode mit XE2 übersetzt 64 Mbyte.
Ansonsten hatten wir schon mal die Umstellung von VCL auf FMkey überlegt, sehen darin aber kaum einen Nutzen.

Nein, kann man nicht. XE2 ist sofern ich mich erinnere, noch nichtmal so schlimm, da dort die RTL und VCL noch nicht so exzessiv von Generics Gebrauch machen, das wurde erst mit XE3 oder XE4 eingeführt. Wenn man nach Möglichkeiten googelt, um die Binarygröße zu reduzieren, findet man genug Anleitungen - deshalb sehe ich hier davon ab, das nochmals aufzulisten. Fakt ist aber, mit jeder Version wirds größer. Schau trotzdem mal nach, dass in den Projektoptionen nicht noch Debug Infos oder so drin stehen, der Zuwachs von 17 auf 64 MB scheint mir etwas extrem.

[Codehunter]

Ich denke, bestimmte Sprach-Features wie in diesem Fall Generics bringen naturgemäß einen gewissen Overhead mit sich. Dass die Binaries dann größer werden versteht sich irgendwie von selbst. Mir kommt zwar ein Zuwachs von 17 auf 64 MB aber auch zu viel vor (denke mal da sind Debug-Infos mit drin).

Ich frage mich, was wohl Oliver (Assarbad) zu den heutigen RTLs sagen würde. Ob er dann noch so ein Projekt wie NonVCL starten würde? Was treibt er eigentlich heute? Schon ewig nix mehr von ihm gehört.

Jedenfalls dämmert mir angesichts der Problematik auch so langsam, warum Software-Updates im Allgemeinen seit Jahren immer größer werden. Manches Sicherheitsupdate für z.B. den IE10 ist ja teilweise größer als im Jahr 2000 das ganze Betriebssystem. Nur mal so als Beispiel...

[Der schöne Günther]

Was glaube ich eher die (ernstzunehmende) Motivation ist wenn man hinter der Binary-Größe her ist ist die Tatsache, sich mit nicht-nativen Anwendungen auf Plattformen wie Android oder iOS messen zu wollen- Da ist eine Taschenlampen-App ein paar KB groß während man mit Delphi+Firemonkey sicher schon 10 MB für den zwingenden Splashscreen braucht.

Wenn die Systeme einem dann noch ein "Diese Anwendung können sie aufgrund der Größe erst herunterladen, wenn sich ein WLAN in Reichweite befindet" aufbrummen macht es einem das sicher nicht einfacher.

Trotzdem finde ich auch die konsequente Ausrichtung, mit vielen verschiedenen Compiler-Backends fahren zu wollen, richtig.

[Buddelfish]

Zitat:

Zitat von jaenicke (Beitrag 1248711)

Zitat:

Zitat von Phoenix (Beitrag 1248701)

Ernsthaft: Bei fast jeder anderen Firma gibts Bugfixes auch noch lange nachdem die Nachfolgeversion herauskam. Es sind Fehlerbehebungen, die sollte man nicht kaufen müssen.

Hätte, wäre, sollte, das Leben ist kein Wunschkonzert. ;-)

Einfach ein Entwicklungssystem nehmen, bei der das Leben dem Wunschkonzert entspricht. Das Leben ist dann doch ein Wunschkonzert. Aber wenn man numal auf seine Renault R4/Trabbi-Gurke pocht, weil man ja noch Ersatzteile im Keller hat, dann... ja dann hinkt man eben immer hinterher.

Zitat:

Mein Problem bei der Nutzung von Open Source und auch generell 3rd Party Projekten ist der Support für neue Delphiversionen.

Open Source: ACK, 3rd-Party: Einfach die Richtigen* kaufen. Mit Quelltext. Und wenige. Also genau die, die man benötigt und nicht jeden Schnickschnack.

[BUG]

Zitat:

Zitat von Codehunter (Beitrag 1248744)

Was treibt er eigentlich heute? Schon ewig nix mehr von ihm gehört.

Ab und zu gibt es einen neuen Betrag aus seinem Blog. Afaik ist er in der Anti-Malware-Branche.

[Christian Seehase]

Zitat:

Zitat von Phoenix (Beitrag 1248701)

Zitat:

Zitat von jaenicke (Beitrag 1248695)

Reichen ja, aber schon wegen den Bugfixes möchte ich nicht mit älteren Versionen arbeiten. Von FireDAC (das wir nun in allen neuen Projekten einsetzen) und ähnlichen Neuerungen ganz zu schweigen.

Ernsthaft: Bei fast jeder anderen Firma gibts Bugfixes auch noch lange nachdem die Nachfolgeversion herauskam. Es sind Fehlerbehebungen, die sollte man nicht kaufen müssen.

Zumal ja wohl auch Software der Gewährleistung unterliegt...

[michaelthuma]

Jeder wie er will. Lass dich von English nicht abhalten. Es wird auch keiner hergehen in Oxygene anfangen Winforms Applikationen exklusiv zu basteln.

XE3 naja, da sitzt mit dem Hals in der Gülle. Das war nicht zwingend die glorreichste Release. XE4 und XE5 sind schon wesentlich besser. XE3 ist kein Maß. Es geht jetzt einiges mehr wieder. Ich hatte einfach alle Code Insight Feature abgedreht. Teils kann man die in XE5 wieder in Betrieb nehmen. Ist jetzt noch kein Lob im großen Stil.

Zitat:

Zitat von stahli (Beitrag 1248599)

Wenn ich mehr Zeit und bessere Englischkenntnisse hätte wäre ich auch schon zu Oxygene (oder anderer Alternative) gewechselt.
Ich werde noch eine Weile bei XE3 bleiben ... und dann mal sehen.

Neukauf bei Emba nur noch, wenn sich bei denen grundlegend alles ändert (Qualität, Support, Preisgestaltung). :-(