Why I Hate Computers And what we might do about it

1
Why I Hate Computers And what we might do about
it

• Howie Shrobe

2
The Thesis

• Architecture, Language and Operating Environment
  are always unified around a common theme.
• That theme can carry varying degrees of
  constraint and semantics
• The degree of semantics is directly proportional
  to the ability to provide visibility,
  introspection and control.
• The problem is that were in the wrong place in
  this spectrum.

3
Finding the Right Unifying Theme for
Architectures, Languages And Operating
Environments
Alternative, More Civil Title

• Bits --gt Objects --gt Plans

4
The Thesis

• Architecture, Language and Operating Environment
  are always unified around a common theme.
• That theme can carry varying degrees of
  constraint and semantics
• The degree of semantics is directly proportional
  to the ability to provide visibility,
  introspection and control.
• The problem is that were in the wrong place in
  this spectrum.

5
Evolution of the CS Research Focus

• It costs to much to write software
• Focus on software design, verification
• It costs to much to maintain software
• Focus on evolution, rationale capture, dynamism
• It costs to much to own software
• Focus on operational costs, security, robustness,
  adaptation

6
The Bad News

• There are more system administrators than school
  teachers in the U.S.
• That doesnt count the part of all of us that is
  devoted to system administration
• Total Cost of Ownership is becoming the new
  watchword.

7
Where we are today Whats Wrong

• Hardware Architectures provide Raw Seething
  Bits
• Programming languages (C) provide direct access
  to Raw Seething Bits without manifest
• Identity
• Boundaries
• Invariant conditions
• Unifying computational model
• Anybody sane or important must erects protection
  barriers to save itself from the screaming
  ninnies
• This breaks modularity in the infrastructure
• This interferes with introspection, adaptivity,
  etc.

8
To be fair

• There is a degree of unity of purpose in
  traditional Unix
• Its not raw seething bits
• Its the byte stream
• HCI, Storage and Computations are interchangeable
  sources/sinks of these
• There is great synergy in this
• But not much structure
• Everything since 1975 has been bursting through
  the seams of this abstraction GUIs, databases,
  
• Any new unifying metaphor should achieve similar
  synergy

9
4 Questions any system should be able to answer

• What are you doing?
• Why are you doing it?
• How did you get here?
• Are things behaving reasonably?

10
If Not Bits, Then Objects

• Synergy at the level of objects
• Object Oriented User Interfaces
• OODBs
• Object Oriented Programming Language
• Unity of Purpose would involve
• Object Oriented Hardware enforcement of the
  object abstraction
• Object Oriented Languages
• Object Oriented Operating System and Environment
• Damn, why didnt we think of that before

11
The MIT Lisp MachineAn Object Oriented System

• 1978 - (they still exist)
• Hardware enforced data type checking (ltlt 20
  logic)
• Hardware enforced bounds checks
• Memory is garbage collected with hardware
  support
• Read barrier for multi-threaded copying collector
• Write barrier for ephemeral collection
• Object creation not memory allocation

12
The Language Model

• Generic function call is basic operation
• Select most appropriate method based on
  arguments object types
• Methods selected by Generic Function dispatch
• Objects accessed only through methods
• Object Model
• Multiple inheritance
• Multiple argument type dispatch
• Method combination with wrapper methods
• OOP with a lisp/functional viewpoint

13
System View

• Multi-threaded single-address space
• No barriers
• No kernel vs user space distinction
• No Special System call mechanism (normal function
  calls)
• Generic services (e.g. file service) using best
  available protocol
• Object Oriented Database for backing storage
• Object Oriented HCI in terms of presentation
  types

14
Introspective Organization

• We carry all the information in the programming
  environment into the execution environment
• Call trees, class organization, meta-class
  organization, source locations
• Manifest object types
• All objects are self describing and know their
  own type
• The stack and other system constructs are vanilla
  objects and play by these rules
• Manifest stack structure
• Running function name
• Arguments, local variables, global variables
• Error handlers, unwind-protects, restart-handlers
• Call chain
• Condition handlers execute in the context of the
  signaling event, preserving state, allowing
  recovery

15
Visibility and Controllability

• All user interfaces are in the Model-View-Controll
  er spirit
• The ensemble of objects is the model
• Things on the screen are presentations of the
  objects
• Gestures (e.g. mouse clicks) associated with
  presentations of objects are translated into
  operations on those objects
• Presentations are updated to reflect current
  state of the system
• System state is manifest as objects, can be
  inspected and modified using this paradigm.

16
Example OO User Interface
17
Full Rule-Base Examiner
(defun graph-rules (conclusions key (stream
standard-output)) (let ((base-rules (loop for
c in conclusions for rules-for-c
(get-rules c) append rules-for-c)))
(fresh-line stream) (climformat-graph-from-root
s base-rules '(lambda (rule
stream) (let ((conclusions (rule-conclusions
rule)) (name (rule-number rule)))
(climsurrounding-output-with-border (stream)
(climwith-output-as-presentation (stream
rule 'rule) (format stream "Rule da"
name (first (first conclusions)))))))
'(lambda (rule) (let ((premises (rule-premises
rule))) (loop for premise in premises append
(get-rules (first premise))))) stream
stream orientation vertical))) (climdefine
-presentation-type-abbreviation parameter ()
(member ,_at_all-parms)) (clim-environmentdefin
e-lisp-listener-command (com-graph-rules name
t) ((conclusions (sequence parameter)))
(graph-rules conclusions))
18
Security and the Lisp

• The Lisp Machine had essentially no notion of
  access rights, security, etc.
• From the console, you can control anything.
• However, from the network it is virtually
  impervious to all known attacks
• The White House Server was never broken into
  although it was outside the firewall
• No Lispm here at MIT has been broken into
• We have red-teamed it (informally) without
  success.
• 80 of all attacks rely on buffer overflow which
  is impossible in such systems.

19
Consequences

• A programmer can tell
• Where the system is
• What its doing
• What its state is even when its screwed up
• A programmer can usually fix the system while
  its running.
• It keeps enough meters counters to indicate
  when behavior is reasonable
• Extremely powerful programming environment
• The saddest day is when then turned off my Lispm.
• Extremely compact system (lt 1 Msloc for
  everything) vs 45Msloc for Windows/Unix

20
WARTS

• Evolutionary history never cleaned up
• Language model bloated and ugly (its Not Scheme)
• Several redundant ways to do everything
• Code bloat
• No security mechanisms

21
Possible Projects

• Build the core of a new Thoroughly OO system
  drawing on best of Lispm, Role Based Access
  Control and Capability ideas
• Develop a clean dynamic OO language suitable for
  such a system (e.g. Scheme CLOS)
• Develop a new multimodal HCI infrastructure based
  on manifest dynamic object types
• Device a new minimal (but no less) hardware base
  to support this new environment.

22
What the Object Model Lacks

• A notion of purpose
• Why am I executing this component
• What does it accomplish
• What depends on it accomplishing that
• Active design level abstractions
• Why cant we code with and execute patterns
  directly
• Suitable abstractions for capturing a notion of
  normal functioning
• Self diagnosis, recovery and adaptation

23
The Plan Level Moving Beyond Objects

• Programming environment information
• Hardware enforced data-typing
• Data-type driven dispatch
• Syntactic introspection
• User programmed diagnosis recovery
• Core Storage convention integrity enforced
• Object Allocation
• Code level
• Presentation Based Interface

• Design environment information
• Hardware enforced capabilities
• Decision Theoretic dispatch
• Semantic introspection
• System provided Diagnosis and Recovery services
• Role and object type access enforcement
• Resource reservations
• Design level
• Adaptive synthesized interface

24
Whats a Plan

• Decomposition of a task into partially ordered
  steps
• Pre, Post and Maintain Conditions for each step
• Primitive steps just execute (at the object
  level)
• Abstract Data Flow
• Abstract Control flow
• Causal Links
• Prerequisite links post-conditions of some
  components to preconditions of others
• Goal links overall post-conditions to those of
  components
• Maintain links overall maintain conditions to
  those of components
• Parameterized Resource Requirements
• Predictive Service Qualities

25
The Execution Model Decision Theoretic Dispatch

• Components interact at the level of goals or
  service requests (abstract function call)
• The environment provides multiple plans (abstract
  methods) for achieving each goal
• Each method renders different qualities of
  service
• The user provides preferences over these service
  qualities.
• That method which the best matches the requestors
  preferences is dispatched (abstract method
  selection, as opposed to type driven).

26
Services are Dynamically Mapped to Plans
The System Selects the Plan Which Maximizes Net
Benefit
27
Robustness and Recovery From Failures

• Breakdowns are inevitable
• Resources sometimes fail while being used
• The system acts on sensor data which has
  uncertainty
• A plan-monitor watches over the execution of a
  plan.
• Each plan step accomplishes sub-goals needed by
  succeeding steps
• Each sub-goal has some way of monitoring whether
  it has been accomplished
• These monitoring steps are also inserted into the
  plan
• If a sub-goal fails to be accomplished,
  model-based diagnosis isolates and characterizes
  the failure
• A recovery is chosen based on the diagnosis
• It might be as simple as try it again, we had a
  network glitch
• It might be try it again, but with a different
  selection of resources
• It might be as complex as clean up and try a
  different plan

28
Making the System Responsible for Achieving Its
Goals
Diagnostic Service
Service Request
Plan-for
Localization Characterization
Repair Plan Selector
Scope of Recovery Selection of Alternative
alerts
Rollback Designer
Concrete Repair Plan
Plan Monitor
Resource Allocator
A plan is a partially ordered collection of
steps Each step achieves a subgoal Some steps
establish pre-requisites for others
Resource Plan
Enactment
29
Dealing with Privacy and Security
Security Policies
30
HCI

• Interacting with a Human becomes a plan level
  process
• There a preferences about which pieces of
  information are most important to convey
• The resources to be managed include the users
  channels of communications
• Visual color, texture, position, size
• Auditory and Haptic
• The system should select or generate
  communications plans that maximize overall
  communications benefit with minimum resrource
  comsumption.

31
Visibility and Introspection

• When executing at the plan level, the system
  knows
• What its doing (what plan step is executing)
• The context of that activity (what plan its part
  of and what goal the plan is intended to achieve)
• The purpose of the current activity to achieve
  prerequisites
• When executing raw code, the system knows
• The most specific plan step this is part of
• The call tree and other syntactic info

32
Adaptation, Robustness, Evolution

• Association with every goal there are potentially
  multiple plans
• Each request for service is accompanied by
  preferences over the service qualities
• Dynamically Pick combination of methods and
  resources that maximizes the ratio of utility of
  the service quality and cost of resources.
• Plan Execution is monitored
• Breakdowns are diagnosed and recovery plans
  selected
• Trust/Reliability model of resources is updated
• New goals are satisfied in light of the trust
  model.
• Plans and goals are modular units that are added
  to the system incrementally.

33
Resource Management

• Plans can include temporal information
• Estimates for how long each step should take
• Association of resources with specific steps
• Required resources can then be reserved for
  specific temporal intervals
• Cost of resources can be estimated at that time
  based on contention
• Detailed scheduling of steps can be done to
  minimize resource contention
• Can provide guarantees about availability of
  shared resources (e.g. network bandwidth)

34
How would we Get Plan Level Information

1. Preserve it by systematic refinement tools that
   refine high level specs into code (e.g. Kestrel)
2. Recover it by reverse engineering standard
   clichés/patterns (e.g. Georgia Tech, Reasoning
   Systems)
3. Make it convenient to annotate code with plan
   like information, even if informal.

35
Possible Projects for Understanding This Paradigm

• Take service level APIs of some standard system
• Rebuild the higher level of these services in
  Plan oriented style
• Build a decision theoretic dispatch service for
  this layer
• Build a resource management and reservation
  service
• Build diagnosis and recovery service

36
Summary

• Current systems operate at the level of raw
  seething bits
• We have existing models that operate at the
  Object Level
• The Future of Systems is AI (and vice versa)
• We can imagine an even more aggressive layer of
  structuring the Plan Level which would provide
  semantic visibility
• A rubric for both long term and short term
  research efforts