Programmer's critique of missing structure of operating systems
I get where the author is coming from, and I&#x27;m often dismayed by how much of programming is just shuffling data from one platform&#x2F;format&#x2F;structure&#x2F;persistence layer to another.  It&#x27;s tedious AF.<p>Still, there appears to be a lot of conflation of concepts here, and I don&#x27;t see anything approaching crystallization of a coherent solution.<p>What do I gain by telling the OS that I want a JPG rather than a sequence of bytes that I know is a JPG?  I&#x27;m probably already using a library to deserialize this for me, unless I&#x27;m a masochist, so the heavy lifting has already been done.  And that object&#x2F;struct&#x2F;whatever is going to be represented somewhat differently in memory for Java than for C++ than for Python.  There is no way to reconcile those differences without creating even more problems.  So a programming language would need to either be written or adopted to standardize on.<p>Most application-specific data is already stored in a database of some sort anyway, which is itself (potentially) platform agnostic.  To assert that applications should instead rely on the OS and filesystem to provide this persistence layer is to assert that there is a universally appropriate choice of database -- a bold claim.<p>Moreover, if structure can (must?) be defined by the application which is interfacing with the OS, then nothing is gained but overhead.  Every object would need a description of itself, so we either end up with redundant structural information for every file, or else we have some centralized table of &quot;object types&quot; that the OS has to look at every time we request something.<p>Maybe I&#x27;m missing something, but I don&#x27;t see the appeal here.  I understand the desire to reduce overhead, but as far as I can see, this just creates more.