AppleScript (2006) [pdf]
Last post:<p>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&amp;H <i>tried</i> to do in their own end-user-language work. But surely it could, should, and must be done much better.<p>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.<p>Aaaand, I’m still figuring out all the details [where the devil is]. But I’m further on.<p>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.<p>(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 <i>solve problems</i> = Cool Beans!)<p>Iris &amp; 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].<p>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 <i>zero</i>. John Shutt’s Kernel language solved this, although couched in typically cryptic academic terms I don’t think many noticed or realized its significance.<p>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 &amp;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.<p>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.)<p>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.)<p>…<p>Now if anyone is really <i>really</i> crazy and looking for something to amuse, #3, <i>iris</i> (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.<p>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.)<p>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 <i>own</i> end-user automation for the <i>next</i> 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.<p>(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.)<p>--<p>[1] Hilariously unaware example of developers expertly explaining why special forms are required in programming languages: <a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;33465692&#x2F;why-is-cond-a-special-form-in-scheme-rather-than-a-function" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;33465692&#x2F;why-is-cond-a-s...</a><p>[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.<p>[3] Perfectly begging the question, which John answered: “They’re not!” <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3831012" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=3831012</a>