The Interface Is The User Data

Relates to:

The interface of the software is tightly bound with the user data. Scripting is fundamental to the software's functioning.

The same commands used to interface with the program are used to describe the data in the program.

For instance, the saved files are simply sets of scripts that are run, restoring each class to the saved state.

One major benefit is that undo is implied. Restoring the application's model is as simple as rewinding the script.

Possible Examples:

AutoDesk MechanicalDesktop?. In AutoCad products, a script to regenerate the drawing is usually a much smaller, more editable file than AutoCad's standard export files (such as .dwg and .dxf).
Stone Design's MacOsx drawing application, Create has an option to save any document as an AppleScript that will recreate the document when run. http://www.stone.com/Create/AppleScript.html

Yes but what if you are creating commercial applications and don't want users or administrators to see the code (which they can if EverythingIsaScript? )? I agree scripting should be embedded where possible but I think it is easier to build whatever logic is needed into code that will be compiled but provide the option to run main methods from command line. Then the OS scripting capability (bash, wsh, perl or whatever) can be used by the customer to automate and combine your application with other processes as needed. Otherwise, the customer ends up trying to use things like Winbatch, Expect or calling methods from dlls which are more complex to do than plain OS scripting.

Originally this pattern wasn't meant for external command line operations. It was meant to be internal to the application. I.e. a "data file" internally is a script, but is treated the same as any other data file(represents the user data) - but it's actually a script. So command line operations yes, but external command prompt operations no.