Why are Script Editor .scpt files not saved as plain text files? The Script Editor (formerly AppleScript Editor pre-Yosemite 10.10) saves .scpt files as binary files, not plain text files.

It makes working with them in source code control systems somewhat cumbersome.

Does anyone know why this is the case? Is there some long-standing history that necessitated this file format be something other than plain text files?
William R. Cook's paper contains an excellent history and insight from those involved with AppleScript in 1989.

What follows is fun and speculative.

Conservation of Space and Processing

AppleScript was written at a time when every byte and bit was valuable. OS X's lazy encoding as property list formats would be wasteful in the eyes' of those early developers.

The binary format provided a pre-parsed form that avoided duplicating the complex, error prone, and time consuming parsing process with each load from disk. Better to load directly into memory and run.

Adaptive

Saving in a binary format allowed AppleScripts to be tied to the underlying AppleEvent codes rather that their dictionary of long form terminology.

This would allow an AppleScript written and saved against one version of an application to automatically update to terminology changes between versions of the targeted applications.

An integer object might be called 'integer' in the script but saved as the four character code 'int ' in the binary representation. The four character code coming from the AppleScript dictionary provided by the operating system.

If a future AppleScript terminology decided to alter the user facing word for integer, the binary representation could map to the newer name.

A flip side to this is possible to see today. Write an AppleScript against an application's dictionary. Then remove the application entirely from your Mac. What do you see in Script Editor upon opening the script?

At least in recent versions, AppleScript Editor showed chevrons surrounding the four character code. The code has been remembered and highlighted. Not the user facing terminology.

This is probably not the primary benefit but a possible benefit.

Modern Bias

It is worth acknowledging our modern bias for text documents. Experience has taught many of us that storing valuable content in a binary format carries risk. Binary formats are often poorly documented, opaque to the end user, and difficult to open when the owning software is not maintained.

When AppleScript and it's binary format were created, this bias was not yet formed. Storage and computational limits were very real and every kilobyte or thousands of cycles saved were worthwhile.

History and Origins

The stories of AppleScript's origin are wonderful but difficult to track down these days. AppleScript tried to be a friendly, English language like, language and was breath taking in its vision; the actual implementation was harder to get right!


AppleScript by William R. Cook
AppleScript - a story worth telling