Ich weiß, es ist schon etwas her, dass Apple sich von Python verabschiedet hat. Dennoch frage ich mich, was man am Mac eigentlich jetzt noch gut für Skripte und kleine, schnell erstellte Programme nutzen kann.

AppleScript wird kaum mehr gepflegt und kennt keine regulären Ausdrücke. JXA wird ebenso wenig gepflegt, ist schlecht dokumentiert und es fehlt ein guter Editor dafür, der alle Mac-Besonderheiten kennt. Die Zukunft ist ebenfalls ungewiss. ZSH hat eine eigenartige Syntax und gerade die Stringbearbeitung ist teils so kryptisch, dass ich meine eigenen Skripte nach einigen Wochen nicht mehr auf Anhieb verstehe.

Habe ich noch eine Sprache übersehen, die mitgeliefert wird und nicht angekündigt ist?

Ich habe schon mit Xojo geliebäugelt, da ich damit ebenfalls schnell kleine Progrämmchen basteln kann, die auf jedem Mac funktionieren. Allerdings ist das ein teures Vergnügen und vor allem nervt die Kompiliererei. Ich bin kein guter Programmierer und muss immer wieder ausprobieren, ob einzelne Änderungen wie gewünscht funktionieren. Das geht mit Skripten viel schneller. Außerdem sind die vielseitiger und ich kann sie etwa in Alfred-Workflows nutzen.

Mir ist klar, das etwa Python3 mit den Xcode-Kommandozeilen-Tools schnell installiert ist. Aber wie lange noch?

Es gibt so viele genannte Punkte hier, denen man pro Punkt eigentlich einen eigenen "Journal" Eintrag widmen könnte Bin noch am Überlegen, ob ich mir den Sonntag versaue oder doch noch weiterhin "zuschaue"

Bei einer so grundsätzlich sich selbst disqualifizierenden Position seitens Unwindprotect - auf die Schnelle:

• der Einsatz des Begriffs Skriptkiddies ist an sich schon falsch, wenn man weiss aus welchem Kontext der normalerweise herrührt. Aber ok, man könnte "etwas offener" sein und den dann "flexibler" einsetzen...
• ich wäre grundsätzlich zunächst zurückhaltend mit "Sprachempfehlungen", da erst Anforderungen, Vorkenntnisse, Vorlieben, sonstige Bedingungen mit dem "Threadstarter" usw. abgeklärt sein sollten, aber JavaScript zu empfehlen ist schon grob fahrlässig.
• ansonsten Leute gilt einfach: "Don't feed the trolls"

Nachtrag zu oben: Wenn man nicht (wie ich oft) in vi direkt auf Shell-Ebene arbeitet, sondern sich einer IDE oder eines Editors mit Sprachunterstützung bedient, kann einem der provozierte Tab/Space-Fehler, den ich oben angeführt habe, schon bei der Eingabe nicht entgehen:

(hier BBEdit mit Jedi)

Mit meiner Konfiguration hätte ich es auch gar nicht erst so eingeben können, da ein Tab gleich auf vier Spaces expandiert wird. Das ist eine andere Methode, das Problem zu vermeiden.

Wieseo "oder"

Ähnlich wie beim bevorzugten Betriebssystem und bei der bevorzugten Automarke kochet bei Programmiersprachen gern mal die Stimmung hoch - das würde ich nicht überbewerten.
Ja und nein, und es wäre durchaus möglich gewesen, die Frage von Nebula falsch zu interpretieren - aus seinen eigenen Antworten schließe ich, daß das nicht passiert ist, also alles im grünen Bereich. Aber ja, grundsätzlich hast Du recht, und der Titel "Beste (Programmier)Sprache für Scripte" ist so absolut durchaus nicht zu beantworten.
Wäre mir jetzt auch nicht beim Stichwort "Scripting" in den Sinn gekommen, aber je nach Anwendungsfall hätte es ja auch wirklich ein guter Tip sein können. Ich sehe die Shortcomings von JavaScript hauptsächlich beim Testen und Debuggen - da habe ich noch keine mit vernünftigem Aufwand betreibbare Lösung gefunden. Ich mußte mal ein CLI-basiertes Tool von einem Kollegen debuggen, das er komplett in JavaScript implementiert hatte, und das war wirklich keine Freude. Mag sein, daß das inzwischen besser geht.

"Grob fahrlässig" ist vielleicht auch etwas zu hart. Aber wie gesagt: Den Vorschlag hätte ich auch nicht gemacht. Schon gar niemandem, der nur gelegentlich Scripte baut.
"Troll" dürfte übertrieben sein, normalerweise schreibt Unwindprotect eigentlich ganz vernünftig - da hatten und haben wir schon andere Kandidaten hier.

Es gibt immer einen Unterschied zwischen jenen die Tensorflow bauen…( in zB C++ und mit APIs für zB Python und JavaScript) und jenen die es nutzen um Modelle zu berechnen. Letzteres ist in der Tat vom Programmieranspruch Skript-Kiddie-Level. Das heißt ja nicht, dass diese Leute Kinder sind - natürlich sind das mitunter fähige Wissenschaftler… aber ihre Kernkompetenz liegt nicht zwingendermaßen bei Softwareentwicklung. Python-Fans spinnen aber immer einen logischen Zusammenhang, dass diese einfachen Skripte für so „krasse“ Dinge wie ML bedeuten müssen, dass Python eine total krasse Sprache sein muss. Das ist aber so nicht der Fall - es handelt sich um einfache Skripte die oft nur einmal ihren Zweck erfüllen müssen. Es ist halt bequemer sowas schnell mit einer Skriptsprache runterzuschreiben.

Skriptsprachen finden sich in allen größeren Projekten. Für was? Für Skripting. Wenn Du Dich so darüber aufregst, solltest Du Dich fragen, wieso Du so gezwungen versuchst eine Skriptsprache wie Python als mehr zu verkaufen als sie ist.

JavaScript war ebenso einfach nur eine Skriptsprache. Allerdings gab es dort durch den Boom von Webanwendungen eine Entwicklung, welche zunehmend Anwendungs- und Dienstentwicklung realistischer gemacht hat.

Python ist signifikant langsamer als JavaScript… ohne das es dabei dynamischer oder flexibler ist… es ist einfach nur eine schlechtere Spracharchitektur und signifikant weniger Optimierung. Die JS-Runtimes wurden in der oben genannten Zeit extrem optimiert.

JavaScript lebt als Hauptsprache in einem Ökosystem, das als „Plattform“ betrachtet werden kann: Das Web. Es wird im Frontend, Backend, on the Edge und für Skripting eingesetzt… also schlicht überall. Das auch nicht erst seit gestern sondern seit geraumer Zeit. Das Wachstum ist dabei immer noch erstaunlich stark.

Python lebt immer noch von seine Blütezeit als man Pluginsschnittstellen damit gemacht hat oder eben ein paar einfache Skripte schreiben wollte. Das sind insbesondere Bereiche wie 3D (mit Blender) oder ML. Dort ist es eben - für Skripting - etabliert.

Genau dieser Zweck wird aber immer mehr von JavaScript übernommen… weil es schlicht genauso gut oder gar besser geht. Wieso zwei Skriptsprachen lernen wenn eine reicht? Wenn man für den Browser eh JavaScript braucht… wieso dann nicht auch einfach für andere Skriptingsachen? Das ist letztlich der Grund wieso es heutzutage keine so tolle Idee mehr ist Python neu zu lernen - es sei denn man muss sich mit bestehendem Code herumschlagen.

Meister… ich programmiere seit fast 30 Jahren. Für BSD Unix, Linux, Mac und Windows… Du brauchst mir nicht erklären was „Python“ ist und das in Linux-Distros damit Skripte geschrieben werden und wurden.

Ich habe die sachliche Ebene nie verlassen. Python ist eine interpretierte Skriptsprache die vorwiegend für Automatisierung und Skripte gedacht ist und eingesetzt wird. Skripte schreiben ist „Skriptkiddie“-Arbeit und keine „Softwareentwicklung“. Das es hier und da mal Ausnahmefälle gibt ist mir bewusst - das ändert aber nichts am Prinzip der Sprache. JavaScript (ähnlich) hat da eine Entwicklung durchgemacht, die Python so nie gemacht hat. Das Ergebnis: Breitere Anwendbarkeit. Es macht heute einfach viel weniger Sinn Python zu lernen als früher.

Du redest Dir einfach nur die van Rossum’sche Fehlentscheidung schön. Diese Syntaxentscheidung macht die Sprache fragiler. Gerade bei einer Skriptingsprache ist das - ohne Mehrwert - ein absolutes NoGo.

Du lehnst Dich damit soweit raus, dass Du gar aus dem Fenster fällst. Bei anderen Sprachen gibt es in der gesamten Firma diesbezüglich keine Probleme. Zudem ist Python hier schlicht und einfach - gemäß seines Hauptzwecks eine „Pluginsprache“, mit der Kunden ebenso Skripte schreiben können. Was meinst Du wo dann die Supportmeldungen aufschlagen? Ich wiederhole es: Für KEINEN Mehrwert wurde eine Fragilität gebaut die unnötige Kosten verursacht. Das so vehement zu verteidigen grenzt schon an Stockholm-Syndrom

Sag das mal den Kunden die mit Python einfach nur Skripte schreiben möchten, wie es mit einer verdammten Skriptsprache einfach möglich sein sollte!

Klar es gibt manchmal Nerds und Freaks die tatsächlich ganze Anwendungen mit Python (oder Brainfuck) schreiben. Ist das noch Leidenschaft oder schon Leidensfähigkeit? 😅

Wieso sollte man denn Python noch zusätzlich lernen, wenn _heutzutage_ eh schon JavaScript/Typescript im Einsatz ist? Wieso Python und dann für Performance mühsam C++-Module einbinden, wenn die Performance in JavaScript meist bereits von Anfang an ausreicht oder in extremeren Fällen durch WASM plattformunabhängig ergänzt werden kann?

Es gibt genau zwei Gründe sich heute Python anzuschauen: 1) Wenn man bestehenden Python-Code anfassen muss 2) Als abschreckendes Beispiel für Sprachdesigner

Etwas Off-Topic - aber die eigenwillige Anwendung von Einrückungen wurde auch schon zur Kunstform erhoben. Man schaue sich, sofern man C kann, mal die Seite des IOCCC (The International Obfuscated C Code Contest) an - wobei die Autoren dort nicht nur Leerzeichen verwenden (oder auch nicht) um den Code so unverständlich wie möglich zu machen.

Ein hübsches Beispiel:

Das bekannteste dürfte aber dieser Code aus 1988 sein, der ein Weihnachtgedicht erzeugt:

OK, das hat dann wohl nicht funktioniert. Schönen Sonntag noch!

Unwindprotect
Wir haben längst verstanden, dass du Python nicht magst und deshalb nicht empfehlen würdest. Das musst du nicht weiter ausführen.
Andere haben dargelegt, dass sie (mich eingeschlossen) JavaScript nicht mögen und deshalb auch nicht empfehlen würden.

Den Schluß zu gehen, dass etwas grundsätzlich schlecht ist, nur weil du es nicht magst, halte ich hingegen für arrogant. Keiner hat die Weisheit mit Löffeln gegessen.
Du hast schlechte Erfahrungen mit Python gemacht?OK, das wird dann so sein und es ist nachvollziehbar, dass du schlechte Erfahrungen meidest.
Andere haben gute Erfahrungen mit Python gemacht und auch das solltest du akzeptieren und sogar respektieren. Das zu respektieren bedeutet ja nicht, es selbst zu nutzen.

Es darf noch immer jeder selbst entscheiden, welche Programmiersprache er für seine Anwendungszwecke für die günstigste Wahl hält. In Entwicklerteams muss diese Einigung im Team erfolgen - an der Stelle macht eine intensive Diskussion auch deutlich mehr Sinn, weil das Team dann ja gemeinsam damit arbeiten muss. Darum ging es aber bei dieser Frage im Forum gar nicht. Es wurde nach Empfehlungen gefragt und es wurden einige Empfehlungen genannt. Es ist für den Fragesteller nicht zielführend, wenn man die Empfehlung anderer einfach nur schlecht macht. Keiner von uns wird am Ende eine Trophäe für die beste Empfehlung bekommen.

Den Absatz mit Beispielen wo Python intensiv genutzt wird (auch von Apple), habe ich wieder gelöscht - das bringt niemanden weiter.

Was willst Du mit so einer Art der Diskussion bezwecken? Alle andere außer Dir wissen nichts? Hier stellt niemand in Abrede, dass Du Deine persönlichen Erfahrungen gemacht hast. Aber so haben das auch andere, und bei mir war das nun einmal so, dass ich sehr viel sehr schlechten JavaScript Code gesehen habe. Ich habe mag die Sprache wegen ihres Designs und meiner Erfahrung nicht, nur ist das kein Grund die Sprache selbst und die Entwickler, die sie nutzen, herabzuwürdigen. Insbesondere als Informatiker solltest Du in der Lage sein, mit jeder beliebigen Sprache ordentliche und saubere Programme zu schreiben. Was Deine Arroganz bezüglich Nichtinformatiker betrifft. Ich habe schon Informatiker erlebt, die anstelle von Funktionen zu schreiben per cut&paste Code vervielfältigt hat. Sagen diese Erfahrungen etwas über alle anderen Informatiker aus?

Ganz einfach: der Fragesteller fragt nach eine Skriptsprache als Alternative zum abgekündigtem Python bei Apple. Ich hab einfach „JavaScript“ als naheliegende Option vorgeschlagen und dabei neben der Verbreitung auch das fehlen der fragilen WS sensitiven Syntax genannt. Seitdem drischt jeder auf _diesen_ Vorschlag ein und meint Python bis zum letzten Mann verteidigen zu müssen. Es geht hier nicht um „mag ich nicht“ sondern:

1) Größere Verbreitung
2) Keine WS Probleme (für manche ist das durchaus relevant)
3) Höhere Ausführungsgeschwindigkeit
4) Größeres Ökosystem
5) Breitere Anwendbarkeit
6) Natürlicher Pfad zu statischen Typen mit TypeScript
7) wird im Frontend bei Webzeug eh schon gebraucht.

Da es ursprünglich um eine Alternative zu Python ging habe ich es auch als „versus“ behandelt. Ist mir schon klar, dass es viele Python-Fans gibt - aber es ging hier nunmal um Alternativen die mitunter in Aspekten besser sein könnten.

Danke für den reichlichen Input. Dass ich hier so eine Grundsatzdiskussion lostrete, hätte ich jetzt nicht gedacht. Ich dachte eigentlich, dass ich den Einsatzzweck meiner Scriptinganforderungen klar formuliert habe. Offensichtlich nicht.

Mein Hauptaugenmerk gilt dem Mac und die Verbesserung der Bedienung oder eben die Bereitstellung von Funktionen via Droplets oder auch einigen Skripten für die Shell. Meine Sachen sollen maximal portabel sein und am Ende keinen Aufwand erzeugen. Ja, ein Installationsprogramm ist bereits für einige eine Herausforderung, weil sie solchen Installationswegen grundsätzlich misstrauen, weil er undurchsichtig ist und gerne von Malware genutzt wird. Wer noch nie was von Python gehört hat, traut eben auch nicht blind einem Installer von Python.org.

Deshalb erachte ich alles, was nachinstalliert werden muss, für meinen Anwendungszweck nicht als Lösung und war auch nicht als Gegenstand der Diskussion gedacht. Ich wollte wissen, welche der noch von Apple mitgelieferten Sprachen langfristig eine Zukunft haben. Steige ich auf Ruby um, stehe ich vermutlich in zwei Jahren vor dem Problem wie jetzt bei Python. Oder eben nicht, weil hier Leute mehr Einblick haben und sagen können, Ruby wird langfristig safe sein, weil Apple es bpsw. selbst nutzt. Oder: Beschäftige dich mit ZSH, das ist das Einzige, was bei Apple langfristig safe sein wird. Oder nimm XYZ, was du offenbar nicht auf dem Schirm hast.

Dennoch hat mich eure Diskussion bzgl. JS/Python etwas weitergebracht. Apple wird wohl nicht so schnell von OSA abrücken und demnach dürft auch JavaScript so schnell nicht aus macOS verschwinden. Das nutze ich ja jetzt schon manchmal, etwa um AppleScript Regex beizubringen, wo es mit ASObjC nicht klappt (Mail-Regeln). Und solange JXA erhalten bleibt, wird auch AppleScript wohl nicht verschwinden, ist es doch ein wenig ausgereifter. Somit bleibe ich erstmal – auch dank Script Debugger – bei AppleScript, werde mich aber vermehrt JavaScript widmen, weil die Sprache an sich ja keine schlechte Zukunft hat. Swift-Skripte kommen doch nicht infrage, weil sie nicht auf einem frischen Mac funktionieren und man die Commandline-Tools benötigt.

Ich habe einfach nur JavaScript als Alternative vorgeschlagen und aus meiner Sicht begründet wieso. Das hat wenig mit Geschmack sondern mit konkreten Fakten zu tun. Die WS Syntax von Python ist durchaus umstritten… auch wenn das natürlich von den Fans gern „wegdiskutiert“ wird. Erfahrungen anderer (zB. Bei uns in der Firma) werden dann als falsch hingestellt und sogar an der Kompetenz der Entwickler gezweifelt. Auf andere Aspekte (Ökosystem, Performance…) wird gar nicht erst eingegangen sondern nur damit argumentiert, dass ich halt Python „nicht mag“… als ob es um eine Spargelsuppe gehen würde

Klar ist doch: Mein Vorschlag wurde nicht akzeptiert. Gründe die ich dazu angegeben habe ebenso nicht. Man hat gefälligst Python zu akzeptieren. Punkt.

Du tust gerade so als ob ich geschrieben hätte „Ich mag Python nicht, deswegen ist es schlecht“. Ich habe Negativmerkmale genannt (WS-Syntax, Performance, Redundanz wenn man eh JS brauchen sollte). Ich traue es den Lesern hier zu diese Merkmale selbst einzuordnen. Wenn einem WS Sensitive Syntax und die Probleme damit nicht stören und Ausführungsgeschwindigkeit egal ist und man sich nicht dran stört mitunter dann noch eine Sprache zu lernen… well feel free. Ich verbiete Dich niemandem etwas. Aber so zu tun als ob alles total toll an Python ist und es keine Kriterien gibt die dagegen sprechen können ist doch naiv.

Es ging hier um Alternativen zu dem nicht mehr mitgelieferten Python. Ich habe meine genannt und begründet warum ich so denke. Seitdem wird auf meine Begründung eingedroschen und nicht akzeptiert oder gar respektiert was ich geschrieben habe. Du sagst mir also: „Hey Alternativen zu Python sind dann ok wenn ihr keine Gründe anführt die gegen Python sprechen, weil das respektlos ist. Falls ihr das doch tut machen wir euch platt und erklären eure Kollegen zu Deppen“. Klingt ja echt Respektvoll…

Es sei denn er entscheidet sich gegen Python und für was anderes und begründet seine Entscheidung entsprechend… dann ist es offensichtlich doch nicht ok.

Es wurde nach einem Ersatz für Python gefragt. Ich habe meine Empfehlung genannt und begründet warum ich diese Empfehle. Alles danach war Nichtakzeptanz meiner Begründung.

Man kann doch schlicht auch akzeptieren, dass es nunmal Gründe geben kann die _gegen_ etwas stehen und bei einer Alternative dann eben besser sind.

Naja, vor allem insofern nicht, als aus Deinen Anforderungen nicht hervorging, ob Deine Skripte mit Cocoa-Apps interagieren müssen. Das ist in meinem Verständnis die alles überlagernde Grundsatzentscheidung; insofern war es verwirrend, dass Du Python und AppleScript in einem Atemzug genannt hast.

Wenn die Skripte mit Cocoa-Apps interagieren müssen, bleiben schlicht nur AppleScript und JXA; da kann es keine Diskussion geben.

Wenn nicht, grenzt es jedenfalls bei AppleScript an Masochismus, es verwenden zu wollen; schlichteste Dinge wie z.B. simple Dateioperationen sind nicht nur sprachlich irre aufwändig, sondern auch technisch: es werden ja statt einem simplen cp oder mv tatsächlich Aufrufe an den Finder gestartet, das zu erledigen. Du machst den Eindruck, als würdest Du das dennoch in Erwägung ziehen; dann ist die Disjunktion zwischen AppleScript/JXA einerseits und Unix-Schriftsprachen andererseits natürlich nicht ganz so scharf. Aber das hätte ich mir beim Lesen Deines Ausgangsbetrags nicht vorstellen können.

Was ist denn mit #!/bin/sh? Ruft das unter aktuellen macOS-Versionen immer noch bash auf oder einen Kompatibilitätsmodus in zsh? Falls Letzteres, wäre dessen Vorhandensein ja auch dauerhaft gesichert. (Genau betrachtet, muss auf einem Unix-System die Ausführbarkeit von /bin/sh sowieso gesichert sein, ganz unabhängig davon, welche interaktive Shell man nutzt.)
Auch das ging aus Deinem Ausgangsbeitrag nicht hervor. Normalerweise stellt die Installation einer Skriptsprache kein Problem dar.

Ich denke für diese Zwecke ist die Shortcuts (Kurzbefehle-App) eine Idee. Dort wird „JavaScript in Safari“ und „JavaScript für Mac-Automation“ integriert. Auch Shell-Scripte sind generell möglich, was mit ein wenig Bastellaune auch sämtliche verfügbaren CLI Interpreter möglich macht.

Von all den Dingen die in Zukunft verschwinden könnten würde ich tatsächlich „Javascript in Safari“ noch als am sichersten einstufen.

Auch Ruby ist nicht wirklich absolut Safe. Apple hat da in der Vergangenheit einfach gern Zöpfe abgeschnitten. Wenn sie das mitliefern müssen sie es Pflegen, sonst ist es eine potentielle Sicherheitslücke. Was im Prinzip fast alle nicht originär von Apple stammenden OpenSource-Projekte umfassen kann. Da sagen sie halt in Zukunft: Wer das braucht installiert es aus offizieller Quelle.

Selbst ZSH würde ich nicht als absolut Safe ansehen. Sie sind ja von bash zu ZSH als default geswitched… also ist es denke ich erstmal recht sicher… aber absolut sicher vermutlich nicht.

Das ist aktuell für den Zweck bestimmt keine schlechte Idee. Allerdings zeigt die „Kurzbefehle“-App da ja schon ein bisschen in welche Richtung es geht. Das Ding gibt es ja auch unter iOS… wo es vermutlich niemals AppleScript oder JXA geben wird.
Was denkt sich da wohl Apple in der Zukunft? Naja Apps können eigene Aktionen bereitstellen… und so kann man nahezu beliebige Automatisierungen bauen. Ein spannendes Beispiel ist unter iOS die tolle App namens „Scriptable“… diese stellt auch Aktionen für Shortcuts bereit, ist aber selbst eine kleine Entwicklungsumgebung für mit JavaScript geschriebene Skripte… mit vielfältigem Zugriff auf iOS/iPadOS… eigentlich wäre eine macOS-Version davon cool.

Nicht so ganz - seit es die Kurzbefehle App auch unter macOS gibt, tut sich so langsam eine moderne Alternative auf. Ich vermute auch, dass es so weitergehen wird.

Es gibt die App Actions (iOS+MacOS) als Erweiterung für Kurzbefehle.app. Die App Actions kennt die Aktion "Transform Text with JavaScript".
Auch die Markdown-App Taio führt JavaScript unter iOS und MacOS aus.

Die Kurzbefehle-App nehme ich gerne als Ausgangspunkt, um andere Skripte auszuführen.

Das sind dann aber eben keine Skripte.

GUI-Baukästen für die Automatisierung von Abläufen mag eine Alternative für ganz einfache Sachen, aber Skripte können schon deutlich mehr.

Nun, Du hast mich sogar mal in dieser Hinsicht korrigiert, dass dies Skripte seien.

So ein Kurzbefehle-"Skript" wie Devonsave geht über 100 Aktionen. Es kann durch Kurzbefehle AppleScript, JavaScript und Shell aufgerufen werden usw. Das Beispiel "Devonsave" erstellt aus Webseiten werbefreie HTML-Clips mit Bildern.
Du hast Kurzbefehle noch nicht auf deinem Mac, aber es ist schon sehr nützlich, da es iOS/MacOS-übergreifend funktioniert. Leider ist die Erstellung von Kurzbefehlen sehr hakelig und mir wäre die Eingabe von Text wesentlich lieber.

Jein - es sind keine Skripte in Textform, aber durchaus ein Äquivalent. Aber darum geht es nicht mal: Man kann daraus ja wiederum zB Shellskripte aufrufen (oder JavaScript nutzen) und hat dann wieder die Möglichkeiten der jeweiligen Skriptsprache. Ich sehe eher die Infrastruktur der Kurzbefehle im Betriebssystem und mit dem was Anwendungen bereitstellen können.

Du siehst nur die Kurzbefehle-GUI und nicht die Infrastruktur drum herum. Aus diesem System kannst Du ja Skripte aufrufen… oder Aktionen die von Anwendungen angeboten werden… damit sind Dinge möglich, die mit einem einfachen „Unix“ Konsolenskript schwer werden.

Ja, das ist eine unglückliche terminologische Verwirrung. Sorry dafür.

Damals wollte ich betonen, dass technisch gesehen Kurzbefehle letztlich Skripte sind, auch wenn sie über eine GUI erstellt werden.

In dem Zusammenhang hier ging es mir darum, dass Skripte leistungsfähiger sind als Kurzbefehle, insofern sie beim Erstellen nicht durch eine GUI eingeschränkt werden, die niemals so umfassend sein kann wie Programmcode.

Zum Vergleich: Website-Baukästen sind eingeschränkter in ihren Möglichkeiten, als HTML von Hand zu schreiben. Aber natürlich produzieren auch Webbaukästen am Ende HTML-Code, „sind“ in diesem Sinne also HTML. Genauso verhält es sich mit GUI-Baukästen für Skripte und handgeschriebenen Skripten.
Aber auf dem iPad. Da habe ich es mir mal kurz angesehen und zumindest vom ersten Eindruck ist das prinzipiell nichts anderes als Automator auch schon, nur halt noch weniger technisch.

Keineswegs. Aber hier geht es ja um Skripte, und GUIs zum Erstellen von Skripten sind eben prinzipbedingt weniger leistungsfähig als Text.
Dann sind aber wieder Skripte die Leistungsträger …
Nö, die sind damit sogar unmöglich. Das war doch gerade mein Punkt. Wenn Du mit einer Skriptsprache Cocoa-Apps steuern willst, brauchst Du AppleScript oder JXA. Wenn Du den Begriff Skriptsprache seeehr dehnst und auch Automator und Kurzbefehle als Skriptsprachen einsortierst, dann auch noch die beiden. Aber niemals Python, Perl, Ruby & Co.

Technischer Hintergrund der neuen Kurzbefehle-API ist übrigens, dass die Schnittstelle von Cocoa-Apps zu AppleScript/JXA nur in Objective-C programmiert werden kann, weil das von Apple derzeit gepushte Swift dazu nicht fähig ist.

Kurzbefehle könnte für Nebula noch den Vorteil haben, dass die Kurzbefehle bei Weitergabe über die iCloud m.W. notarisiert sind.

Der oben genannte Kurzbefehl für die Sicherung einer Website bekomme ich nur mit einem Kurzbefehl hin. Wenn ich das über readability-cli in der Kommandozeile mache, bekomme ich die störenden Elemente nicht aus der Website. Also die Kurzbefehle-App hat für mich schon ihre eigene Daseinsberechtigung.

Kurzbefehle nutze ich für Kleinkram, aber ich scheitere bspw. schon daran, zu prüfen, ob ein Pfad in Textform im Dateisystem existiert.

Du hast es immer noch nicht verstanden. Kurzbefehle ist nicht “nur eine GUI zum Erstellen von Skripten” es ist eine erweiterbare Infrastruktur sehr ähnlich zu dem was Apple ursprünglich mal mit der Open Scripting Architecture geschaffen hat. Entwickler können selbst App-spezifische Aktionen programmieren die dann über diese Infrastruktur wieder zur Verfügung stehen. Man kann die dann in der von Dir genannten GUI Nutzen, aber auch anders.

Seufz…
“Leistungsträger” soso…
Das ganze ist doch komplett Wechselseitig… Du kannst Skripte aus Shortcuts aufrufen und Du kannst Shortcuts mit Skripten aufrufen (man kann sie sogar einfach per URL ausführen). Wenn Du Dir Nebulas Post richtig durchgelesen hast, geht hier um Automatisierung und Skripting von Apps. Ja insbesondere bislang auch mittels OSA. Aber da es auch um das Thema “Zukunftsträchtigkeit” ging, habe ich die Kurzbefehle-API aufgenommen. Warum? Weil ich Zweifel daran hege ob OSA wirklich zukunftssicher ist. In Kürze? Vermutlich eher nicht, aber es funktioniert nicht unter iOS oder iPadOS und nichts sieht so aus als ob sich das jemals ändern wird. Stattdessen wurde mittlerweile die Shortcuts API zum Mac portiert und der Automator so langsam aufs Abstellgleis geführt. Wer da nicht total betriebsblind ist sollte Zeichen sehen.

Ich wundere mich wirklich sehr. Du bist außerordentlich schnell dabei festzustellen was genau unmöglich ist und was nicht, siehst dabei aber den Wald vor lauter Bäumen nicht. Ich habe den Eindruck es fehlt einfach ein Blick auf das größere Ganze. AppleScript und JXA ist mehr oder minder das gleiche - das gehört einfach zur OSA. Du kannst natürlich über die OSA mittels Skriptsprachen Mac-Programme steuern. Das geht auch mit Python, Ruby oder ZSH. Die Shortcuts-API bietet wiederum ebenso entsprechende Möglichkeiten. Ich hab aber keine Lust mir den Mund fusslig zu reden indem ich das nochmal alles erkläre.

Sorry, aber das ist Quatsch. Technischer Hintergrund ist, dass es außerhalb des Mac (iOS, iPadOS, WatchOS…) keine OSA gibt und kein Apple Events IPC. Diese Schnittstelle ist uralt (System 7). Das wird schlicht und einfach nicht mehr in die neueren Systeme weitergeschleppt werden.

Na, dann seien wir mal froh, dass wenigstens Du es verstanden hast. 🙄

Ich verstehe zudem nicht, worüber wir hier überhaupt streiten. Ich dachte die ganze Zeit, wir würden in der Diskussion hier in etwa dieselbe Position einnehmen. Offenbar nicht.

All die Dinge, über die Du mich belehren zu müssen meinst, sind mir wohlbekannt. Ich ordne sie nur anders ein.

Der Ausgangspunkt unseres Disputs war, dass ich sagte, man brauche AppleScript oder JXA, um mit Cocoa-Apps zu interagieren, weil ich in einem Thread über Skriptsprachen GUI-Ansätze wie Kurzbefehle oder auch Automator ungeachtet aller dahinterstehen Infrastruktur nicht für einschlägig halte. Dir scheint aus irgendeinem Grund wahnsinnig wichtig zu sein, dass die taxonomisch auch dazugehören. Für mich hängt da nichts dran und ich habe Dir längst zugestanden, dass, falls man Kurzbefehle mit berücksichtigt, man selbstverständlich auch mit denen mit Cocoa-Apps interagieren kann (Nebula allerdings hat schon gesagt, dass die aus seiner Sicht nur für kleine Sachen zu gebrauchen und für ihn daher uninteressant sind). Was also soll diese ganze Aufgeregtheit von Deiner Seite?
Auch mit einer Skriptsprache? Mit welcher? Das ist das Thema hier.
Das weiß ich auch. Trotzdem bleiben Skripte Skripte und Kurzbefehle Kurzbefehle. Das man bei einer Kombination beider Systeme die Möglichkeiten beider Systeme erhält, ist ja nun ultra-trivial. Auch aus AppleScript kann man Shellskripte aufrufen und umgekehrt. Aber deshalb kann man doch nicht sagen, dass AppleScript und Shellskripte dasselbe können.
Dann habe ich ihn mir – gerade eben nochmals – wohl falsch durchgelesen, denn Skripten von Apps steht mit meinen Augen gelesen eben gerade nicht da. Genau das hatte ich wegen seiner Missverständlichkeit oben schon bemängelt.
Das wäre auch völlig unnötig, weil mir das alles wohlbekannt ist. Aus irgendeinem Grund willst Du aber partout ein großes Fass aufmachen.
Das ist die Aussage des zuständigen Engineering-Teams, mit dem ich in Kontakt stehe. Was ist Deine Quelle für Deine feinziselierte Aussage?
Ja, und warum wohl? Nicht wegen des Alters …

Am besten für "die kleine Programmierung zwischendurch" ist meiner Meinung nach immer noch CodeRunner. Damit kannst du mal eben ein script in irgend einer Sprache schreiben und ausführen. Dabei werden nicht nur Sprachen wie C oder Objective-C Unterstützt, auch Python, Ruby, Lua, JavaScript, PHP oder Shell-Scripte.

Die aktuelle Version enthält für verschiedene Sprachen auch einen Debugger (Python, C und Javascript) und der sorgt zb dafür, dass CodeRunner meiner Meinung nach das einfachste Programm ist, mit dem man Python Skripte auf dem Mac entwickeln kann.

Das Programm kostet 20€, was aber bei dem Funktionsumfang ein echtes Schnäppchen ist.

Zu finden unter (https://coderunnerapp.com)

Ich habe eher den Eindruck, dass Du Dich darüber aufregst um meinen ursprünglichen Vorschlag sich auch Kurzbefehle anzuschauen wegzudiskutieren. Dass Du es nun plötzlich doch genauso siehst kam nicht wirklich rüber.
Auch mit einer Skriptsprache? Mit welcher? Das ist das Thema hier.
[/quote]

Na klar!

Ich fand es ja auch ultra-trivial - deswegen bin ich ja auch verwundert warum Du da so dagegen kämpfst. Offensichtlich geht es Dir um eine eher akademische Frage des "Was kann AppleScript bzw. Shellskripte für sich alleine". Da diese beiden Technologien aber eben nicht alleine dastehen sondern in einer Infrastruktur und gerade weil sie entsprechende Brückenfeatures haben geht eben mehr. Das macht für mich überhaupt den Hauptsinn solcher Tools aus. Was bringt es mir zu wissen, dass ich mit AppleScript ohne Integration mit dem Rest nur ein Subset machen kann? Ist das nicht auch eine triviale Aussage? Ist das nicht total praxisfern? Am Ende soll doch was getan werden. Das ist doch kein Wettbewerb nach der Art "Schau mal was ich nur mit AppleScript alleine gemacht habe".

Ich hab lediglich etwas ergänzt - da Dir ja schon alles bekannt war und Du mir ja (laut oben) auch halbwegs zustimmen kannst (bis auf so manches Wording vielleicht) - verstehe ich selbst ja auch nicht wieso Du Dich über die Einordnung der Kurzbefehl-Möglichkeiten so aufregst. Du hättest es doch schlicht und einfach als das annehmen können was es war: Eine Ergänzung um einen weiteren Baustein in diesem Kontext, denn man bei diesen Themen in Zukunft auch im Auge behalten sollte.

Same... präzisierend: Natürlich ist der Bezug auf Swift _ein_ Aspekt. Aber das ist eben nur einer. Die Tatsache, dass es unter iOS/iPadOS usw. ebenso nicht verwendbar ist und sich das wohl auch nie ändern wird ist allerdings der gewichtigere Aspekt.

Im groben und ganzen sind wir doch offensichtlich gar nicht soooo weit auseinander. Vielleicht einfach das Kriegsbeil begraben und konstruktiv diskutieren?

Ja, allein darum ging es mir an dieser Stelle. Begrifflich saubere Trennung zweier verschiedener Dinge ist die Voraussetzung dafür, dass man sich in einem zweiten Schritt überlegen kann, wie sie zusammenpassen/kombiniert werden können.

„akademische Frage“ ist für mich kein Schimpfwort, eher das Gegenteil.
Nö, das ist begriffliche Präzision. 🤓
Der ist aber eine Folge des ersteren.
Wir sind überhaupt nicht auseinander.
Sehr gerne.

Das Problem ist, dass Du in Deinem Engagement weit übers Ziel hinausschießt. Bleib bei den Fakten, und dann wirst Du auch weniger Widerspruch ernten. Und nein, das heißt nicht, dass JavaScript eine schlechte Empfehlung ist.
1) Laut TIOBE (mit den üblichen Problemen) ist Python in der Statistik deutlich vor JavaScript
2) Dafür gibt es Tools und Regeln
3) Wir reden über eine Skriptsprache, ist das ein Problem kann die Empfehlung für macOS eigentlich nur Swift lauten.
4) Wirklich oder wieder nur persönlicher Blickwinkel?
5) Webbrowser unterstützen Python nicht, dafür kann ich keine Stored Procedures für PostgreSQL in JavaScript schreiben.
6) Wenn das ein Thema ist dann doch eher Rust oder Ada
7) Ist nicht mein Thema und das des OPs wohl auch nicht.
Ich bin kein Python-Fan, ich nutze es sehr selten. Du bewertest JavaScript vs. Python sehr subjektiv, und das bringt eine unnötige Schärfe rein.

Ich wüsste nicht wo ich irgendwo nicht bei den Fakten geblieben wäre. Der Widerspruch bezieht sich ja vor allem auf solche Dinge wie z.B. selbst kein Problem in WS sensitive Syntax zu sehen. Das ist natürlich für denjenigen schön der kein Problem hat, aber nimmt dem anderen, der mit _tatsächlichen_ Problemen Konfrontiert ist (z.B. bei Kunden die oft selbst nicht Profis sind) nicht den Schmerz. Insofern ist es schlicht und einfach ein geäußerter Fakt (reale Begebenheit) den man nicht durch eine Meinung wegdiskutieren kann. Oder: Nur weil Du kein Problem damit hast, heißt das nicht, das niemand ein Problem damit haben darf. Ich sage ja auch nicht, dass jeder ein Problem damit haben muss, sondern, dass manche Leute damit eben ein Problem haben (legitimerweise!). Natürlich darf man selbst aus eigener Erfahrung kein Problem damit haben - aber es ist schlicht zu akzeptieren, wenn jemand sagt: Ich empfehle JS _auch_ weil es u.a. ein Problem nicht hat was bei uns (und anderen) mitunter eine Rolle spielt. Wenn dann als Argument kommt "Ihr seid halt doofe Entwickler" dann frage ich mich was das mit "bei den Fakten bleiben" zu tun hat.

Jepp - heißt der Begriff "Python" ist in der Vergangenheit in Suchstatistiken bei Google häufiger vorgekommen als "Javascript". Was jedoch auch eine nicht unumstrittene Metrik darstellt.

Ein anderes Beispiel ist Github mit der Octoverse-Statistik (Javascript immer noch führend)
Oder Stackoverflow (https://survey.stackoverflow.co/2022/#technology) - auch dort führt JavaScript deutlich. Wenn man Typescript noch dazu rechnet sogar noch mehr.

Natürlich - und diese Tools und Regeln gibt es warum? Weil es Probleme gab. Man hätte diese Probleme aber auch mit einem anderen Syntax-Design vermeiden können. Das ist in meinen Augen ein absolut legitimer Kritikpunkt auf den Pythonfans - finde ich - viel zu empfindlich reagieren.

Nein - weil Swift wieder eine ganze Reihe anderer Aspekte miteinbringt, die vielleicht unerwünscht sind, denn: Ja es geht um Skriptsprachen und da gibt es neben Python tatsächlich noch andere. JavaScript ist heutzutage einfach ein durchaus valider Kandidat der nebenbei im Vergleich auch signifikant bessere Performance bietet. Auch das ist schlicht ein Fakt und ebenso schlicht ein legitimes Kriterium das man doch nun wirklich nennen dürfen sollte. Auch hier: Pythonfans reagieren angepisst wenn man das erwähnt.
(War "Ökosystem")
Natürlich "Wirklich". JavaScript hat schon mal eine signifikant höhere Installationsbasis der notwendigen Runtime. Mit der Integration im Webbrowser ist es eine Sprache die in einer der wohl mit am häufigsten eingesetzten Apps verwendet wird (Browser). Die Zahl der Websites, Webapps, Serveranwendungen, Desktopanwendungen... die JavaScript verwenden ist ebenso gigantisch. Das package-Repository npm bietet 1,3 Millionen Pakete an (PyPI: 350K). All das sind Aspekte die überhaupt nichts mit "meinem persönlichen Blickwinkel" zu tun haben.
Doch man kann tatsächlich stored procedures für PostgreSQL in Javascript schreiben. Davon abgesehen: JavaScript ist mit u.a. Node.js auch am Server eine gängige Programmiersprache und man kann aus Node.js auch sehr gut auf diverse Datenbanken zugreifen. Es gibt keinen Grund wieso man da plötzlich _unbedingt_ Python braucht. Im Webbrowser kommt man aber um JavaScript kaum herum. Deswegen _kann_ es für manche Nutzer ein entscheidendes Kriterium sein, dass sie dann mehr Dinge einfach mit einer Skriptsprache machen können als dafür dann mehrere zu lernen. Auch das ist - finde ich - ein legitimes faktisches Kriterium und nicht nur eine subjektive Meinung.

Rust ist eine tolle Sprache - war für mich seit Common Lisp vor knapp 25 Jahren die erste Entdeckung die mich wirklich fasziniert hat. Ada fand ich dagegen eher langweilig - hat aber bestimmt auch seine Fans.
Natürlich ist Typescript bei weitem nicht die einzige Wahl, wenn man sich mit stark typisierten Sprachen beschäftigen möchte (Auch Haskell und OCaml wären da nett). Allerdings hat das Typsystem von Typescript einige Besonderheiten die es mittlerweile sehr empfehlenswert machen: Die Art wie strukturiertes Typing, generische Typen, unions, intersections usw. usf. genutzt wurden um daraus ein Typsystem für eine so dynamische _Skript_-Sprache wie JavaScript zu erschaffen ist tatsächlich eine Leistung der Anerkennung gebührt. Es ist schon erstaunlich was man in diesem Typsystem mittlerweile alles ausdrücken kann. Und das schöne: Man bewegt sich fließend zwischen der Dynamik von JavaScript und sehr streng statisch getypem Code. Ich habe selten so eine flexible Kombination gesehen. Heißt: Wer vor allem Skripting machen möchte, aber vielleicht einen Mehrwert in statischer Typisierung sieht die _optional_ angewandt werden kann und die Dynamik der Skriptsprache wenig behindert... der hat hier von JavaScript nach Typescript einen guten Trampelpfad.

Mit mypy gibts ja sowas wie einen Mitbewerber in der Python-Welt, aber da ist Typescript wirklich signifikant weiter.

Ah ja... wenn es um Dich geht dann zieht das Argument wohl ^^

Du liest eine Subjektivität hinein, die nicht vorhanden ist. Ich habe konkrete Argumente gebracht. Glaubst Du wirklich, dass Dein Post, dass gleich mal damit beginnt, dass ich "in meinem Engagement über das Ziel hinausschieße" und damit endet, dass ich Python unnötig scharf und subjektiv bewerte hier als Vorbild zu nennen ist? Statt dem Thema kritisierst Du halt mich persönlich, mindestens so subjektiv wie Du es mir vorwirfst.... weil Dir vermutlich meine Art oder was ich schreibe einfach nicht passt.

Irgend wie willst Du nicht sehen. Ok, für mich EOT

Ich verwehre mich nicht grundsätzlich der Kurzbefehle. Der Editor ist halt extrem buggy, mit dem Mausgeschubse recht zeitaufwendig und man sieht immer nur wenige Zeilen Code, sofern man nicht drei Hochkant-Monitor besitzt und die übereinander stellt. 😉

Ich glaube auch, dass Apple in Shortcuts die Zukunft sieht, aber ohne Code-Editor erscheint mir das für meine Zwecke nicht praktikabel. Dazu sind meine Skripte dann doch zu groß. Es gab mit ScPL ja mal einen Ansatz, aber irgendwie ist das Projekt eingeschlafen. Jellycuts fokussiert sich leider nur auf iOS.

Bzgl. der Python-Thematik möchte ich noch Editorconfig ins Spiel bringen, das von vielen Editoren unterstützt wird. Damit vermeidet man, dass der eine Tabs nutzt und der andere Spaces.

Da Du auf meine Webseite verlinkst – wo bitte liest Du dort, dass JXA keine regulären Ausdrücke hätte? Das gilt für AppleScript, dem im Übrigen massenhaft Funktionen/Methoden fehlen, die man gerne hätte (Strings, Arrays, Introspection).

"Nicht gut" ist kein Urteil, dass ich in diesem Zusammenhang abgegeben hätte. JXA hat seine Macken, aber zumindest kann man damit einigermaßen knappen und brauchbaren Code schreiben (wie auch mit Python und allen möglichen anderen Sprachen, aber eben nicht mit AppleScript).

Dass JXA proprietäre Teile enthält, ist eine Binse – es kommt von Apple, natürlich ist es auf Automation in MacOS zugeschnitten. Aber, und das scheint mir das Missverständnis zu sein: Es setzt komplett auf JavaScript, besser gesagt auf ECMAScript, und zwar in einer sehr aktuellen Variante (vermutlich dieselbe, die auch Safari benutzt). Daran ist nichts proprietär, sondern das ist die Sprache, die alle Browser und node etc. benutzen. Und die braucht auch keineswegs, wie jemand anders hier meinte, einen Browser als Laufzeitumgebung (schon seit mindestens 10 Jahren nicht mehr, aber was soll's).

Das "Proprietäre" an JXA beschränkt sich auf die globalen Objekte und deren Methoden. Die sind nötig, wenn man mit Apps reden möchte. Ist halt so, und in dem Sinne ist auch das ECMAScript in jedem Browser "proprietär", da es window und document als globale Objekte bereitstellt, die nicht zum Sprachstandard gehören.

Da Du dich als Autor hier zu Wort meldest , möchte ich die Gelegenheit nutzen, mich ausdrücklich und herzlich für Deine tolle Website zu bedanken, die mir enorm geholfen hat, als ich mich seinerzeit in JXA reingefuchst habe. Wie ich oben schon schrieb:Dass Peter Eckel ganz seltsame Annahmen Deiner Website entnehmen zu können meint, habe ich ihm oben ja auch schon geschrieben, aber nie eine Reaktion erhalten. Vielleicht hast Du mehr Glück.
Das kann ich nur dick und fett unterstreichen. 👍

/usr/bin/ruby

Exakt. Eine Konsequenz die sich daraus ergibt ist, dass man in JXA nicht ohne weiteres XHR-Requests machen kann, wie man das als Webentwickler eventuell gewohnt ist. Da es aber eine ObjC Bridge gibt müsste es aber möglich sein eine eigene Implementierung von „fetch“ zu bauen (so wie das auch für Node.js passiert ist). Weiterhin müsste man auch das Node.js Ökosystem zusammen mit einem Bundler verwenden können… damit habe ich aber auch noch nicht experimentiert

Nur zum Trollen hier?

Ehrlich gesagt verstehe ich die Negativbewertungen des Beitrags und den Kommentar nicht. Ich weiß natürlich nicht ob der Poster in der Vergangenheit des öfteren negativ aufgefallen sein mag, aber Ruby vorzuschlagen ist doch eigentlich legitim oder? Oder ist das jetzt wieder nicht legitim weil das Ruby-Lager und das Python-Lager sich seit gefühlten Ewigkeiten bekriegen?

Nochmal ein paar kleine Rückmeldungen an jene die es interessiert:

Es gibt seit einiger Zeit ein Projekt um Shortcuts direkt mit Code zu generieren:

https://shortcuts.fun

z.B.:

Wie praktikabel das mitunter für jemanden ist muss man selbst entscheiden - es ist aber eine coole Idee.

Hier sind noch für JXA ein paar Packages um es z.B. zusammen mit TypeScript zu verwenden:

https://github.com/JXA-userland/JXA

Damit hat man dann u.a. auch typbasiertes Autocomplete im Editor (z.B. bei VSCode).


Das Projekt bietet auch packages um JXA aus Node.js heraus aufzurufen.

Ich gehört keinem Lager an.
Aber substanzlos hier einfach was hinknallen ohne Kommentar hilft niemanden, zumal Apple Ruby für spätere macOS Versionen abgekündigt hat. Dann bringt dir ein `/usr/bin/ruby` nix außer einer Fehlermeldung.

Der Beitrag war so leider nicht hilfreich. Für Ruby habe ich mich interessiert und um Einschätzung gebeten. Immerhin ist Ruby weiterhin vorinstalliert, obwohl bereits vor 4 Jahren abgekündigt (bleibt es doch?). Mitgenommen habe ich hier, dass ich vermutlich mehr davon habe, wenn ich Python oder JavaScript lerne.

Niedrigschwellige Angebote für mich als Einsteiger sind vorinstallierte Sprachen, homebrew, Kurzbefehle, ein AppleScript zum Anpassen.
Skripte erstellen traue ich mir schon zu.

Generell abschreckend ist für mich dagegen die spätere Diskussion. Insbesondere wenn ich noch zusätzlich ein IDE, XCode mit 20 GB, Libraries, Frameworks etc. brauche (oder auch nicht) und erst nachträglich feststellen kann, dass ich mich in den falschen Zug gesetzt habe, weil mir keiner die Fahrtrichtung sagen konnte oder wollte. Das stellt eine Einstiegshürde dar, wenn ich mich nur mit Thema beschäftigen möchte, um mal hin und wieder etwas zu automatisieren.

Sorry, das hat jetzt etwas gedauert, da ich mich aus dem, was zwischenzeitlich aus dieser Diskussion geworden war, verabschiedet habe.

Du hast Recht - Die RegEx-Information stammte nicht von Dir, sondern aus irgendeiner anderen Quelle, die ich zwischenzeitlich nicht mehr finde und die vermutlich entweder veraltet oder sowieso inkorrekt war - vermutlich irgendein Thread auf Stackoverflow. Bitte entschuldige die fehlerhafte Attributierung, von Dir stammt das so nicht.
Das ist ein Mißverständnis Deinerseits: Das Originalzitat ist "Nicht gut und vor allem nicht korrekt dokumentiert". Also, wenn man die Klammer auflöst, "Nicht gut dokumentiert und vor allem nicht vollständig dokumentiert". Ganz so primitive Urteile wie "Die Sprache ich nicht gut" gebe ich dann doch nicht von mir.
Das macht in der Tat den Eindruck. Ich halte die Sprache nach wie vor für eine Nischenlösung (im Gegensatz zu JavaScript als solches), und da zunächst der Eindruck entstand, der OP sei an einer "general purpose"-Scriptsprache interessiert (was er ja später klarstellte) hätte ich sie nicht weiter in Betracht gezogen, nicht zuletzt aufgrund der halbherzigen Unterstützung seitens Apple, die Du ja auch kritisierst.
Unter dem Gesichtspunkt "general purpose" ist das ja nun schon zu proprietär. Wenn man natürlich Aktionen mit macOS-Software automatisieren will hast Du recht, dann kommt man um den proprietären Teil nicht herum.
Das hatte ich schon verstanden.

Bei der (nachträglich leider erfolglosen) Recherche nach der Quelle für meine Fehlinformation bin ich noch auf einen Artikel gestoßen, der für Nebula interessant sein könnte:

Mit Ruby hat das überhaupt nichts zu tun.

Es ist schon nicht sehr freundlich, einfach kommentarlos einen Dateipfad hinzurotzen. Aber OK, in Anbetracht des Threadthemas ließe sich das als Ich würde Ruby empfehlen interpretieren.

Nur wurde Ruby in diesem Thread zuvor in 10 Beiträgen teils ausgiebig erörtert. Man muss meinetwegen nicht unbedingt einen Thread ganz durchlesen, bevor man einen Beitrag schreibt (obwohl man sollte), aber wenn der eigene Beitrag aus einem einzigen Begriff besteht, dann kann man ja wohl mal die Suchfunktion des Browsers nutzen und gucken, ob darüber bereits diskutiert wurde.

Das geht tatsächlich im Prinzip mit ObjC-JXA. Allerdings nicht ganz so, wie man das in ObjC machen würde, weil JXA Leiber Blöcke kennt.

Allerdings gibt es ja nicht nur XHR, sondern auch anderes nicht, was Webentwickler kennen. Es geht halt um ECMAScript iA, nicht um dessen Umsetzung in Browsern.

Und mit nodeautomation (auf GitHub) gibt es auch eine Integration von OSA in node, die möglicherweise besser funktioniert als JXA.

[quote Peter Eckel]Ich halte die Sprache nach wie vor für eine Nischenlösung (im Gegensatz zu JavaScript als solches),
[/quote]
Das ist mE ein Missverständnis: JXA ist keine "Sprache", sondern eben ECMAScript "als solches". Ergänzt um globale Objekte, die man für das Scripten von Apps und das Anbinden von Frameworks braucht. Die Programmiersprache entspricht exakt dem, was man in anderen Implementierungen vom ECMAScript findet, inklusive regular expressions etc.

Wer weder App-Scripting noch Frameworks braucht, kann mit node und Javascript auf macOS arbeiten – das ist mE sehr "als solches".

Das habe ich unterdessen auch gefunden. Tatsächlich gibt es diverse Projekte die Node.js mit OSA verbinden. Inklusive Support für Typen mit Typescript.

Sorry für die Kürze. Aber es war eine Antwort auf deine Frage: "Habe ich noch eine Sprache übersehen, die mitgeliefert wird und nicht angekündigt ist?"

Wenn Du Objektorientiert programmieren lernen willst ist Ruby m.E. fantastisch. Für meinen Geschmack ist es auch sowohl einfacher als auch logischer als Python aufgebaut. Und es macht SPASS. Aber das ist wirklich auch Geschmacksache. Du musst das richtige für dich selber finden. Javascript ist sicher auch nicht verkehrt. Aber mit weniger Freude an der gleichzeitigen Einfachheit wie Genialität von ruby.

Ich zitiere mal Apple:

Damit wäre Ruby raus.

Ich habe mir auch einmal ein paar Sprachen als Alternative zu C++ angeschaut:
- Rust (ist mir zu restriktiv, Stichwort borrow, borrow checker - wird sehr gut von VS Code unterstützt, gute Doku)
- Zig (eigentlich absolut cool und extrem schnell, hat aber ein Manko, die Dokumentation, die sich meist auf einfache Beispiele beschränkt (habe es z.B. nicht geschafft eine Arraylist per alloc zu erzeugen) - ebenfalls gute VS Code Unterstützung) bin sehr gespannt, wie die Entwicklung weitergeht
- V (sehr klein und minimal, Nachteil: Keine Variablen außerhalb von Funktionen erlaubt - keine Ahnung, wie man so programmieren soll)
- Go (mein Favorit, einfach zu erlernen, schnell, typsicher aber trotzdem nicht zu restriktiv - sehr gute VS Code Unterstützung und sehr gute Doku)

Wenn du das so siehst wären damit praktisch alle Skriptsprachen raus.
Aber eigentlich heißt das nur, dass du den Interpreter für deine gewählte Skriptsprache selber installieren musst. Das ist wirklich kein Aufwand. Und hättest du so oder so machen sollen um nicht mit einer veralteten Version zu arbeiten.

Stimmt, aber genau das war ja Nebulas Ausgangsfrage.
Der Punkt war aber, dass die Skripte an andere verteilt werden und dort einfach laufen sollen.