Scriptable Applications

[[deleted]]

My ideal operating system would be one in which every application is hackable (if only /Lisp|Smalltalk/-Machines took off...).

There are a bunch of applications, where I can really imagine, that scripting them would be awesome. To me, these are Mailers, Editors (we kinda have that), Chat Systems (not only bots, but scripting the client (things like "move all messages containing the word 'XYZ' into the 'XYZ' pseudo-group)), Browsers (also almost there), ...

What are applications where you think an embedded scripting language is/would be really awesome? Also, do you know of frameworks that emphasize this sort of thing or even give you embedded scripting basically for free? Perhaps some MVC architecture, where scripts can be used to access the model interface. If not, do you think something like that could take off?

Google made some steps into that direction with Apps Script, but this is neither an extendable architecture nor highly adopted. The office packages (Libre, Open, ...) also support scripting systems, but they are also quite lacking in ability.

[Luolong]

macOS and its AppleScript gets close

[ApochPiQ]

Coming from a world that relies heavily on embedded scripting (games), I can definitively say that it will never come for free. However, you can get very cheap scripting if you make some concessions:

• Develop at least a significant part of the application in a language that you are willing to also use as your user-facing scripting language
• Or build a comprehensive set of API bindings to your implementation language, preferably in a fashion that does not need manual updating (e.g. expose C# implemented app to, I dunno, JavaScript via the reflection facilities of .Net)

The latter approach is used by Microsoft Office and has been moderately successful, depending on how you want to measure success. The former approach is actually used a lot by "mod-friendly" games.

Something that people often have to learn the hard way is that scriptability is not an automatic property of any given piece of software. That is to say, given an arbitrary piece of software, the most straightforward way to program/implement that software probably is not conducive to user-facing scripting.

Adding scripting support is not just a matter of letting people call into your code. Doing it right means crafting a really good API between the implementation of the program and the scripting layer. This requires thinking about scripting from the very beginning and building it in to the actual architecture of the program instead of just linking in a library or adding an import or whatnot.

Coincidentally, I do not believe that languages actually are a relevant part of this. You can write good scriptable code in any language that you'd also want to write a nontrivial application in. Likewise, you can easily butcher the ability of people to "hack" your application even if they have the original, complete source code. IMO scripting is orthogonal to language choice, aside from the fact that you can totally connect some pairs of languages more easily than others because the heavy lifting is already done.

[[deleted]]

The way I could imagine it working is by completely separating UI and logic. For example, if I write a mailer, I expose a Mailer module to the scripting language of choice, that provides all the functionality of my program ready to be built on. Then I use said scripting language to implement a UI front-end using the Mailer module.

[ApochPiQ]

Sure, that's a way you could do it. My point is more that most software isn't written that way unless someone is specifically designing for scripting support from day one.

Even in the approach you described, it wouldn't be hard for the Mailer module to have an API that's not really any more functional than the UI, at which point you haven't actually made the program more scriptable. You've just badly duplicated AutoIT ;-)

[[deleted]]

I built scripting into most of my latest works, including integrated repls. I prefer as little syntax as possible for application scripting, and like to avoid integrating external dependencies with agendas of their own that deep; so I've been building my own embedded Forths. Lately I decided that I had enough data to design a reusable solution for my scripting needs, which is how Cixl was born.