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:

Zitat von Phoenix (Beitrag 1318788)

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:

Zitat von Phoenix (Beitrag 1318788)

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:

Zitat von Lemmy (Beitrag 1318793)

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:

Zitat von bernau (Beitrag 1318797)

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:

Zitat von Phoenix (Beitrag 1318800)

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 :stupid:

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:

Zitat von bra (Beitrag 1318807)

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!

[Dejan Vu]

Zitat:

Zitat von Mavarik (Beitrag 1318821)

Mit D10 arbeite ich den ganzen Tag ohne einen Fehler!

Un.Glaub.Lich. Sollte das nicht immer so sein?

Na ja. Ich für meinen Teil empfinde es als sehr angenehm, wenn eine Sprache auf unnötigen Ballast verzichtet, und die sinnlose Konstrukte verbietet und nicht nur als Warnung anzeigt. Ich finde es angenehm, wenn ich aus verschiedenen Libraries (z.B. 20 JSON) die auswählen kann, die für meine Bedürfnisse ideal ist. Wenn ich aus einer ganzen Reihe von Mocking-Frameworks wählen kann, mit denen ich die Legacy-Anwendungen meines Vorgängers wenigstens testen kann. Wenn es sich für einen Anbieter lohnt, sein UI-Framework weiterzuentwickeln oder Plugins anzubieten, die mich *wesentlich* produktiver arbeiten lassen. Wenn ich zwischen kleinen und großen, jungen und alten ORM-Frameworks wählen kann, wo Linq nicht das Gegenteil von Recht ist, wo ich beim Debuggen auch mal eben -wupps- eine stored procedure schrittweise debuggen kann und und und.

Und ich finde es sehr angenehm, wenn ich bei der Suche nach Mitarbeitern eine Auswahl habe und nicht den einzigen nehmen muss, der im Umkreis von 200km verfügbar ist.

[Hansa]

Zitat:

Zitat von Phoenix (Beitrag 1318788)

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

Der wahre Produktivitätskiller liegt hier :

Zitat:

Zitat von Phoenix (Beitrag 1318788)

Warum ein neues kleines Tool denn nicht mal mit Ruby oder Python basteln?

Also Python lernen (z.B. 3 Wochen ?) und etwas mit einer Zeile machen, wofür ich in Delphi 3 gebraucht hätte ? Tja, so kann man Produktivität auch definieren. :lol:

Zitat:

Zitat von Phoenix (Beitrag 1318788)

jedem anderen Entwicklungs-Ökosystem da draussen mindestens genauso..

Sehe ich genauso kritisch. Unter Ökösystem versteht man eigentlich einen Kreislauf. Ich atme Luft ein und wieder aus und die ausgeatmetet Luft wird von Pflanzen wieder in Sauerstoff umgewandelt und den atme ich dann wieder ein. Wenn M$ auf die Idee kommen sollte, den Papierkorb abzuschaffen (den sie sowieso von Apple geklaut haben), tja was sollen die Delphi-Entwickler denn da innerhalb dieses Pseudo-Ökosystems machen ?

Dann propagierst Du noch diverse Zusatztprodukte. Soll ich da jetzt 100 Komponenten usw. zusammenbauen und hoffen, dass alles läuft ? Ich sehe da eher das Problem, dass man sich mehr zu fixende Bugs einhandelt, als nötig oder sich verzettelt mit Ruby usw. Zumindest dafür kann man aber Emba dann nicht verantwotlich machen.

[mensch72]

Der letzte Satz von @Dejan Vu kommt der Realität am nächsten!

Delphi war mal sehr verbreitet, ist heute mit Mobil&FMX wenn man es sich leisten kann zwar wieder sehr nah am Markt, aber eben nun nicht mehr sehr verbreitet und die Leute die es können werden älter und teurer.

Was heißt schon "Höhe der Zeit"?
SprachFeatures?, IDE?, Debug?, Portabel?, freie&komerzielle"Komponenten"?

Die "arme" Jugend und die Schulen geben Anfangs kein großes Geld für aktuelles Delphi aus, und später gibt es kaum einen Grund für den Neu-Einstieg in Delphi. Delphi fehlt schlicht ein Grund, warum man es anfangs NEU nehmen müßte. (Bestandsprojekte mal aussen vor, dann nimmt nur wer es hat und kann, es eben aus Gewohnheit weiter auch für neues)

Bei "native C" ist es ähnlich, aber doch anders. Anfangs lernt das auch niemand mehr, aber wer dann in Lehre oder UNI etwas in Richtung Hardware Nähe geht, stellt plötzlich fest das es doch tatsächlich noch sowas wie pures C gibt. Portabel heißt da plötzlich nicht mehr WIN,OSX,IOS, sondern 8Bit,16Bit&32Bit MicroControler... und da geht es dann doch auch ohne LINQ, ORM oder was weiß ich... einfaches selbstdiszipliniertes strukturiertes programmieren mit gaaanz viel Eigenverwantwortung für das was man tut.
Auch da gibt es Nachwuchs und Leute nicht (überall) wie Sand am Meer, aber es gibt sie und sie kommen auch weiter die nächsten Jahre kontinuierlich nach.


Fazit: Delphi mit FMX ist wieder gut, nur ohne Verbreitung entkommt es nicht mehr der biologischen Sackgasse in die es steuert. Die nächsten 10Jahre mit 2 Updates pro Jahr sehr ich aber noch gesichert:)

[Dejan Vu]

Zitat:

Zitat von Hansa (Beitrag 1318834)

Der wahre Produktivitätskiller liegt hier :

Zitat:

Zitat von Phoenix (Beitrag 1318788)

Warum ein neues kleines Tool denn nicht mal mit Ruby oder Python basteln?

Es geht hier eher darum, seinen Horizont zu erweitern. Das macht der professionelle Entwickler (nach Robert C Martin, 'Clean Coder') in seiner Freizeit oder wenn es sonst wenig zu tun gibt. Ein professioneller Softwareentwickler bildet sich auch weiter, schaut sich neue Entwurfsmuster an, feilt an seinen Skills etc.

Zitat:

Wenn M$ auf die Idee kommen sollte, den Papierkorb abzuschaffen (den sie sowieso von Apple geklaut haben)...

Nein. Microsoft hat ihn von Xerox geklaut. Und Steve Jobs war sauer, weil Bill Gates zuerst da war.

Zitat:

Zitat von Wikipedia

In der Tat wurden Konkurrenten sogar in die Entwicklungsabteilungen eingelassen. Darunter waren unter anderem Steve Jobs und Bill Gates, die sich dort den Xerox Alto ansehen konnten und das dort gewonnene Wissen für eigene Produkte einsetzten. Jahre später beklagte Jobs, dass Microsoft das Konzept der GUI bei Apple gestohlen habe, worauf Bill Gates antwortete:

„No, Steve, I think it's more like we both have this rich neighbour called Xerox, and you broke in to steal the TV set, found I'd been there first, and said: ‚Not fair, I wanted to steal the TV set.‘“

– Bill Gates