Delphi langsam ersetzen

[Bernhard Geyer]

Zitat von Daniel:

Zitat von Dejan Vu:

Was habe ich denn von meinen 20 Jahren Delphi-Erfahrung? N-I-X.

Wenn Du nach 20 Jahren der Softwareentwicklung daraus keinen Benefit ziehen kannst, dann ist das vermutlich kein Problem der Sprache.

[mm1256]

Das Argument mit den 20 Jahren Erfahrung sehe ich genauso. Das ist kein Problem mit der Sprache. Im Laufe meiner 24 Jahre Selbständigkeit hatte ich einige Programmierer (und eine Programmiererin) angestellt, die allesamt Delphi als "eine ihrer Sprachen" praktiziert haben. Keiner hatte sich wirklich auf Delphi konzentriert. Über die Ergebnisse zu lästern, erspare ich mir jetzt. Einzige Ausnahme war ein Student der schon in den 90-ern fast ausschließlich TurboPascal-Programme geschrieben hat, und dann sein Pascal-Wissen ab Delphi 1 weiter verwendet und vertieft hat. Heute hat er einen sehr gut dotierten Job als Delphi-Entwickler. Von der Höhe seines monatlichen Einkommens träumen wohl viele nur. Es ist letztendlich das Ergebnis seiner Spezialisierung auf eine einzige Sprache. Er "kann" zwar auch andere Sprachen, aber praktisch arbeiten tut er nur mit Delphi.

Ich selber kann auch nur eine einzige Sprache. Habe mir zwar andere Sprachen angesehen, aber wohl gefühlt habe ich mich mit keiner so richtig. Wir wissen aber alle, dass ein gewisser Wohlfühlfaktor zur erfolgreichen Ausführung seines Jobs ein wichtiger Beitrag ist.

Sicher gibt es Situationen, wo mehrere Sprachen gefragt sind. Doch ob sich der Einzelne mit dem ständigen Sprachenwechsel im Job wohl fühlen kann, sollte er für sich selbst entscheiden können und dürfen.

Mein Standpunkt ist jedenfalls: Lieber eine einzige Sprache vernünftig angehen, als mehrere nur oberflächlich. Natürlich sollte man das aber auch vom Alter abhängig machen. Wenn ich anstatt jetzt knapp 60 noch 25 wäre, dann würde ich mir sicherlich mehrere Sprachen intensiver rein ziehen, schon aus dem Grund um den vielzitierten Horizont zu erweitern. Dagegen ist überhaupt nichts einzuwenden.

Was ich mit allem sagen will: Gute Ratschläge zu erteilen ist in diesem Metier sehr schwierig. Wenn man die persönlichen Vorlieben und Fähigkeiten des Fragenden nicht kennt, könnten sogar gut gemeinte Ratschläge das Gegenteil bewirken.

Darum, aufgrund der wenigen Informationen des TE: Wenn ich der TE wäre, würde ich die gewonnene Erfahrung mit Delphi nicht über Bord werfen und mir den Stress antun, auf eine andere Sprache mit neuer IDE zu wechseln. Außer ich wäre noch unter 30..35 (also mit noch etwa 30 Berufsjahren vor mir) und würde mich mit Delphi nicht wohl fühlen. Dann allerdings würde ich C++ mit MS VS empfehlen, denn Delphi ist langfristig gesehen auf einem absteigenden Ast. Dass Delphi mal in die TOP 10 kommt, wird wohl ein Traum bleiben. Microsoft hingegen hat es geschafft, den Markt für Programmiersprachen richtig anzugehen. Vielleicht erinnert sich ja noch jemand daran, als MS mit C noch ein Nobody war, weit abgeschlagen hinter Symantec und Watcom. Die haben ihren Job einfach gut gemacht und für die Zukunft ist mächtig viel Potential (Geld) da, um das erfolgreich fortzusetzen.

[IBExpert]

Zitat von mm1256:

Microsoft hingegen hat es geschafft, den Markt für Programmiersprachen richtig anzugehen .... Die haben ihren Job einfach gut gemacht und für die Zukunft ist mächtig viel Potential (Geld) da, um das erfolgreich fortzusetzen.

Das einzige, was Microsoft geschafft hat, ist es, in der Windows Fat Client Welt ein Quasi Monopol für Entwicklungswerkzeuge zu schaffen und alle anderen Anbieter zu verdrängen.

Ob man mit Mobilgeräten Geld verdienen kann lass ich mal im Raume stehen, aber Microsoft hat dafür keinerlei Tools, mit denen ernsthafte Android und iOS Entwickler arbeiten. Das Windows Phone interessiert weiterhin keine Sau, Windows Universal Apps sind ein weiterer Rohrkrepierer, den nur IT Journalisten toll finden.

Freunde von mir (pocketfms.com) entwickeln eine Moving Map/Flightmanagement Software für Piloten, die wirklich Multiplattform ist, über die Plattform Marmelade. Wenn man sich da alleine mal anschaut, wie viele Setups für die jeweiligen Plattformen existieren, ist das alleine schon heftig: http://docs.madewithmarmalade.com/di...latform+guides

Angefangen haben die mal von 12 Jahren mit VS und hatten einen Windows CE und einen Windows Client, die sich aber erheblich unterschieden. Alles war mit VS programmiert. Als dann irgendwann die Mobiltelefone und Tablets immer mehr iOS und Android waren und netterweise gleichzeitig Microsoft de facto den Support für Windows CE eingestellt hat, haben die sich entschlossen, eine neue Plattform zu evaluieren. Es hat ca. 2 Jahre gedauert, bis ein brauchbarer Client fertig war, den man auch zeigen konnte und der nicht auf jeder Plattform völlig neue Macken hat.
Die neue Basis war also diese Marmelade Lib, eigentlich eine Gaming Engine, passt aber gut zu den Anforderungen.

Die waren dadurch nicht die ersten Anbieter im Apple Appstore oder im Android Market und haben dadurch auch diverse Kunden verloren, aber im Moment sind wirklich alle Clients 100% identisch in der Funktionalität. Darunter sind auch native Clients für Windows, Max OS-X, Win8-10 mobile, Android, iOS. Für jede Plattform setzen die aber ein eigenes Compile Setup ein, um die Binaries nativ zu erzeugen.

Als Sprache wird C++ benutzt, aber ohne eine ähnliche Multiplattform Bibliothek bringt die die Auswahl der IDE nix.

Die 2 Jahre Arbeit an der neuen Version haben auch Spuren an den alten Version hinterlassen, die während dieser zeit kaum verbessert wurde. Wer die alte Software kannte und dann die ersten neuen Prototypen gesehen hat, schaute erst mal recht dämlich, nach der Devise: Das ist alles? kann ja nicht mal 10% von dem was ich kenne ..... Das Argument "aber funktioniert immerhin auf iOS und Android" interessierte erst mal kaum jemand.

Mittlerweile ist der Aufwand für die Umstellung auf die neue Plattform abgeschlossen, alle Entwickler haben die neue API mehr oder weniger gut verstanden und man baut regelmäßig neue Features ein, die immer ohne Einschränkung auf allen Plattformen laufen und in allen Appstpres sind. Was aber ganz klar ist zumindest für dieses Unternehmen: Wenn man sich auf die Plattformen beschränkt hätte, die VS unterstützt, wären die schon lange arbeitslos und der Laden Pleite.

Chefentwickler Rob ist dabei schon ewig mit C++ unterwegs und musste keine neue Sprache lernen, sondern nur die Marmelade API und die Besonderheiten der anderen Plattformen bei Setup, Distribution etc. Ich hatte mich mit Ihm mal auf einer Luftfahrt Messe über Lazarus unterhalten und ihm ein paar Miniprojekte auf Android und iOS, die damit erzeugt wurden, gezeigt. Einen Quellcode zu schreiben, der über entsprechende Bibliotheken auf allen Plattformen mit der gleichen IDE debuggt werden kann, war ausgesprochen interessant aus seiner Sicht, aber aufgrund der von Ihm bevorzugten C++ Sprache und den bereits endlos vorhandenen Bibliotheken für seine Zwecke keine echte Alternative. So war das von mir aber auch gar nicht gedacht. Sicherlich hätte er sich schnell in die Pascalsprache einarbeiten können, aber er hätte für alles mögliche, was er als Syntax oder unter Nutzung siener Bibliotheken so in C++ runterschreibt, in Pascalsprache auch umsetzen können, aber dann wäre das sicherlich nicht in 2 jahren erledigt gewesen.

Mit geht das umgekehrt ziemlich ähnlich. Mittlerweile mehr 20 Jahre Pascalsprache/vcl/lcl in Delphi/Lazarus sorgen dafür, das ich nur in wenigen Fällen irgendein Verfahren suchen muss (meistens hier), um etwas umzusetzen. Schnick Schnack wie grüne Buttons oder sonstigen GUI Kram ersetze ich gerne durch Ownerdraw oder Konstuktionen mit TPanels o.ä., im gesunden Bewusstsein, das ich dieses Verfahren auch noch dann einsetzen kann, wenn irgendein Komponentenhersteller kein Bock mehr hat, weil er kein Geld mehr verdient und deswegen seine Komponenten nicht mehr weiterentwickelt werden. Da eh alles zur Laufzeit kommt, ist mir die Bedienbarkeit im Objektinspektor eh egal. Eine simple MakeButton(....) Funktion unterstützt dabei mittlerweile je nach globaler Config diverse icon libs, drag and drop auf favoriten toolbar, touch Bedienung, resizing, autoalign, u.v.m.

Sicherlich gibt es sowohl bei VS als auch für Delphi diverse Komponenten, die das alles besser und einfacher können, brauch ich aber trotzdem nicht, weil ich da einfach auch in 20 jahren zu viel kennengelernt hab, was es schon lange nicht mehr gibt.

Mein ganz entscheidener Vorteil ist aber auch, das ich als Chef in unserem Unternehmen selber entscheiden kann, womit wir arbeiten. Wer als Angestellter in seiner aktuellen Position das nehmen muss, was sein Chef sagt, hat da schon eine ganz andere Position. Und wer dazu eh kein Bock hat und sich daher eine neue Stelle sucht, der ist vielleicht mit der Pascalsprache nicht unbedingt extrem gefragt, aber man sollte nicht unterschätzen, das man durch auch bei entsprechender Kompetenz und Erfahrung sehr gute Gehälter fordern kann, denn in vielen Unternehmen erreichen die Delphi Programmierer mittlerweile ein Alter, das nicht merh weit von der Rente entfernt ist. Das sehe ich bei einigen Kunden und diverse Kunden suchen auch mehr oder weniger aktiv Nachfolger für solche Entwickler und würden gerne auch jemanden nehmen, der noch nicht 100% auf der Kappe hat, aber lernfähig ist und sich mit dem, was bereits vorhanden ist, aktiv auseinander setzen möchte, ohne immer nur zu hören, das man das alles besser neu schreiben sollte .....

Wer Delphi nach x Jahren also durch was anderes ersetzen möchte, muss sich immer überlegen, welches Know How man dabei neu lernen möchte. irgendwelche blöden Schleifekonstrukte und Variablen sind dabei noch geringste Problem. Das wahre Vokabular lernst du erst durch konkrete Anwendung. Die Bedienung der IDE gehört dazu. F5 oder F9 lernt man schnell, aber ein Delphi VCL Projekt mit den ganzen Units in eine standardkonforme VS Solution zu übertragen, ist da alleine schon ein wenig mehr Aufwand.

Und dadurch hast du noch keinerlei Vorteil, wenn deinen Kunden oder Chef nur die Funktionalität der Executable interessiert und von dir keine Ausreden anhören will, warum du zwar viel Geld kassierst oder zeit verballerst, aber seit 2-4 Jahren an der Portierung arbeitest, ohne das dadurch eine identisch bedienbare Software mit gleichem Funktionsumfang zu erstellen.

[Dejan Vu]

Zitat von IBExpert:

Das einzige, was Microsoft geschafft hat, ist es, in der Windows Fat Client Welt ein Quasi Monopol für Entwicklungswerkzeuge zu schaffen und alle anderen Anbieter zu verdrängen....

Du bist ein professioneller Anbieter? Hmmm. Und dann so eine Aussage?

Zitat:

...Es hat ca. 2 Jahre gedauert, bis ein brauchbarer Client fertig war,

Das Einzige, was ich brauchbar für Windows auf einem Symbol (Handheld) hinbekommen habe (weil ich nur den einen Auftrag hatte), war nach 2 Tagen fertig. Und ich hatte noch nicht einmal Ahnung von dem Thema. Nicht, das ich der el gran Zampano unter den Programmierern bin (ganz sicher nicht), aber es war nunmal einfach einfach.

Übrigens: Wer in seiner Delphiwohlfühlblase mit Delphi klar kommt: Toll. Man kann ja mit Delphi wirklich so ziemlich alles machen. Na ja. Außer: Ein Team zusammenstellen. Aber lassen wir das. Man kann auch mit VB oder mit irgendeiner antiquarischen Sprache sehr viel machen, wenn man sie denn beherrscht. Aber, Holger. Das ist doch kein Argument. Außer vielleicht der letzte Strohalm, bevor man erkennt.... :kopfschuettel:

Nochmal: Das Thema lautet.... "Von Delphi weg... aber langsam"...

[Luckie]

Ohne alles gelesen zu haben. Ich bin an Lazarus und Freepascal gescheitert. Meine einfache Idee: Auf dem Smartphone (Android) einfach nur Dateien löschen. Unter WhatsApp/Images und die Thumbnails.

Ich habe alles so wie in einem Tutorial beschrieben installiert. Ich habe nicht mal eine einfache Form für Android kompiliert bekommen. Sehr ernüchternd und demotivierend.

Meine Idee war eine App, wo man per Checkbox einfach anhakt, was wo gelöscht werden soll. Nichts wildes. Drei, vier Checkboxen und einen "Mach es"-Button.

Es hat nicht funktioniert.

Ich wäre ja gerne bereit für die neuen Technologie, aber nicht so. Wenn man sich die Entwicklungsumgebung zusammenfricklen muss.

[jaenicke]

Das funktioniert mit Delphi in der Regel problemlos. Sofern der debug Treiber für dein Gerät installiert ist, genügt es wenn du Delphi installierst und dann das Handy anschließt und F9 drückst. Für das Formular kannst Du mit Delphi arbeiten wie sonst auch. Nur dass es eben firemonkey ist, aber das macht bei so einfachen Apps keinen Unterschied.

[Daniel]

Ja, Michael wollte es aber gerade mit Alternativen probieren.

Es wäre aber gut, wenn Ihr wieder sachlich zum Thema kommen würdet. Die üblichen Floskeln der "ehemaligen Delphianer" bezüglich der "Wohlfühlblase" etc. bringen uns nicht weiter und sind nicht weniger enervierend als im vergangenen Jahr. Es ist einfach müßig.

[IBExpert]

Zitat von Dejan Vu:

Zitat von IBExpert:

Das einzige, was Microsoft geschafft hat, ist es, in der Windows Fat Client Welt ein Quasi Monopol für Entwicklungswerkzeuge zu schaffen und alle anderen Anbieter zu verdrängen....

Du bist ein professioneller Anbieter? Hmmm. Und dann so eine Aussage?

Siehst du das anders? Zähl mir doch mal die möglichen kommerziellen Anbieter für Entwicklungswerkzeuge mit existierendem Support auf, die noch in der Windows Welt übrig geblieben sind? Und bitte nur die, die nicht nur Exotencharakter haben? Da war vor 15 Jahren deutlich mehr Auswahl.

Sicherlich ist vieles auch durch Open Source zugrunde gegangen, aber Microsoft konnte alle Entwicklungswerkzeuge mit den Erlösen anderer Produkte (Office und Windows) subventionieren. Und einige Sachen (z.B. Foxpro) hat man einfach gekauft und eingestampft. Ob Foxpro gut ist oder nicht lass ich dabei mal jeden selbst entscheiden, dbase im Hause Borland hatte ja ein ähnliches Schicksal.

Zitat von Dejan Vu:

Zitat von IBExpert:

...Es hat ca. 2 Jahre gedauert, bis ein brauchbarer Client fertig war,

Das Einzige, was ich brauchbar für Windows auf einem Symbol (Handheld) hinbekommen habe (weil ich nur den einen Auftrag hatte), war nach 2 Tagen fertig. Und ich hatte noch nicht einmal Ahnung von dem Thema. Nicht, das ich der el gran Zampano unter den Programmierern bin (ganz sicher nicht), aber es war nunmal einfach einfach.

Naja, Technisch ist ein Moving Map System auch nicht nur mal eben 10 Komponenten zusammenklicken. Es gibt sehr viel Software, die auch ein großer Zampano nicht mal eben in zwei Tagen auf eine andere Plattform portiert.

Zitat von Dejan Vu:

Übrigens: Wer in seiner Delphiwohlfühlblase mit Delphi klar kommt: Toll. Man kann ja mit Delphi wirklich so ziemlich alles machen. Na ja. Außer: Ein Team zusammenstellen. Aber lassen wir das. Man kann auch mit VB oder mit irgendeiner antiquarischen Sprache sehr viel machen, wenn man sie denn beherrscht. Aber, Holger. Das ist doch kein Argument. Außer vielleicht der letzte Strohalm, bevor man erkennt.... :kopfschuettel:

Ich hab sehr oft zu tun mit Kunden, die sogar teilweise ziemlich große Teams haben und sehr professionelle Software entwickeln. Und ganz viele von denen arbeiten mit Delphi und einige von denen wollen auch ganz offen von Delphi weg, müssten aber erst mal x Mannjahre realisieren, um überhaupt was vergleichbares auf die Beine zu stellen, wo der Kunde auch nur annähernd den kompletten Funktionsumfang hat und weiterhin Geld für die Produkte bezahlt. Das ist dann simple Betriebswirtschaft für den Unternehmer. Wenn er sich das leisten kann und anschliessend echte Vorteile hat, kann sich das rechnen. Es kann Ihn aber auch in die Pleite treiben ...

Die IDE und Programmiersprache ist nur ein Baustein für den Erfolg eines Softwareprojektes, Prozesswissen und Softwarearchitektur sind aus meiner Sicht aber wesentlich wichtiger im Wettbewerb. Wenn man kein generelles personenunabhängiges Konzept für eine langlebige Softwarearchitektur hat, wird man mit den vorhandenen Ressourcen eh irgendwann an der Komplexität der Materie scheitern, egal in welcher Programmiersprache und mit welcher IDE.

Ich sehe daher auch sehr oft im Kundenauftrag über den eigenen Tellerrand hinaus und diskutier mit Kunden deren Performanceprobleme, meistens im Bereich Datenbanken, aber auch oft in Hinblck auf Softwarearchitektur. Da sind auch Kunden mit Java, VS c++, c# oder eben auch Delphi dabei.

Dabei wird oft deutlich, das die keine eigene Softwarearchitektur haben, sondern sich einfach leiten lassen nach der Devise: Ich mal das einfach mal so weil ich das schon immer so gemacht hab und weil es funktioniert. Ob nun Delphi einen dazu verleitet, einfach alles zusammenzuklicken und damit nicht wirklich wartungsfähige Software erstellt, muss jeder selbst entscheiden. Wer ein komplexes Delphi Projekte mit tausenden irgendwo verteilten Datasource/Datasets hat, macht was falsch! Das ist eine Sackgasse. Für kleine Projekte oder wenn man mal eben was zusammenklöppelt, an dem man eh nichts mehr ändern muss, ist das ok.

Den gleichen Schrott fangen viele dann aber auch in anderen Programmiersprachen an, weil die es es nicht besser wissen.

Delphi langsam ersetzen ist zwar der original Thread aber ich würde jedem vorher empfehlen, eine geeignete Softwarearchitektur zu entwickeln und basierend darauf dann auszuwählen, ob das mit Delphi, VS, java oder als Webapp umgesetzt werden soll.

Viele setzen zwar eine Pseudosoftwarearchitektur auf Basis von Delphi Klassen ein, die ist aber oft schon in jede 2. Zeile mit TDataset verheiratet, so das die auf anderen Plattformen so gar nicht mehr implementierbar sind.

Das hat auch nichts mit einer Delphi Wohlfühlblase zu tun, wenn du eine Architektur als Backend hast ist, dann ist die Programmiersprache und IDE extrem austauschbar. Ohne Architektur machst du in der nächsten Welt viele Fehler wieder und hast nur den Teufel durch den Belzebub ersetzt.

[sh17]

Jupp, so isses.

Wir sind aktuell dabei, nach längerer Vorbereitung der Architektur in Delphi, unser Backend nach Oxygene zu portieren, sodass es auf .Net,Java und iOS läuft. Wenn man die Eigenheiten aller Plattformen beachtet und keine Abhängigkeiten in Delphi erzeugt, klappt das ganz gut. Aktuell lässt sich so einfach viel rüber kopieren und es müssen nur noch die Oxygene-eigenen Sprachmerkmale angepasst werden. Wir haben lange überlegt, ob wir alles in den jeweiligen Sprachen direkt neu schreiben, haben uns aber vorerst dagegen entschieden.

[MrSpock]

Zitat von IBExpert:

...
Das hat auch nichts mit einer Delphi Wohlfühlblase zu tun, wenn du eine Architektur als Backend hast ist, dann ist die Programmiersprache und IDE extrem austauschbar. Ohne Architektur machst du in der nächsten Welt viele Fehler wieder und hast nur den Teufel durch den Belzebub ersetzt.

Hallo Holger, bzgl. der Microsoft Strategie des "Vertreibens" jeglicher Konkutrrenz stimme ich dir zu. Ich habe das schon vor Jahren erschreckend feststellen müssen. Damals habe ich noch mit WordPerfect Office gearbeitet, DBase und Paradox, Netscape und wenn man in die Fachliteraturabteilung einer Bücherei gegangen ist, hat man noch eine gute Auswahl an Systemen gefunden. Microsoft hat alles plattgemacht. Und ohne Borland gäbe es auch auf dem SW Entwicklungsmarkt fast nur noch eine Monokultur. Mir kommt deshalb auch .NET nicht in die Tüte. Reine Windowsanwendungen entwickle ich mit der VCL. Ansonsten Java oder C++. Dazu gibt es dann gute IDEs mit Eclipse oder Netbeans. Auf meinem Mac nutze ich Objective-C und arbeite mich weiter in Swift ein.

Eine Frage habe ich zur praktischen Anwendung der "Softwarearchitektur". Ich habe mich mit dem Thema Systemarchitektur schon oft auseinandergesetzt und kenne zum Beispiel den amerikanischen Verteidigungsstandard DoDAF zur Definition einer Architektur. Mich würde interessieren, wie ihr die Architektur definiert und nach Delphi bzw. Lazarus umgesetzt habt. Nutzt ihr UML, wenn ja, welches Tool und welche Ansichten. Beschränkt sich die Architektur auf Klassendiagramme oder geht sie darüber hinaus?