Die Zukunft von Delphi - aber bitte optimistisch!

[BloodySmartie]

Hallo liebe Community!

Ich würde mich gern einmal von den ganzen Delphi-Endzeit-Diskussionen lösen und die Frage in den Raum stellen, in welchen Bereichen Ihr für die Delphi-IDE und -Sprache eine Zukunft seht.

- In welchen Projekten wird Delphi an Bedeutung gewinnen / verlieren?
- Welche Sprachkonstrukte werden künftig in Delphi zu finden sein? Oder welche wünscht Ihr euch?
- In welchen Bereichen werden andere Sprachen/IDEs Delphi den Rang ablaufen und wo wird es vielleicht umgedreht sein?


Ich fange mal an...

Unser Unternehmen beschäftigt sich vor allem mit der Entwicklung individueller Web- und Softwarelösungen. Nicht selten geht es da um Multi Tier Anwendungen und MashUps. Dabei gliedern sich unsere Systeme meist in drei oder vier Schichten:
- das Web-Frontend für Intra- / Internet in Flash oder als "normale" HTML-Seite
- die Business-Logik in PHP oder JSP mit Datenbank MySQL / Postgresql / Oracle
- ein Redaktionsmodul als Win-Software für den Kunden
- ein Administrationsmodul(quasi als Plugin) für uns selbst - ebenfalls als Windows Software

Delphi(vorzugsweise Win32) hat bei uns einen festen Stellenwert, vor allem natürlich in den beiden letztgenannten Bereichen der Windows Software. Allerdings auch im PHP-Umfeld. Und nein, wir nutzen bisher Delphi for PHP nicht. Dafür setzen wir auf RemObjects, um über PHP-XMLRPC verbindungen Delphi Servern herzustellen und so flexibel und schnell komplexe, mehrschichtige Systeme zu implementieren.

Wir schätzen an Delphi das Komponentenkonzept als eine konsequente und sehr schnell einzusetzende Lösung für die Wiederverwendung von Sourcecode. Das gestaltet unseren Entwicklungsprozess schnell und dadurch wirtschaftlich. Unsere eigenen Komponenten werden gut gepflegt und wir haben bisher den Eindruck, dass sich die Community auch wunderbar um die meisten Open Source Komponenten kümmert.

C++ verwenden wir immer dann, wenn es um sehr systemnahe Anwendungen oder hohe Ausführungsgeschwindigkeiten gehen soll. Beides ist bei uns nicht all zu oft der Fall. Meist wird dann ein solches Modul wiederum vom zuständigen C-Hacker zur Einbindung in eine Delphi-Host-Anwendung vorbereitet.

Kurzfristig wünschen wir uns eine Delphi-IDE, die weniger zickt und in der durch winzige Bugfixes mancher Handgriff gespart wird - vielleicht auch ein Highlighting für begin/end - Blöcke wie bei Klammern. Mittel- und Langfristig wäre es toll, weiterhin Win32-Compiler nutzen zu können, statt auf .NET aufbauen zu müssen. Der Grund dafür liegt schlicht in der Abwärtskompatibilität unserer Anwendungen, sowie darin, dass die meisten VCL-Komponenten, die wir geschrieben haben und nutzen, nicht im .NET-Umfeld verwendbar sind. Außerdem wären Templates außerhalb von .NET toll...

Jetzt Ihr! :coder:

[Der.Kaktus]

Zitat:

Zitat von BloodySmartie

..C++ verwenden wir immer dann, wenn es um sehr systemnahe Anwendungen oder hohe Ausführungsgeschwindigkeiten gehen soll...

Also ich habe bisher fuer keine systemnahen Anwendungen extra C(++) gebraucht. Selbst die Ausfuehrungsgeschwindigkeiten sind in der heutigen Zeit kaum noch zu merken. Ein Unterschied ist nur zu merken,meine Meinung, wenn man direkt in Assembler schreibt.
Zur Zukunft von Delphi kann ich nichts sagen, da ja nun auch Borland Codegear verkauft hat und ich nicht deren Strategien kenne.

[Codewalker]

Ich kann mich vielen Deiner Punkte innerlich anschließen. Ich denke, dass Delphi in Zukunft bei so manchen neuen Projekten gegenüber .NET, Java und Konsorten zurückstecken muss, weil der Glaube an das Potenzial dieser Sprache fehlt. Andere Sprachen können mit werbewirksamen Neuerungen punkten und liefern damit viele Argumente für eine Diskussion.

Bei Delphi fehlen meiner Meinung nach diese bahnbrechenden Neuerungen. Borland/Inprise/CodeGear hat hier seit etlichen Versionen stark nachgelassen. Nicht, dass es keine Neuerungen geben würde (ECO, IntraWeb, uvm.), aber sie werden nicht so stark beworben. Java und .NET sind da viel mehr im Vordergrund. Hinzu kommt, dass Borland die Entwicklung scheinbar hat schleifen lassen und Win32 - die Stärke von Delphi - zugunsten von .NET zurückstecken musste. So kann Delphi immernoch kein Unicode und immer noch kein 64Bit - was ein großer Nachteil bei Zukunftsperspektiven neuer Projekte sein kann. Delphi fehlt ein "Knaller" - etwas dass Delphi wieder bekannter macht und etwas liefert, dass alle irgendwie haben wollen und es ohne Delphi nicht gibt.

Ich persönlich mag Pascal als Sprache - die Syntax ist lesefreundlicher als so mancher C++ - Code. Von daher bin ich Delphi immer treu geblieben. Außerdem ist das Prototyping super einfach: Nirgendwo kann man so schnell eine optisch ansprechende Oberfläche erstellen und nach belieben ohne zuviel Aufwand umbauen. Aber Pascal ist auch in die Jahre gekommen und neue Sprachkonstrukte fehlen oder kamen erst sehr spät: Templates, Generics, Operator-Überladung...... alles, was in anderen Sprachen z.T. selbstverständlich ist.

Der große Pluspunkt für Delphi ist die Community. Alleine in diesem Forum treiben sich Einsteiger rum, denen gerne und vernünftig geholfen wird, als auch Profis, die über systemnahe Programmierung, DLL-Injections, etc. auf hohem Niveau diskutieren. Die JCL/JVCL ist einzigartig und - für mich persönlich - unverzichtbar. Andorra2D beispielsweise gibt (lange Zeit nach DelphiX) die Möglichkeit, Spiele in Delphi zu entwickeln und dabei vorhandene Hardware auszunutzen - und das dank FreePascal sogar platformübergreifend. All das sind für mich Argumente, damit ich Delphi treu bleibe. (Wobei ich Kylix SEHR vermisse - es wäre ein mehr als gutes Argument gewesen).

Bleibt zu hoffen, dass es beim neuen Inhaber von Delphi besser wird - ansonsten hängt alles an der Community. Aber das schaffen wir ja schon recht gut ;-)

Grüße

Thomas

[BloodySmartie]

@Der.Kaktus:

Ich kann mich Dir da durchaus anschließen. Für so gut wie alle Aufgaben ist Delphi auch in der Geschwindigkeit einfach gut gewappnet. Allerdings fahren wir intern kleine Tests um zu prüfen. ob wir mit C++ noch was rausholen können. Gerade bei reinen Rechenaufgaben ohne Datenbank oder irgendwelchem anderen Quark ist C++ bisher im Schnitt bis zu 20% schneller gewesen-was aber auch stark von der Aufgabe abhing. Zumeist waren Delphi und C++ gleichauf.

@CodeWalker:
Zumindest 64-Bit und Unicode stehen ja schon in der Roadmap*hüpf*

[Codewalker]

Zitat:

Zitat von BloodySmartie

Zumindest 64-Bit und Unicode stehen ja schon in der Roadmap*hüpf*

Tja, nur kann man mit einer Roadmap keinen Chef bei neuen Projekten überzeugen :|
Ich hoffe einfach, dass es möglichst bald Platz in meinem Regal findet :mrgreen:

[Lemmy1]

Also mal meine zwei €-Cents:

Ich denke, es gibt einige Entwicklungen, die Delphi einfach machen muss. Das ist aber mehr Pflicht als Kür. Dazu gehören:

• Unicode (kommt 2008)
• 64 Bit (kommt 2009)
• .Net 3.5
• Stabile IDE

Dadurch alleine macht man aber noch niemanden glücklich. Das kann man erst dadurch erreichen, wenn man mal wirklich etwas neues wagt. Ein paar Wünsche, die ich dabei hätten wären:

• Native Unterstützung von Linux (GTK und QT) sowie MacOS X
• Kostenlose Einsteigerversionen
• Vernünftige Preise, längere Release-Zyklen
• GC und vollständige RTTI in Native Code
• Eine IDE, die denselben Comfort wie ReSharper + Visual Studio bietet
• Sprachfeatures aus .Net und anderen Sprachen in Native Code (Generics, Boxing, Anonymous Delegegates, Linq, Closures und und und)
• Aufräumen der Delphi Language

Mit dem Letzten Punkt meine ich, dass es einfach viele Dinge in der Sprache gibt, die einem zusammengehackt vorkommen. Zum Beispiel wäre das der globale Scope von Enum-Members (daher haben die alle so hässliche Präfixe wie alClient statt TAlign.Client).
Was ich auch schon immer seltsam fand war, dass man Klassen im Implementation Teil nicht als private Members einer Klasse im Interface-Teil verwenden kann. Und so weiter....es gibt da zig Beispiele.

Mein Punkt ist...diese Dinge sind alle lösbar. Wenn CodeGear den Wunsch hat, wieder ganz nach vorne zu kommen dann wird das ein weiter Weg aber der ist gehbar. Wichtig wäre aber vor allem erstmal, die Pflicht abzuarbeiten und uns dann ab 2009 mit der Kür zu überraschen. Und das gute ist: Die Roadmap lässt GENAU das erahnen.

[mkinzler]

Zitat:

@CodeWalker:
Zumindest 64-Bit und Unicode stehen ja schon in der Roadmap*hüpf*

Mir wäre lieber das in Release Notes zu Lesen :zwinker:

Zitat:

* Native Unterstützung von Linux (GTK und QT) sowie MacOS X

FULL ACK; Vielleicht auch Wx

Zitat:

* Vernünftige Preise,

Wenn die Qualität stimmt

Zitat:

längere Release-Zyklen

Wenn di Konkurrenz diese gleichzeitig verkürszt? Besser wäre mehr Manpower in die Weiterentwicklung, denn in den letzten Jahren wurde ja mehr Augenmerk auf das Marketing gelegt. Vielleicht eine Trennung der Entwicklungszyklen der IDE von den der Compilern.

Zitat:

* Sprachfeatures aus .Net und anderen Sprachen in Native Code (Generics, Boxing, Anonymous Delegegates, Linq, Closures und und und)

Es wäre imho sinnvoll den Compiler von der Plattform zu trennen. Damit meine ich das es nicht einen Delphicompiler für Win32, einen für .Net, einen C++-Compiler für Win32 und einen für .Net sondern einen für Delphi und einen für C++. Im 2. Schritt würde dann der eigentliche Code für die Plattform (Win32, .Net, Mono, Linux, MacOS) erzeugt werden.

Zitat:

* Aufräumen der Delphi Language

Das würde zur mangelnden Rückwärtskompatibilität führen.

[Nuclear-Ping]

Wenn Delphi stur auf der Schiene bleibt, in der es jetzt (seit Jahren) fährt, wird es nicht mehr lange überleben. Vielleicht max. 5-10 Jahre? Je nachdem was für eine Kompatibilität zu künftigen Betriebssystemen geschaffen wird.

Aber das was ich bei Delphi bis heute schmerzlich vermisse ist:

- Plattformunabhängigkeit
- 64bit Compiler
- Erweiterte Sprachkomponenten

[Lemmy1]

Zitat:

Zitat von mkinzler

Es wäre imho sinnvoll den Compiler von der Plattform zu trennen. Damit meine ich das es nicht einen Delphicompiler für Win32, einen für .Net, einen C++-Compiler für Win32 und einen für .Net sondern einen für Delphi und einen für C++. Im 2. Schritt würde dann der eigentliche Code für die Plattform (Win32, .Net, Mono, Linux, MacOS) erzeugt werden.

Ja das wär schon was, aber in der Realität wahrscheinlich sehr komplex (bislang haben sie sich ja sogar gegen ein Two-Pass Compiler gesträubt, da will man ja sowas gar nicht erst ansprechen :-) Den Compiler zu opensourcen wär aber ein schöner Schachzug...

Zitat:

Zitat von mkinzler

Das würde zur mangelnden Rückwärtskompatibilität führen.

Nun ja. Schau doch mal unter .Net 2.0 den Namespace System.Collections an. Der ist bereits suboptimal, weil .Net 1.0/1.1 keine Generics kannten. D.h. bereits in Version 2 (!) fängt das Chaos an (sonst würde es keine ArrayList Klasse geben). Delphi ist nun das selbe, nur multipliziert mit 20 oder sowas, wenn man die Pascals für Dos mitzählt.
Aber es gibt doch Wege: Man führt eine neue Syntax ein und erlaubt dann beide Varianten, mit deprecated Warnings beim Compilieren der alten. Abwärtskompatibilität ist ja schön und gut, aber man muss doch auch mal bestimmte Dinge loslassen können.

Bei Delphi wird immer auf so uralt Versionen Rücksicht genommen. Das liegt doch aber nur daran, dass 1) neue Versionen zu verbuggt erscheinen oder 2) neue Versionen zu teuer sind. Und beidem kann man doch Herr werden. Wäre ein neues Delphi eine echte Alternative, so würden die Leute mitgenommen werden - man könnte die Sourcen schrittweise modernisieren und die Leute müssten keine 6 Versionen überspringen.

[Lemmy1]

Noch ein Nachtrag zur Abwärtskompatibilität: Was wäre den die Alternative zum Aufräumen? Immer mehr Chaos herrschen lassen bis es irgendwann daran erstickt und durch neue Sprachen ersetzt wird? Wäre doch schade...