Gospel of Data Ecologies - LeFreq/Singularity GitHub Wiki
STUB Much of the former content here has been moved to the GOOP.
The computer is generally a serial-access, Turing machine accessing a single datum at once, so the presence of an array is already a signal that a poor architecture is in place, because no computer and few programs use data in such a way at the engineering level. Even a database table hardly is the natural form of interaction, other than data that is integrated like an excel spreadsheet where numbers are added together between rows.
NewStudent >> UniversityRegister
Since this is a unified model, Universities can trade these records over the internet without changing anything. Further, Presidents can collate data across universities to see what skills are available for very high level understandings.
data, informatics, knowledge understanding, wisdom, satori
>> NewStudent = Name("First Unique Last") >> Name >> Database: #ERR: duplicate name.
>> >> NewStudent >> PLU >> Student(Person, Classlist, ) >> 1999Roster,
With contracts, once objects are trusted, you can set the TRUST level (between, say, 0-255) for each object group (objects, say, from the same programmer or source) and the code will check once every 256-(TRUST+1) times (or some rough heuristic), that contracts were met, rather than lose processing time checking contracts pedantically.
This also may get rid of naive try..except blocks that show a lack of epistemical knowledge. Contracts can be used instead to ensure things are tight and secure, not loosey-goosey.
Needs statements also allow the posting and possibly specification of function requirements (like a RFC), so that a coding team or the data ecosystem itself can answer it. How does it answer it? By writing doctests that meet the specification. BOOM.
The GOOP on OOP.
After Guido kicked me out from the list a few years ago, I went underground and developed the following. It is hoped to be a complete manifesto to accomplish all of OOPs goals. If you feel something is missing, you can join the project at github.com/thePastor/PositionOS. Enjoy:
NOTE: This document distinguishes between two main primary object inter-actors: programmers (who code the objects) and "users" (who use these as apps). This is an important distinction in a data ecosystem where objects can be apps and all apps are objects.
- Modularity: Objects are encapsulations of code + data contained and labeled with a unique LABEL. Otherwise known as "encapsulation". Objects that don't have data are called lambdas or mix-ins. Objects that don't have code are called arrays or structs (or tables for you DB users). And without a name or label, don't call it an "object".
- Open: Objects should be open source, so that others can modify them, fix them, and inspect them. This creates the ecosystem where everyone gets to benefit from everyone else, allowing only the BEST to emerge, rather than a plethora of competing, closed objects fighting for the same functionality.
- Applicability: All objects should be useful enough to turn into micro (or major) applications, via the run (1/object) method, otherwise what good is it? If it is not useful enough to create a micro-app (like a String object that holds a byte-array and simply outputs it as an ASCII string), don't pollute the ecosystem with it. Let it do something interesting, so other user's will want to interact with your object. This also gives objects another way to be understood with a quick review.
- Well-rooted: It is a grave error to attempt great ontologies of objects starting with Abstract Base Classes and building towards specialization. This is backwards. Just as a raindrop forms around an impurity in the air, form your objects around the machine types. Save ABCs where there is NO relationship to your data ecosystem (like container objects or graphical simulation objects).
- Loosely-coupled: Users should be spared programmer idiosyncrasies as much as possible. That means all objects in the ecosystem should conform to a uniform syntax, rather than have custom APIs for every object. Just as there are only 26 letters to handle the entire corpus of English text and 2 numbers to represent any quantity, in this gospel, there are only two methods needed to create any object behavior: receive (>>), send (<<). Between these two methods, the object NAME, and the return value, these give every programmer a uniform way to relate to every object. No more guesswork that makes you feel you're wearing another programmer`s underwear.
- Needs a Hardware Abstraction Layer (HAL): Being well-rooted in the machine types but loosely-coupled means that the perfect ecosystem has a fungilble middle layer that allows user-programmers to "plug-in" their objects to their hardware via other, machine-specific objects without sacrificing modularity, re-useability, or functionality. This also saves the users who get to keep the same EXACT application suites on different hardware.
- Substitutability: You should be able to use an object on the right-hand side of an expression, like any variable. Each object should have a piece of canonical data returned from the object. This should be affiliated with the object`s SWEAR contract. It could be the cursor of a database object or properties of a window object, etc. (Python: This is their REPR data, which differentiates itself from the STR data which might be output with the run method.)
- Contractually Guaranteed: To make things easier for Users, particularly of foreign objects, specialized keywords to create input contracts (like "implore") and output contracts ("swear") 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 programmers on the network can know about it and fix it. "Needs" keywords can specify what another object requires and be posted in the data ecosystem, to see who fulfills it.
- Trustability: To make things easier for Programmers, runnable documentation should be available in the object. Programmers shouldn't have to wonder about the stability of foreign objects (or their own) amidst changes they may make to them internally. To this end, DocTests are the sugar you want with your objects.
- Inspectable: Since, objects exist in a larger ecosystem rather than simply apps, there are two other methods to make life easier. One of these is the query-state operator ("?"). This will return things like whether a file is open or closed, whether a network socket is open or not, an application is running, and so forth. This is different from being "open" (a separate item above).
- Copyable: Objects should be able to be copied so they can be re-used in other applications. This is the other method for all objects. The clone-object (%) operator will give a deep-clone of the object down to where machine (hardware) dependencies exist.
- Indexability: Environment should be able to generalize objects such that they are containable in a "meta-objects". These objects have an additional method or "operator": the index [].
- Metadata: Since all objects should consider themselves members of a data ecosystem, they should contain metadata. Minimally: point_of_origin (an Internet address to get new versions), version #, PayPal_ID (programmers want to get paid).
- Version sanity: Object versions which break compatibility in some way should increase their major version number. Versions which do not break compatibility should increase a minor version number. This also lets programmers know how much other programmers are thinking through things. An object at major revision 41 probably doesn't know what they're doing. On the other hand, it might show the object is more mature...
- Easy-to-use ecosystem: To make things simple, all operators in the object model should have correlates in the ecosystem that perform similar functions. This makes it easy to use. All operators should be generalizable such that they are useful outside of objects and in the data ecosystem itself. OThe can also pass data into (">>") and out of ("<<") their host environment (as a sort of "meta" object), or query ("?") that environment to get system version and perhaps enter the help system.
- Initializable: Objects should be able to set at object start without having to "fill" the object after instantiation. 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.??? This was to make use of optimizations available at object creation, but may be irrelevant.
- Compositable: Instead of inheritance, objects are composited: pasted together to create larger functionality, much like Unix did for command-line utilities. Refining your datatype (as the programmer) generalizes it towards the user who works in app-space, not code-space. Programmers create super-objects: object mashups, allowing the cross-fertilization of object traits into re-useable, higher-level applications that are also their own object.
- Hosted: A data ecosystem needs a uniform hosting environment for all users. This host environment should provide built-in "meta-"operators that make it easy to inspect, edit, test, and understand objects: "&" (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.
- Tight-coupled documentation: Besides a well-thought NAME, objects should have docstrings to describe what the object is useful for. Language should support tying documentation to objects, like Python docstrings. An object's doctoring and all subobject`s docstrings should provide a clear understanding of what the object is going to do. Separate manuals not desired. Between the name of the object, it`s DocString, it's behavior when run, and the doctests you have everything you should need to know what the object does. Each one of these is stays with the object via the programming language syntax.
- 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.