diff options
author | Martin Odersky <odersky@gmail.com> | 2004-01-19 12:06:29 +0000 |
---|---|---|
committer | Martin Odersky <odersky@gmail.com> | 2004-01-19 12:06:29 +0000 |
commit | 94d7bcd7ab135de76ca1f5719f1dd6e5122acb99 (patch) | |
tree | 3b73ffffbfffb49b501ac9df074a31c71e067dcb /doc/reference/Rationale.tex | |
parent | 1dbc00126bf0e660b0286ac247271549158bcb65 (diff) | |
download | scala-94d7bcd7ab135de76ca1f5719f1dd6e5122acb99.tar.gz scala-94d7bcd7ab135de76ca1f5719f1dd6e5122acb99.tar.bz2 scala-94d7bcd7ab135de76ca1f5719f1dd6e5122acb99.zip |
*** empty log message ***
Diffstat (limited to 'doc/reference/Rationale.tex')
-rw-r--r-- | doc/reference/Rationale.tex | 107 |
1 files changed, 68 insertions, 39 deletions
diff --git a/doc/reference/Rationale.tex b/doc/reference/Rationale.tex index 5187663f1e..66df5d85e6 100644 --- a/doc/reference/Rationale.tex +++ b/doc/reference/Rationale.tex @@ -2,8 +2,8 @@ There are hundreds of programming languages in active use, and many more are being designed each year. It is therefore very hard to justify the development -of yet another language. Nevertheless, this is what I attempt to do here. My -argument rests on two claims: +of yet another language. Nevertheless, this is what we attempt to do here. +Our effort is based on two claims: \begin{itemize} \item[] {\em Claim 1:} The raise in importance of web services and other distributed software is a fundamental paradigm @@ -13,6 +13,20 @@ from character-oriented to graphical user interfaces. for new programming languages, just as graphical user interfaces promoted the adoption of object-oriented languages. \end{itemize} +For the last 20 years, the most common programming model is the +object-oriented one: System components are objects, and computation is +done by method calls. Methods themselves take object references as +parameters. Remote method calls let one extend this programming model +to distributed systems. The problem of this model with respect to wide +scale distribution is that it does not scale up very well to networks +where messages can be delayed and components may fail. Web services +address the message delay problem by increasing granularity, using +method calls with larger, structured arguments, such as XML trees. +They address the failure problem by avoiding server state and +transparent replication. Conceptually, they are {\em tree +transformers} that consume incoming message documents and produce outgoing +ones. +\comment{ To back up the first claim, one observes that web services and other distributed software increasingly tend to communicate using structured or semi-structured data. A typical example is the use of XML to describe data @@ -27,45 +41,60 @@ each other by transmitting asynchronous messages that carry structured documents, usually in XML format. Programs then conceptually become {\em tree transformers} that consume incoming message documents and produce outgoing ones. +} + +Why should this change in system architecture have an effect on +programming languages? There are at least two reasons: First, today's +object-oriented languages are not very good tools for analyzing and +transforming XML trees. Because such trees usually contain data but no +methods, they have to be decomposed and constructed from the +``outside'', that is from code which is external to the tree +definition itself. In an object-oriented language, the ways of doing +so are limited. The most common solution \cite{dom} is to represent +trees in a generic way, where all tree nodes are values of a common +type. This makes it easy to write generic traversal functions, but +forces applications to operate on a very low conceptual level, which +often loses important semantic distinctions present in the XML data. +Semantically more precise is to use different internal types to model +different kinds of nodes. But then tree decompositions require the +use of run-time type tests and type casts 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. -To back up the second claim, one notes that today's object-oriented languages -are not very good tools for analyzing and transforming the trees which -conceptually model XML data. Because these trees usually contain data but no -methods, they have to be decomposed and constructed from the ``outside'', that is -from code which is external to the tree definition itself. In an -object-oriented language, the ways of doing so are limited. The most common -solution is to represent trees in a generic way, where all tree nodes are -values of a common type. This approach is used in DOM, for instance. It -facilitates the implementation of generic traversal functions, but forces -applications to operate on a very low conceptual level, which often loses -important semantic distinctions that are present in the XML data. A -semantically more precise alternative would be to use different internal types -to model different kinds of nodes. But then tree decompositions require the use -of run-time type tests and type casts 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. +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. -Web services can be constructed using such a transformation language -together with some middleware framework such as Corba to handle -distribution and an object-oriented language for the ``application -logic''. The downside of this approach is that the necessary amount -of cross-language glue can make applications cumbersome to write, -verify, and maintain. Better productivity and trustworthiness is -achievable using a single notation and conceptual framework that would -express object-oriented, concurrent, as well as functional aspects of -an application. Hence, a case for so called ``multi-paradigm'' -languages can be made. But one needs to be careful not to simply -replace cross-language glue by awkward interfaces between different -paradigms within the language itself. The benefits of integration are -realized fully only if the common language achieves a meaningful -unification of concepts rather than being merely an agglutination of -different programming paradigms. This is what we try to achieve with -Scala\footnote{Scala stands for ``Scalable Language''.}. +The glue problem could be addressed by a ``multi-paradigm'' language +and that would express object-oriented, concurrent, as well as +functional aspects of an application. But one needs to be careful 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 is what we try to achieve with Scala\footnote{Scala stands for +``Scalable Language''.}. Scala is both an an object-oriented and functional language. It is a pure object-oriented language in the sense that every value is an |