Python bietet sich mittlerweile an. Python hatte abseits der Oracle PHP Erweiterung eine brauchbare Unterstützung für die Datenbank und war bis zu einem gewissen Grad webfähig. Damals war PHP am Absterben. Das war so um PHP 4 herum. Python hatte zu der Zeit schon ein soliden Support für 'Bindings Out of the Box', sprich keine Notwendigkeit Header Files zu übersetzen und die 'zentrale' Registratur.
Die Glanzzeit von Delphi am Web war zu Zeiten von ASP. Ein Enterprise Umfeld zeichnet insbesondere die totale Kontrolle über die Infrastruktur aus. FPC/Laz war an sich auch schon nach 2010 in Kombination mit Fast-CGI brauchbar, aber die Billighoster haben einfach die Boxen nach einm Systemauptade in der 'Cloud' haben abgeschossen. Weswegen viel mit Scripting usw. wurde gearbeitet.
In 2009 versuchte ein Freund von mir ein Deployment eines Python Programms zu erreichen. Im Prinzip eine Systemmigration in einem Konzern und von einer einfachen aber praktischen Python 'Anwendung', welche es erlaubte Tabellen zu navigieren, aber für damalige Verhältnisse so richtig fette und über den Webbrowser aus der Zeit nach 2k. Der Anruf beim Support endete, 'Python wer? Python wie? Davon hörten wir nie!' und noch dazu in einer bestimmten Version.
Auch das fällt unter volle Kontrolle der Infrastruktur. Delphi Anwendungen sind diesbezüglich noch immer beliebter, bspw. im selben Konzern eine Anwendung zum Management von Infrastruktur und bei Anlagenreparaturen. In so einem Fall laufen 400 Leute kreuz und quer durch die Gegend und die ausfassten Materialen müssen getrackt werden inkl. Lagerstandsbuchungen (zumindest erfasst). Wenn, wie in einem praxisrelevanten Fall, die Serververbindung zum Rechenzentrum weg ist, dann konnte man mit der Delphi Anwendung einfach eine Sicherung vom Rechenzentrum im Betriebsgelände holen, die Datenbankdateien lokal installieren, den Datenbankpfad verbiegen und weiter ging es. Als diese Anwendungen entstand war es mit .net noch nit weit her, besser gesagt, selbiges in weiter Ferne. Die Anwendung läuft mittlerweile im Alter von über 25 Jahren wie damals. Wenn die 400 Leute ins Stehen kommen, ... und der Anlagenstillstand mit Folgekosten usw. Für Enterprise Szenaren ist Delphi tip top. Sprich auf einer Maske wurde abgebildet wofür man in SAP 24 braucht und viel Modifikation. Tja und so zogen Unmengen an SAP Berater wieder von der IBM von dannen und das nachdem 'Das machen wir so nebenbei mit. Aus Wochen wurde Monate und nach 1,5 Jahren hat die IBM den Stecker gezogen'. Was diese Small Footprint Databases nicht alles in der Lage sind zu leisten.
Anwendungen unter UNIX oder Linux sind nicht wie unter Windows, sprich weniger integriert. Diese Spezialität bietet eher der Windows Desktop.
Der FireMonkey aka. FMX war zu Beginn auch für Business Anwendungen am Mac, siehe U.S. und für Business Anwendung gedacht und in die Linux Option für den EMS, zu Beginn. Später kam der
GUI Aspekt supported über einen kürzlich leider verstorbenen Third-Party Provider hinzu.
Enterprise und Professional ist keine Rangordnung. Tools für Professionals waren schon immer anspruchsvoller, da diese 'Berufsgruppe' von der IT lebt. Ein Konzern lebt davon, dass insbesondere auch alles andere klaglos funktioniert. Wenn man serverseitig für Windows Server implementiert und clientseitig eine
GUI Anwendung, dann ist man schon in einer Mischung aus Enterprise plus Professional. Der David I. sprach das Thema einmal an, Thema Datenbanksupport in Delphi und C++ Builder, dass die Professional eigentlich für
GUI Desktop ist.
In unseren Breitengraden haben wir diesbezüglich eine wenig eine andere Kultur, vermutlich noch aus der Tradition der Integrierten
DB-4GL Umgebungen aus den 1990ern und der Verbreitung von Servern unter Windows insb. 4. Bei uns war zuvor eher die Abkehr von CASE-Tools, denn die gerieten zurecht z.T. auch nicht unter Verruf. Diese Lücke haben zuerst VB und Delphi geschlossen, aber wer den Inder am Schoß der Abteilungsleiterin in den 1990ern loswerden wollte, die Typen in den 1990ern eine Handvoll Masken pflegten und das seit der Version 1 und das über die Dekade hinweg, der hat einfach die Entwicklungstechnologie getauscht und Inhouse gegen Professional. Java ist dort relativ hurtig als Reaktion darauf mit den Huge Stacks reingegrätscht.
Aber vor den 1990ern hatten viele mehrere Entwicklungstechnologien zur Hand, das kam in Verruf und seit gut 15 Jahren wieder. Das 'C' als die only one, war eine Reaktion auf Kundenbeschwerden insb. bezüglich
COM Programmierung. Die Idee von MS, an sich nicht dumm, war der Professional entwickelt den Teil näher dem
OS und der VB Programmierer, zumeist im Business angesiedelt, macht die Masken. Diese zwei Rollen standen sich teils 'verfeindet' gegenüber. Eine Kompromisslösung waren die CRM Systeme mit Dictionary. Die sind gut, aber ich kenne keines mehr, welches entweder wie eine fröhliche Mumie virtualisiert noch immer schnurrt, begleitet von einer Unzahl an ergänzenden 'Utilities', welche sich bspw. um die Erstellung von PDF Report (bspw. in einem Krankenhaus hier), sprich die modernen Aspekte kümmern. Deswegen kam oft eine Anfrage nach Delphi auf Linux schon vor gut 15 Jahren. Das Problem bezüglich FPC Lazarus war die Dokumentation der Systemänderung. Lieber die Daten 100mal mit der Kirche ums Kreuz, als einmal die Änderung eines symbolischen Links dokumentieren und zugegeben zuvor von Gott und der Welt, Leuten die von der IT null Ahnung haben, Unterschriften einholen.
Die Stärken von Delphi & Co kommen dann zur Geltung, wenn die Benutzer und Administratoren im Enterprise Umfeld und dessen Wahnsinn angekommen sind. Noch dazu haben IT Organisationen und mit der Zeit auch die User einen limited Scope, auch z.T. der Fähigkeit gewisse Technologieschienen industriell, sprich 24*7, am Laufen zu halten.
okay.
Dann bleibe ich wohl lieber bei Python und meinen aktuellen Compiler-Projekt:
hier
Das müsste dann unter Windows und Linux laufen.
Hab das aber noch nicht ausgiebig getestet...