/prog/rider's secret society

We should create a club/lodge for programmers. If stonemasons created one many years ago just because they knew how to carve stupid stones and build some basic structures, why we still don't have one?
This is what we need:
◦ A symbol.
◦ A secret handshake.
◦ A set of rules.
◦ An unknown leader.
◦ An unknown sub-leader.
◦ A library with exceptional computer books, a printed version of world4ch's /prog/ (aka The Old Testament), ancient computers, and other relics.
◦ A list of heretic languages carved in stone.

>>49
That was beautiful.

To some extent this is done with files. A file is an encoding of some arbitrary thing, where the arbitrary thing is realized once a specific program is used to load it and present it in some way. A lisp data structure is some sort of tree of arbitrary objects, and not that different from a file system with various files stored in various encodings. The file system is clunky, restrictive, and not approachable to the typical user. But it's layout is standardized. I can always move one file from one location to another. My file system checker knows how to check for errors in the file system. My programs all know how to interact with the file system using a basic interface.

In a lisp system, the file system doesn't need to exist. The objects that are normally dormant sitting in encoded files are alive and ingrained in the image of your lisp system. They pass between ram and persistent memory fluidly on a need basis. Perhaps the lisp system uses a transaction system for checking out and committing objects. I was planning on finding a few disadvantages to using this, but now I can't. Perhaps the only reason this isn't the standard today is that the current system is good enough, and if we want something like the lisp system, it can be layered on top of the current standard as a user process that stores its image in a file.