Here's my understanding of the general idea (let me know if I got something wrong!). Say you have a bunch of computers with different software and hardware. You come up with a cool new image format called "PJEG". To get the images to show up on all the computers, you typically do the following:
* Publish a PJEG spec
* Define a .pjeg extension and let everyone know that means it's
a PJEG file
* Write a PJEG encoder/viewer for each kind of computer
* Distribute these programs to the computers
* Configure the computers to open .pjeg files using the programs
you distributed
* Modify other programs (image editors, web browsers) so they
can recognize, encode and view PJEG files as well
* etc...
This approach doesn't scale very well. I think the alternative Alan is suggesting is that you'd include an interpretable description of the file format in the file itself in a sort of meta-format. Once you have an interpreter for these meta-format descriptions, all you'd have to do is:
* Include an interpretable PJEG encoder/viewer with every PJEG file
And that's all! Any program able to read the meta-format could use this file without any extra software. This obviates file type metadata and reduces the amount of distribution you need to do, making the whole thing way more scalable. The practical problems with this solution (larger file size, slow encoding and decoding) can be solved in various ways:
* The larger file size can be mitigated by format negotiation
(if I already know about the format, you don't have to tell
me about it)
* Optimized encoders and decoders can be written to replace the
slower interpreted ones included with the file
Having the interpreted format description makes it easier to validate the optimized version, too (you can generate a bunch of random examples and make sure they decode/encode the same way). And this doesn't have to just be for files, you can use the same technique for arbitrary "data types" in your program as well.
Great example. I'll add that the "compile everything to Javascript" ecosystem shows that it's easily possible. Arguably, it's already being done for web stuff just not below a certain level of the stack. There were related fields that did this stuff called agent-oriented programming and meta protocols.
In agent-oriented programming, one could send the code and data packaged together to the remote site. It could do any necessary computation there through the platform's interface to prevent lots of data being transfered. It might also do typical RPC's on remote sites. As it was interpreted, it could in theory even modify itself to use a different communication or storage method.
For meta-objects, that was just ways to create other objects. Starts with stuff like CLOS and Smalltalk that's really about clever ways to specify systems. Also allows self-modifying or improving code. Later versions, applicable here, allowed one to specify protocols or interfaces that meta-tools would turn into libraries for one's programs. Some even had interpreters built-in so apps could negotiate arbitrary protocols during runtime. Such tech gets us closer to the idea of focusing on a higher level and how things communicate rather than their state and coding specific procedures for sharing it.
Not necessarily. That was one of the points Alan made in his AMA when suggesting 'send processes rather than messages'[1] That thread used the example of how to find things and then what to do when you find them.
This would require that any new image format only did things that were foreseen by the creators of the metalanguage. If the metalanguage is Turing complete then it's just an interpreter. Python, for example, could be your metalanguage. Then I would argue that we already have this.
