While there are parallels between Nebulo and Object-Oriented programming designs, we’d describe our system as ‘Semantically Intelligent‘ ( a system for establishing meaning and implementing machine behaviors in real-time ) instead of object. The ‘description’ of what the user wants in a behavior and associated data is the fundamental model.
Idea (Jy)
- Data structures are re-ordered, reformatted and translated into other Ideas. Ideas do not have the structure-alignment, static typing, and method model that typical OO Classes do. Using Is-a and As-a, we can make multiple inheritance and dynamic conversions, but all function association is handled separately, akin to ‘protocols’ or ‘interfaces’ in many OO languages.
Thing (Dz)
- Thing design is not a Class instantiated Object since it is designed around access control, via the Guard’s behavior/data. Unlike Objects, Things have their data structures split across various buffers and potentially cloned for multiple processor uses. Things do not have the usual Getter/Setter model for a single record but a universal time/variation key used to solve for ‘when the get/set can occur’ and if it is allowed.
- Things (Dz) are better related to OO ideas as a Collection of Objects, some owned ( unique ), some shared ( by group Thing ), and some default ( inherited ).
- Things’ primary role is to handle if and when a load, read, write, or sync needs to occur.
ID
- All information, whether a scalar, vector, or large dynamic collection, has a unique ID, similar to a URL, and provides for level of detail access to any property or larger container.
Dz
- All information is Guarded by a Thing (Dz). The owner, author, editor, frequent user, etc. can and likely are different Things (Dz).
- The takeaway is that all information has a Thing (Dz) which guards access.
Behaviors
- Actual Functions, which we call a ‘Behavior‘ if it’s written in Essence Meaning Coordinates (a system of terms and clauses) as Meaning Units and ‘Code‘ once the Essence Meaning Coordinates have been mapped into Qcode (cacheable nuggets of auto-generated adaptive computer code) and subsequently machine or emulated instructions. Behaviors use Context ( local data from one or more Things ) and Situation ( work-specific data, such as Subject/Object/Where/When/etc. ).
Thing (Dz)
- Can message other Things via using the same Behavior calls they might use on themselves. The resolution is transparent but does invoke that Things’ Guard and may return ‘not-allowed’ or ‘not-now, try-in-8ms’ or other replies based on scheduling read/write access and estimates.
Possibility Boxes
- All data is stored in Possibility Boxes which are built of collections of those data elements. The rules for how those collections behave ( FILO stack, FIFO queue, arbitrary set/bag, sorted by number/lexical/spatial/etc. ) are customized for each need. It’s like having all similar data stored in Relational Database Tables, but the tables might be uniquely arranged/accessed, such as signals.
Aptivs
- Packages or Modules in most OO models do fit our notion of Aptivs ( a package containing an Agent, Powers, Skills and Media ) along with additional digital content such as media, big-data-tables, and localization.
Dictionary
- Essence has no fixed set of keywords, just a dictionary with a bunch of synonyms/mappings-to-meanings.
Grok-Units
- Nebulo Behaviors accept 1 or more Grok-Units (units of meanings/beliefs), which are the input/output template for a Behavior that specifies one or more ‘to read’ or ‘to write’ Ideas (Jy).
Ideas + Behaviors 
@Starup
- Nebulo starts with over 500 base Ideas and close to 1,000 initial Behaviors, many of which are art styles or procedural generators for tables.
Data & Resources State Rules
- Collections separate Creation ( Allocate memory, flag as uninitialized ) is separated from Add ( Init, make available ), same for Remove ( deactivate, make available for Creation ) versus Destroy ( allow space to be reclaimed ).
- Issues of what a symbol maps to, order of precedence, and range of results are always explicitly defined for any Behavior.
- Nebulo doesn’t define a Null as in traditional OO languages. There are various ‘Not Available, Not Defined, Not Logical’ which are paired with a change estimate in time or percent done, such as Not Available having a percent available and estimated time to be done.
- Order and Constraints are explicit in every Behavior and every piece of Work done.
Additional comparison information that elaborates on how different Nebulo® is from OO paradigms:
- No Global Variables: All values have multiple-levels of discoverability/visibility/modification and a ‘when’ the reply will be available.
- Explicit Scheduling: Explicit Scheduling of when persistent values are changed prevents ambiguity on side-effects. Access time and a permutation number keeps parallelism valid.
- Persistent Values: Persistent values ‘considered’ as thoughts can pass thru a variety of code ( topics/actions that may modify the value locally, as per Functional Programming Paradigms ). Requiring an explicit ‘Remember’ to any variable change may seem cumbersome, but it is easy to automate and later analyze/understand in a parallel environment.
- Parallel Processor Distribution: Note that ‘parallel’ may be per CPU ( same die w/ shared caches or different socket w/ different caches ), per Processor ( CPU & 3 GPUs w/ Clones of same data synchronized ), or per Machine ( LAN, WAN, even slow exchanges like Cloud-sync/SMTP for exchanges, etc. ). Same principles apply as the latency of changes increases ( going from multi-core chip to WAN ).
- Type Inference: Type Inference is handled via assignment and reduction of use cases, implementing a Hindley–Milner type system.
- Concurrency: Regarding Co-routines in Concurrency, all Behaviors are executed in parallel, whether a separate Cooperative Fiber, Preemptive Thread, OS Process, or different Machine.
- Channelization: Regarding Channels, each Thing (Dz) can have 1 or more MessageBoxes (Smv) to use to communicate to each other, allowing user-level influence on how to handle responses to overflow of messages, unwanted messages, loss of response, etc. The protocol is a context clause or ‘GrokUnit‘ (Sx) which is one or more Ideas (Jy) expressed as the Grok Unit requires.
- Suspension and Resumption: All Behaviors can be suspended and resumed with the same state, if desired, like Knuth Coroutine, or can simply complete and be invoked again with fresh state, like a classic Subroutine.
- Translatable Data Structures: Our Idea (Jy) translated-data-structure model allows explicit Is-a and As-a relationships gives it a ‘manifest’ type system that could be also defined as ‘structural type system’. However, the ‘As-a’ aspect of translation allows a virtual-duck-typing or runtime-binded-typing approach in the sense that some Ideas (Jy) can be adapted to provide the structure members needed on the fly or via cache.
To learn more about how Essence manages data and machine behaviors, read the upcoming post on ‘Essence Data Structures‘.
Follow us on this blog, social media, and our website as we unveil more potentially world-changing solutions.
Leave A Comment