Instrumentation Development Environment

Disclaimer:

This is all way out on a limb, but I had a few thoughts and I wanted to write them down before I forget.

Parts of this design are 'simplified' in an effort to make the plan understandable to everyone. If you are a programmer, you may find that some of my definitions seem a bit incomplete, fuzzy or blurred. For example, the dividing line between Storage and Memory is more philosophically than physically (hardware) defined.

On the other hand, it might just be that this design is incomplete, fuzzy and blurred, like wayward thoughts hanging from a gnarled limb and twisting in the wind ...

Introduction:

An "Integrated Development Environment" or IDE contains everything needed by designers and programmers to create an application. This design is an attempt to organize the functions of a programming language and the operating system that supports it into a single vocabulary so that user macros, shell commands (or Job Control Language) and program code could be written using the same commands. I'm basically attempting to follow the BeOS® model where the user interface is just an extension of the application programming and system programming interfaces.

This design should have all of the same facilities available in any fully developed IDE, but those facilities will be organized according to the Instrumentation philosophy. The order of the types below is not the order that I originally chose. I would have made Programming the dominant (Supremacy) type, but that didn't fit the apparent internal/external nature of this Instrumental design.

This design can be considered a part of the Circular Desk. This design should contain the low level facilities needed to implement the functions in the "Application" column of the "Tech Support" table. We are also documenting the further evolution of the Problem Solving, Program Design, Glyphic Editor, User Interface, Programming Design Patterns, Information Theory and Units of Control technical expansion series.

You may notice an absence of programming terms like 'and', 'or', 'xor', 'if', 'else', etc. This is because these 'programming primitives' already exist within the Syntax Block. Links will exist between different parts of the Specialization index, but it would be wasteful to use a four-chord Specialization term to represent a one-chord Articulation term.

Beyond Demographics and Privacy

If Instrumentation becomes the "One True Universal Interface" (do you hear voices singing?) there will be an enormous opportunity to collect demographic data from a global source. This can be a source of valuable information about local and global preferences that can help Instrumentation and all of the services that use it to improve their "User Interfaces". 

The flip side is that personal information should never be taken from an individual without their consent. In case you are worried, the current free application does not collect or report any information at all.

Instrumentation usage and preference information should be 'bought' openly from the users. The payment need not be money, it could be technical support or some other client/provider relationship enhancement. The user should know exactly what information is being collected and be able to disapprove the addition of new parameters to the monthly(?) secure update (or quit altogether). 

The compiled statistics should be available to psychologists, sociologists, linguists, gossips and the general public. The data should be partitioned by language, country and geographic region for comparative studies.

This process must be completely open and established with the user at the beginning of the opt-in relationship (however that relationship develops). The whole relationship should be as transparent as the Debian popularity-contest.

Realistically the user 'term usage' statistics would look something like this:

We really don't care what you are saying, we mostly just want to know which words aren't being used so that we can optimize the basic vocabulary. If you don't upload your usage statistics, your favorite words may get shipped up-level to the vast Specialization wilderness.

Preference data would look something like this:

If the preferences are backed-up online, the user should also be able to download and reinstall them if they get stomped.

The user should be able to view their most recent data update and their total usage statistics to date. This data should be maintained by user GPC within the user's hardware, but aggregated to maintain user anonymity before it is shared with others. Security would be handled with double key encryption. Trust must be established and maintained for this system to work.

If updates to the user interface are driven by user interaction statistics, the whole system can evolve more quickly and surely. "Beyond Demographics and Privacy" lies mutual advantage, one would hope.

Other Considerations

These are features that I have mentioned in other designs. I'm collecting and organizing them here to make sure that all my designs appear to have a vague semblance of cohesion. The taxonomic hierarchy below is only one possible view of a vast, complex and extensively interrelated structure. We start with the Client because that is where the money is.

• Client satisfaction
  
• interface design
• intuitive experience facilitation and expectation setting
• what client can and cannot get
• program functional specification ('program specs')
• with client final approval
  
• order management
• requirement priority and scheduling
• requirement tracking
• bug tracking
  
• Quid pro Quo
• price and delivery date
  
• Design patterns and "Code reuse"
• Macros - a recorded sequence of user actions
  
• Programming by example
• can use macro templates to simplify automation
• Templates - a code shell for a generic algorithm or process
  
• code sanitation and wrapping
• can use macro with "variable substitution" prompts for template customization
  
• Wrappers that allow anything to be treated as a function
• define start and stop points
• define input and output data
• document the above to facilitate "Code reuse"
  
• Code
• Code discovery
  
• SQL
• Regular Expressions,
  
• Design pattern Taxonomy
  
• AI* heuristics
  
• etc.
• Code reuse
• templates
• wrappers
• system facilities and methods
  
• Code entry
• macros to facilitate "Code reuse"
• Debugging
• error reporting with trace data
  
• compilation information, warnings and errors
• AI* for real time program memory space analysis
  
• syntax checking, parenthesis matching
• execution with breakpoints, single stepping, variable 'printing', etc.
  
• Testing
• regression
• benchmarks
• baselines
• client sign-off
• Application versioning and promotion
  
• with test, final (client) test and production access and data
  
• Data
• Raw Data (unordered and quarantined)
• Data sterilization, partitioning and packaging
• Information
• Metadata
• Organized and sanitized data
• AI* and statistical analysis
• Visualized correlations
  
• Objects
• Application objects
• user data
  
• User Interface objects
• GUI, WIMP, etc.
  
• API objects
• System interface
• File I/O
• XML and other format conversion
• Indexed file access (fast, cheap)
  
• Database
• Graphic, Mathematical & Logical primitives
• Event objects
• schedules
• milestones
  
• Entities (Objects that act, change or exist independently)
• business or social
• clients
• employees
• markets and prospects
  
• mental
• efficiency and quality
  
• regulatory
• accounting
  
• physical
• plant
• real estate and property
• product
  
• User Interface (input and output)
  
• Video (any visual)
  
• Audio (any audible)
  
• Kinesthetics (any physical)
  
• Artificial Intelligence (AI)
• User Feedback
• bug reports
• change requests
  
• user metrics
• privacy
• 2 glyph Galactic Postal Code (GPC)
• 4 glyph public key
• 4 glyph private key
• System
• Status and dashboard
  
• Status discovery
• co-workers
• deadlines and milestones
• system and application status
• workloads and delay resolution
  
• Status scheduling (multiple interrelated schedules)
  
• meetings
• vacations
  
• Efficiency monitoring interface
  
• Status update
• Out of Office, leave a message
  
• Interfaces
• Communication
• Data input and output
• Identification and authorization
• Efficiency optimization
  
• Help
• Technical assistance and AI*
  
• Documentation
• Documentation entry
• Documentation discovery
• Utility
• Find and replace (etc.)
  
• Execute Macro
  
  

This design uses the following eight Types:

External Interfaces:

User Interface

This is where commands originate and results go to die.

The User Interface includes video, audio, keyboard, mouse, joystick, game controller etc. These are the facilities that translate formats and handle the user interface. This is in the Supremacy slot because the user should be the alpha and omega of system design and operation.

Communication In/Out-put

This is your portal to the outside world.

Everything coming in and going out should be checked for problems by the system "border guards". All input should go to a quarantined Storage area until it has been completely pacified and 're-educated'. Any downloaded executable entity should be initially run by a restricted shell in a protected "sandbox" until it's behavior has been adjudicated as safe.

System

Begging for access and promising to be good.

The System stops you from doing things that are hazardous to the system (hopefully). This is where you obtain resources (CPU load sharing, memory, threads, environmental variables, etc.) needed to accomplish your task.

Storage (persistent)

Storage contains files, data bases, serialized objects, etc. These contain the results of your past work and the data needed for your future work.

This is the Peril slot because of the potential for data corruption, data theft, and data loss. Storage should be well protected and have multiple redundant backups.

Internal Facilities:

Programming 

Making the system deliver what the user wants.

This covers the Programming commands for things like sequence, selection, iteration, alternation and parallel. This is the part of a program that tells the system which part of that program will run next.

Programming also covers the use of source, executables and modular libraries for actually running a system.

Memory (ephemeral)

Organizing information that only exists for the life of a program.

This covers program 'variables' like integers, strings, arrays, linked lists, trees, maps, vectors and other temporary data structures including the non-static parts of objects. This data may be read from and written to Storage, but it requires dynamic resources (such as RAM) while a program is running.

This is the passive part of the meta-data storage and code classification (design patterns) functions. (see Glyphics)

Glyphics

Manipulating Glyphs as active variables and functions rather than passive numbers or terms or graphics. The entire system is designed to operate on Glyphs by means of Glyphs, so Glyphs will also be used as passive data, but this type is focused on 'flexibility' rather than 'value'.

I have to admit, this is somewhat of a blank space at the moment because the framework is still so new, but I'm assuming that his will be the Artificial Intelligence (AI*) part of the IDE. Since each Glyph has a documented function, the system can guide the user through program creation.

This is the active part of the meta-data maintenance and code reuse functions.

Math & Logic

These are the most basic bit manipulation facilities.

This is the reason computers were created in the first place. Gaming, email and word-processing weren't even considered and the internet didn't exist. Nowadays, this is the invisible (to the end user) under-carriage upon which everything else rides.

This block would require the Business, Science, Sport, Leisure, Education and Art laths. That would put it somewhere in the #DD Specialization area.

The terms are organized into four tables, each containing four sub-tables (or banks) which consist of sixteen cells. Each cell contains a term,  command, a keyword or a link depending on usage.  The headings before the four tables below and the (unique) element combinations that define each sub-table's purpose show the External Interfaces divisions. The four dark rows within each table separate the the sub-categories or banks and contain the (repeating) four Internal Facilities element combinations that define the meaning of each individual cell.

This design only shows positive terms. Negative terms would be the opposite of each 'passive' term listed below. If the term is 'active', the negative form will invoke the function or be used to capture the state or current Value.

Cell #00 contains the name of this block of terms, it is used to create the Specialization "Table of Contents". If you select cell #00, you will lock-in this block of terms and you will need to unplug Command Mode to exit, even if these terms aren't commands. I can't think of a reason to select cell #00 that doesn't involve using the Table of Contents to lock-in this block of terms, so I don't see this as a problem.

The "Basic" sub-table is the default because that is where the most common terms should reside. These are the "Left Hand Only" indices (#0[0-F]). The "Right Hand Only" indices are the first (#[0-F]0) terms in each sub-table. Notice also that '5' and 'D' are the most awkward finger combinations so they are used for less critical events (ideally).

These tables are incomplete because I am still looking for the 'best' terms and organization (and this is all just a mock-up anyway).

Basic Facilities

The first table does not have either the Communication In/Out-put or User Interface Types. This table contains terms related to basic programming idioms and facilities.

Communication, Privacy and Security

User Interface

Artificial Intelligence

The Four Internal (Yin) Articulation functions Delineated

I have touched upon these concepts from another angle, but I think that this design is where the rubber really starts to meet the road. 

I'm skipping the four external I/O functions because they are basically the same as any other system ever (with or without glyphs), and the Communication table handles them nicely.

Details:

A general AI would have to manipulate tautologies. All systems of tautologies should have some similarities in the ways that an individual axiom forms interconnections with other individual axioms and with interconnected groups of tautologies.

Instrumentation can reduce a basic axiom to three glyphs (or less) and thereby efficiently encode an interconnected ontology. Since all glyphs are (theoretically) inherently and numerically classified into their own connotative domains (as Areas, Divisions and Blocks), developing strategies for generalizing and extending relationships should be simplified.

• Extrapolation
• Generate 'new' Axioms
• fill in axioms implied by other axioms (imagination)
  
• test random axioms (inspiration)
  
• test exploratory axioms for potential relationships (inspiration)
• Interpolation
• Construct axiom webs (classification)
  
• Identify axiom trends (codification)
• trends are then extrapolated with exploratory axioms
• Recognition
• Match input to any existing data (classification)
• Supply internal queries with existing data (inspiration)
• Note input matches for any running processes (inspiration)
• Recollection
• record all objects / relationships / domain rules efficiently (codification)
• access all objects / relationships / domain rules efficiently (imagination)

The (inspiration), (imagination), (codification) and (classification) tags show how the major processes interact with one another.

Eventually the system can build a knowledge ontology for a specific domain by asking the user to describe objects and relationships and then asking the user to validate extrapolated axioms. This (lengthy) process should result in a system that can predict the behavior of the various objects within that domain.

In essence, 'learning' requires the same types of data collection and organization whether the student is a person or a machine. This process should be seen as "getting to know a new friend".

If axioms were included in the statistics upload, a global decision support system could be developed that would greatly reduce the time required to 'train' the system to accommodate a new 'friend' by providing an initial ontology of "common knowledge".

Nothing bad can ever possibly come of this.

Appendix:

• Introduction:
• Beyond Demographics and Privacy
• Other Considerations
• This design uses the following eight Types:
  • External Interfaces:
    • User Interface
    • Communication In/Out-put
    • System
    • Storage (persistent)
  • Internal Facilities:
    • Programming 
    • Memory (ephemeral)
    • Glyphics
    • Math & Logic
• Basic Facilities
  • Programming
  • Storage
  • System
  • Objects
• Communication, Privacy and Security
  • Communication
  • Bookmarks
  • Encryption
  • Quarantine
• User Interface
  • Preferences
  • Input
  • Output
  • Help
• Artificial Intelligence
  • Recollection
  • Recognition
  • Interpolation
  • Extrapolation
• The Four Internal (Yin) Articulation functions Delineated
  • Details: