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

Re: Native Compiler for Scala

63 replies
Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Native Compiler for Scala

The problem with JButton having 392 methods (yes, folks, thats three
hundred and ninety-two) is that most of them are useless to those who
actually use JButton directly. It's a really horribly polluted API.

If inheritance is about modelling is-a relationships, and not about
inheriting method definitions, then why are you complaining about only
being able to inherit from one class? You can inherit from as many
interfaces as you like.

Implementing inheritance via implicits in Scala requires more work,
yes, because Scala supports inheritance in the Java sense already.
It's hard to beat native language support in a library.

The reason inheritance is detrimental when used to model is-a, is that
everyone has a different idea of is-a, and a compiler cannot help you
to restrict it to any safe subset. A square is a rectangle.

2009/11/17 Naftoli Gugenheim :
> If you would have said JComponent instead of JButton I would say "what that shows is how limiting single inheritance is."
> But you're complaining that a descendant of the hierarchy inherited a lot of methods. So what's wrong with that?
> And even if there is, I'm not sure what your point is. You said that inheritance is about get some VeryUsefulMethods from an ancestor. I guess you were justifying (sarcastically) describing it as code reuse.
> I responded with JButton, meaning that inheritance is not _about_ having an ancestor with useful methods, but about modelling real-world is-a relationships which implies inheriting functionality. The fact that mathematically there's no distinction between is-a and has-a (apparently) notwithstanding, it has been demonstrated in thid thread (I think) that implementing inheritance via implicits requires plenty more work, not to mention that it's counterintuitive.
> But my point is not to argue in favor of inheritance, but to ask for a reasoning how inheritance, when used to model true is-a, is detrimental per se.
>
>
> -------------------------------------
> Ricky Clarkson wrote:
>
> If you ever think Swing is a source of good examples of inheritance, try:
>
> classOf[javax.swing.JButton].getMethods.length
>
> 2009/11/16 Naftoli Gugenheim :
>> Is that the relationship of JButton to JComponent?
>>
>> -------------------------------------
>> Ricky Clarkson wrote:
>>
>> The way inheritance encourages code reuse is that you create a
>> VeryUsefulClass with a bunch of usefulMethods in it, then subclass
>> VeryUsefulClass to get at the usefulMethods.  It encourages monoliths.
>>
>> There are other ways to reuse code, that don't encourage monoliths.
>>
>> 2009/11/16 Matthew Willson :
>>> I'm quite interested in this debate.
>>>
>>> The "inheritance is just another monomorphism, why make it special" argument appeals to my mathematical side.
>>>
>>> That said there are a lot of similar "x is just a kind of y, so why not generalise?" statements one can make in computer science, and not all of them form a good basis for language design. So I think a nuanced view is required of why inheritance concepts, and the "has a" vs "is a" distinction remain in the current crop of OO languages, which despite their flaws, are successfully used by many to structure software 'in the large'.
>>>
>>> One gut feeling of mine is this:
>>>
>>> So long as a language has concepts of object identity ("is a") whose semantics are at the level of the memory model, then the "is a" vs "has a" distinction will remain relevant.
>>> If you want inheritance to be "just a function" then perhaps making equality "just a function" too is a pre-requisite.
>>>
>>> On 16 Nov 2009, at 07:45, Tony Morris wrote:
>>>
>>>> This guy is on the money
>>>> http://apocalisp.wordpress.com/2009/08/27/hostility-toward-subtyping/
>>>
>>>
>>
>>
>>
>> --
>> Ricky Clarkson
>> Java and Scala Programmer, AD Holdings
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>>
>
>
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

So the problem with inheritance is that the compiler doesn't check that you're doing it right?

-------------------------------------
Ricky Clarkson wrote:

The problem with JButton having 392 methods (yes, folks, thats three
hundred and ninety-two) is that most of them are useless to those who
actually use JButton directly. It's a really horribly polluted API.

If inheritance is about modelling is-a relationships, and not about
inheriting method definitions, then why are you complaining about only
being able to inherit from one class? You can inherit from as many
interfaces as you like.

Implementing inheritance via implicits in Scala requires more work,
yes, because Scala supports inheritance in the Java sense already.
It's hard to beat native language support in a library.

The reason inheritance is detrimental when used to model is-a, is that
everyone has a different idea of is-a, and a compiler cannot help you
to restrict it to any safe subset. A square is a rectangle.

2009/11/17 Naftoli Gugenheim :
> If you would have said JComponent instead of JButton I would say "what that shows is how limiting single inheritance is."
> But you're complaining that a descendant of the hierarchy inherited a lot of methods. So what's wrong with that?
> And even if there is, I'm not sure what your point is. You said that inheritance is about get some VeryUsefulMethods from an ancestor. I guess you were justifying (sarcastically) describing it as code reuse.
> I responded with JButton, meaning that inheritance is not _about_ having an ancestor with useful methods, but about modelling real-world is-a relationships which implies inheriting functionality. The fact that mathematically there's no distinction between is-a and has-a (apparently) notwithstanding, it has been demonstrated in thid thread (I think) that implementing inheritance via implicits requires plenty more work, not to mention that it's counterintuitive.
> But my point is not to argue in favor of inheritance, but to ask for a reasoning how inheritance, when used to model true is-a, is detrimental per se.
>
>
> -------------------------------------
> Ricky Clarkson wrote:
>
> If you ever think Swing is a source of good examples of inheritance, try:
>
> classOf[javax.swing.JButton].getMethods.length
>
> 2009/11/16 Naftoli Gugenheim :
>> Is that the relationship of JButton to JComponent?
>>
>> -------------------------------------
>> Ricky Clarkson wrote:
>>
>> The way inheritance encourages code reuse is that you create a
>> VeryUsefulClass with a bunch of usefulMethods in it, then subclass
>> VeryUsefulClass to get at the usefulMethods.  It encourages monoliths.
>>
>> There are other ways to reuse code, that don't encourage monoliths.
>>
>> 2009/11/16 Matthew Willson :
>>> I'm quite interested in this debate.
>>>
>>> The "inheritance is just another monomorphism, why make it special" argument appeals to my mathematical side.
>>>
>>> That said there are a lot of similar "x is just a kind of y, so why not generalise?" statements one can make in computer science, and not all of them form a good basis for language design. So I think a nuanced view is required of why inheritance concepts, and the "has a" vs "is a" distinction remain in the current crop of OO languages, which despite their flaws, are successfully used by many to structure software 'in the large'.
>>>
>>> One gut feeling of mine is this:
>>>
>>> So long as a language has concepts of object identity ("is a") whose semantics are at the level of the memory model, then the "is a" vs "has a" distinction will remain relevant.
>>> If you want inheritance to be "just a function" then perhaps making equality "just a function" too is a pre-requisite.
>>>
>>> On 16 Nov 2009, at 07:45, Tony Morris wrote:
>>>
>>>> This guy is on the money
>>>> http://apocalisp.wordpress.com/2009/08/27/hostility-toward-subtyping/
>>>
>>>
>>
>>
>>
>> --
>> Ricky Clarkson
>> Java and Scala Programmer, AD Holdings
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>>
>
>
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>

Ricky Clarkson
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Native Compiler for Scala

I'd like you to read more closely.

2009/11/17 Naftoli Gugenheim :
> So the problem with inheritance is that the compiler doesn't check that you're doing it right?
>
> -------------------------------------
> Ricky Clarkson wrote:
>
> The problem with JButton having 392 methods (yes, folks, thats three
> hundred and ninety-two) is that most of them are useless to those who
> actually use JButton directly.  It's a really horribly polluted API.
>
> If inheritance is about modelling is-a relationships, and not about
> inheriting method definitions, then why are you complaining about only
> being able to inherit from one class?  You can inherit from as many
> interfaces as you like.
>
> Implementing inheritance via implicits in Scala requires more work,
> yes, because Scala supports inheritance in the Java sense already.
> It's hard to beat native language support in a library.
>
> The reason inheritance is detrimental when used to model is-a, is that
> everyone has a different idea of is-a, and a compiler cannot help you
> to restrict it to any safe subset.  A square is a rectangle.
>
> 2009/11/17 Naftoli Gugenheim :
>> If you would have said JComponent instead of JButton I would say "what that shows is how limiting single inheritance is."
>> But you're complaining that a descendant of the hierarchy inherited a lot of methods. So what's wrong with that?
>> And even if there is, I'm not sure what your point is. You said that inheritance is about get some VeryUsefulMethods from an ancestor. I guess you were justifying (sarcastically) describing it as code reuse.
>> I responded with JButton, meaning that inheritance is not _about_ having an ancestor with useful methods, but about modelling real-world is-a relationships which implies inheriting functionality. The fact that mathematically there's no distinction between is-a and has-a (apparently) notwithstanding, it has been demonstrated in thid thread (I think) that implementing inheritance via implicits requires plenty more work, not to mention that it's counterintuitive.
>> But my point is not to argue in favor of inheritance, but to ask for a reasoning how inheritance, when used to model true is-a, is detrimental per se.
>>
>>
>> -------------------------------------
>> Ricky Clarkson wrote:
>>
>> If you ever think Swing is a source of good examples of inheritance, try:
>>
>> classOf[javax.swing.JButton].getMethods.length
>>
>> 2009/11/16 Naftoli Gugenheim :
>>> Is that the relationship of JButton to JComponent?
>>>
>>> -------------------------------------
>>> Ricky Clarkson wrote:
>>>
>>> The way inheritance encourages code reuse is that you create a
>>> VeryUsefulClass with a bunch of usefulMethods in it, then subclass
>>> VeryUsefulClass to get at the usefulMethods.  It encourages monoliths.
>>>
>>> There are other ways to reuse code, that don't encourage monoliths.
>>>
>>> 2009/11/16 Matthew Willson :
>>>> I'm quite interested in this debate.
>>>>
>>>> The "inheritance is just another monomorphism, why make it special" argument appeals to my mathematical side.
>>>>
>>>> That said there are a lot of similar "x is just a kind of y, so why not generalise?" statements one can make in computer science, and not all of them form a good basis for language design. So I think a nuanced view is required of why inheritance concepts, and the "has a" vs "is a" distinction remain in the current crop of OO languages, which despite their flaws, are successfully used by many to structure software 'in the large'.
>>>>
>>>> One gut feeling of mine is this:
>>>>
>>>> So long as a language has concepts of object identity ("is a") whose semantics are at the level of the memory model, then the "is a" vs "has a" distinction will remain relevant.
>>>> If you want inheritance to be "just a function" then perhaps making equality "just a function" too is a pre-requisite.
>>>>
>>>> On 16 Nov 2009, at 07:45, Tony Morris wrote:
>>>>
>>>>> This guy is on the money
>>>>> http://apocalisp.wordpress.com/2009/08/27/hostility-toward-subtyping/
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Ricky Clarkson
>>> Java and Scala Programmer, AD Holdings
>>> +44 1565 770804
>>> Skype: ricky_clarkson
>>> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>>> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>>>
>>
>>
>>
>> --
>> Ricky Clarkson
>> Java and Scala Programmer, AD Holdings
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>>
>
>
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>

nilskp
Joined: 2009-01-30,
User offline. Last seen 1 year 27 weeks ago.
Re: Native Compiler for Scala
On Tue, Nov 17, 2009 at 8:39 AM, Ricky Clarkson <ricky [dot] clarkson [at] gmail [dot] com> wrote:
It's a really horribly polluted API.

How about
classOf[scala.collection.immutable.List[_]].getMethods.length
Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

I'll try. :)
You made four points.
1. Most of what JButton inherits is useless when you use it directly. Can you give an example?
2. Inheriting multiple interfaces. I'm not sure what you mean here but it may have resulted from misunderstanding my comment. What I was trying to say is that when I started reading your email I thought you were going to point out a flaw in single inheritance. Never mind--it's irrelevant.
3. With native compiler support it would be easier. Let's discuss this after everything else. In any case it's not a problem with inheritance but a qualification of its advantage, if you will.
4. "The reason inheritance is detrimental when used to model is-a, is that everyone has a different idea of is-a, and a compiler cannot help you to restrict it to any safe subset." I think this is the bag vs. set article. The compiler cannot tell you that set breaks bag's contract. Hence, you have to use good judgement yourself. Or factor the hierarchy so parents have the most lenient contracts. "A square is a rectangle." I'm not sure what you want with this.
Okay, I did my best reading you closely! :) If I misunderstood please correct me!
-------------------------------------
Ricky Clarkson wrote:

I'd like you to read more closely.

2009/11/17 Naftoli Gugenheim :
> So the problem with inheritance is that the compiler doesn't check that you're doing it right?
>
> -------------------------------------
> Ricky Clarkson wrote:
>
> The problem with JButton having 392 methods (yes, folks, thats three
> hundred and ninety-two) is that most of them are useless to those who
> actually use JButton directly.  It's a really horribly polluted API.
>
> If inheritance is about modelling is-a relationships, and not about
> inheriting method definitions, then why are you complaining about only
> being able to inherit from one class?  You can inherit from as many
> interfaces as you like.
>
> Implementing inheritance via implicits in Scala requires more work,
> yes, because Scala supports inheritance in the Java sense already.
> It's hard to beat native language support in a library.
>
> The reason inheritance is detrimental when used to model is-a, is that
> everyone has a different idea of is-a, and a compiler cannot help you
> to restrict it to any safe subset.  A square is a rectangle.
>
> 2009/11/17 Naftoli Gugenheim :
>> If you would have said JComponent instead of JButton I would say "what that shows is how limiting single inheritance is."
>> But you're complaining that a descendant of the hierarchy inherited a lot of methods. So what's wrong with that?
>> And even if there is, I'm not sure what your point is. You said that inheritance is about get some VeryUsefulMethods from an ancestor. I guess you were justifying (sarcastically) describing it as code reuse.
>> I responded with JButton, meaning that inheritance is not _about_ having an ancestor with useful methods, but about modelling real-world is-a relationships which implies inheriting functionality. The fact that mathematically there's no distinction between is-a and has-a (apparently) notwithstanding, it has been demonstrated in thid thread (I think) that implementing inheritance via implicits requires plenty more work, not to mention that it's counterintuitive.
>> But my point is not to argue in favor of inheritance, but to ask for a reasoning how inheritance, when used to model true is-a, is detrimental per se.
>>
>>
>> -------------------------------------
>> Ricky Clarkson wrote:
>>
>> If you ever think Swing is a source of good examples of inheritance, try:
>>
>> classOf[javax.swing.JButton].getMethods.length
>>
>> 2009/11/16 Naftoli Gugenheim :
>>> Is that the relationship of JButton to JComponent?
>>>
>>> -------------------------------------
>>> Ricky Clarkson wrote:
>>>
>>> The way inheritance encourages code reuse is that you create a
>>> VeryUsefulClass with a bunch of usefulMethods in it, then subclass
>>> VeryUsefulClass to get at the usefulMethods.  It encourages monoliths.
>>>
>>> There are other ways to reuse code, that don't encourage monoliths.
>>>
>>> 2009/11/16 Matthew Willson :
>>>> I'm quite interested in this debate.
>>>>
>>>> The "inheritance is just another monomorphism, why make it special" argument appeals to my mathematical side.
>>>>
>>>> That said there are a lot of similar "x is just a kind of y, so why not generalise?" statements one can make in computer science, and not all of them form a good basis for language design. So I think a nuanced view is required of why inheritance concepts, and the "has a" vs "is a" distinction remain in the current crop of OO languages, which despite their flaws, are successfully used by many to structure software 'in the large'.
>>>>
>>>> One gut feeling of mine is this:
>>>>
>>>> So long as a language has concepts of object identity ("is a") whose semantics are at the level of the memory model, then the "is a" vs "has a" distinction will remain relevant.
>>>> If you want inheritance to be "just a function" then perhaps making equality "just a function" too is a pre-requisite.
>>>>
>>>> On 16 Nov 2009, at 07:45, Tony Morris wrote:
>>>>
>>>>> This guy is on the money
>>>>> http://apocalisp.wordpress.com/2009/08/27/hostility-toward-subtyping/
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Ricky Clarkson
>>> Java and Scala Programmer, AD Holdings
>>> +44 1565 770804
>>> Skype: ricky_clarkson
>>> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>>> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>>>
>>
>>
>>
>> --
>> Ricky Clarkson
>> Java and Scala Programmer, AD Holdings
>> +44 1565 770804
>> Skype: ricky_clarkson
>> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
>> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>>
>
>
>
> --
> Ricky Clarkson
> Java and Scala Programmer, AD Holdings
> +44 1565 770804
> Skype: ricky_clarkson
> Google Talk: ricky [dot] clarkson [at] gmail [dot] com
> Google Wave: ricky [dot] clarkson [at] googlewave [dot] com
>

andreas s.
Joined: 2009-01-15,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Rex Kerr-2 wrote:
>
> Inheritance to give subclasses the methods of superclasses *is* an example
> of code reuse, unless you have a really weird definition of "reuse".
>
> If you have a nonstandard definition of reuse, please specify it now
> before
> we waste any more time discussing different things.
>
> If you have a standard definition of reuse, then
> if class A, no more and no less, is required somewhere
> if class B, no more and no less, is required somewhere
> if class B has all methods and data of class A and then some
> if class B can stand in for class A in some pieces of code
> then class B requires duplication of the methods and data of class A by
> some mechanism
> inheritance provides a near-trivial mechanism to accomplish this
> duplication
>
> Do I need to write this out in well-formed formulas for this to constitute
> a
> proof that inheritance allows code reuse?
>
> Since I already supplied an explicit example of this taking place, I claim
> we have both a demonstration of a non-empty set of inheritance leading to
> code reuse, and a logical argument that states that inherited methods are
> in
> fact reused code in certain cases.
>
> Perhaps you mean re-use in that someone else can use my library? Same as
> above, except A is provided in the library, and B is not.
>
> --Rex
>
>

I think there is the important, yet subtle spot: use and re-use. In my
opinion tony is actually right when he says: inheritance does not re-use
code.
Example: B extends A
Now B can call code from A. It is able to use Code from that but re-use
seems difficult in that context. Because inheritance only gives you 2
Options: use it or not.
I guess re-use moves in a context of compose or bind in tony's context(which
does actually make sense to me!).
That's the obvious thing which was already stated before, but i think its
not bad to repeat it here.

I have been reading through the complete discussion and it has been very
interesting so far!
I think its a important discussion since obvious or simple things are
discussed which reveal to be not simple or obvious at all!

I think also that this was an important statement:

Ricky Clarkson wrote:

The way inheritance encourages code reuse is that you create a
VeryUsefulClass with a bunch of usefulMethods in it, then subclass
VeryUsefulClass to get at the usefulMethods. It encourages monoliths.

There are other ways to reuse code, that don't encourage monoliths.

To give Swing as an example was quite a bad example, because people tried to
build a system of components which is re-usable and as other stated
inheritance did NOT make a good job here! You need a much finer level of
control, rules which allow you to combine etc.
Since inheritance only allows you to use exactly the code of the super class
or not, it seems hard to build new functionality in the child class out of
the code from the parent class without making it a simply restricted version
of that.

So it makes ( to me ) absolutely sense that inheritance is bad for code
re-use (and i haven't yet read the The_Curry-Howard_isomorphism!).

regards andreas

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: Native Compiler for Scala
On Tue, Nov 17, 2009 at 12:53 PM, andreas s. <andreas_scheinert [at] web [dot] de> wrote:
Rex Kerr wrote:
>
> Inheritance to give subclasses the methods of superclasses *is* an example
>

I think there is the important, yet subtle spot: use and re-use. In my
opinion tony is actually right when he says: inheritance does not re-use
code.
Example: B extends A
Now B can call code from A. It is able to use Code from that but re-use
seems difficult in that context. Because inheritance only gives you 2
Options: use it or not.

Agreed.  This is both its strength and its weakness.  The strength of inheritance is that the minimum description length for doing it is very short--you say "I want that", and you get it (with some futzing with constructors which often makes it less fun).  The weakness of inheritance is that you cannot express very much with it.

Inheritance is in some sense the natural unit of reuse for objects.  This is because if you have an object O with hidden data and hidden methods and public methods, you _don't know_ what might use what.  If you take _all_ of O's functionality, you're on much safer ground than if you get to decide to keep some bits and lose other bits.

This is why inheritance can, if used properly, be both very easy to use and very powerful.  But it is undeniably limited.
 
I guess re-use moves in a context of compose or bind in tony's context(which
does actually make sense to me!).

This is another way to get re-use.
 
Ricky Clarkson<ricky.clarkson@...> wrote:

The way inheritance encourages code reuse is that you create a
VeryUsefulClass with a bunch of usefulMethods in it, then subclass
VeryUsefulClass to get at the usefulMethods.  It encourages monoliths.

There are other ways to reuse code, that don't encourage monoliths.


To give Swing as an example was quite a bad example, because people tried to
build a system of components which is re-usable and as other stated
inheritance did NOT make a good job here!

This is because Swing was badly designed, also.  (Given how hurried the initial creation if it was, and how new Java was, I don't think it reflects particularly negatively on its creators; but with more time and more perspective--or just with a little more insight or luck--one could do a lot better.)

And it is because the idea of single inheritance is too limited.

There are other ways to get modularity and code re-use.

Interfaces are another way, though they are too limited in Java; Scala's traits are IMO the sensible partition: you may add arbitrary functions given other functions (and/or classes).  Swing would look vastly better if it had been built with traits.

Generics are another way, though this is mostly to keep your types straight and for good performance; you can always pass in Any or AnyRef and use reflection to try to find out what methods are available.

Pattern matching is another way.

And various functional styles and constructs provide yet more ways to re-use code.

These all have advantages and disadvantages.

You need a much finer level of
control, rules which allow you to combine etc.
Since inheritance only allows you to use exactly the code of the super class
or not, it seems hard to build new  functionality in the child class out of
the code from the parent class without making it a simply restricted version
of that.

Subclasses are typically simply expanded versions of the parent, typically, not simply restricted ones.  If they're simply restricted, using inheritance may be the wrong thing to do.  (Unless by "restricted" you mean "given a specific implementation"--then, yes, subclasses may get specific implementations.)

So, if you want all the power of an Actor but need to do a few extra things, then extending Actor is a great way to reuse all the Actor code.

If you want something like a ListBuffer except that it can contain only zero or one elements and can't be iterated over, you probably do not want to extend ListBuffer.  (Just as well, since ListBuffer is final!)

If the claim is that _forcing all reuse to happen via inheritance is bad for code reuse_, then I agree.  Otherwise, I think inheritance is one of the three or four really clever ideas on how to easily reuse code from the past few decades.  It's been overused, as often happens when a new idea turns into a fad, but it is still very useful in the right context.  Avoiding it when it is the right solution is just as foolish as using it when it is the wrong solution.

  --Rex

Raoul Duke
Joined: 2009-01-05,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

On Tue, Nov 17, 2009 at 6:39 AM, Ricky Clarkson
wrote:
> The reason inheritance is detrimental when used to model is-a, is that
> everyone has a different idea of is-a, and a compiler cannot help you
> to restrict it to any safe subset.  A square is a rectangle.

if i have an interface, and i have things which implement that
interface, and i pass different instances of those implementations
into the same code at different times, that seems to me to also be
assuming a particular meaning about how the things relate, about what
it means to implement that interface, and that doesn't seem on the
face of it to me much different than is-a via inheritance. cowboy,
artist, draw()!

(i'm not wed to anything, i'm just trying to learn.)

sincerely.

Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Sure, interfaces are also an is-a relationship. They're a limited form of multiple inheritance.
I think this thread shows that people approach programming paradigms differently.
Some people view programming from a mathematical/functional angle. So inheritance is an odd specialization of a function.
Some people take the approach that it's all just a matter of tools, and whatever covers your immediate needs best should be used. If you need a simple derivation use inheritance; for a more complex one use other techniques.
My approach is that programs are a virtual representation of the world. OOP is about modelling the world, but I don't take the to mean physical objects but modelling real world concepts. A transaction, material, or button are concepts in the real world. A Role or a Request, although not tangible, are real concepts that exist. A program models those concepts, and the closer it adheres to the way the world is structured, the more comprehensible and coherent that program is, and the more likely to be designed well because you can reason about it better.
Thus, it makes the most sense to declare Animal as a class and Cat as subclass of Animal. Because a cat is indeed an animal, anything that applies to animals automatically applies to cats, unless cat overrides it. This is not a convenience for delegation. It's the way it is really.
Traits make sense, because besides a cat being a mammal, it also has a tail (maybe not the best use of a trait but I think it gets the point across). Mammals and fish (don't know if this is true but you get the point) may or may not have tails. So a cat is-a Mammal and it is-a TailedAnimal.
That is how it is in the real world, and therefore by sticking as close to this hierarchy as possible you have increased ability to reason about the program.
Of course there maybe many corner cases where it's not obvious whether A is a B. You have to use your judgement. At the end of the day the ancestor's contract should best model the real-world concept it represents, so that descendants don't break it.
So I postulate that the differences of opinion in this thread stem from these different programming-worldviews.
Eagerly awaiting any thoughts on my wild philosophising!

-------------------------------------
Raoul Duke wrote:

On Tue, Nov 17, 2009 at 6:39 AM, Ricky Clarkson
wrote:
> The reason inheritance is detrimental when used to model is-a, is that
> everyone has a different idea of is-a, and a compiler cannot help you
> to restrict it to any safe subset.  A square is a rectangle.

if i have an interface, and i have things which implement that
interface, and i pass different instances of those implementations
into the same code at different times, that seems to me to also be
assuming a particular meaning about how the things relate, about what
it means to implement that interface, and that doesn't seem on the
face of it to me much different than is-a via inheritance. cowboy,
artist, draw()!

(i'm not wed to anything, i'm just trying to learn.)

sincerely.

Roland Kuhn
Joined: 2008-12-26,
User offline. Last seen 3 years 14 weeks ago.
Re: Questions about axiomatic programming (was: Native Compiler

What you describe below coincides quite nicely with the typical
learning showcase of OOP. This is a tool like many others, and I
completely agree with the "choose the best tool for the job" mantra,
especially when programming for money. So, as a side remark, when you
don't need to model the world, then don't do it.

On the other hand, there have been advances in the computer sciences
towards an axiomatic view on programming. Mathematics, as you probably
know, has nothing to do with the real world in the sense that it does
not even need a universe to exist (that is the reason I studied
physics instead). In that sense, mathematics is abstraction in its
pure form. The ability to solve problems without taking references to
our daily experiences allows such wondrous techniques as transferring
a problem from one domain (say geometry) to another (say algebra) to
prove it. So, one might be inclined to take this to the extreme and
transform computer programming into theorem proving. Not wanting to
put anything into other people's mouth, I presume that this point of
view might help understanding some of the previous posts in this thread.

I have one question, though, which has been on my mind for quite some
time. While I accept that a program can be transformed and analyzed
under a set of axioms, what is the point? To my knowledge, the largest
program ever proven consists of around 8000 lines of code, and that
was a major effort. This seems to indicate that this technique is not
ready for the real world, where every non-trivial project exceeds this
size by a large factor.

One other question comes to mind. If you can prove that a program
adheres to its specification for all possible inputs, does that not
imply that the set of such programs must be restricted somehow? If
not, I would have difficulties reconciling this with the answer to the
halting problem.

If someone could enlighten me, I'd be grateful even for some links.

Regards,

Roland

On Nov 18, 2009, at 06:30 , Naftoli Gugenheim wrote:

> Sure, interfaces are also an is-a relationship. They're a limited
> form of multiple inheritance.
> I think this thread shows that people approach programming paradigms
> differently.
> Some people view programming from a mathematical/functional angle.
> So inheritance is an odd specialization of a function.
> Some people take the approach that it's all just a matter of tools,
> and whatever covers your immediate needs best should be used. If you
> need a simple derivation use inheritance; for a more complex one use
> other techniques.
> My approach is that programs are a virtual representation of the
> world. OOP is about modelling the world, but I don't take the to
> mean physical objects but modelling real world concepts. A
> transaction, material, or button are concepts in the real world. A
> Role or a Request, although not tangible, are real concepts that
> exist. A program models those concepts, and the closer it adheres to
> the way the world is structured, the more comprehensible and
> coherent that program is, and the more likely to be designed well
> because you can reason about it better.
> Thus, it makes the most sense to declare Animal as a class and Cat
> as subclass of Animal. Because a cat is indeed an animal, anything
> that applies to animals automatically applies to cats, unless cat
> overrides it. This is not a convenience for delegation. It's the way
> it is really.
> Traits make sense, because besides a cat being a mammal, it also has
> a tail (maybe not the best use of a trait but I think it gets the
> point across). Mammals and fish (don't know if this is true but you
> get the point) may or may not have tails. So a cat is-a Mammal and
> it is-a TailedAnimal.
> That is how it is in the real world, and therefore by sticking as
> close to this hierarchy as possible you have increased ability to
> reason about the program.
> Of course there maybe many corner cases where it's not obvious
> whether A is a B. You have to use your judgement. At the end of the
> day the ancestor's contract should best model the real-world concept
> it represents, so that descendants don't break it.
> So I postulate that the differences of opinion in this thread stem
> from these different programming-worldviews.
> Eagerly awaiting any thoughts on my wild philosophising!
>
>
> -------------------------------------
> Raoul Duke wrote:
>
> On Tue, Nov 17, 2009 at 6:39 AM, Ricky Clarkson
> wrote:
>> The reason inheritance is detrimental when used to model is-a, is
>> that
>> everyone has a different idea of is-a, and a compiler cannot help you
>> to restrict it to any safe subset. A square is a rectangle.
>
> if i have an interface, and i have things which implement that
> interface, and i pass different instances of those implementations
> into the same code at different times, that seems to me to also be
> assuming a particular meaning about how the things relate, about what
> it means to implement that interface, and that doesn't seem on the
> face of it to me much different than is-a via inheritance. cowboy,
> artist, draw()!
>
> (i'm not wed to anything, i'm just trying to learn.)
>
> sincerely.

--
I'm a physicist: I have a basic working knowledge of the universe and
everything it contains!
- Sheldon Cooper (The Big Bang Theory)

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Questions about axiomatic programming (was: Native Compile
Roland, you can't dissociate programs from math, because programs are a mathematical construct, whether you realize it or not.
Now, the question is not so much about theorem proving -- and, by the way, any program you compile with a statically typed language is proving a lot of things already, no matter how many lines it has -- as about *soundness*. By soundness I mean the ability of writing code with the confidence it will do what you expect it to, as long as you are following correctly a set of rules. 
For example, we expect == to me commutative, associative and transitive. A language which is sound enable us to define such an operation over a set of values with the confidence that these rules will work. It just so happens that in the presence of inheritance no such guarantee can be made. You may write your code correctly, but external code, outside your control, might make that untrue.
That means the fundaments of the language are unsound.
So, yes, you can write software without caring about mathematics. But if the language designer doesn't care about mathematics, you'll be given a flawed tool to work with.
On Wed, Nov 18, 2009 at 6:49 AM, Roland Kuhn <rk [at] rkuhn [dot] info> wrote:
What you describe below coincides quite nicely with the typical learning showcase of OOP. This is a tool like many others, and I completely agree with the "choose the best tool for the job" mantra, especially when programming for money. So, as a side remark, when you don't need to model the world, then don't do it.

On the other hand, there have been advances in the computer sciences towards an axiomatic view on programming. Mathematics, as you probably know, has nothing to do with the real world in the sense that it does not even need a universe to exist (that is the reason I studied physics instead). In that sense, mathematics is abstraction in its pure form. The ability to solve problems without taking references to our daily experiences allows such wondrous techniques as transferring a problem from one domain (say geometry) to another (say algebra) to prove it. So, one might be inclined to take this to the extreme and transform computer programming into theorem proving. Not wanting to put anything into other people's mouth, I presume that this point of view might help understanding some of the previous posts in this thread.

I have one question, though, which has been on my mind for quite some time. While I accept that a program can be transformed and analyzed under a set of axioms, what is the point? To my knowledge, the largest program ever proven consists of around 8000 lines of code, and that was a major effort. This seems to indicate that this technique is not ready for the real world, where every non-trivial project exceeds this size by a large factor.

One other question comes to mind. If you can prove that a program adheres to its specification for all possible inputs, does that not imply that the set of such programs must be restricted somehow? If not, I would have difficulties reconciling this with the answer to the halting problem.

If someone could enlighten me, I'd be grateful even for some links.

Regards,

Roland

On Nov 18, 2009, at 06:30 , Naftoli Gugenheim wrote:

Sure, interfaces are also an is-a relationship. They're a limited form of multiple inheritance.
I think this thread shows that people approach programming paradigms differently.
Some people view programming from a mathematical/functional angle. So inheritance is an odd specialization of a function.
Some people take the approach that it's all just a matter of tools, and whatever covers your immediate needs best should be used. If you need a simple derivation use inheritance; for a more complex one use other techniques.
My approach is that programs are a virtual representation of the world. OOP is about modelling the world, but I don't take the to mean physical objects but modelling real world concepts. A transaction, material, or button are concepts in the real world. A Role or a Request, although not tangible, are real concepts that exist. A program models those concepts, and the closer it adheres to the way the world is structured, the more comprehensible and coherent that program is, and the more likely to be designed well because you can reason about it better.
Thus, it makes the most sense to declare Animal as a class and Cat as subclass of Animal. Because a cat is indeed an animal, anything that applies to animals automatically applies to cats, unless cat overrides it. This is not a convenience for delegation. It's the way it is really.
Traits make sense, because besides a cat being a mammal, it also has a tail (maybe not the best use of a trait but I think it gets the point across). Mammals and fish (don't know if this is true but you get the point) may or may not have tails. So a cat is-a Mammal and it is-a TailedAnimal.
That is how it is in the real world, and therefore by sticking as close to this hierarchy as possible you have increased ability to reason about the program.
Of course there maybe many corner cases where it's not obvious whether A is a B. You have to use your judgement. At the end of the day the ancestor's contract should best model the real-world concept it represents, so that descendants don't break it.
So I postulate that the differences of opinion in this thread stem from these different programming-worldviews.
Eagerly awaiting any thoughts on my wild philosophising!


-------------------------------------
Raoul Duke<raould [at] gmail [dot] com> wrote:

On Tue, Nov 17, 2009 at 6:39 AM, Ricky Clarkson
<ricky [dot] clarkson [at] gmail [dot] com> wrote:
The reason inheritance is detrimental when used to model is-a, is that
everyone has a different idea of is-a, and a compiler cannot help you
to restrict it to any safe subset.  A square is a rectangle.

if i have an interface, and i have things which implement that
interface, and i pass different instances of those implementations
into the same code at different times, that seems to me to also be
assuming a particular meaning about how the things relate, about what
it means to implement that interface, and that doesn't seem on the
face of it to me much different than is-a via inheritance. cowboy,
artist, draw()!

(i'm not wed to anything, i'm just trying to learn.)

sincerely.

--
I'm a physicist: I have a basic working knowledge of the universe and everything it contains!
   - Sheldon Cooper (The Big Bang Theory)




--
Daniel C. Sobral

Veni, vidi, veterni.
Raoul Duke
Joined: 2009-01-05,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

> I think this thread shows that people approach programming paradigms differently.

some folks are criticizing classes (vs. object), too:

http://lists.ops4j.org/pipermail/qi4j-dev/2009-November/006186.html

sincerely.

Roland Kuhn
Joined: 2008-12-26,
User offline. Last seen 3 years 14 weeks ago.
Re: Questions about axiomatic programming (was: Native Compile
Statically typed languages like Scala, especially with such a powerful type system, enable the expression of several behavior aspects using types and so make them accessible to compile-time verification. But this has limits: the type does not encode semantics of the operation. How would you construct a type such that the signature of "sort" would accept any input but create only sorted output? If you cannot express this, then the compiler cannot verify it, thus leaving us at square one ("intuitive results", as you later say).
My current understanding of the situation is that there is no language implementation which disallows spec-violating code, where by "spec" I mean something useful to the normal human. Please correct me, if I'm wrong. The problem indeed goes beyond mathematics: in the real world, a customer formulates requirements in plain english and pays you for their transformation into machine code. This process needs some ingredients which are  not readily accessible with mathematics: common sense and creativity. The product in the end will have a much more specific behavior than originally requested, and the mathematical specification will be much larger than the original one.
Concerning your "==" example: given that in Scala "==" is nothing but a normal method call on the object to the left, I am well prepared to assume nothing like commutativity in the general case. I don't see why that should be a problem.
Regards,
Roland
On Nov 18, 2009, at 12:08 , Daniel Sobral wrote:
Roland, you can't dissociate programs from math, because programs are a mathematical construct, whether you realize it or not.
Now, the question is not so much about theorem proving -- and, by the way, any program you compile with a statically typed language is proving a lot of things already, no matter how many lines it has -- as about *soundness*. By soundness I mean the ability of writing code with the confidence it will do what you expect it to, as long as you are following correctly a set of rules. 
For example, we expect == to me commutative, associative and transitive. A language which is sound enable us to define such an operation over a set of values with the confidence that these rules will work. It just so happens that in the presence of inheritance no such guarantee can be made. You may write your code correctly, but external code, outside your control, might make that untrue.
That means the fundaments of the language are unsound.
So, yes, you can write software without caring about mathematics. But if the language designer doesn't care about mathematics, you'll be given a flawed tool to work with.
On Wed, Nov 18, 2009 at 6:49 AM, Roland Kuhn <rk [at] rkuhn [dot] info> wrote:
What you describe below coincides quite nicely with the typical learning showcase of OOP. This is a tool like many others, and I completely agree with the "choose the best tool for the job" mantra, especially when programming for money. So, as a side remark, when you don't need to model the world, then don't do it.

On the other hand, there have been advances in the computer sciences towards an axiomatic view on programming. Mathematics, as you probably know, has nothing to do with the real world in the sense that it does not even need a universe to exist (that is the reason I studied physics instead). In that sense, mathematics is abstraction in its pure form. The ability to solve problems without taking references to our daily experiences allows such wondrous techniques as transferring a problem from one domain (say geometry) to another (say algebra) to prove it. So, one might be inclined to take this to the extreme and transform computer programming into theorem proving. Not wanting to put anything into other people's mouth, I presume that this point of view might help understanding some of the previous posts in this thread.

I have one question, though, which has been on my mind for quite some time. While I accept that a program can be transformed and analyzed under a set of axioms, what is the point? To my knowledge, the largest program ever proven consists of around 8000 lines of code, and that was a major effort. This seems to indicate that this technique is not ready for the real world, where every non-trivial project exceeds this size by a large factor.

One other question comes to mind. If you can prove that a program adheres to its specification for all possible inputs, does that not imply that the set of such programs must be restricted somehow? If not, I would have difficulties reconciling this with the answer to the halting problem.

If someone could enlighten me, I'd be grateful even for some links.

Regards,

Roland

On Nov 18, 2009, at 06:30 , Naftoli Gugenheim wrote:

Sure, interfaces are also an is-a relationship. They're a limited form of multiple inheritance.
I think this thread shows that people approach programming paradigms differently.
Some people view programming from a mathematical/functional angle. So inheritance is an odd specialization of a function.
Some people take the approach that it's all just a matter of tools, and whatever covers your immediate needs best should be used. If you need a simple derivation use inheritance; for a more complex one use other techniques.
My approach is that programs are a virtual representation of the world. OOP is about modelling the world, but I don't take the to mean physical objects but modelling real world concepts. A transaction, material, or button are concepts in the real world. A Role or a Request, although not tangible, are real concepts that exist. A program models those concepts, and the closer it adheres to the way the world is structured, the more comprehensible and coherent that program is, and the more likely to be designed well because you can reason about it better.
Thus, it makes the most sense to declare Animal as a class and Cat as subclass of Animal. Because a cat is indeed an animal, anything that applies to animals automatically applies to cats, unless cat overrides it. This is not a convenience for delegation. It's the way it is really.
Traits make sense, because besides a cat being a mammal, it also has a tail (maybe not the best use of a trait but I think it gets the point across). Mammals and fish (don't know if this is true but you get the point) may or may not have tails. So a cat is-a Mammal and it is-a TailedAnimal.
That is how it is in the real world, and therefore by sticking as close to this hierarchy as possible you have increased ability to reason about the program.
Of course there maybe many corner cases where it's not obvious whether A is a B. You have to use your judgement. At the end of the day the ancestor's contract should best model the real-world concept it represents, so that descendants don't break it.
So I postulate that the differences of opinion in this thread stem from these different programming-worldviews.
Eagerly awaiting any thoughts on my wild philosophising!


-------------------------------------
Raoul Duke<raould [at] gmail [dot] com> wrote:

On Tue, Nov 17, 2009 at 6:39 AM, Ricky Clarkson
<ricky [dot] clarkson [at] gmail [dot] com> wrote:
The reason inheritance is detrimental when used to model is-a, is that
everyone has a different idea of is-a, and a compiler cannot help you
to restrict it to any safe subset.  A square is a rectangle.

if i have an interface, and i have things which implement that
interface, and i pass different instances of those implementations
into the same code at different times, that seems to me to also be
assuming a particular meaning about how the things relate, about what
it means to implement that interface, and that doesn't seem on the
face of it to me much different than is-a via inheritance. cowboy,
artist, draw()!

(i'm not wed to anything, i'm just trying to learn.)

sincerely.

--
I'm a physicist: I have a basic working knowledge of the universe and everything it contains!
   - Sheldon Cooper (The Big Bang Theory)




--
Daniel C. Sobral

Veni, vidi, veterni.

--Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.
  -- Dijkstra

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