From 2102c85d8d5fe408914ae2e4609fcc8524a6be34 Mon Sep 17 00:00:00 2001 From: Martin Odersky Date: Tue, 20 Jan 2004 14:31:22 +0000 Subject: *** empty log message *** --- doc/reference/RationalePart.tex | 40 +++++++--------------------------------- 1 file changed, 7 insertions(+), 33 deletions(-) (limited to 'doc') 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. - - - - -- cgit v1.2.3