Finding some gems in this history of Applescript:
dl.acm.org/doi/pdf/10.114…
1) Applescript originally had other dialects besides English!? Including a "professional" syntax that never shipped
dl.acm.org/doi/pdf/10.114…
1) Applescript originally had other dialects besides English!? Including a "professional" syntax that never shipped
I love this: "all our other products are localized, why not our scripting lang?"
(seems like projectional editing, but with a text editor rather than structured editor, interesting compromise...🤔)
(seems like projectional editing, but with a text editor rather than structured editor, interesting compromise...🤔)
Apparently this effort eventually ended because app developers didn't provide app-specific terminology in different languages
Btw, for a fantastic exploration of programming languages that span multiple human languages, see @ra's talk, "A personal computer for children of all cultures"
It specifically calls out this last challenge around library names
deconstructconf.com/2019/ramsey-na…
It specifically calls out this last challenge around library names
deconstructconf.com/2019/ramsey-na…
2) I like this idea of factoring your UI into a GUI and a "backend" to make it more scriptable... Do Mac apps actually commonly work this way?
The web frontend/backend split doesn't seem quite right, not granular enough
Something like a command log in Elm/Redux seems closer. Eg, Redux enabled building an alternate CLI on top of Firefox dev tools:
Something like a command log in Elm/Redux seems closer. Eg, Redux enabled building an alternate CLI on top of Firefox dev tools:
Key for scriptability to have a higher-level "semantic" event log, not just low-level GUI events..
Seems like a scriptability win when a UI architecture nudges you towards creating this higher-level event log by default, with lower-level events encapsulated inside components
github.com/geoffreylitt/t…
github.com/geoffreylitt/t…
3) This paper got me thinking about "automation" vs "customization"...
It says "customization requires automation to be useful", which I don't really understand
It says "customization requires automation to be useful", which I don't really understand
The "macro recording / automation" style is all about doing something in the existing UI, and then making a robot do it faster
But what does end user scripting look like if it's more about doing new things, and less about doing the same things faster?
But what does end user scripting look like if it's more about doing new things, and less about doing the same things faster?
This is an idea I'm trying to explore with Wildcard: by exposing a structured data view, can we help people think of new ideas which weren't even possible in the original UI? The spreadsheet UI liberates your imagination a bit
geoffreylitt.com/wildcard/salon…
geoffreylitt.com/wildcard/salon…
One more thing -- given a lot of recent discussion around here about CLIs vs GUIs, it's fun to see how far back this desire goes
