David Millington nicht mehr bei Emba?

[dummzeuch]

Zitat von himitsu:

Beim C++Builder kannst du auch Pascal-DCUs einbinden. (glaub nur DCUs, nicht direkt PAS)
Andersrum wäre es auch schön gewesen.

Nee, .pas geht auch. Aber ja: Andersrum wäre schon mehrfach sehr praktisch gewesen.

[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.

[Rollo62]

Zitat:

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.
...
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.
...

Ok, ich sehe hier das Elements.RTL und bin davon ausgegangen, dass es alle bietet was z.B. Delphi bietet.
Du meinst also mit Kompat-Layer, sowas in der Art wie Elements.RTL, aber eben nur rudimentäre Klassen und keine Forms, Components oder sonstige UI-Schichten.

Das wäre allerdings blöd, wenn man mit einem Source nicht alle Plattformen erreicht, dann macht es wirklich keinen Sinne.
Dann kann ich wirklich direkt nativ arbeiten.

Gut, der einzige Vorteil wäre dann noch, dass man eben nicht in XCode, Android Studio, VisualStudio usw. arbeiten muss,
sondern das alles unter einem System (IDE) programmierbar ist.

Wenn dafür dann aber keine generischen Labels, Buttons, GridViews, usw. vorhanden sind, die in allen Plattformen gleichermaßen vorhanden sind, dann wäre das allerdings schlecht.
Ich hätte jetzt gedacht, dass dies in so einem System leicht möglich sein sollte einfache UI (Button, Edit, Layout, Memo, ...) überall aus einer Source heraus zu generieren und jeweils für die einzelne Platform optimal anzuzeigen.