Summary
A quick introduction where I come from and what led up to Scala.
Advertisement
This is my first blog at Artima.com. I'll be writing mostly about
language design and the Scala programming language.
But first, let me introduce myself. At university, I had my first
programming class (in Algol60, no less! -- I believe we were the last
class to be taught in that language). Whenever my program had a syntax
error, the TA of the course mumbled something about my program not
passing the compiler. I deduced that a compiler would be a sort of
small computer that would be sitting between my teletype and the real
computer. Its task would be to prepare my program so that the real
computer could concentrate on the hard part, which would be executing
the program I wrote. It seemed to me at the time that compilation was
much simpler than, say, evaluating a polynomial with Horner's rule.
When I found out what a compiler really was, I was hooked. I went on
to write compilers for Pascal and Modula-2. Afterwards, I joined
Niklaus Wirth's group at ETH Zuerich
as a Ph.D. student, working on
Modula-2 and Oberon. After that, I fell in love with functional
programming and wrote a lot of papers on calculi and type systems for
functional programming languages (most of them are on my website).
In 1995 I learned about Java and teamed up with Philip Wadler to
write a functional language that compiles to Java bytecodes. This work
on Pizza led eventually to GJ, the new javac compiler, and Java
generics. It was exciting to do work on Java because of its huge
impact, but it was also very difficult because Java is a rich language
with many features which often conflict with extensions in unforeseen
ways.
In 1999, I joined EPFL. I thought that I would now use my academic
freedom to do language design starting from a clean sheet. I still
wanted to combine functional and object-oriented programming, but
without the restrictions imposed by Java. I had found out about
join calculus, and believed that this would be a great foundation on
which to base such a unification. The result was Funnel, a
programming language for functional nets. This was a beautifully
simple design, with very few primitive language features. Almost
everything, including classes and pattern matching, would be done by
libraries and encodings.
However, it turned out that the language was not very pleasant to use
in practice. Minimalism is great for language designers but not for
users. Non-expert users don't know how to do the necessary encodings,
and expert users get bored having to do them over and over again.
Also, it became quickly apparent that any new language has a chance of
being accepted only if it comes with a large set of standard
libraries.
Funnel led to Scala, whose design began in 2001, and which was first
released in 2003. Scala is not an extension of Java, but it is
completely interoperable with it. Scala translates to Java bytecodes,
and the efficiency of its compiled programs usually equals Java's. A
second implementation of Scala compiles to .NET. (this version is currently
out of date, however).
Scala was designed to be both object-oriented and functional. It is a
pure object-oriented language in the sense that every value is an
object. Objects are defined by classes, which can be composed using
mixin composition. Scala is also a functional language in the sense
that every function is a value. Functions can be nested, and they can
operate on data using pattern matching.
The Scala user community is still relatively small, but it's
growing. We currently see about 1000 downloads per month of the
Scala distribution on our website.
I'll write more about specific aspects of Scala in the coming blogs.
For now I log off with the "hello-world" program written in Scala:
Scala rocks !! I have been trying to evangelize Scala amongst the programming community. I like the solid advanced type system of Scala - Scala has really brought us the delights of all the functional as well as OO constructs within the framework of static typechecking. I have extensively blogged about some of the remarkable features of Scala. Pls see the following :
> Scala rocks !! > I'd like to add that I've been quite intrigued by Scala too. I have only read the documents, though. I haven't had time to actually play with writing code in it, but I was really happy that Martin wanted to start blogging about it here.
One of my fears with Scala is that despite it's pragmatic basis (runs on JVM) it will remain a language only used by academics and uber-geeks and lack acceptance in the 'real-world'.
I plan to learn more anyway but clearly the interest I have is not unique and I see that as a fairly good sign.
I've deployed a document transfer application written in Scala into a customer's environment. The client thinks that it is a regular Java application. Works for me :)
I've puzzled over how OO and functional languages might be combined, so Scala is intriguing.
One of the greatest strengths I perceive in functional languages is the solution to the concurrency problem (for readers: a call in a functional language has no side effects, so it can be executed as a separate task without worrying that it will conflict with other tasks).
I'm interested in Scala, as well as a couple languages for the CLR - Boo and Nemerle. I'm curious how much of the compiler API is exposed through the compiler library in order to facilitate completion, refactoring, etc for an Eclipse plugin.
Boo and Nemerle expose much of the compiler API for this. But unless there's good IDE integration, I suspect many developers will pass it over.
> I've puzzled over how OO and functional languages might be > combined, so Scala is intriguing. > > One of the greatest strengths I perceive in functional > languages is the solution to the concurrency problem (for > readers: a call in a functional language has no side > effects, so it can be executed as a separate task without > worrying that it will conflict with other tasks). > > Does Scala solve this problem?
Scala isn't a pure functional language like Haskell or Clean. But programming in a more functional manner in Scala or Nemerle can help in finding opportunities for concurency. In Nemerle the default variable type is immutable. So you have to annotate your real variables with the mutable keyword. I'm not sure about Scala though.
With dual cores hitting the mainstream machines now, functional-style programming should see a renewed interest.
One of the fundamental reasons to want to merge object-oriented and functional programming is that object-orientation gives you a convenient mechanism for adding new datatypes that respond in different ways to various functions without messing with the original code, while functional programming gives you a convenient mechanism for adding new functions without messing with the original code.
The best technique I've seen for making both easy to do is multiple-dispatch object-oriented programming, i.e., multimethods. (Such as in the Dylan programming language).
I don't understand why Scala uses a single-dispatch object-oriented model, and I hope that Odersky will explain this design decision in a future article.
> One of the fundamental reasons to want to merge > object-oriented and functional programming is that > object-orientation gives you a convenient mechanism for > adding new datatypes that respond in different ways to > various functions without messing with the original code, > while functional programming gives you a convenient > mechanism for adding new functions without messing with > the original code. > > The best technique I've seen for making both easy to do is > multiple-dispatch object-oriented programming, i.e., > multimethods. (Such as in the Dylan programming > language). > > I don't understand why Scala uses a single-dispatch > object-oriented model, and I hope that Odersky will > explain this design decision in a future article.
It's disappointing that Apple didn't give Dylan more of a chance to get out there. It's still one of my favorite languages. I still think that separating data structures, functions/generic methods via multimethods, and a proper module system is a lot cleaner way to do OO than the Java/C# way.
There was a discussion about multimethods on the mailinglist either last month or in April. It didn't look promising though.
> I've puzzled over how OO and functional languages might be > combined, so Scala is intriguing. > > One of the greatest strengths I perceive in functional > languages is the solution to the concurrency problem (for > readers: a call in a functional language has no side > effects, so it can be executed as a separate task without > worrying that it will conflict with other tasks). > > Does Scala solve this problem?
Yes and no. Scala does not prevent side effects, but it makes it easier to program without them. There is also a library for actors which implement all the essentials of Erlang-style processes. This library is thread-based, and thus shares the usual restrictions of the JVM on number of threads. Another, as yet experimental, library for actors is event-based and scales up to hundreds of thousands of processes.
> I'm interested in Scala, as well as a couple languages for > the CLR - Boo and Nemerle. I'm curious how much of the > compiler API is exposed through the compiler library in > order to facilitate completion, refactoring, etc for an > Eclipse plugin. > There is actually a pretty decent Eclipse plugin for Scala. It has syntax highlighting, automatic project builds, completion, but (not yet) refactoring. It will have debugger integration real soon now. See: http://scala.epfl.ch/downloads/eclipse/index.html
> The best technique I've seen for making both easy to do is > multiple-dispatch object-oriented programming, i.e., > multimethods. (Such as in the Dylan programming > language). > > I don't understand why Scala uses a single-dispatch > object-oriented model, and I hope that Odersky will > explain this design decision in a future article.
Thanks for the suggestion! I'll try to write something up about this soon. In short, I also think that multi-methods are appealing as a alternative for static overloading. The issue is whether one can do this switch from static to dynamic overloading and still stay compatible with all the existing Java libraries. Swing for example uses very intricate patterns of static overloading.
Flat View: This topic has 61 replies
on 5 pages
[
12345
|
»
]