Disruptive Programming Language Technologies - PowerPoint PPT Presentation

Loading...

PPT – Disruptive Programming Language Technologies PowerPoint presentation | free to download - id: 3d689-NmFmM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Disruptive Programming Language Technologies

Description:

A LISP programmer knows the value of everything and the cost of nothing. ... Diagnostic data available to programmer --- 1/50 rule 'Introspective' data ... – PowerPoint PPT presentation

Number of Views:76
Avg rating:3.0/5.0
Slides: 33
Provided by: todd121
Learn more at: http://research.microsoft.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Disruptive Programming Language Technologies


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

2
Topic of Your Choice
  • Where choice begins, Paradise ends --- Arthur
    Miller
  • Richard Hammings obituary (1998)
  • The Innovators Dilemma by Clayton Christensen
    (1997)
  • Perl, Visual Basic popularityTheir popularity
    is important (and good!)

3
Richard Hammings Snare
  • Richard Hammings three questions for new hires
    at Bell Labs
  • What are you working on?
  • Whats the most important open problem in your
    area?
  • Why arent they the same? (Ouch!)
  • You and Your Research --- Richard Hamming
    (1986)

4
The Least Important Open Problem in Programming
Languages
  • Increasing program performance via compiler
    optimization
  • Moores 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

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.

6
Programmer Productivity 3 Approaches
  • Process (software engineering)
  • Controlling programmers
  • 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)

7
Language Design C vs. LISP
  • Whats 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)

8
Programming Language TechnologiesRecent
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

9
New Programming Language! Why Should I Care?
  • The problem is not designing a new language
  • Its easy! Thousands of languages have been
    developed
  • The problem is how to get wide adoption of the
    new language
  • Its hard! Challenges include
  • Competition
  • Usefulness
  • Interoperability
  • Fear
  • Can other useful languages succeed? I think so.
  • Im avoiding the problem of how to design an
    elite language
  • Its a good idea, but its a new idea
    therefore, I fear it and must reject it. ---
    Homer Simpson

10
The Innovators 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 books back cover
  • Why is C/C losing steam? ?
  • Can we use the books lessons to help future
    language efforts? (Not the books
    intent)

11
The Innovators DilemmaCable-Actuated Excavators
  • A disruptive technology hydraulic mechanisms
  • Disadvantage in primary market small, unreliable
  • Advantage in secondary market safe, attaches to
    tractor
  • Sold in small, low-margin market independent
    contractors
  • Established companies concentrate and innovate on
    primary market ignore secondary capacity (for
    excavation)
  • Timely improvements lessen disruptive
    technologys liabilities, increasing markets,
    market share, margins, etc.

12
The Innovators Dilemma C
  • A disruptive technology safe, GCed
    interpreters
  • Disadvantage SLOW
  • Advantage Rapid Application Develop
  • Sold in small, low-margin market web developers,
    ISVs
  • (established competitor ignored market)
  • Established companies concentrate on primary
    differentiator SPEED
  • Timely improvements lessen disruptive
    technologys liabilities, increasing markets,
    market share, margins, etc.
  • Moores Law (for free!)
  • RAD enhancements

13
Perl, Visual Basic, Java vs. C(Programmer
Productivity vs. Speed)
14
Distinguishing/Disruptive TechnologiesAlleviatin
g Real Problems
  • Perl
  • Scripting with data structures (duct tape)
  • Regular expressions
  • Visual Basic
  • Drag-and-drop environment (Windows for the
    masses)
  • Component-friendly
  • Java
  • Browser applets
  • Language integration yields pervasive patterns
    and abstractions

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

16
Future Disruptive Language Technologies(My
Recurring Wish List)
  • My criteria technology must
  • Have disadvantages
  • Be ignored by recent PLDI andPOPL conferences
    (but not others)
  • Alleviate real problemsWhat does it do?
  • For each candidate technology 2 slides
  • Opportunity whats the issue?
  • Current solutions whats done now
  • Proposal sketch of language solution
  • Disadvantages why some (many?) will scoff
  • Unmet needs benefits to adopters

17
Candidate Flight Data Recorders
  • Opportunity How do you debug a program that
    misbehaved after the error occured?
  • Microsoft Watson experience
  • 50 of crashes caused by 1 of bugs.
  • Current solutions
  • Ad hoc attempts to reproduce error condition
  • Examine stack trace, program state (core dump)

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

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
  • Doesnt scale well to unbounded undo
  • Programmatic checkpoint by saving select data to
    file
  • Subject to judgment (and error)
  • Undo by saving operations and their inverse data
  • Tedious
  • Error-prone

20
Disruptive Checkpoints/Undo
  • Make checkpointing and undo (i.e., restoreto
    checkpoint) primitives in theprogramming
    language. Transactions.
  • Important disadvantages
  • External side-effects pose limitations(e.g.,
    I/O)
  • Slower than hand-crafted solution
  • Unmet needs
  • Simplicity
  • Automation

checkpoint X ltrandom codegt restore/commit X
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
  • Poor access to non-SQL resources
  • Construct SQL queries by hand in host language
  • No compile-time checks
  • Tedious
  • Embed SQL into host language via quoting
  • Poor integration of host types and SQL types

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

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)

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
  • XML grammar has 80 productions

25
Candidate Manipulating XML
  • Opportunity How to manipulate XML documents
  • ltstudentsgt
  • ltnamegtGracelt/namegt
  • ltnamegtSusanlt/namegt
  • ltnamegtAnnettelt/namegt
  • lt/studentsgt
  • Current solutions
  • Marshal into and out of native data structures
  • Use Document Object Model structures and API
  • Use XML-specific sublanguage like XPath/XSLT
  • Javas a drug you rub on venture capitalists to
    make them crazy.--- John Doerr, (JavaOne 1996)

26
Disruptive XML Manipulation
  • Give XML first-class status for creation,
    pattern-matching and manipulation. E.g.,
  • x ltnamegtGracelt/namegt
  • ltnamegt?ylt/namegt x
  • foreach ltstudentsgt?ylt/studentsgt x do ltSgt
  • Important disadvantages
  • Declarative pattern matching may be slow
  • Unmet needs
  • XML integration into general purpose language
  • Compile-time checking of XML manipulations.

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

28
Disruptive Constraint Solvers
  • Adding linear programming constraint solver (or,
    better, integer programming) to a programming
    language
  • Important disadvantages
  • Slower than tailored algorithmicsolutions
  • Unmet needs
  • Quick and dirty solutions
  • Visual layout (Interviews-Tk?)

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!

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.

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
  • Were a small group Chris Fraser, Dave Hanson
    and me
  • Were recruiting! (Full-time and interns)
  • Email toddpro_at_microsoft.com

32
The End
About PowerShow.com