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?

Falls Du etwas installieren (lassen) möchtest (also nicht maOS out-of-the-box) dann ist python3 überhaupt kein Problem (außer den Problemen, die man mit python nunmal hat ). python.org z.B. Und drumherum, gibt es alles was man braucht auch für den mac (conda, VS Code, PyCharm, ...).

du hast noch Perl auf deinem Rechner.
Im Terminal mal perl -v eingeben
Gruß

Ich frage mich derzeit auch, mit welcher Script-Sprache ich überhaupt anfangen soll.

Neben den genannten AppleScript, Java for Automation und Python scheint mir noch Ruby und Lua interessant.
Wenn Bash-Skripte an Ihre Grenzen stoßen, ist wohl Ruby oft der nächste Schritt. Ruby ist auf dem Mac vorinstalliert (2.6.1 in Ventura).
Lua wird von Programmen wie Hammerspoon genutzt.
Die Seite "Learn X in Y minutes" finde ich interessant, um mal schnell einen Eindruck zu bekommen.
Mein Bauchgefühl sagt mir:
AppleScript - weil alle Vorlagen/Bausteine in AppleScript sind
Ruby - vielseitig
Lua - einfach

Bevor ich die Frage nach einer Scriptsprache stellen würde, sollte man sich so erstmal überlegen (und schreiben) welche Probleme man damit lösen will. Wer zB überwiegend vorhandene Programme „verbinden“ / bzw. Steuern will, der kommt um AppleScript nicht drumrum. Ggf. kann es sein, das einem der Automator recht, nur bei komplexeren Aufgaben hat der mir nie getaugt.
Wer sich überwiegend im Terminal tummelt und dort mit einer der vielen Scriptsprachen seine Probleme lösen kann, der sollte sich dann dort die passendste für sein Problem suchen. Wenn die erst installiert werden muß, dann ist das eben so.
Keinesfalls (außer man will mal was anderes probieren) würde ich der aktuellen (Script)Sau hinterher laufen die soeben durchs Dorf getrieben wird.
Damit kann man, ohne die zu lösenden Aufgaben zu kennen, keine allgemeine Empfehlung geben welche Scriptsprache man denn verwenden/lernen sollte.

Klar ist der Einsatzzweck wichtig. Ich nutze aktuell AppleScript, damit es eine GUI gibt und darin oft Shell-Kommandos und Pythonskripte, weil sich damit besser Daten verarbeiten lassen (via Regex). Einiges habe ich mittlerweile auf AppleScript only (mit Shellkram für Dateihandling) umgestellt, damit Kollegen es ohne große Erklärung nutzen können. Viele meiner Skripte sind in Droplets verpackt: Dateien draufschmeißen, Parameter abfragen, Ergebnis in neue Datei schreiben oder Zwischenablage packen. Automator nutze ich für Dienste, die etwa Text verarbeiten und direkt ersetzen sollen. Der Kern läuft mangels Programmlogik aber als Skript ab. Bei Shortcuts ist das bei mir ähnlich. Basiert der Kern auf Python, habe ich wieder ein Problem. Längst ist nicht alles an Python3 angepasst, weshalb ich auch noch Python2 installiert habe.

Diesen Wildwuchs will ich halt langfristig und zukunftssicher entschlacken, so dass ich nur noch einen Wrapper wie AppleScript habe und die Logik dann aber in einer möglichst universellen Sprache abläuft.

Ruby ist interessant, aber wurde das nicht auch längst abgekündigt? Und Perl ebenso? So verstehe ich hier Apples Text jedenfalls.

Offensichtlich wird langfristig nur ZSH übrig bleiben, oder? Oder ich integriere die Runtimes direkt in meine Bundles, damit sie portabel bleiben. Aber vielleicht steckt ja noch mehr in macOS. Habe kürzlich entdeckt, dass auch die DASH Shell enthalten ist.

Sehe grade, dass man auch in Swift Skripte schreiben kann. Vielleicht ein guter Einstieg in die Sprache. Wenn ich mir die Beispiele anschaue, schreckt mich aber gleich wieder ab, wie viele Zeilen Code für simpelste Sachen nötig sind. Unklar ist mir auch, ab welcher macOS-Version das überhaupt geht.

Was habe ich schon über simpelste Dinge geschimpft die mit Python in wenigen Minuten erledigt waren.

Noch mehr Senf von mir, frei nach dem Motto "10 Antworten, 11 Meinungen":

Meine (begrenzte) Erfahrung sagt mir:
- Applescript und/oder Shell nur, um Sachen evtl. anzuschupsen, dann möglichst früh auf eine "richtige" Programmiersprache umsteigen.

- Swift scheint mir die aktuell gepushte Apple-"Strategie" zu sein.
Sobald man über die Anfangshürden weg ist (Stichwort: zu viele Zeilen Code), können die Programme richtig schick werden.
Wie lange diese Apple-"Strategie-der-Woche" anhält, kann aber keiner sagen.

-----
Nicht lachen:
Als Umsteiger vom anderen Ufer bin ich mit C# in Visual Studio auf dem Mac recht zufrieden. Analog kann ich mir vorstellen, dass Mac-Natives mit Swift glücklich werden.

Wenn ich derzeit vor der Wahl stände, mit einer Scriptsprache neu anzufangen, dann wäre das ganz klar Python 3.

Zum einen ist Python derzeit die wohl beliebteste und meistverwendete Scriptsprache und auch in der aktuellen TIOBE-Liste , in der nicht nur Scriptsprachen gelistet sind, auf Platz 1. Und das hat gute Gründe: Python ist ausgesprochen elegant, hat ein unglaublich großes Ökosystem von verfügbaren Modulen und Entwicklungsumgebungen, wird von sehr vielen Tools als Schnittstellensprache unterstützt und ist extrem gut dokumentiert. Und dann kommt noch dazu, daß Python-Programme aufgrund der erzwungenen Einrückung mehr oder weniger zwangsläufig lesbar sind (und ja, man kann auch in Python grauenhaft programmieren).

Vor 15 Jahren hätte ich noch Perl empfohlen. Leider ist Perl nicht gut gealtert, der mißlungene Versionssprung zu Perl 6 hat extrem lange gedauert und wurde inzwischen weitestgehend verworfen. Zudem ist Perl aufgrund seiner Sprachkonzepte heute einfach nicht mehr wirklich zeitgemäß - was schade ist, Perl 6 hatte gute Ansätze und hätte eine Chance verdien gehabt, aber die Community ist einfach nicht in die Gänge gekommen und jetzt ist es zu spät um noch irgendetwas zu retten.

Ruby, Lua, JavaScript etc. haben alle ihre Daseinsberechtigung, aber als Universalsprache würde ich keine davon einsetzen wollen. Für die Systemprogrammierung ist Rust sehr interessant, erfüllt aber Dein Kriterium (Scriptsprache) nicht. Java und alles, was damit zusammenhängt, ist zurecht auf dem absteigenden Ast ... einen der letzten Sargnägel hat gerade Oracle selbst mit der Java-Lizensierung eingeschlagen. Fort mit Schaden, ich hab's nie gemocht. Go ist mir aus zweierlei Gründen unsympathisch: Erstens wird die Sprache von Google bereitgestellt, die gerade wieder damit in die Presse geraten sind, daß sie über Tracking in der Entwicklungsumgebung nachdenken (Google halt), zweitens nervt das zwingend statische Einbinden aller Libraries erheblich (Größe der Executables/Sicherheitsupdates etc.).

Warum sollte Java am absteigenden Ast sein? Im Backend ist es doch quasi Standard für größere Projekte.
Klar, am Desktop hat es hingegeben kaum Relevanz.

Auch ich würde als Skriptsprache zuerst Python empfehlen. Sollte Apple das nicht mehr mitliefern - egal, lässt sich ja einfach installieren.
Erst wenn es an GUI geht, wird es aufwändiger, aber oft braucht man das nicht, wenn man Skripte schreibt.

Ein Vorteil, den andere Sprachen auch haben (aber nicht alle) man kann Python-Skript fast 1:1 auch auf anderen Systemen laufen lassen und es gibt mittlerweile schon einige „embedded“ Systeme, die stark auf Python setzen. Auf der anderen Seite kann man mit Python alles vom schnellen Skript bis zur Objekt-Orientierten Anwendung umsetzen, teils sehr elegant.

Danke, Python rückt nun nach oben auf der Liste Mir kommt es tatsächlich nur auf Automation für den Eigenbedarf an. Da möchte ich in einer interpretierten Sprache schnell etwas experimentieren und anpassen können.

Wie wäre es mit Purebasic (wehwehweh.purebasic.com)?
Ist zwar keine Scriptsprache (bringt echten Compiler mit), aber BASIC ist sehr einfach zu lernen.
Die Freewareversion hat eine Einschränkung was die Anzahl an Codezeilen angeht, zum Experimentieren reicht das allemal. Und, es gibt auch eine Apple Silicon Version.

KongoOtto

Oh ja... BASIC - das waren noch Zeiten - aber das war alles andere als elegant damals vor 40 Jahren.

Irgendwann bestanden meine BASIC Programme nur noch aus PEEK, POKE und langen DATA Zeilen mit den Maschienensprache-Befehlen (also den CPU-Opcodes)

@ssb
Habe damals (lang lang ist's her) Basic auf dem Commodore Plus4 "gelernt".
Der Plus4 war als Nachfolger des C64 gedacht, konnte sich aber nie so richtig durchsetzen.
Bin dann ziemlich schnell zu 6502 Assembler gewechselt (der Plus4 hatte einen eingebauten Assembler/Debugger).
Ich erinnere mich auch heute noch gern an diese Zeit.

Gut, ich habe graue Haare... aber für Admin-Scripts finde ich Perl immer noch ziemlich brauchbar. Sehr häufig geht es bei mir um Textmanipulation, und da ist Perl mit RegEx und für mich brauchbarem String-Handling immer noch erste Wahl. Mir ist jedenfalls noch kein Problem über den Weg gelaufen, weswegen ich Python lernen wollen würde. AppleScript schon eher, aber da habe ich noch keinen Einstieg gefunden.

Aber klar, YMMV

Willkommen im Club
Nein, eben (leider) nicht mehr. Das ist genau das Problem - Perl war jahrelang erste Wahl, ich habe selbst auch sehr viel, sogar größere Projekte, in Perl entwickelt.

Irgendwann so um die Jahrtausendwende hat Perl aber leider den Anschluß verpaßt und sich nicht mehr weiterentwickelt. Moderne - und deutlich besser lesbaren Code liefernde - Ansätze der objektorientierten Programmierung kann man in Perl zwar realisieren, aber im Grunde ist das eher eine OO-Imitation als wirklich OO. Sigils (also als Prefix verwendete Sonderzeichen, die den Typ einer Variable angeben, wie $, @ und %) sind auch ein aus den 80ern übriggebliebenes Konzept, das heute eher archaisch anmutet.

Ich habe auch lange an Perl festgehalten, zumal es ja auch immer Aufwand bedeutet, sich komplett umzustellen, aber letztlich bin ich dann doch zu Python gewechselt und bin heute sehr froh darüber.

Das ist aber natürlich auch immer eine Frage der Notwendigkeit. Wenn Du gelegentlich mal ein paar Zeilen Code schreibst und Dir das in Perl flott von der Hand geht - bleib dabei, das ist vollkommen in Ordnung und wenn Du es nicht aus Gründen des persönlichen Spaßes an Neuem machst ist es auch nicht wichtig.

Perl neu zu erlernen würde ich heute aber wirklich niemandem mehr empfehlen.

Warum es auf dem absteigenden Ast ist, ist einfach zu beantworten: Weil es eine von Oracle mit heftigen Lizenzgebühren belegte, gräßliche Sprache mit riesigen Kompatibilitätsproblemen zwischen den einzelnen Releases ist. Kurz: Weil es das verdient hat

OK, ja, das ist jetzt ein kleines bißchen subjektiv.

Daß es auf dem absteigenden Ast ist, zeigen die einschlägigen Statistiken, z.B. Tiobe (Link siehe oben). Du kannst aber auch andere Statistiken bemühen, die Du leicht findest RedMonk oder PYPL zum Beispiel. Weniger die Reihenfolge der Sprachen ist interessant, weil die von der Methodik abhängt, aber der Trend über die Jahre ... die Nutzung von Java sinkt langsam (auch bedingt durch die von Dir erwähnte große Verbreitung in Firmensoftware), aber stetig.

Hat jemand eine Idee, wonach ich suchen muss, um ein monolithisches Python zu bekommen, das ich einfach mit in meine Applets packen kann? Also die Runtime mit allen Dependencies in einem Binary. Ich will meine Skripte nicht kompilieren, sondern den Interpreter mitliefern.

Ich würde schlicht und einfach mal Javascript vorschlagen. Das ist signifikant verbreiteter und flexibler als Python und leidet auch nicht an der IMO extrem dummen Idee signifikanten Whitespace in der Syntax zu nutzen.

Gerade wenn es um Skripting-Sachen geht kann man mit Node.js sehr viel machen. Das Ökosystem ist mit der npm-Package Registry riesig.

Lernt man noch das Typssystem mit Typescript dazu ist das ebenfalls hilfreich.

Als Editor mit allem drum und dran ist Visual Code gut geeignet.

py2app dürfte sein, was Du suchst.

Naja, über Geschmack läßt sich nicht streiten ... was für den einen eine "extrem dumme Idee" ist, ist für den anderen einer der Gründe, warum er die Sprache sehr schätzt. Genauso könnte man den Klammerverhau bei JS (und anderen C-ähnlichen Sprachen) als "extrem dumme Idee" bezeichnen ...

JavaScript würde ich Python (trotzdem ) vorziehen, wenn es um Frontend-Entwickung und GUIs ginge. "Scripte und kleine, schnell erstellte Programme" klingt mir aber eher nicht so.

Es wäre im Grunde sinnvoller, die Runtime einmal zu installieren und nicht in jedem Droplet die komplette Runtime einzupacken. Das spräche dann eher wieder für eine kompilierte Sprache und nicht für eine Skriptsprache. Aber wie bereits erwähnt gibt es auch dafür Lösungen, die vermutlich entweder Python nachinstallieren oder die Python-Umgebung eingebettet haben. Es gibt übrigens auch Cython, mit dem man aus Python native Programme kompilieren kann, das habe ich aber noch nicht probiert. Ein paar meiner Projekte sind OpenSource und da wäre das ohnehin nicht notwendig.

Ich habe neulich erst eine kleine DB-Anwendung mit Django umgesetzt, weil Django-Code in Python geschrieben wird und man JavaScript optional nutzen kann, das aber zum Glück nicht muss - dann hätte ich nämlich gelassen.

Ich glaube für den gewünschten Zweck (Automatisierung von Abläufen) is JavaScript ziemlich unsinnig. Wozu sollte man eine Web-Technologie verwenden, die dann in einer Web-Browser-Umgebung etwas nativ auf dem Rechner tut? Einer der Gründe, weshalb ich Electron für völlig überbewertet halte. Electron macht eigentlich nur Sinn, wenn man eine App für etwas baut, was man sonst im Browser laufen lassen würde - genau das macht Electron. Daher scheidet bei mir übrigens VS Code als Editor aus.

Ansonsten verstehe ich, dass manche sich Einrückungen im Code nicht vorschreiben lassen wollen. Was hatten wir im Büro schon für Diskussionen über TAB vs. BLANKS. Tatsache ist aber, dass das die Lesbarkeit verbessert. Nicht umsonst gibt es Code-Beautifier die Einrückungen von zB C-Code vornehmen und an Style-Guides anpassen. Die gibt es bei Python eher nicht, weil man da ohnehin einrücken muss. Am Ende ist die Lesbarkeit von Code wichtiger als ein paar Bytes, die man sich sparen könnte. Es soll doch tatsächlich schon vorgekommen sein, dass man eigenen Code erst nach Jahren mal wieder anschaut - da ist die Lesbarkeit sehr hilfreich, weil man oft selbst nicht sofort weiß, was man wie implementiert hat. Gerade „schnell mal eben“ geschriebener Code hält sich oft am längsten

Python@3.10 habe ich wg. VisiCalc bereits installiert. Es ließ sich aber nicht selbst aufrufen. Also habe ich gestern Python installiert (3.11) und es funktioniert offenbar. Erkennt Python im Normalfall selbst, welches die Hauptversion ist? "python3 --version" antwortet jedenfalls mit Python 3.11.2 und VisiCalc funktioniert auch noch.
Die Python Launcher App findet kein Default-Python. Muss ich hier einen Alias an einen der Default-Orte einrichten? Oder ist die App erstmal unnötig?Für mich sind Einrückungen sehr viel lesbarer als diese geschweiften Klammern.

Dann steht das Python-Executable nicht in PATH. Vermutlich installiert sich VisiCalc irgendwo eine private Python-Umgebung.

Die zu nutzen ist ohnehin keine besonders gute Idee, da solche Setups oft ziemlich allergisch auf die Installation neuerer Paketversionen durch Dritte reagieren. Lieber in Ruhe lassen und eine saubere eigene Installation nutzen, und bei größeren Projekten auch venv/virtualenv, um Versionsprobleme grundsätzlich zu vermeiden.
Wenn Du keinen vollständigen Pfad beim Aufruf angibst (z.B. "/usr/bin/python3"), nutzt die Shell das Python, das sie zuvorderst im PATH findet. Welche das ist, findest Du mit "which python3" heraus.
[/code]
Wenn Du aus dem Terminal arbeitest, ist sie komplett unnötig.
Geht mir auch so, aber manche Nutzer sehen das halt anders ... jedem das seine. Wenn es jemandem so weh tut, syntaktische Einrückungen zu nutzen, dann ist Python halt die falsche Sprache für ihn.

Ich mache ziemlich viel mit Django und finde die Umgebung auch durchaus angenehm - GUI-Entwicklung ist auch nicht wirklich mein Ding, und das nimmt einem Django zumindest wenn man keine speziellen Anforderungen hat sehr schön ab. Da bin ich also ganz bei Dir.
Geht mir auch so. Aber auch hier wieder - Geschmacks- und Prinzipsache. Ich habe eine Electron-Anwendung, um die ich derzeit nicht herumkomme (Stoplight Studio), und auf die Dauer macht mich das Ding wahnsinnig.
Das ist so ein Aufreger, den ich nicht wirklich verstehe. So ziemlich jeder sollte gelernt haben, daß semantisch korrekte Einrückungen die Lesbarkeit von Code dramatisch verbessern. Der Unterschied bei Python ist nur, daß sie nicht nur semantisch, sondern eben auch syntaktisch relevant sind. Wer das als "Gängelung" begreift kann damit dann nicht leben ... andererseits halte ich das für sehr subjektiv und eigentlich kaum rational begründbar.
Ah, eines meiner Lieblingsthemen ... ich bin (natürlich ) strikt gegen Tabs im Code. Schon allein, weil das zu heillosem Kuddelmuddel führt, wenn Leute mal Tabs und mal Spaces verwenden und dann jemand anders, am besten noch mit einer anderen Grundeinstellung für die Anzahl der Spaces pro Tab, den Code anfaßt.

Zum Glück gibt es auch da bei guten Editoren eine Lösung: Entweder jeweils n Spaces automatisch in ein Tab wandeln oder andersherum, aber konsistent. Und da es bei Cursorbewegungen per Tastatur immer nervt, wenn der Cursor auf einmal um vier Stellen springt, wenn man nur einmal auf die Cursortaste getipp hat: Spaces. Punkt. (Das gibt einen lustigen Flamewar ).
Oh, aber natürlich gibt es die, zum Beispiel Black . Der paßt auch nicht nur die Einrückungstiefen an, sondern sorgt auch generell für die Einhaltung des vorgegebenen Codierstils. Meiner Meinung nach eine sehr sinnvolle Sache.
Das Skurrile ist, daß Python-Code in aller Regel deutlich kürzer ist als der in vielen anderen Programmiersprachen, da diverse bei Python überflüssige Syntaxelemente durch die syntaktische Einrückung unnötig sind - allen voran die in vielen Sprachen inflationären geschweiften Klammern. Also lesbar und kurz ...

Wenn man die Wahl hat und/oder grüne Wiese dann unbedingt Python.
Mit einer Zeile installiert. Venv oder (mini)conda. Riesige Codebasis.
Leichter als Basic damals, sehr viel mächtiger. (pytorch, django etc)
Platformunabhängig.
macOS ist unixoid und da passt das bestens.

Gruss,

Bodo, Senior Admin/Programmierer, der viel Mist und Legacy Blödsinn gesehen hat und sieht.

Für gröbere Sachen (embedded etc): Rust

Die Frage ist ein bisschen seltsam – das klingt so, als ob die Auswahl immer dünner würde, aber das Gegenteil ist der Fall.

Mag sein, dass macOS weniger vorinstalliert mitliefert als früher, aber wer sich zutraut, Skripte zu schreiben, sollte sich auch zutrauen, Skriptsprachen zu installieren, und zwar direkt von deren Websites, völlig unabhängig von Apple. macOS ist das verbreitetste Unix-Betriebssystem; kein Anbieter von Unix-Skriptsprachen wird es sich erlauben, keine Installationspakete für macOS anzubieten. Das ist alles völlig zukunftssicher und hat damit, was Apple macht, nix zu tun.

Welche Sprache man nutzen sollte, lässt sich so allgemein kaum sagen, dass hängt sehr von den Aufgaben ab.

Es gibt 3 „Sprachfamilien“, die auf ganz verschiedene Aufgaben zugeschnitten sind. Innerhalb der Familien ist es dann eher Geschmacksache, welches Familienmitglied man bevorzugt.


1. Shellsprachen

bash, zsh, … Diese Sprachen dienen zuvorderst der interaktiven Nutzung als Terminal-Shell. Für ganz einfache Skripte lassen sie sich aber auch verwenden; Vorteil ist der fast nahtlose Übergang zwischen Shell-Interaktion und Skript; was man gerade einmalig interaktiv in der Shell gemacht hat, kann man schnell in ein Shellskript zur wiederholten Nutzung überführen. Operationen mit Dateien (Kopieren, Verschieben, Umbenennen, Rechte anpassen) wären klassische Beispiele.

Ich rate Einsteigern zu bash, weil es dafür die mit Abstand meisten Beispielskripte im Netz gibt. Andere bevorzugen zsh; das ist Geschmacksache und natürlich genauso legitim, nur sollte man zsh nicht deswegen bevorzugen, weil Apple das aus Lizenzgründen pusht; man wird auch immer bash installieren und nutzen können.


2. Unix-Skriptsprachen

Unix-Skriptsprachen sind von vornherein auf Skripte zugeschnitten und entsprechend leistungsfähiger. Sie dienen komplexeren Automatisierungen aller möglichen Dinge auf Unix-Ebene, d.h. unterhalb der macOS-GUI. GUI-Dialoge können manche Sprachen durchaus generieren, aber keine kann mit existierenden macOS-GUI-Apps interagieren. Ansonsten wieder Geschmacksache; ich finde Python wegen der semantischen Funktion von Whitespace grässlich, andere lieben es genau deswegen … Ich bleibe dann lieber beim angeblich veralteten Perl.


3. macOS-Skriptsprachen

Das sind Skriptsprachen von Apple, die in der Lage sind, mit Cocoa-GUI-Apps zu interagieren, und für entsprechende Aufgabenstellungen daher alternativlos. AppleScript, die eine der beiden Sprachen, hat aber eine sehr, nunja, eigenwillige Syntax, die nach meinem Eindruck nur die wirklich beherrschen, die 25h/Tag mit AppleScript arbeiten; alle anderen modifizieren immer nur Code-Beispiele. In Unix-Sprachen simple Dinge wie Dateioperationen können in AppleScript unglaublich umständlich sein.

AppleScript ist das völlig misslungen, was Objective-C als Compilersprache so unglaublich gut gelungen ist: Programmzeilen zu schreiben, die sich fast wie englischer Text lesen lassen. Das liegt daran, dass Apple – anders als Objective-C – die Freiheitsgrade natürlicher Sprachen imitieren wollte, weshalb semantisch bedeutungslose Füllwörter eingebaut werden können, alles auf x verschiedene Weisen ausgedrückt werden kann und am Ende niemand mehr durchblickt, was nun gerade erlaubt ist und was nicht.

Die Alternative dazu, die es dankenswerterweise seit einem Jahrzehnt gibt, ist JavaScript for Automation (JXA). Das ist JavaScript aufgebohrt mit den Funktionen von AppleScript, die mit GUI-Apps interagieren können, sodass das nun auch mit einer halbwegs vernünftigen Sprache möglich ist.

Leider ist JXA wie so vieles bei Apple nicht „ganz fertig“ geworden, es fehlen einige AppleScript-Funktionalitäten. Meist kann man AppleScript aber ganz gut damit ersetzen. JXA ist eher spärlich dokumentiert, daher hier ein paar Links zu guten Dokumentationen:

JXA Resources (Übersicht zu verfügbaren JXA-Infos)
Scripting with JXA (die IMHO beste Einführung)
JavaScript for Automation Cookbook
A Beginners Guide to JXA, JavaScript Application Scripting

Schließlich sei noch darauf verwiesen, dass man für komplexere Aufgabenstellungen, die beides benötigen, Shellskript- und Unix-Skriptsprachen mit macOS-Skriptsprachen mischen kann, um von den Vorzügen beider zu profitieren:

Von macOS-Skripten aus kann man Shellskripte mit do shell script (AppleScript) bzw. doShellScript (JXA) aufrufen.

Aus Shellsprachen und Unix-Skriptsprachen lassen sich mit dem Unix-Programm osascript AppleScript und JXA aufrufen.

Es ist als JavaScript for Automation sogar höchst sinnvoll, wenn bei dieser Automatisierung auch Cocoa-Apps eine Rolle spielen, denn dann wäre die einzige Alternative das sperrige AppleScript.
JavaScript for Automation läuft nicht in einer Web-Browser-Umgebung, sondern in einer in macOS integrierten Laufzeitumgebung.

Ja, für die Meisten ist es kein Thema, einen Installer etwa für Python aufzurufen oder im Terminal "xcode-select --install" einzugeben. Wenn jemand aber keinem Installer traut, diesen aufgrund von Rechtebeschränkungen nicht ausführen kann oder eben Angst vor dem Terminal hat, dem ist nicht geholfen. Da will ich keinem rein funken. Ich muss ja schon Überzeugungsarbeit leisten, damit jemand ein Droplet von mir annimmt. Meist sehen sie es live und dann wollen sie es auch.

Es ging halte jahrelang recht einfach, so Mischskripte als Droplet zu verteilen. Einiges habe ich sogar mit reinem AppleScript von der Python-Abhängigkeit lösen können, aber das geht natürlich nicht, wenn ich etwa komplexere Python-Funktionen nutze, um Markdown zu interpretieren.

Ein kompiliertes Python/Cython kommt für mich nicht infrage, weil ich manchmal auch beim Kollegen auf Fehlersuche gehen und dann direkt Korrekturen im Skript testen möchte. Ist sicher alles kein sauberes Vorgehen, aber die Skripte entstehen meist quick & dirty, wenn knappe Zeitfenster verfügbar sind. Deshalb ist es auch wichtig, dass ich wenige Zeilen Code tippen muss. Ich kann mir leider keinen ganzen Arbeitstag Zeit nehmen, um was sauberes zu programmieren. Meine Fähigkeiten sind da auch zu beschränkt. Bin das typische Skriptoverflow-Skript-Kiddie, oder mittlerweil eher -Grandpa. 😁

Bzgl. JXA fehlt mir übrigens eine vernünftige Entwicklungsumgebung, wie Script Debugger für AppleScript. Der Skripteditor ist totale Grütze und nicht wirklich hilfreich. Die Dictionaries sind leider oft auch nicht an JXA angepasst.

Python gibt es als ganz reguläres macOS-Installer.pkg; Du brauchst weder das Terminal noch irgendwelche besonderen Prozeduren. Wer nicht mal das will, na, der will halt nicht, der kann dann ja auch keine Programme außerhalb des App Stores installieren. So jemandem ist nicht zu helfen.
Warum willst Du Leute denn zu ihrem Glück zwingen?
Ich schreibe recht viel JXA-Skripte und kann beides nicht bestätigen. Man braucht ganz am Anfang halt etwas Geduld, aber ist das nicht überall so? Mit JXA bist Du wenigstens die Installations-Hypochonder los.

Das Argument von Nebula war nicht, dass AppleScript besser als JXA sei. Für AppleScript gibt es das Programm Script Debugger , was recht hilfreich sein soll. Für JXA gibt es nichts Vergleichbares, sondern nur den Skripteditor.

Wenn ich das richtig sehe, ist JXA:

• Komplett Apple-propietär, und selbst da nur eine Nischenlösung
• Nie wirklich fertig geworden und allem Anschein nach von Apple aufgegeben
• Nicht gut und vor allem nicht korrekt dokumentiert
• Funktional unvollständig (z.B. keine RegEx)

Quelle:

Die einzigen Vorteile scheinen mir die Nähe zu JavaScript, die Integration mit macOS zur Automatisierung und die Schnittstelle zu Objective C zu sein. Ich glaube nicht, daß ich so eine Sprache als Lösung für kleine Scriptaufgaben ernsthaft eines zweiten Blickes würdigte, wenn ich nicht schon in JavaScript eingearbeitet bin und der Lernaufwand damit überschaubar ist.

Von einem halbtoten Pferd (Perl) nicht abzusteigen ist eine Sache, auf ein totes Pferd (JXA) aufzusteigen eine andere.

Jede der angeführten Sprachen hat ihre Vor- und Nachteile, daher glaube ich nicht dass es die eine Sprache für alles gibt.
In meinem Alltag ist es meist eine Kombination aus zsh & AppleScript, da beide recht reibungslos miteinander harmonieren. Die Unterschiede zwischen zsh und bash sind schnell gelernt, also kein Verlust. AppleScript ist eine komplett andere Welt, aber zur Kommunikation mit Scripting-fähigen Programmen eigentlich ohne ernsthafte Alternative. Es sei denn du arbeitest viel mit JSON, dann halt auch noch JXA. Alles unter der Prämisse, so wenig wie möglich auf den Macs zu installieren oder mir Gedanken machen zu müssen welche Version evtl. vorhanden ist oder Vorrang hat.

Zuvor wars meist bash und python; allerdings, wie mit Python in 12.3 oder so geschehen, würde ich eine kurzfristige Entfernung von bash nicht komplett ausschließen (obwohl ich den Aufstand aller Mac Admins dann gern sehen würde).

Aus meiner Sicht die beste Alternative?
Keine Ahnung, aber vielleicht wird's irgendwann mal Swift, einfach weil Network Requests und das Parsen von XML, CSV oder JSON relativ simpel sind (also, nicht zwingend die Network Requests, aber den Grundstock braucht man ja nur einmal). Und weil damit vollwertige UI's machbar sind (für die, die's brauchen und manchmal braucht man's halt).
Allerdings ist der Aufwand doch ein ganz klein wenig höher und ich hab keine Idee ob und wie in den noch unterstützten macOS Versionen (also 11, 12, 13) verschiedene Swift-Versionen vorinstalliert sind (ok, ich hab mich auch nicht dafür interessiert).

Du missverstehst das - mein Hinweis hatte nichts mit einem „Geschmacksurteil“ zu tun. Wir haben Python seit mehr als 15 Jahren als Skriptingsprache in unserem Produkt integriert und das absolut häufigste Problem ist, dass irgendjemand ein Skript mit einem Editor editiert der die „falsche“ Einstellung zu Tabs vs Spaces hat. Am Ende kommt es dann zu schwer nachvollziehbaren Fehlern. Dieses Argument, dass Python mit dieser „Designentscheidung“ unerfahrene Entwickler zum richtigen Einrücken ermuntert ist also ein Witz. Die bessere Lösung dafür ist einfach Prettier als Commit-Hook in JavaScript/TypeScript.


JavaScript würde ich Python (trotzdem ) vorziehen, wenn es um Frontend-Entwickung und GUIs ginge. "Scripte und kleine, schnell erstellte Programme" klingt mir aber eher nicht so.
[/quote]

Das sagt ja auch niemand. Du hast es aber auch falsch herum beschrieben. Webbrowser verwenden JavaScript-Umgebungen und nicht JavaScript „Webumgebungen“. Die Browser-APIs und das DOM sind in Node.js nicht verfügbar - es unterscheidet sich hier nicht von Python… nur hat es einen besseren JIT-Compiler, kann mit WASM Platformunabhängigen Code in nahezu nativer Geschwindigkeit ausführen und hat natürlich auch die Möglichkeit native Module zu laden wie Python auch.

Man kann aber zB die Devtools eines Browsers nutzen um Node.js Skripte interaktiv zu debuggen… wenn man nicht eh gleich eine entsprechende IDE benutzt.

Wieso? Was ist ein Webbrowser anderes als eine plattformunabhängige hochoptimierte UI? Mittels HTML oder gar einem Framework wie React kriegt man in wesentlich kürzerer Zeit eine brauchbare UI als das mit Python jemals möglich war. Zudem ist das nicht die einzige Möglichkeit: man kann den Browser auch weglassen und zB mit React Native native UIs bauen.

Auch hier ein grobes Missverständnis dessen um was es geht. Die Kritik an Pythons strunzdoofer signifikanter WS Syntax hat nichts mit „Geschmack“ oder „kompakter geschriebenen Code“ zu tun sondern mit der Pflege-Hölle die man damit hat wenn mal wieder jemand eines der Pythonskripte im System mit dem falschen Editor bearbeitet hat. Wir haben Python seit mehr als 15 Jahren als Skriptsprache in unserem Produkt integriert und es ist eine der am meisten bereuten Entscheidungen überhaupt

Könnt Ihr mir noch bitte eine Einschätzung zu Ruby geben? Ruby ist immerhin noch vorinstalliert (und Homebrew benötigt es), hat kein Spaces/Tabs-Problem und scheint doch gerade für Scripting gut geeignet.
Und meine Haupt-Fundgrube nutzt Ruby , sonst würde ich vermutlich gar nicht überlegen.

Mit Python kann man direkt etliche GUIs programmieren. Es gibt APIs für GTK, Qt, Tk, WxWindows, … Es gab zumindest einmal auch eine Bridge für die Cocoa-API von MacOS X. Es mag also ein Problem sein für macOS ein natives GUI mit Python umsetzen zu können, aber JavaScript kann es ebenfalls nicht. Mit Glade (GUI Editor für GTK-GUIs) kann man GTK GUIs bauen, und diese per simplen Befehl laden, so dass das in Python ein Einzeiler ist.

Mit React Native kann man in JavaScript native UIs bauen… und mit Expo ist das sogar besonders einfach.

Ich will ja niemandem sein Python madig machen - aber es ist mir schlicht bis heute ein Rätsel wieso so viele Anfänger darauf stehen… vermutlich wegen dieses naiven „Syntax ist wie Pseudocode“-Spruches der nun wirklich der größte Schmarren ist. PIP ist sogar gegen npm echt schlecht… und das will was heißen. Generell sind viele Python packages sichtlich von Erstsemestern mit rudimentärer Programmiererfahrung mit heißer Nadel gestrickt.

Zu JavaScript gibt es wenigstens einen Sprachstandard, viele gepflegte und gut optimierte Implementierungen und es läuft auf praktisch jedem OS und Gerät. Mit Typescript gibt es sogar ein wirklich sinnvoll gemachtes Typsystem dafür. Seit ES6 hat sich die Sprache auch durchaus positiv entwickelt. Bei Python kann ich das so eher nicht behaupten…

Wer was mit ML macht (wegen des ML Ökosystems) oder eine bestehende App mit Python-Skripting ansteuert… jepp da ist es wohl angemessen. Als allgemeine Skriptinglösung finde ich es aber nicht empfehlenswert. Als Lehrsprache schon gleich zweimal nicht

Python ist im MINT-Bereich sehr verbreitet, weil es sehr simpel erlaubt technischwissenschaftliche Auswertungen mit NumPy zu machen. Als sich da Python etablierte war JavaScript ein recht großes Ärgernis im Webbrowser und für sonst nichts zu gebrauchen.

Und ich weiß nicht wie Du darauf kommst, man würde mit React ein natives GUI bauen. Python mit GTK nutzt das ObjectModel von GTK (GObject) und kein eigenes! Gerade wenn man Crossplattform FrameWorks nutzt, wird eben nicht das native FrameWork einer Plattform genutzt, es werden dann nur Elemente des nativen GUIs benutzt. Es gibt da nicht unerhebliche Unterschiede wie die Programme mit dem Rest des GUIs interagieren, und das fällt Nutzern auf, wenn sie sehr genau darauf achten. Hier im Forum gibt es einige, denen das sofort auffällt.

Keine Ahnung, was Dich an dem Skript-Editor stört. Ich kann JXA-Skripte damit problemlos schreiben.

Eine „Entwicklungsumgebung“ für Skripte finde ich Kanonen auf Spatzen.
Was meinst Du denn damit? Die .sdef-Datei? Die muss für JXA doch überhaupt nicht angepasst werden – das ist dieselbe Schnittstelle.

Wenn, aber das ist nicht der Fall. Ich verstehe nicht ganz, wie Du aus der von Dir verlinkten Quelle die folgenden Punkte ableiten kannst.
Das ist das ganz normale JavaScript (auf macOS 10.14.6 Version 1.7) ergänzt um die Schnittelle zu Cocoa-Apps – die ist natürlich proprietär, nicht mehr und nicht weniger als AppleScript.Dass Apple bei vielen Sachen bei 95% die Lust verliert und sich lieber dem nächsten heißen Scheiß zuwendet, ist ja leider nichts Neues. Bei Cocoa ist das mindestens ebenso schlimm. Das allermeiste funktioniert aber. Und aufgegeben ist da gar nix; ich habe mich erst kürzlich mit dem zuständigen Apple-Ingenieur über Verbesserungen ausgetauscht.Nicht gut ja (auch so ein wohlbekanntes Apple-Phänomen, deshalb habe ich ja hilfreiche andere Websites verlinkt), aber was meinst Du mit nicht korrekt? Das ist falsch; das normale JavaScript wird bis auf die nur innerhalb eines Webbrowsers sinnvollen Funktionen vollständig unterstützt; RegEx sind kein Problem.
Findest Du AppleScript lebendiger? Das ist nunmal die einzige Alternative zu JXA, wenn Du mit Cocoa-Apps interagieren willst.

Quark - Python war immer schon charmant für Skriptkiddies und außerhalb der Informatik haben die Leute meist nur sehr rudimentäre Programmierkenntnisse. Was ich da schon an Python „Programmen“ gesehen habe… da kommt selbst Pferden das kotzen.

React Native wer lesen kann ist klar im Vorteil.

Es nutzt Bridging - aber was tut GTK hier überhaupt zur Sache?

Mit React Native kannst Du beliebige native Views und Controls einbinden bzw. Komponenten in bestehende native UIs integrieren.

Niemand redet hier von GTK, QT oder sowas wie Flutter.

Lange Rede kurzer Sinn - wenn Du gerne mit einer Skriptkiddie-Sprache wie Python arbeitest sei Dir das unbenommen. Du könntest aber auch akzeptieren, dass es neben diesem Vorschlag auch andere - mitunter bessere Alternativen gibt… aber ich weiß Python-Fanboys tun sich da schwer damit…

Dank Euch Allen für diesen sehr interessanten Thread!

Ich (ganz graue Haare und seit Atari 800 dabei) hab‘ gerade Python für mich entdeckt, weil es gut auf der Synology läuft und ich damit viele kleine Spielereien für die Hausautomation mache. Auf dem Mac werde ich es auch vermehrt einsetzen, weil AppleScript mich zu oft nervt.

Swift sieht auch gut aus, läuft aber nicht auf der Synology. Trotzdem werd‘ ich damit Mal spielen…

Python nur wegen der Beliebtheit bei Skript-Kiddies abzuwerten, ist eine sehr oberflächliche Sichtweise. Natürlich kann man mit Python schlechten Code schreiben, das kann man mit jeder Programmiersprache.

Die Aussage: Python ist charmant für Skript-Kiddies ist hinreichend aber nicht notwendig. Bedeutet also nicht, dass Python nur etwas für Skript-Kiddies ist.
Das gleiche gilt für die Aussage: mit Python kann man schlechten Code schreiben - was nicht bedeutet, dass Python-Code schlecht ist.

Du wolltest mich (und eventuell andere) sicher nicht als Programmieranfänger bezeichnen - unterstellst aber, dass man wohl ein Programmieranfänger sein müsse, wenn man jemandem zum Einstieg Python empfiehlt. Es kommt nicht von ungefähr, dass man die Konzepte des Programmieren an Schulen oft mit Python (am RasPi) lehrt. Vielleicht rührt daher deine Skript-Kiddie Aussage.

Ich bin aber ganz sicher kein Programmieranfänger - ich lebe seit über 30 Jahren davon. Ich hatte ja schon erwähnt, dass ich mit BASIC (mit Zeilennummern) Anfang der 80er begonnen habe und ich habe seither schon mit einigen Programmiersprachen hantiert, einschließlich Assembler für verschiedene Prozessoren. Das liegt einfach daran, dass jede Programmiersprache sich aus verschiedenen Einsatzzwecken entwickelt hat. Es gibt keine universelle Sprache, die für alle Aufgaben die optimale Wahl ist.

Aber Dir ist schon klar, daß Du Dich da komplett in die Python Hater-Ecke verrannt hast, oder?

Projekte wie Sage , Pandas und TensorFlow , um nur ein paar zu nennen, sind aus der Wissenschaft kaum wegzudenken und wohl kaum das Werk programmierunerfahrener Scriptkiddies.

Sites wie Reddit und Youtube sind (oder waren, so genau verfolge ich das nicht) in Python implementuert - wohl kaum von irgendwelchen Scriptkiddies.

Viele Linux-Tools, unter anderem auch die Systeminstallationsroutinen sind in Python implementiert. Und so weiter, mehr findest Du bei Interesse hier .

Also vergessen wir mal das Scriptkiddie-"Argument" und kommen auf die sachliche Ebene zurück.

Ich kenne Dein Projekt nicht, aber wenn Ihr massive Probleme habt, weil die Leute verschiedene Editoren mit (so nehme ich an) verschiedenen Tab-Einstellungen den Code verhunzen, dann habt Ihr kein Python-Problem, sondern eins mit der Definition des Code Styles. Und natürlich mit Tabs, aber davon hatte ich es ja schon. Und vielleicht - da lehne ich mich jetzt aber vielleicht zu weit aus dem Fenster - mit der Qualität der Programmierer. Die verhunzen Dir in jeder anderen Sprache den Code genauso, nur hat es da keine Konsequenzen außer daß die Lesbarkeit leidet.

Umgekehrt habe ich in den letzten 10-15 Jahren schon an ziemlich vielen Projekten (mit)gearbeitet, in denen nur oder auch Python als wesentliche Implementierungssprache zum Einsatz kam, und in keinem davon, auch nicht in welchen mit deutlich mehr als einem Entwickler, hat es die Art von Problemen gegeben, die Du beschreibst. Darüber stolpert man vielleicht ein paarmal am Anfang, und das war's dann - das passiert Dir bei jeder anderen Programmiersprache genauso, nur an anderen Stellen. Wenn man nicht gerade Gelegenheitsprogrammierer (oder Scriptkiddies - ach nein, die beherrschen ja Python ) an seinen Code läßt sollte das kein Thema sein.

Und nochmal: Wenn man Python aus irgendwelchen Gründen nicht mag oder andere Sprachen von den Features her geeigneter erscheinen zwingt einen niemand es zu benutzen. Ich bleibe aber dabei, daß Python als Einsteigersprache für einfache Scripting-Aufgaben ebenso wie für große Projekte bestens geeignet ist, gegebenenfalls (Frontend) in Verbindung mit Frameworks wie Django, dann ggf. JavaScript, TypeScript, Bootstrap etc. für GUI-Anpassungen.

Hier mal ein Link zu den "Skriptkiddies" und "Python-Fanboys" vom Large Hadron Collider am Cern:

Vorab: Keine Sprache hat ein Spaces/Tabs-Problem. (Schlechte) Programmierer haben ein Spaces/Tabs-Problem. Grausigen Code produziert das in allen Sprachen, nur bei Python sind die Programme dann kaputt ... das kann man aber auch als Vorteil sehen, dann merkt man nämlich, daß man beim Code Style pfuscht (vorausgesetzt man testet seine Änderungen):
Sollte reichen, oder?

Zu Ruby: Ich komme auch dann und wann damit in Berührung, insbesondere die Konfiguration von Vagrant erfolgt in Ruby und da muß ich wirklich mitunter nicht ganz triviale Sachen machen.

Demzufolge hatte ich auch schon Ansätze gemacht, mich da tiefer einzuarbeiten und die Sprache von Grund auf zu erlernen, aber irgendwie bin ich nie so richtig damit warmgeworden. Die Syntax ist ein wenig ungewöhnlich und die Lernkurve steiler als bei Python, aber das ist eigentlich kein Problem - meine Hauptschwierigkeit bei der Motivation war eher, daß ich nichts gefunden habe, was ich in Ruby eleganter, schneller, einfacher oder kürzer hätte erledigen können als in anderen Sprachen, und daß Ruby als zusätzliches Standbein daher für mich keinen großen Sinn hat.

Insofern: Wenn Du auf der sprichwörtlichen grünen Wiese stehst, ohnehin Bedarf an Ruby-Kenntnissen hast und Dich auf eine Sprache einschießen willst, dann ist Ruby sicher einen Versuch wert. Es gibt ziemlich umfangreiche Libraries an Modulen ("Gems"), eine aktive Community, so daß man auch mal Teillösungen im Netz findet, und Ruby wird ebenso wie Python permanent aktiv weiterentwickelt.

Immerhin kenne ich Algorithmen aus der Graphentheorie
Danke für den Thread, der mir sehr weitergeholfen hat. Als Scriptkiddie werde ich wohl opportunistisch vorgehen (AppleScript) und bei eigenen Werken eher den Fokus auf Python und Java legen.