8 ms·

AppleScript (2006) [pdf]

69 points by salgernon 5y ago

bouvin 5y ago
AppleScript is not much of a general purpose programming language (the syntax certainly takes a while to get used to), but for automating stuff, sorting files into folders, and the like, it is a nice tool. I have scripts that are indispensable to me, and combined with Folder Actions it ensures that there are things that Just Work.
serverlessmom 5y ago
I didn't realize AppleScript was still a thing, but here it is: https://developer.apple.com/library/archive/documentation/AppleScript/Conceptual/AppleScriptLangGuide/introduction/ASLR_intro.html https://developer.apple.com/library/archive/documentation/Ap...
bobbylarrybobby 5y ago
As terrible as AppleScript is as a language, it's really nice that Apple even built a framework for apps to use to expose their functionality to external scripts -- I'm not sure today's Apple would have gone to the trouble. And now that you can use JavaScript instead of AppleScript, with a more or less standard way of translating calls between the two, scripting+automating macOS is really painless. I do wonder why the Shortcuts app seems to be reinventing the wheel. You'd think the functionality an app exposed to AppleScript would've been automatically made available in Shortcuts, with Shortcuts being more or less a block-based interface to the same scripting environment that AppleScript uses, but that doesn't seem to be the case. Kind of an odd choice to not build off their existing work there.
- crooked-v 5y ago
  > I do wonder why the Shortcuts app seems to be reinventing the wheel. Shortcuts is cross-platform, and so designed from the ground up to work sanely under the limitations of both macOS and iOS.
  - mmerickel 5y ago
    I have plenty of shortcuts that work on iOS but don't work on macOS. It's fun when you use siri on the mac and it tells you it can't do something halfway through.
- fiddlerwoaroof 5y ago
  It’s also relatively easy to use the Scripting Bridge from any language that can integrate with the objective-c runtime. I’ve written a bunch of Mac automation in Common Lisp
- alwillis 5y ago
  I had to automate transforming some Excel data for a friend recently and I did it using AppleScript. Turns out it’s not as bad as the prevailing HN narrative. It does require a change in mindset but once you get there, it’s actually quite nice, especially when using an app with a nicely designed dictionary. Like a lot of Apple’s technology from the 90’s, it was a technology before its time. It certainly was pretty important during Apple’s near death experience in the late 90’s due to the publishing workflows that could only be done (at that time) using AppleScript and Quark XPress, etc.
  - fzumstein 5y ago
    Have a look at xlwings (I am the creator), it’s a Python wrapper around AppleScript that follows closely the original VBA object model, so won’t require a change in mindset.
    - hhas02 5y ago
      Hi Felix! Sorry I’m a jerk who never responds to PRs, although I know py3-appscript* is in its best hands with you so just keep rolling as you see fit. (*I am currently dragging nodeautomation back up to operational status so I can use it in new customer work, but that’s as much appscript-ing as my poor brain can cope with now.)
      - fzumstein 5y ago
        Hey has! I should have mentioned that xlwings is a wrapper around your excellent appscript package that does all the heavy lifting with AppleScript :) Thanks for reviving the project on GitHub :)
        hhas02 5y ago
        “I should have mentioned” Not at all. Results are what matters, not the technical gubbins under the hood. I’m happy appscript helps you to empower your users.
- jhbadger 5y ago
  It's a "terrible language" in that it doesn't resemble most languages currently in use, but it resembles Hypercard's language Hypertalk a lot, so at the time it was created, this was a good idea. Hypercard/Hypertalk made GUI programming possible for non-technical people in a way that has not been possible since.
- tinus_hn 5y ago
  > I do wonder why the Shortcuts app seems to be reinventing the wheel. The Shortcuts app is a third party app bought by Apple.
- radicality 5y ago
  The other day I wanted to do something seemingly simple with Shortcuts - set my screen and my 3 external displays brightness to 100%. I saw an action to set screen brightness, but figuring out how to apply it to a specific display is an exercise left to the reader ugh. Shortcuts so far seems like a very unpolished product. Do you know if something like this is easily doable in AppleScript (and whether it’s even worth it vs writing these kinds of things in swift with apple libraries)
  - bobbylarrybobby 5y ago
    https://apple.stackexchange.com/a/285907 https://apple.stackexchange.com/a/285907
- hhas02 5y ago
  “And now that you can use JavaScript instead of AppleScript” You really can’t. JXA is garbage, crippled, incompetent, and long since abandoned to pine for the fjords. Its only actual function is to impede any re-development of ES6 as a useful scripting platform within Apple, and probably hinders 3rd-party alternatives such as Scriptable and ScriptKit, because what 3rd-party dev wants to be pre-emptively Sherlocked by garbage like that? Apple abandoned AppleScript and AppleEvent-based automation after they gave the Mac Automation team multiple opportunities to make it successful—and they failed every one. Thus Apple fairly concludes it is a failed product on a legacy platform, ceases work on it because what’s the point on throwing more good money after bad, and looks elsewere for something new and more promising to try next. Hence Shortcuts, which started out as a 3rd-party iOS app, Workflow. As a technology it is at best mediocre; as a polished, well-presented, and properly-sold product it was already moving up on iOS with positive customer response. Instantly far more promising than the inept, lethargic, and generally couldn’t-sell-icecones-in-a-desert Mac Automation team, where the critical failure was never the technology itself but purely PEBKAC; but an organization the size of Apple doesn’t care about that distinction, only about its results. Thus, not too long after finally shitcanning the Mac Automation team in 2016, Apple bought up @WorkflowHQ outright, and have been positioning Shortcuts, née Workflow, for its true purpose: to provide their Siri UI with a reasonably granular, accessible, plugin backend so that Siri can actually make itself useful. … Lesson here for y’all: It does not matter one whit how good (or not) your technology is. (Apple themselves taught me that.) What matters is how good you are at selling product, i.e. putting bums on seats, and keeping them there. That’s why AppleEvent technology (which is in many ways far superior) now rots in history’s dustbin, while Apple gives the [Siri-backed and Siri-backing] Shortcuts its opportunity to prove itself a successful product and future of Apple Automation. Could a successful merging of the two produce a product 100× better? Sure. But if you’re asking that and not understanding why most likely won’t/can’t happen, you’re not understanding how successful big business works. My personal work (github.com/hhas/) testifies to hard lessons learned. (Though if you wish to have a crack, fill your boots. Perhaps you’ll do a better job n’me.)
olliej 5y ago
I implemented quick sort in AppleScript many years ago (to see if I could, not because this is a good idea), and it was excruciating. Very much the epitome of read only code :D
- jtbayly 5y ago
  I wrote a fair bit of AppleScript. It always seemed like my code was right, but it was wrong just as often as any other programming language I use. It was just as inflexible and demanding. That was frustrating, since reading it made it look like it was easy and it didn't care how you wrote it. But anyway, at least you could read the program and understand it afterwards, whether you wrote it or not, whether you understood all the things that had to be just so or not.
lostgame 5y ago
AppleScript might be one of the single most bizarre and arduous-to-write-in mainstream scripting/coding languages in history. I can’t say I’m a fan of such a literal interpretation of writing code. That being said, before I got a solid grasp on Obj-C and the (at the time) OSX APIs like CoreImage, etc; it got me started on writing Mac applications whereas otherwise I’d have had a much rougher time with it. Back when I’d made the switch from Windows to OSX in 2005 or so, I had written an AppleScript and accompanying Xcode app to auto-align desktop icons to the left, such as on the Windows desktop, as it drove me nuts that they auto-aligned to the right. (Now I prefer the right, lol…)
pie_flavor 5y ago
I lament the modern dearth of natural-language scripts designed for normal people who have slightly higher engineering instinct than average but otherwise just want to use their computer. Different people notice the usefulness of such things in different places, but for me it was Minecraft server administration. You have thirteen year olds doing a 'banging on the keyboard' level of management for game servers for eleven year olds, and who do not know the first thing about programming and would take years to get up and running with Java, but who have added to the server dozens of commands and idiosyncratic game mechanics with Skript, because Skript's language is so fundamentally easy and approachable that just about anyone could make just about anything in it that they could conceptualize of the details for. I really don't think AppleScript's primary application has vanished like many people seem to think it has. Desktop software may be on the decline, but that just means that something equivalent for web needs to exist. Every other day you hear about a business that had some major component, which finally broke, being a giant kludge of an Excel sheet. Those things don't start because they're the best tool for the job, they start because Excel's approachable for non-programmers who can figure out how to make an algorithm work as long as you don't call it an algorithm or force them to start with stdio. Flash had that property too, and the Internet is the lesser for its disappearance; it took so little effort for an animation to be turned into a game that so many animators decided to try. Nobody ever bothers making things like that anymore because everyone's internalized this idea that anything like programming is as hard and as not worth targeting towards normal people as general programming. I don't know how to end rants.
- pjot 5y ago
  I see it similar to self-selection. Those interested will dig into the OS, then find Automator, then find Apple Script, notice similarities to Minecraft servers, and ultimately choose their own adventure. I wonder though, if these features were more forward, how would that shape what the “typical” user discovers? As Bradbury-esque as that may sound…
- imglorp 5y ago
  AS failed at natural language though. The experience is exactly programming with more keywords. There's still a rigid grammar and keywords have precise meanings. You still have to look up what keywords are available, what contexts to use them, what arguments they want, etc etc. It's programming. Harder even. Ideally there's a bunch of real conversational NLP with common sense and context. This is really what you want: find my firefox window move it to the second workspace on that desktop make slack to be the top window close all finder windows we're not there yet
leodriesch 5y ago
I’ve recently wrote some AppleScript for some window management and as someone with more experience with C-style languages I find it’s syntax deeply confusing. It was more of a trial and error thing than anything else, tutorials online worked more or less. I see that it is incredibly easy to read, also for non-programmers, but I find it really hard to write, at least as someone that is not very into it.
udbhavs 5y ago
See also: Hyperscript (https://www.hyperscript.org https://www.hyperscript.org)
lopis 5y ago
Does this still exist? And is it actually "widely used" by any MacOS apps?
- duskwuff 5y ago
  Still exists, but support in modern macOS apps is pretty spotty. One app which does have surprisingly good AppleScript support is Music, which exposes the library as a fully featured OSA collection: tell application "Music" play (some track whose genre is "Rock" and duration < 240) end tell Unfortunately, the scripting dictionary is kind of old, and doesn't fully expose some newer features like "Up Next".
  - ihuman 5y ago
    I'm surprised, since the dictionary has some apple music and icloud music library functionality. I expected it to expose "up next" as another type of playlist. I'm not sure if the same on desktop, but the iOS version of music allows you to control whats up next using Shortcuts. On the mac, you can control shortcuts with applescript using "Shortcuts Events", and shortcuts can run applescript. https://sixcolors.com/post/2022/01/shortcuts-applescript-terminal-working-around-automation-roadblocks/ https://sixcolors.com/post/2022/01/shortcuts-applescript-ter...
russellbeattie 5y ago
Apple desperately needs to kill AppleScript. Every year or so for the past decade, I run into a problem and think, "Oh, I'll try AppleScript" and as the saying goes, it rarely ends well. [1] We NEED the functionality of desktop apps and services exposing scriptable objects and methods. We do NOT need a "human language based scripting language". Programming in Python, Java and JavaScript have been taught at all levels of school for many years now, with countless resources online. Anyone who would ever have an interest in scripting their computer - the so-called Power Users - already have been exposed to traditional programming languages at some point in their lives and don't need or want to use a "simplified" language. So not only is AppleScript a bewildering, barely documented, Through-the-Looking-Glass version of a programming language ("‘How do you know that I’m mad?’ said Alice. ‘You must be,’ said the Cat, ‘or you wouldn’t have come here.’”), but the impetus for using such a language has totally disappeared, even if it wasn't an unusable mess designed by autists on LSD. 1. https://www.russellbeattie.com/blog/fun-with-the-os-x-finder-and-applescript https://www.russellbeattie.com/blog/fun-with-the-os-x-finder...
- ihuman 5y ago
  You can use Javascript [0] or Objective-C (via ScriptingBridge) instead of Applescript. Any language that can bridge to Objective-C (like Swift, Python, or Ruby) can also use ScriptingBridge. [0] https://developer.apple.com/library/archive/releasenotes/InterapplicationCommunication/RN-JavaScriptForAutomation/Articles/Introduction.html https://developer.apple.com/library/archive/releasenotes/Int...
  - russellbeattie 5y ago
    First of all, support and documentation is virtually non-existent for any of those options. Have you tried to use JS alone to automate anything? Eventually you'll end up on the GitHub wiki like the rest of us, trying to convert 15 year old AppleScript examples into JS. It's a nightmare. This is related my point that AppleScript is an an anachronism. Apple must know that as well and don't want to spend any resources on the problem. So it's just sort of stuck.
dnljrz 5y ago
I remember showing my friend a few tricks with AppleScript when he started working as a genius. Apparently his manager got mad at him after a customer had complained about him writing a script as they thought he was "hacking" them. Turns out the manager had no idea what AppleScript was too.
gcanyon 5y ago
It’s important to distinguish Apple script the language from the dictionaries of events that apps support. The language is fine. It’s a little different, and there are many features from modern languages like Python that it could use. But the main issue is not the language, but the event dictionaries exposed by applications. I once spent most of a day finding out that a “page” was not an element of a “document”, but a “spread” was, and a “page” was an element of a “spread”. That might have been in adobe pagemaker. When the dictionary is clear, everything is fine. When it’s opaque, that’s when things get sticky. To be clear, AppleScript and app dictionaries are awesome — just someone’s also painful.
regus 5y ago
I like the idea of AppleScript, but every, single, time, I try to use it I walk away frustrated. I can never accomplish the goal I set out to do. Instead I end up wasting hours and hours fiddling around with this language. The syntax is just odd, since it has this conversational style ("tell app to do this") I constantly fall into the trap of trying to write out something that I think should work, but it does not. This happens all the time. The other day I wanted to automate something on my new M1 Mac. SURPRISE! The latest version of the app I was trying to use no longer supports Apple Script! Trying to automate stuff on Mac is so frustrating. Don't even get me started on Automator! I tried playing around with the new Shortcuts app, but that thing is also difficult.
alazoral 5y ago
A lot of open source software gains automatic trust by virtue of the fact you could check it out, read the source, and compile it yourself. This possibility stands in for the fact that you probably can't - you probably can't actually read the code, and if you could you can't possibly understand all the edge cases and implications, and you definitely don't have time, especially if you are to recurse into its dependency tree. So for scripting, where you give a random piece of code access to your entire digital life, a language that is hard to write for even experienced developers but is easy to read and fully understand what is going to happen when they run it, for anyone who could read its licence agreement, is an inspired choice. It should be very hard to make software that could hurt people. It should be obvious, to as many people as possible, when software could hurt people. If we all prioritised user safety over developer comfort we would have a very different industry.
CPLX 5y ago
Back in 2007 or so I wrote an AppleScript that would iterate through every email I had ever sent or received, find every properly formed email address, go to the Facebook website, and attempt to add that person as my friend. At the time I was a publicist in the entertainment business so this was a lot of people. Was a fun way to kill an afternoon, and I still have about 5,000 “friends” on Facebook, many of whom I don’t know super well. So I’ve got that going for me. AppleScript was cool.
hhas02 5y ago
Cook’s HOPL3 paper on the early history and motivations of AppleScript is a great read, full of insight and ambition, and it is a damn shame that early 90s Apple management pissed off Cook and Harris into walking out the door, effectively taking with them all of the institutional knowledge and experience that—after a few more rounds—could’ve made Mac Automation into a true game changer. I will also put this here: https://www.youtube.com/watch?v=1MaHJ_mzrTU https://www.youtube.com/watch?v=1MaHJ_mzrTU As presentations go, it not the best sales pitch; and it lacks the depth of the paper (which was written much later), but it’s just a joy to see two young UX innovators genuinely psyched and evangelizing their work. Sadly Warren Harris passed, still young, a few years back; and William Cook late last year. Which probably leaves me as the last person who truly understands that work, and what it tried to achieve. (And still could, in the right hands, although I doubt those hands existin in Apple any more.)
hhas02 5y ago
I will also leave these here: appscript.sourceforge.net sourceforge.net/projects/appscript/files github.com/hhas/SwiftAutomation www.npmjs.com/package/nodeautomation (The nodeautomation bridge on npm is broken due to bitrot in NodObjC; there’s an active fork on my github which works, albeit slowly RN, as I bring it back into operation for new customer work.) … Python appscript was, and arguably still is, the single best piece of software I ever wrote. And it wiped the floor with AppleScript. To the scripters and programmers who used it, it was a revelation: 99.9% as good as AppleScript for automating Mac apps, in a language they already know and love. Protip: Nothing in AppleScript makes sense except in light of relational queries. Appscript was the first time anyone explained honestly to Mac OS X devs how Apple event automation actually works. Application Automation is not OOP (despite its misleading jargon and superficial appearance). It’s RPC plus simple first-class queries. It’s most closely related to SQL and RDBMSes—except whereas SQL talks to a handful of virtually identical apps all doing the same thing, here’s a system that talks to hundreds of wildly heterogenous apps; and in a way that is, in principle, accessible to everyone from expert programmers to end users. Once you know that, all the bafflement and confusion caused by the mismatch between you you think it works and what you see it actually doing evaporates. And not only is it clear, it is also logical and elegant AF. A really nice, thought-out, very-high-level UI/UX; a programmatic peer—and equal—to the Mac GUI. Instant, irresistable catnip for geeks. Today it should have a technical audience millions strong, powering the heart and userlands of every Apple OS. … The first version of appscript (2003–2004) was a failure. It took years for me to fully understand the implications of “Not Object-Oriented, Query-Driven”. By the time Dr Cook was presenting his AppleScript paper at HOPL3, I had eventually figured it out for myself; even so, reading that paper a while later was hugely enlightening and confirmed I finally had a Mental Model that Is Not Wrong. I owe Cook and Harris a debt of gratitude for their work that am still grinding away to pay off. Anyway… Back in 2006/2007, Apple approached me expressing an interest in including Python and Ruby appscript in Mac OS X Leopard. Alas, due to my non-existent sales skills and the then-Mac Automation team’s terminal (literally) Not Invented Here Syndrome, that opportunity was lost. Apple shipped its garbage ScriptingBridge.framework, which immediately failed and sunk with barely a trace. (Yes, I was a dunce; but at least I wasn’t the dunce being paid six figures at Apple to utterly feck things up. That was Sal Soghoian’s job.) By time 2012 rolled around, the bottom had dropped out the Mac Automation market and it was clear it was on its way out. That year I predicted AppleScript would be done within the next 5–10. When JXA was surprise-announced at WWDC14 (no doubt pissing off the JavaScriptCore team after revealing their own alternative to AppleScript at WWDC13), I realized this was a unique opportunity to turn things around. The JavaScriptOSA component at the second line, I wrote in less than a month and sent it to the Mac Automation team to learn from/steal however they liked. I even had the book outline for “Learn JavaScript for Automation” worked out, and good chance of getting Apress to publish it. I’d have done all the community building and support—everything needed to make JXA successful, because I adore what Mac Automation technology has empowered me to do as both an end user and as professional developer. I was desperate to see that power shared with other users, so those users could empower themselves too—even as the Zucks and the rest were doing their damndest to lock all us in their gilded cages and nice little dependent revenue streams for themselves. I gave Soghoian six weeks of world-expert consultancy in the runup to JXA’s release, and in return for all that he ghosted me with not even a “Thanks, but no thanks” for working my ass off to make him successful. Probably cos I was telling his work was crap—and how to fix it within weeks to be awesome—and not how the sun was shining out of his ass. Mr Jazz-Ego, ladies and gentlemen. At least I had the sense to write off my losses and run. … There is a coda: Not too long after JXA immediately failed and sank without trace exactly the same as ScriptingBridge did 8 years before, Apple’s new Swift language was starting to rocket as the Hot New Platform in macOS development. And because I’m a glutton for self-inflicted pain, I wrote SwiftAutomation.framework for it, and then wrote Sal Soghoian offering to give it to his team outright. Simply tie it onto Swift’s coattails and ride that Swift rocket to mass market success. Sal Soghoian, a natuarl charmer who for 20 years sat in the front seat row to the greatest Marketing and Sales Masterclass of a generation, arrogantly blew me off threw that third-and-final chance for success straight back in my face. And in return for that, I wrote a no-holds-barred email explaining to him exactly how his incompetence and failure to learn had driven Mac Automation right into the ground. And just over a year later, Apple management, facing their first flat year in over a decade, did some long overdue dead-wood clearing, and the waste of a chair was finally sacked—though not before dragging his entire team, product, and users right down with him. Mac Automation as Cook and Harris conceived it was an incredible thing. Apple management only made two mistakes: 1. Pissing off C&H by stealing half their team in order (as one wag memorably put it) to get OpenDoc ready to throw away; causing them to quit in disgust, taking all of the institutional knowledge, insight, and experience for making Mac Automation a popular success; and 2. Hiring Sal Soghoian, a charming enthusiastic fanboy with zero product development skills (and zero interest in learning) as their “replacement”. If only Apple had hired Cal Simone or Mark Alldritt, who actually knew what they were doing and how to sell product. Or better yet, realized what visionary jewels they had in Cook and Harris, and bent over backwards to win them back. So it goes. … I’d say “AMA”, but I think that largely covers it. Yes I am salty AF; but I know what has been so incompetently and thoughtlessly lost. And some of that’s my bad, for blowing opportunities like cheap balloons, so mostly I’m just pissed at myself. But William Cook passed recently, which I am still sad about, and Warren Harris a few years before. Those guys and Bill Atkinson are my Tiny Gods, and as I line up for my next attempt to Make Things Better (3rd time’s the charm), I would not be me without them and their groundbreaking work. Mad props, fellas; and whatever heaven you’re now in, may all your AppleScripts there compile and run forever. --has
hhas02 5y ago
Last post: All of my own “amateur” end-userlanguage design work of the last 15 years is the result of coming up through AppleScript, simultaneously delighted at the power it gifted me while increasingly appalled at how much hard unforgiving graft I put in to master this supposedly “easy language for ordinary end users”. (Cook and Harris made me the the monster I am today!) Which got me thinking: I appreciate all that C&H tried to do in their own end-user-language work. But surely it could, should, and must be done much better. And the answer is: YES! End-user programming can be made vastly quicker, simpler, easier, and accessible; and plain old written words—humanity’s greatest and most successful technology of the last 10,000 years are. Aaaand, I’m still figuring out all the details [where the devil is]. But I’m further on. So for those that are bravely curious: there are 3 experimental language proof-of-concepts on my GitHub that you are free to explore and do with as you will: entoli, the second one, and iris. (The first two are somewhat interesting experiments. The third, could be viable. All technically “toy languages”. But so’s JavaScript—and it prolly has 10Bn seats and counting. “Toys” that solve problems = Cool Beans!) Iris & friends are all “stealth Logos”; much as Logo itself is a “stealth Lisp”. Personally I’d argue Logo’s more Forth than Lisp; and in any case Lisp isn’t a good Lisp either, because Lisp, like AppleScript, BS-es its users by hiding complexity instead of eliminating it; in Lisp’s case pretending it is simple and perfectly uniform while being absolutely riddled with invisible special forms[1]. Lisp’s mistake: eager evaluation. Once you move decision-making as to how and when arguments are evaluated, from the command’s context to the handlers’, the number of special forms your language requires to do its job drops to zero. John Shutt’s Kernel language solved this, although couched in typically cryptic academic terms I don’t think many noticed or realized its significance. I solved the same problem independently, though coming from the hacker’a “git it done” perspective. You can see how I did it in iris &co. Interpreted performance is inevitably slowed by the extra layer of abstraction. However, by completely separating handler implementation (just an ordinary Swift function) from handler interface (the novel iris↔Swift type bridging that converts arguments and results from one to other), it should be trivial to create an optimizing Iris compiler that traverses an Iris script (which, like Lisp, is composed of simple native data structures) and outputs a Swift program that links up those Swift functions directly. And that’s relevant here too, because? Because I lifted that whole idea straight from AppleScript’s “application dictionaries”; and a helluva terrific idea those were too. (Even if they botched some of the implementation details, and then quit in anger before the developer documentation was done.) High-level RESTful interfaces? Cook and Harris largely did it first, and arguably did it better too. And theirs was just as ubiquitously misinterpreted and rottenly implemented by 99% the rest of the world as HTTP is today. (But that’s a rant for elsewhere.) … Now if anyone is really really crazy and looking for something to amuse, #3, iris (its name is obvious wordplay) has one outstanding TODO: finish its library that allows it to speak Siri Shortcuts. Because Shortcuts’ awful XML workflow files, stripped right down to their essentials, are simple sequences of commands; exactly what Forth and Lisp and Logo and my own languages all speak. I am currently pursuing a different market, though if anyone else wishes to pick up and run with iris: be my guest. Right now, Jellycuts is leading the field, having cracked the translation bit and put a nice, if unimaginatively conventional “UI” around it. (Although its increasingly solid Swift-like syntax is a good practical choice from a marketing perspective; and I’m honestly surprised @AriX’s team hasn’t swooped in and bought it and its developer yet.) Because whoever can unify text-based scripting [2], GUI-block-based scripting, and voice-driven scripting, into a single language that just speaks words, with a choice of presentations for every market and task, can basically own end-user automation for the next 30 years. For with billions of “supercomputers in pockets” today, and a billion kids grown up using them and hungry for more, there is an opportunity there to redefine “Personal Computing” for this new generation. (And I’ll bet you no-one at Apple, Alphabet, et al has even noticed it yet. Just remember: building it is the easy part; the trick is in clinching the sale.) -- [1] Hilariously unaware example of developers expertly explaining why special forms are required in programming languages: https://stackoverflow.com/questions/33465692/why-is-cond-a-special-form-in-scheme-rather-than-a-function https://stackoverflow.com/questions/33465692/why-is-cond-a-s... [3] And here think: not Bash, not C, not Python, but “TXT-speak”. Because the pidgin-English we all use when texting on our phones is remarkably similar to the pidgin-English that Logo language used (and which my own language designs use too). A natural, evolved, successful text interface in which a billion users are already trained and know how to use. [3] Perfectly begging the question, which John answered: “They’re not!” https://news.ycombinator.com/item?id=3831012 https://news.ycombinator.com/item?id=3831012

69 points by salgernon 5y ago

AppleScript is not much of a general purpose programming language (the syntax certainly takes a while to get used to), but for automating stuff, sorting files into folders, and the like, it is a nice tool. I have scripts that are indispensable to me, and combined with Folder Actions it ensures that there are things that Just Work.

serverlessmom 5y ago

I didn't realize AppleScript was still a thing, but here it is: https://developer.apple.com/library/archive/documentation/AppleScript/Conceptual/AppleScriptLangGuide/introduction/ASLR_intro.html https://developer.apple.com/library/archive/documentation/Ap...

bobbylarrybobby 5y ago

As terrible as AppleScript is as a language, it's really nice that Apple even built a framework for apps to use to expose their functionality to external scripts -- I'm not sure today's Apple would have gone to the trouble. And now that you can use JavaScript instead of AppleScript, with a more or less standard way of translating calls between the two, scripting+automating macOS is really painless. I do wonder why the Shortcuts app seems to be reinventing the wheel. You'd think the functionality an app exposed to AppleScript would've been automatically made available in Shortcuts, with Shortcuts being more or less a block-based interface to the same scripting environment that AppleScript uses, but that doesn't seem to be the case. Kind of an odd choice to not build off their existing work there.

crooked-v 5y ago
> I do wonder why the Shortcuts app seems to be reinventing the wheel. Shortcuts is cross-platform, and so designed from the ground up to work sanely under the limitations of both macOS and iOS.
- mmerickel 5y ago
  I have plenty of shortcuts that work on iOS but don't work on macOS. It's fun when you use siri on the mac and it tells you it can't do something halfway through.
fiddlerwoaroof 5y ago
It’s also relatively easy to use the Scripting Bridge from any language that can integrate with the objective-c runtime. I’ve written a bunch of Mac automation in Common Lisp
alwillis 5y ago
I had to automate transforming some Excel data for a friend recently and I did it using AppleScript. Turns out it’s not as bad as the prevailing HN narrative. It does require a change in mindset but once you get there, it’s actually quite nice, especially when using an app with a nicely designed dictionary. Like a lot of Apple’s technology from the 90’s, it was a technology before its time. It certainly was pretty important during Apple’s near death experience in the late 90’s due to the publishing workflows that could only be done (at that time) using AppleScript and Quark XPress, etc.
- fzumstein 5y ago
  Have a look at xlwings (I am the creator), it’s a Python wrapper around AppleScript that follows closely the original VBA object model, so won’t require a change in mindset.
  - hhas02 5y ago
    Hi Felix! Sorry I’m a jerk who never responds to PRs, although I know py3-appscript* is in its best hands with you so just keep rolling as you see fit. (*I am currently dragging nodeautomation back up to operational status so I can use it in new customer work, but that’s as much appscript-ing as my poor brain can cope with now.)
    - fzumstein 5y ago
      Hey has! I should have mentioned that xlwings is a wrapper around your excellent appscript package that does all the heavy lifting with AppleScript :) Thanks for reviving the project on GitHub :)
      - hhas02 5y ago
        “I should have mentioned” Not at all. Results are what matters, not the technical gubbins under the hood. I’m happy appscript helps you to empower your users.
jhbadger 5y ago
It's a "terrible language" in that it doesn't resemble most languages currently in use, but it resembles Hypercard's language Hypertalk a lot, so at the time it was created, this was a good idea. Hypercard/Hypertalk made GUI programming possible for non-technical people in a way that has not been possible since.
tinus_hn 5y ago
> I do wonder why the Shortcuts app seems to be reinventing the wheel. The Shortcuts app is a third party app bought by Apple.
radicality 5y ago
The other day I wanted to do something seemingly simple with Shortcuts - set my screen and my 3 external displays brightness to 100%. I saw an action to set screen brightness, but figuring out how to apply it to a specific display is an exercise left to the reader ugh. Shortcuts so far seems like a very unpolished product. Do you know if something like this is easily doable in AppleScript (and whether it’s even worth it vs writing these kinds of things in swift with apple libraries)
- bobbylarrybobby 5y ago
  https://apple.stackexchange.com/a/285907 https://apple.stackexchange.com/a/285907
hhas02 5y ago
“And now that you can use JavaScript instead of AppleScript” You really can’t. JXA is garbage, crippled, incompetent, and long since abandoned to pine for the fjords. Its only actual function is to impede any re-development of ES6 as a useful scripting platform within Apple, and probably hinders 3rd-party alternatives such as Scriptable and ScriptKit, because what 3rd-party dev wants to be pre-emptively Sherlocked by garbage like that? Apple abandoned AppleScript and AppleEvent-based automation after they gave the Mac Automation team multiple opportunities to make it successful—and they failed every one. Thus Apple fairly concludes it is a failed product on a legacy platform, ceases work on it because what’s the point on throwing more good money after bad, and looks elsewere for something new and more promising to try next. Hence Shortcuts, which started out as a 3rd-party iOS app, Workflow. As a technology it is at best mediocre; as a polished, well-presented, and properly-sold product it was already moving up on iOS with positive customer response. Instantly far more promising than the inept, lethargic, and generally couldn’t-sell-icecones-in-a-desert Mac Automation team, where the critical failure was never the technology itself but purely PEBKAC; but an organization the size of Apple doesn’t care about that distinction, only about its results. Thus, not too long after finally shitcanning the Mac Automation team in 2016, Apple bought up @WorkflowHQ outright, and have been positioning Shortcuts, née Workflow, for its true purpose: to provide their Siri UI with a reasonably granular, accessible, plugin backend so that Siri can actually make itself useful. … Lesson here for y’all: It does not matter one whit how good (or not) your technology is. (Apple themselves taught me that.) What matters is how good you are at selling product, i.e. putting bums on seats, and keeping them there. That’s why AppleEvent technology (which is in many ways far superior) now rots in history’s dustbin, while Apple gives the [Siri-backed and Siri-backing] Shortcuts its opportunity to prove itself a successful product and future of Apple Automation. Could a successful merging of the two produce a product 100× better? Sure. But if you’re asking that and not understanding why most likely won’t/can’t happen, you’re not understanding how successful big business works. My personal work (github.com/hhas/) testifies to hard lessons learned. (Though if you wish to have a crack, fill your boots. Perhaps you’ll do a better job n’me.)

olliej 5y ago

I implemented quick sort in AppleScript many years ago (to see if I could, not because this is a good idea), and it was excruciating. Very much the epitome of read only code :D

jtbayly 5y ago
I wrote a fair bit of AppleScript. It always seemed like my code was right, but it was wrong just as often as any other programming language I use. It was just as inflexible and demanding. That was frustrating, since reading it made it look like it was easy and it didn't care how you wrote it. But anyway, at least you could read the program and understand it afterwards, whether you wrote it or not, whether you understood all the things that had to be just so or not.

lostgame 5y ago

AppleScript might be one of the single most bizarre and arduous-to-write-in mainstream scripting/coding languages in history. I can’t say I’m a fan of such a literal interpretation of writing code. That being said, before I got a solid grasp on Obj-C and the (at the time) OSX APIs like CoreImage, etc; it got me started on writing Mac applications whereas otherwise I’d have had a much rougher time with it. Back when I’d made the switch from Windows to OSX in 2005 or so, I had written an AppleScript and accompanying Xcode app to auto-align desktop icons to the left, such as on the Windows desktop, as it drove me nuts that they auto-aligned to the right. (Now I prefer the right, lol…)

pie_flavor 5y ago

I lament the modern dearth of natural-language scripts designed for normal people who have slightly higher engineering instinct than average but otherwise just want to use their computer. Different people notice the usefulness of such things in different places, but for me it was Minecraft server administration. You have thirteen year olds doing a 'banging on the keyboard' level of management for game servers for eleven year olds, and who do not know the first thing about programming and would take years to get up and running with Java, but who have added to the server dozens of commands and idiosyncratic game mechanics with Skript, because Skript's language is so fundamentally easy and approachable that just about anyone could make just about anything in it that they could conceptualize of the details for. I really don't think AppleScript's primary application has vanished like many people seem to think it has. Desktop software may be on the decline, but that just means that something equivalent for web needs to exist. Every other day you hear about a business that had some major component, which finally broke, being a giant kludge of an Excel sheet. Those things don't start because they're the best tool for the job, they start because Excel's approachable for non-programmers who can figure out how to make an algorithm work as long as you don't call it an algorithm or force them to start with stdio. Flash had that property too, and the Internet is the lesser for its disappearance; it took so little effort for an animation to be turned into a game that so many animators decided to try. Nobody ever bothers making things like that anymore because everyone's internalized this idea that anything like programming is as hard and as not worth targeting towards normal people as general programming. I don't know how to end rants.

pjot 5y ago
I see it similar to self-selection. Those interested will dig into the OS, then find Automator, then find Apple Script, notice similarities to Minecraft servers, and ultimately choose their own adventure. I wonder though, if these features were more forward, how would that shape what the “typical” user discovers? As Bradbury-esque as that may sound…
imglorp 5y ago
AS failed at natural language though. The experience is exactly programming with more keywords. There's still a rigid grammar and keywords have precise meanings. You still have to look up what keywords are available, what contexts to use them, what arguments they want, etc etc. It's programming. Harder even. Ideally there's a bunch of real conversational NLP with common sense and context. This is really what you want: find my firefox window move it to the second workspace on that desktop make slack to be the top window close all finder windows we're not there yet

leodriesch 5y ago

I’ve recently wrote some AppleScript for some window management and as someone with more experience with C-style languages I find it’s syntax deeply confusing. It was more of a trial and error thing than anything else, tutorials online worked more or less. I see that it is incredibly easy to read, also for non-programmers, but I find it really hard to write, at least as someone that is not very into it.

udbhavs 5y ago

See also: Hyperscript (https://www.hyperscript.org https://www.hyperscript.org)

lopis 5y ago

Does this still exist? And is it actually "widely used" by any MacOS apps?

duskwuff 5y ago
Still exists, but support in modern macOS apps is pretty spotty. One app which does have surprisingly good AppleScript support is Music, which exposes the library as a fully featured OSA collection: tell application "Music" play (some track whose genre is "Rock" and duration < 240) end tell Unfortunately, the scripting dictionary is kind of old, and doesn't fully expose some newer features like "Up Next".
- ihuman 5y ago
  I'm surprised, since the dictionary has some apple music and icloud music library functionality. I expected it to expose "up next" as another type of playlist. I'm not sure if the same on desktop, but the iOS version of music allows you to control whats up next using Shortcuts. On the mac, you can control shortcuts with applescript using "Shortcuts Events", and shortcuts can run applescript. https://sixcolors.com/post/2022/01/shortcuts-applescript-terminal-working-around-automation-roadblocks/ https://sixcolors.com/post/2022/01/shortcuts-applescript-ter...

russellbeattie 5y ago

Apple desperately needs to kill AppleScript. Every year or so for the past decade, I run into a problem and think, "Oh, I'll try AppleScript" and as the saying goes, it rarely ends well. [1] We NEED the functionality of desktop apps and services exposing scriptable objects and methods. We do NOT need a "human language based scripting language". Programming in Python, Java and JavaScript have been taught at all levels of school for many years now, with countless resources online. Anyone who would ever have an interest in scripting their computer - the so-called Power Users - already have been exposed to traditional programming languages at some point in their lives and don't need or want to use a "simplified" language. So not only is AppleScript a bewildering, barely documented, Through-the-Looking-Glass version of a programming language ("‘How do you know that I’m mad?’ said Alice. ‘You must be,’ said the Cat, ‘or you wouldn’t have come here.’”), but the impetus for using such a language has totally disappeared, even if it wasn't an unusable mess designed by autists on LSD. 1. https://www.russellbeattie.com/blog/fun-with-the-os-x-finder-and-applescript https://www.russellbeattie.com/blog/fun-with-the-os-x-finder...

ihuman 5y ago
You can use Javascript [0] or Objective-C (via ScriptingBridge) instead of Applescript. Any language that can bridge to Objective-C (like Swift, Python, or Ruby) can also use ScriptingBridge. [0] https://developer.apple.com/library/archive/releasenotes/InterapplicationCommunication/RN-JavaScriptForAutomation/Articles/Introduction.html https://developer.apple.com/library/archive/releasenotes/Int...
- russellbeattie 5y ago
  First of all, support and documentation is virtually non-existent for any of those options. Have you tried to use JS alone to automate anything? Eventually you'll end up on the GitHub wiki like the rest of us, trying to convert 15 year old AppleScript examples into JS. It's a nightmare. This is related my point that AppleScript is an an anachronism. Apple must know that as well and don't want to spend any resources on the problem. So it's just sort of stuck.

dnljrz 5y ago

I remember showing my friend a few tricks with AppleScript when he started working as a genius. Apparently his manager got mad at him after a customer had complained about him writing a script as they thought he was "hacking" them. Turns out the manager had no idea what AppleScript was too.

gcanyon 5y ago

It’s important to distinguish Apple script the language from the dictionaries of events that apps support. The language is fine. It’s a little different, and there are many features from modern languages like Python that it could use. But the main issue is not the language, but the event dictionaries exposed by applications. I once spent most of a day finding out that a “page” was not an element of a “document”, but a “spread” was, and a “page” was an element of a “spread”. That might have been in adobe pagemaker. When the dictionary is clear, everything is fine. When it’s opaque, that’s when things get sticky. To be clear, AppleScript and app dictionaries are awesome — just someone’s also painful.

regus 5y ago

I like the idea of AppleScript, but every, single, time, I try to use it I walk away frustrated. I can never accomplish the goal I set out to do. Instead I end up wasting hours and hours fiddling around with this language. The syntax is just odd, since it has this conversational style ("tell app to do this") I constantly fall into the trap of trying to write out something that I think should work, but it does not. This happens all the time. The other day I wanted to automate something on my new M1 Mac. SURPRISE! The latest version of the app I was trying to use no longer supports Apple Script! Trying to automate stuff on Mac is so frustrating. Don't even get me started on Automator! I tried playing around with the new Shortcuts app, but that thing is also difficult.

alazoral 5y ago

A lot of open source software gains automatic trust by virtue of the fact you could check it out, read the source, and compile it yourself. This possibility stands in for the fact that you probably can't - you probably can't actually read the code, and if you could you can't possibly understand all the edge cases and implications, and you definitely don't have time, especially if you are to recurse into its dependency tree. So for scripting, where you give a random piece of code access to your entire digital life, a language that is hard to write for even experienced developers but is easy to read and fully understand what is going to happen when they run it, for anyone who could read its licence agreement, is an inspired choice. It should be very hard to make software that could hurt people. It should be obvious, to as many people as possible, when software could hurt people. If we all prioritised user safety over developer comfort we would have a very different industry.

CPLX 5y ago

Back in 2007 or so I wrote an AppleScript that would iterate through every email I had ever sent or received, find every properly formed email address, go to the Facebook website, and attempt to add that person as my friend. At the time I was a publicist in the entertainment business so this was a lot of people. Was a fun way to kill an afternoon, and I still have about 5,000 “friends” on Facebook, many of whom I don’t know super well. So I’ve got that going for me. AppleScript was cool.

hhas02 5y ago

Cook’s HOPL3 paper on the early history and motivations of AppleScript is a great read, full of insight and ambition, and it is a damn shame that early 90s Apple management pissed off Cook and Harris into walking out the door, effectively taking with them all of the institutional knowledge and experience that—after a few more rounds—could’ve made Mac Automation into a true game changer. I will also put this here: https://www.youtube.com/watch?v=1MaHJ_mzrTU https://www.youtube.com/watch?v=1MaHJ_mzrTU As presentations go, it not the best sales pitch; and it lacks the depth of the paper (which was written much later), but it’s just a joy to see two young UX innovators genuinely psyched and evangelizing their work. Sadly Warren Harris passed, still young, a few years back; and William Cook late last year. Which probably leaves me as the last person who truly understands that work, and what it tried to achieve. (And still could, in the right hands, although I doubt those hands existin in Apple any more.)

hhas02 5y ago

I will also leave these here: appscript.sourceforge.net sourceforge.net/projects/appscript/files github.com/hhas/SwiftAutomation www.npmjs.com/package/nodeautomation (The nodeautomation bridge on npm is broken due to bitrot in NodObjC; there’s an active fork on my github which works, albeit slowly RN, as I bring it back into operation for new customer work.) … Python appscript was, and arguably still is, the single best piece of software I ever wrote. And it wiped the floor with AppleScript. To the scripters and programmers who used it, it was a revelation: 99.9% as good as AppleScript for automating Mac apps, in a language they already know and love. Protip: Nothing in AppleScript makes sense except in light of relational queries. Appscript was the first time anyone explained honestly to Mac OS X devs how Apple event automation actually works. Application Automation is not OOP (despite its misleading jargon and superficial appearance). It’s RPC plus simple first-class queries. It’s most closely related to SQL and RDBMSes—except whereas SQL talks to a handful of virtually identical apps all doing the same thing, here’s a system that talks to hundreds of wildly heterogenous apps; and in a way that is, in principle, accessible to everyone from expert programmers to end users. Once you know that, all the bafflement and confusion caused by the mismatch between you you think it works and what you see it actually doing evaporates. And not only is it clear, it is also logical and elegant AF. A really nice, thought-out, very-high-level UI/UX; a programmatic peer—and equal—to the Mac GUI. Instant, irresistable catnip for geeks. Today it should have a technical audience millions strong, powering the heart and userlands of every Apple OS. … The first version of appscript (2003–2004) was a failure. It took years for me to fully understand the implications of “Not Object-Oriented, Query-Driven”. By the time Dr Cook was presenting his AppleScript paper at HOPL3, I had eventually figured it out for myself; even so, reading that paper a while later was hugely enlightening and confirmed I finally had a Mental Model that Is Not Wrong. I owe Cook and Harris a debt of gratitude for their work that am still grinding away to pay off. Anyway… Back in 2006/2007, Apple approached me expressing an interest in including Python and Ruby appscript in Mac OS X Leopard. Alas, due to my non-existent sales skills and the then-Mac Automation team’s terminal (literally) Not Invented Here Syndrome, that opportunity was lost. Apple shipped its garbage ScriptingBridge.framework, which immediately failed and sunk with barely a trace. (Yes, I was a dunce; but at least I wasn’t the dunce being paid six figures at Apple to utterly feck things up. That was Sal Soghoian’s job.) By time 2012 rolled around, the bottom had dropped out the Mac Automation market and it was clear it was on its way out. That year I predicted AppleScript would be done within the next 5–10. When JXA was surprise-announced at WWDC14 (no doubt pissing off the JavaScriptCore team after revealing their own alternative to AppleScript at WWDC13), I realized this was a unique opportunity to turn things around. The JavaScriptOSA component at the second line, I wrote in less than a month and sent it to the Mac Automation team to learn from/steal however they liked. I even had the book outline for “Learn JavaScript for Automation” worked out, and good chance of getting Apress to publish it. I’d have done all the community building and support—everything needed to make JXA successful, because I adore what Mac Automation technology has empowered me to do as both an end user and as professional developer. I was desperate to see that power shared with other users, so those users could empower themselves too—even as the Zucks and the rest were doing their damndest to lock all us in their gilded cages and nice little dependent revenue streams for themselves. I gave Soghoian six weeks of world-expert consultancy in the runup to JXA’s release, and in return for all that he ghosted me with not even a “Thanks, but no thanks” for working my ass off to make him successful. Probably cos I was telling his work was crap—and how to fix it within weeks to be awesome—and not how the sun was shining out of his ass. Mr Jazz-Ego, ladies and gentlemen. At least I had the sense to write off my losses and run. … There is a coda: Not too long after JXA immediately failed and sank without trace exactly the same as ScriptingBridge did 8 years before, Apple’s new Swift language was starting to rocket as the Hot New Platform in macOS development. And because I’m a glutton for self-inflicted pain, I wrote SwiftAutomation.framework for it, and then wrote Sal Soghoian offering to give it to his team outright. Simply tie it onto Swift’s coattails and ride that Swift rocket to mass market success. Sal Soghoian, a natuarl charmer who for 20 years sat in the front seat row to the greatest Marketing and Sales Masterclass of a generation, arrogantly blew me off threw that third-and-final chance for success straight back in my face. And in return for that, I wrote a no-holds-barred email explaining to him exactly how his incompetence and failure to learn had driven Mac Automation right into the ground. And just over a year later, Apple management, facing their first flat year in over a decade, did some long overdue dead-wood clearing, and the waste of a chair was finally sacked—though not before dragging his entire team, product, and users right down with him. Mac Automation as Cook and Harris conceived it was an incredible thing. Apple management only made two mistakes: 1. Pissing off C&H by stealing half their team in order (as one wag memorably put it) to get OpenDoc ready to throw away; causing them to quit in disgust, taking all of the institutional knowledge, insight, and experience for making Mac Automation a popular success; and 2. Hiring Sal Soghoian, a charming enthusiastic fanboy with zero product development skills (and zero interest in learning) as their “replacement”. If only Apple had hired Cal Simone or Mark Alldritt, who actually knew what they were doing and how to sell product. Or better yet, realized what visionary jewels they had in Cook and Harris, and bent over backwards to win them back. So it goes. … I’d say “AMA”, but I think that largely covers it. Yes I am salty AF; but I know what has been so incompetently and thoughtlessly lost. And some of that’s my bad, for blowing opportunities like cheap balloons, so mostly I’m just pissed at myself. But William Cook passed recently, which I am still sad about, and Warren Harris a few years before. Those guys and Bill Atkinson are my Tiny Gods, and as I line up for my next attempt to Make Things Better (3rd time’s the charm), I would not be me without them and their groundbreaking work. Mad props, fellas; and whatever heaven you’re now in, may all your AppleScripts there compile and run forever. --has

hhas02 5y ago

Last post: All of my own “amateur” end-userlanguage design work of the last 15 years is the result of coming up through AppleScript, simultaneously delighted at the power it gifted me while increasingly appalled at how much hard unforgiving graft I put in to master this supposedly “easy language for ordinary end users”. (Cook and Harris made me the the monster I am today!) Which got me thinking: I appreciate all that C&H tried to do in their own end-user-language work. But surely it could, should, and must be done much better. And the answer is: YES! End-user programming can be made vastly quicker, simpler, easier, and accessible; and plain old written words—humanity’s greatest and most successful technology of the last 10,000 years are. Aaaand, I’m still figuring out all the details [where the devil is]. But I’m further on. So for those that are bravely curious: there are 3 experimental language proof-of-concepts on my GitHub that you are free to explore and do with as you will: entoli, the second one, and iris. (The first two are somewhat interesting experiments. The third, could be viable. All technically “toy languages”. But so’s JavaScript—and it prolly has 10Bn seats and counting. “Toys” that solve problems = Cool Beans!) Iris & friends are all “stealth Logos”; much as Logo itself is a “stealth Lisp”. Personally I’d argue Logo’s more Forth than Lisp; and in any case Lisp isn’t a good Lisp either, because Lisp, like AppleScript, BS-es its users by hiding complexity instead of eliminating it; in Lisp’s case pretending it is simple and perfectly uniform while being absolutely riddled with invisible special forms[1]. Lisp’s mistake: eager evaluation. Once you move decision-making as to how and when arguments are evaluated, from the command’s context to the handlers’, the number of special forms your language requires to do its job drops to zero. John Shutt’s Kernel language solved this, although couched in typically cryptic academic terms I don’t think many noticed or realized its significance. I solved the same problem independently, though coming from the hacker’a “git it done” perspective. You can see how I did it in iris &co. Interpreted performance is inevitably slowed by the extra layer of abstraction. However, by completely separating handler implementation (just an ordinary Swift function) from handler interface (the novel iris↔Swift type bridging that converts arguments and results from one to other), it should be trivial to create an optimizing Iris compiler that traverses an Iris script (which, like Lisp, is composed of simple native data structures) and outputs a Swift program that links up those Swift functions directly. And that’s relevant here too, because? Because I lifted that whole idea straight from AppleScript’s “application dictionaries”; and a helluva terrific idea those were too. (Even if they botched some of the implementation details, and then quit in anger before the developer documentation was done.) High-level RESTful interfaces? Cook and Harris largely did it first, and arguably did it better too. And theirs was just as ubiquitously misinterpreted and rottenly implemented by 99% the rest of the world as HTTP is today. (But that’s a rant for elsewhere.) … Now if anyone is really really crazy and looking for something to amuse, #3, iris (its name is obvious wordplay) has one outstanding TODO: finish its library that allows it to speak Siri Shortcuts. Because Shortcuts’ awful XML workflow files, stripped right down to their essentials, are simple sequences of commands; exactly what Forth and Lisp and Logo and my own languages all speak. I am currently pursuing a different market, though if anyone else wishes to pick up and run with iris: be my guest. Right now, Jellycuts is leading the field, having cracked the translation bit and put a nice, if unimaginatively conventional “UI” around it. (Although its increasingly solid Swift-like syntax is a good practical choice from a marketing perspective; and I’m honestly surprised @AriX’s team hasn’t swooped in and bought it and its developer yet.) Because whoever can unify text-based scripting [2], GUI-block-based scripting, and voice-driven scripting, into a single language that just speaks words, with a choice of presentations for every market and task, can basically own end-user automation for the next 30 years. For with billions of “supercomputers in pockets” today, and a billion kids grown up using them and hungry for more, there is an opportunity there to redefine “Personal Computing” for this new generation. (And I’ll bet you no-one at Apple, Alphabet, et al has even noticed it yet. Just remember: building it is the easy part; the trick is in clinching the sale.) -- [1] Hilariously unaware example of developers expertly explaining why special forms are required in programming languages: https://stackoverflow.com/questions/33465692/why-is-cond-a-special-form-in-scheme-rather-than-a-function https://stackoverflow.com/questions/33465692/why-is-cond-a-s... [3] And here think: not Bash, not C, not Python, but “TXT-speak”. Because the pidgin-English we all use when texting on our phones is remarkably similar to the pidgin-English that Logo language used (and which my own language designs use too). A natural, evolved, successful text interface in which a billion users are already trained and know how to use. [3] Perfectly begging the question, which John answered: “They’re not!” https://news.ycombinator.com/item?id=3831012 https://news.ycombinator.com/item?id=3831012