Quo vadis Embarcadero?

[jaenicke]

Zitat von Medium:

Die IDE ist so weit okay, ErrorInsight kann aber geflissentlich ignoriert werden. (Es hilft meist nur dann, wenn man sich bei einer lokalen Variable verschreibt.)

Das hat sich seit Delphi 2007 deutlich geändert. Wo ich noch Probleme habe ist an Stellen wie dieser:
http://qc.embarcadero.com/wc/qcmain.aspx?d=121805
Aber das ist ja nicht der Regelfall.

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

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

[mquadrat]

Zitat von cookie22:

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.

Auch bei MS werden die Zyklen kürzer und kürzer. Jedes Jahr eine Major und die Minors kommen in immer kürzeren Zyklen.

Zitat:

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?"

Das an den Unis kein Delphi mehr genutzt wird, hat aber weniger mim Preis zu tun. Da wird auch kaum .NET verwendet, obwohl die Express nix kosten. Bei der JVM kannst du halt an allem rumdrehen.

[cookie22]

Zitat von mquadrat:

Auch bei MS werden die Zyklen kürzer und kürzer. Jedes Jahr eine Major und die Minors kommen in immer kürzeren Zyklen.

Nein, werden Sie nicht. 2013 war eine Ausnahme und hing eng mit Windows 8 Änderungen zusammen, die nächste Version ist VS 2015.

Ganz davon ab, zahlt man bei M$ nicht für Updates. Dazu kommt wie unsäglich die Updates bei Delphi ausgeliefert werden. Da muss man eventuell neu installieren damit alles wieder läuft. Bei anderen IDEs drück ich auf "Update Now" und das Ding wird in 5 Minuten gepatcht und alles läuft.

Zitat von mquadrat:

Das an den Unis kein Delphi mehr genutzt wird, hat aber weniger mim Preis zu tun. Da wird auch kaum .NET verwendet, obwohl die Express nix kosten. Bei der JVM kannst du halt an allem rumdrehen.

Ich habe nie behauptet, dass an den Unis .Net verwendet wird. Ich sagte:"Frag mal nach Delphi". Das kennt dort keine Sau mehr. Mit .Net haben aber 2/3 aller Studenten schon mal in ihrer Freizeit gearbeitet. Und warum? Weil M$ halt nicht auf den Nachwuchs kackt. Ich sag nur Dreamspark. Von sowas kann Emba nur träumen. Wenn der letzte Delphi-Opa gestorben ist, werden immer noch Kinder und Jugentliche .Net verwenden. Eben, weil es nichts kostet. Mittlerweile ist C# genauso produktiv wie Delphi, ja in einigen Bereichen entwicket man mit C# sogar viel schneller.

Schau dir doch nur mal die default FMX Skins an. Die Programme sehen unter Windows und MacOS X einfach nur gruselig aus. Emba hat es seit 5 Versionen nicht hingebracht, Skins anzubieten die annäherd nativ aussehen. So etwas will doch keiner freiwillig benutzen.

Nur mal so eine Frage am Rande. Gibt es eigentlich nur ein einziges wirklich erfolgreiches Programm, dass mit FMX entwickelt wurde?

Ich kann hier nur immer wieder meinen Respekt unseren beiden Stahlis aussprechen, die sich den Käse seit Jahren antun und immer noch nicht die Geduld verloren haben.