Coming from an MS-DOS background, I immediately fell in love with the Unix Programming Environment when I first encountered it. The idea of treating the "user" not as a "consumer" of large isolated and monolithic "applications" but rather provide a toolbox allowing to quickly assemble non-trivial ad-hoc programs in the form of pipelines utterly changed my take on how to use computers.
In a way, the Unix shell and the Unix tools are an "Integrated Development Environment" (IDE for short) although nowadays people believe that behemoths like Eclipse or Microsoft Visual Studio are IDEs.
However the original Unix toolkit lacked an integrated editor and so the full potential of the Unix Philosophy in One Lesson remained untapped for some time. (In case you are unfamiliar with the Art of Unix Programming I suggest reading all of it just in case.)
Enter Plan 9 from Bell Labs.
Things changed some of the original Unix creators designed Plan 9 at Bell Labs in the late 1980s. Some of the clear breaks in the original Unix tradition were eventually taken care of. Examples of those are a global instead of local file system hierarchy or the lack of integration of networking and graphics.
For example every Unix user has at least heard of the claim that "everything is a file". And sure enough the character like /dev/ttyS0 and block devices like /dev/sda1 give an idea of how this works. For a GNU/Linux user it is easy to create an SD-card for an embedded system with the help of a small tool called dd and the block devices that represent the SD card and partitions on it. For Windows users it is not uncommon to download a mere ~120 MiB program called Etcher to solve the same problem.
Special file systems like procfs extend the usefulness of these basics. A good example is configuring a regular Linux IP stack into a network router with a trivial shell command in a root shell:
root@krikkit:~# echo 1 > /proc/sys/net/ipv4/ip_forward root@krikkit:~#
Let’s take a second to analyze this. We don’t need any fancy tool or let alone a GUI to change the inner workings of the Linux kernel. Not even a utility aimed at changing kernel parameters. The echo builtin command from a Unix shell combined with the concept of redirecting input and output streams is enough to do the job. Of course a significant part of this construction is the pseudo file system mounted at /proc processing the write.
It is this simplicity arising like pure magic when the underlying concepts have been architect ed especially well. Sometimes it is not at all clear upfront how to achieve this and the procfs file system is a good example of that. It predates Linux and seems to have appeared for the first time in Unix 8th Edition. However it originally was meant to provide access to process images on the system. Only the subsequent addition of the /proc/sys sub directory extended the scope and brought kernel parameters into view.
As the concept is so powerful, more and more features were added into procfs turning it into a powerful tool for system introspection. This went on until it was basically hard to understand why the base file system was called /proc to begin with. Somewhere around that phase, the Linux developers decided to stop this feature creep and instead introduced the sysfs file system usually mounted at /sys.
But this is just a digression of today’s topic, i.e. Plan 9’s solution for the editing task or the Acme User Interface for Programmers. Unfortunately it is difficult to understand acme without understanding process local namespaces and how blatantly elegant inter-process communication can become if you can "mount" the services of another program into your own namespace and then simply access it by regular file operations. As an example, in such a system it is nearly trivial to access mail by mounting the mail file server into your namespace. The resulting /mail/fs will then have numbered entries for all the mails in your mailbox. Every directory contains files like from, to, header, etc. and the file body will contain the message without its headers. Of course attachments are then again simply numbered directories in the mail directory itself.
With this, you can use the full power of grep, find, etc. to process your mailbox instead of special tools. Once you realize how powerful and consistent this fits with the "KISS" principle, you may wonder what else is possible in such an ecosystem.
Nevertheless it is hard to understand the beauty and expressiveness of the resulting system without seeing it for yourself. And so instead of trying to describe acme myself, I much rather defer you to this 20 minute video Tour of Acme from Russ Cox allowing you to see the system in action.
If the video succeeded to whet your appetite, then why not try getting Plan 9 on Qemu + KVM to work on your own system. I will be grateful if you leave a comment on what you think of the experience.