Slide 1: Disruptive Programming Language Technologies Todd A. Proebsting Microsoft Research April 24, 2002
Slide 2: “Topic of Your Choice” “Where choice begins, Paradise ends” --- Arthur Miller   Richard Hamming’s obituary (1998) The Innovator’s Dilemma by Clayton Christensen (1997) Perl, Visual Basic popularity: Their popularity is important (and good!)  April 24, 2002 Disruptive Programming Language Technologies 2
Slide 3: Richard Hamming’s Snare  Richard Hamming’s three questions for new hires at Bell Labs: 1. 2. 3. “What are you working on?” “What’s the most important open problem in your area?” “Why aren’t they the same?” (Ouch!) “You and Your Research” --- Richard Hamming (1986) April 24, 2002 Disruptive Programming Language Technologies 3
Slide 4: The Least Important Open Problem in Programming Languages* Increasing program performance via compiler optimization    Moore’s Law suffices Algorithms and design make the big difference Challenge: Name a single significant software product that relied on compiler optimization for viability. * The opinions expressed here are mine and mine alone. Microsoft disavows any connection to them… April 24, 2002 Disruptive Programming Language Technologies 4
Slide 5: The Most Important Open Problem In Programming Languages* Increasing Programmer Productivity    Write programs correctly Write programs quickly Write programs easily  Why?     Decreases support cost Decreases development cost Decreases time to market Increases satisfaction *Standard disclaimer. April 24, 2002 Disruptive Programming Language Technologies 5
Slide 6: Programmer Productivity: 3 Approaches 1. Process (software engineering)  Controlling programmers 2. Tools (static analysis, program generation)  Important, but generally of narrow applicability  Language design --- the center of the universe!    Core abstractions, mechanisms, services, guarantees Affect how programmers approach a task (C vs. LISP) Assumptions, expectations, patterns (e.g., regular expressions, events, first-class functions, garbage collection, types…) Disruptive Programming Language Technologies 6 April 24, 2002
Slide 7: Language Design: C vs. LISP  What’s the difference between a C programmer and a LISP programmer?   A LISP programmer knows the value of everything and the cost of nothing. A C programmer knows the cost of everything and the value of nothing. E.g., garbage collection, first-class functions, safety…  The languages encourage this thinking: (map fn L) vs. while (*d++ = *s++); The “value investors” are reaping strong returns nowadays. (www.paulgraham.com) Disruptive Programming Language Technologies 7  April 24, 2002
Slide 8: Programming Language Technologies: Recent Research vs. Progress(!)  Recent (perpetual?) academic research:       Type theory Functional programming Object-oriented programming Parallel programming Static analysis Compiler optimization  Recent adoption: Perl, Python, Visual Basic, Java   Almost void of innovation on type theory, functional programming, OO programming, optimization, etc! Perversely hopeful development for new language design efforts Disruptive Programming Language Technologies 8 April 24, 2002
Slide 9: New Programming Language! Why Should I Care?  The problem is not designing a new language  It’s easy! Thousands of languages have been developed It’s hard! Challenges include o Competition o Usefulness o Interoperability o Fear Can other useful languages succeed? I think so.  The problem is how to get wide adoption of the new language    I’m avoiding the problem of how to design an “elite” language… “It’s a good idea, but it’s a new idea; therefore, I fear it and must reject it.” --- Homer Simpson April 24, 2002 Disruptive Programming Language Technologies 9
Slide 10: The Innovator’s Dilemma (C. Christensen)  languages “… why companies that did everything right---were in tune with their competition, listened to their customers, and invested aggressively in new technologies---still lost their market leadership when confronted with disruptive changes in technology…” --- the book’s back cover  Why is C/C++ losing steam?   Can we use the book’s lessons to help future language efforts? (Not the book’s intent…) Disruptive Programming Language Technologies 10 April 24, 2002
Slide 11: The Innovator’s Dilemma: Cable-Actuated Excavators  A “disruptive” technology    hydraulic mechanisms small, unreliable safe, attaches to tractor independent contractors Disadvantage in primary market Advantage in secondary market Sold in small, low-margin market  Established companies concentrate and innovate on primary market; ignore secondary capacity (for excavation) Timely improvements lessen disruptive technology’s liabilities, increasing markets, market share, margins, etc.  April 24, 2002 Disruptive Programming Language Technologies 11
Slide 12: The Innovator’s Dilemma: C  A “disruptive” technology    safe, GC’ed interpreters Disadvantage SLOW Advantage Rapid Application Develop Sold in small, low-margin market web developers, ISV’s (established competitor ignored market)  Established companies concentrate on primary differentiator SPEED Timely improvements lessen disruptive technology’s liabilities, increasing markets, market share, margins, etc. Moore’s Law (for free!) RAD enhancements  April 24, 2002 Disruptive Programming Language Technologies 12
Slide 13: Perl, Visual Basic, Java vs. (Programmer Productivity vs. Technology Safety (null checks, bounds checks) Garbage Collection Slow Lack of control Interpretation Virtual Machine Slow Difficult interop Disadvantage (relative to C) Slow C Speed) Advantage (relative to C) RAD (debugging) Confine damage Confidence RAD Simple Confidence RAD (debugging) Portable platform Portable application April 24, 2002 Disruptive Programming Language Technologies 13
Slide 14: Distinguishing/Disruptive Technologies: Alleviating Real Problems  Perl   Scripting with data structures (“duct tape”) Regular expressions Drag-and-drop environment (Windows for the masses) Component-friendly Browser applets  Visual Basic    Java  Language integration yields pervasive patterns and abstractions April 24, 2002 Disruptive Programming Language Technologies 14
Slide 15: Not A Dilemma---An Opportunity!  Languages (or language technologies) that solve real problems can succeed      Even if slow Even with simple types Even without academic significance Even without rocket science If useful  Researchers need not despair  Golden opportunity to use disruptive technology as a Trojan Horse for disseminating research ideas April 24, 2002 Disruptive Programming Language Technologies 15
Slide 16: Future Disruptive Language Technologies (My Recurring Wish List)  My criteria: technology must    Have disadvantages Be ignored by recent PLDI and POPL conferences (but not others) Alleviate real problems “What does it do?” Append Dining Philo’s Factorial  For each candidate technology: 2 slides      Opportunity Current solutions Proposal Disadvantages Unmet needs what’s the issue? what’s done now sketch of language solution why some (many?) will scoff benefits to adopters 16 April 24, 2002 Disruptive Programming Language Technologies
Slide 17: Candidate: Flight Data Recorders  Opportunity: How do you debug a program that misbehaved after the error occured?  Microsoft “Watson” experience o 50% of crashes caused by 1% of bugs.  Current solutions   Ad hoc attempts to reproduce error condition Examine stack trace, program state (“core dump”) April 24, 2002 Disruptive Programming Language Technologies 17
Slide 18: Disruptive Flight Data Recorders Add persistent, automatic “tracing” of function calls, events, I/O, etc. to the language run time. (E.g., AMOK/IDAL from IDA on CRAY-1)  Important disadvantages   Will slow every program down Will require storage  Unmet needs   Diagnostic data available to programmer --- 1/50 rule “Introspective” data available to program Disruptive Programming Language Technologies 18 April 24, 2002
Slide 19: Candidate: Checkpoints/Undo  Opportunity: Programs provide checkpoint or “undo” facilities in haphazard, unreliable ways. (E.g., MS Outlook, TurboTax, almost all tiny apps.) Current solutions:     Checkpoint by saving document to a file o Doesn’t scale well to unbounded undo Programmatic checkpoint by saving select data to file o Subject to judgment (and error) Undo by saving operations and their inverse data o Tedious o Error-prone Disruptive Programming Language Technologies 19 April 24, 2002
Slide 20: Disruptive Checkpoints/Undo Make checkpointing and undo (i.e., restore to checkpoint) primitives in the programming language. Transactions.  Important disadvantages   External side-effects pose limitations (e.g., I/O) Slower than hand-crafted solution checkpoint X; <random code> restore/commit X;  Unmet needs   Simplicity Automation April 24, 2002 Disruptive Programming Language Technologies 20
Slide 21: Candidate: Database (SQL?) Integration  Opportunity: Facilitate access to values held in a database. Databases are too useful to hide behind SQL. Current solutions:     Use SQL only o Poor access to non-SQL resources Construct SQL queries by hand in host language o No compile-time checks o Tedious Embed SQL into host language via quoting o Poor integration of host types and SQL types Disruptive Programming Language Technologies 21 April 24, 2002
Slide 22: Disruptive Database Integration Proposal:    Integrate DB types and host types Expose simple operations for Join, Project, Select, Sort Treat relations like structs  Important disadvantages   Type integration likely to include slow marshaling Lost opportunities to tune query processing  Unmet needs   One-language solution Lowered barrier to entry, more accessible functionality Disruptive Programming Language Technologies 22 April 24, 2002
Slide 23: Candidate: Parsing  Opportunity: Parsing is common and difficult in general. Current solutions:     Parser generators for subsets of CFLs Regular expressions ala Perl Roll your own parser (and cross your fingers that nobody ever needs to maintain it) April 24, 2002 Disruptive Programming Language Technologies 23
Slide 24: Disruptive Parsing “Scannerless Generalized LR Parsing” (or Earley parsing) could be integrated into a language  Important disadvantages   Slow Ambiguity presents its own problems  Unmet needs    Handle arbitrary CFL grammar Spec-driven systems adapt smoothly to change Confidence that parser meets spec o XML grammar has 80+ productions… Disruptive Programming Language Technologies 24 April 24, 2002
Slide 25: Candidate: Manipulating XML  Opportunity: How to manipulate XML documents <students> <name>Grace</name> <name>Susan</name> <name>Annette</name> </students>  Current solutions    Marshal into and out of native data structures Use “Document Object Model” structures and API Use XML-specific sublanguage like XPath/XSLT Microsoft execs “Java’s a drug you rub on venture capitalists to make them crazy.” --- John Doerr, (JavaOne 1996) 2002 April 24, 2002 Disruptive Programming Language Technologies 25 XML
Slide 26: Disruptive XML Manipulation Give XML first-class status for creation, patternmatching and manipulation. E.g., x := <name>Grace</name>; <name>?y</name> := x; foreach <students>…?y…</students> := x do <S>  Important disadvantages  Declarative pattern matching may be slow  Unmet needs   XML integration into general purpose language Compile-time checking of XML manipulations. Disruptive Programming Language Technologies 26 April 24, 2002
Slide 27: Candidate: Constraint Solvers  Opportunity: Many applications have a subproblem that involves solving (or optimizing) a system subject to constraints   Natural fit for visual layout problems (e.g., render tree structures, resize windows, summarize maps) Natural fit for optimization problems  Current solutions     Hand-rolled algorithms Library routines Third-party solvers Give up Disruptive Programming Language Technologies 27 April 24, 2002
Slide 28: Disruptive Constraint Solvers Adding linear programming constraint solver (or, better, integer programming) to a programming language  Important disadvantages  Slower than tailored algorithmic solutions  Unmet needs  Quick and dirty solutions o Visual layout (Interviews-Tk?) Disruptive Programming Language Technologies 28 April 24, 2002
Slide 29: Quandary: Distributed Programming   Distributed programming is too hard Intuition says there must be an 80/20 disruptive technology out there.  This would be huge with Web Services  Suggestions welcome! April 24, 2002 Disruptive Programming Language Technologies 29
Slide 30: A Final Prediction  The next big programming language will be slower than what it replaces Why?    The incumbent language will have been optimized relentlessly To replace it, the new language must offer something new that will be valuable even if slow. April 24, 2002 Disruptive Programming Language Technologies 30
Slide 31: Shameless Self-Interest  I manage the Programming Language Systems group in Microsoft Research     We work on programming language design and implementation We appreciate small, simple solutions We’re a small group: Chris Fraser, Dave Hanson and me We’re recruiting! (Full-time and interns)  Email: toddpro@microsoft.com April 24, 2002 Disruptive Programming Language Technologies 31
Slide 32: The End April 24, 2002 Disruptive Programming Language Technologies 32