Language-Oriented Programming am Beispiel Lisp Arbeitskreis Objekttechnologie Norddeutschland HAW Hamburg, 6.7.2009 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik und Capgemini sd&m Research 1 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems The big picture Agile development Conclusion 2 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
My Background Diplom-Informatiker, Universität Kaiserslautern: Lisp as first programming language Focus on artificial intelligence (AI): thesis on machine learning Ph.D. Computer Science, University of Wollongong, Australia: Thesis on transactions in distributed object-oriented systems 11 years with sd&m: Development of large-scale business information systems Developer, chief architect, project manager, department manager, head of sd&m Research Hochschule Darmstadt University of Applied Sciences Professor for software engineering and project management Focus on software architecture 3 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Language-Oriented Programming Instead of simply writing your application in the base language, you build on top of the base language a language for writing programs like yours, then write your program in it. Paul Graham, Hackers & Painters, 2004 DSL = Domain-Specific Language 4 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
IDE: Allegro Common Lisp Express Edition Franz Inc. 5 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
6 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
7 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems The big picture Agile development Conclusion 8 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Lisp = List Processing List: the basic Lisp data structure (1 2 3) ( This is a list of strings ) ((:key1. value1) (:key2. value2)) (:key1 value1 :key2 value2) (((3) 2 (4)) 1 (() 5 (6))) Lisp Programs are data: (factorial 5) (+ 2 3 4) (if condition (then-operation) (else-operation)) (defun identity (x) x) (defclass Customer (name address)) Association list Property list Binary Tree Function call: prefix notation Control structures Lisp Programs are represented by their syntax trees convenient transformation of Lisp programs via macro processor :key1 value1 :key2 value2 9 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009 2 3 4 Function definition Class definition 1 5 6
Configuration data Program code Interactive console (REPL) IDE: Allegro Common Lisp Express Edition 10 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Franz Sciences. Inc. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems A query language A rules language A workflow language The big picture Agile development Conclusion 11 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Excursus: The Quasar reference architecture for business information systems Services (Use Cases) class Quasar Architecture «Abstract T Compo... Workflow Management «Abstract T Compo... Client Management «Abstract T Compo... Batch Management pkg Application Components Entity Managers (DAOs, Controllers) A-Component 3 UseCase 3.1 UseCase 3.2 «A Component» Workflow «A Component» Dialog «A Component» Batch A-Controller 3.1 A-Controller 3.2 A-Controller 3.3 Workflows A-Entity 3.1 A-Entity 3.2 A-Entity 3.3 Dialogs «Abstract T Compo... Application Kernel Facade Entities «A Component» Application Component «Abstract T Compo... Authorization Application data types «Abstract T Compo... Transaction «Abstract T Compo... Persistence Queries 12 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Example: A simple DSL for application data types 13 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Example: A simple DSL for entity types 14 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Criteria for a good DSL A DSL consists of: Syntax needs an editor to program in Semantics needs a compiler and a runtime environment to execute Good Syntax is: Concise Easy and intuitively to understand Semantics should be: Expressive / powerful Efficient implementation Example DSLs: Query language Rules language Workflow language 15 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems A query language A rules language A workflow language The big picture Agile development Conclusion 16 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
A general object database query language Local variable Persistent class Auxiliary variable not needed in result set Conjunctive clauses Any form of Lisp expression allowed. Here: object navigation 17 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems A query language A rules language A workflow language The big picture Agile development Conclusion 18 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Excursus on semantic web technology: RDF(S) Resource Description Framework (Schema) Statement Subject Predicate Object has-income Huber 65.000 Huber rdf:type Person Person rdf:type rdfs:class has-income rdf:type rdf:property has-income rdfs:domain Person has-income rdfs:range xs:integer 19 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
XML syntax for RDF(S): no appropriate langauge for representating knowledge Meaning: Course CIT2112 is taught by teachers 949111, 9493252, and 949318 Source: Antoniou, van Harmelen: A Semantic Web Primer 20 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Simplify URI syntax (add-triple!ins:franz!ins:has-disease!ins:heart-stroke) <http://www.fbi.h-da.de/insurance#franz> <http://www.fbi.h-da.de/insurance#has-disease> <http://www.fbi.h-da.de/insurance#heart-stroke> 21 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Provide means for declaring classes and instances (add-class!ins:person :comment "Natural Person" :see-also!ins:profession) (add-instance!ins:huber!ins:person) (ADD-TRIPLE!ins:Person!rdf:type!rdfs:class) (ADD-TRIPLE!ins:Person!rdfs:comment (LITERAL "Natural Person")) NIL (ADD-TRIPLE!ins:Person!rdfs:seeAlso!ins:Profession)) (ADD-TRIPLE!ins:Huber!rdf:type!ins:Person) 22 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Provide means for declaring properties (add-property!ins:person!ins:has-desease!ins:disease) (add-triple!ins:franz!ins:has-disease!ins:heart-stroke) (ADD-TRIPLE!ins:has-desease!rdf:type!rdf:Property) (ADD-TRIPLE!ins:has-desease!rdfs:domain!ins:Person) (ADD-TRIPLE!ins:has-desease!rdfs:range!ins:Disease) (add-triple!ins:franz!ins:has-disease!ins:heart-stroke) 23 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
A rules language oriented on Prolog Facts Rules: Head <- goal 1 goal n Variables Unification of variables and terms Interactive Query 24 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems A query language A rules language A workflow language The big picture Agile development Conclusion 25 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Customer Identification Rating A Workflow Language no Create Customer Account accept XOR accept Receive Customer Request Check whether Account exists XOR yes XOR Rate Customer XOR Rate-manually Manually rate customer XOR reject reject XOR reject Inform customer on rejection accept Policy preparation Contract signing Policy signed Finalize Policy Prepare policy Send polic to customer Receive signed policy XOR Policy not signed Binding period passed No Policy 26 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Named workflow Synchronous invocation of service Manual activities can be accessed via worklist dialogs Voucher mechanism: waits until value has been set Worflows are services that can be invoked Asynchronous invocation of service 27 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Waiting for external events Waiting for timing conditions 28 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems The big picture Agile development Conclusion 29 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Domain-specific languages (DSL) or different general-purpose languages (GPL) may be derived from a base language (BL) Project-specific DLS e.g., GUI style guide BIS DSL Family E.g., Quasar BIS = Business Information Systems. Reference architecture includes dialogs, components, services, entity managers, entities, data types Object-oriented GPL e.g., CLOS + extensions Query DSL Configuration DSL e.g., Scribble, XML Test DSL e.g., LispUnit Functional GPL e.g., Scheme Business Process DSL Rules DSL e.g., Prolog Base Language (BL) e.g., Common Lisp S-Expressions Legend: Language Based on 30 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Language design and application design are relevant for application development Level Content Example M3: Meta-Meta- Model Base-Language Common Lisp S-Expressions S-Expr ::= Atom (S-Expr*) Atom ::= Relevant for application development M2: Meta-Model M1: Model Languages (GPL, DSL) (Language-Design) Applications (Design & Implementation) Entity.lang.lisp Insurance.entity.lisp (defmacro define-entity (name attributes) ) (define-entity Customer (id name address) ) M0: Instance Objects (Runtime) Entity Customer (Customer :id 42 :name Smith ) 31 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
The language stack describes the configuration of language versions (GPL, DSL) based on each other Project-specific extension BIS Entity Language GP OO Language Base Language Insurance Entity Version x.y.z Quasar Entity Version x.y.z CLOS + extensions Version x.y.z Common Lisp S-Expressions Version x.y.z Language Configuration 32 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems The big picture Agile development Conclusion 33 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Incremental language design allows scaling the language to the problem domain. Incremental application development allows stepwise increase of quality Production-ready Integratable Prototypical Ad-hoc Vertical scalabiliy via quality levels: Incremental application development. Conformance checks ensure quality levels Horizontal scalabiliy via languages (GPL, DSL): Incremental language design Query Language Business Process Language 34 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Example for vertical scalability: Successively adding typing, documentation, error handling, pre- / post-conditions etc. Parameter typing Vertical scalabiliy via quality levels Conformance checks for typing, documentation etc. Full documentation Pre- and Postconditions Error specification Ad-hoc: Untyped Undocumented No error handling No implementation 35 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Agenda Introduction & Example A few words on Lisp DSLs for business information systems The big picture Agile development Conclusion 36 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009
Conclusion and discussion Language oriented programming (LOP) allows specifiying a solution to a problem on the appropriate level of abstraction Lisp is well suited for LOP Programming of a high level of abstraction is useful BUT BUT BUT Defining languages is hard Language versioning is a problem Lisp is not widely adopted in industry Every complex abstration is leaky (Spolsky) What is your opinion? 37 Prof. Dr. Bernhard Humm, Darmstadt University of Applied Sciences. 2009