[pypy-svn] r48292 - pypy/extradoc/talk/roadshow-ibm

[pedronis at codespeak.net]

Author: pedronis
Date: Sun Nov  4 16:24:38 2007
New Revision: 48292

Modified:
   pypy/extradoc/talk/roadshow-ibm/talk.txt
Log:
tweak and shuffle



Modified: pypy/extradoc/talk/roadshow-ibm/talk.txt
==============================================================================
--- pypy/extradoc/talk/roadshow-ibm/talk.txt	(original)
+++ pypy/extradoc/talk/roadshow-ibm/talk.txt	Sun Nov  4 16:24:38 2007
@@ -20,7 +20,6 @@
 
 Targets as different as C and the industry OO VMs (JVM, CLR) are supported.
 
-
 What is PyPy
 ==============
 
@@ -30,49 +29,36 @@
 
 We want the tool-chain itself to be as simple as possible.
 
-We operate both as an open source with production usage aspirations and
-research project.
-
-We focus on the whole system.
-
-Some of what we do is relatively straight-forward, some is challenging
-(generating dynamic compilers!).
-
-
-
-
-What is PyPy?
-==============
-
-PyPy is a tool-chain with a *new paradigm* for building interpreters:
-
-It challenges commonly held assumptions about the
-construction of interpreters for dynamic languages.
 
 Folk Wisdom about Interpreters for Dynamic Languages
 ====================================================
 * There are unavoidable tradeoffs between flexibilty, maintainability,
   and speed
 
-* Popular dynamic languages such as Python and Ruby are the best we
-  can do given these tradeoffs and constraints.
-
 * Fast, Maintainable, Flexible -- pick one
 
 What this means in Practice
 ===========================
 
-Dynamic languages are not very flexible.
+Current popular open source dynamic language implemtations:
+
+* are relatively slow
+
+* are not very flexible:
 
 - Low-level decisions permeate the entire code base.
 - One cannot simply plug-in a new garbage collector, or threading model
   when one desires to experiment.  
 - Early decisions come back to haunt you.
 
-Dynamic languages are hard to maintain.
+What this means in Practice (2)
+==================================
 
-- because they are traditionally written in low-level languages, they are
-  harder to write than they need be.
+.. XXX too big
+
+* are harder to maintain than we would like them to be
+
+- because they are traditionally written in low-level languages
 - the language community, which generates experts in the dynamic langauge,
   can not use this expertise in its own maintenance.  Instead, expertise
   in C, or C++ is usually needed.
@@ -80,12 +66,18 @@
   The maintainers of Jython and IronPython, for instance, are lost to the
   C Python community.  They have enough to do just to keep up with C Python.
 
-Dynamic Languages are Slow.
+PyPy as a project
+===================
+
+We operate both as an open source with production usage aspirations and
+research project.
+
+We focus on the whole system.
+
+Some of what we do is relatively straight-forward, some is challenging
+(generating dynamic compilers!).
 
-Thus it looks like what we really have is:
-* Fast, Maintainable, Flexible -- you get NONE.
 
-There has got to be a better way.
 
 Translation: Going from interpreters to VMs
 ==============================================