| Lisp: Where Do We Come From? What Are We? Where Are We Going? Peter Norvig NASA Ames Research Center |
| The answer is l (and the Y combinator) |
| Where Do We Come From? (1958-1989: the first 30 years) |
| John McCarthy | ||
| Notation, Functional Programming, Statements as Expressions, Incremental Compilation | ||
| MIT/Stanford/CMU/Xerox | ||
| Language of choice for many elite programmers | ||
| Language of Artificial Intelligence | ||
| Lisp Machines | ||
| Tool of choice; A religion?; Commercialization | ||
| Lucid/Franz/Harlequin/Digitool/... | ||
| Many of benefits to stock HW (without religion) | ||
| What Are We? (1990s: the last ten years) |
| Groups and Fields can be defined in terms of: | |
| Shared Community | |
| Shared Tools | |
| Shared Literature | |
| Ecological Niche | |
| We are a Shared Community |
| But is the community healthy? | ||
| Defensive stance (like Apple or Linux) | ||
| Minority, with some zealots, past-looking | ||
| Numbers holding steady(?) | ||
| But the world is consolidating on C++/Java | ||
| See http://www.norvig.com/Lisp-retro.html | ||
| C++/Java way out in front | ||
| Lisp comparable to Perl on Books, Usenet, URLs | ||
| But Lisp far behind in Job postings | ||
| We Have a Set of Shared Tools |
| Interactive RAD | |
| Garbage Collection | |
| Everything is an Object | |
| Higher-order Functions | |
| Emacs | |
| Lisp Machines | |
| Macros, Meta-Programming | |
| Custom Small Languages | |
| Generic Functions, Informal Interfaces | |
| Mostly Functional Programming | |
| Our Tools are “Under-Appreciated” |
| Six “Lasting Concepts” from tPoP: | ||
| Simplicity and Clarity L/J=2 | ||
| Generality L/J=1.5 | ||
| Evolution L/J=3 | ||
| Interfaces L/J=0.5 | ||
| Automation (under-appreciated) L/J=10 | ||
| (Programs writing other programs, tests, etc.) | ||
| Notation (under-appreciated) L/J=5 | ||
| (Little Languages) | ||
| We Have a Shared Literature |
| We Inhabit an Ecological Niche |
| Artificial Intelligence | ||
| Recent competition from C++, Java, MATLAB, etc. | ||
| “Solving the hard problems” | ||
| Very competitive niche | ||
| RAD | ||
| Lisp is losing the high ground: | ||
| CAD, Education | ||
| But … | ||
| Lisp is the most adaptable language ever | ||
| The key to survival is to find a new niche | ||
| In 30 years Lisp will likely be ahead
of C++/Java (but behind something else) |
||
| Where Are We Going? (the next 10 to 100 years) |
| How to predict the future? | ||
| Look at published theories | ||
| What niche can we inhabit? | ||
| Look at some new ones | ||
| Worse Is Better (Gabriel 1990) |
| Simple is Better | |
| First provide the right 50% capability | |
| Users will grow it to 90% | |
| Lisp: too “right thing,” CL too big, Scheme too small, large entry barrier (50% of population below median) | |
| Prediction: Hard for Lisp to compete, even with “Win Big” strategy | |
| Crossing the Chasm (Moore 1991) |
| Useful is Better | |
| Early adopters don’t predict mainstream adopters | |
| Be useful in a vertical industry | |
| Then move into the mainstream | |
| Lisp as Tool: Too early-adopter | |
| Prediction: Lisp can Help companies cross (Viaweb) |
| Innovator’s
Dilemma (Christensen 1997) |
| Cheaper is Better | |
| Innovation moves up from the low end, often with new business model or manufacturing process | |
| The best companies can lead tech development, and still miss out | |
| Lisp Firms: overtaken by “inferior” C, etc. |
| Internet Time (eVeryone 1998) |
| First is Better | |
| Rush to market, get market share | |
| Lisp: not keeping up | |
| Prediction: need for premier RAD tool; Lisp techniques could be part of solution | |
| Where is Lisp Winning? |
| NASA Remote Agent (and various rovers) | |
| Yahoo Viaweb Shopping (Paul Graham) | |
| Ascent Datamining Tool | |
| Nichimen (nee Symbolics) Graphics Systems | |
| AT&T, Lucent, other 24x7 telecom switches | |
| NASA, Boeing, Airline planning/scheduling | |
| Reasoning Systems Y2K program analysis tools | |
| Prototyping by Wizards
(many…) Answer: Where There Are Lisp Programmers |
|
| Where Is Lisp Losing? |
| “ The worst thing we can do is to
stand still as a community, and that is what is happening.” - Richard Gabriel (in 1991, and since then?) |
||
| “ Three strikes and you’re
out” - Cordell Green (on Lisp+Unix+Category Theory) |
||
| RAD development as good as Lisp | ||
| And better for traditional GUIs | ||
| Standardization falling far behind | ||
| GUI, HTTP, TCP/IP, Threads,
binaries Answer: need a 10´ or 100´ breakthrough |
||
| What Niche Can We Inhabit? |
| The High Ground in 10´ or 100´ improvements | |
| Look at three possibilities “We” means Lisp Community Not necessarily Lisp |
| (1) First-class Design Patterns |
| Design Patterns are hot | ||
| At least in bookstore; for actual production use??? | ||
| Design Patterns are: | ||
| Descriptions of what experienced designers know | ||
| Hints/reminders for choosing classes and methods | ||
| Higher-order abstractions for program organization | ||
| To discuss, weigh and record design tradeoffs | ||
| To avoid limitations of implementation language | ||
| Lisp is the best host for first class patterns | ||
| First-class Design
Patterns: Levels of Implementation |
| Invisible So much a part of language that you don’t notice (e.g. when class replaced struct in C++, no more “Encapsulated Class” pattern) |
|
| Informal Design pattern in prose; refer to by name, but Must be implemented from scratch for each use |
|
| Formal Implement pattern itself within the language Instantiate/call it for each use Usually implemented with macros |
| Applying Lisp to Design Patterns |
| 16 of 23 GOF patterns are either invisible or simpler: | |
| First-class types (6): Abstract-Factory, Flyweight, Factory-Method, State, Proxy, Chain-Of-Responsibility | |
| First-class functions (4.5): Command, Strategy, Template-Method, Visitor, Iterator | |
| Macros (1.5): Interpreter, Iterator | |
| Method Combination (2): Mediator, Observer | |
| Multimethods (1): Builder | |
| Modules (1): Facade |
| Constructing and
Deconstructing Programs into Patterns |
| (2) Adaptive, Teachable Systems |
| Not enough programmers to go around | ||
| But many users, domain experts, critics | ||
| Architect systems in which: | ||
| Programmers specify initial architecture, specs | ||
| Users say “good” or “bad” (reinforcement learning) | ||
| Users can correct answers (supervised learning) | ||
| Users can script new behavior, then improve | ||
| Program learns from many users (statistics) | ||
| Programs have ontology of user goals, situations | ||
| Adaptable, Teachable
Systems: Interfaces vs. Performance |
| Black Box: | ||
| Input/Output spec. | ||
| Can’t talk about performance | ||
| Open Implementation: | ||
| Performance tweaking, T | ||
| Designer picks good tweaks | ||
| Adaptive Software: | ||
| Performance feedback, F | ||
| Feedback informs tweaks | ||
| Adaptable, Teachable
Systems: Decomposing Into the Right Components |
| Aspect-Oriented Programming | ||
| Deal with one aspect at a time (performance, parallelism, replication, etc.) | ||
| http://www.parc.xerox.com/aop | ||
| Subject-Oriented Programming | ||
| A subject is a collection of classes | ||
| http://www.research.ibm.com/sop | ||
| Intentional Programming | ||
| Don’t bother with syntax; express intentions | ||
| http://www.research.microsoft.com/research/ip/ | ||
| (3) Self-verifying and Repairing Systems |
| Model Checking, other Formal Methods | ||
| Formally prove properties of program | ||
| Helps with concurrency, etc. | ||
| Model-Based Reasoning | ||
| Say what there is, not how to do things with it | ||
| Separate reasoning engines for the what | ||
| Adaptive to changes in environment, system | ||
| Conclusions |
| Lisp has always allowed us to imagine the abstractions we want, and then build a program with them (see On Lisp) | |
| Now it is time to imagine the program development and use system we really want, and then evolve all our programs starting with it | |
| Even if the resulting system is not in Lisp, its users will essentially be Lisp Programmers |