JavaScript-Implementation war ein seit vielen Jahren überfälliger Schritt. Ich hätte eher vermutet, dass sie das Script-Interface generell sterben lassen, nachdem eigentlich alle Versuche in der Vergangenheit (z.B. Automator) nie nennenswerten Erfolg hatten, verglichen mit Software auf Basis „klassischer“ Programmiersprachen.

Ist jetzt länger her, dass ich was mit AS gemacht habe, aber ich erinnere mich mit Grausen an die Versuche, QuarkXpress fernzusteuern:

“Insert new Page at beginning of Document 1“

…erinnert mich fatal an so'nen Unfug wie „Deutsches Basic“ in den 80ern: “mit t von 1 bis 100“

Für Profis war das immer zu doof, und für Anwender immer noch zu schwer. Hohe Bugdichte und ständig wechselnde Kompatibilitätsprobleme war dann der finale Todesstoß. Spätestens seit sich JavaScript für alles möglich durchsetzt, wo „kleine Software“ gebraucht wird, war das definitiv eine sehr gute Entscheidung.

Ich habe nie einen anderen Programmierer getroffen, der schon mal was nennenswertes mit AppleScript gemacht hatte, JavaScript ist hingegen Standard. Selbst Web-Backendler müssen da schon mal was mit schrubben, bevor der Frontendler es dann noch mal richtig macht.

So ist es.

Alles sehr vielversprechend.

Nicht nur das damalige Basic in den 80ern. AppleScript war ebenfalls und ist bis heute so ausgelegt und erlaubt für die Syntax Nicht-Englischsprachigkeit (vorgesehen: Englisch, Französisch, Japanisch; voreingestellte Primärsprache: Englisch), siehe dazu auch diesen Kommentar bzw. diese vom Kommentar referenzierten Apple-Dokumente: (Apple, PDF), (Apple, PDF).

Konnte sich aber nicht wirklich durchsetzen, die Möglichkeit dazu besteht aber bis heute und ist in der AppleScript-Sprache vorgesehen und grundlegend so angelegt.

Sorry, ratti, dem muss ich widersprechen:

a) In AppleScript ist man leider davon abhängig, wie es in den Applikationen umgesetzt wurde.
In QuarkXpress ist das bis heute ein Graus (falsche Resultate, Bereiche wie nicht zugänglich, plötzliche Fehler bei Änderung einer Unterversion) - während es in InDesign problemlos funktioniert. So lassen sich Scripts von CS3 oder zum Teil von CS1 auch noch unter CS6 einsetzen.

b) Die Schreibweise ist vollkommen egal, ob die für manche doof ist, wichtig ist zu wissen, was dabei rauskommt (event log). Und mit ein paar Zeilen kann man elegant Programme miteinander verknüpfen und steuern.

c) Ad Sinnvolles: Mit FileMaker, AppleScript und InDesign oder auch Photoshop lassen sich sehr schnell tolle Lösungen bauen - für mich ist das eines der großen Vorteile am Mac gegenüber Windows Plattform.

lg, karo
karo.at

Das Problem ist nicht (nur) Quark. Das Problem ist schon die Idee: Man könnte Leuten, die eigentlich keine Programmierer sind, möglich nah an Umgangs-Englisch Zugriff auf eigentlich grafische Software geben.

Die Idee ist deswegen dumm, weil die Schwierigkeit ganz woanders liegt. Solange man seinem Quark (Word, InDesign,…) eben nicht „sagen“ kann: „He, Programm, mach bitte in meinem Dokument alle englischen Texte grau, alle Telefonnummern kursiv und alle Überschriften fett“ ist Programmieren eben doch wieder eine „schwierige Sache“, bei der man komplexe Objekte benötigt.

Wie zum Beispiel Reguläre Ausdrücke zum Erkennen von Telefonnummern. Dann ist aber AppleScript auch nicht mehr einfach. Im Gegenteil. „characters a thru b of myZeile as text“ statt substr(myZeile,a,b) treibt gesunden Menschen die Tränen in die Augen. Deswegen gibt es auch keine brauchbare Doku, Community etc.: Die Profis machen so'n Scheiss nicht mit, und die Laien können sich nicht mal eben eine fremde RegExp aus dem Web ergooglen.

Die Adobe-Programme haben aus den von dir genannten Gründen schon lange ein JavaScript-Interface, da habe ich mich immer gefragt, wieso die AppleScript überhaupt erst zusätzlich eingebaut haben.

Es geht mir also nicht um (und gegen) Scriptbarkeit von GUI-Applikation.

Es geht mir darum, dass AppleScript keine gute Sprache ist.
Das Automator nur einen zusätzlichen krepeligen GUI-Layer darüber legt.
Und das JavaScript eine deutlich bessere Wahl dafür ist.

Ich würde mal drauf tippen, dass die Applikation gar nix ändern müssen. Die API ist ja da. Apple muss sie nur an js exponieren, und eine JS-Engine haben sie ja bereits.

Objective-C ist nicht betagt, auch wenn das jetzt alle gebetsmühlenartig wiederholen...

Wenn Dir da das Wort betagt nicht gefällt, dann halt so: aus Apples Sicht bzw. aus der Sicht von Apples diesbzgl. Verantwortlichem (neben Swift auch LLVM- und Clang-Urheber) Chris Lattner zunehmend ungeeignet und unzureichend für das was Apple mit seinen Plattformen in Zukunft vorhat und auf welche Weise man deren Programmierung erleichtern, verbessern, sicherer machen und besser auf moderne Prozessor-Hardware (Stichwort: Multicore-Prozessoren und Parallelverarbeitung) optimieren will, da man auf Basis von Obj-C langfristig wohl nicht so weiterkommt wie es wünschenswert wäre oder auf dieser Basis nicht weitermachen will (weil zu kompliziert, zuviele potentielle Fehlerquellen beinhaltend), sondern lieber einen Neuanfang wagt, der zielführende moderne Ansätze mit deren Vorteilen mit den Vorteilen und Gewohntem des Bisherigen vereint.

Von daher ist der Ausdruck betagt meiner Ansicht nach durchaus nicht irreführend sondern eher zutreffend gewählt weil die Realitäten in Bezug auf die anvisierte Zukunft und die jetzt schon vorliegenden Aufgaben nicht falsch beschreibend. Sonst hätte Apple Obj-C weiter aufgebohrt und um die nötigen Dinge erweitert und hätte mit Swift keinen Neuanfang gemacht bzw. würde auch keine Tipps geben, wie man bestehenden Obj-C-Code gänzlich oder teilweise in Swift-Code überführt (Migrating Your Objective-C Code to Swift ).

Beide Sprachen sollen koexistieren können, doch langfristig betrachtet ist da sicherlich eine Ablösung zu sehen, sollte sich Swift als mindestens ebenbürtig erweisen und dahingehend entwickeln.

Mozilla denkt und handelt ja seit einiger Zeit ähnlich bzgl. deren sehr ähnlicher und auch ähnlich zielender Programmiersprache Rust und baut auf Basis von Rust (zusammen mit Samsung) Mozillas nächste Rendering-Engine Servo, die, wenn sie stabil und leistungsfähig genug ist, eines Tages die seit Jahren eingesetzte Gecko Rendering-Engine ablösen soll.

Bevor hier rattis von phrankster bekräftigter Meinung stehen bleibt, muß ich mal intervenieren und schließe mich karobert deutlich an:

Nur weil ratti mal die Hölle (QuarkXPress zu scripten) kennengelernt hat, ist das NICHT AppleScript. AppleScript ist die schönste und süchtig machende Sprache dieses Planeten. Punkt. Nur darin, selbstredend nur auf dem Mac, kann man seinen Rechner umfassend automatisieren. Und den Automator packe ich nie an, ich entwickle inzwischen nach dem Tod von AppleScript Studio 2005 nur noch im Scripteditor und ich würde gerne mal ratti ein paar umfassende Projekte zeigen. Also von wegen, "Profis trauen sich da nicht ran". Der ganze Kram, der nun wirklich nicht für Laien gedacht und erst recht nicht mal eben nachmachbar ist, wie reguläre Ausdrücke oder Shellscript-Ansteuerung, dazu existiert in AS eine wunderbar geniale Kupplung (do shell script).

AS ist wie die Puppensammlung von Momo: Es gibt keinen Anfang und kein Ende. Mit jedem Programm erweitert sich der Funktionsumfang. Und ja, XPress ist schrott. Aber XPress ist doch eh schon lange tot.
Und was Adobe bei der CS und CC mit dem Script-Umfang getan hat, ist genial. Supersaubere Umsetzung von JavaScript, aber eben auch AppleScript. Inklusive EventListener und Menüeinklinkern.

Ganze Redaktionssysteme setzen darauf.

Intern ist das eine Scriptengine.

Und ratti, nur weil es nicht heißt, string.x, sondern string & x oder eben characters 7 thru 11 (da merkt man übrigens, wie wenig Erfahrung von AS hast: Erfahrene Scripter würden direkt text 7 thru 11 schreiben, dann entfällt eine Typwandlung und das Script läuft deutlich performanter, wenn man Hunderte von Dingen so erstellt), soll die Sprache "zu blöd" sein?

AppleScript ist nur scheinbar leicht zu verstehen, da eben die Schlüsselwörter fast alles englische Begriffe sind. Es gipfelt manchmal liebevoll in "round 3.456 rounding as taught in school", aber dafür hat ObjC auch einen Zahlentyp namens long long -- auch nicht besser.

In Wirklichkeit ist AppleScript manchmal sehr schwer zu schreiben, nur scheinbar leicht zu lesen. Das ist so, daß manchmal ein Datenbegriff direkt zugewiesen werden muß, also set xx of zz to yy, manchmal kann er aber nur über die properties, also set properties of xx to {zz:value} zugewiesen werden. Das ist eben Sache der Entwickler des Zielpogrammes.

Und sierkb, was Du schreibst, ist heutzutage absoluter kalter Kaffee: Deine Dokumente sind von 1994 . Es gibt heute keine anderssprachigen Dialekte mehr. Das war zu OS 8 und 9.

Als Ergänzung noch: Dokus gibt es wie gesagt daher niemals, weil das ein endlos dickes Buch wäre. Aber an fischer-bayern.de, macscripter.net, dougscripts.com und einigen deutschen Cracks sieht man, daß die Szene absolut nicht klein oder was für Laien wäre.

Und manche Dinge sind auch eine Parade für AppleScript, gerade was Stringoperationen angeht. Ein Such-Tausch-Algorithmus ist in AS immer noch am schnellsten arbeitend. Und wenn das nicht reicht, für regex, dann nimmt man eben perl oder sed, awk .. endlos großer Sandkasten.

Wie kommt MTN dazu, immer wieder so etwas zu schreiben? Ich habe mittlerweile von mehreren hochrangigen Apple Engineers die Aussage, dass das weder in naher noch in ferner Zukunft geplant ist, es dazu nicht einmal ernste Überlegungen gibt so etwas zu tun. Mich würde also mal brennend interessieren auf welche offiziellen Aussage diese Behauptung basiert? Wunschdenken von MTN Entwicklern?

Macmissionar:

Das kann ja sein, dass diese Dokumente schon etwas älter sind. Trotzdem sind sie bei Apple noch als gültig referenziert und nicht als ungültig gekennzeichnet. Und nur weil die Praxis sich in der Umsetzung bisher in die Richtung bewegt hat, dass die Englischsprachigkeit für AppleScript sich als de-facto-Standard etabliert hat, heißt das noch lange nicht, dass es nicht auch theoretisch anders ginge und dass die Sprache dazu im Inneren dazu ausgelegt ist, anderssprachig zu schreiben, wenn man denn wollte bzw. es tun wollte. Die Sprache gibt das her, und ich sehe nirgendwo einen Hinweis darauf, dass diese grundsätzliche Eigenschaft und Möglichkeit abhandengekommen sein sollte und nicht auch heute noch möglich wäre. Denn wäre dem so, wären diesen Dokumente bei Apple mit Sicherheit nicht mehr an erster Stelle referenziert und oben im Kopf ganz dick als veraltet und nicht mehr zutreffend deklariert worden und durch neuere ersetzt worden, in denen das nicht mehr drinsteht.

Mecki:

Du zitierst falsch bzw. legst falsch in den Mund. MTN hat das nicht geschrieben, sondern ich.

Zu Deiner Frage: Lies einfach mal das, was Apple dazu in seinen aktuellen Developer-Dokumenten schreibt und durchblicken lässt und lies einfach mal das, was Chris Lattner, der Urheber und Autor des Ganzen und seit einer ganzen Weile Apples Haupt- und Rundum-Verantwortlicher für die gesamte Developer-Sparte dazu bisher schreibt bzw. durchblicken lässt.

+1
Das stimmt schlicht nicht:

Objective-C kann schon deshalb nicht unzureichend sein, weil die Runtime von Swift und Objective-C schließlich dieselbe ist.

Da es aber bis heute offenbar das Auffassungsvermögen vieler Programmierer, die von anderen Sprachen kommen, übersteigt zu begreifen, wie Objective-C eckige Klammern einsetzt, gibt es jetzt halt für Leute, die Dot-Syntax für das Maß der Dinge halten, eine Alternative, denn Apple will nach wie vor seine Programmiererbasis verbreitern, klar.
Wenn es nur so wäre Ist es aber nicht:

• Die selbstdokumentierende Klarheit von Objective-C ist, wenn nicht verloren, so doch erheblich eingeschränkt.
• Swift verwendet so viele „Komfort-Abkürzungen“, dass das Verständnis dafür, was gerade tatsächlich passiert, allzu leicht verloren gehen kann (Perl anyone?). Tut dann weh, wenn etwas nicht funktioniert, wie es soll.
• (Markanter Spezialfall des vorigen Punktes) Die Swift-Syntax verwischt den Unterschied zwischen Funktionen und Messages und damit das OO-Paradigma – aua!
• Die problemlose Kombination mit C und C++ entfällt.
• Swift kann nichts, was Objective-C nicht auch könnte (logisch – selbe Runtime)

Weia:

, ,


Und zu : Noch nicht. Alle Zeichen zeigen, was die langfristige Perspektive angeht, da aber hin, und natürlich formuliert er da für den jetzigen Moment vorsichtig und zurückhaltend, um nicht noch mehr Pferde scheu zu machen als es derzeit ohnehin schon sind. Ähnlich einem Politiker, der sich, daraufhin angesprochen, in Bezug auf Steuererhöhungen, Maut, Rente oder dergleichen heiße Themen auch erstmal für den Moment vorsichtig ausdrückt und besänftigende Worte findet was den status quo angeht, obwohl es die Spatzen von den Dächern pfeifen, dass langfristig gesehen es wohl keinen Weg daran vorbei geben wird.

Gleichzeitig sagen er und auch Apples bisher veröffentlichten Informationen und Dokumente eindeutig aus, dass man da für die Zukunft Größeres und Großartiges vorhabe und Apple bzgl. Swift einen neuen Schwerpunkt setze, neue "Duftmarken" in puncto Programmierung in der Zukunft setzen wolle. Und das klingt, wenn man einmal subsummiert eindeutig nach einer Schwerpunktverlagerung aus. Mehr zugunsten von Swift und eher zulasten von Objective-C. Wäre es anders, hätte man sich Swift sicher gespart. Swift hat einen Grund. Und der hat mehr mit neuen Paradigmen, die an eine heutige Programmiersprache gestellt werden und der dann aufgrund der teilweise doch komplizierten und nicht gerade eingängigen Syntax doch vergleichbar geringen Attraktivität für Entwickler zu tun und weniger damit, dass man da jetzt einfach "just for fun" eine neue Spielwiese eröffne. "Just for fun" macht Apple das nicht. Da steckt ganz sicher eine Strategie dahinter – eine langfristige, eine in die Zukunft schauende.

Siehe dazu auch die eingehenden Worte im aktuellen TIOBE-Index, die das aktuelle Thema grad' aufgreifen: . Sie bestätigen in Kurzfassung das, was der arstechnica-Artikel auch schon sagt.

Auch werden von einigen Vergleiche mit Scala laut, da scheint es große Ähnlichkeiten der beiden Sprachen zu geben: , .

Ohne Grund macht Apple das alles nicht. Wäre das aus der NeXT-Ära stammende und auf diese Plattform hin ausgerichtete (die Klassen-Namen zeugen ja von heute noch davon) Objective-C für Apple noch das unangefochtene Nonplusultra, hätten sie nicht Swift ins Leben gerufen. Sondern Objective-C selber einem Wandel unterworfen und den gewünschten Gegebenheiten angepasst – und sei es lediglich in Form einer einfacheren und weniger abschreckenderen Syntax, einem "Objective-C Light" meinetwegen. Hat Apple aber nicht getan. Sondern Swift ins Leben gerufen.

Apple formuliert es aber so in seinen veröffentlichten Dokumenten. Soll man das jetzt abstreiten und sagen, Apple behaupte was Falsches?

Ja, kenne ich natürlich alles. Und?
Klar. Hatte die Java-Objective-C Bridge 2000 auch.
Sorry, aber durch Wiederholen wird das nicht richtiger. Was soll eingängiger sein als eine Methoden-Syntax, die ihren Inhalt sprachlich lesbar selbst dokumentiert?
Nö, sondern wegen dem endlosen Lamentieren von Leuten, die behaupten, Objective-C hätte eine „nicht gerade eingängige Syntax“.
Da steht genau das drin, was ich auch sage: die ganzen iOS-Kiddies raffen Objective-C nicht, also hat Apple nach einer Alternative geguckt.
Arstechnica ist in vielen Bereichen sehr kompetent; Objektive-C gehört leider nicht dazu. Die Behauptung, Objektive-C könne keine Generics und die Wertung, Pointer seien ein Problem, sagen mir genug …

In vielen Worten einmal mehr die geistige Inflexibilität eines Programmierers, der zu sehr von anderen Sprachen geprägt ist.
Nein, natürlich nicht. So etwas würde Apples PR-Abteilung nie tun

Hier muss ich mich korrigieren; ich hatte schlicht übersehen, dass der Artikel mehrere Seiten hat und auf Seite 1 zu lesen aufgehört (ich gebe mal den 30°C im Schatten die Schuld )

Die beiden folgenden Seiten sind in der Tat profunder, geben mir aus meiner Sicht aber wiederum recht:

Lesbarkeit (fette Hervorhebung von mir):

Klare Semantik:

Die IMHO einzige Sache, die in Swift besser als in Objektive-C ist, Kategorien, erwähnt der Artikel auch:

Aus meiner Sicht ist das unter dem Strich ein vernichtendes Urteil. Die Zielgruppe ist auch klar: Leute, die so wenig vom Programmieren verstehen, dass sie alle möglichen Basis-Fehler machen würden, die Swift schlicht verhindert. Und die nicht wirklich verstehen, was sie da eigentlich tun. Swift „abstrahiert“ quasi von einem notwendigen Verständnis und kommt so dieser Gruppe entgegen. Für simple Apps ist das alles prima, solange es funktioniert. Falls nicht, dann wird’s heikel …

Benchmarks gefällig?

Ja, das kommt noch hinzu …

Wobei man da natürlich sagen könnte, das wird hoffentlich besser im Laufe der Zeit.

Aber ich würde jede Wette eingehen, dass z.B. Logic Pro X auch in 10 Jahren noch unter Objective-C (und intern viel C++) läuft …

Ohgott. Da kannst Du Punkte-dahinter-machen, wie Du willst, mit sowas:

…bist Du kein Profi.

Wir delegieren einen Regulären Ausdruck an den Kommandointerpreter einer ganz anderen Sprache, die diese Parameter dann per Stdin an ein nachzuladendes Binary übergibt?
Welches dann in einer Schleife vielleicht ein paar tausend mal gestartet wird?
Um Sachen zu realisieren, die ein Taschenrechner beherrscht?

Ehrlich. Was für ein grober Unfug.

Du kriegst damit Sachen zum Laufen, das ist schön und gut. Wenn es rennt (bzw: kriecht) und dabei seine Brötchen verdient, fragt hinterher keiner mehr, ob die Lottozahlen mit einem Commodore 64 in BASIC ermittelt wurden. Alles prima. Geschenkt.

Aber AppleScript fehlt eigentlich alles, was eine Programmiersprache ausmacht, es bewegt sich in seiner Mächtigkeit ungefähr auf der Ebene eines Homecomputers der 80er Jahre. Das sieht man ja dann auch: Bei TIOBE rangiert es unter den Sprachen, die sie zwar messen, die aber kaum messbar sind. Niemand wird sich hinstellen und echte Software mit AS entwicklen. Genau dahin geht JavaScript aber immer mehr.

Du scheinst da mit deinen „scriptgesteuerten Redaktionssystemen“ auch was zu verwechseln: Dass eine Applikation ein Apple-Events-Interface hat, heisst nicht, dass man den auch nur in AppleScript ansteuern könnte. Wenn Du in Finder.app eine Datei doppelklickst, schickt der einen open-Event an sagenwirmal TextEdit.app, ohne dass ein AppleScript beteiligt wäre. Genau dieses Interface wird man in Zukunft auch mit JS nutzen können.

Hinter JS steht aber ein riesiges Ökosystem mit professionellen Tools.

Also ich habe grad einen ganzen Arbeitsablauf automatisiert, Und das auch noch mit dem Automator. Ist alles drin: Shell-Scripte, zusätzliche AppleScripte, etc. Geht wunderbar. Es kommt halt auf dem Zweck an.

ratti. Hochmut kommt vor dem Fall.Wir laden Bibliotheken in anderen Sprachen, da es im Standardumfang nich vorhanden ist? Ist das performanter oder besser?
Drück es ruhig noch gestelzter aus oder führ Dich noch dramatischer auf, ist nicht nur mir schnuppe: Dinge, die ein Taschenrechner beherrscht, die kann auch AppleScript. Und wenn man eben was braucht, was nicht da ist, gibt es entweder OSAXe oder das von mir bevorzugte immer mögliche shell script.

Und wenn Du über die Shell an sich lachst, dann ist das Deine Sache. Ich interagiere, wenn nötig mit der Shell. Und ich brauche auch keine Kupplungsschleifen, sondern kann falls nötig die Shellschleifen verwenden, also do .. if .. fi .. done usw.

Und ich habe bereits echte Software mit AS realisiert, zu genüge. Leute, die sich über Programmiersprachen lustig machen, sind meist frustrierte Leute mit wenig Lust zum Neulernen ihrer alten Pascal-Unisprachen.

Und wenn Du keine Redaktionssysteme kennst, die sich als Event Listener in Satzsysteme einklinken, dann ist das nicht schlimm. Aber Du brauchst nicht was vom Doppelklick zu faseln. Und ein AppleEvent ist nichts anderes, was unter anderem _durch_ AppleScript ausgelöst werden kann.

Im Übrigen hat OS X schon länger eine Open Script Architecture, und ob da nun AS oder JS verwendet wird, ist erstmal zweitrangig. Das macht JS nicht mächtiger oder hebt es über den Lauch, den Du hier beschreibst.

Macmissionar
Niemand sagt etwas gegen die Shell oder gar AppleEvents – die sind unverzichtbar.

Was wirklich absolut grausam ist (aus den von ratti genannten Gründen) ist AppleScript die „Sprache“ (wenn man so eine Kopfgeburt überhaupt so nennen kann).
Ist es nicht: im einen Fall (AS) kriege ich Schreikrämpfe, im anderen kann ich einfach arbeiten.

(Und ja, ich spreche viele, viele Programmiersprachen – Pascal allerdings nicht. )

Ja, AppleScript bringt mich auch immer zum Verzweifeln. Leicht zu lesen, schwer zu schreiben. So geht es mir jedenfalls. Aber trotzdem: Es sit und bleibt eine prima Sache, die seinesgleichen sucht.

Und exakt das ist der Punkt: Man kann sich damit gut Kleinkram zurechtscripten. So, wie man sich im technischen Umfeld halt mal was in der Bash o.ä. zusammenstrickt, was dann teilweise jahrelang gut werkelt.

Das geht seit längerem irgenwie mit AppleScript, und es wird in Zukunft mit JavaScript noch sehr viel besser gehen. Alles super. Little helpers.

Unter „echtem programmieren“ verstehe ich aber dann doch mehr, als in AppleScript (oder Bash) möglich ist. Als Mindestmaß sei mal so in den Raum gestellt, dass man ein Vererbungsmodell hat, Objekte, Autoloader, Namespaces… also so Sachen wie sie sagenwirmal in perl, php, ruby etc. selbstverständlich sind.

Dazu würde ich wollen, dass das nicht nur auf dem Papier möglich wäre, sondern defacto auch ein entsprechendes Ökosystem existiert wie sagenwirmal CPAN für perl, wo ich dann auch mal eben Code andocken kann, der …mir die Geoinformationen aus einem JPG holt, oder den Fontnamen aus einer nicht installierten OTF-Datei, oder… …so Zeug halt. Wahrscheinlich wird mir jetzt jemand einen Einzeiler um die Ohren hauen, der beginnt mit „tell Application Preview.app“, aber eben darum geht es auch, dass man grundlegende Dinge /ohne/ Preview.app, shell binaries etc. machen kann, weil es Libraries dafür gibt.

Solange ein solches Ökosystem nicht existiert, nimmt der Viertelprofi und aufwärts davon eben doch lieber die Hochsprache, mit der er „normalerweise“ was schrubbt.

Warum? Was sollte sich außer der Syntax ändern? Wäre natürlich super, wenn mehr Programme dann eine Schnittstelle hätten. Aber das würde jetzt schon Problemlos gehen.
AppleScript hat rein gar nichts mit "echtem" Programmieren zu tun. Das macht es jedoch in keiner Weise schlechter.
Du hast schon verstanden, was AppleScript genau ist? Es ist der Hammer um Nägel reinzuschlagen. aber nicht der Schraubendreher um Schrauben reinzuschrauben. Oder lebst Du nach dem Motto: "Der Meister kannst kaum glauben, man kann auch mit dem Hammer schrauben!"?

Ich würde mir bei meinem Job wünschen, ich hätte sowas. Statt dessen muß ich manche Dinge aus einem Konglomerat aus AutoIT, VB.net, WSH-Scripting, Batch, etc. lösen.

Ein deutlich größerer Spachumfang, eine riesige aktive Community, gigantische Mengen an existierendem Code.


Wieso?
Doch.
Wenn man weniger Möglichkeiten hat, ist das natürlich …weniger. Also schlechter.


Gah. Was hat das denn mit „nicht verstanden“ zu tun? Natürlich habe Ich AppleScript verstanden, ich habe selbst Sachen darin gebaut, und es ist mir einfach zu wenig. Ein paar „dumme“ Kontrollstrukturen, und alles andere muss man sich vom Leistungsumfang irgendwelcher Applikationen holen.

Jetzt bekommen wir eine deutlich mächtigere Werkzeugkiste. Das ist zwar immer noch kein vollgepackter Handwerkerbus mit Werkzeugen, aber es ist eben auch nciht mehr nur der Hammer, sondern auch Schraubendreher, Zange, Lötkolben und Säge.Und im Gegensatz zu AppleScript passt es auch zu europäischen Schrauben nach DIN-Norm.

Nochmal:
Es geht in keinster Weise irgendwie gegen die Idee, GUI-Apps ein Eventmodell zu verpassen und sie „von draussen“ zu steuern. Das ist eine großartige Idee und ein Superfeature! Apple kann auch nix dafür, wenn einzelne Hersteller das schlecht umsetzen.

Es geht einzig und allein darum, dass die Sprache, die diese Events SENDET, ein Haufen Rotz ist. Obwohl es da draussen für lau und unter GPL/BSD/Apache/Whatever-Lizenz stehende Interpreter für Ruby, Perl, Php, gibt. Und eben JavaScript.

Und sorry — wer sich Ruby mal anguckt, der wird sich von AppleScript mit Grausen abwenden. Das ist im übrigen auch kein Apple-Bashing. So'n Zeug haben wir in den 90ern nun mal verwendet. Jetzt ist aber 2014, und das sieht man AS einfach nicht an.

Was das Windows-Gekröse angeht: Kann ich nix zu sagen, ich verstehe nichts von Windows. Schlimmer geht halt immer.