1. 8
  1.  

  2. 4

    Could somebody explain in more detail what the goal of this is?

    1. 1

      Not 100% sure but I can take a shot:

      We’re using bash to simulate a true Alan Kay style network of autonomous objects that communicate exclusively via messages.

      • Each object is its own process (this ensures it’s truly autonomous). It just sits there waiting for messages.
      • The file descriptors are the methods. The public ones are executable programs (100 in the example). Ofc, numbers don’t make great method names but this is a POC and that’s just a detail we can hand wave over.
      • You get enforced encapsulation using file permissions (eg, you could make a “method” executable but not readable)
      Why?
      • To emphasize that the deep, underlying idea of “objects” has nothing to do with a particular programming language
      • To show that the idea exists in unexpected places
      • Fun
    2. 3

      Could this be the basis for Poor Man’s translators? https://www.gnu.org/software/hurd/hurd/translator.html

      1. 2

        It looks funny :-)

        But to make it at least somehow useful, you would need to map the numbers (PID, FD) to meaningful names. Probably using symlinks. But then you can drop whole the process and FDs idea and use just symlinks and directories. The processes and FDs have IMHO no benefit here.

        Another approach could be writing a virtual FUSE file system, which would not store the objects/methods/properties on the disk but in the RAM – and you will have a single process that would manage your object world and then you could easily add some dynamism (add and remove objects, change behavior etc.). You can use also extended attributes for metadata and introspection.

        Everything is a file!

        1. 2

          Yes! That is the main idea behind this whole ordeal. I am pretty much aware that it is completely unusable as it is. I intend to prototype something more robust using 9P.

          I like that example, though, mostly because it summarizes most of my ideas on how object orientation should work in ways that I can’t even express in natural language. And if you look at it closely, there are a few takeaways that present interesting challenges to work on in the future. Here are some of them:

          • Processes are inherently concurrent. There is a chance that those examples are more closely related to actors than to objects, actually.
          • Method implementations are language-independent. As long as they are represented as an executable file, they will work;
          • A hypothetical language with better option parsing mechanisms would allow for Smalltalk-like method call syntax, for example, or maybe even something more sophisticated as implementing different DSLs for different methods.

          I expect to have the time and energy to have this pseudo-research come to fruition.

        2. 1

          If you’re going to create an object system with bash, associative arrays and functions seem like a more likely basis.