[pypy-svn] rev 1660 - pypy/trunk/doc/funding

[pedronis at codespeak.net]

Author: pedronis
Date: Fri Oct 10 14:03:01 2003
New Revision: 1660

Modified:
   pypy/trunk/doc/funding/B1.0_objectives.txt
Log:
reedit of B1 Problem to be Solved, major points:

1) I swapped 2 paragraphs
2) I have changed:

"""
The architecture of current interpreter implementations, on the other
hand, is generally focused on performance issues.
"""
into

"""
The architectures of current interpreter implementations are a
compromise between initial simplicity, Unix-style portability and
performance in a single code base.
"""

1) it's me bothering about our first reference to "interpreters" in the old version being dangling/unclear.




Modified: pypy/trunk/doc/funding/B1.0_objectives.txt
==============================================================================
--- pypy/trunk/doc/funding/B1.0_objectives.txt	(original)
+++ pypy/trunk/doc/funding/B1.0_objectives.txt	Fri Oct 10 14:03:01 2003
@@ -6,41 +6,42 @@
 ---------------------------
 
 Current language implementations are static and hard to modify by
-users.  Even the open-source languages are designed in a non-flexible
-way by a small group of developers.  While designing a good programming
-language is no easy task often application developers seek more 
-support and configurability of their language. This is especially
-the case for the rising number of specialized runtime environments
-where small memory footprints, concurrency or realtime features 
-are essential.
-
-The architecture of current interpreter implementations, on the other
-hand, is generally focused on performance issues. The resulting
-monolithic (C) code base is inflexible and expensive to maintain. Early
-design decisions concerning aspects such as memory management, object
-model and layout, security, multi-threading model are deeply tangled in
-the code and cannot be reverted, experimented with or adapted to
-specific runtime environments. 
-
-Very-high-level languages (VHLL) offer a highly productive development 
-environment.  However, whole-program static compilation is often not 
-suitable, so that VHLL are usually implemented by introducing a bytecode 
-and interpretation level, resulting in a loss of performance.  This is 
-in contrast to lower-level languages such as C, which offer performance 
-but greatly decrease productivity.
-
-Thus user pressure tends to shape interpreters towards performance at
-the expense of other aspects (simplicity, flexibility), possibly
-culminating with the introduction of a native JIT, adding a significant
-amount of code and complexity and further impairing the
+users.  Even the implementations of open-source dynamic languages have
+non-flexible designs crafted by a small group of developers.  While
+designing a good programming language is no easy task often
+application developers seek more support and configurability of their
+language. This is especially the case for the rising number of
+specialized runtime environments where small memory footprints,
+concurrency or realtime features are essential.
+
+Very-high-level languages (VHLL) offer a highly productive development
+tool.  However, whole-program static compilation is often not
+suitable, so that VHLL are usually implemented by introducing a
+bytecode and interpretation level, resulting in a loss of performance.
+This is in contrast to lower-level languages such as C, which offer
+performance but greatly decrease productivity.
+
+The architectures of current interpreter implementations are a
+compromise between initial simplicity, Unix-style portability and
+performance in a single code base. The resulting monolithic (C) code
+bases are inflexible and expensive to evolve. Early design decisions
+concerning aspects such as memory management, object model and layout,
+security, multi-threading model are deeply tangled in the code and
+cannot be reverted, experimented with or adapted to specific runtime
+environments.
+
+In the long run, user pressure tends to shape interpreters towards
+performance at the expense of other aspects (simplicity, flexibility),
+possibly culminating with the introduction of a native JIT, adding a
+significant amount of code and complexity and further impairing the
 flexibility. [S03]_
 
-Subsequently, application developers are often left with bad choices not
-only for productivity versus performance, but they have to work around
-the hard-wired characteristics built into the languages. Instead they
-would like to adapt and configure a VHLL to suit their needs while at 
-the same time developing on top of a custom but standardised language 
-offering both productivity and performance.
+Consequently, application developers are often left with bad choices
+not only for productivity versus performance, but they have to work
+around the hard-wired characteristics built into the
+languages. Instead they would like to adapt and configure a VHLL to
+suit their needs while at the same time developing on top of a custom
+but standardised language offering both productivity and performance.
 
 
 Quantified specific objective