Everything Isa File

The concept on *IX file systems that everything, including system devices, are files. For one, this makes it much easier to programmatically address any object on an *IX system. -- JonMadison

PlanNineFromBellLabs takes this concept much further than any backwards Unix. But it doesn't matter since everything is a file is an inherently backwards criterion owing its usefulness to backwards languages (C/C++) and backwards communications protocols (TCP/IP)­.

A system with a modern language like SmalltalkLanguage, and modern distribution protocols (SOAP) replaces the backwards "everything is a file" with the more sensible Everything Is An OBJECT.

Everything is a file is a crutch for systems that simply aren't OO in any way, shape or form, but want to buy into some of the advantages of OO. Everything is a file is "everything is an object" for retards who haven't joined the 1980s, never mind the 21st century. -- rk

To get the historical details right: it was a reaction to the older universal approach of having multiple incompatible file types (ISAM etc), each of which required a completely different method of programming in order to just plain read and write them. Typically a different COPY program was required per file type.

What it accomplished, back then, was to make the OS interface polymorphic, by having just one type of file (a stream of bytes), and if further structure (e.g. ISAM) was desired, then individual application programs could layer that on top of a byte stream.

So it had nothing to do with the language nor with communication protocols; it had only to do with fixing an older problem with filesystems themselves.

Modern operating systems that do what you desire: treating files as object streams (actually only NextOS did that, as far as I know), do this again by layering on type of the byte stream, not by taking the backward step of making all files incompatible again.

Here's the test: can a COPY utility ("cp", in Unix) be trivially written to read and write files, no matter what objects they are composed of? This should, of course, be possible. Next test: does it require the OS itself to be aware of the object's definition? If so, that's a design smell; information hiding should mean that I should be able to keep my objects private, and not have to explain them to the OS.

-- DougMerritt

Your comments explain the situation with early Unices. However, PlanNineFromBellLabs was made in the 1990s, long after Smalltalk-80 had come around. I still say that DennisRitchie is an idiot who missed out on OO under the excuse of creating a perfect Unix long after Unix had become completely obsolete.

• I have kind of wondered about that, but to give due credit, at least he didn't completely stop with Unix, which would have been typical (how many people do more than just one big innovation at different periods in their lives?), but instead at least took the additional step of eliminating ioctl in Plan-9, completing the EverythingIsaFile plan.

• Processes are not files in Plan9­. They're represented by files but it's impossible to clone a process by simple copying of the files that represent it. Therefore, it's false that everything is a file in Plan9, and so Plan9 is a failure even at its pathetic design goals.

It's completely irrelevant to me whether you can write a trivial copy program for trivial objects. What matters is being able to clone objects no matter how complex they are.

• Yes...but I mean to say that trivial copying should be trivial, otherwise it indicates a problem with the grander scheme.

An object is a subgraph of the total graph. The object graph is completely general; it can describe ANYTHING. This is NOT the case with mere streams of bytes. Therefore, streams of bytes are retarded.

• As a systems programmer who has implemented more than one OO language, I tend to be more keenly aware that OO is a layer on top of raw RAM bytes, implementation-wise (with the exception of the i432 processor, which was a dismal failure in both design and implementation).
• Similarly, OO databases use commodity disks that offer mere blocks or byte streams at the low level; no one requires special disks to get the OO database implemented. Good thing, considering commodity pricing.
• There's a good argument that raw streams of bytes shouldn't be exposed to the user nor even the applications programmer, but so far they turn out to be a very handy thing to expose to systems programmers.

• Exposing pages of bytestreams is a good thing for raw RAM, yes. The same for networking since any decent network protocol must be implemented over the low-level bytestream. But that's because that's what the hardware provides. Sticking to bytestreams at a higher layer is as backwards as sticking with GOTOs. In fact, bytestreams are NOT sufficiently general abstractions to construct every possible data structure the same way that gotos can be used to construct every possible control structure. IOW, bytestreams are worse than gotos.

If you're smart, you build your classes on top of the object graph because then your objects can be anything. You don't need to explain your objects to the OS because "subgraph of the graph" is all it needs to know. There is NO excuse for settling for flat streams of bytes. -- rk

Terminology question: you're using the term "the object graph" as if it is capitalized; which page should I look at to refresh my memory of what you are referring to? -- ?

The object graph is just the directed graph of object references. This includes whatever special features (like PermissionFlags) you build into the object references. It's a term used by the e-rights people in their pages, though they include no special features at all.

Back to bytestreams. Not only are bytestreams primitive, not sufficiently general and powerful, but they're also horribly inelegant. This is because bytestreams are an incredibly special special case.

Think about it. You've got your basic operations on a node; add a named vertex, replace the vertex associated with a name, remove a named vertex­. So how do the typical file operations map to them?

• You can append to a file but you can't prepend before it.
• You can neither insert nor delete bytes at a particular location, only truncate a file or append to it.
• You can't add bytes to negative locations (..., -2, -1).
• You can't delete bytes 100-200 without renaming every single byte that follows them.

The first two are completely arbitrary (read: retarded, for retards by retards) limitations on bytestreams. The third is only a bit more complicated. The last is something else entirely. It's a fundamental limitation of bytestreams that they are contiguous. Remove that limitation, generalize bytestreams, and you've got a completely different data structure. One I plan to build into my object graph as a special case.

In GrandUnifiedCapabilities, I will use no bytestreams. I will use sets of byte spans. They're the null vertices in nodes. -- rk