Home

To operate your hackerspaces, use the Business Plan. I may get time to rewrite it (ping me).
To start your own game that will "self" organize your organization, check the World Game.

This project is spawn off work done to create AI using a self-generating, self-organizing network of "neurons". Because AI deals with many key concept related to epistemology and metaphysics, this work can be re-applied to other domains, like economic theory and social intelligence, etc.

While it may seem that the project is too simple to create generalizable intelligence, that is not the case. Just as the complexity of the Mandelbrot Set is produced with a simple equation, so can infinite complexity be organized and generated by a few simple concepts. A mathematical graph, for example, and one of the main data structures you'll find in the project gives you 1.1Trillion possibilities (unique graphs) in just 20 nodes (approximately 2²ⁿ). This is significant because it means we can store information deeply with just a small network. Add another dimension of order by placing those networks in a node of another graph, and you have a complete system of mind. The network is the knowledge, making AI a tractable problem.

The real home page is here. But put your finger to the wind and listen to this...

GOSPEL OF OBJECT-ORIENTED PROGRAMMING (GOOP)

Note: this taken from hackerspaces wiki, so any broken links are at the original wikiwikiweb.

OOP has gotten very confused. Besides reaching a plateau of "everything is an object" which it doesn't seem to know how to get itself beyond, it has never reached even it`s noble goals of re-useable code. That had been one of the goals of OOP, not theoretical purity.

This page is to help sort out the confusion that you undoubtedly have, because the whole field is confused. Most programmers thought you should simulate real-word objects (Square is-a Shape), but most programs are not simulations. No, the real value of OOP in the age of the internet is going to be massive amounts of data processing (exabytes) into elegant ontologies of knowledge. In other words: data itself is the gold we're looking for -- the fundamental value-unit.

• First, you must realize the ultimate nature of data: that (betwixt random numbers and NULL), it relates to something, it does not exist in isolation to everything else. It has it's own nature.
• Then, you shall realize that every datum relates to all other data: you just haven't discovered it`s place in the ontology. Your file system has been acting as a buffer for your ignorance and passivity. Your applications, pimping up your data. Discriminate between the tasks of processing, presenting, and storing data and start your ontology. Keep the latter as meta-objects or "containers".
• And finally, that the ultimate machine for such an ontology is a unified, 3-dimensional visualization model where the language is the OS. But then, you ask.... how? See the PositionOS project at GitHub.com

---

BEGIN:

1. Objects are discrete encapsulations of code + data contained and labeled with a unique LABEL. Objects that don't have data are called lambdas (Python, not LISP) or mix-ins. Objects that don't have code are called arrays or structs (tables for you DB users). And without a label, don't call it an "object".
2. The object domain (or DataEcosystem) is a nascent field, but there should be noted only two kinds of object interactions: users-of-objects and makers-of-objects. The former I'll term users (sometimes: higher-level "applications") and the latter programmers. Programmers are also users, but users are not always programmers. Applications never are -- in this context, these are sometimes called mashups. The point is that there is no canonical way to refer to a object syntactically (uppercase vs. lowercase, e.g.), as there will always be more than one kind of relationship to it.
3. It is a grave sin to attempt great ontologies of objects starting with Abstract Base Classes and building towards specialization. This is backwards (cf. single-table databases). Start with concrete base classes, like int, and let those hierarchies grow in the other direction (like an object Rational holding an abstracted concept for number that hides machine limitations): the application the user sees -- not your personal relationship to the code. Just as a raindrop is said to form around an impurity in the air, form your objects around the machine types. Container objects (objects holding objects) are then meta-objects where ABCs are appropriate. Here's a guided meditation. NOTE to self: Rational IMPLEMENTS int (duplicates functions), IS-A copies functions/properties, IMPLEMENTS copies functions, HAS-A contains data. Dict IMPLEMENTS Set but NOT IS-A Set. NO. Dict HAS-A Set? NO. Dict IS-A Set: it is a superset of all set`s functionality.
4. Users should be spared programmer idiosyncrasies as much as possible. That means all objects in the ecosystem should conform to a uniform syntax for data passing, rather than learn custom APIs for every object. Just as there are only 26 letters to handle the entire corpus of English text, there are only five functions (4+1) needed to handle every object need: query-object (?), clone-object (%), receive (>>), send (<<), and run (1/). Some of these may take one parameter, like the >> method, to return an indexed data object. These operators are meant to scale all the way up so that, for example, the user/programmer can also pass data into (">>") and out of ("<<") their host environment (a sort of "meta" object) or query ("?") that environment to get system version and perhaps enter the help system.
5. Each object should contain metadata to store: point_of_origin (an address to get new versions), version, PayPal_ID. Further each object should have a piece of canonical data returned from the object when it is instantiated or run within code (w/out a window). This is affiliated with the object`s SWEAR contract. In this way, objects are supercharged variables, except you don't assign to them, you pass data to them.
6. Object initialization can take any serial data stream (like reading a file), and whip it into the construct the data was designed for (a video, for example): VideoMP4("\marshalled\media\myvideo.mp4") will load and initialize the object. That construct can then be interacted with through the special five methods. >> might allow you to add frames to the video, for example (frameData >> myvideoobject), or maybe the object is a player and will queue up the item. Metaclasses take any other type and spit out another class.
7. Object compositing. Specializing your datatype (as the programmer) generalizes it towards the user who works in conceptual-space, not code-space, just like Unix did for the command-line utilities. To create this, programmers create super-objects: object mashups, allowing the hybridization and cross-fertilization of object traits into re-useable, higher-level applications that are also their own object.
8. Every object should be able to be run (1/myObject) and do something interesting, except for containers (meta-objects), otherwise what good is it? The method handles this and takes the object from the programmer`s perspective and flips it into the user`s perspective -- a little micro-application. This understanding between users and programmers clears up various ambiguities like Python's str() vs. repr(). Str() is for the user and repr() for the programmer. Here is where you ascend to be the master of data. For example, invert your video object and a window appears playing the video. Do the same to a table of data, and a nice pretty-printed tabulation of the data might appear. Or maybe an object just outputs a text fortune cookie. In any case, let it do something interesting, so other user's will want to interact with your object.
9. The host environment should also have built-in meta-operators that make it easy to test and inspect objects: "#" to set a function in the host environment, "!" (followed by the object name) for testing and validation, "<<" saves an object to your local environment, ">>" publishes it to the world at large, "?" for examining all the docs for the object, "@" to message another node in the p2p network, etc.
10. Users shouldn't have to wonder about the purpose of foreign objects or objects within a complex object hierarchy. To this end, DocTests are the sugar you want with your objects. Languages with optional "DocStrings" are the best idea. This way you get documentation also--an essential part of the data ecosystem. Between the name of the object and it`s DocString you have everything you should need to know what the object does. See also TightCoupling.
11. Users also should be able to trust other objects. Specialized keywords (like implore (input contracts) and swear (output contracts)) can ensure that everything is acting as it should when you're not looking. A shared global purgatory can store objects whose behavior did not match their sworn contracts, so everyone on the network can know about it (and try to fix it).
12. Since files are a just a '''type of data''', you can create a whole shell and windowing OS with the above. You can set aside EMACS, you can have LanguageAsAnOS! Applications can be created and started by compositing objects. Your language and the OS are one with the application. The kernel still has to handle how to store all the data, but that's a different problem.
13. Boom, you're the w0/man. Now go find the GlassBeadGame at sourceforge and help make it a reality.

Any bias towards the language in the foregoing of Python is due to the fact that it is the furthest along in providing the tools for a data ecosystem. So please overlook such bias as any language that offered similar ease would be equally chosen for the host environment.

So to clear up some long-standing confusion: a "class" is a "type" until it's instantiated into an "object". In come languages (like Python), a "type" is a "class". Metatypes (aka metaclasses) are classes that take other classes and spit out another classes. These classes have to be initialized to be used. Metaobjects are objects that hold other objects (aka containers). In some languages they are already initialized by special syntax, like "[]" symbols. This is an important new term to distinguish object relations in languages where "everything is an object".

If all this is a bit much for you, steer back to the OneTruePath. If it's not, get ready for the next Object Revolution!

Here endeth the lesson. Please return to your seats.

---

The outer design of the OS has 10 commands, or so: HELP, TEST, GROUP, RUN, SET, MSG, CLONE, ...

• To publish: >> GROUPNAME
• To intern (permanent storage): << MyObject
• To install or duplicate an existing system: %NODENAME
• To test all objects: !NODENAME
• Query another node: ?NODE
• To message another node/group: @NODENAME
• To set an environment variable: #VAR(VALUE)
• To list all variables or ones in a particular namespace: $, $namespace
• To edit an object: &MyObject

Input messages from OS:

• New Object available ObjectName from NODE, Docstring.
• /NODE "Message text."
• Query from NODE.
• Object fail: ThisObject.
• 265 objects on system. (when another node does a dir on you).
• 715 objects copied.
• Startup done. 1032 objects. Would you like to test objects now (Y/n)?
• Done. (SET without any parameters, saves memory objects to disk (flush to disk).)