It is necessary, in building towards a Design Process Support Software Application, to design and program a Rules and Pattern System as an extreme form of bottom-up object-oriented intelligence (pragmatic AI) that has a direct relationship between perception and action without a guiding top-down intelligence.
When the designer is faced with the task of designing a singular object, not a widget (!), that he/she wants to design, he wants to do something creative, but not re-invent the wheel. He/she wants to design an object in a workspace with help from already existing components in a library database. Yet these components will not relate to the new singular object in a typical mechanical relationship of the parts to the whole. There will instead be an exciting, inspirational relationship of creativity between the existing components and the coming-into-existence new design. The relationship between library elements and new object is like musical composition. What corresponds to this suggestiveness and resonance in “new computer science“ (Alan Shapiro) is the radical OO coding of patterns and rules. It is exactly like sports where (1) rules are respected, (2) many previous patterns are known, thereby (3) playfulness is liberated. New computer science is based on a paradigm that combines engineering with art and humanities, rather than being just engineering.
The exact goal of this software development project is to demonstrate, in working code, and in a working client application, the new relationship between the code in the Engine and the software instance.
This relationship will be something new and different, powerful and valuable, that no other software has. It will be a qualitatively new relationship of similarity/patterns/samples between smallest data items and ALife software instance.
The structuralism that underlies standard OO and the “mechanical” way that the software instance instantiates itself from code in an engine is obsolete because structures in fact do not have a rigid, stable center. The center of a structure is wild, dynamic, self-evolving, unstable, creative.
The delivered software will consist of the following 4 packages:
- Logic Engine for Rules and Patterns Extreme OO New Intelligence.
- Logic Parsers for testing the operations of the Logic Engine.
- PSQL (Post-Structuralist Query Language for aesthetic operations)
- Test Client Application (ACAD – Aesthetic CAD)
The Structure class provides the basic repository, or data structure, in the Logic Engine. It is a functor associated with a group of terms. A functor can be any object. A term is either a structure or a variable. A structure is an aggregation of other structures.
The PostStructure class extends the Structure class. It is radicalized OO. Everything is a PostStructure in a Aesthetic Logic Engine.
A Variable is an object that has a name and can Instantiate Structures, PostStructures, and other Variables.
A Rule is an axiom, or statement of truth, or pragmatically simulated hypothesized truth, that has more than one Struture, or PostStructure. In a Rule, the truth of the first PostStruture follows from the ability to prove the remaining PostStructures.
A Program is a collection of axioms, which are Facts or Rules.
A Query, in the conventional “Building Parsers” subdivision of computer science, is a Structure that can prove itself against a program. For us, a Query is a PostStructure that can prove itself against an ALife program.
What does it mean to “Prove” a Query? The Post-Logic Engine proves a Query by aesthetically unifying the query’s PostStructures with Rules in a program.
To “aesthetically unify” means not to do a mechanical calculation, but rather to try out a series of hypotheses, verifying their facticity, their conformance to a set of rules. This establishes their truth in the way of a pragmatic simulation.
The Engine has additional features like Comparisons and Evaluations.
A Parser is an object that recognizes the elements of a language. A Parser is either a Terminal or a composition of other Parsers. I will write a hierarchy of Parsers for Pattern Recognition. The point is to do both standard Pattern Recognition (we need to have that in order to then build on top of it) and a new kind of Pattern Recognition that is non-combinatorial.
We will have a Parser base class, simple parsers for simple operations, then special subclasses of Parser that provide composite Parsers, to describe Sequences, Alternations, and Repetitions of other Parsers.
What we will have here that no one else has is an emergent property of Pattern Recognition arising from “Difference within Repetition and Alternation”. This subclass of the Parser class will be called Differance.
PSQL will resemble SQL. It will have SELECT statements, which implement a new, more powerful relationship among the metadata in the database. It will have JOIN statements for multi-table queries. PSQL will have a simple user environment application, showing Queries and Results.
PSQL will be influenced by list-processing languages like LISP and by Pattern Recognition and Robot command languages (two areas where AI has pragmatically succeeded).
The Centrality of Roles
The object-oriented ontology needs to be radicalized in the direction of Roles and of the autonomy of objects.
The attributes of software classes or software objects are containers of data. Data is a consequence of a subject-centered worldview. Data is reductionist. What we want is a Gestalt of information. An informational field that is the true opposite of chaos, rather than a compulsive need for order in precise information.
The object-oriented model has no real appreciation of time. A class is a blueprint of an instance, and an instance is culled from classes one single time, at construction. It cannot modify itself during the real-time activity of the program, of the software system.
We need a software instance that it is a state of “not knowing.” This makes it alive (almost sort of human). It goes along being alive without being so precisely defined. It picks up its definition in real-time, during the live in-play of the system.
Therefore one can say that may roles are available to the instance. It is existentially free to “choose” among all these available roles.
The system does not define classes, it defines roles.
In the current OO model, there is a kind of Sartrean bad faith going on. The object is fixed or pinned down to its identity.
The object should have no identity. Everything that it does is a “performance.”