Why I Hate Computers And what we might do about it

1. Why I Hate ComputersAnd 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 we’re in the wrong place in this spectrum.

3. Alternative, More Civil Title: Finding the Right Unifying Theme for Architectures, Languages And Operating Environments Bits --> Objects --> 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 we’re 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 doesn’t 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: 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.

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

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

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

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

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

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

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

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 can’t we code with and execute “patterns” directly • Suitable abstractions for capturing a notion of “normal functioning” • Self diagnosis, recovery and adaptation

23. 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 The Plan Level: Moving Beyond Objects

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

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. Each Plan Requires Different Resources Each Method Binds the Settings of The Control Parameters in a Different Way Resource1,1 Service Control Parameters Resource Cost Function Resource1,2 User’s Utility Function Abstract Service Resource1,j Plan1 Plan2 The Binding of Parameters Has a Value to the User User Requests A Service With Certain Parameters The Resources Used by the Method Have a Cost Plann Each Service Can Be Provided by Several Plans Net Benefit 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. Step-B Step-A requires achieves Condition-1 Condition-1 prerequisite 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. Resource1,1 Resource1,2 Resource Cost Function Plan1 Resource1,j Plan2 User’s Utility Function Abstract Service Plann Net Benefit Security and Privacy Issues Are Addressed by Factoring in the Cost of Violating a Security or Privacy Policy 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 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.

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

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 • Preserve it by systematic refinement tools that refine high level specs into code (e.g. Kestrel) • Recover it by reverse engineering standard clichés/patterns (e.g. Georgia Tech, Reasoning Systems) • Make it convenient to annotate code with plan like information, even if informal.

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

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