The Artima Developer Community
Articles | News | Weblogs | Books | Forums
Artima Forums | Articles | Weblogs | Java Answers | News
Sponsored Link •

Articles Forum
The Goals of Scala's Design

17 replies on 2 pages. Most recent reply: Jun 2, 2009 4:01 PM by Raoul Duke

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 17 replies on 2 pages [ 1 2 | » ]
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

The Goals of Scala's Design Posted: May 10, 2009 10:00 PM
Reply to this message Reply
Advertisement
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?


Mike Zhou

Posts: 1
Nickname: mikezhou
Registered: May, 2009

Re: The Goals of Scala Posted: May 11, 2009 7:09 PM
Reply to this message Reply
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

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Goals of Scala's Design Posted: May 12, 2009 5:33 AM
Reply to this message Reply
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?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Goals of Scala's Design Posted: May 12, 2009 6:26 AM
Reply to this message Reply
> 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 Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Goals of Scala's Design Posted: May 12, 2009 6:46 AM
Reply to this message Reply
> 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

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Goals of Scala's Design Posted: May 12, 2009 7:57 AM
Reply to this message Reply
> 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.

Daniel Serodio

Posts: 13
Nickname: dserodio
Registered: Apr, 2006

Re: The Goals of Scala's Design Posted: May 12, 2009 8:07 AM
Reply to this message Reply
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?

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Goals of Scala's Design Posted: May 12, 2009 8:08 AM
Reply to this message Reply
> 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).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Goals of Scala's Design Posted: May 12, 2009 8:36 AM
Reply to this message Reply
> 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.

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Goals of Scala's Design Posted: May 12, 2009 8:46 AM
Reply to this message Reply
> 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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The Goals of Scala's Design Posted: May 12, 2009 9:15 AM
Reply to this message Reply
> 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.

johny boyd

Posts: 28
Nickname: johnyboyd
Registered: Apr, 2007

Re: The Goals of Scala's Design Posted: May 13, 2009 1:33 PM
Reply to this message Reply
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

Mark Thornton

Posts: 275
Nickname: mthornton
Registered: Oct, 2005

Re: The Goals of Scala's Design Posted: May 13, 2009 1:53 PM
Reply to this message Reply
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.

James Iry

Posts: 85
Nickname: jiry
Registered: Nov, 2007

Re: The Goals of Scala's Design Posted: May 18, 2009 7:43 PM
Reply to this message Reply
> 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.

gabriele renzi

Posts: 5
Nickname: riffraff
Registered: Nov, 2003

Re: The Goals of Scala's Design Posted: May 21, 2009 9:21 AM
Reply to this message Reply
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?

Flat View: This topic has 17 replies on 2 pages [ 1  2 | » ]
Topic: The Point of Pattern Matching in Scala Previous Topic   Next Topic Topic: The Purpose of Scala's Type System
Sponsored Links


Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use