Emacs and the UNIX philosophy, part 2

See also: UNIX, Lisp Machines, Emacs, and the Four User Freedoms.

Each of the main tenets of the UNIX philosophy has essentially a kernel of truth to it:

• we want to break functionality down into individual pieces so that they can be handly used as tools,
• we want a common data interchange format so that everything is interoperable,
• and we want to make sure to design everything to be composable.

However, it misunderstands how best to achieve each and every one of these options. Human-readable text is a good medium for data, but it is too flexible to be the data interchange format, by itself, and lacks out-of-band capabilities, as I've said before. Breaking down functionality into entirely separate programs/processes is way, way too hard of a line, causing both severe overhead (forking is expensive), making it more difficult and slower to communicate data in a useful way (no shared memory space), and turning each set of functionality into a tiny little black box where it's difficult to modify or adapt its behavior except through a million esoteric and idiosyncratic flags (see also: programmability vs customizability). Likewise, UNIX's answer to composing programs is shell: a weak, underpowered, insecure language full of gotchas that has to shell out to a million sub-languages with different syntax and semantics to do basic things, and which provides no common substrate of conventions and interoperability between components that are supposed to "compose."

In my opinion, a better solution to each of these examples is available, and exemplified by Emacs, as the last heir to the Lisp Machines:

• Emacs breaks all functionality down into functions, which can be used handily as tools, but which don't come with the costs of separate processes/programs. It also means that complete, holistic applications can be written for Emacs and still remain composable, since all of their internal functions are exposed to the whole system to use and reuse and script and automate in any way desired. This means that there doesn't have to be an intentional attempt to expose an Emacs program's separate functionalities as sub-commands, or a tension between large integrated programs and small composable "do one thing and do it well" programs. You can have both. (Emacs also has powerful process manipulation capabilities and is not afraid of shelling out, too. Emacs in fact makes an excellent shell.)
• Emacs provides a data interchange format with all of the benefits of text and none of the downsides. It is flexible, easily reinterpretable, composable, human readable, and simple, but has the capacity to easily encode structured data and the semantics of the data provided out of band and in a way that can be reliably communicated and understood within its environment.
• Emacs provides a computing environment and language that does functional programming (which is what the UNIX philosophy really is is) better than Bash. It can compose functionality (processes and functions) and transform data in a much more powerful and ergonomic way.