Right, the primitives are definitely different. But that's my point. The Unix primitives are simple and generic, which allows the user to quickly and easily adapt a disparate set of tools into an infinite number of workflows. The user is not required to also be a programmer[1]. If they are missing a specific tool, which is very rare, then it can be written in any language and integrated into existing workflows by following the simple design conventions. This generic interface is why programs written decades ago are still useful today. They don't need to be aware of how they're going to be used. They just need to follow the established design conventions.
In contrast, if a specific Emacs package doesn't do what the user needs, they must use Elisp to change it, or write their own package. Integrating packages in a cohesive workflow also requires programming, and each integration is special because every package has its own quirks and API. This might be second nature to some Emacs gurus, but I don't want to program whenever I need to change my workflow. I'm sure that I could eventually build the perfect operating system for me this way, but I'd rather rely on an extensive ecosystem of tools written by others.
[1]: I would argue that shell scripting is not programming, for better or worse. It's often the best tool for the job for getting things done quickly, but for more sophisticated tasks a programming language is a better fit.
Emac's primitive are much more involved for sure. But the focus on having a simple and common representation for input and output instead of the separation between prompt and output has make it a lot easier to write involved tooling. Instead of a TUI application which breaks the unix philosophy or a script for a single workflow, you have both. The closest I think is now Vim+tmux, but it's now as easy to modify on the fly.
Comments
Right, the primitives are definitely different. But that's my point. The Unix primitives are simple and generic, which allows the user to quickly and easily adapt a disparate set of tools into an infinite number of workflows. The user is not required to also be a programmer[1]. If they are missing a specific tool, which is very rare, then it can be written in any language and integrated into existing workflows by following the simple design conventions. This generic interface is why programs written decades ago are still useful today. They don't need to be aware of how they're going to be used. They just need to follow the established design conventions.
In contrast, if a specific Emacs package doesn't do what the user needs, they must use Elisp to change it, or write their own package. Integrating packages in a cohesive workflow also requires programming, and each integration is special because every package has its own quirks and API. This might be second nature to some Emacs gurus, but I don't want to program whenever I need to change my workflow. I'm sure that I could eventually build the perfect operating system for me this way, but I'd rather rely on an extensive ecosystem of tools written by others.
[1]: I would argue that shell scripting is not programming, for better or worse. It's often the best tool for the job for getting things done quickly, but for more sophisticated tasks a programming language is a better fit.
Emac's primitive are much more involved for sure. But the focus on having a simple and common representation for input and output instead of the separation between prompt and output has make it a lot easier to write involved tooling. Instead of a TUI application which breaks the unix philosophy or a script for a single workflow, you have both. The closest I think is now Vim+tmux, but it's now as easy to modify on the fly.