David Millington nicht mehr bei Emba?

[Phoenix]

Zitat von Rollo62:

Dazu kann man anscheinend mit Pascal, C#, Swift usw. am Projekt arbeiten, womöglich sogar gemischt,
was es für Teams wohl einfacher macht in seiner Lieblingssprache zu schreiben.

Ja, ABER...

Das große ABER ist, dass Du mit einem Projekt prinzipell erstmal nur eine Plattform anvisierst.

Das heisst im Umkehrschluss, wenn Du z.B. nativ für den Mac entwickelst, du auch NUR die Apple-APIs im Zugriff hast. Dir fehlt alles, was nicht nativ zu dieser Plattform gehört. Dazu gehört eben, dass dir als .NET/C#ler eben alle Dinge fehlen, die Du in .NET so liebst. Oder im Umkehrschluss als Java-Dev alles, was dir in Java das Leben angeblich einfacher macht. Als Delphianer hast Du freilich nicht die VCL und auch vieles der BCL nicht im Zugriff. Du hast dafür aber eben auch ALLES direkt an der Hand, was Apple so in macOS bzw. iOS bzw. iPadOS bzw. WatchOS bietet. Ohne Swift oder noch schlimmer Objective-C zu lernen.

Klar, es gibt einen Kompat-Layer, der Dir die meisten Grundtypen ummapped, aber wenn Du z.B. einen Hintergrundservice bauen willst, wirst Du dennoch keinen .NET HttpClient haben, wenn das Projekt nicht gerade auf .NET targeted.

Leider - zumindest ist das meine Meinung - ist es am Ende eben nicht die Sprache die den Ausschlag gibt, sondern eben die APIs des eigenen Entwicklungs-Ökosystems, die jemanden wirklich Produktiv machen. Ohne meine ganzen APIs und Typen und Features die mit .NET so liefert, würde ich mir einen abbrechen, wenn ich etwas ähnliches in einem System bauen müsste - selbst wenn die Zielplattform das alles auch bietet: Ich kenne die dortigen APIs schlicht nicht (so gut). Da aber die meisten Systeme ja inzwischen plattformunabhängiges Entwickeln ermöglichen, fehlt dann em Ende eigentlich nichts mehr.

Die einzige Idee wäre eben, wenn man heute wirklich noch Plattform-native Anwendungen bauen müsste (wobei das eigentlich Schwachsinnig ist), alles bis auf das UI Plattformunabhängig zu bauen, eine gescheite Abstraktion zum UI zu bauen und dann nur noch diese Abstraktion nativ zu implementieren. Und genau an der Stelle könnte RO dann ins Spiel kommen, weil man dann "nur noch" die Plattformspezifische API lernen müsste, und diese eben mit der Sprache der eigenen Wahl direkt ansprechen könnte.

Aber gefühlt - meine letzten Erfahrungen damit sind jetzt auch schon 3-4 Jahre her - ist das ganze IDE-System mit Fire und Water halt irgendwie Dekaden hinter aktuell wirklich guten IDEs (also alles von JetBrains oder VS Code) hinterher. Ich würde da ehrlich gesagt lieber die Plattformspezifischen Dinge mit den Plattformspezifischen Hausmitteln Vibe-Coden und dann als shared library / DLL / so / dylib in meine Umgebung einbinden.