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?

und die Antwort schreibt Apple selbst doch schon

Es geht aber nicht um Apps, sondern um alleinstehende Skript-Dateien.

Also, warum nicht einfach mal Go ausprobieren?
Ist kostenlos, VS Code ebenfalls, die Erweiterung für Go paßt perfekt, die Sprache ist gut dokumentiert und es gibt ein sehr gutes Buch für Programmiereinsteiger:
Get Programming with Go (von Nathan Youngman & Roger Peppe).

Das einzige Kriterium welches nicht erfüllt wird ist, daß Go keine Skriptsprache ist. Aber, wenn hier schon Xojo in den Ring geworfen wird, welches gerade wieder 50 Euro teurer geworden ist (von 349 auf 399 Euro), dann weiß ich auch nicht.

Aber nur darum geht es in diesem Thread. 🙄

Wenn es um Compilersprachen ginge, müssten wir doch nicht diskutieren. Da nimmt man auf dem Mac natürlich Objective-C oder Swift. Schöngeister Ersteres, Krämerseelen Letzteres.

@Weia
Für Dich noch einmal zum Nachlesen (letzter Post von Nebula):
"Ich habe schon mit Xojo geliebäugelt, da ich damit ebenfalls schnell kleine Progrämmchen basteln kann, die auf jedem Mac funktionieren."
Und, vielleicht vergleichst Du mal die Einstiegshürden zwischen den von Dir genannten Compilersprachen und Go und ebenfalls zwischen Xcode und VS Code.
Ich habe lediglich versucht, eine kostenlose, leichtgewichtige und einsteigerfreundliche Alternative zum genannten Xojo aufzuzeigen, da nun offensichtlich "Scriptsprache" kein Alleinstellungskriterium mehr darstellt.

Läßt sich das nicht mit Script Bundles erschlagen? Da könnte man doch die Runtime einfach unterbringen, wie bei Apps.

Das ist aber ein absurder Overhead. 10 kleine Skripte mit ein paar Hundert Bytes, und dann jedes Mal die Runtime dazu?

Bei Apple ändert sich immer wieder was. Heute ist Ruby, Perl, JXA, AppleScript vorhanden. Also kann man es auch als Skriptsprache nutzen. Ist /usr/bin/swift auch immer vorhanden?
Das Ende von Ruby wurde zwar mal verkündet, aber nicht umgesetzt. Also ist es doch bis auf Weiteres nutzbar.
Und alle genannten Sprachen lassen sich über die Aktion "Shell-Skript" in Kurzbefehle oder in Automator aufrufen.

Dumm nur, dass Du unterschlägst, wie’s weitergeht:Nebula hat diesen Thread begonnen, nachdem und weil er Xojo aus den genannten Gründen verworfen hatte.
Was gibt es denn bitteschön bei Objective-C und Xcode für Einstiegshürden verglichen mit anderen Programmiersprachen und Programmierumgebungen? Noch einfacher als Objective-C geht ja wohl kaum, das ist fast wie gesprochene Sprache (also wie das, was AppleScript immer wollte und nie geschafft hat).

Und statt auf die optimal integrierte native Entwicklungsumgebung auf irgendeine Cross-Platform-Krücke ausgerechnet auch noch von Microsoft und basierend auf Elektron 🤮 zu setzen, ist, wenn man nicht unbedingt muss, ja vollkommen widersinnig.

Ich persönlich mag Swift überhaupt nicht, aber Swift Playgrounds bieten in Xcode ja ein Skript-ähnliches Programmiererlebnis ohne Compiler-Zyklen, wenn einem das wichtig ist.

@Weia
Ich finde es toll, daß Du fließend Objective-C sprichst, ist mir nie gelungen. Ebenfalls konnte (und kann) ich mich nie an die - für meine Begriffe - komplizierte OS X API gewöhnen und benutze halt Werkzeuge, die mir eine zusätzliche Abstraktionsschicht schaffen, wie Qt oder eben Go und Zig.
Ein weiterer Vorteil ist dann auch die Plattformunabhängigkeit, die hier aber wohl keine Rolle spielt.
Meine (zugegebenermaßen nicht sehr umfangreichen) in Go geschriebenen Utilities kompilieren in ca 0,1 sek. - nicht wahrnehmbar.
Außerdem gibt es ja auch noch "go run ." vs "go build ."
In Sachen Performance sind Swift und Go in etwa ebenbürtig.
Was Xcode angeht - ich finde VS Code dagegen doch sehr, sehr schlank.

Egal, es nützt Nebula nichts - wenn wir uns gegenseitig unsere Meinungen um die Ohren hauen, daher wird dies mein letzter Post in diesem Thread sein

Aus Neugierde habe ich das "Hello, World!"-Beispiel für Objective-C gesucht. So rede ich nicht einmal mit einem Korken im Mund

Was für ein polemischer Unfug! Wo hast Du das denn bitte her?

Das ist gerade nicht Objective-C, sondern eine ganz banale C-Funktion (NSLog()) zur Textausgabe in der Kommandozeile plus der manuellen Initiierung der Objective-C-Speicherverwaltung in einer C-Funktion (main()), die normalerweise Xcode automatisch vornimmt und mit der der Programmierer gar nicht in Berührung kommt. Und die hier völlig unnötig ist, weil es eben gar keinen weiteren Objective-C-Code gibt. 🙄 Und in einer veralteten, unnötig umständlichen Syntax obendrein.

Man kann Kommandozeilenprogramme in Cocoa und Objective-C schreiben; ihr Schwerpunkt liegt aber auf GUI-Programmen. Wenn Du dafür ein Projekt in Xcode startest, bekommst Du ein Programmgerüst mit u.a. einer Menüzeile und einem Hauptfenster. Du kannst dann mit der Maus grafisch z.B. ein Textfeld irgendwo in das Fenster ziehen und ebenfalls grafisch mit der Datei mit dem Programmcode verbinden, sodass der weiß, dass es ein Textfeld gibt. Bis dahin hast Du noch keinerlei Code geschrieben und die Tastatur lediglich benutzt, um Deinem grafisch erzeugten Textfeld einen eindeutigen Namen zu geben (im Beispiel MeinTextfeld).

Der einzige zu schreibende Code für die Ausgabe von "Hallo Welt!" im Textfeld eines Fensters wäre dann:
Solange man Englisch kann (mit fast wie gesprochene Sprache meinte ich im Falle der von Apple in Cocoa angebotenen Methoden natürlich Englisch, bei eigenen kann man aber natürlich die Sprache seiner Wahl verwenden), sehe ich nicht, wie man nicht verstehen kann, was in dieser Codezeile passiert.

Wenn man will, dass der Nutzer den Text verändern kann, schreibt man:

Das Einzige, was einem spanisch vorkommen mag, sind die für Objective-C typischen eckigen Klammern. Die trennen einfach Objective-C von C. Objective-C ist ja ein Superset von C; alles innerhalb der eckigen Klammern ist Objective-C, alles außerhalb ist C. Das ist die einzige wirkliche Hürde der Sprache: Wenn man sich außerhalb von Objective-C in C bewegt (was man jederzeit kann und was einem einen riesigen Fundus an existierendem Code erschließt), dann sollte man halt C können.

Wenn man zum Beispiel Hallo Welt! auch noch auf Unix-/Kommandozeilen-Ebene ausgeben will, würde man schreiben:
NSLog ist aber C (außerhalb der eckigen Klammern!) und nicht Objective-C. Es ist hingegen Bestandteil der Cocoa-Bibliothek, erkennbar am Präfix NS (von NEXTSTEP). Dein obiges Beispiel ist also auf so vielen Ebenen daneben, dass man schon fast Böswilligkeit vermuten muss.

Objective-C und Cocoa werden oft in einen Topf geschmissen, obwohl es zwei völlig verschiedene Sachen sind. Objective-C ist eine objektorientierte Sprache und supersimpel; sie besteht nur aus einigen wenigen Syntax-Elementen. Wer Objective-C nicht an an bis zwei Wochenenden lernen kann, sollte vom Programmieren generell die Finger lassen. Cocoa hingegen, die Bibliothek, die praktisch die gesamte API für macOS enthält, hat einen riesigen Umfang, in dem man schier ertrinken kann und gar nicht weiß, wo man anfangen soll. Aber das liegt halt am Umfang von dem, was macOS bietet, und nicht an Objective-C. Es wäre mit keiner anderen Sprache anders, sofern sie die Möglichkeiten von macOS nicht beschneidet.

Der Vorteil der Lesbarkeit von Objective-C kommt vor allem bei vielen Parametern zum Tragen:
Keine andere Sprache (außer SmallTalk, der Mutter von Objective-C) kann das so konsistent lesbar formulieren. Swifts Syntax ist leider nur eine jämmerliche, inkonsistente Imitation davon und andere Sprachen können das gar nicht.

Aber für Kommandozeilenprogramme, sofern sie nicht auf ein Cocoa-Feature angewiesen sind, ist Objective-C nicht das Richtige. Und für Skripte sowieso nicht.

Dann hast Du es nie wirklich versucht oder es ist mir ein völliges Rätsel. Es gibt nichts Simpleres als Objective-C. Keine andere Sprache konnte ich jemals so schnell und mühelos lernen wie diese.
Die ist aufgrund ihrer vielen Möglichkeiten unvermeidlich komplex.
Und damit zwangsläufig minderwertige macOS-Programme erzeugen, die das System verseuchen. Wenn ich der König von Zamunda wäre, würde ich die alle verbieten. So vermeide ich solche Programme zumindest wie der Teufel das Weihwasser.
Das ist doch kein Vorteil! Das ist die Pest in Tüten, weil sie prinzipiell ein fauler Kompromiss ist, der alles an macOS Einzigartige wegnivelliert.

Nur weil jemand Deine Meinung zu Objective-C nicht teilt, wird er nicht gleich polemisch. Und niemand spricht oder schreibt so natürliche Sprache, wie man Objective-C schreibt.

Das war Spott über Objective-C, aber keine Polemik oder Böswilligkeit.

Ich habe zuvor einige eigene Skripte in verschieden Sprachen von ChatGPT ausprobiert*. Nun habe ich tatsächlich aus Neugierde mal sehen wollen, wie das - "wie gesprochene Sprache" - Objective-C aussieht. Also wieder ChatGPT gefragt und die Ergebnisse im Internet überprüft (sogar in XCode dargestellt). Ich habe nun angenommen, dass die Lesbarkeit sich wohl im übertragenen Sinne auf große Programme beziehen muss und das "Hello, World!" daher offensichtlich als Spott verstanden wird.

Immerhin hat mir das jetzt eine Einführung in Objective-C eingebracht

* Beim Testen konnte ich mal besser in Ruby, Python oder AppleScript Variablen übergeben und Ergebnisse verarbeiten. Ich nehme in Zukunft einfach, was funktioniert.

Ich meinte damit doch um Himmels willen nicht marm, sondern die Quelle, die diesen Code als Hello World!-Beispiel für Objective-C anführt.
Natürlich nicht. Aber jeder, der die natürliche Sprache (Englisch) spricht, kann einen großen Teil dessen, was da passiert, auf Anhieb verstehen. Das ist bei anderen Sprachen nicht so.

Wie auch immer, es zeugt jedenfalls von keinem tiefgründigen Verständnis der Sprache, wenn man als Hello World!-Beispiel eine C-Funktion listet, in der Objective-C gar nicht vorkommt (wenn man von der Objective-C-Variante des Strings “Hello World!” absieht, einer Variation, die bei einem fest codierten String allerdings völlig bedeutungslos ist). Ich denke, Deine Links kommen alle von Texten in mehr oder weniger didaktischer Absicht, und didaktisch ist das jedenfalls saudumm, wenn auch technisch korrekt.
Ach, Herr ChatGPT wieder!
Es bezieht sich auch ganz konkret auf einzelne Programmbefehle, wie ich hoffentlich oben veranschaulichen konnte.
Jedes Programm muss bestimmten streng formalisierten Overhead erzeugen, damit das Programm überhaupt vom Betriebssystem gestartet werden kann. Das absolute Minimum ist, dass es konventionsgemäß die Funktion main() gibt, die zum Programmstart vom Betriebssystem aufgerufen wird und der die Parameter der Kommandozeile übergeben werden. Bei Interpreter-Sprachen steckt das im Interpreter und im Skript bekommt man davon überhaupt nichts mit.

Das korrekteste Beispiel ist das mit dem Screenshot von Xcode. Da hast Du die Initialisierung der automatischen Speicherverwaltung zeitgemäß und übersichtlich formuliert mit
Zusammen mit main() und dem Import einer Standardbibliothek (Foundation ist der Nicht-GUI-Teil von Cocoa) ist das alles völlig standardisierter Overhead, der in jedem Programm absolut gleich aussieht, von Xcode automatisch generiert wird und dessen Anzeige man in einer anfängerfreundlichen Variante genauso gut weglassen könnte. Dazwischen, angedeutet durch […], ist dann der eigentliche Programmcode.

Der einzige tatsächlich geschriebene Code ist also NSLog(@"Hallo World!"); und das ist absurderweise eben C und nicht Objective-C. Wie gesagt kann man in jedem Objective-C-Programm auch beliebig C-Code schreiben.

Wenn das eigentliche Beispiel nur aus einer Zeile besteht, bekommt der jedesmal gleiche Overhead natürlich ungebührlich viel Aufmerksamkeit, die er überhaupt nicht verdient. Und wenn die eine Zeile dann nicht mal ein Beispiel für die Sprache ist … 🙄

Ob Spott, Polemik, Böswilligkeit oder schlicht Dummheit, sei mal dahingestellt …