In this interview, Scala creator Martin Odersky talks with Bill Venners and Frank Sommers about the compromises and most important goals in Scala's design, its object-oriented innovations, and what's in it for you.

http://www.artima.com/scalazine/articles/goals_of_scala.html

Odersky said in this interview, "It's debatable whether the compromises we made were altogether a bad thing, or whether they were actually good." What's your opinion? What do you think of the goals and innovations listed, and how important is Scala's ability to make more concise classes, especially for immutable objects, to you?

I am a professional Java programmer. I have a Ph.D. in electrical engineering. Recently, I stared experimenting with Scala. After working with the language for sometime, not very long, what the author stated here started make sense to me.

I guess the problem in the world could be broadly broken in to two main categories: data intensive and relationship intensive. Object-oriented approach is good to wrap data in such a way that it could be processed and used in many different ways.

But there are many other problems, which might be better to wrap in a relationship view. For example, in electrical engineering, there is the Ohm's Law, which states Voltage = Resistance * Current. The representation of Voltage, Current and Resistance could be using real number, complex number or vector/matrix. It is rather difficult to write a generic Ohm's Law using Java.

What I found is that my Scala code is more easy to change architecturely/structurely. I can move a piece of code, normally written in a Scala function, move freely than the same code written in a Java method.

I am still a newbie. I would like to thank the author to give the world such a wonderful language.

Mike

The set of value types is fixed (not user extendable). Presumably this is a consequence of JVM limitations. Is this a compromise that you would like to remove in future versions?

> The set of value types is fixed (not user extendable).
> Presumably this is a consequence of JVM limitations. Is
> this a compromise that you would like to remove in future
> versions?

Mark, what do you imagine you would do with this feature? Would you use it primarily for performance reasons?

> Mark, what do you imagine you would do with this feature?
> Would you use it primarily for performance reasons?
Firstly it appears to be an arbitrary decision unless you refer to the detail of the JVM implementation.

For practical use, there are numerous methods in Java which take a int[], float[], or double[] parameter which is interpreted as x values in the even positions and y values in the odd positions. This is rather ugly in an OO language, but there is a significant performance benefit. Anything isomorphic to a point or complex value benefits from this treatment. For classes much bigger than this (2 or 3 double values), the benefit soon disappears.

I suspect that 99% of the unmet value type requirement could be covered by

Point
Point.Float
Point.Double
Complex.Float
Complex.Double

> For practical use, there are numerous methods in Java
> which take a int[], float[], or double[] parameter which
> is interpreted as x values in the even positions and y
> values in the odd positions. This is rather ugly in an OO
> language, but there is a significant performance benefit.
> Anything isomorphic to a point or complex value benefits
> from this treatment. For classes much bigger than this (2
> or 3 double values), the benefit soon disappears.

A while back I read some pretty interesting stuff about how escape analysis in the JVM could potentially eliminate heap allocations of objects and even eliminate the object by putting the variables directly on the stack.

I guess I'm wondering if something akin to this could be done for the problem you are addressing. In other words, could a smarter VM make it unnecessary to define new primitives.

In The Origins of Scala, you mention the Nice programming language.

Nice's treatment of null values is perfect, IMHO: references are non-nullable by default, and you need to explicitly declare that a reference may be null with a question mark.

http://nice.sourceforge.net/manual.html#optionTypes

Wouldn't this approach work in Scala?

> A while back I read some pretty interesting stuff about
> how escape analysis in the JVM could potentially eliminate
> heap allocations of objects and even eliminate the object
> by putting the variables directly on the stack.
>
> I guess I'm wondering if something akin to this could be
> done for the problem you are addressing. In other words,
> could a smarter VM make it unnecessary to define new
> primitives.

My understanding is that it is very hard for the VM to transparently turn an array of references to objects into an array of values. The VM may well be able to eliminate individual occurences, but 'flattening' an array is hard.

Thus this is a problem for types which are commonly managed in large arrays --- essentially points and complex values. The object form results in a typical overhead of 3 'words' (24 bytes on a 64 bit VM) per value, while the content of a double complex is 'just' 16 bytes. Then more than half the cache is wasted on unnecessary values. (Main memory may be cheap, but cache and memory bandwidth remain significant limitations in some applications).

> My understanding is that it is very hard for the VM to
> transparently turn an array of references to objects into
> an array of values. The VM may well be able to eliminate
> individual occurences, but 'flattening' an array is hard.

I can see that this would hard for mutable types and I'm probably missing something but if the types in question were immutable (and the VM 'knows', of course) it seems like it should be able to extract the variables onto the array transparently.

> I can see that this would hard for mutable types and I'm
> probably missing something but if the types in question
> were immutable (and the VM 'knows', of course) it seems
> like it should be able to extract the variables onto the
> array transparently.

Another requirement is that object equality isn't used (== in Java). I'm not sure if that together with immutability is sufficient to allow the VM to replace objects with values.

> Another requirement is that object equality isn't used (==
> in Java). I'm not sure if that together with immutability
> is sufficient to allow the VM to replace objects with
> values.

That's what I was missing (one thing at least).

One possible solution to that issue would be for a language to have a special subset of object types that are value types. This wouldn't help with supporting Java integration, of course.

Not directly related ...
but here's a blog entry from Tim Bray, expressing skeptism about the whole 'functional programming' paradigm (see section on Tail recursion).

http://www.tbray.org/ongoing/When/200x/2009/05/11/Tech-Tab-Sweep

Also pointers to Guido (Python)'s blog entries where he shares similar sentiments about functional programming.

Comments?

-jb

Guido is mostly saying it (tail recursion) doesn't fit with Python which is fair enough, while Tim Bray's gripe is with a language where tail recursion is the only way to loop. I wouldn't argue with that either.

The problem I see with Scala's tail recursion is its fairly limited scope --- it is too easy to write a method that you expect to tail recurse and find that you are getting regular recursion and stack overflow.

> but here's a blog entry from Tim Bray, expressing skeptism
> about the whole 'functional programming' paradigm (see
> section on Tail recursion).

Anybody who thinks tail calls are just about "loops" does not understand functional programming. Take their opinions about the benefits and drawbacks of FP with a boulder sized grain of salt.

About multimethods, it is said
"""
We might have wanted to experiment with something more radical such as multi-methods, [...]. It would have been an exciting possibility to explore, but we didn't do it because we wanted to stay compatible with Java.
"""

I don't understand: the Nice language had multimethods for many years and it was still compatible with java, so why where they considered incompatible with java when designing scala?