Sind wir veraltet?

[freimatz]

Ne ne, das ist der MichaelT. Der schrieb schon so als es noch keine KI gab die schreiben konnten.

[vr2]

Spannender Thread, und die Beschreibung von dummzeuch gibt die Lage gut wieder, danke! Na denn:

1. Delphi

Ich nutze Delphi seit Ewigkeiten. Sehr lange sah es bei Delphi nicht gut aus, das Unicode-Geraffel, Firmenwechsel, ... da sind einige gute Entwickler weitergezogen. Die IDE ist immer noch eine Krankheit. Manche Treiber für Datenbanken buggy, der Paketmanager GetIt mit veralteten Paketen, ... Je nachdem, was man machen will, ist es Gefrickel ohne Ende. SynEdit ersetzen, weil der alte Ranz modify after free macht? Viel Spaß. Doku zu Delphi im Netz ist zäh mittlerweile. FastMM4 veraltet, UIB tot, Firebird 4-Features werden kaum unterstützt. Visualisierung/GUI geht besser mittlerweile - woanders.

Von Delphi will ich hauptsächlich

- amtliche Datenbankanbindung, alles, ODBC, native APIs auf dem Stand, nicht Jahre hinterher
- ordentliches GUI / Visualisierung
- aktuelle Funktionen (schmerzfreie Unterstützung für Parallelisierung bspw - die ist wirklich gut)
- reibungslose Updates
- gepflegte Dokumentation
- RAD - aber echt

Bspw hätte ich von Delphi gern die Unterstützung von UDRs ab Firebird 4 oder überhaupt mal das komplette API abgedeckt. Dafür gibt es bisher nur fbintf von Tony Whyman https://www.mwasoftware.co.uk/fb-pascal-api. Das Paket ist amtlich, aber was, wenn der in Rente geht?

2. Web

Kenne u.a. javascript (ECMAScript >= 6) gut. Nimmt man libs wie d3 https://github.com/d3/d3/blob/main/API.md oder plot https://github.com/observablehq/plot/tree/main/src, bekommt man mal den Blick von der anderen Seite. Der Code modular, kein Gramm Fett, eben nicht die xten Frameworks, Releases gut dokumentiert, so hätte ich das gerne bei Delphi. Und zum Entwickeln reicht ein guter Texteditor wie notepad++ und ein Browser. Debugging - im Browser, funktionierend.

3. Wie anders?

Aufs Wesentliche konzentrieren. Zuständigkeiten modularisieren. CIP bekommt Vorrang vor immer noch mehr Features.

Bei großen Delphi-Altanwendungen sind meistens Abhängigkeiten und Komplexität die Hauptprobleme. Beides einfach zu minimieren muss der Schwerpunkt der Ausrichtung sein, oberste Prio. Diese Unterstützung will ich von meinem Werkzeug. In Delphi würde ich VCL etc auslaufen lassen und GUI / Visualisierung über Webtechniken machen, dabei aber die Firefox-Engine zugrundelegen. Unterstützung von SVG inklusive, frei Haus. Plattformunabhängig.

Geschäftslogik in die Datenbank verlagern. Über die o.g. Unterstützung von Firebird-UDRs (von Plugins träume ich gar nicht erst) ließen sich externe Stored Prozedures umsetzen, mit denen die Datenbank bspw einen Webrequest machen kann oder einen ODBC-Request. Queues in die DB verlagern. Ordentliche Transaktionssteuerung für die Geschäftslogik. Dann ist das backend und das Kernstück der Anwendung auch plattformunabhängig, und robust. Anderen Client inkl REST-Server davorhängen? Datenaustausch mit anderen Systemen? Konsistenz? Kein Thema.

Delphi dann außerdem für die Kopplung der beiden Welten und das, was so nicht sinnvoll abgedeckt werden kann. Das wird oftmals einiges handlicher sein.

So modularisiert können Aufgabenbereiche besser verteilt und separat getestet werden.

[Codehunter]

Zitat von vr2:

In Delphi würde ich VCL etc auslaufen lassen und GUI / Visualisierung über Webtechniken machen, dabei aber die Firefox-Engine zugrundelegen. Unterstützung von SVG inklusive, frei Haus. Plattformunabhängig.

Wenn man Delphi ohne native GUI denkt, dann bleibt da kaum was über das man nicht mit anderen Frameworks wesentlich schneller erledigen könnte. Es gab ja mal so einen Versuch, glaube von Devexpress, wo man sich auf dem Formulardesigner ein Webformular zusammenklicken konnte. Ist schon lange her und glaube ich auch nicht mehr weiter gepflegt. Wohl auch besser so, das ganze fühlte sich an wie Dreamweaver für Arme. Auch das ist schon lange tot und IMHO zurecht gestorben. Heutzutage nimmt man für Web-Frontend-Entwicklung meist irgendein buzzwordiges Framework, klebt damit ein rudimentäres GUI zusammen und plant den Totalabriss in zwei bis fünf Jahren gleich mit ein. Einfach weil die meisten Web-Frameworks nur so kurze Lifecycles haben. Beispiel jQuery: Einst gefeiert und überall verbaut, wirbt u.a. Bootstrap inzwischen damit, ohne dieses auszukommen.

Ich seh es genau umgekehrt wie du: Es ist (vielleicht zusammen mit Visual Studio) ein Alleinstellungsmerkmal von Delphi, native GUIs in kurzer Zeit erstellen zu können. Dort wo Delphi heut noch zum Einsatz kommt, dass sind i.d.R. Profi-Anwendungen mit extrem langfristiger Verfügbarkeit. Also IMHO das krasse Gegenteil von dem was heutzutage bei Webfrontends gemacht wird. Ich würde also das Alleinstellungsmerkmal kultivieren anstatt absägen. Aber da red ich ja mit der Hand wenn ich seit Jahren trommle dass sie die VCL X-Plattform machen und alle Compiler mit allen Editionen ausliefern sollen.

[vr2]

Zitat von Codehunter:

Wenn man Delphi ohne native GUI denkt, dann bleibt da kaum was über das man nicht mit anderen Frameworks wesentlich schneller erledigen könnte. [...]

Ich seh es genau umgekehrt wie du: Es ist (vielleicht zusammen mit Visual Studio) ein Alleinstellungsmerkmal von Delphi, native GUIs in kurzer Zeit erstellen zu können. Dort wo Delphi heut noch zum Einsatz kommt, dass sind i.d.R. Profi-Anwendungen mit extrem langfristiger Verfügbarkeit. Also IMHO das krasse Gegenteil von dem was heutzutage bei Webfrontends gemacht wird. Ich würde also das Alleinstellungsmerkmal kultivieren anstatt absägen. Aber da red ich ja mit der Hand wenn ich seit Jahren trommle dass sie die VCL X-Plattform machen und alle Compiler mit allen Editionen ausliefern sollen.

Ich sehe das tatsächlich ähnlich wie Du, hast in vielen Punkten Recht, deswegen muss ich meinen VCL-Vorschlag erklären. Plattformunabhängiges GUI ist sicher mindestens so aufwändig wie alle möglichen DBs zu unterstützen. Man käme aber in vielen Fällen schon sehr weit mit einem webbasierten GUI, ohne weitere libs. Da geht mit HTML5 und CSS3 schon eine ganze Menge. Will/muss man das GUI komplexer datengesteuert aufbauen/ zur Laufzeit verändern, kann man sowas wie d3.js (data driven documents, ein modulares Microframework) ins Spiel bringen. Ich hab d3 bewusst erwähnt in Abgrenzung zu den buzzword-frameworks, dann a) ist es standardkonform - Arbeit, die man dort investiert, ist nicht für Tonne und b) ist es von einer Codequalität, die man suchen gehen kann. Oder ich lasse mir die Seite oder Teile davon, weil alles textbasiert ist, direkt aus der Datenbank erzeugen, da hat Delphi ja auch allerhand zu bieten. Dann brauche ich nur Ahnung von SQL und komme sehr weit. Auch bei SQL hat sich einiges getan, window functions bspw sind ein mächtiges Konstrukt.

Angenommen, Du willst eine Fabriksteuerung schematisch visualisieren und darüber auf einem Screen überwachen und steuern, oder das Dashboard eines Reporting-Systems - mach das mal mit der VCL. Aus Delphi-Sicht wäre dafür "nur" nötig, eine ordentliche Rendering engine zu integrieren, man würde sich vermutlich einig mit Mozilla. Und wenn Du dann eine Stelle asynchron haben willst, packst Du eine kleine selbergeschriebene js-unit oder .pas-unit dazu. Der Ansatz würde auch die Abhängigkeit von TeeChart relativieren.

Re Frameworks: Immer so wenig wie möglich, für Packages gilt das gleiche.

VCL X-Plattform machen: Ja klar, aber der jetzige Delphi-GUI-Gemischtwarenladen - das kann sich ziehen. Das Problem ist nicht neu, ich weiß nicht, woran es hängt, ist aber irgendwann auch egal. Es gibt andererseits da draußen viele, die sich mit Web gut auskennen, denen kann man sagen, ihr könnt die Oberfläche einer Delphi-Anwendung umsetzen, wie ihr es kennt, und dann schauen wir uns die Datenanbindung und Steuerung an. Das könnte für Emba den Druck etwas rausnehmen, sie könnten sich in Ruhe um die GUI-Integration kümmern, aber derweil kämen etliche neue und jüngere Leute, die ihr bisheriges Knowhow zu Delphi mitbringen können. Denn bspw App-Entwicklung ist/war lange sehr frickelig. Das könnte auch für Firmen mit großen Delphi-Anwendungen Entlastung und Perspektive bringen. Also mindestens längerfristige Perspektive, oder die Möglichkeit, einfach zu wechseln. Am besten beides, und zwar für Firmen und für den Nachwuchs.

Es geht auch darum, dass man mehr als eine Option hat, etwas umzusetzen, Hauptsache, die Basis dafür ist von guter Qualität. Delphi kann diese verschiedenen Welten zusammenbringen, und das Deployment zusammen mit dem direkten Draht zum Betriebssystem, der Webanwendungen normalerweise versperrt ist - das ist, wo Delphi wirklich wieder punkten könnte.

[Codehunter]

Zitat von vr2:

VCL X-Plattform machen: Ja klar, aber der jetzige Delphi-GUI-Gemischtwarenladen - das kann sich ziehen.

Der Witz ist: Die Arbeit ist ja schon lange getan in Form von CrossVCL, vom selben Entwickler der auch FMX ursprünglich erfunden hat. Diese Richtung nicht zu gehen ist eine politische Entscheidung seitens Emba.

Zitat von vr2:

Es geht auch darum, dass man mehr als eine Option hat, etwas umzusetzen, Hauptsache, die Basis dafür ist von guter Qualität. Delphi kann diese verschiedenen Welten zusammenbringen, und das Deployment zusammen mit dem direkten Draht zum Betriebssystem, der Webanwendungen normalerweise versperrt ist - das ist, wo Delphi wirklich wieder punkten könnte.

Das klingt fast nach DCOM und DHTML, mit dem Microsoft vor über 20 Jahren mal versucht hat, Web und native Anwendungen zu verheiraten. In der Delphi-Welt hieß die entsprechende Komponente TEmbeddedWB. Darauf aufbauend habe ich mal einen kleinen HTML-Wysiwg-Editor a la Dreamweaver gebaut. Aus dieser Erfahrung heraus weiß ich: Die Schnittstellen um sich in den DOM-Baum einzuklinken und mit dem User zu interagieren, waren geradezu irre kompliziert, regelrecht brainfucking.

Wenn es darum geht, sich von Teechart zu lösen, das kannst du auch einfacher haben. Integriere einen kleinen Webserver, liefere darüber deine Daten in REST/JSON aus und lass das Rendering ChartJS und die Chromium-Engine machen, die dem neuen TWebbrowser zugrunde liegt.

[vr2]

Zitat von Codehunter:

Der Witz ist: Die Arbeit ist ja schon lange getan in Form von CrossVCL, vom selben Entwickler der auch FMX ursprünglich erfunden hat. Diese Richtung nicht zu gehen ist eine politische Entscheidung seitens Emba.

Ui, das war mir nicht klar, danke für den Hinweis. Kennst Du die Gründe oder hast Du eine Vermutung, warum nicht?

Zitat von Codehunter:

Das klingt fast nach DCOM und DHTML, mit dem Microsoft vor über 20 Jahren mal versucht hat, Web und native Anwendungen zu verheiraten.

Nee, DCOM eher gar nicht, denke ich, weil über Rechnergrenzen lässt sich auch anders kommunizieren, bzw will ich mich um die Low-Level-Details nicht kümmern müssen, wenn ich ein fetch mache.
Und DHTML - das musste ich tatsächlich nachschlagen, ähm, alles was Du heute an Seiten siehst, ist demnach "DHTML", also das ist Standard und kannst Du voraussetzen. Und hat zum Glück mit Microsoft nichts zu tun.

Zitat von Codehunter:

In der Delphi-Welt hieß die entsprechende Komponente TEmbeddedWB. Darauf aufbauend habe ich mal einen kleinen HTML-Wysiwg-Editor a la Dreamweaver gebaut. Aus dieser Erfahrung heraus weiß ich: Die Schnittstellen um sich in den DOM-Baum einzuklinken und mit dem User zu interagieren, waren geradezu irre kompliziert, regelrecht brainfucking.

Ok, ein webbasierter wysiwig-Editor ist aber auch sportlich .

Zitat von Codehunter:

Wenn es darum geht, sich von Teechart zu lösen, das kannst du auch einfacher haben. Integriere einen kleinen Webserver, liefere darüber deine Daten in REST/JSON aus und lass das Rendering ChartJS und die Chromium-Engine machen, die dem neuen TWebbrowser zugrunde liegt.

Webserver hab ich lokal, kann denn auf Windows TWebbrowser weiterhin nur auf Edge basiert betrieben werden? Und ja ich weiß, die haben Chromium eingepackt. Geht evtl noch ein wenig "Telemetrie" zu MS, wenn man die Komponente nutzt.

Aus https://docwiki.embarcadero.com/Libr...r.TWebBrowser:

Supporting JavaScript Integration on Windows Platform
On Windows target platforms (WIN32 and WIN64), TWebBrowser may incorrectly display some Web pages if a Web site uses JavaScript dialog boxes, panels, and other elements for various purposes.
To work around this issue, your application should display Web pages in the IE11 edge mode using the FEATURE_BROWSER_EMULATION feature of Internet Explorer.

IE, damit javascript richtig funktioniert ?? Sind die noch ganz gesund? Den schlechtesten und kaputtesten Browser aller Zeiten emulieren und damit die Webkomponente betreiben? Hast Du mal nennenswert SVG an den Browser verfüttert? Das packte nicht mal der Edge, als er noch nicht auf Chromium basierte. Geschweige denn der IE. Schwächel. Wollte eigentlich kein kaputtes Spielzeug. SVG ist ein Standard, und was ich beschrieben habe, bezog sich noch auf den alten, zig Jahre alten Standard.

Also wenn der Hinweis aus der Doku noch aktuell ist, schau ich in einem Jahr noch mal nach. Das meinte ich weiter oben mit "gute Basis".

[jaenicke]

Zitat von vr2:

Webserver hab ich lokal, kann denn auf Windows TWebbrowser weiterhin nur auf Edge basiert betrieben werden? Und ja ich weiß, die haben Chromium eingepackt.
[...]
Also wenn der Hinweis aus der Doku noch aktuell ist, schau ich in einem Jahr noch mal nach. Das meinte ich weiter oben mit "gute Basis".

Was sollen sie denn sonst nehmen? Das ist nun einmal unter Windows das, was das System zur Verfügung stellt.

Wenn man etwas anderes nehmen möchte, muss man ja nicht TWebBrowser verwenden. Es gibt ansonsten aber an ernstzunehmenden Alternativen ohnehin nur Chromium mit direkter Ansteuerung, aber da muss man sich dann selbst um das Deployment kümmern usw., was die eigenen Releases aufbläht.

[Frickler]

Zitat von vr2:

Geschäftslogik in die Datenbank verlagern. Über die o.g. Unterstützung von Firebird-UDRs (von Plugins träume ich gar nicht erst) ließen sich externe Stored Prozedures umsetzen, mit denen die Datenbank bspw einen Webrequest machen kann oder einen ODBC-Request.

Embarcadero präferiert den Firebird-Konkurrenten InterBase, den sie selbst verkaufen. Aber der kann keine UDR, nur UDF, und die braucht man auch, denn die Datenbank ist wirklich sehr schlank gehalten. Der Fokus scheint mittlerweile auf IoT zu liegen, Industriesteuerungen, Messdatenerfassung, sowas.

[MichaelT]

Zitat von freimatz:

Ne ne, das ist der MichaelT. Der schrieb schon so als es noch keine KI gab die schreiben konnten.

Jup. Werde mich in Zukunft kürzer fassen oder eine KI bemühen. Fragt mich nicht was ich da geschrieben habe.

18er Juli. Da habe ich vermutlich meine Computerbrille ausgetestet. Danke für eure Geduld.

Vermutlich geht es um mein Lieblingsthema der Selbstständige im Sozialismus und die knappe Kasse im privaten Umfeld für solche und ähnlich gelagerte heute vermutlich schon eher als 'besonderes Extra' empfundene Ausgaben im Haushalt. Denke der Gustl passt ganz gut zum Thread.

---

Früher gab es in der DDR Westfernsehen, heute dafür bald vermutlich noch nicht einmal mehr Strom. Warten wir einmal diesen Winter ab. Ohne FAX-Geräte brechen dann sowohl der Deutsche Staat und Embarcadero gleichzeitig zusammen.

Ganz auf der Höhe der Zeit waren 'wir' eher in den 1990ern, zumindest bezüglich Delphi/Windows.

@Codehunter

Von Ablöse ist hier weit und breit keine Spur. Hie und da wird eine neu übersetzt, aber damit war es das. Delphi Programmierer findest du bei uns keine oder IT Leute in Österreich.

Der Bürgermeister von Linz/Donau ist auf 'Recruting' Reise in Serbien und versucht eine paar 'verlorene' Programmierer Seelen für Linz zu gewinnen, so steht es zumindest in der regionalen Zeitung. Inwiefern diese Reise mit einem auf grüner Wiese neu hingestellten Technologiezentrum zusammenhängt, kann ich nicht sagen. Auf jeden Fall scheint viel Platz darin übrig zu sein, aber da müsste ich einmal vor Ort nachsehen und mir selbst ein Bild machen.

In dem Sinne ist der gute alte 'Delphi Hero' ala Knight Rider, die One Man Show und seine IDE, mit KI spricht sie möglw. bald und erlaubt einem Höhenflüge zwar oldschool aber nicht ganz aus der Zeit.

Bei uns gilt an sich, hilf dir selbst dann hilft dir Gott. Für das ist mir Delphi resp. das RAD Studio durchaus recht und damit zu entwickeln fühlt sich wenn schon nicht gut, dann zumindest noch immer 'richtig' oder auf einem solchen Weg an.

Zentralismus schwächt Peer To Peer Ansätze. Ich möchte eher die Frage stellen, ob irgendjemand eine Dezentralisierungsbewegung ausmacht.

Ich habe keine Ahnung wie es in Deutschland aussieht, denn auf euren Wirtschaftsraum wird sich der Artikel beziehen, denke aber solche Artikel schlagen in die Richtung die letzten Programmierer/Entwickler alter Schule in eine wie auch immer geartete neue Welt zu bekommen.

Bei uns ist eher der Status. Die Crowd der Java, Ruby und .net Leute sitzt entweder in gefestigten Organisationen (teils öffentl. Charakter wie auch Banken und quält die User auf ihrem Wege) und wartet die bestehenden Anwendungen. Wie ein Freund von mir einst sagte, 'Michael. Wir schreiben einfach die Legacy von morgen und warten diese bis zur Ablöse'. Die sitzen und warten noch immer und insbesondere auf die Ablöse. Extreme Programming im Beamtenstil auf Österreichisch. Der gute Junge treibt sich vermutlich noch immer als Scrum Trainer herum, na gute Nacht. Der Fairness halber sei gesagt, vor 15 Jahren hatte ein Neugründer kaum eine andere Chance. Zu investieren war damals schon mutig.

Der Gust(i|l) steht im Moment einem Buch Freiheut von der Donner Monika gegenüber und dort entsteigt ein Tiger dem Schafspelz. Die neue Welt/Freiheit vs. die alte einst freie. Selbst dann wären wir noch immer im Stile der 1990er unterwegs.

Leopard wird keiner abgebildet, ansonsten erinnerte es wohl eher an FPC/Laz vs. eh schon wissen.

Ich habe noch nicht einmal mehr einen Backup und kann Softwareentwicklung auf dem Weg eher als Hobby vorantreiben oder Hoppy (Package). Hoppy/Hoppelchen ist der Nachfolger besser der Kollega vom Gustl dem angehängten Plüschmammut - Weisheit geboren aus Erfahrung vs. jugendliche Frische, Dynamik und Wissbegierigkeit.

Bei uns ist mit Entwicklung abseits von Standardprodukten, die sind thematisch eher selten technisch und eher kaufmännisch, nicht (mehr) viel. Der Geist der 1990er hier war im Stile der Kommunikation aus der E.U. - Schreibt den Kunden als Projekt was sie wollen und denkt nicht, ob sie es können brauchen und ansonsten wird Standardsoftware verwendet. Österreich ist schwer ERP lastig und 20 Jahre wurde zuzüglich Analysen dazu kaum etwas gemacht. Ein paar ambitionierte Ausnahmen bestätigten die Regel. Aber die meisten damals eher 'Brainworker' Produkte im Peer To Peer Stil sind entweder verschwunden oder als Serverlösungen existent. Aber mit jung und dynamisch und spritzig frisch ist es auch bei den Kunden nicht weit her.

Die meisten Lösungen für 'mobil' sind entweder Apps geschrieben im Osten Österreichs und Europas und der Mittelstand wertet entweder Datenbasen mit den neuen Reportingwerkzeugen und 'Umgebungen' für zumeist stat. Analysen aus und der Rest läuft über Infrastruktur nahe Lösungen, Klassiker iPad und RDP Sitzung.

Oldschool ist ein relativer Begriff.

[Codehunter]

Wir sind anscheinend doch noch nicht so veraltet