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

[lac at codespeak.net]

Author: lac
Date: Sun Nov  4 13:12:41 2007
New Revision: 48282

Modified:
   pypy/extradoc/talk/roadshow-ibm/talk.txt
Log:
Ok, try the non-challenging, non-threatening version



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 13:12:41 2007
@@ -13,48 +13,43 @@
 It challenges commonly held assumptions about the
 construction of interpreters for dynamic languages.
 
-What we Reject
-==============
-* Interpreters for Dynamic Languages must be slow
-
-* Fast, Maintainable, Flexible -- pick one
-
-* C is the most appropriate language for implementing interpreters.
-
-* C++ is the most appropriate language for implementing interpreters.
-
-* Requiring type-hints everywhere, thus turning your dynamic language
-  into a static one, on the sly
-
-What we insist upon
-===================
+Folk Wisdom about Interpreters for Dynamic Languages
+====================================================
+* There are unavoidable tradeoffs between flexibilty, maintainability,
+  and speed
 
-* real source code portability between different target implementations
+* Popular dynamic languages such as Python and Ruby are the best we
+  can do given these tradeoffs and constraints.
 
-* support for an actual existing dynamic language, not an academic toy
-
-* support for the complete language, not a subset
-
-* The interpreter we write should be free of low-level details as possible
-
-* the ability to experiement with all aspects of the compiler, including
-  garbage collection strategies, threading models, security models
-
-* fun
+* Fast, Maintainable, Flexible -- pick one
 
-Implications?
-=============
+What this means in Practice
+===========================
 
-* type analysis must be performed on live code objects, not dead source trees
+Dynamic languages are not very flexible.
 
-* parts of the interpreter must be written in a static manner.
+- 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.
+
+- because they are traditionally written in low-level languages, they are
+  harder to write than they need be.
+- 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.
+- every time a new VM is needed, there is a fork in the language community.
+  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.
 
-* Generate compilers using partial evaluation techniques.  Don't write them
-  by hand!
+Dynamic Languages are Slow.
 
-* Build a toolchain with pluggable components, for e.g. garbage collection
+Thus it looks like what we really have is:
+* Fast, Maintainable, Flexible -- you get NONE.
 
-* The translation framework can be reused by _any_ dynamic language!
+There has got to be a better way.
 
 Translation details
 =======================