1. © 2004 Soar Technology, Inc.  July 14, 2015  Slide 1 Thinking… …inside the box Randolph M. Jones Commercializing Soar: Software Engineering Perspective

2. © 2004 Soar Technology, Inc.  July 14, 2015  Slide 2 Commercialization Issues  The primary concern for commercialization is the ability to build and maintain the systems we want quickly and cheaply  Other general requirements The systems run as efficiently as possible The systems are robust and bug-free  Other Soar-specific requirements We want developers to be able to use Soar easily when Soar is the right tool to use  Provide a smooth transition path from non-Soar solutions to Soar solutions  Remove or reduce the barriers to entry to Soar programmers

3. © 2004 Soar Technology, Inc.  July 14, 2015  Slide 3 The Software Life Cycle  Because of barriers to entry, Soar’s advantages are most pronounced for large applications that exploit Soar’s strengths Relational knowledge base, knowledge-based decision making Pattern matching, associative retrieval Significant situation interpretation and representation Intricate belief representation Complex (hierarchical) goal structures and least-commitment execution Explanation-based learning Re-entrant, interrupt-driven decision making  These advantages imply that the (current) best commercial uses of Soar will be for relatively large systems The primary costs for large, long-lived systems are in development and maintenance There are proven software engineering methods for reducing these costs

4. © 2004 Soar Technology, Inc.  July 14, 2015  Slide 4 Lessons from Computer Science  A primary solution approach to these types of problems is layered levels of abstraction E.g., hardware, virtual machine, high-level language, libraries  Each layer is designed to foster reuse at that level Component-oriented virtual/hardware layer High-level language that captures common idioms and patterns Formal interfaces for high-level components  Ultimately, specification at each level needs to be developer-friendly, not machine-friendly Efficiency and robustness are issues, but should be handled by the compiler and virtual machine

5. © 2004 Soar Technology, Inc.  July 14, 2015  Slide 5 Obstacles to Low-Level Reuse in Soar  The current programming primitives in Soar are very close to the low-level architecture Programming is akin to programming in assembly language You can write reusable modules in assembly language, but nobody does it any more  Many current Soar “behavior libraries” rely on the goal stack The goal stack is a limited resource Two integrated libraries must contend for the resource  Architecture-level interface to libraries Higher-level interface  increased generality  more reuse  Because there is no formal design level, there can be little design- level reuse  Crippled low-level functionality for common functions Counting, sets, structure copying, data chunking, accumulation of historical information Solutions will necessarily be idiosyncratic  A higher-level language with well-defined semantics will allow the current best (or alternative) implementation to be used uniformly

6. © 2004 Soar Technology, Inc.  July 14, 2015  Slide 6 Reducing Entry Barriers  How can we reduce the learning curve for Soar, or make it less important? Change low-level language syntax Provide a higher level language Allow procedural access to Soar data structures (e.g., object-oriented access to working memory)  This could also provide a smooth migration path from procedural systems to Soar systems, as well as the potential for easily integrated hybrid systems  JESS and CLIPS have done similar things Provide an easily extensible library of components for cognitive and non-cognitive tasks

7. © 2004 Soar Technology, Inc.  July 14, 2015  Slide 7 Potential Directions  Reimplement and “componentize” Soar Allows smooth migration path for software engineers Allows easier integration, extension, experimentation Allows application-specific configuration of reasoning engine Allows easier insertion of common low-level functions Allows easier, rational choices for hybrid systems  Build/prototype your own subsystems and components  Reimplement appropriate pieces in Soar  Make Soar’s production syntax into a modern and comprehensible (to engineers) language Strong typing Syntactic encapsulation This can be a pre-processor or compiler, so Soar remains backwards compatible  Develop high-level languages and tools Must be informed by (and will inform) lower-level changes Should exploit the defining programming paradigm differences  Re-entrant, event-driven, relational pattern-oriented, least commitment