*** empty log message ***

1 files changed, 7 insertions, 33 deletions

diff --git a/doc/reference/RationalePart.tex b/doc/reference/RationalePart.tex
index a757ec2779..0b8defc75e 100644
--- a/doc/reference/RationalePart.tex
+++ b/doc/reference/RationalePart.tex
@@ -3,10 +3,10 @@
 There are hundreds of programming languages in active use, and many
 more are being designed each year. It is therefore hard to justify the
 development of yet another language. Nevertheless, this is what we
-attempt to do here. The justification for doing so rests on two claims:
+attempt to do here.  Our argument is based on two claims:
 \begin{itemize}
 \item[] {\em Claim 1:} The raise in importance of web services and
-other distributed software represents a fundamental paradigm
+other distributed software is a fundamental paradigm
 shift in programming. It is comparable in scale to the shift 20 years ago
 from character-oriented to graphical user interfaces.
 \item[] {\em Claim 2:} That paradigm shift will provide demand
@@ -59,29 +59,6 @@ to adapt the treatment to the kind of node encountered. Such type
 tests and type casts are generally not considered good object-oriented
 style. They are rarely efficient, nor easy to use.
 
-By contrast, tree transformation is the natural domain of functional
-languages. Their algebraic data types, pattern matching and
-higher-order functions make these languages ideal for the task. It's
-no wonder, then, that specialized languages for transforming XML data
-such as XSLT are functional.
-
-Another reason why functional language constructs are attractive for
-web-services is that mutable state is problematic in this setting.
-Components with mutable state are harder to replicate or to restore
-after a failure. Data with mutable state is harder to cache than
-immutable data. Functional language constructs make it relatively easy
-to construct components without mutable state.
-
-Many web services are constructed by combining different languages.
-For instance, a service might use XSLT to handle document
-transformation, XQuery for database access, and Java for the
-``business logic''.  The downside of this approach is that the
-necessary amount of cross-language glue can make applications
-cumbersome to write, verify, and maintain. A particular problem is
-that cross-language interfaces are usually not statically typed.
-Hence, the benefits of a static type system are missing where they are
-needed most -- at the join points of components written in different
-paradigms.  
 
 Conceivably, the glue problem could be addressed by a ``multi-paradigm''
 language that would express object-oriented, concurrent, as well
@@ -90,10 +67,11 @@ not to simply replace cross-language glue by awkward interfaces
 between different paradigms within the language itself.  Ideally, one
 would hope for a fusion which unifies concepts found in different
 paradigms instead of an agglutination, which merely includes them side
-by side.  This fusion is what we try to achieve with Scala\footnote{Scala
-stands for ``Scalable Language''. The name means ``Stairway'' in Italian}.
+by side.  This fusion is what we try to achieve with Scala
+\footnote{Scala stands for ``Scalable Language''. The term means
+  ``Stairway'' in Italian}.
 
-Scala is both an an object-oriented and a functional language.  It is a
+Scala is both an object-oriented and functional language.  It is a
 pure object-oriented language in the sense that every value is an
 object. Types and behavior of objects are described by
 classes. Classes can be composed using mixin composition.  Scala is
@@ -142,7 +120,7 @@ composition constructs of object-oriented languages. The unification
 is made possible by means of a new type system based on path-dependent
 types \cite{odersky-et-al:fool10}.
 \end{itemize}
-Ther are several other languages that try to bridge the gap between
+There are several other languages that try to bridge the gap between
 the functional and object oriented
 paradigms. Smalltalk\cite{goldberg-robson:smalltalk-language},
 Python\cite{rossum:python}, or Ruby\cite{matsumtoto:ruby} come to
@@ -160,7 +138,3 @@ excessive type annotations in user programs can usually be avoided.
 %chapters contain the language definition. The definition is formulated
 %in prose but tries to be precise.
 
-
-
-
-