Quo vadis Embarcadero?

[mquadrat]

Dann hänge ich mich mal mit rein.

Die IDE
Die IDE ist für mich in den aktuellen Versionen durchaus gelungen. Wobei ich jetzt mal davon ausgehe, dass manche der Bugs, die mich in unserer XE2 manchmal zur Verzweiflung bringen (Absturz mit internem Fehler) in der XE5 gelöst sind.

Die Frameworks
Mit Firemonkey werde ich nicht so recht warm, aktuell bleiben wir bei VCL. Die "Alles ist ein DataSet/Source" Mentalität liegt mir nicht, da gehen wir eigene Wege. Ich würde mir wünschen, dass es mehr Framework-Unterstützung seitens Emba geben würde. Also z.B. ein Package für Authentifizierung etc. etc. Dazu könnte man aktiver Spring4D / D# unterstützen.

Die Compiler
Da wir Mobile wohl eher nicht mit Emba-Produkten machen werden, bleiben mir die Windows-Compiler und die funktionieren.

Die Dokumentation und Hilfe
Soo schlecht ist die Doku nun auch nicht. Ich finde es eher schade, dass das EDN so schleifen gelassen wird. Da wäre ja viel mehr Luft, als "Ich zeige euch jetzt wie man eine leere Anwendung für iOS schreibt".

Die Geschäftspolitik
Kurze Release-Zyklen sind inzwischen Industriestandard. Damit hat man immer ein Problem mit den Major-Versionen. Die gibt es bei den kurzen Zyklen ja eigentlich nicht mehr, aber man braucht sie um das Geschäftsmodell aufrecht zu erhalten. Ein Major pro Jahr passt. Für Firmen, die mit Delphi ihr Geld verdienen ist der Preis auch in Ordnung. Das hin und her bei Mobile war natürlich suboptimal.

Die Community
Hindernis für die Community ist sicher auch das Package-Management und die Herkunft aus der Closed-Source-Ecke. Wir denken aktuell darüber nach Teile unsers Application-Frameworks als Open-Source zu veröffentlichen, würden aber natürlich immer nur die Delphi-Version unterstützen, die wir nutzen. Das Anspruchsdenken der Community dürfte aber wohl eher sein stets verwendbare Releases für alle Versionen zu haben. Dazu sind die Abhängigkeiten ein Problem. Es wäre super, wenn es etwas wie NuGet / Composer geben würde.

Die Preise
Wie schon geschrieben sind die Preise für mich kein Problem. Auch nicht für die Community. Schauen wir uns doch mal an wie OpenSource-Projekte/Komponenten aufgestellt sind. Alles was sich länger am Markt hält hat große Supporter. HHVM kommt von Facebook, Bootstrap von Twitter, Angular.JS von Google, Firefox von der Foundation. Projekte sind inzwischen so komplex, dass gute OS-Komponenten eigentlich nicht mehr von Privatpersonen als Hobby entwickelt werden können und werden.


Delphi ist für Desktop-Windows immer noch erste Wahl. Und wenn mit dem nächsten Update die Grenze von Modern-UI und Desktop weiter verwischt wird, dann kann man sich auch mit Metropolis blicken lassen ohne ausgelacht zu werden. Der X-Plattform-Ansatz ist in der Strategie richtig, der Markt mit der größten Bewegung ist Mobile also ist auch das richtig gewählt. Einzig der Coolness-Faktor scheint Emba so komplett zu fehlen und das macht es schwierig bei den Mobile-Entwicklern zu punkten. Reine Windows-Entwicklung mit Fat-Clients ist einfach kein Zukunftskonzept mehr.

[Stevie]

Zitat von mquadrat:

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 (denn im Mobile Bereich spielt die Größe sehr wohl eine Rolle!). Davon abgesehen bin ich eher zurückhaltend, was die Integration von Open Source Projekten in das Produkt out-of-the-box angeht, falls du darauf angespielt hast. Aber insgesamt könnte die Zusammenarbeit mit der Community noch ein bisschen verbessert werden, wenn es nicht gerade um werbewirksame Auftritte geht.

[mquadrat]

Nicht out-of-the-box, aber man könnte im EDN die Sachen ja mal prominent featuren. Ihr geht ja zum Teil wirklich tief in die Innereien, insofern würde eine engere Zusammenarbeit ja unter Umständen auch der Gesamtsprache helfen.

[hanspeter]

Zitat von Stevie:

Zitat von mquadrat:

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 von mquadrat:

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 von hanspeter:

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.

[BUG]

Zitat von Codehunter:

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.

[Stevie]

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

Nö, nur wenn sie eben so implementiert sind, wie in Delphi, als Templates. Dann wird für jede TList<T> eine Kopie gemacht und T entsprechend ersetzt, durch string, Integer, TFoo, TBar, was auch immer. Dumm nur, dass zumindest für alle möglichen Klassen der interne Code für diese Klasse identisch ist. Ob ich nun eine TFoo oder eine TBar Instanz hinzufüge, der ausgeführte Code ist immer der gleiche. Solang also nichts mit T direkt gemacht wird (z.B. T.Create oder TypeInfo(T) etc) könnte der Linker den Code zusammenführen, so dass nicht für TList<TFoo> und TList<TBar> der identische Code zweimal in der Binary steht (siehe für mehr Infos dazu diesen Blog Artikel).

Das wurde auch schon experimentell mal von Commmunity Membern gemacht, was doch einiges an Ersparnis in einer Anwendung brachte.

[cookie22]

Zitat von mquadrat:

Die Geschäftspolitik
Kurze Release-Zyklen sind inzwischen Industriestandard. Damit hat man immer ein Problem mit den Major-Versionen. Die gibt es bei den kurzen Zyklen ja eigentlich nicht mehr, aber man braucht sie um das Geschäftsmodell aufrecht zu erhalten. Ein Major pro Jahr passt. Für Firmen, die mit Delphi ihr Geld verdienen ist der Preis auch in Ordnung. Das hin und her bei Mobile war natürlich suboptimal.

Wo hast du das denn her? Du Vergleichst hier Äpfel mit Birnen. Delphi ist eine Entwicklungsumgebung und kein Browser. Den Standard stellt hier ja wohl M$ auf und guck dir mal deren Zyklen an. Bei Apple ist es egal, weil man dort nicht für die Tools zahlen muss. Leuten buggy Sortware zu verkaufen und für Bugfixes nochmal Geld zu verlangen ist schlichtweg eine Frechheit.

Zitat von mquadrat:

Die Preise
Wie schon geschrieben sind die Preise für mich kein Problem. Auch nicht für die Community. Schauen wir uns doch mal an wie OpenSource-Projekte/Komponenten aufgestellt sind. Alles was sich länger am Markt hält hat große Supporter. HHVM kommt von Facebook, Bootstrap von Twitter, Angular.JS von Google, Firefox von der Foundation. Projekte sind inzwischen so komplex, dass gute OS-Komponenten eigentlich nicht mehr von Privatpersonen als Hobby entwickelt werden können und werden.

Die Preise sind kein Problem für die Community? Arbeitest du für Emba? Welche Community überhaupt? Die paar Leute die hier noch aktiv sind? Delphi hatte mal eine riesen Community, die nun langsam aber sicher stribt, weil die Leute immer älter werden und Emba der Nachwuchs komplett ignoriert. Geh mal in eine beliebige Uni und frag dort nach Delphi. Als Antwort wirst du Dinger zu hören bekommen, wie: "Damit hab ich mal was in der Schule gemacht. Gibts das überhaupt noch?"

Zitat von mquadrat:

Delphi ist für Desktop-Windows immer noch erste Wahl. Und wenn mit dem nächsten Update die Grenze von Modern-UI und Desktop weiter verwischt wird, dann kann man sich auch mit Metropolis blicken lassen ohne ausgelacht zu werden. Der X-Plattform-Ansatz ist in der Strategie richtig, der Markt mit der größten Bewegung ist Mobile also ist auch das richtig gewählt. Einzig der Coolness-Faktor scheint Emba so komplett zu fehlen und das macht es schwierig bei den Mobile-Entwicklern zu punkten. Reine Windows-Entwicklung mit Fat-Clients ist einfach kein Zukunftskonzept mehr.

Es gibt wohl kaum noch etwas, dass mit C# nicht genauso schnell oder sogar schneller ginge als mit Delphi.

Es ist wohl mehr die Lieblosigkeit mit der FMX umgesetzt wurde, als dort irgendwo der Coolness-Faktor fehlt. Warum sollte man viel Geld für ein schlecht umgesetztes System zahlen und sich herum ärgern, wenn man kostelos nativ entwickeln kann.