Befindet sich Delphi noch auf der Höhe der Zeit?

[Sherlock]

So lange hier keiner Turingmaschinen programmieren muss, geht es allen richtig gut.

Sherlock

[Phoenix]

Es geht doch dabei eigentlich gar nicht um die Sprache an sich.

Object Pascal ist recht cool, und wenn man sich anschaut was man mit ein wenig mehr Gehirnschmalz im Sprachdesign hinbekommt (siehe das, was RemObjects mit Oxygene gemacht hat), dann ist auch Object Pascal noch auf der Höhe der Zeit.

Das, was wirklich nicht mehr auf der Höhe der Zeit ist, ist doch das ganze Drumherum.

Die IDE schleppt seit Jahren Bugs mit sich rum, um wenn man sich anguckt was zum Beispiel nur im Bereich Debugging heute eben z.B. mit Visual Studio oder anderen Plattformen möglich ist, dann sieht man wie groß die Kluft in der Tat ist.

z.B. Remote Debugging: Ich brauche z.B. keinen Agent auf einem Produktivsystem sondern dort nur die entsprechenden Rechte und kann mich mit meiner IDE jederzeit an einen bockingen Live-Prozess attachen und muss nicht mehr umständlich versuchen, irgendwelche Probleme lokal zu reproduzieren.

Oder Intellitrace: historisches Debuggen durch die Aufzeichnungen eines kompletten Prozesses - jederzeit schauen, was zu einem beliebigen Zeitpunkt in der Vergangenheit auf dem Stack lag, egal in welchem Thread, und im Zweifel kann ich den Wert von damals auch jetzt noch ändern und lokal einen neuen Prozess ab genau dieser Stelle vond amals weiterlaufen lassen und gucken was passiert. (Okay, zugegeben: dieses Feature spart nicht nur wahnsinnig Aufwand, es ist auch leider wahnsinnig teuer).

Aber es hört ja nicht bei der IDE auf.

Wenn ich mir anschaue, was man bei Delphi alles noch immer aufwändig selber machen muss, ist das doch ein riesiger Produktivitätskiller.

Auf nahezu jeder anderen Entwicklungsplattform (JavaScript, Java, .NET, Ruby, PHP, Python, Objective-C, Swift, sogar C und C++) gibt es zu nahezu jedem vorstellbarem Thema unzählige Open-Source Projekte, die man sich mit gängigen Paketmanagern (npm, Maven, NuGet, Bower, Packagist, Composer etc.) einfach herunterladen, installieren und nutzen kann. Ich schaue dort in das Unit-Test Projekt rein wie man eine bestimmte Komponente nutzt, und lege los.

Für Delphi gibt es noch ein paar wenige, hauptsächlich kommerzielle Komponentenanbieter, und - bitte korrigiert mich wenn ich da falsch liege - de fakto keine aktive Open-Source Community.

Wie viele OR-Mapper für unterschiedliche Anwendungszwecke gibt es? Wie viele JSON-Libraries? Wie viele Adapter zu anderen externen Systemen (z.B. Elasticsearch, Redis, ActiveMQ) etc. gibt es? Wenn überhaupt, dann maximal 2-4 Stück, alle sehr rudimentär, und meist nur für eine bestimmte Delphi-Version.

Die Zeit, in der Delphi mit der VCL Vorreiter war, ist nunmal leider vorbei. Jeder, der sich darauf einlassen will wird sehr bald feststellen, dass er nach einer nur sehr kurzen Lernphase und Umgewöhnungszeit mit so ziemlich jedem anderen Entwicklungs-Ökosystem da draussen mindestens genauso, wenn nicht sogar deutlich effizienter das gleiche Zeug bauen kann wie mit Delphi auch. Von den Preisen der Umgebungen mal abgesehen, weil die meisten da draussen eher kostenfrei sind als nicht.

[Lemmy]

@Sebastian: Danke für das Posting. Kannst Du ggf. Licht ins Dunkel bringen, weshalb Interfaces broken by Design sind? Gelesen habe ich nun oft davon - Gründe für die Aussage aber bisher keine...

[bernau]

Zitat von Phoenix:

Wie viele OR-Mapper für unterschiedliche Anwendungszwecke gibt es? Wie viele JSON-Libraries? Wie viele Adapter zu anderen externen Systemen (z.B. Elasticsearch, Redis, ActiveMQ) etc. gibt es? Wenn überhaupt, dann maximal 2-4 Stück, alle sehr rudimentär, und meist nur für eine bestimmte Delphi-Version.

Warum brauche ich 20 JSON-Libraries, wenn es eine gibt, die alles macht, was ich will. Manchmal ist die Masse auch behindernd. Sehe ich also nicht als Nachteil.

Zitat von Phoenix:

Die Zeit, in der Delphi mit der VCL Vorreiter war, ist nunmal leider vorbei. Jeder, der sich darauf einlassen will wird sehr bald feststellen, dass er nach einer nur sehr kurzen Lernphase und Umgewöhnungszeit mit so ziemlich jedem anderen Entwicklungs-Ökosystem da draussen mindestens genauso, wenn nicht sogar deutlich effizienter das gleiche Zeug bauen kann wie mit Delphi auch. Von den Preisen der Umgebungen mal abgesehen, weil die meisten da draussen eher kostenfrei sind als nicht.

Es mag sein, daß man sich schnell auf andere Plattformen umgewöhnen kann. Wenn man aber ein gewachsenes Projekt hat, welches 20 Jahre auf dem Buckel hat, dann überlegt man schon, ob man alles portieren soll. Ich für mich kann mit den Defiziten leben. Und wenn ich sehe, wie sich Delphi grade entwickelt, habe ich da echt keine Bedenken.

Auch wenn andere Produkte Preiswerter sind, sage ich mir, daß ich mit diesem Werkzeug verdiene. Dann darf das auch etwas kosten. Im Vergleich zu anderen Sparten haben wir ein recht günstiges Werkzeug. Einzig eine Schülerversion würde ich mir kostenlos wünschen. Der Nachwuchs fehlt, weil die Jugend erst mal ein kostenloses Produkt testet und dann dort hängen bleibt. Ich bin zu TurboPascal gekommen, weil es ein preiswerter Einstieg in die Programmierung war.

[mkinzler]

Ein großes Problem an der Entwicklung ist der faktor Zeit (feste Termine für Veröffentlichung). Neue Features können so nicht richtig fertiggestellt werden sondern es wird (very) quick and dirty Features nur oberflächlich angflanscht. Das hat sicherlich auch mit der immer noch nicht einheitlich vorhandenen Complier Struktur (Front-/Backend) zu tun. So lange es den alten "Flickwerk" Complier noch gib, können notwendige Änderungen im Kern nicht erfolgen. Features die an diesem nicht möglich sind, werden auch in den neueren Compliern kaum gemacht werden, da dieser ja immer noch der wichtigste ist ( Win32/OSX32).

[BUG]

Zitat von Lemmy:

Kannst Du ggf. Licht ins Dunkel bringen, weshalb Interfaces broken by Design sind?

Afaik bezieht sich das darauf, das Interfaces in Delphi quasi COM-Interfaces sind.
Quasi wird ein Model benutzt, was dafür nicht unbedingt für die allgemeine Interfaces gedacht war, sondern zur Sprach- und/oder Prozessübergreifenden Kommunikation. Damit bekommt man mit Interfaces quasi immer gleich Referenzzählung und GUIDs.

[Phoenix]

Zitat von bernau:

Wenn man aber ein gewachsenes Projekt hat, welches 20 Jahre auf dem Buckel hat, dann überlegt man schon, ob man alles portieren soll.

Sollte man vermutlich eher nicht

Eine gewachsene komplette Anwendung umzutopfen macht keinen Sinn. Und in den Bereichen, in denen technologisch nicht so hyperviel Innovation gefordert wird braucht man auch nicht zwangsläufig so viel Innovation in den Tools.

Mir geht es primär darum, das man als Entwickler auch öfter mal den Blick über den Tellerrand wagen sollte:
Warum ein neues kleines Tool denn nicht mal mit Ruby oder Python basteln? Warum nicht mal Node und JavaScript anschmeissen um einen kleinen Daten-Importer zu bauen?
Das "Das hat man hier noch nie gemacht" oder "damit kennt sich keiner aus" sind alles Argumente die einen eher kurz als Mittelfristig Betriebsblind machen.

Wenn wir uns z.B. mal UWP anschauen, Web-Frontends für Anwendungen, Mobile devices, Applikationen für den Massenmarkt, skalierbare, verteilte Anwendungen, da macht auf einmal schon ein kleiner Vorsprung bei modernem Tooling einen riesen Unterschied in der Produktivität. Warum also nicht mal sowas ausprobieren?

[BUG]

Zitat von Phoenix:

Warum nicht mal Node und JavaScript anschmeissen um einen kleinen Daten-Importer zu bauen?

Obwohl die node.js-Explosion da vermutlich aus der anderen Richtung kommt: Frontend-Webentwickler wollen alles mit JavaScript machen ... und es gibt Unmengen an Frontend-Webentwickler

Mein Lieblingsanwendungsfall für node.js sind immer noch adhoc-Web-APIs; für allgemeine Tools finde ich Python angenehmer.

[bra]

Ich habe beruflich mit Delphi zu tun (D2007-XE8) und die größte Schwäche ist m.E. die IDE. Unkomfortable, verbuggt und langsam. Ich ärgere mich jeden Tag zig-mal, weil irgendwas mal wieder nicht funktioniert, das Ding wegen zu wenig Speicher ins Nirvana fliegt oder sie einfach nur rumzickt.
Mit RAD hat das leider oft nichts zu tun. Sowas wie Error Insight muss man z.B. generell abschalten, weil alle paar Minuten einfach mal der halbe Quelltext als fehlerhaft unterstrichen wird aber fehlerfrei kompiliert.

Davon abgesehen ist das ständige Updaten alle halbe Jahr, damit man mit den mobilen Systemen überhaupt noch mithalten kann, ein wahrer Krampf. Wir brauchen jedesmal mehrere Tage, um das (bisher) einzige Projekt mit XE4+ überhaupt vernünftig auf der neuen Version zum Laufen zu bringen. Seien es fehlende Komponenten oder einfach neue/alte Bugs, die das ganze wieder teilweise um Wochen verzögern, es kostet jedesmal unnötige Zeit und Nerven.

[Mavarik]

Zitat von bra:

Ich habe beruflich mit Delphi zu tun (D2007-XE8) und die größte Schwäche ist m.E. die IDE. Unkomfortable, verbuggt und langsam. Ich ärgere mich jeden Tag zig-mal, weil irgendwas mal wieder nicht funktioniert, das Ding wegen zu wenig Speicher ins Nirvana fliegt oder sie einfach nur rumzickt.

Tja zum Glück gibt es ja wieder ein Update... Mit Delphi 10 hast Du die Speicherprobleme erstmal nicht mehr...
XE6,7,8 musste ich nach jedem Build für iOS oder Android neu starten... Mit D10 arbeite ich den ganzen Tag ohne einen Fehler!