1. Disruptive Programming Language Technologies Todd A. Proebsting Microsoft Research April 24, 2002

2. Disruptive Programming Language Technologies2 “Topic of Your Choice” “Where choice begins, Paradise ends” --- Arthur Miller n Richard Hamming’s obituary (1998) n The Innovator’s Dilemma by Clayton Christensen (1997) n Perl, Visual Basic popularity: Their popularity is important (and good!)

3. April 24, 2002 Disruptive Programming Language Technologies3 Richard Hamming’s Snare n Richard Hamming’s three questions for new hires at Bell Labs: 1.“What are you working on?” 2.“What’s the most important open problem in your area?” 3.“Why aren’t they the same?” (Ouch!) “You and Your Research” --- Richard Hamming (1986)

4. April 24, 2002 Disruptive Programming Language Technologies4 The Least Important Open Problem in Programming Languages* Increasing program performance via compiler optimization n Moore’s Law suffices n Algorithms and design make the big difference n 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…

5. April 24, 2002 Disruptive Programming Language Technologies5 The Most Important Open Problem In Programming Languages* Increasing Programmer Productivity u Write programs correctly u Write programs quickly u Write programs easily n Why? u Decreases support cost u Decreases development cost u Decreases time to market u Increases satisfaction *Standard disclaimer.

6. April 24, 2002 Disruptive Programming Language Technologies6 Programmer Productivity: 3 Approaches 1. Process (software engineering) u Controlling programmers 2. Tools (static analysis, program generation) u Important, but generally of narrow applicability 3. Language design --- the center of the universe! u Core abstractions, mechanisms, services, guarantees u Affect how programmers approach a task (C vs. LISP) u Assumptions, expectations, patterns (e.g., regular expressions, events, first-class functions, garbage collection, types…)

7. April 24, 2002 Disruptive Programming Language Technologies7 Language Design: C vs. LISP n What’s the difference between a C programmer and a LISP programmer? u A LISP programmer knows the value of everything and the cost of nothing. u A C programmer knows the cost of everything and the value of nothing. E.g., garbage collection, first-class functions, safety… n The languages encourage this thinking: (map fn L) vs. while (*d++ = *s++); n The “value investors” are reaping strong returns nowadays. (www.paulgraham.com)

8. April 24, 2002 Disruptive Programming Language Technologies8 Programming Language Technologies: Recent Research vs. Progress(!) n Recent (perpetual?) academic research: u Type theory u Functional programming u Object-oriented programming u Parallel programming u Static analysis u Compiler optimization n Recent adoption: Perl, Python, Visual Basic, Java u Almost void of innovation on type theory, functional programming, OO programming, optimization, etc! u Perversely hopeful development for new language design efforts

9. April 24, 2002 Disruptive Programming Language Technologies9 New Programming Language! Why Should I Care? n The problem is not designing a new language u It’s easy! Thousands of languages have been developed n The problem is how to get wide adoption of the new language u It’s hard! Challenges include o Competition o Usefulness o Interoperability o Fear u Can other useful languages succeed? I think so. n 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

10. April 24, 2002 Disruptive Programming Language Technologies10 The Innovator’s Dilemma (C. Christensen) n “… 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 n Why is C/C++ losing steam? u Can we use the book’s lessons to help future language efforts? (Not the book’s intent…) languages

11. April 24, 2002 Disruptive Programming Language Technologies11 The Innovator’s Dilemma: Cable-Actuated Excavators n A “disruptive” technologyhydraulic mechanisms u Disadvantage in primary marketsmall, unreliable u Advantage in secondary marketsafe, attaches to tractor u Sold in small, low-margin marketindependent contractors n Established companies concentrate and innovate on primary market; ignore secondarycapacity (for excavation) n Timely improvements lessen disruptive technology’s liabilities, increasing markets, market share, margins, etc.

12. April 24, 2002 Disruptive Programming Language Technologies12 The Innovator’s Dilemma: C n A “disruptive” technologysafe, GC’ed interpreters u DisadvantageSLOW u Advantage Rapid Application Develop u Sold in small, low-margin marketweb developers, ISV’s (established competitor ignored market) n Established companies concentrate on primary differentiatorSPEED n Timely improvements lessen disruptive technology’s liabilities, increasing markets, market share, margins, etc. Moore’s Law (for free!) RAD enhancements

13. April 24, 2002 Disruptive Programming Language Technologies13 Perl, Visual Basic, Javavs.C (Programmer Productivityvs.Speed) TechnologyDisadvantage (relative to C) Advantage (relative to C) Safety (null checks, bounds checks) SlowRAD (debugging) Confine damage Confidence Garbage CollectionSlow Lack of control RAD Simple Confidence Interpretation Virtual Machine Slow Difficult interop RAD (debugging) Portable platform Portable application

14. April 24, 2002 Disruptive Programming Language Technologies14 Distinguishing/Disruptive Technologies: Alleviating Real Problems n Perl u Scripting with data structures (“duct tape”) u Regular expressions n Visual Basic u Drag-and-drop environment (Windows for the masses) u Component-friendly n Java u Browser applets Language integration yields pervasive patterns and abstractions

15. April 24, 2002 Disruptive Programming Language Technologies15 Not A Dilemma---An Opportunity! n Languages (or language technologies) that solve real problems can succeed u Even if slow u Even with simple types u Even without academic significance u Even without rocket science u If useful n Researchers need not despair u Golden opportunity to use disruptive technology as a Trojan Horse for disseminating research ideas

16. April 24, 2002 Disruptive Programming Language Technologies16 Future Disruptive Language Technologies (My Recurring Wish List) n My criteria: technology must u Have disadvantages u Be ignored by recent PLDI and POPL conferences (but not others) u Alleviate real problems “What does it do?” n For each candidate technology: 2 slides u Opportunitywhat’s the issue? u Current solutionswhat’s done now u Proposalsketch of language solution u Disadvantageswhy some (many?) will scoff u Unmet needsbenefits to adopters Append Dining Philo’s Factorial

17. April 24, 2002 Disruptive Programming Language Technologies17 Candidate: Flight Data Recorders n Opportunity: How do you debug a program that misbehaved after the error occured? u Microsoft “Watson” experience o 50% of crashes caused by 1% of bugs. n Current solutions u Ad hoc attempts to reproduce error condition u Examine stack trace, program state (“core dump”)

18. April 24, 2002 Disruptive Programming Language Technologies18 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) n Important disadvantages u Will slow every program down u Will require storage n Unmet needs u Diagnostic data available to programmer --- 1/50 rule u “Introspective” data available to program

19. April 24, 2002 Disruptive Programming Language Technologies19 Candidate: Checkpoints/Undo n Opportunity: Programs provide checkpoint or “undo” facilities in haphazard, unreliable ways. (E.g., MS Outlook, TurboTax, almost all tiny apps.) n Current solutions: u Checkpoint by saving document to a file o Doesn’t scale well to unbounded undo u Programmatic checkpoint by saving select data to file o Subject to judgment (and error) u Undo by saving operations and their inverse data o Tedious o Error-prone

20. April 24, 2002 Disruptive Programming Language Technologies20 Disruptive Checkpoints/Undo Make checkpointing and undo (i.e., restore to checkpoint) primitives in the programming language. Transactions. n Important disadvantages u External side-effects pose limitations (e.g., I/O) u Slower than hand-crafted solution n Unmet needs u Simplicity u Automation checkpoint X; restore/commit X;

21. April 24, 2002 Disruptive Programming Language Technologies21 Candidate: Database (SQL?) Integration n Opportunity: Facilitate access to values held in a database. Databases are too useful to hide behind SQL. n Current solutions: u Use SQL only o Poor access to non-SQL resources u Construct SQL queries by hand in host language o No compile-time checks o Tedious u Embed SQL into host language via quoting o Poor integration of host types and SQL types

22. April 24, 2002 Disruptive Programming Language Technologies22 Disruptive Database Integration Proposal: u Integrate DB types and host types u Expose simple operations for Join, Project, Select, Sort u Treat relations like structs n Important disadvantages u Type integration likely to include slow marshaling u Lost opportunities to tune query processing n Unmet needs u One-language solution u Lowered barrier to entry, more accessible functionality

23. April 24, 2002 Disruptive Programming Language Technologies23 Candidate: Parsing n Opportunity: Parsing is common and difficult in general. n Current solutions: u Parser generators for subsets of CFLs u Regular expressions ala Perl u Roll your own parser (and cross your fingers that nobody ever needs to maintain it)

24. April 24, 2002 Disruptive Programming Language Technologies24 Disruptive Parsing “Scannerless Generalized LR Parsing” (or Earley parsing) could be integrated into a language n Important disadvantages u Slow u Ambiguity presents its own problems n Unmet needs u Handle arbitrary CFL grammar u Spec-driven systems adapt smoothly to change u Confidence that parser meets spec o XML grammar has 80+ productions…

25. April 24, 2002 Disruptive Programming Language Technologies25 Candidate: Manipulating XML n Opportunity: How to manipulate XML documents Grace Susan Annette n Current solutions u Marshal into and out of native data structures u Use “Document Object Model” structures and API u Use XML-specific sublanguage like XPath/XSLT “Java’s a drug you rub on venture capitalists to make them crazy.” --- John Doerr, (JavaOne 1996) XMLMicrosoft execs 2002

26. April 24, 2002 Disruptive Programming Language Technologies26 Disruptive XML Manipulation Give XML first-class status for creation, pattern- matching and manipulation. E.g., x := Grace ; ?y := x; foreach …?y… := x do n Important disadvantages u Declarative pattern matching may be slow n Unmet needs u XML integration into general purpose language u Compile-time checking of XML manipulations.

27. April 24, 2002 Disruptive Programming Language Technologies27 Candidate: Constraint Solvers n Opportunity: Many applications have a subproblem that involves solving (or optimizing) a system subject to constraints u Natural fit for visual layout problems (e.g., render tree structures, resize windows, summarize maps) u Natural fit for optimization problems n Current solutions u Hand-rolled algorithms u Library routines u Third-party solvers u Give up

28. April 24, 2002 Disruptive Programming Language Technologies28 Disruptive Constraint Solvers Adding linear programming constraint solver (or, better, integer programming) to a programming language n Important disadvantages u Slower than tailored algorithmic solutions n Unmet needs u Quick and dirty solutions o Visual layout (Interviews-Tk?)

29. April 24, 2002 Disruptive Programming Language Technologies29 Quandary: Distributed Programming n Distributed programming is too hard n Intuition says there must be an 80/20 disruptive technology out there. u This would be huge with Web Services n Suggestions welcome!

30. April 24, 2002 Disruptive Programming Language Technologies30 A Final Prediction n The next big programming language will be slower than what it replaces n Why? u The incumbent language will have been optimized relentlessly u To replace it, the new language must offer something new that will be valuable even if slow.

31. April 24, 2002 Disruptive Programming Language Technologies31 Shameless Self-Interest n I manage the Programming Language Systems group in Microsoft Research u We work on programming language design and implementation u We appreciate small, simple solutions u We’re a small group: Chris Fraser, Dave Hanson and me u We’re recruiting! (Full-time and interns) n Email: toddpro@microsoft.com

32. April 24, 2002 Disruptive Programming Language Technologies32 The End