Why I Hate Computers And what we might do about it

Howie Shrobe

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 we’re in the wrong place in this spectrum.

Finding the Right Unifying Theme for

Architectures, Languages And

Operating Environments

Bits --> Objects --> Plans

Alternative, More Civil Title:

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 we’re in the wrong place in this spectrum.

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

The Bad News

• There are more system administrators than school teachers in the U.S.

• That doesn’t count the part of all of us that is devoted to system administration

• Total Cost of Ownership is becoming the new watchword.

Where we are today: What’s 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.

To be fair:• There is a degree of unity of purpose in traditional

Unix– It’s not raw seething bits

– It’s 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: GUI’s, databases, …

• Any new unifying metaphor should achieve similar synergy

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?

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 didn’t we think of that before

The MIT Lisp Machine:An Object Oriented System

• 1978 - (they still exist)• Hardware enforced data type checking (<< 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

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

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”

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

Visibility and Controllability

• All user interfaces are in the Model-View-Controller 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.

Example OO User Interface

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) (clim:format-graph-from-roots base-rules #'(lambda (rule stream)

(let ((conclusions (rule-conclusions rule))

(name (rule-number rule))) (clim:surrounding-output-with-border (stream)

(clim:with-output-as-presentation (stream rule 'rule) (format stream "~%Rule ~d~%~a" 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)))

(clim:define-presentation-type-abbreviation parameter () `(member ,@*all-parms*))

(clim-environment::define-lisp-listener-command (com-graph-rules :name t) ((conclusions `(sequence parameter))) (graph-rules conclusions))

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.

Consequences

• A programmer can tell:– Where the system is

– What it’s doing

– What it’s state is even when it’s screwed up

• A programmer can usually fix the system while it’s 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 (< 1 Msloc for everything) vs 45Msloc for Windows/Unix

WARTS

• Evolutionary history never cleaned up• Language model bloated and ugly (it’s Not

Scheme)• Several redundant ways to do everything• Code bloat• No security mechanisms

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.

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 can’t we code with and execute “patterns” directly

• Suitable abstractions for capturing a notion of “normal functioning”

• Self diagnosis, recovery and adaptation

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

What’s 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

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).

AbstractService

ServiceControl Parameters

User’sUtility

Function

The Binding of Parameters Has a Value to the User

Resource1,1

Resource1,2

Resource1,j

Each Plan Requires Different Resources

The System Selects the Plan Which Maximizes Net Benefit

User Requests A

Service With

Certain Parameters

ResourceCost

Function

The ResourcesUsed by the MethodHave a Cost

Net Benefit

Each Method Binds the Settings of The Control Parameters in a Different Way

Plan1

Plan2

Plann

Each Service Can BeProvided by Several

Plans

Services are Dynamically Mapped to Plans

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”

Making the System Responsible for Achieving Its Goals

Scope of RecoverySelection of Alternative

Localization & Characterization

DiagnosticService

Repair PlanSelector

ResourceAllocator

Concrete Repair Plan

Resource Plan

alerts

PlanMonitor

RollbackDesigner

Enactment

achieves

requires

Step-A

Step-B

Condition-1

Condition-1

prerequisite

ServiceRequest

Plan-for

A plan is a partially ordered collection of stepsEach step achieves a subgoalSome steps establish pre-requisites for others

Security PoliciesSecurity Policies

Dealing with Privacy and Security

Security and Privacy Issues Are Addressed by Factoring in the Cost of Violating a Security or Privacy Policy

ResourceCost

Function

Resource1,1

Resource1,2

Resource1,j

AbstractService

User’sUtility

Function

Net Benefit

Plan1

Plan2

Plann

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 user’s 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.

Visibility and Introspection

• When executing at the plan level, the system knows:– What it’s doing (what plan step is executing)

– The context of that activity (what plan it’s 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

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.

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)

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.

Possible Projects for Understanding This Paradigm

• Take service level API’s 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

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