This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Scala whiskers

20 replies
Justin Johansson
Joined: 2008-12-14,
User offline. Last seen 3 years 45 weeks ago.

It seems to me, and possibly others, that Scala is growing whiskers.

Scala needs shaving .. with Occam's razor that is.
Ref: http://en.wikipedia.org/wiki/Occam%27s_razor

Substantial arguments:

There is a growing indistinction in Scala between traits and classes,
especially given recent debate on this list (and LAMP research) about
traits evolving to have constructors.
That is definitely whisker material deserving of a good Occam.

Scala has done wonders to render readable programs to lesser keystrokes to
type and characters to read for authors and readers alike.
There is now little syntactic difference between vals and defs of zero
arguments.
The meanings of val and def are now so overlapping to the point of reaching
diminishing returns for the Scala programmer's investment in time in
deciding which to use.
Having reached terminal velocity, an optimizing (Scala) compiler could well
reduce defs of zero arguments to vals anyway.
It's time to apply Occam and deprecate vals (in favour of defs) forthwith.

[To keep this post short, let's stop there for now. Those in favour of the
razor, please add to these arguments.]

Subjective arguments:

On a linear scale, Java is to C++ as Scala is to Java.

Unless it is to be just an academic fad, Scala needs to achieve an
exponential leap (from Java).

Contra-arguments:

Scala attempts to meld functional & OO idioms; of course there will be
blurring in any attempt to taxonimize classes, traits, (singleton) objects
etc.; taxonomy is never perfect in any domain; so just enjoy growing a beard.

There are many ways to achieve ends in Fortran, C++ and Java. Scala is no
different and nor should be.

[These arguments beg more substance from the devil & his advocates.]

The above is just my humble opinion so, please, no need for flames, just
constructive debate [from both sides].

Bests to all,
Justin Johansson

Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Scala whiskers
val and def have very different evaluation semantics

On Fri, Dec 19, 2008 at 11:52 AM, Justin Johansson <mail [at] justinjohansson [dot] com> wrote:
It seems to me, and possibly others, that Scala is growing whiskers.

Scala needs shaving .. with Occam's razor that is.
Ref: http://en.wikipedia.org/wiki/Occam%27s_razor

Substantial arguments:

There is a growing indistinction in Scala between traits and classes,
especially given recent debate on this list (and LAMP research) about
traits evolving to have constructors.
That is definitely whisker material deserving of a good Occam.

Scala has done wonders to render readable programs to lesser keystrokes to
type and characters to read for authors and readers alike.
There is now little syntactic difference between vals and defs of zero
arguments.
The meanings of val and def are now so overlapping to the point of reaching
diminishing returns for the Scala programmer's investment in time in
deciding which to use.
Having reached terminal velocity, an optimizing (Scala) compiler could well
reduce defs of zero arguments to vals anyway.
It's time to apply Occam and deprecate vals (in favour of defs) forthwith.

[To keep this post short, let's stop there for now.  Those in favour of the
razor, please add to these arguments.]

Subjective arguments:

On a linear scale, Java is to C++ as Scala is to Java.

Unless it is to be just an academic fad, Scala needs to achieve an
exponential leap (from Java).

Contra-arguments:

Scala attempts to meld functional & OO idioms; of course there will be
blurring in any attempt to taxonimize classes, traits, (singleton) objects
etc.;  taxonomy is never perfect in any domain; so just enjoy growing a beard.

There are many ways to achieve ends in Fortran, C++ and Java.  Scala is no
different and nor should be.

[These arguments beg more substance from the devil & his advocates.]


The above is just my humble opinion so, please, no need for flames, just
constructive debate [from both sides].

Bests to all,
Justin Johansson



Justin Johansson
Joined: 2008-12-14,
User offline. Last seen 3 years 45 weeks ago.
Re: Scala whiskers

Thanks for that Jorge.

Please tell more. Your response suggests that both val and def are
"evaluated" in some fashion, so at least "evaluatability" (computability)
is something in common between val and def.

In your estimation, what do you see as common between val and def and what
is saliently different?

Erkki Lindpere
Joined: 2008-12-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers

I don't think Scala should be substantially changed, but I would like to
see another language, "a simplified Scala", which focuses on the strong
sides of Scala (not 100% sure what that would leave out) and drops many
features to reduce complexity. If I knew anything about compilers, I
would try to implement it myself.
The simplified Scala should be something that is more tuned for
applications and DSL-s, but less tuned for writing compilers.

Erkki

Justin Johansson wrote:
> It seems to me, and possibly others, that Scala is growing whiskers.
>
> Scala needs shaving .. with Occam's razor that is.
> Ref: http://en.wikipedia.org/wiki/Occam%27s_razor
>
> Substantial arguments:
>
> There is a growing indistinction in Scala between traits and classes,
> especially given recent debate on this list (and LAMP research) about
> traits evolving to have constructors.
> That is definitely whisker material deserving of a good Occam.
>
> Scala has done wonders to render readable programs to lesser keystrokes to
> type and characters to read for authors and readers alike.
> There is now little syntactic difference between vals and defs of zero
> arguments.
> The meanings of val and def are now so overlapping to the point of reaching
> diminishing returns for the Scala programmer's investment in time in
> deciding which to use.
> Having reached terminal velocity, an optimizing (Scala) compiler could well
> reduce defs of zero arguments to vals anyway.
> It's time to apply Occam and deprecate vals (in favour of defs) forthwith.
>
> [To keep this post short, let's stop there for now. Those in favour of the
> razor, please add to these arguments.]
>
> Subjective arguments:
>
> On a linear scale, Java is to C++ as Scala is to Java.
>
> Unless it is to be just an academic fad, Scala needs to achieve an
> exponential leap (from Java).
>
> Contra-arguments:
>
> Scala attempts to meld functional & OO idioms; of course there will be
> blurring in any attempt to taxonimize classes, traits, (singleton) objects
> etc.; taxonomy is never perfect in any domain; so just enjoy growing a beard.
>
> There are many ways to achieve ends in Fortran, C++ and Java. Scala is no
> different and nor should be.
>
> [These arguments beg more substance from the devil & his advocates.]
>
>
> The above is just my humble opinion so, please, no need for flames, just
> constructive debate [from both sides].
>
> Bests to all,
> Justin Johansson
>
>
>

James Iry
Joined: 2008-08-19,
User offline. Last seen 1 year 23 weeks ago.
Re: Scala whiskers


On Fri, Dec 19, 2008 at 9:52 AM, Justin Johansson <mail [at] justinjohansson [dot] com> wrote:

There is a growing indistinction in Scala between traits and classes,
especially given recent debate on this list (and LAMP research) about
traits evolving to have constructors.
That is definitely whisker material deserving of a good Occam.

Even when/if traits have all the power of classes, we may be stuck with this whisker due to Java compatibility.
 

Having reached terminal velocity, an optimizing (Scala) compiler could well
reduce defs of zero arguments to vals anyway.

I have no idea what terminal velocity of an optimizing compiler is.  But that's not a sound transformation in an impure, Turing complete language.  In the absence of side effects, a def maybe could be reduced to a lazy val but the type system can't prove that (yet). 
 
First, the turing complete issue

def a : Int = b
def b : Int = a

This doesn't cause an infinite loop until you try to evaluate a or b.  Transform it into vals and your program gets stuck.

Now the impure issue

def a = println("hello")

Everytime you evaluate a you get another "hello" on the screen.   Convert it into a val and you get a "hello" once.


David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers
I've been doing Scala coding for 2+ years.  I strongly disagree with your statement and your sentiment.

On Fri, Dec 19, 2008 at 9:52 AM, Justin Johansson <mail [at] justinjohansson [dot] com> wrote:
It seems to me, and possibly others, that Scala is growing whiskers.

Scala needs shaving .. with Occam's razor that is.
Ref: http://en.wikipedia.org/wiki/Occam%27s_razor

Substantial arguments:

There is a growing indistinction in Scala between traits and classes,
especially given recent debate on this list (and LAMP research) about
traits evolving to have constructors.
That is definitely whisker material deserving of a good Occam.

Except traits have mixin rules and can be used to compose programs and reason about programs in a way that classes do not.  On the other hand, given the limitations of the JVM, it's necessary to have classes and it will continue to be necessary for the foreseeable future.  If you have a suggestion about how to either distinguish or unify, let's hear it, but otherwise, I find this complain baseless.
 


Scala has done wonders to render readable programs to lesser keystrokes to
type and characters to read for authors and readers alike.
There is now little syntactic difference between vals and defs of zero
arguments.

There are huge differences between these two constructs and understanding how to use them in your program and what they mean is very important.  As far as I can tell, you're complaining that val and def have three characters and thus have little syntactic difference.  Not only is this complain completely baseless, but it indicates that you do not understand the basic concept of when a computation takes place.
 

The meanings of val and def are now so overlapping to the point of reaching
diminishing returns for the Scala programmer's investment in time in
deciding which to use.
Having reached terminal velocity, an optimizing (Scala) compiler could well
reduce defs of zero arguments to vals anyway.

It cannot do so without an effects system.  There are also performance reasons to choose a def rather than a val... or a lazy val.
 

It's time to apply Occam and deprecate vals (in favour of defs) forthwith.

No, it's not.
 


[To keep this post short, let's stop there for now.  Those in favour of the
razor, please add to these arguments.]

Subjective arguments:

On a linear scale, Java is to C++ as Scala is to Java.

This is wrong.
 


Unless it is to be just an academic fad, Scala needs to achieve an
exponential leap (from Java).

And who the heck are you to make such a statement.  You don't even understand the difference between val and def.
 


Contra-arguments:

Scala attempts to meld functional & OO idioms; of course there will be
blurring in any attempt to taxonimize classes, traits, (singleton) objects
etc.;  taxonomy is never perfect in any domain; so just enjoy growing a beard.

There are many ways to achieve ends in Fortran, C++ and Java.  Scala is no
different and nor should be.

[These arguments beg more substance from the devil & his advocates.]


The above is just my humble opinion so, please, no need for flames, just
constructive debate [from both sides].

Bests to all,
Justin Johansson





--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Scala whiskers
val random = new scala.util.Random
val valRandInt = random.nextInt
def defRandInt = random.nextInt

valRandInt says: get one one random Int and return the same Int every time I ask for it.
defRandInt says: give me a (possibly) different random random Int every time I ask for one

--j

On Fri, Dec 19, 2008 at 12:12 PM, Justin Johansson <mail [at] justinjohansson [dot] com> wrote:
Thanks for that Jorge.

Please tell more. Your response suggests that both val and def are
"evaluated" in some fashion, so at least "evaluatability" (computability)
is something in common between val and def.

In your estimation, what do you see as common between val and def and what
is saliently different?

Justin Johansson
Joined: 2008-12-14,
User offline. Last seen 3 years 45 weeks ago.
Re: Scala whiskers

Thanks for the polite response Jorge.

Your "random" example succinctly explains the difference between val and
def in contemporary Scala.
This is an excellent example which would satify the casual Scala user
perfectly.

May I say that I knew that already, though you would not have known that (I
knew that) due limitations of email communication.

I remain, however, steadfast to my original post and will draw references
from "Programming in Scala, A step to step guide" by Odersky, Spoon and
Venners to support my (original) argument in due course.

Unfortunately my time zone is diammetrically opposite to that of most
others on this list (it's now 5.15 am in Australia) and the midnight oil
has long burned out.

Russ Abbott
Joined: 2008-12-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers
Justin's question has bothered me as well. (I raised it earlier and don't recall getting a response that settled the issue for me.)

In simplest terms, for me the question comes down to this. What are the essential differences between:

val f : <parameters> => <result type> = <body>

and

def f(<parameters>) : <result type> = <body>


One difference is that you can't use type parameters in the val version. I don't understand why it would be a bad idea to extend Scala to allow that.

A second difference is that as Seth pointed out the def version allows function name overloading whereas the val version doesn't.  That seems to me to be a bit harder to solve. I once proposed a solution. But let's leave that issue to the side for a moment and forget about name overloading.

A third difference is that val creates a first class object; def does not.

Unless there is something I don't see, it appears that val can do everything def can do and in addition makes first class objects. If that is the case, I don't understand why it would be a bad idea to eliminate def as a user level construct.  Why wouldn't that simplify the language without reducing its capabilities?


-- Russ

On Fri, Dec 19, 2008 at 11:36 AM, Justin Johansson <mail [at] justinjohansson [dot] com> wrote:
Thanks for the polite response Jorge.

Your "random" example succinctly explains the difference between val and
def in contemporary Scala.
This is an excellent example which would satify the casual Scala user
perfectly.

May I say that I knew that already, though you would not have known that (I
knew that) due limitations of email communication.

I remain, however, steadfast to my original post and will draw references
from "Programming in Scala, A step to step guide" by Odersky, Spoon and
Venners to support my (original) argument in due course.

Unfortunately my time zone is diammetrically opposite to that of most
others on this list (it's now 5.15 am in Australia) and the midnight oil
has long burned out.

Erik Engbrecht
Joined: 2008-12-19,
User offline. Last seen 3 years 18 weeks ago.
Re: Scala whiskers
Do you really want an object to be created for every method you define?

On Fri, Dec 19, 2008 at 2:54 PM, Russ Abbott <russ [dot] abbott [at] gmail [dot] com> wrote:
Justin's question has bothered me as well. (I raised it earlier and don't recall getting a response that settled the issue for me.)

In simplest terms, for me the question comes down to this. What are the essential differences between:

val f : <parameters> => <result type> = <body>

and

def f(<parameters>) : <result type> = <body>


One difference is that you can't use type parameters in the val version. I don't understand why it would be a bad idea to extend Scala to allow that.

A second difference is that as Seth pointed out the def version allows function name overloading whereas the val version doesn't.  That seems to me to be a bit harder to solve. I once proposed a solution. But let's leave that issue to the side for a moment and forget about name overloading.

A third difference is that val creates a first class object; def does not.

Unless there is something I don't see, it appears that val can do everything def can do and in addition makes first class objects. If that is the case, I don't understand why it would be a bad idea to eliminate def as a user level construct.  Why wouldn't that simplify the language without reducing its capabilities?


-- Russ

On Fri, Dec 19, 2008 at 11:36 AM, Justin Johansson <mail [at] justinjohansson [dot] com> wrote:
Thanks for the polite response Jorge.

Your "random" example succinctly explains the difference between val and
def in contemporary Scala.
This is an excellent example which would satify the casual Scala user
perfectly.

May I say that I knew that already, though you would not have known that (I
knew that) due limitations of email communication.

I remain, however, steadfast to my original post and will draw references
from "Programming in Scala, A step to step guide" by Odersky, Spoon and
Venners to support my (original) argument in due course.

Unfortunately my time zone is diammetrically opposite to that of most
others on this list (it's now 5.15 am in Australia) and the midnight oil
has long burned out.

-- Justin



At 12:22 PM 19/12/2008 -0600, you wrote:
>>>>
val random = new scala.util.Random
val valRandInt = random.nextInt
def defRandInt = random.nextInt

valRandInt says: get one one random Int and return the same Int every time
I ask for it.
defRandInt says: give me a (possibly) different random random Int every
time I ask for one

--j

On Fri, Dec 19, 2008 at 12:12 PM, Justin Johansson
<<mailto:mail [at] justinjohansson [dot] com>mail [at] justinjohansson [dot] com> wrote:
Thanks for that Jorge.

Please tell more. Your response suggests that both val and def are
"evaluated" in some fashion, so at least "evaluatability" (computability)
is something in common between val and def.

In your estimation, what do you see as common between val and def and what
is saliently different?

-- Justin

>>>>
val and def have very different evaluation semantics





--
http://erikengbrecht.blogspot.com/
Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Scala whiskers
If you eliminated def it would be impossible to create Scala classes that were reasonably accessible from Java.

On Fri, Dec 19, 2008 at 1:54 PM, Russ Abbott <russ [dot] abbott [at] gmail [dot] com> wrote:
Justin's question has bothered me as well. (I raised it earlier and don't recall getting a response that settled the issue for me.)

In simplest terms, for me the question comes down to this. What are the essential differences between:

val f : <parameters> => <result type> = <body>

and

def f(<parameters>) : <result type> = <body>


One difference is that you can't use type parameters in the val version. I don't understand why it would be a bad idea to extend Scala to allow that.

A second difference is that as Seth pointed out the def version allows function name overloading whereas the val version doesn't.  That seems to me to be a bit harder to solve. I once proposed a solution. But let's leave that issue to the side for a moment and forget about name overloading.

A third difference is that val creates a first class object; def does not.

Unless there is something I don't see, it appears that val can do everything def can do and in addition makes first class objects. If that is the case, I don't understand why it would be a bad idea to eliminate def as a user level construct.  Why wouldn't that simplify the language without reducing its capabilities?


-- Russ

On Fri, Dec 19, 2008 at 11:36 AM, Justin Johansson <mail [at] justinjohansson [dot] com> wrote:
Thanks for the polite response Jorge.

Your "random" example succinctly explains the difference between val and
def in contemporary Scala.
This is an excellent example which would satify the casual Scala user
perfectly.

May I say that I knew that already, though you would not have known that (I
knew that) due limitations of email communication.

I remain, however, steadfast to my original post and will draw references
from "Programming in Scala, A step to step guide" by Odersky, Spoon and
Venners to support my (original) argument in due course.

Unfortunately my time zone is diammetrically opposite to that of most
others on this list (it's now 5.15 am in Australia) and the midnight oil
has long burned out.

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Scala whiskers
It seems to me, and possibly others, that Scala is growing whiskers.

I am too.  They keep me warm.
 
There is now little syntactic difference between vals and defs of zero
arguments.

There is a big semantic difference because the expression on the right hand side of the = can have side effects.

The meanings of val and def are now so overlapping to the point of reaching
diminishing returns for the Scala programmer's investment in time in
deciding which to use.

I only understood the first part of this sentence, and it's wrong for the reason I stated above.  The second appears to have been written in bullshit.

Having reached terminal velocity, an optimizing (Scala) compiler could well
reduce defs of zero arguments to vals anyway.

Not all, thanks to side effects.  Not as many as you'd hope either, thanks to separate compilation.
 
Unless it is to be just an academic fad, Scala needs to achieve an
exponential leap (from Java).

It's already not an academic fad.  Outside of EFPL, I think most Scala users are not in academia. 
Tony Morris
Joined: 2008-12-19,
User offline. Last seen 30 weeks 4 days ago.
Re: Scala whiskers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The differences between def and val are so enormous that it might even
be considered the single biggest difference that one could possibly
conceive in the language. Certainly those differences are a
fundamental property of the language such that if one or the other
were removed, would render the language fatally useless (as in, even
more useless than Java).

I am comforted by the supposition that any programming language
designer is at the very least aware of these facts and so such a
destructive act would never occur - even out of ignorance, phew.

http://en.wikipedia.org/wiki/Evaluation_strategy

Justin Johansson wrote:
> The meanings of val and def are now so overlapping to the point of reaching
> diminishing returns for the Scala programmer's investment in time in
> deciding which to use.
> Having reached terminal velocity, an optimizing (Scala) compiler could well
> reduce defs of zero arguments to vals anyway.
> It's time to apply Occam and deprecate vals (in favour of defs) forthwith.

- --
Tony Morris
http://tmorris.net/

S, K and I ought to be enough for anybody.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklMJygACgkQmnpgrYe6r61XOACguGnxoRaAf9xVdqrES3F0jU6s
01YAoLxmRqWF3+UUCFPudnLHJ3+NHPDw
=2IpV
-----END PGP SIGNATURE-----

Russ Abbott
Joined: 2008-12-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers
To comment in reverse order.

The differences between def and val are so enormous that it might even
be considered the single biggest difference that one could possibly
conceive in the language. Certainly those differences are a
fundamental property of the language such that if one or the other
were removed, would render the language fatally useless (as in, even
more useless than Java).

I am comforted by the supposition that any programming language
designer is at the very least aware of these facts and so such a
destructive act would never occur - even out of ignorance, phew.

This is not a useful answer. I understand that you have strong feelings about this, and perhaps that you think it's stupid of me even to raise the issue. But it doesn't help me see the error of my ways. I'd appreciate some concrete examples.

You can't just leave these issues to the side and forget about them.
Inheritance, overloading, covariance and contravariance, etc, are the
major issues you hit when you try to combine functional and
object-oriented programming in a Java-compatible(*) way.  If you're
doing no OOP and you don't need Java compatibility, you don't need Scala
David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers


On Fri, Dec 19, 2008 at 3:58 PM, Russ Abbott <russ [dot] abbott [at] gmail [dot] com> wrote:
To comment in reverse order.


The differences between def and val are so enormous that it might even
be considered the single biggest difference that one could possibly
conceive in the language. Certainly those differences are a
fundamental property of the language such that if one or the other
were removed, would render the language fatally useless (as in, even
more useless than Java).

I am comforted by the supposition that any programming language
designer is at the very least aware of these facts and so such a
destructive act would never occur - even out of ignorance, phew.

This is not a useful answer. I understand that you have strong feelings about this, and perhaps that you think it's stupid of me even to raise the issue. But it doesn't help me see the error of my ways. I'd appreciate some concrete examples.


You can't just leave these issues to the side and forget about them.
Inheritance, overloading, covariance and contravariance, etc, are the
major issues you hit when you try to combine functional and
object-oriented programming in a Java-compatible(*) way.  If you're
doing no OOP and you don't need Java compatibility, you don't need Scala
Russ Abbott
Joined: 2008-12-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers
Just to clarify, I wasn't suggesting that there be no methods in the "Scala machine" only that methods be limited to classes that are predefined in the language and that they not be available at the Scala developer level.

-- Russ Abbott
_____________________________________________
Professor, Computer Science
California State University, Los Angeles
o Check out my blog at http://russabbott.blogspot.com/


On Fri, Dec 19, 2008 at 4:27 PM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:


On Fri, Dec 19, 2008 at 3:58 PM, Russ Abbott <russ [dot] abbott [at] gmail [dot] com> wrote:
To comment in reverse order.


The differences between def and val are so enormous that it might even
be considered the single biggest difference that one could possibly
conceive in the language. Certainly those differences are a
fundamental property of the language such that if one or the other
were removed, would render the language fatally useless (as in, even
more useless than Java).

I am comforted by the supposition that any programming language
designer is at the very least aware of these facts and so such a
destructive act would never occur - even out of ignorance, phew.

This is not a useful answer. I understand that you have strong feelings about this, and perhaps that you think it's stupid of me even to raise the issue. But it doesn't help me see the error of my ways. I'd appreciate some concrete examples.


You can't just leave these issues to the side and forget about them.
Inheritance, overloading, covariance and contravariance, etc, are the
major issues you hit when you try to combine functional and
object-oriented programming in a Java-compatible(*) way.  If you're
doing no OOP and you don't need Java compatibility, you don't need Scala
John Nilsson
Joined: 2008-12-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers
On Sat, Dec 20, 2008 at 1:27 AM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:
In Scala functions are objects.  At the first level, if you redefine all methods as functions so that the only thing an instance has on it are a bunch of named slots (instance variables) that contain functions, you'll have to create a new function object for each method on each instance of an object that you create.  This is a waste of time and space and breaks compatibility with Java.  And for what?  Some sense of symmetry?

David, I think you are confusing language semantics with implementation details here. What happends at the low level of bytecode is implementation and optimization details. Just like Scala allready handles "primitives" as objects at a semantic level the byte code can be either java primitives or boxed versions of them depending on the optimizaiton oppertunities of the compiler.
Unifying objects and primitives into the single concept of objects worked. What I read from the suggestion about methods and function is to do something similar, just a unification of the semantics.
Also you shouldnt just write it of as "some sense of symmetry". It's not symmetry to remove a semantic concept, its reduction of complexity. The less complexity you have in the language semantics the easier it is to reason about a snippet of code. The brain simply has a limited capacity to deal with complexity, any reduction could result in magnitudes of productivity improvements.
It is also the case that if you remove one concept in favor of using a more general one you automatically force the design in the direction where the ramaining concepts must be composable in more flexible ways to achieve the same ends. I think that such a design is ultimatley more usable and more powerfull.
(Note that I haven't expressed any opinions on the actual suggestion, just about the discussion about it...)
BR,John
David Pollak
Joined: 2008-12-16,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers


On Sat, Dec 20, 2008 at 6:42 AM, John Nilsson <john [at] milsson [dot] nu> wrote:
On Sat, Dec 20, 2008 at 1:27 AM, David Pollak <feeder [dot] of [dot] the [dot] bears [at] gmail [dot] com> wrote:
In Scala functions are objects.  At the first level, if you redefine all methods as functions so that the only thing an instance has on it are a bunch of named slots (instance variables) that contain functions, you'll have to create a new function object for each method on each instance of an object that you create.  This is a waste of time and space and breaks compatibility with Java.  And for what?  Some sense of symmetry?

David, I think you are confusing language semantics with implementation details here. What happends at the low level of bytecode is implementation and optimization details. Just like Scala allready handles "primitives" as objects at a semantic level the byte code can be either java primitives or boxed versions of them depending on the optimizaiton oppertunities of the compiler.
Unifying objects and primitives into the single concept of objects worked. What I read from the suggestion about methods and function is to do something similar, just a unification of the semantics.
Also you shouldnt just write it of as "some sense of symmetry". It's not symmetry to remove a semantic concept, its reduction of complexity.

John,

When I woke up this morning, I realized why this concept that does away with methods bugs me so much.  It's because the method/message is the single place where pure OO breaks with "everything is an object."  Even in Smalltalk, messages are something different than objects (although sometime messages can be promoted to objects... for example when handling a missing method.)

At its core, Scala is an Object Oriented language.  See some of Martin's discussions of where he sees Scala breaking new ground.  It's on the OO side of things.

So, if Scala is OO, then methods (messages) are the thing is not an object unless there's an event that promotes it to be an object (e.g., turning it into a function.)

While this does not directly address the reduction of complexity discussion, it does address the brain-slots discussion.  OO trained developers have brain slots for objects and methods/messages.  Barring a compelling reason to change that distinction, I wouldn't.

Is making all methods functions or having all methods expressed in function notation compelling?  I don't think so.  I haven't seen a good reason why:
val foo = (p: String, p1: Int): Int => ....

is better notation than:

def foo(p: String, p1: Int): Int =

Also given that I can refer to foo (and have the compiler promote it to a function) at will, there's no conceptual gain.

In fact, reminding the developer than Scala is an OO language with methods seems to make a lot of sense to me.  The syntax reinforces the semantics that Scala is OO.

Thanks,

David


 
The less complexity you have in the language semantics the easier it is to reason about a snippet of code. The brain simply has a limited capacity to deal with complexity, any reduction could result in magnitudes of productivity improvements.
It is also the case that if you remove one concept in favor of using a more general one you automatically force the design in the direction where the ramaining concepts must be composable in more flexible ways to achieve the same ends. I think that such a design is ultimatley more usable and more powerfull.
(Note that I haven't expressed any opinions on the actual suggestion, just about the discussion about it...)
BR,John



--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
Lauri Alanko
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Scala whiskers

It is well known that it is possible to implement functions on top of
objects, and objects on top of functions (+ records). The former is
trivial, for the latter see e.g.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.2962

If you're going to have a language that supports both objects and
functions (and this seems to be an essential feature of Scala), then,
for economy, you'd prefer to implement one on top of the other,
instead of making them both be primitive.

In _principle_ the choice of which to make primitive is arbitrary, and
your idea, implementing (user-level) objects as records of primitive
functions, is not invalid, when designing a language from scratch. It
is, in general, harder to implement efficiently, though.

But another defining feature of Scala is that it's meant to run on top
of the JVM, and interact with other JVM code. And the JVM provides
primitive support for _objects_, not functions. This being the case,
it's much much more sensible for Scala, too, to have _objects_ as the
underlying primitive concept, and functions defined on top of those.

You seem to be suggesting that the methods visible in user-level
syntax should be translated to record fields with function values in
the conceptual core Scala language (similar to the way that function
values are currently translated to objects), and this core Scala with
functions and records should then be compiled back to JVM that only
supports objects. This is a huge implementation burden for the
compiler, as well as a huge conceptual burden for the programmer who
needs to understand how Scala interoperates with other JVM code.

Lauri

Jorge Ortiz
Joined: 2008-12-16,
User offline. Last seen 29 weeks 3 days ago.
Re: Scala whiskers
Russ,

Let's address some of your points.

First, about the discussion itself, you say: "It would also be good to discuss these questions without answering related but trivial question such as that var values are evaluated once and defs are evaluated whenever they are called. Assuming that the person who asks about the difference between var and def doesn't understand that is insulting, unproductive, and unworthy of a discussion at this level."

Before I reply to those comments, let's recap the history of this thread. Justin stated, in the opening e-mail of this thread: "The meanings of val and def are [...] overlapping." He adds that the "compiler could well reduce defs of zero arguments to vals anyway" and suggested that Scala "deprecate vals [...] forthwith."

(Please note that while you and Justin share a common purpose, namely unifying defs and vals, his concrete proposal is very different from yours. He proposes deprecating vals, while you propose eliminating defs. My responses to each of you are necessarily different.)

Now, I disagree with Justin that "the meanings of val and def are overlapping". As I see it, and as I replied, "val and def have very different evaluation semantics". I did not, as you assert, "assume" that he "doesn't understand" this difference.

(An aside. If, as you propose, defs are eliminated, it is relatively straightforward to see how the evaluation semantics of defs could be mimicked, namely with vals that are Functions. This is something you have pointed out in the past. If, however, as Justin proposes, vals are eliminated, I don't see how their evaluation semantics could be mimicked using just defs. This would, in my opinion, be a terrible loss, as I regularly make use of the evaluation semantics of vals. One could make an inner def and bind an expression to an argument of the inner def everytime one wanted to emulate a val, but that seems tortuous at best. Even this would not allow, for example, classes to have public vals.)

Justin replied to my initial email, asking me to "please tell more". I didn't know an easier way to communicate more of what I meant than by providing a code example, which shows a real difference between val and def that I frequently rely upon, which his proposal would (unless I'm missing something) eliminate.

If this exchange was in any way insulting to Justin, then I apologize. It was certainly not intended that way.

If, however, it was insulting to you, Russ, then I really don't know what to say, as you weren't even involved in the thread up to that point.

*     *     *

Now, to continue, lets discuss your (distinct) proposal to eliminate defs. I have two issues with this. 1) The proposed syntax is ugly, in my opinion. I much prefer the existing def syntax. That said, this is a relatively trivial matter. My more pressing concern is, 2) this would significantly decrease the practical power of Scala, namely, to produce certain kinds of bytecode outputs.

Let's explore this second point a bit further. First, you have not mentioned how your proposal would allow Scala to implement Java interfaces or inherit from Java classes. Perhaps you have something in mind, but you haven't spoken about it.

Second, as I pointed out earlier in this thread, accessing Scala functions from Java would be more painful than accessing Scala methods from Java. Yes, accessing Scala's more advanced features from Java is often painful, but that doesn't mean that using Scala's most basic features from Java should be painful too. You may not care much about this, but for people who frequently mix Scala and Java (and there are many such people) this would certainly be a deal-killer.

Third, if you did manage to resolve these two Java interoperability concerns, I don't see how it could be done without adding some significant method invocation overhead. This could become a performance concern for certain applications.

Fourth, some proposed changes to the language would no longer be possible, at least not in their presently suggested state. For example, the proposal for named and optional parameters is only contemplated to work for methods, and not for functions. This kind of extensibility to the language would be lost if we got rid of methods and were left only with functions.

Fifth, as you point out, your proposal implies that "methods be limited to classes that are predefined in the language and that they not be available at the Scala developer level." In my opinion, this would be a terrible loss. One of the beautiful things about Scala is how little of the language is "compiler magic", and how much of it is really just a part of the Scala libraries, themselves written in Scala. For example, currently the scala.Function1 trait is written in Scala. Yes, this trait is in some sense intimately tied to the compiler. For example, the compiler needs to do some "magic" to turn the expression (x: Int) => x + 1 into an instance of Function1[Int, Int]. However, just because the compiler is aware of the existence of this part of the standard library does not mean there's any magic in the implementation of Function1 itself. Under your proposal, the definition of Function1 would need to be baked into the compiler. Indeed, much of this power to express core parts of Scala in Scala itself would be lost.

This, incidentally, is one of my favorite things about Scala. The Scala compiler and the Scala libraries are written entirely in Scala. This is not true of many other languages. Python, Ruby, and PHP are all written in C. JRuby, Fan, and Clojure are each at least partially written in Java. Even Rubinius, originally conceived as the "Ruby in Ruby" project, is now half Ruby and half C. There's no theoretical impediment to writing a Ruby interpreter in Ruby, but rather a practical impediment. A Ruby interpreter written in Ruby would be so painfully slow that even die-hard "performance doesn't matter" Rubyist wouldn't want to use it. Allowing this kind of practical expressivity (that lets Scala bootstrap itself without sacrificing performance) might tar a bit the theoretical purity of Scala as a language, but I think there's equal (perhaps greater) merit in finding the particular balance that Scala has struck: between being a theoretically coherent language that nevertheless allows those with practical concerns (about performance, say) enough flexibility to achieve what they want.

If you ask me what the difference is between these two lines of code:
  def fn1(x: Int) = x + 1
  val fn2 = (x: Int) => x + 1
Then, yes, you're right. Theoretically, there is not much (if any) difference between them. Practically, however, there is an enormous difference, made manifest in the (very) different bytecodes these two lines of code emit. This distinction may not be important in the classroom, but it is very important in the real world. Scala has a lot of "hacks" like this one. These hacks may not be theoretically pretty, but practically they are essential for Scala to be a credible real world language. If you want a language of theoretical perfection, Scala is not it. As I understand it, Scala is meant to be a language that is, as much as possible, theoretically sound, yet also useful in practice.

(Another aside. Nothing in the above paragraph is meant to be disparaging towards the classroom. I taught introductory programming to college students for almost three years. I have a strong fondness for teaching. Nor are my comments meant to disparage theory. For example, my complaints about Java as a language of instruction for introductory programming are directed precisely at Java's awful balance between theory and practice. If you're concerned with the practical aspects of programming, then students who learn Java as a first language are severely impaired from ever understanding memory management in the future. If you're concerned with the theoretical aspects of computer science, then students who learn Java are bogged down by silly practical distinctions. One student, for example, was very confused by the difference between an Array and an ArrayList. Why were they different, why did they have a different syntax, why could one store ints and Integers but the other only Integers? To get to the root of these problems, I had to explain the difference between objects and primitives, the stack and the heap, explain autoboxing and unboxing and more. Aside from being confusing, these trivial implementation distinctions should be irrelevant to the student first learning the theory of programs. Students learning Scala as a first language would in all likelihood be similarly impaired from ever understanding memory management, but at the very least the theory of programs is much cleaner in Scala than it is in Java. For example, it's worth noting that Scala managed to achieve a theoretical union between Arrays and ArrayLists (well, ArrayBuffer in Scala). Somewhat humorously, this has caused a fair amount of howling and gnashing of teeth from practitioners surprised at the performance characteristics of some uses of Arrays. You win a few, you lose a few.)

So, to address your suggestion: yes, it would make Scala theoretically prettier. In my opinion, this modest theoretical improvement to Scala would not be worth the large practical cost it would impose. If I had to bet, I would say the Scala team would not think the cost was worth it either.

--j

On Fri, Dec 19, 2008 at 5:58 PM, Russ Abbott <russ [dot] abbott [at] gmail [dot] com> wrote:
To comment in reverse order.

The differences between def and val are so enormous that it might even
be considered the single biggest difference that one could possibly
conceive in the language. Certainly those differences are a
fundamental property of the language such that if one or the other
were removed, would render the language fatally useless (as in, even
more useless than Java).

I am comforted by the supposition that any programming language
designer is at the very least aware of these facts and so such a
destructive act would never occur - even out of ignorance, phew.

This is not a useful answer. I understand that you have strong feelings about this, and perhaps that you think it's stupid of me even to raise the issue. But it doesn't help me see the error of my ways. I'd appreciate some concrete examples.

You can't just leave these issues to the side and forget about them.
Inheritance, overloading, covariance and contravariance, etc, are the
major issues you hit when you try to combine functional and
object-oriented programming in a Java-compatible(*) way.  If you're
doing no OOP and you don't need Java compatibility, you don't need Scala
odersky
Joined: 2008-07-29,
User offline. Last seen 45 weeks 6 days ago.
Re: Scala whiskers

Just wanted to say, it's fine to discuss radical language changes like
giving up `def', but it is an ``academic'' dicussion. Scala will
certainly not change to such a degree that would make this possible.
It is what it is, and a lot of work went into making it that. I'm
talking not only of the language definition and the compilers, but
also of all the other tools, libraries, documentation, applications,
all of which would become outdated. So, if people want to discuss
radical design changes, it would be better to do this in the context
of a new language, not Scala.

Cheers

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland