A next step is a system without I/O. Everything is just an object, memory-resident, locally persistent, remote. You simply do what must be done with the thing. Already with 64-bit address space it is no problem to have any object on any computer addressable.
TBH, 48-bit is more than enough.
Multics had persistency
The history of custom/high-level architectures is quite interesting.
I got my hands on a copy of the Intel iAPX proposals to extend Ada, and somewhere I have a PDF on the Objectiv processor.
I don’t think such a thing is feasible, unless you mean to insinuate subsuming I/O operations into objects or some analog — even pure-functional languages typically have an “escape-hatch” for I/O.
I mean the purpose of most I/O is to move object or its parts from one type of memory to another.
You seem not to understand “universal interfaces”. You’re not alone. For example a KDE folderview is easier to use from a user perspective than .desktop files. Also systemd in multiple ways but in particular it’s early logging was completely ignorant/dismissive. It’s a bit crazy how someone who hates Unix (Lennart) is payed/allowed to create a major Unix component.
I am a bit puzzled by the video when the argument against OOP is that messages can’t transfer references to other objects.
See a typical Java line:
public void paint(Graphics g) {
g is given as a reference…
Maybe I miss the point and lack explanations…
There is the problem about the graph of objects which must be a tree. If it is about classes, it is wrong. Many classes can use a File class for example. If it is about the class instances, I guess that in most cases, it is hard to avoid… OOP or not since a data is given typically as a global variables or a parameter and parameters are preferred.
There is an argument about the problem of too many little objects which displaces the complexity (managing a mess of many classes). I understand, but it is a common problem with many modular system, and can enable a good complexity management. Typically, a file system is typically OOP (polymorphic since you access ext3, reiserfs, fat32, ntfs with the same methods, encapsulation: the caller does’t bother with the internal complexity… only missing: heritage) and it helps to separate the complexity of the whole system.