|
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
The Goals of Scala's Design
May 10, 2009 9:00 PM
|
|
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? |
|
Posts: 1 / Nickname: mikezhou / Registered: May 11, 2009 0:45 PM
Re: The Goals of Scala
May 11, 2009 6:09 PM
|
|
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 |
|
Posts: 2 / Nickname: dserodio / Registered: April 25, 2006 4:06 AM
Re: The Goals of Scala's Design
May 12, 2009 7:07 AM
|
|
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? |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: The Goals of Scala's Design
May 12, 2009 4:33 AM
|
|
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?
|
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: The Goals of Scala's Design
May 12, 2009 5:26 AM
|
|
> 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? |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: The Goals of Scala's Design
May 12, 2009 5:46 AM
|
|
> 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 |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: The Goals of Scala's Design
May 12, 2009 6:57 AM
|
|
> 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. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: The Goals of Scala's Design
May 12, 2009 7:08 AM
|
|
> 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). |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: The Goals of Scala's Design
May 12, 2009 7:36 AM
|
|
> 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. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: The Goals of Scala's Design
May 12, 2009 7:46 AM
|
|
> 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. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: The Goals of Scala's Design
May 12, 2009 8:15 AM
|
|
> 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. |
|
Posts: 11 / Nickname: johnyboyd / Registered: April 26, 2007 3:17 AM
Re: The Goals of Scala's Design
May 13, 2009 0:33 PM
|
|
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 |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: The Goals of Scala's Design
May 13, 2009 0:53 PM
|
|
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. |
|
Posts: 11 / Nickname: jiry / Registered: November 15, 2007 2:29 AM
Re: The Goals of Scala's Design
May 18, 2009 6:43 PM
|
|
> 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. |
|
Posts: 5 / Nickname: riffraff / Registered: November 18, 2003 4:43 AM
Re: The Goals of Scala's Design
May 21, 2009 8:21 AM
|
|
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? |
|
Posts: 15 / Nickname: modersky / Registered: September 14, 2003 9:46 PM
Re: The Goals of Scala's Design
May 22, 2009 5:15 AM
|
|
> 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? Well there's compatible and compatible. For instance Swing uses static overloading in really wild ways. Can we guarantee that a multi-method scheme would still always resolve correctly? Can we guarantee that one can write new Swing components that always work correctly? Maybe we can, but I just don't know for sure. I would have liked to have had the time to explore this in depth when Scala was first designed. What scared me off at that time was that MultiJava had both multi-methods and a separate static overloading mechanism. Given that this is rather clunky and MultiJava's designers are bright people, the only reason for them doing this that I could imagine was compatibility problems. But I might have been too paranoid. Btw, are there signficant applications using Swing in Nice (inluding ones that define their own components)? If yes, that would be a good indicator that the problems are more mangeable than I feared. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: The Goals of Scala's Design
May 26, 2009 5:36 AM
|
|
I was not sure about pattern matching at first and I'm still not completely sure I understand how to use it to it's full potential but it's clear that it does everything you can do with multi-methods and more. It's more explicit than multi-methods too. If I had my druthers, I'd get rid of method overloading completely in Scala. It's been one of the biggest sources of hair-pulling for me in my Java career and doesn't provide any real benefits.
|
|
Posts: 20 / Nickname: raoulduke / Registered: April 14, 2006 11:48 AM
Re: The Goals of Scala's Design
June 2, 2009 3:01 PM
|
|
> but it's clear that it does everything
> you can do with multi-methods and more. hmmm. |