Programmer's critique of missing structure of operating systems
It&#x27;s probably worth the owner checking out the Lisp Machine, Oberon, and Inferon (A descendent of Plan9 where they improved over the original concept). They say Plan9 is a step in the right direction, but rather than attacking a specific aspect of Plan9, they critique how the concepts were imported into Linux, which seems inherently silly to me.<p>It&#x27;s like critiquing a master craftman&#x27;s tools by observing how a master craftman uses his tools, and then critiquing how the apprentice uses those tools. Sure, some of that criticism of the concepts is valid, but they picked the worst implementation of those concepts to critique.<p>One of the things mentioned in the critique is how the filesystem in question communicates the changes back to the user, and how the user is expected to know what parts of the filesystem to alter. While in the examples given, it does seem relatively obscure, the decry the fact that they had to <i>check the manual</i> for the position to write to.<p>However, both of those would still be the case for the system that they talk about. Let&#x27;s talk about object orientated systems, which already exist, in limited (compared to the operating system) forms. You still have to pick up a manual to figure out what keys and functions are relevant to you. In Pharo (which is more or less the system they&#x27;re after!), you can inspect objects that exist and the methods that exist for them -- however -- often, similarily-named functions do different things, which also requires reading a manual. In addition, using these tools as a first-time user, I was overwhelmed by the number of functions available, most of which I could only guess at what their purpose was. Pharo integrates the manual into the system, but the manual is still there!<p>Standardized error codes are given in structures passed back (As in Erlang) or in Exceptions, but there are problems with those too. You still have to figure out <i>what those exceptions or errors mean</i>, and there isn&#x27;t necessarily a <i>standardized format for those errors</i>. As a developer I&#x27;ve been recently been working on writing a Python api. As someone who has little experience with the intimate details of the Python language, I do not always know of the exceptions that exist that I am able to throw, I do not always know of which exceptions would be most appropriate. The same problem exists (obscure error values), but in a different form. There are existing libraries that I rely on that implement more exceptions, sometimes these aren&#x27;t documented, and even with the venerable Requests library, I have still had to crack open the objects that exist to find easier methods of passing data that the Requests library <i>has</i>, and <i>uses</i>, but does not <i>document</i> for external use.<p>Let&#x27;s look at the windows hive database. That&#x27;s a database of keys for values in the operating system. As a random developer, would you be able to open it and figure out what it does? I wouldn&#x27;t. As a windows power user I often relyied on articles from howtogeek without really fully understanding what the keys were doing (Although because of my experience an a systems developer, I could guess, but only <i>after the fact</i>). Again, the same problem (&quot;I know what I want to do, but I do not know how to do it&quot;) is exposed in a different form, and the methods and practices of the Microsoft organization make that difficult hard to reach. Yet again, the same problems are there, but in a different form.<p>I do agree that the shell should handle program arguments, a program could expose keys and values and a shell could read that and tell the user about it. I would be interested to see the problems that the Oil shell encounter in their implementation of an object-orientated shell.