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

Re: Native Compiler for Scala

63 replies
Naftoli Gugenheim
Joined: 2008-12-17,
User offline. Last seen 42 years 45 weeks ago.

Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.

-------------------------------------
Tony Morris wrote:

No certainly not. I mean inheritance, just like you do. So, where's the
code reuse again?

Quenio dos Santos wrote:
> Traits are just a clever way of doing multiple inheritance, which
> allows mixing without some of the issues you would find in C++. It is
> not much different from multiple inheritance in Eiffel, which also
> resolves some of the C++ issues.
>
> I think when you say inheritance, you really mean traditional single
> inheritance like in Java.
>
> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris > wrote:
>
> Scala without traits would be unthinkable! Inheritance is an expensive
> implicit.
>
> Quenio dos Santos wrote:
> > I may be completely be missing your point here, but I cannot imagine
> > Scala without traits. Maybe, without single inheritance, but not
> traits.
> >
> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>
> > >> wrote:
> >
> > I didn't mean to imply that absence of inheritance was a
> good idea for
> > Go. I listed my opinion on Go a few days ago in private to other
> > inquiring minds.
> >
> > I intended only that inheritance is certainly not essential
> for a
> > "modern" programming language (which I assumed to be
> synonymous with
> > "practical") and is indeed, rather antithetical. One may or
> may not
> > agree, but it's quite easy to solidly argue the fact. Scala
> users
> > ultimately suffer as a result (see the mailing lists for
> many examples
> > with new ones regularly arriving). Thankfully Oleg has done
> all the
> > arguing for me so I best not be too loud lest I be coaxed
> into another
> > debate!
> >
> > Quenio dos Santos wrote:
> > > Go has neither inheritance nor sub-typing. It has interfaces,
> > which do
> > > provide sub-typing on some level, but are limited in my
> opinion. One
> > > interface cannot sub-type another interface, for example.
> > >
> > > As far as inheritance being a flaw, I don't think Martin
> Ordersky
> > > would agree with you. Otherwise, he wouldn't have put the
> feature in
> > > Scala :)
> > >
> > > Scala not only adopted inheritance but enhanced it with
> traits.
> > >
> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
> >
> >
> > >
> >>> wrote:
> > >
> > > Haskell does away with inheritance just fine. Indeed, it
> > reaps the
> > > benefits of having abandoned such a blatant type
> system flaw.
> > > http://okmij.org/ftp/Computation/Subtyping/
> > >
> > > Quenio dos Santos wrote:
> > > > Hello All,
> > > >
> > > > I don't know if you have heard the buzz about the new Go
> > programming
> > > > language from Google, which is been touted as the
> new systems
> > > language
> > > > to replace C/C++.
> > > >
> > > > I have been exploring it, and although I found it
> interesting
> > > > initially, now I am not so impressed. Just for starters,
> > it doesn't
> > > > support sub-typing. I can't really see how can you live
> > without
> > > > sub-typing and inheritance in a modern programming
> language.
> > > >
> > > > I honestly believe that Scala would be a great systems
> > language if a
> > > > native compiler was available for Scala. Has that ever
> > crossed the
> > > > mind of the Scala development team, or anybody else?
> > > >
> > > > - Quenio
> > >
> > > --
> > > Tony Morris
> > > http://tmorris.net/
> > >
> > >
> > >
> >
> > --
> > Tony Morris
> > http://tmorris.net/
> >
> >
> >
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

I'm not talking in riddles at all. I have already stated that
inheritance is merely a function. We often think of it differently (to
our detriment?) -- an arrow pointing upward instead of right-ward, but
it essentially means "implies", just like any other function. It is also
implicitly converted, unlike a typical function.

I fail to see how any of this constitutes code reuse. I am awaiting an
example to the contrary. I'm well aware that few programmers know what
code reuse means, and I'm most aware of marketing slogans that tout
inheritance as correlated to code reuse, but I remain optimistic.

Show me an example.

Naftoli Gugenheim wrote:
> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>
>
> -------------------------------------
> Tony Morris wrote:
>
> No certainly not. I mean inheritance, just like you do. So, where's the
> code reuse again?
>
> Quenio dos Santos wrote:
>
>> Traits are just a clever way of doing multiple inheritance, which
>> allows mixing without some of the issues you would find in C++. It is
>> not much different from multiple inheritance in Eiffel, which also
>> resolves some of the C++ issues.
>>
>> I think when you say inheritance, you really mean traditional single
>> inheritance like in Java.
>>
>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris > > wrote:
>>
>> Scala without traits would be unthinkable! Inheritance is an expensive
>> implicit.
>>
>> Quenio dos Santos wrote:
>> > I may be completely be missing your point here, but I cannot imagine
>> > Scala without traits. Maybe, without single inheritance, but not
>> traits.
>> >
>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>
>> > >> wrote:
>> >
>> > I didn't mean to imply that absence of inheritance was a
>> good idea for
>> > Go. I listed my opinion on Go a few days ago in private to other
>> > inquiring minds.
>> >
>> > I intended only that inheritance is certainly not essential
>> for a
>> > "modern" programming language (which I assumed to be
>> synonymous with
>> > "practical") and is indeed, rather antithetical. One may or
>> may not
>> > agree, but it's quite easy to solidly argue the fact. Scala
>> users
>> > ultimately suffer as a result (see the mailing lists for
>> many examples
>> > with new ones regularly arriving). Thankfully Oleg has done
>> all the
>> > arguing for me so I best not be too loud lest I be coaxed
>> into another
>> > debate!
>> >
>> > Quenio dos Santos wrote:
>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>> > which do
>> > > provide sub-typing on some level, but are limited in my
>> opinion. One
>> > > interface cannot sub-type another interface, for example.
>> > >
>> > > As far as inheritance being a flaw, I don't think Martin
>> Ordersky
>> > > would agree with you. Otherwise, he wouldn't have put the
>> feature in
>> > > Scala :)
>> > >
>> > > Scala not only adopted inheritance but enhanced it with
>> traits.
>> > >
>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>> >
>> >
>> > >
>> >>> wrote:
>> > >
>> > > Haskell does away with inheritance just fine. Indeed, it
>> > reaps the
>> > > benefits of having abandoned such a blatant type
>> system flaw.
>> > > http://okmij.org/ftp/Computation/Subtyping/
>> > >
>> > > Quenio dos Santos wrote:
>> > > > Hello All,
>> > > >
>> > > > I don't know if you have heard the buzz about the new Go
>> > programming
>> > > > language from Google, which is been touted as the
>> new systems
>> > > language
>> > > > to replace C/C++.
>> > > >
>> > > > I have been exploring it, and although I found it
>> interesting
>> > > > initially, now I am not so impressed. Just for starters,
>> > it doesn't
>> > > > support sub-typing. I can't really see how can you live
>> > without
>> > > > sub-typing and inheritance in a modern programming
>> language.
>> > > >
>> > > > I honestly believe that Scala would be a great systems
>> > language if a
>> > > > native compiler was available for Scala. Has that ever
>> > crossed the
>> > > > mind of the Scala development team, or anybody else?
>> > > >
>> > > > - Quenio
>> > >
>> > > --
>> > > Tony Morris
>> > > http://tmorris.net/
>> > >
>> > >
>> > >
>> >
>> > --
>> > Tony Morris
>> > http://tmorris.net/
>> >
>> >
>> >
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>

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

If I am interpreting your terse hints correctly, your objection to inheritance (besides whichever dangers you hint to but haven't specified) is that implicits, or "can be seen as," are a generalization of inheritance. "Is-a" is a redundant kind of relationship since it can be expressed as an instance of "can be seen as." Occam's razor or something...
Before I go further I would like you to comment on whether I am reading you correctly or not.
I know, it's evil to utter a redundant word if the thought can be expressed without it, even if consequently no one (except the anti-anti-intellectual movement) will understand it. But for now humor us and expand a bit on the kernel of the thought please.

-------------------------------------
Tony Morris wrote:

It is a common myth that inheritance is related to code reuse, except
perhaps that it prevents reuse to some extent under certain conditions.

Inheritance is simply an implicit function (plus problems). The
difference being cognitive; the arrow is pointing upward instead of
rightward.

Quenio dos Santos wrote:
> This article you referenced is very interesting. It basically shows
> that you can break the contract of a super-class by changing the
> behavior in the sub-class.
>
> I don't think this common, easily-resolvable issue should be a
> suggestion that inheritance is evil. Even with interfaces, you can
> always provide an implementation that breaks the contract of the
> interface.
>
> Also, in the article, the author suggests that test suite was
> carefully implemented by the authors of both the Bag and the Set.
> However, one important characteristic was not checked by the test
> suite: add(x);add(x);count(x) ==2. Exactly the one that failed in the
> foo() method of the example.
>
> It is interesting to me that one of the few languages that actually
> has built-in support for checking contracts (Eiffel) was designed by
> Bertrand Meyer, which stated clearly in his book "Object-Oriented
> Software Construction
> "
> that it is just fine to use inheritance as a way to re-use code even
> if the super-class and the sub-class have no sub-type relationship in
> the real world.
>
> Eiffel is a serious language implementation that has been around for
> years and is well-respected in the academic community. It has multiple
> inheritance, which works very similarly to traits, and it doesn't
> suffer from the diamond problem.
>
> On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris > wrote:
>
> Haskell does away with inheritance just fine. Indeed, it reaps the
> benefits of having abandoned such a blatant type system flaw.
> http://okmij.org/ftp/Computation/Subtyping/
>
> Quenio dos Santos wrote:
> > Hello All,
> >
> > I don't know if you have heard the buzz about the new Go programming
> > language from Google, which is been touted as the new systems
> language
> > to replace C/C++.
> >
> > I have been exploring it, and although I found it interesting
> > initially, now I am not so impressed. Just for starters, it doesn't
> > support sub-typing. I can't really see how can you live without
> > sub-typing and inheritance in a modern programming language.
> >
> > I honestly believe that Scala would be a great systems language if a
> > native compiler was available for Scala. Has that ever crossed the
> > mind of the Scala development team, or anybody else?
> >
> > - Quenio
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

That's the thing, there is no deep thought. Inheritance is simply an
implicit conversion from an element of one set S to another T and we
denote it with an upward arrow S => T. Nothing more, nada.

This is has absolutely nothing to do with code reuse, as far as I can
see. Apparently, there are claims to the contrary. Let's see them.
"Bertrand Meyer said so" or "Sun marketing team said so" is not good
enough. I want an example, even one. If not, I resort to the default
position -- it's bullshit. Very popular bullshit I might add.

Naftoli Gugenheim wrote:
> If I am interpreting your terse hints correctly, your objection to inheritance (besides whichever dangers you hint to but haven't specified) is that implicits, or "can be seen as," are a generalization of inheritance. "Is-a" is a redundant kind of relationship since it can be expressed as an instance of "can be seen as." Occam's razor or something...
> Before I go further I would like you to comment on whether I am reading you correctly or not.
> I know, it's evil to utter a redundant word if the thought can be expressed without it, even if consequently no one (except the anti-anti-intellectual movement) will understand it. But for now humor us and expand a bit on the kernel of the thought please.
>
> -------------------------------------
> Tony Morris wrote:
>
> It is a common myth that inheritance is related to code reuse, except
> perhaps that it prevents reuse to some extent under certain conditions.
>
> Inheritance is simply an implicit function (plus problems). The
> difference being cognitive; the arrow is pointing upward instead of
> rightward.
>
> Quenio dos Santos wrote:
>
>> This article you referenced is very interesting. It basically shows
>> that you can break the contract of a super-class by changing the
>> behavior in the sub-class.
>>
>> I don't think this common, easily-resolvable issue should be a
>> suggestion that inheritance is evil. Even with interfaces, you can
>> always provide an implementation that breaks the contract of the
>> interface.
>>
>> Also, in the article, the author suggests that test suite was
>> carefully implemented by the authors of both the Bag and the Set.
>> However, one important characteristic was not checked by the test
>> suite: add(x);add(x);count(x) ==2. Exactly the one that failed in the
>> foo() method of the example.
>>
>> It is interesting to me that one of the few languages that actually
>> has built-in support for checking contracts (Eiffel) was designed by
>> Bertrand Meyer, which stated clearly in his book "Object-Oriented
>> Software Construction
>> "
>> that it is just fine to use inheritance as a way to re-use code even
>> if the super-class and the sub-class have no sub-type relationship in
>> the real world.
>>
>> Eiffel is a serious language implementation that has been around for
>> years and is well-respected in the academic community. It has multiple
>> inheritance, which works very similarly to traits, and it doesn't
>> suffer from the diamond problem.
>>
>> On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris > > wrote:
>>
>> Haskell does away with inheritance just fine. Indeed, it reaps the
>> benefits of having abandoned such a blatant type system flaw.
>> http://okmij.org/ftp/Computation/Subtyping/
>>
>> Quenio dos Santos wrote:
>> > Hello All,
>> >
>> > I don't know if you have heard the buzz about the new Go programming
>> > language from Google, which is been touted as the new systems
>> language
>> > to replace C/C++.
>> >
>> > I have been exploring it, and although I found it interesting
>> > initially, now I am not so impressed. Just for starters, it doesn't
>> > support sub-typing. I can't really see how can you live without
>> > sub-typing and inheritance in a modern programming language.
>> >
>> > I honestly believe that Scala would be a great systems language if a
>> > native compiler was available for Scala. Has that ever crossed the
>> > mind of the Scala development team, or anybody else?
>> >
>> > - Quenio
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>

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

First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.

-------------------------------------
Tony Morris wrote:

I'm not talking in riddles at all. I have already stated that
inheritance is merely a function. We often think of it differently (to
our detriment?) -- an arrow pointing upward instead of right-ward, but
it essentially means "implies", just like any other function. It is also
implicitly converted, unlike a typical function.

I fail to see how any of this constitutes code reuse. I am awaiting an
example to the contrary. I'm well aware that few programmers know what
code reuse means, and I'm most aware of marketing slogans that tout
inheritance as correlated to code reuse, but I remain optimistic.

Show me an example.

Naftoli Gugenheim wrote:
> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>
>
> -------------------------------------
> Tony Morris wrote:
>
> No certainly not. I mean inheritance, just like you do. So, where's the
> code reuse again?
>
> Quenio dos Santos wrote:
>
>> Traits are just a clever way of doing multiple inheritance, which
>> allows mixing without some of the issues you would find in C++. It is
>> not much different from multiple inheritance in Eiffel, which also
>> resolves some of the C++ issues.
>>
>> I think when you say inheritance, you really mean traditional single
>> inheritance like in Java.
>>
>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris > > wrote:
>>
>> Scala without traits would be unthinkable! Inheritance is an expensive
>> implicit.
>>
>> Quenio dos Santos wrote:
>> > I may be completely be missing your point here, but I cannot imagine
>> > Scala without traits. Maybe, without single inheritance, but not
>> traits.
>> >
>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>
>> > >> wrote:
>> >
>> > I didn't mean to imply that absence of inheritance was a
>> good idea for
>> > Go. I listed my opinion on Go a few days ago in private to other
>> > inquiring minds.
>> >
>> > I intended only that inheritance is certainly not essential
>> for a
>> > "modern" programming language (which I assumed to be
>> synonymous with
>> > "practical") and is indeed, rather antithetical. One may or
>> may not
>> > agree, but it's quite easy to solidly argue the fact. Scala
>> users
>> > ultimately suffer as a result (see the mailing lists for
>> many examples
>> > with new ones regularly arriving). Thankfully Oleg has done
>> all the
>> > arguing for me so I best not be too loud lest I be coaxed
>> into another
>> > debate!
>> >
>> > Quenio dos Santos wrote:
>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>> > which do
>> > > provide sub-typing on some level, but are limited in my
>> opinion. One
>> > > interface cannot sub-type another interface, for example.
>> > >
>> > > As far as inheritance being a flaw, I don't think Martin
>> Ordersky
>> > > would agree with you. Otherwise, he wouldn't have put the
>> feature in
>> > > Scala :)
>> > >
>> > > Scala not only adopted inheritance but enhanced it with
>> traits.
>> > >
>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>> >
>> >
>> > >
>> >>> wrote:
>> > >
>> > > Haskell does away with inheritance just fine. Indeed, it
>> > reaps the
>> > > benefits of having abandoned such a blatant type
>> system flaw.
>> > > http://okmij.org/ftp/Computation/Subtyping/
>> > >
>> > > Quenio dos Santos wrote:
>> > > > Hello All,
>> > > >
>> > > > I don't know if you have heard the buzz about the new Go
>> > programming
>> > > > language from Google, which is been touted as the
>> new systems
>> > > language
>> > > > to replace C/C++.
>> > > >
>> > > > I have been exploring it, and although I found it
>> interesting
>> > > > initially, now I am not so impressed. Just for starters,
>> > it doesn't
>> > > > support sub-typing. I can't really see how can you live
>> > without
>> > > > sub-typing and inheritance in a modern programming
>> language.
>> > > >
>> > > > I honestly believe that Scala would be a great systems
>> > language if a
>> > > > native compiler was available for Scala. Has that ever
>> > crossed the
>> > > > mind of the Scala development team, or anybody else?
>> > > >
>> > > > - Quenio
>> > >
>> > > --
>> > > Tony Morris
>> > > http://tmorris.net/
>> > >
>> > >
>> > >
>> >
>> > --
>> > Tony Morris
>> > http://tmorris.net/
>> >
>> >
>> >
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

I've no idea what you mean by "putting code in functions and invoking
them is a form of code reuse."

I define code reuse along the same lines as that mentioned in Why
Functional Programming Matters (John Hughes).

What do I mean by implies? You have surely seen this Scala syntax =>.
That is logical implication under the Curry-Howard Isomorphism. When you
write Int => String, you are saying "Int implies String."

Here's a fun example List[A] => A. This is a lie! It fails to terminate
under certain domain values (empty list). But we write such a function
anyway (head). That's what I mean by implies and it's exactly what *you*
mean when you use inheritance. You talk of "views"; these are simply
functions, they are not special, just functions. They might be
*implicit* functions (or views), but that's precisely what inheritance
is. When you say "Int => String", you are saying "Int inherits from
String, with the exception that it is explicit." When you write an
implicit function, you are using inheritance encoded differently (and
often times, without certain costs that *inhibit* code reuse).

Here's another example, Option[A] => List[A] (there is a reason I am
avoiding Iterable). This is a true statement. Indeed, Option is simply a
List with a maximum length of 1. It is also (for a typical
implementation), an injection. This is an important part. Indeed, most
programmers, knowingly or not, use inheritance when the implication is
injective. It's not surjective though.

That's all inheritance is. I realise that this may destroy a lot of
fanciful dreams and may even cause offence, but I am just the messenger.
This also has nothing to do with code reuse. It never did. *pop*

Naftoli Gugenheim wrote:
> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>
>
>
> -------------------------------------
> Tony Morris wrote:
>
> I'm not talking in riddles at all. I have already stated that
> inheritance is merely a function. We often think of it differently (to
> our detriment?) -- an arrow pointing upward instead of right-ward, but
> it essentially means "implies", just like any other function. It is also
> implicitly converted, unlike a typical function.
>
> I fail to see how any of this constitutes code reuse. I am awaiting an
> example to the contrary. I'm well aware that few programmers know what
> code reuse means, and I'm most aware of marketing slogans that tout
> inheritance as correlated to code reuse, but I remain optimistic.
>
> Show me an example.
>
> Naftoli Gugenheim wrote:
>
>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> No certainly not. I mean inheritance, just like you do. So, where's the
>> code reuse again?
>>
>> Quenio dos Santos wrote:
>>
>>
>>> Traits are just a clever way of doing multiple inheritance, which
>>> allows mixing without some of the issues you would find in C++. It is
>>> not much different from multiple inheritance in Eiffel, which also
>>> resolves some of the C++ issues.
>>>
>>> I think when you say inheritance, you really mean traditional single
>>> inheritance like in Java.
>>>
>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >> > wrote:
>>>
>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>> implicit.
>>>
>>> Quenio dos Santos wrote:
>>> > I may be completely be missing your point here, but I cannot imagine
>>> > Scala without traits. Maybe, without single inheritance, but not
>>> traits.
>>> >
>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>
>>> > >> wrote:
>>> >
>>> > I didn't mean to imply that absence of inheritance was a
>>> good idea for
>>> > Go. I listed my opinion on Go a few days ago in private to other
>>> > inquiring minds.
>>> >
>>> > I intended only that inheritance is certainly not essential
>>> for a
>>> > "modern" programming language (which I assumed to be
>>> synonymous with
>>> > "practical") and is indeed, rather antithetical. One may or
>>> may not
>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>> users
>>> > ultimately suffer as a result (see the mailing lists for
>>> many examples
>>> > with new ones regularly arriving). Thankfully Oleg has done
>>> all the
>>> > arguing for me so I best not be too loud lest I be coaxed
>>> into another
>>> > debate!
>>> >
>>> > Quenio dos Santos wrote:
>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>> > which do
>>> > > provide sub-typing on some level, but are limited in my
>>> opinion. One
>>> > > interface cannot sub-type another interface, for example.
>>> > >
>>> > > As far as inheritance being a flaw, I don't think Martin
>>> Ordersky
>>> > > would agree with you. Otherwise, he wouldn't have put the
>>> feature in
>>> > > Scala :)
>>> > >
>>> > > Scala not only adopted inheritance but enhanced it with
>>> traits.
>>> > >
>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>> >
>>> >
>>> > >
>>> >>> wrote:
>>> > >
>>> > > Haskell does away with inheritance just fine. Indeed, it
>>> > reaps the
>>> > > benefits of having abandoned such a blatant type
>>> system flaw.
>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>> > >
>>> > > Quenio dos Santos wrote:
>>> > > > Hello All,
>>> > > >
>>> > > > I don't know if you have heard the buzz about the new Go
>>> > programming
>>> > > > language from Google, which is been touted as the
>>> new systems
>>> > > language
>>> > > > to replace C/C++.
>>> > > >
>>> > > > I have been exploring it, and although I found it
>>> interesting
>>> > > > initially, now I am not so impressed. Just for starters,
>>> > it doesn't
>>> > > > support sub-typing. I can't really see how can you live
>>> > without
>>> > > > sub-typing and inheritance in a modern programming
>>> language.
>>> > > >
>>> > > > I honestly believe that Scala would be a great systems
>>> > language if a
>>> > > > native compiler was available for Scala. Has that ever
>>> > crossed the
>>> > > > mind of the Scala development team, or anybody else?
>>> > > >
>>> > > > - Quenio
>>> > >
>>> > > --
>>> > > Tony Morris
>>> > > http://tmorris.net/
>>> > >
>>> > >
>>> > >
>>> >
>>> > --
>>> > Tony Morris
>>> > http://tmorris.net/
>>> >
>>> >
>>> >
>>>
>>> --
>>> Tony Morris
>>> http://tmorris.net/
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

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

First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.

What does "Int implies String" mean?
I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
Your answer is, I think, that that difference has no ramification.
Before I continue please correct any misunderstanding.

-------------------------------------
Tony Morris wrote:

I've no idea what you mean by "putting code in functions and invoking
them is a form of code reuse."

I define code reuse along the same lines as that mentioned in Why
Functional Programming Matters (John Hughes).

What do I mean by implies? You have surely seen this Scala syntax =>.
That is logical implication under the Curry-Howard Isomorphism. When you
write Int => String, you are saying "Int implies String."

Here's a fun example List[A] => A. This is a lie! It fails to terminate
under certain domain values (empty list). But we write such a function
anyway (head). That's what I mean by implies and it's exactly what *you*
mean when you use inheritance. You talk of "views"; these are simply
functions, they are not special, just functions. They might be
*implicit* functions (or views), but that's precisely what inheritance
is. When you say "Int => String", you are saying "Int inherits from
String, with the exception that it is explicit." When you write an
implicit function, you are using inheritance encoded differently (and
often times, without certain costs that *inhibit* code reuse).

Here's another example, Option[A] => List[A] (there is a reason I am
avoiding Iterable). This is a true statement. Indeed, Option is simply a
List with a maximum length of 1. It is also (for a typical
implementation), an injection. This is an important part. Indeed, most
programmers, knowingly or not, use inheritance when the implication is
injective. It's not surjective though.

That's all inheritance is. I realise that this may destroy a lot of
fanciful dreams and may even cause offence, but I am just the messenger.
This also has nothing to do with code reuse. It never did. *pop*

Naftoli Gugenheim wrote:
> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>
>
>
> -------------------------------------
> Tony Morris wrote:
>
> I'm not talking in riddles at all. I have already stated that
> inheritance is merely a function. We often think of it differently (to
> our detriment?) -- an arrow pointing upward instead of right-ward, but
> it essentially means "implies", just like any other function. It is also
> implicitly converted, unlike a typical function.
>
> I fail to see how any of this constitutes code reuse. I am awaiting an
> example to the contrary. I'm well aware that few programmers know what
> code reuse means, and I'm most aware of marketing slogans that tout
> inheritance as correlated to code reuse, but I remain optimistic.
>
> Show me an example.
>
> Naftoli Gugenheim wrote:
>
>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> No certainly not. I mean inheritance, just like you do. So, where's the
>> code reuse again?
>>
>> Quenio dos Santos wrote:
>>
>>
>>> Traits are just a clever way of doing multiple inheritance, which
>>> allows mixing without some of the issues you would find in C++. It is
>>> not much different from multiple inheritance in Eiffel, which also
>>> resolves some of the C++ issues.
>>>
>>> I think when you say inheritance, you really mean traditional single
>>> inheritance like in Java.
>>>
>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >> > wrote:
>>>
>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>> implicit.
>>>
>>> Quenio dos Santos wrote:
>>> > I may be completely be missing your point here, but I cannot imagine
>>> > Scala without traits. Maybe, without single inheritance, but not
>>> traits.
>>> >
>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>
>>> > >> wrote:
>>> >
>>> > I didn't mean to imply that absence of inheritance was a
>>> good idea for
>>> > Go. I listed my opinion on Go a few days ago in private to other
>>> > inquiring minds.
>>> >
>>> > I intended only that inheritance is certainly not essential
>>> for a
>>> > "modern" programming language (which I assumed to be
>>> synonymous with
>>> > "practical") and is indeed, rather antithetical. One may or
>>> may not
>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>> users
>>> > ultimately suffer as a result (see the mailing lists for
>>> many examples
>>> > with new ones regularly arriving). Thankfully Oleg has done
>>> all the
>>> > arguing for me so I best not be too loud lest I be coaxed
>>> into another
>>> > debate!
>>> >
>>> > Quenio dos Santos wrote:
>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>> > which do
>>> > > provide sub-typing on some level, but are limited in my
>>> opinion. One
>>> > > interface cannot sub-type another interface, for example.
>>> > >
>>> > > As far as inheritance being a flaw, I don't think Martin
>>> Ordersky
>>> > > would agree with you. Otherwise, he wouldn't have put the
>>> feature in
>>> > > Scala :)
>>> > >
>>> > > Scala not only adopted inheritance but enhanced it with
>>> traits.
>>> > >
>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>> >
>>> >
>>> > >
>>> >>> wrote:
>>> > >
>>> > > Haskell does away with inheritance just fine. Indeed, it
>>> > reaps the
>>> > > benefits of having abandoned such a blatant type
>>> system flaw.
>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>> > >
>>> > > Quenio dos Santos wrote:
>>> > > > Hello All,
>>> > > >
>>> > > > I don't know if you have heard the buzz about the new Go
>>> > programming
>>> > > > language from Google, which is been touted as the
>>> new systems
>>> > > language
>>> > > > to replace C/C++.
>>> > > >
>>> > > > I have been exploring it, and although I found it
>>> interesting
>>> > > > initially, now I am not so impressed. Just for starters,
>>> > it doesn't
>>> > > > support sub-typing. I can't really see how can you live
>>> > without
>>> > > > sub-typing and inheritance in a modern programming
>>> language.
>>> > > >
>>> > > > I honestly believe that Scala would be a great systems
>>> > language if a
>>> > > > native compiler was available for Scala. Has that ever
>>> > crossed the
>>> > > > mind of the Scala development team, or anybody else?
>>> > > >
>>> > > > - Quenio
>>> > >
>>> > > --
>>> > > Tony Morris
>>> > > http://tmorris.net/
>>> > >
>>> > >
>>> > >
>>> >
>>> > --
>>> > Tony Morris
>>> > http://tmorris.net/
>>> >
>>> >
>>> >
>>>
>>> --
>>> Tony Morris
>>> http://tmorris.net/
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Here's how it looks in Scala:

implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...

That is all inheritance buys you (with some costs that are antithetical
to code reuse). If this is somehow "code reuse", then I guess we are
using very distinct definitions.

I implore you to read up on C-H to understand why function signatures
using => logical implication.

Naftoli Gugenheim wrote:
> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>
> What does "Int implies String" mean?
> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
> Your answer is, I think, that that difference has no ramification.
> Before I continue please correct any misunderstanding.
>
>
> -------------------------------------
> Tony Morris wrote:
>
> I've no idea what you mean by "putting code in functions and invoking
> them is a form of code reuse."
>
> I define code reuse along the same lines as that mentioned in Why
> Functional Programming Matters (John Hughes).
>
> What do I mean by implies? You have surely seen this Scala syntax =>.
> That is logical implication under the Curry-Howard Isomorphism. When you
> write Int => String, you are saying "Int implies String."
>
> Here's a fun example List[A] => A. This is a lie! It fails to terminate
> under certain domain values (empty list). But we write such a function
> anyway (head). That's what I mean by implies and it's exactly what *you*
> mean when you use inheritance. You talk of "views"; these are simply
> functions, they are not special, just functions. They might be
> *implicit* functions (or views), but that's precisely what inheritance
> is. When you say "Int => String", you are saying "Int inherits from
> String, with the exception that it is explicit." When you write an
> implicit function, you are using inheritance encoded differently (and
> often times, without certain costs that *inhibit* code reuse).
>
> Here's another example, Option[A] => List[A] (there is a reason I am
> avoiding Iterable). This is a true statement. Indeed, Option is simply a
> List with a maximum length of 1. It is also (for a typical
> implementation), an injection. This is an important part. Indeed, most
> programmers, knowingly or not, use inheritance when the implication is
> injective. It's not surjective though.
>
> That's all inheritance is. I realise that this may destroy a lot of
> fanciful dreams and may even cause offence, but I am just the messenger.
> This also has nothing to do with code reuse. It never did. *pop*
>
> Naftoli Gugenheim wrote:
>
>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>
>>
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> I'm not talking in riddles at all. I have already stated that
>> inheritance is merely a function. We often think of it differently (to
>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>> it essentially means "implies", just like any other function. It is also
>> implicitly converted, unlike a typical function.
>>
>> I fail to see how any of this constitutes code reuse. I am awaiting an
>> example to the contrary. I'm well aware that few programmers know what
>> code reuse means, and I'm most aware of marketing slogans that tout
>> inheritance as correlated to code reuse, but I remain optimistic.
>>
>> Show me an example.
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>> code reuse again?
>>>
>>> Quenio dos Santos wrote:
>>>
>>>
>>>
>>>> Traits are just a clever way of doing multiple inheritance, which
>>>> allows mixing without some of the issues you would find in C++. It is
>>>> not much different from multiple inheritance in Eiffel, which also
>>>> resolves some of the C++ issues.
>>>>
>>>> I think when you say inheritance, you really mean traditional single
>>>> inheritance like in Java.
>>>>
>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>> > wrote:
>>>>
>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>> implicit.
>>>>
>>>> Quenio dos Santos wrote:
>>>> > I may be completely be missing your point here, but I cannot imagine
>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>> traits.
>>>> >
>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>
>>>> > >> wrote:
>>>> >
>>>> > I didn't mean to imply that absence of inheritance was a
>>>> good idea for
>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>> > inquiring minds.
>>>> >
>>>> > I intended only that inheritance is certainly not essential
>>>> for a
>>>> > "modern" programming language (which I assumed to be
>>>> synonymous with
>>>> > "practical") and is indeed, rather antithetical. One may or
>>>> may not
>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>> users
>>>> > ultimately suffer as a result (see the mailing lists for
>>>> many examples
>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>> all the
>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>> into another
>>>> > debate!
>>>> >
>>>> > Quenio dos Santos wrote:
>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>> > which do
>>>> > > provide sub-typing on some level, but are limited in my
>>>> opinion. One
>>>> > > interface cannot sub-type another interface, for example.
>>>> > >
>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>> Ordersky
>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>> feature in
>>>> > > Scala :)
>>>> > >
>>>> > > Scala not only adopted inheritance but enhanced it with
>>>> traits.
>>>> > >
>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>> >
>>>> >
>>>> > >
>>>> >>> wrote:
>>>> > >
>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>> > reaps the
>>>> > > benefits of having abandoned such a blatant type
>>>> system flaw.
>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>> > >
>>>> > > Quenio dos Santos wrote:
>>>> > > > Hello All,
>>>> > > >
>>>> > > > I don't know if you have heard the buzz about the new Go
>>>> > programming
>>>> > > > language from Google, which is been touted as the
>>>> new systems
>>>> > > language
>>>> > > > to replace C/C++.
>>>> > > >
>>>> > > > I have been exploring it, and although I found it
>>>> interesting
>>>> > > > initially, now I am not so impressed. Just for starters,
>>>> > it doesn't
>>>> > > > support sub-typing. I can't really see how can you live
>>>> > without
>>>> > > > sub-typing and inheritance in a modern programming
>>>> language.
>>>> > > >
>>>> > > > I honestly believe that Scala would be a great systems
>>>> > language if a
>>>> > > > native compiler was available for Scala. Has that ever
>>>> > crossed the
>>>> > > > mind of the Scala development team, or anybody else?
>>>> > > >
>>>> > > > - Quenio
>>>> > >
>>>> > > --
>>>> > > Tony Morris
>>>> > > http://tmorris.net/
>>>> > >
>>>> > >
>>>> > >
>>>> >
>>>> > --
>>>> > Tony Morris
>>>> > http://tmorris.net/
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> Tony Morris
>>>> http://tmorris.net/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

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

You haven't answer any of my questions. I realized that was what you're proposing.
1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?

-------------------------------------
Tony Morris wrote:

Here's how it looks in Scala:

implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...

That is all inheritance buys you (with some costs that are antithetical
to code reuse). If this is somehow "code reuse", then I guess we are
using very distinct definitions.

I implore you to read up on C-H to understand why function signatures
using => logical implication.

Naftoli Gugenheim wrote:
> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>
> What does "Int implies String" mean?
> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
> Your answer is, I think, that that difference has no ramification.
> Before I continue please correct any misunderstanding.
>
>
> -------------------------------------
> Tony Morris wrote:
>
> I've no idea what you mean by "putting code in functions and invoking
> them is a form of code reuse."
>
> I define code reuse along the same lines as that mentioned in Why
> Functional Programming Matters (John Hughes).
>
> What do I mean by implies? You have surely seen this Scala syntax =>.
> That is logical implication under the Curry-Howard Isomorphism. When you
> write Int => String, you are saying "Int implies String."
>
> Here's a fun example List[A] => A. This is a lie! It fails to terminate
> under certain domain values (empty list). But we write such a function
> anyway (head). That's what I mean by implies and it's exactly what *you*
> mean when you use inheritance. You talk of "views"; these are simply
> functions, they are not special, just functions. They might be
> *implicit* functions (or views), but that's precisely what inheritance
> is. When you say "Int => String", you are saying "Int inherits from
> String, with the exception that it is explicit." When you write an
> implicit function, you are using inheritance encoded differently (and
> often times, without certain costs that *inhibit* code reuse).
>
> Here's another example, Option[A] => List[A] (there is a reason I am
> avoiding Iterable). This is a true statement. Indeed, Option is simply a
> List with a maximum length of 1. It is also (for a typical
> implementation), an injection. This is an important part. Indeed, most
> programmers, knowingly or not, use inheritance when the implication is
> injective. It's not surjective though.
>
> That's all inheritance is. I realise that this may destroy a lot of
> fanciful dreams and may even cause offence, but I am just the messenger.
> This also has nothing to do with code reuse. It never did. *pop*
>
> Naftoli Gugenheim wrote:
>
>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>
>>
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> I'm not talking in riddles at all. I have already stated that
>> inheritance is merely a function. We often think of it differently (to
>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>> it essentially means "implies", just like any other function. It is also
>> implicitly converted, unlike a typical function.
>>
>> I fail to see how any of this constitutes code reuse. I am awaiting an
>> example to the contrary. I'm well aware that few programmers know what
>> code reuse means, and I'm most aware of marketing slogans that tout
>> inheritance as correlated to code reuse, but I remain optimistic.
>>
>> Show me an example.
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>> code reuse again?
>>>
>>> Quenio dos Santos wrote:
>>>
>>>
>>>
>>>> Traits are just a clever way of doing multiple inheritance, which
>>>> allows mixing without some of the issues you would find in C++. It is
>>>> not much different from multiple inheritance in Eiffel, which also
>>>> resolves some of the C++ issues.
>>>>
>>>> I think when you say inheritance, you really mean traditional single
>>>> inheritance like in Java.
>>>>
>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>> > wrote:
>>>>
>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>> implicit.
>>>>
>>>> Quenio dos Santos wrote:
>>>> > I may be completely be missing your point here, but I cannot imagine
>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>> traits.
>>>> >
>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>
>>>> > >> wrote:
>>>> >
>>>> > I didn't mean to imply that absence of inheritance was a
>>>> good idea for
>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>> > inquiring minds.
>>>> >
>>>> > I intended only that inheritance is certainly not essential
>>>> for a
>>>> > "modern" programming language (which I assumed to be
>>>> synonymous with
>>>> > "practical") and is indeed, rather antithetical. One may or
>>>> may not
>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>> users
>>>> > ultimately suffer as a result (see the mailing lists for
>>>> many examples
>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>> all the
>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>> into another
>>>> > debate!
>>>> >
>>>> > Quenio dos Santos wrote:
>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>> > which do
>>>> > > provide sub-typing on some level, but are limited in my
>>>> opinion. One
>>>> > > interface cannot sub-type another interface, for example.
>>>> > >
>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>> Ordersky
>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>> feature in
>>>> > > Scala :)
>>>> > >
>>>> > > Scala not only adopted inheritance but enhanced it with
>>>> traits.
>>>> > >
>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>> >
>>>> >
>>>> > >
>>>> >>> wrote:
>>>> > >
>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>> > reaps the
>>>> > > benefits of having abandoned such a blatant type
>>>> system flaw.
>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>> > >
>>>> > > Quenio dos Santos wrote:
>>>> > > > Hello All,
>>>> > > >
>>>> > > > I don't know if you have heard the buzz about the new Go
>>>> > programming
>>>> > > > language from Google, which is been touted as the
>>>> new systems
>>>> > > language
>>>> > > > to replace C/C++.
>>>> > > >
>>>> > > > I have been exploring it, and although I found it
>>>> interesting
>>>> > > > initially, now I am not so impressed. Just for starters,
>>>> > it doesn't
>>>> > > > support sub-typing. I can't really see how can you live
>>>> > without
>>>> > > > sub-typing and inheritance in a modern programming
>>>> language.
>>>> > > >
>>>> > > > I honestly believe that Scala would be a great systems
>>>> > language if a
>>>> > > > native compiler was available for Scala. Has that ever
>>>> > crossed the
>>>> > > > mind of the Scala development team, or anybody else?
>>>> > > >
>>>> > > > - Quenio
>>>> > >
>>>> > > --
>>>> > > Tony Morris
>>>> > > http://tmorris.net/
>>>> > >
>>>> > >
>>>> > >
>>>> >
>>>> > --
>>>> > Tony Morris
>>>> > http://tmorris.net/
>>>> >
>>>> >
>>>> >
>>>>
>>>> --
>>>> Tony Morris
>>>> http://tmorris.net/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

1. I implore you read up on C-H, not because it is a diversion, but
because it is one of many fundamental tenets of the skill that you claim
to profess.
2. There are many possibilites. The point is that JButton implies
JComponent and to get there you needn't call an explicit function, but
an implicit one implicitly (ala inheritance)

Here's one

new JComponent() {
// delegate
}

Naftoli Gugenheim wrote:
> You haven't answer any of my questions. I realized that was what you're proposing.
> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>
> -------------------------------------
> Tony Morris wrote:
>
> Here's how it looks in Scala:
>
> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>
> That is all inheritance buys you (with some costs that are antithetical
> to code reuse). If this is somehow "code reuse", then I guess we are
> using very distinct definitions.
>
> I implore you to read up on C-H to understand why function signatures
> using => logical implication.
>
> Naftoli Gugenheim wrote:
>
>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>
>> What does "Int implies String" mean?
>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>> Your answer is, I think, that that difference has no ramification.
>> Before I continue please correct any misunderstanding.
>>
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> I've no idea what you mean by "putting code in functions and invoking
>> them is a form of code reuse."
>>
>> I define code reuse along the same lines as that mentioned in Why
>> Functional Programming Matters (John Hughes).
>>
>> What do I mean by implies? You have surely seen this Scala syntax =>.
>> That is logical implication under the Curry-Howard Isomorphism. When you
>> write Int => String, you are saying "Int implies String."
>>
>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>> under certain domain values (empty list). But we write such a function
>> anyway (head). That's what I mean by implies and it's exactly what *you*
>> mean when you use inheritance. You talk of "views"; these are simply
>> functions, they are not special, just functions. They might be
>> *implicit* functions (or views), but that's precisely what inheritance
>> is. When you say "Int => String", you are saying "Int inherits from
>> String, with the exception that it is explicit." When you write an
>> implicit function, you are using inheritance encoded differently (and
>> often times, without certain costs that *inhibit* code reuse).
>>
>> Here's another example, Option[A] => List[A] (there is a reason I am
>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>> List with a maximum length of 1. It is also (for a typical
>> implementation), an injection. This is an important part. Indeed, most
>> programmers, knowingly or not, use inheritance when the implication is
>> injective. It's not surjective though.
>>
>> That's all inheritance is. I realise that this may destroy a lot of
>> fanciful dreams and may even cause offence, but I am just the messenger.
>> This also has nothing to do with code reuse. It never did. *pop*
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>
>>>
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> I'm not talking in riddles at all. I have already stated that
>>> inheritance is merely a function. We often think of it differently (to
>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>> it essentially means "implies", just like any other function. It is also
>>> implicitly converted, unlike a typical function.
>>>
>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>> example to the contrary. I'm well aware that few programmers know what
>>> code reuse means, and I'm most aware of marketing slogans that tout
>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>
>>> Show me an example.
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>> code reuse again?
>>>>
>>>> Quenio dos Santos wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>> resolves some of the C++ issues.
>>>>>
>>>>> I think when you say inheritance, you really mean traditional single
>>>>> inheritance like in Java.
>>>>>
>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>> > wrote:
>>>>>
>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>> implicit.
>>>>>
>>>>> Quenio dos Santos wrote:
>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>> traits.
>>>>> >
>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>
>>>>> > >> wrote:
>>>>> >
>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>> good idea for
>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>> > inquiring minds.
>>>>> >
>>>>> > I intended only that inheritance is certainly not essential
>>>>> for a
>>>>> > "modern" programming language (which I assumed to be
>>>>> synonymous with
>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>> may not
>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>> users
>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>> many examples
>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>> all the
>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>> into another
>>>>> > debate!
>>>>> >
>>>>> > Quenio dos Santos wrote:
>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>> > which do
>>>>> > > provide sub-typing on some level, but are limited in my
>>>>> opinion. One
>>>>> > > interface cannot sub-type another interface, for example.
>>>>> > >
>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>> Ordersky
>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>> feature in
>>>>> > > Scala :)
>>>>> > >
>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>> traits.
>>>>> > >
>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>> >
>>>>> >
>>>>> > >
>>>>> >>> wrote:
>>>>> > >
>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>> > reaps the
>>>>> > > benefits of having abandoned such a blatant type
>>>>> system flaw.
>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>> > >
>>>>> > > Quenio dos Santos wrote:
>>>>> > > > Hello All,
>>>>> > > >
>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>> > programming
>>>>> > > > language from Google, which is been touted as the
>>>>> new systems
>>>>> > > language
>>>>> > > > to replace C/C++.
>>>>> > > >
>>>>> > > > I have been exploring it, and although I found it
>>>>> interesting
>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>> > it doesn't
>>>>> > > > support sub-typing. I can't really see how can you live
>>>>> > without
>>>>> > > > sub-typing and inheritance in a modern programming
>>>>> language.
>>>>> > > >
>>>>> > > > I honestly believe that Scala would be a great systems
>>>>> > language if a
>>>>> > > > native compiler was available for Scala. Has that ever
>>>>> > crossed the
>>>>> > > > mind of the Scala development team, or anybody else?
>>>>> > > >
>>>>> > > > - Quenio
>>>>> > >
>>>>> > > --
>>>>> > > Tony Morris
>>>>> > > http://tmorris.net/
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> >
>>>>> > --
>>>>> > Tony Morris
>>>>> > http://tmorris.net/
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>> --
>>>>> Tony Morris
>>>>> http://tmorris.net/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

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

1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.

-------------------------------------
Tony Morris wrote:

1. I implore you read up on C-H, not because it is a diversion, but
because it is one of many fundamental tenets of the skill that you claim
to profess.
2. There are many possibilites. The point is that JButton implies
JComponent and to get there you needn't call an explicit function, but
an implicit one implicitly (ala inheritance)

Here's one

new JComponent() {
// delegate
}

Naftoli Gugenheim wrote:
> You haven't answer any of my questions. I realized that was what you're proposing.
> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>
> -------------------------------------
> Tony Morris wrote:
>
> Here's how it looks in Scala:
>
> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>
> That is all inheritance buys you (with some costs that are antithetical
> to code reuse). If this is somehow "code reuse", then I guess we are
> using very distinct definitions.
>
> I implore you to read up on C-H to understand why function signatures
> using => logical implication.
>
> Naftoli Gugenheim wrote:
>
>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>
>> What does "Int implies String" mean?
>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>> Your answer is, I think, that that difference has no ramification.
>> Before I continue please correct any misunderstanding.
>>
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> I've no idea what you mean by "putting code in functions and invoking
>> them is a form of code reuse."
>>
>> I define code reuse along the same lines as that mentioned in Why
>> Functional Programming Matters (John Hughes).
>>
>> What do I mean by implies? You have surely seen this Scala syntax =>.
>> That is logical implication under the Curry-Howard Isomorphism. When you
>> write Int => String, you are saying "Int implies String."
>>
>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>> under certain domain values (empty list). But we write such a function
>> anyway (head). That's what I mean by implies and it's exactly what *you*
>> mean when you use inheritance. You talk of "views"; these are simply
>> functions, they are not special, just functions. They might be
>> *implicit* functions (or views), but that's precisely what inheritance
>> is. When you say "Int => String", you are saying "Int inherits from
>> String, with the exception that it is explicit." When you write an
>> implicit function, you are using inheritance encoded differently (and
>> often times, without certain costs that *inhibit* code reuse).
>>
>> Here's another example, Option[A] => List[A] (there is a reason I am
>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>> List with a maximum length of 1. It is also (for a typical
>> implementation), an injection. This is an important part. Indeed, most
>> programmers, knowingly or not, use inheritance when the implication is
>> injective. It's not surjective though.
>>
>> That's all inheritance is. I realise that this may destroy a lot of
>> fanciful dreams and may even cause offence, but I am just the messenger.
>> This also has nothing to do with code reuse. It never did. *pop*
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>
>>>
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> I'm not talking in riddles at all. I have already stated that
>>> inheritance is merely a function. We often think of it differently (to
>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>> it essentially means "implies", just like any other function. It is also
>>> implicitly converted, unlike a typical function.
>>>
>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>> example to the contrary. I'm well aware that few programmers know what
>>> code reuse means, and I'm most aware of marketing slogans that tout
>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>
>>> Show me an example.
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>> code reuse again?
>>>>
>>>> Quenio dos Santos wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>> resolves some of the C++ issues.
>>>>>
>>>>> I think when you say inheritance, you really mean traditional single
>>>>> inheritance like in Java.
>>>>>
>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>> > wrote:
>>>>>
>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>> implicit.
>>>>>
>>>>> Quenio dos Santos wrote:
>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>> traits.
>>>>> >
>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>
>>>>> > >> wrote:
>>>>> >
>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>> good idea for
>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>> > inquiring minds.
>>>>> >
>>>>> > I intended only that inheritance is certainly not essential
>>>>> for a
>>>>> > "modern" programming language (which I assumed to be
>>>>> synonymous with
>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>> may not
>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>> users
>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>> many examples
>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>> all the
>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>> into another
>>>>> > debate!
>>>>> >
>>>>> > Quenio dos Santos wrote:
>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>> > which do
>>>>> > > provide sub-typing on some level, but are limited in my
>>>>> opinion. One
>>>>> > > interface cannot sub-type another interface, for example.
>>>>> > >
>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>> Ordersky
>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>> feature in
>>>>> > > Scala :)
>>>>> > >
>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>> traits.
>>>>> > >
>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>> >
>>>>> >
>>>>> > >
>>>>> >>> wrote:
>>>>> > >
>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>> > reaps the
>>>>> > > benefits of having abandoned such a blatant type
>>>>> system flaw.
>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>> > >
>>>>> > > Quenio dos Santos wrote:
>>>>> > > > Hello All,
>>>>> > > >
>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>> > programming
>>>>> > > > language from Google, which is been touted as the
>>>>> new systems
>>>>> > > language
>>>>> > > > to replace C/C++.
>>>>> > > >
>>>>> > > > I have been exploring it, and although I found it
>>>>> interesting
>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>> > it doesn't
>>>>> > > > support sub-typing. I can't really see how can you live
>>>>> > without
>>>>> > > > sub-typing and inheritance in a modern programming
>>>>> language.
>>>>> > > >
>>>>> > > > I honestly believe that Scala would be a great systems
>>>>> > language if a
>>>>> > > > native compiler was available for Scala. Has that ever
>>>>> > crossed the
>>>>> > > > mind of the Scala development team, or anybody else?
>>>>> > > >
>>>>> > > > - Quenio
>>>>> > >
>>>>> > > --
>>>>> > > Tony Morris
>>>>> > > http://tmorris.net/
>>>>> > >
>>>>> > >
>>>>> > >
>>>>> >
>>>>> > --
>>>>> > Tony Morris
>>>>> > http://tmorris.net/
>>>>> >
>>>>> >
>>>>> >
>>>>>
>>>>> --
>>>>> Tony Morris
>>>>> http://tmorris.net/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

1. I'm assuming you claim to be a computer programmer. I truly can't be
expected to copy/paste reference material here.
2. A JButton. I'm not bending over backwards at all; I'm demonstrating
quite emphatically, that inheritance is what I said it is, and
therefore, has nothing at all to do with code reuse. It's a very popular
myth that is spread via pop culture programming. Medusa didn't really
have snakes in her hair either.

By the way, Either represents disjunction under C-H.
By the way, disjunction is inequivalent to implication.

I might stop now, don't be afraid to learn!

Naftoli Gugenheim wrote:
> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>
> -------------------------------------
> Tony Morris wrote:
>
> 1. I implore you read up on C-H, not because it is a diversion, but
> because it is one of many fundamental tenets of the skill that you claim
> to profess.
> 2. There are many possibilites. The point is that JButton implies
> JComponent and to get there you needn't call an explicit function, but
> an implicit one implicitly (ala inheritance)
>
> Here's one
>
> new JComponent() {
> // delegate
> }
>
> Naftoli Gugenheim wrote:
>
>> You haven't answer any of my questions. I realized that was what you're proposing.
>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> Here's how it looks in Scala:
>>
>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>
>> That is all inheritance buys you (with some costs that are antithetical
>> to code reuse). If this is somehow "code reuse", then I guess we are
>> using very distinct definitions.
>>
>> I implore you to read up on C-H to understand why function signatures
>> using => logical implication.
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>
>>> What does "Int implies String" mean?
>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>> Your answer is, I think, that that difference has no ramification.
>>> Before I continue please correct any misunderstanding.
>>>
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> I've no idea what you mean by "putting code in functions and invoking
>>> them is a form of code reuse."
>>>
>>> I define code reuse along the same lines as that mentioned in Why
>>> Functional Programming Matters (John Hughes).
>>>
>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>> write Int => String, you are saying "Int implies String."
>>>
>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>> under certain domain values (empty list). But we write such a function
>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>> mean when you use inheritance. You talk of "views"; these are simply
>>> functions, they are not special, just functions. They might be
>>> *implicit* functions (or views), but that's precisely what inheritance
>>> is. When you say "Int => String", you are saying "Int inherits from
>>> String, with the exception that it is explicit." When you write an
>>> implicit function, you are using inheritance encoded differently (and
>>> often times, without certain costs that *inhibit* code reuse).
>>>
>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>> List with a maximum length of 1. It is also (for a typical
>>> implementation), an injection. This is an important part. Indeed, most
>>> programmers, knowingly or not, use inheritance when the implication is
>>> injective. It's not surjective though.
>>>
>>> That's all inheritance is. I realise that this may destroy a lot of
>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>> This also has nothing to do with code reuse. It never did. *pop*
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>
>>>>
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> I'm not talking in riddles at all. I have already stated that
>>>> inheritance is merely a function. We often think of it differently (to
>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>> it essentially means "implies", just like any other function. It is also
>>>> implicitly converted, unlike a typical function.
>>>>
>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>> example to the contrary. I'm well aware that few programmers know what
>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>
>>>> Show me an example.
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>> code reuse again?
>>>>>
>>>>> Quenio dos Santos wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>> resolves some of the C++ issues.
>>>>>>
>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>> inheritance like in Java.
>>>>>>
>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>> > wrote:
>>>>>>
>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>> implicit.
>>>>>>
>>>>>> Quenio dos Santos wrote:
>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>> traits.
>>>>>> >
>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>
>>>>>> > >> wrote:
>>>>>> >
>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>> good idea for
>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>> > inquiring minds.
>>>>>> >
>>>>>> > I intended only that inheritance is certainly not essential
>>>>>> for a
>>>>>> > "modern" programming language (which I assumed to be
>>>>>> synonymous with
>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>> may not
>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>> users
>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>> many examples
>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>> all the
>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>> into another
>>>>>> > debate!
>>>>>> >
>>>>>> > Quenio dos Santos wrote:
>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>> > which do
>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>> opinion. One
>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>> > >
>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>> Ordersky
>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>> feature in
>>>>>> > > Scala :)
>>>>>> > >
>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>> traits.
>>>>>> > >
>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>> >
>>>>>> >
>>>>>> > >
>>>>>> >>> wrote:
>>>>>> > >
>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>> > reaps the
>>>>>> > > benefits of having abandoned such a blatant type
>>>>>> system flaw.
>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>> > >
>>>>>> > > Quenio dos Santos wrote:
>>>>>> > > > Hello All,
>>>>>> > > >
>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>> > programming
>>>>>> > > > language from Google, which is been touted as the
>>>>>> new systems
>>>>>> > > language
>>>>>> > > > to replace C/C++.
>>>>>> > > >
>>>>>> > > > I have been exploring it, and although I found it
>>>>>> interesting
>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>> > it doesn't
>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>> > without
>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>> language.
>>>>>> > > >
>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>> > language if a
>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>> > crossed the
>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>> > > >
>>>>>> > > > - Quenio
>>>>>> > >
>>>>>> > > --
>>>>>> > > Tony Morris
>>>>>> > > http://tmorris.net/
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>> > --
>>>>>> > Tony Morris
>>>>>> > http://tmorris.net/
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> Tony Morris
>>>>>> http://tmorris.net/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

This guy is on the money
http://apocalisp.wordpress.com/2009/08/27/hostility-toward-subtyping/

Naftoli Gugenheim wrote:
> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>
> -------------------------------------
> Tony Morris wrote:
>
> 1. I implore you read up on C-H, not because it is a diversion, but
> because it is one of many fundamental tenets of the skill that you claim
> to profess.
> 2. There are many possibilites. The point is that JButton implies
> JComponent and to get there you needn't call an explicit function, but
> an implicit one implicitly (ala inheritance)
>
> Here's one
>
> new JComponent() {
> // delegate
> }
>
> Naftoli Gugenheim wrote:
>
>> You haven't answer any of my questions. I realized that was what you're proposing.
>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> Here's how it looks in Scala:
>>
>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>
>> That is all inheritance buys you (with some costs that are antithetical
>> to code reuse). If this is somehow "code reuse", then I guess we are
>> using very distinct definitions.
>>
>> I implore you to read up on C-H to understand why function signatures
>> using => logical implication.
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>
>>> What does "Int implies String" mean?
>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>> Your answer is, I think, that that difference has no ramification.
>>> Before I continue please correct any misunderstanding.
>>>
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> I've no idea what you mean by "putting code in functions and invoking
>>> them is a form of code reuse."
>>>
>>> I define code reuse along the same lines as that mentioned in Why
>>> Functional Programming Matters (John Hughes).
>>>
>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>> write Int => String, you are saying "Int implies String."
>>>
>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>> under certain domain values (empty list). But we write such a function
>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>> mean when you use inheritance. You talk of "views"; these are simply
>>> functions, they are not special, just functions. They might be
>>> *implicit* functions (or views), but that's precisely what inheritance
>>> is. When you say "Int => String", you are saying "Int inherits from
>>> String, with the exception that it is explicit." When you write an
>>> implicit function, you are using inheritance encoded differently (and
>>> often times, without certain costs that *inhibit* code reuse).
>>>
>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>> List with a maximum length of 1. It is also (for a typical
>>> implementation), an injection. This is an important part. Indeed, most
>>> programmers, knowingly or not, use inheritance when the implication is
>>> injective. It's not surjective though.
>>>
>>> That's all inheritance is. I realise that this may destroy a lot of
>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>> This also has nothing to do with code reuse. It never did. *pop*
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>
>>>>
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> I'm not talking in riddles at all. I have already stated that
>>>> inheritance is merely a function. We often think of it differently (to
>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>> it essentially means "implies", just like any other function. It is also
>>>> implicitly converted, unlike a typical function.
>>>>
>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>> example to the contrary. I'm well aware that few programmers know what
>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>
>>>> Show me an example.
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>> code reuse again?
>>>>>
>>>>> Quenio dos Santos wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>> resolves some of the C++ issues.
>>>>>>
>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>> inheritance like in Java.
>>>>>>
>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>> > wrote:
>>>>>>
>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>> implicit.
>>>>>>
>>>>>> Quenio dos Santos wrote:
>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>> traits.
>>>>>> >
>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>
>>>>>> > >> wrote:
>>>>>> >
>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>> good idea for
>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>> > inquiring minds.
>>>>>> >
>>>>>> > I intended only that inheritance is certainly not essential
>>>>>> for a
>>>>>> > "modern" programming language (which I assumed to be
>>>>>> synonymous with
>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>> may not
>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>> users
>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>> many examples
>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>> all the
>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>> into another
>>>>>> > debate!
>>>>>> >
>>>>>> > Quenio dos Santos wrote:
>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>> > which do
>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>> opinion. One
>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>> > >
>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>> Ordersky
>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>> feature in
>>>>>> > > Scala :)
>>>>>> > >
>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>> traits.
>>>>>> > >
>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>> >
>>>>>> >
>>>>>> > >
>>>>>> >>> wrote:
>>>>>> > >
>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>> > reaps the
>>>>>> > > benefits of having abandoned such a blatant type
>>>>>> system flaw.
>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>> > >
>>>>>> > > Quenio dos Santos wrote:
>>>>>> > > > Hello All,
>>>>>> > > >
>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>> > programming
>>>>>> > > > language from Google, which is been touted as the
>>>>>> new systems
>>>>>> > > language
>>>>>> > > > to replace C/C++.
>>>>>> > > >
>>>>>> > > > I have been exploring it, and although I found it
>>>>>> interesting
>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>> > it doesn't
>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>> > without
>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>> language.
>>>>>> > > >
>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>> > language if a
>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>> > crossed the
>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>> > > >
>>>>>> > > > - Quenio
>>>>>> > >
>>>>>> > > --
>>>>>> > > Tony Morris
>>>>>> > > http://tmorris.net/
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>> > --
>>>>>> > Tony Morris
>>>>>> > http://tmorris.net/
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> Tony Morris
>>>>>> http://tmorris.net/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

matthw
Joined: 2009-08-23,
User offline. Last seen 3 years 9 weeks ago.
Re: Native Compiler for Scala

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
Joined: 2008-12-19,
User offline. Last seen 3 years 2 weeks ago.
Re: Native Compiler for Scala

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/
>
>

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

You're missing my point.
The basis of your argument is that the definition of functions covers inheritance too. This is based on your cryptic usage of "implies." You refuse to elaborate because you can't be bother to copy-paste? Is that the depth of your understanding? You know how to point to a source or copy-paste it? If you understand it, you should be able to explain it concisely but clearly in about five sentences.
I won't respond to (2) because if you think about what I said you'll realize what I meant by bending over backward; and because it's secondary to this discussion.

-------------------------------------
Tony Morris wrote:

1. I'm assuming you claim to be a computer programmer. I truly can't be
expected to copy/paste reference material here.
2. A JButton. I'm not bending over backwards at all; I'm demonstrating
quite emphatically, that inheritance is what I said it is, and
therefore, has nothing at all to do with code reuse. It's a very popular
myth that is spread via pop culture programming. Medusa didn't really
have snakes in her hair either.

By the way, Either represents disjunction under C-H.
By the way, disjunction is inequivalent to implication.

I might stop now, don't be afraid to learn!

Naftoli Gugenheim wrote:
> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>
> -------------------------------------
> Tony Morris wrote:
>
> 1. I implore you read up on C-H, not because it is a diversion, but
> because it is one of many fundamental tenets of the skill that you claim
> to profess.
> 2. There are many possibilites. The point is that JButton implies
> JComponent and to get there you needn't call an explicit function, but
> an implicit one implicitly (ala inheritance)
>
> Here's one
>
> new JComponent() {
> // delegate
> }
>
> Naftoli Gugenheim wrote:
>
>> You haven't answer any of my questions. I realized that was what you're proposing.
>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> Here's how it looks in Scala:
>>
>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>
>> That is all inheritance buys you (with some costs that are antithetical
>> to code reuse). If this is somehow "code reuse", then I guess we are
>> using very distinct definitions.
>>
>> I implore you to read up on C-H to understand why function signatures
>> using => logical implication.
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>
>>> What does "Int implies String" mean?
>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>> Your answer is, I think, that that difference has no ramification.
>>> Before I continue please correct any misunderstanding.
>>>
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> I've no idea what you mean by "putting code in functions and invoking
>>> them is a form of code reuse."
>>>
>>> I define code reuse along the same lines as that mentioned in Why
>>> Functional Programming Matters (John Hughes).
>>>
>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>> write Int => String, you are saying "Int implies String."
>>>
>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>> under certain domain values (empty list). But we write such a function
>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>> mean when you use inheritance. You talk of "views"; these are simply
>>> functions, they are not special, just functions. They might be
>>> *implicit* functions (or views), but that's precisely what inheritance
>>> is. When you say "Int => String", you are saying "Int inherits from
>>> String, with the exception that it is explicit." When you write an
>>> implicit function, you are using inheritance encoded differently (and
>>> often times, without certain costs that *inhibit* code reuse).
>>>
>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>> List with a maximum length of 1. It is also (for a typical
>>> implementation), an injection. This is an important part. Indeed, most
>>> programmers, knowingly or not, use inheritance when the implication is
>>> injective. It's not surjective though.
>>>
>>> That's all inheritance is. I realise that this may destroy a lot of
>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>> This also has nothing to do with code reuse. It never did. *pop*
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>
>>>>
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> I'm not talking in riddles at all. I have already stated that
>>>> inheritance is merely a function. We often think of it differently (to
>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>> it essentially means "implies", just like any other function. It is also
>>>> implicitly converted, unlike a typical function.
>>>>
>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>> example to the contrary. I'm well aware that few programmers know what
>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>
>>>> Show me an example.
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>> code reuse again?
>>>>>
>>>>> Quenio dos Santos wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>> resolves some of the C++ issues.
>>>>>>
>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>> inheritance like in Java.
>>>>>>
>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>> > wrote:
>>>>>>
>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>> implicit.
>>>>>>
>>>>>> Quenio dos Santos wrote:
>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>> traits.
>>>>>> >
>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>
>>>>>> > >> wrote:
>>>>>> >
>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>> good idea for
>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>> > inquiring minds.
>>>>>> >
>>>>>> > I intended only that inheritance is certainly not essential
>>>>>> for a
>>>>>> > "modern" programming language (which I assumed to be
>>>>>> synonymous with
>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>> may not
>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>> users
>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>> many examples
>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>> all the
>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>> into another
>>>>>> > debate!
>>>>>> >
>>>>>> > Quenio dos Santos wrote:
>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>> > which do
>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>> opinion. One
>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>> > >
>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>> Ordersky
>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>> feature in
>>>>>> > > Scala :)
>>>>>> > >
>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>> traits.
>>>>>> > >
>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>> >
>>>>>> >
>>>>>> > >
>>>>>> >>> wrote:
>>>>>> > >
>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>> > reaps the
>>>>>> > > benefits of having abandoned such a blatant type
>>>>>> system flaw.
>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>> > >
>>>>>> > > Quenio dos Santos wrote:
>>>>>> > > > Hello All,
>>>>>> > > >
>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>> > programming
>>>>>> > > > language from Google, which is been touted as the
>>>>>> new systems
>>>>>> > > language
>>>>>> > > > to replace C/C++.
>>>>>> > > >
>>>>>> > > > I have been exploring it, and although I found it
>>>>>> interesting
>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>> > it doesn't
>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>> > without
>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>> language.
>>>>>> > > >
>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>> > language if a
>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>> > crossed the
>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>> > > >
>>>>>> > > > - Quenio
>>>>>> > >
>>>>>> > > --
>>>>>> > > Tony Morris
>>>>>> > > http://tmorris.net/
>>>>>> > >
>>>>>> > >
>>>>>> > >
>>>>>> >
>>>>>> > --
>>>>>> > Tony Morris
>>>>>> > http://tmorris.net/
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> Tony Morris
>>>>>> http://tmorris.net/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Naftoli Gugenheim wrote:
> You're missing my point.
> The basis of your argument is that the definition of functions covers inheritance too.
No it isn't. I have repeated myself enough now and if you insist on
misrepresenting what I say, then I suggest that we abort.
> This is based on your cryptic usage of "implies."
There is nothing cryptic about my use of implies. The => syntax *means
implies*. That is what it means. There is nothing cryptic here.

Do you want me to explain implication? Sure.

p q p->q
0 0 1
0 1 1
1 0 0
1 1 1

> You refuse to elaborate because you can't be bother to copy-paste? Is that the depth of your understanding? You know how to point to a source or copy-paste it? If you understand it, you should be able to explain it concisely but clearly in about five sentences.
>
That seems rather arbitrary. Did you pull that out of your arse? Why are
you so averse to learning?
> I won't respond to (2) because if you think about what I said you'll realize what I meant by bending over backward; and because it's secondary to this discussion.
>
There is no discussion. You refuse to comprehend what I am saying. I am
not sure why that is, but I suggest that due its consistency, you go no
believing what you do, and I'll keep understanding what inheritance (and
implication) is.
>
> -------------------------------------
> Tony Morris wrote:
>
> 1. I'm assuming you claim to be a computer programmer. I truly can't be
> expected to copy/paste reference material here.
> 2. A JButton. I'm not bending over backwards at all; I'm demonstrating
> quite emphatically, that inheritance is what I said it is, and
> therefore, has nothing at all to do with code reuse. It's a very popular
> myth that is spread via pop culture programming. Medusa didn't really
> have snakes in her hair either.
>
> By the way, Either represents disjunction under C-H.
> By the way, disjunction is inequivalent to implication.
>
> I might stop now, don't be afraid to learn!
>
> Naftoli Gugenheim wrote:
>
>> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
>> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> 1. I implore you read up on C-H, not because it is a diversion, but
>> because it is one of many fundamental tenets of the skill that you claim
>> to profess.
>> 2. There are many possibilites. The point is that JButton implies
>> JComponent and to get there you needn't call an explicit function, but
>> an implicit one implicitly (ala inheritance)
>>
>> Here's one
>>
>> new JComponent() {
>> // delegate
>> }
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> You haven't answer any of my questions. I realized that was what you're proposing.
>>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> Here's how it looks in Scala:
>>>
>>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>>
>>> That is all inheritance buys you (with some costs that are antithetical
>>> to code reuse). If this is somehow "code reuse", then I guess we are
>>> using very distinct definitions.
>>>
>>> I implore you to read up on C-H to understand why function signatures
>>> using => logical implication.
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>>
>>>> What does "Int implies String" mean?
>>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>>> Your answer is, I think, that that difference has no ramification.
>>>> Before I continue please correct any misunderstanding.
>>>>
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> I've no idea what you mean by "putting code in functions and invoking
>>>> them is a form of code reuse."
>>>>
>>>> I define code reuse along the same lines as that mentioned in Why
>>>> Functional Programming Matters (John Hughes).
>>>>
>>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>>> write Int => String, you are saying "Int implies String."
>>>>
>>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>>> under certain domain values (empty list). But we write such a function
>>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>>> mean when you use inheritance. You talk of "views"; these are simply
>>>> functions, they are not special, just functions. They might be
>>>> *implicit* functions (or views), but that's precisely what inheritance
>>>> is. When you say "Int => String", you are saying "Int inherits from
>>>> String, with the exception that it is explicit." When you write an
>>>> implicit function, you are using inheritance encoded differently (and
>>>> often times, without certain costs that *inhibit* code reuse).
>>>>
>>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>>> List with a maximum length of 1. It is also (for a typical
>>>> implementation), an injection. This is an important part. Indeed, most
>>>> programmers, knowingly or not, use inheritance when the implication is
>>>> injective. It's not surjective though.
>>>>
>>>> That's all inheritance is. I realise that this may destroy a lot of
>>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>>> This also has nothing to do with code reuse. It never did. *pop*
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> I'm not talking in riddles at all. I have already stated that
>>>>> inheritance is merely a function. We often think of it differently (to
>>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>>> it essentially means "implies", just like any other function. It is also
>>>>> implicitly converted, unlike a typical function.
>>>>>
>>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>>> example to the contrary. I'm well aware that few programmers know what
>>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>>
>>>>> Show me an example.
>>>>>
>>>>> Naftoli Gugenheim wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>>
>>>>>>
>>>>>> -------------------------------------
>>>>>> Tony Morris wrote:
>>>>>>
>>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>>> code reuse again?
>>>>>>
>>>>>> Quenio dos Santos wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>>> resolves some of the C++ issues.
>>>>>>>
>>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>>> inheritance like in Java.
>>>>>>>
>>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>>> > wrote:
>>>>>>>
>>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>>> implicit.
>>>>>>>
>>>>>>> Quenio dos Santos wrote:
>>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>>> traits.
>>>>>>> >
>>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>>
>>>>>>> > >> wrote:
>>>>>>> >
>>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>>> good idea for
>>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>>> > inquiring minds.
>>>>>>> >
>>>>>>> > I intended only that inheritance is certainly not essential
>>>>>>> for a
>>>>>>> > "modern" programming language (which I assumed to be
>>>>>>> synonymous with
>>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>>> may not
>>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>>> users
>>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>>> many examples
>>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>>> all the
>>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>>> into another
>>>>>>> > debate!
>>>>>>> >
>>>>>>> > Quenio dos Santos wrote:
>>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>>> > which do
>>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>>> opinion. One
>>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>>> > >
>>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>>> Ordersky
>>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>>> feature in
>>>>>>> > > Scala :)
>>>>>>> > >
>>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>>> traits.
>>>>>>> > >
>>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>>> >
>>>>>>> >
>>>>>>> > >
>>>>>>> >>> wrote:
>>>>>>> > >
>>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>>> > reaps the
>>>>>>> > > benefits of having abandoned such a blatant type
>>>>>>> system flaw.
>>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>>> > >
>>>>>>> > > Quenio dos Santos wrote:
>>>>>>> > > > Hello All,
>>>>>>> > > >
>>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>>> > programming
>>>>>>> > > > language from Google, which is been touted as the
>>>>>>> new systems
>>>>>>> > > language
>>>>>>> > > > to replace C/C++.
>>>>>>> > > >
>>>>>>> > > > I have been exploring it, and although I found it
>>>>>>> interesting
>>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>>> > it doesn't
>>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>>> > without
>>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>>> language.
>>>>>>> > > >
>>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>>> > language if a
>>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>>> > crossed the
>>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>>> > > >
>>>>>>> > > > - Quenio
>>>>>>> > >
>>>>>>> > > --
>>>>>>> > > Tony Morris
>>>>>>> > > http://tmorris.net/
>>>>>>> > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> >
>>>>>>> > --
>>>>>>> > Tony Morris
>>>>>>> > http://tmorris.net/
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> --
>>>>>>> Tony Morris
>>>>>>> http://tmorris.net/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

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

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/
>
>

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

I'm guessing by equality you mean identity?

-------------------------------------
Matthew Willson wrote:

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/

geoff
Joined: 2008-08-20,
User offline. Last seen 1 year 25 weeks ago.
Re: Native Compiler for Scala

On Mon, Nov 16, 2009 at 02:40:32PM -0800, Naftoli Gugenheim said
> -------------------------------------
> 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.
>
> Is that the relationship of JButton to JComponent?

Well AbstractButton seems to have the union of functionality between
JButton, JMenuItem, JToggleButton, JCheckBox and JRadioButton rather
than the intersection. I think that illustrates Ricky's point rather
well.

matthw
Joined: 2009-08-23,
User offline. Last seen 3 years 9 weeks ago.
Re: Native Compiler for Scala

Yep, sorry meant identity there.

Haskell of course, meets this condition (no sense of object identity
at the level of the memory model, just an 'Eq' typeclass), and it uses
typeclasses rather than inheritance to great effect.

Does anyone have an example of a non-pure, OO or OO-FP hybrid language
which uses some kind of implicit-like mechanism in place of inheritance?

On 16 Nov 2009, at 22:40, Naftoli Gugenheim wrote:

> I'm guessing by equality you mean identity?
>
> -------------------------------------
> Matthew Willson wrote:
>
> 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/
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Matthew Willson wrote:
> Yep, sorry meant identity there.
>
> Haskell of course, meets this condition (no sense of object identity
> at the level of the memory model, just an 'Eq' typeclass), and it uses
> typeclasses rather than inheritance to great effect.
>
> Does anyone have an example of a non-pure, OO or OO-FP hybrid language
> which uses some kind of implicit-like mechanism in place of inheritance?
Scala.

Note that Scala's implicit is extremely similar (with some minor notable
differences) to Haskell's type-classes, which as you say replaces
inheritance. I shall say no more :)
See Scalaz for an example of using implicit instead of inheritance, with
some exceptions.

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Naftoli Gugenheim wrote:
> Please don't say I refuse to comprehend.
>
I will stop saying it on exactly one condition.
> If you can't explain implies except for in terms of a truth able (or more precisely a binary table) then either (1) you don't understand my question; (2) you happen to not have an answer; or (3) there is no answer, because this is not a concept that exists outside of mathematical jargon.
>
You're just making shit up.
> -------------------------------------
> Tony Morris wrote:
>
>
>
> Naftoli Gugenheim wrote:
>
>> You're missing my point.
>> The basis of your argument is that the definition of functions covers inheritance too.
>>
> No it isn't. I have repeated myself enough now and if you insist on
> misrepresenting what I say, then I suggest that we abort.
>
>> This is based on your cryptic usage of "implies."
>>
> There is nothing cryptic about my use of implies. The => syntax *means
> implies*. That is what it means. There is nothing cryptic here.
>
> Do you want me to explain implication? Sure.
>
> p q p->q
> 0 0 1
> 0 1 1
> 1 0 0
> 1 1 1
>
>
>
>> You refuse to elaborate because you can't be bother to copy-paste? Is that the depth of your understanding? You know how to point to a source or copy-paste it? If you understand it, you should be able to explain it concisely but clearly in about five sentences.
>>
>>
> That seems rather arbitrary. Did you pull that out of your arse? Why are
> you so averse to learning?
>
>> I won't respond to (2) because if you think about what I said you'll realize what I meant by bending over backward; and because it's secondary to this discussion.
>>
>>
> There is no discussion. You refuse to comprehend what I am saying. I am
> not sure why that is, but I suggest that due its consistency, you go no
> believing what you do, and I'll keep understanding what inheritance (and
> implication) is.
>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> 1. I'm assuming you claim to be a computer programmer. I truly can't be
>> expected to copy/paste reference material here.
>> 2. A JButton. I'm not bending over backwards at all; I'm demonstrating
>> quite emphatically, that inheritance is what I said it is, and
>> therefore, has nothing at all to do with code reuse. It's a very popular
>> myth that is spread via pop culture programming. Medusa didn't really
>> have snakes in her hair either.
>>
>> By the way, Either represents disjunction under C-H.
>> By the way, disjunction is inequivalent to implication.
>>
>> I might stop now, don't be afraid to learn!
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
>>> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> 1. I implore you read up on C-H, not because it is a diversion, but
>>> because it is one of many fundamental tenets of the skill that you claim
>>> to profess.
>>> 2. There are many possibilites. The point is that JButton implies
>>> JComponent and to get there you needn't call an explicit function, but
>>> an implicit one implicitly (ala inheritance)
>>>
>>> Here's one
>>>
>>> new JComponent() {
>>> // delegate
>>> }
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> You haven't answer any of my questions. I realized that was what you're proposing.
>>>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>>>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> Here's how it looks in Scala:
>>>>
>>>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>>>
>>>> That is all inheritance buys you (with some costs that are antithetical
>>>> to code reuse). If this is somehow "code reuse", then I guess we are
>>>> using very distinct definitions.
>>>>
>>>> I implore you to read up on C-H to understand why function signatures
>>>> using => logical implication.
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>>>
>>>>> What does "Int implies String" mean?
>>>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>>>> Your answer is, I think, that that difference has no ramification.
>>>>> Before I continue please correct any misunderstanding.
>>>>>
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> I've no idea what you mean by "putting code in functions and invoking
>>>>> them is a form of code reuse."
>>>>>
>>>>> I define code reuse along the same lines as that mentioned in Why
>>>>> Functional Programming Matters (John Hughes).
>>>>>
>>>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>>>> write Int => String, you are saying "Int implies String."
>>>>>
>>>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>>>> under certain domain values (empty list). But we write such a function
>>>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>>>> mean when you use inheritance. You talk of "views"; these are simply
>>>>> functions, they are not special, just functions. They might be
>>>>> *implicit* functions (or views), but that's precisely what inheritance
>>>>> is. When you say "Int => String", you are saying "Int inherits from
>>>>> String, with the exception that it is explicit." When you write an
>>>>> implicit function, you are using inheritance encoded differently (and
>>>>> often times, without certain costs that *inhibit* code reuse).
>>>>>
>>>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>>>> List with a maximum length of 1. It is also (for a typical
>>>>> implementation), an injection. This is an important part. Indeed, most
>>>>> programmers, knowingly or not, use inheritance when the implication is
>>>>> injective. It's not surjective though.
>>>>>
>>>>> That's all inheritance is. I realise that this may destroy a lot of
>>>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>>>> This also has nothing to do with code reuse. It never did. *pop*
>>>>>
>>>>> Naftoli Gugenheim wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------
>>>>>> Tony Morris wrote:
>>>>>>
>>>>>> I'm not talking in riddles at all. I have already stated that
>>>>>> inheritance is merely a function. We often think of it differently (to
>>>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>>>> it essentially means "implies", just like any other function. It is also
>>>>>> implicitly converted, unlike a typical function.
>>>>>>
>>>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>>>> example to the contrary. I'm well aware that few programmers know what
>>>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>>>
>>>>>> Show me an example.
>>>>>>
>>>>>> Naftoli Gugenheim wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------
>>>>>>> Tony Morris wrote:
>>>>>>>
>>>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>>>> code reuse again?
>>>>>>>
>>>>>>> Quenio dos Santos wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>>>> resolves some of the C++ issues.
>>>>>>>>
>>>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>>>> inheritance like in Java.
>>>>>>>>
>>>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>>>> implicit.
>>>>>>>>
>>>>>>>> Quenio dos Santos wrote:
>>>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>>>> traits.
>>>>>>>> >
>>>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>>>
>>>>>>>> > >> wrote:
>>>>>>>> >
>>>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>>>> good idea for
>>>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>>>> > inquiring minds.
>>>>>>>> >
>>>>>>>> > I intended only that inheritance is certainly not essential
>>>>>>>> for a
>>>>>>>> > "modern" programming language (which I assumed to be
>>>>>>>> synonymous with
>>>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>>>> may not
>>>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>>>> users
>>>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>>>> many examples
>>>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>>>> all the
>>>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>>>> into another
>>>>>>>> > debate!
>>>>>>>> >
>>>>>>>> > Quenio dos Santos wrote:
>>>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>>>> > which do
>>>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>>>> opinion. One
>>>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>>>> > >
>>>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>>>> Ordersky
>>>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>>>> feature in
>>>>>>>> > > Scala :)
>>>>>>>> > >
>>>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>>>> traits.
>>>>>>>> > >
>>>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> >>> wrote:
>>>>>>>> > >
>>>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>>>> > reaps the
>>>>>>>> > > benefits of having abandoned such a blatant type
>>>>>>>> system flaw.
>>>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>>>> > >
>>>>>>>> > > Quenio dos Santos wrote:
>>>>>>>> > > > Hello All,
>>>>>>>> > > >
>>>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>>>> > programming
>>>>>>>> > > > language from Google, which is been touted as the
>>>>>>>> new systems
>>>>>>>> > > language
>>>>>>>> > > > to replace C/C++.
>>>>>>>> > > >
>>>>>>>> > > > I have been exploring it, and although I found it
>>>>>>>> interesting
>>>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>>>> > it doesn't
>>>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>>>> > without
>>>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>>>> language.
>>>>>>>> > > >
>>>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>>>> > language if a
>>>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>>>> > crossed the
>>>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>>>> > > >
>>>>>>>> > > > - Quenio
>>>>>>>> > >
>>>>>>>> > > --
>>>>>>>> > > Tony Morris
>>>>>>>> > > http://tmorris.net/
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > Tony Morris
>>>>>>>> > http://tmorris.net/
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>> --
>>>>>>>> Tony Morris
>>>>>>>> http://tmorris.net/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

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

Please don't say I refuse to comprehend. I don't have to detail the reasons why it's impractical for me to read up on this at the moment. I'm asking you to write five sentences explaining in plain English how the relationship described in "A car implies four wheels" applies to that expressed in "A car is a vehicle". The explanation does not have to be mathematically precise; it has to convey the understanding.
If you can't explain implies except for in terms of a truth able (or more precisely a binary table) then either (1) you don't understand my question; (2) you happen to not have an answer; or (3) there is no answer, because this is not a concept that exists outside of mathematical jargon.

-------------------------------------
Tony Morris wrote:

Naftoli Gugenheim wrote:
> You're missing my point.
> The basis of your argument is that the definition of functions covers inheritance too.
No it isn't. I have repeated myself enough now and if you insist on
misrepresenting what I say, then I suggest that we abort.
> This is based on your cryptic usage of "implies."
There is nothing cryptic about my use of implies. The => syntax *means
implies*. That is what it means. There is nothing cryptic here.

Do you want me to explain implication? Sure.

p q p->q
0 0 1
0 1 1
1 0 0
1 1 1

> You refuse to elaborate because you can't be bother to copy-paste? Is that the depth of your understanding? You know how to point to a source or copy-paste it? If you understand it, you should be able to explain it concisely but clearly in about five sentences.
>
That seems rather arbitrary. Did you pull that out of your arse? Why are
you so averse to learning?
> I won't respond to (2) because if you think about what I said you'll realize what I meant by bending over backward; and because it's secondary to this discussion.
>
There is no discussion. You refuse to comprehend what I am saying. I am
not sure why that is, but I suggest that due its consistency, you go no
believing what you do, and I'll keep understanding what inheritance (and
implication) is.
>
> -------------------------------------
> Tony Morris wrote:
>
> 1. I'm assuming you claim to be a computer programmer. I truly can't be
> expected to copy/paste reference material here.
> 2. A JButton. I'm not bending over backwards at all; I'm demonstrating
> quite emphatically, that inheritance is what I said it is, and
> therefore, has nothing at all to do with code reuse. It's a very popular
> myth that is spread via pop culture programming. Medusa didn't really
> have snakes in her hair either.
>
> By the way, Either represents disjunction under C-H.
> By the way, disjunction is inequivalent to implication.
>
> I might stop now, don't be afraid to learn!
>
> Naftoli Gugenheim wrote:
>
>> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
>> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> 1. I implore you read up on C-H, not because it is a diversion, but
>> because it is one of many fundamental tenets of the skill that you claim
>> to profess.
>> 2. There are many possibilites. The point is that JButton implies
>> JComponent and to get there you needn't call an explicit function, but
>> an implicit one implicitly (ala inheritance)
>>
>> Here's one
>>
>> new JComponent() {
>> // delegate
>> }
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> You haven't answer any of my questions. I realized that was what you're proposing.
>>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> Here's how it looks in Scala:
>>>
>>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>>
>>> That is all inheritance buys you (with some costs that are antithetical
>>> to code reuse). If this is somehow "code reuse", then I guess we are
>>> using very distinct definitions.
>>>
>>> I implore you to read up on C-H to understand why function signatures
>>> using => logical implication.
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>>
>>>> What does "Int implies String" mean?
>>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>>> Your answer is, I think, that that difference has no ramification.
>>>> Before I continue please correct any misunderstanding.
>>>>
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> I've no idea what you mean by "putting code in functions and invoking
>>>> them is a form of code reuse."
>>>>
>>>> I define code reuse along the same lines as that mentioned in Why
>>>> Functional Programming Matters (John Hughes).
>>>>
>>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>>> write Int => String, you are saying "Int implies String."
>>>>
>>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>>> under certain domain values (empty list). But we write such a function
>>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>>> mean when you use inheritance. You talk of "views"; these are simply
>>>> functions, they are not special, just functions. They might be
>>>> *implicit* functions (or views), but that's precisely what inheritance
>>>> is. When you say "Int => String", you are saying "Int inherits from
>>>> String, with the exception that it is explicit." When you write an
>>>> implicit function, you are using inheritance encoded differently (and
>>>> often times, without certain costs that *inhibit* code reuse).
>>>>
>>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>>> List with a maximum length of 1. It is also (for a typical
>>>> implementation), an injection. This is an important part. Indeed, most
>>>> programmers, knowingly or not, use inheritance when the implication is
>>>> injective. It's not surjective though.
>>>>
>>>> That's all inheritance is. I realise that this may destroy a lot of
>>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>>> This also has nothing to do with code reuse. It never did. *pop*
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> I'm not talking in riddles at all. I have already stated that
>>>>> inheritance is merely a function. We often think of it differently (to
>>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>>> it essentially means "implies", just like any other function. It is also
>>>>> implicitly converted, unlike a typical function.
>>>>>
>>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>>> example to the contrary. I'm well aware that few programmers know what
>>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>>
>>>>> Show me an example.
>>>>>
>>>>> Naftoli Gugenheim wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>>
>>>>>>
>>>>>> -------------------------------------
>>>>>> Tony Morris wrote:
>>>>>>
>>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>>> code reuse again?
>>>>>>
>>>>>> Quenio dos Santos wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>>> resolves some of the C++ issues.
>>>>>>>
>>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>>> inheritance like in Java.
>>>>>>>
>>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>>> > wrote:
>>>>>>>
>>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>>> implicit.
>>>>>>>
>>>>>>> Quenio dos Santos wrote:
>>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>>> traits.
>>>>>>> >
>>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>>
>>>>>>> > >> wrote:
>>>>>>> >
>>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>>> good idea for
>>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>>> > inquiring minds.
>>>>>>> >
>>>>>>> > I intended only that inheritance is certainly not essential
>>>>>>> for a
>>>>>>> > "modern" programming language (which I assumed to be
>>>>>>> synonymous with
>>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>>> may not
>>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>>> users
>>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>>> many examples
>>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>>> all the
>>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>>> into another
>>>>>>> > debate!
>>>>>>> >
>>>>>>> > Quenio dos Santos wrote:
>>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>>> > which do
>>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>>> opinion. One
>>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>>> > >
>>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>>> Ordersky
>>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>>> feature in
>>>>>>> > > Scala :)
>>>>>>> > >
>>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>>> traits.
>>>>>>> > >
>>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>>> >
>>>>>>> >
>>>>>>> > >
>>>>>>> >>> wrote:
>>>>>>> > >
>>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>>> > reaps the
>>>>>>> > > benefits of having abandoned such a blatant type
>>>>>>> system flaw.
>>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>>> > >
>>>>>>> > > Quenio dos Santos wrote:
>>>>>>> > > > Hello All,
>>>>>>> > > >
>>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>>> > programming
>>>>>>> > > > language from Google, which is been touted as the
>>>>>>> new systems
>>>>>>> > > language
>>>>>>> > > > to replace C/C++.
>>>>>>> > > >
>>>>>>> > > > I have been exploring it, and although I found it
>>>>>>> interesting
>>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>>> > it doesn't
>>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>>> > without
>>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>>> language.
>>>>>>> > > >
>>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>>> > language if a
>>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>>> > crossed the
>>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>>> > > >
>>>>>>> > > > - Quenio
>>>>>>> > >
>>>>>>> > > --
>>>>>>> > > Tony Morris
>>>>>>> > > http://tmorris.net/
>>>>>>> > >
>>>>>>> > >
>>>>>>> > >
>>>>>>> >
>>>>>>> > --
>>>>>>> > Tony Morris
>>>>>>> > http://tmorris.net/
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>> --
>>>>>>> Tony Morris
>>>>>>> http://tmorris.net/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

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

Where do you see that?
More importantly, why is that a result of using inheritance rather than poor design per se?

-------------------------------------
Geoff Reedy wrote:

On Mon, Nov 16, 2009 at 02:40:32PM -0800, Naftoli Gugenheim said
> -------------------------------------
> 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.
>
> Is that the relationship of JButton to JComponent?

Well AbstractButton seems to have the union of functionality between
JButton, JMenuItem, JToggleButton, JCheckBox and JRadioButton rather
than the intersection. I think that illustrates Ricky's point rather
well.

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

Excuse me?
Did I offend you? I honestly had no such intention. If someone could point out what was offending about my questions please point it out so I can be more careful.
You said your goal is to make people think. Well I'm doing a lot of thinking and you're not helping.
In any case if there's anyone on the list that understands Tony's position then feel free to answer my questions. If no one does then I'll go on to my next question.

-------------------------------------
Tony Morris wrote:

Naftoli Gugenheim wrote:
> Please don't say I refuse to comprehend.
>
I will stop saying it on exactly one condition.
> If you can't explain implies except for in terms of a truth able (or more precisely a binary table) then either (1) you don't understand my question; (2) you happen to not have an answer; or (3) there is no answer, because this is not a concept that exists outside of mathematical jargon.
>
You're just making shit up.
> -------------------------------------
> Tony Morris wrote:
>
>
>
> Naftoli Gugenheim wrote:
>
>> You're missing my point.
>> The basis of your argument is that the definition of functions covers inheritance too.
>>
> No it isn't. I have repeated myself enough now and if you insist on
> misrepresenting what I say, then I suggest that we abort.
>
>> This is based on your cryptic usage of "implies."
>>
> There is nothing cryptic about my use of implies. The => syntax *means
> implies*. That is what it means. There is nothing cryptic here.
>
> Do you want me to explain implication? Sure.
>
> p q p->q
> 0 0 1
> 0 1 1
> 1 0 0
> 1 1 1
>
>
>
>> You refuse to elaborate because you can't be bother to copy-paste? Is that the depth of your understanding? You know how to point to a source or copy-paste it? If you understand it, you should be able to explain it concisely but clearly in about five sentences.
>>
>>
> That seems rather arbitrary. Did you pull that out of your arse? Why are
> you so averse to learning?
>
>> I won't respond to (2) because if you think about what I said you'll realize what I meant by bending over backward; and because it's secondary to this discussion.
>>
>>
> There is no discussion. You refuse to comprehend what I am saying. I am
> not sure why that is, but I suggest that due its consistency, you go no
> believing what you do, and I'll keep understanding what inheritance (and
> implication) is.
>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> 1. I'm assuming you claim to be a computer programmer. I truly can't be
>> expected to copy/paste reference material here.
>> 2. A JButton. I'm not bending over backwards at all; I'm demonstrating
>> quite emphatically, that inheritance is what I said it is, and
>> therefore, has nothing at all to do with code reuse. It's a very popular
>> myth that is spread via pop culture programming. Medusa didn't really
>> have snakes in her hair either.
>>
>> By the way, Either represents disjunction under C-H.
>> By the way, disjunction is inequivalent to implication.
>>
>> I might stop now, don't be afraid to learn!
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
>>> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> 1. I implore you read up on C-H, not because it is a diversion, but
>>> because it is one of many fundamental tenets of the skill that you claim
>>> to profess.
>>> 2. There are many possibilites. The point is that JButton implies
>>> JComponent and to get there you needn't call an explicit function, but
>>> an implicit one implicitly (ala inheritance)
>>>
>>> Here's one
>>>
>>> new JComponent() {
>>> // delegate
>>> }
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> You haven't answer any of my questions. I realized that was what you're proposing.
>>>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>>>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> Here's how it looks in Scala:
>>>>
>>>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>>>
>>>> That is all inheritance buys you (with some costs that are antithetical
>>>> to code reuse). If this is somehow "code reuse", then I guess we are
>>>> using very distinct definitions.
>>>>
>>>> I implore you to read up on C-H to understand why function signatures
>>>> using => logical implication.
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>>>
>>>>> What does "Int implies String" mean?
>>>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>>>> Your answer is, I think, that that difference has no ramification.
>>>>> Before I continue please correct any misunderstanding.
>>>>>
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> I've no idea what you mean by "putting code in functions and invoking
>>>>> them is a form of code reuse."
>>>>>
>>>>> I define code reuse along the same lines as that mentioned in Why
>>>>> Functional Programming Matters (John Hughes).
>>>>>
>>>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>>>> write Int => String, you are saying "Int implies String."
>>>>>
>>>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>>>> under certain domain values (empty list). But we write such a function
>>>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>>>> mean when you use inheritance. You talk of "views"; these are simply
>>>>> functions, they are not special, just functions. They might be
>>>>> *implicit* functions (or views), but that's precisely what inheritance
>>>>> is. When you say "Int => String", you are saying "Int inherits from
>>>>> String, with the exception that it is explicit." When you write an
>>>>> implicit function, you are using inheritance encoded differently (and
>>>>> often times, without certain costs that *inhibit* code reuse).
>>>>>
>>>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>>>> List with a maximum length of 1. It is also (for a typical
>>>>> implementation), an injection. This is an important part. Indeed, most
>>>>> programmers, knowingly or not, use inheritance when the implication is
>>>>> injective. It's not surjective though.
>>>>>
>>>>> That's all inheritance is. I realise that this may destroy a lot of
>>>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>>>> This also has nothing to do with code reuse. It never did. *pop*
>>>>>
>>>>> Naftoli Gugenheim wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>>>
>>>>>>
>>>>>>
>>>>>> -------------------------------------
>>>>>> Tony Morris wrote:
>>>>>>
>>>>>> I'm not talking in riddles at all. I have already stated that
>>>>>> inheritance is merely a function. We often think of it differently (to
>>>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>>>> it essentially means "implies", just like any other function. It is also
>>>>>> implicitly converted, unlike a typical function.
>>>>>>
>>>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>>>> example to the contrary. I'm well aware that few programmers know what
>>>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>>>
>>>>>> Show me an example.
>>>>>>
>>>>>> Naftoli Gugenheim wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------
>>>>>>> Tony Morris wrote:
>>>>>>>
>>>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>>>> code reuse again?
>>>>>>>
>>>>>>> Quenio dos Santos wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>>>> resolves some of the C++ issues.
>>>>>>>>
>>>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>>>> inheritance like in Java.
>>>>>>>>
>>>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>>>> implicit.
>>>>>>>>
>>>>>>>> Quenio dos Santos wrote:
>>>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>>>> traits.
>>>>>>>> >
>>>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>>>
>>>>>>>> > >> wrote:
>>>>>>>> >
>>>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>>>> good idea for
>>>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>>>> > inquiring minds.
>>>>>>>> >
>>>>>>>> > I intended only that inheritance is certainly not essential
>>>>>>>> for a
>>>>>>>> > "modern" programming language (which I assumed to be
>>>>>>>> synonymous with
>>>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>>>> may not
>>>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>>>> users
>>>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>>>> many examples
>>>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>>>> all the
>>>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>>>> into another
>>>>>>>> > debate!
>>>>>>>> >
>>>>>>>> > Quenio dos Santos wrote:
>>>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>>>> > which do
>>>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>>>> opinion. One
>>>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>>>> > >
>>>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>>>> Ordersky
>>>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>>>> feature in
>>>>>>>> > > Scala :)
>>>>>>>> > >
>>>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>>>> traits.
>>>>>>>> > >
>>>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > >
>>>>>>>> >>> wrote:
>>>>>>>> > >
>>>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>>>> > reaps the
>>>>>>>> > > benefits of having abandoned such a blatant type
>>>>>>>> system flaw.
>>>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>>>> > >
>>>>>>>> > > Quenio dos Santos wrote:
>>>>>>>> > > > Hello All,
>>>>>>>> > > >
>>>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>>>> > programming
>>>>>>>> > > > language from Google, which is been touted as the
>>>>>>>> new systems
>>>>>>>> > > language
>>>>>>>> > > > to replace C/C++.
>>>>>>>> > > >
>>>>>>>> > > > I have been exploring it, and although I found it
>>>>>>>> interesting
>>>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>>>> > it doesn't
>>>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>>>> > without
>>>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>>>> language.
>>>>>>>> > > >
>>>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>>>> > language if a
>>>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>>>> > crossed the
>>>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>>>> > > >
>>>>>>>> > > > - Quenio
>>>>>>>> > >
>>>>>>>> > > --
>>>>>>>> > > Tony Morris
>>>>>>>> > > http://tmorris.net/
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > Tony Morris
>>>>>>>> > http://tmorris.net/
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>> --
>>>>>>>> Tony Morris
>>>>>>>> http://tmorris.net/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

No, I am not offended. You have offended intellectual discourse if anything.

"You are making shit up" is standard nomenclature down under. It means
"you're pulling it out of your arse" or "you're inventing nonsense." I'm
not sure what an appropriate translation is, so I hope this is sufficient.

I'm not prepared to concede to your invented notions, simply because you
are too lazy to read up a bit. Implication is nothing more than a truth
table, which is precisely what I provided. C-H is all about types as
theorems. What did you think the => syntax means in any case?

See if you can get through this
http://en.wikibooks.org/wiki/Haskell/The_Curry-Howard_isomorphism

It covers implication (=> or scala.Function1), disjunction
(scala.Either), conjunction (scala.Tuple2) and falsity (scala.Nothing)
to name a few.

Naftoli Gugenheim wrote:
> Excuse me?
> Did I offend you? I honestly had no such intention. If someone could point out what was offending about my questions please point it out so I can be more careful.
> You said your goal is to make people think. Well I'm doing a lot of thinking and you're not helping.
> In any case if there's anyone on the list that understands Tony's position then feel free to answer my questions. If no one does then I'll go on to my next question.
>
>
>
> -------------------------------------
> Tony Morris wrote:
>
> Naftoli Gugenheim wrote:
>
>> Please don't say I refuse to comprehend.
>>
>>
> I will stop saying it on exactly one condition.
>
>> If you can't explain implies except for in terms of a truth able (or more precisely a binary table) then either (1) you don't understand my question; (2) you happen to not have an answer; or (3) there is no answer, because this is not a concept that exists outside of mathematical jargon.
>>
>>
> You're just making shit up.
>
>> -------------------------------------
>> Tony Morris wrote:
>>
>>
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> You're missing my point.
>>> The basis of your argument is that the definition of functions covers inheritance too.
>>>
>>>
>> No it isn't. I have repeated myself enough now and if you insist on
>> misrepresenting what I say, then I suggest that we abort.
>>
>>
>>> This is based on your cryptic usage of "implies."
>>>
>>>
>> There is nothing cryptic about my use of implies. The => syntax *means
>> implies*. That is what it means. There is nothing cryptic here.
>>
>> Do you want me to explain implication? Sure.
>>
>> p q p->q
>> 0 0 1
>> 0 1 1
>> 1 0 0
>> 1 1 1
>>
>>
>>
>>
>>> You refuse to elaborate because you can't be bother to copy-paste? Is that the depth of your understanding? You know how to point to a source or copy-paste it? If you understand it, you should be able to explain it concisely but clearly in about five sentences.
>>>
>>>
>>>
>> That seems rather arbitrary. Did you pull that out of your arse? Why are
>> you so averse to learning?
>>
>>
>>> I won't respond to (2) because if you think about what I said you'll realize what I meant by bending over backward; and because it's secondary to this discussion.
>>>
>>>
>>>
>> There is no discussion. You refuse to comprehend what I am saying. I am
>> not sure why that is, but I suggest that due its consistency, you go no
>> believing what you do, and I'll keep understanding what inheritance (and
>> implication) is.
>>
>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> 1. I'm assuming you claim to be a computer programmer. I truly can't be
>>> expected to copy/paste reference material here.
>>> 2. A JButton. I'm not bending over backwards at all; I'm demonstrating
>>> quite emphatically, that inheritance is what I said it is, and
>>> therefore, has nothing at all to do with code reuse. It's a very popular
>>> myth that is spread via pop culture programming. Medusa didn't really
>>> have snakes in her hair either.
>>>
>>> By the way, Either represents disjunction under C-H.
>>> By the way, disjunction is inequivalent to implication.
>>>
>>> I might stop now, don't be afraid to learn!
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
>>>> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> 1. I implore you read up on C-H, not because it is a diversion, but
>>>> because it is one of many fundamental tenets of the skill that you claim
>>>> to profess.
>>>> 2. There are many possibilites. The point is that JButton implies
>>>> JComponent and to get there you needn't call an explicit function, but
>>>> an implicit one implicitly (ala inheritance)
>>>>
>>>> Here's one
>>>>
>>>> new JComponent() {
>>>> // delegate
>>>> }
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> You haven't answer any of my questions. I realized that was what you're proposing.
>>>>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>>>>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> Here's how it looks in Scala:
>>>>>
>>>>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>>>>
>>>>> That is all inheritance buys you (with some costs that are antithetical
>>>>> to code reuse). If this is somehow "code reuse", then I guess we are
>>>>> using very distinct definitions.
>>>>>
>>>>> I implore you to read up on C-H to understand why function signatures
>>>>> using => logical implication.
>>>>>
>>>>> Naftoli Gugenheim wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>>>>
>>>>>> What does "Int implies String" mean?
>>>>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>>>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>>>>> Your answer is, I think, that that difference has no ramification.
>>>>>> Before I continue please correct any misunderstanding.
>>>>>>
>>>>>>
>>>>>> -------------------------------------
>>>>>> Tony Morris wrote:
>>>>>>
>>>>>> I've no idea what you mean by "putting code in functions and invoking
>>>>>> them is a form of code reuse."
>>>>>>
>>>>>> I define code reuse along the same lines as that mentioned in Why
>>>>>> Functional Programming Matters (John Hughes).
>>>>>>
>>>>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>>>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>>>>> write Int => String, you are saying "Int implies String."
>>>>>>
>>>>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>>>>> under certain domain values (empty list). But we write such a function
>>>>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>>>>> mean when you use inheritance. You talk of "views"; these are simply
>>>>>> functions, they are not special, just functions. They might be
>>>>>> *implicit* functions (or views), but that's precisely what inheritance
>>>>>> is. When you say "Int => String", you are saying "Int inherits from
>>>>>> String, with the exception that it is explicit." When you write an
>>>>>> implicit function, you are using inheritance encoded differently (and
>>>>>> often times, without certain costs that *inhibit* code reuse).
>>>>>>
>>>>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>>>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>>>>> List with a maximum length of 1. It is also (for a typical
>>>>>> implementation), an injection. This is an important part. Indeed, most
>>>>>> programmers, knowingly or not, use inheritance when the implication is
>>>>>> injective. It's not surjective though.
>>>>>>
>>>>>> That's all inheritance is. I realise that this may destroy a lot of
>>>>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>>>>> This also has nothing to do with code reuse. It never did. *pop*
>>>>>>
>>>>>> Naftoli Gugenheim wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------
>>>>>>> Tony Morris wrote:
>>>>>>>
>>>>>>> I'm not talking in riddles at all. I have already stated that
>>>>>>> inheritance is merely a function. We often think of it differently (to
>>>>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>>>>> it essentially means "implies", just like any other function. It is also
>>>>>>> implicitly converted, unlike a typical function.
>>>>>>>
>>>>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>>>>> example to the contrary. I'm well aware that few programmers know what
>>>>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>>>>
>>>>>>> Show me an example.
>>>>>>>
>>>>>>> Naftoli Gugenheim wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------
>>>>>>>> Tony Morris wrote:
>>>>>>>>
>>>>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>>>>> code reuse again?
>>>>>>>>
>>>>>>>> Quenio dos Santos wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>>>>> resolves some of the C++ issues.
>>>>>>>>>
>>>>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>>>>> inheritance like in Java.
>>>>>>>>>
>>>>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>>>>> implicit.
>>>>>>>>>
>>>>>>>>> Quenio dos Santos wrote:
>>>>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>>>>> traits.
>>>>>>>>> >
>>>>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>>>>
>>>>>>>>> > >> wrote:
>>>>>>>>> >
>>>>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>>>>> good idea for
>>>>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>>>>> > inquiring minds.
>>>>>>>>> >
>>>>>>>>> > I intended only that inheritance is certainly not essential
>>>>>>>>> for a
>>>>>>>>> > "modern" programming language (which I assumed to be
>>>>>>>>> synonymous with
>>>>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>>>>> may not
>>>>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>>>>> users
>>>>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>>>>> many examples
>>>>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>>>>> all the
>>>>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>>>>> into another
>>>>>>>>> > debate!
>>>>>>>>> >
>>>>>>>>> > Quenio dos Santos wrote:
>>>>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>>>>> > which do
>>>>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>>>>> opinion. One
>>>>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>>>>> > >
>>>>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>>>>> Ordersky
>>>>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>>>>> feature in
>>>>>>>>> > > Scala :)
>>>>>>>>> > >
>>>>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>>>>> traits.
>>>>>>>>> > >
>>>>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > >
>>>>>>>>> >>> wrote:
>>>>>>>>> > >
>>>>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>>>>> > reaps the
>>>>>>>>> > > benefits of having abandoned such a blatant type
>>>>>>>>> system flaw.
>>>>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>>>>> > >
>>>>>>>>> > > Quenio dos Santos wrote:
>>>>>>>>> > > > Hello All,
>>>>>>>>> > > >
>>>>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>>>>> > programming
>>>>>>>>> > > > language from Google, which is been touted as the
>>>>>>>>> new systems
>>>>>>>>> > > language
>>>>>>>>> > > > to replace C/C++.
>>>>>>>>> > > >
>>>>>>>>> > > > I have been exploring it, and although I found it
>>>>>>>>> interesting
>>>>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>>>>> > it doesn't
>>>>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>>>>> > without
>>>>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>>>>> language.
>>>>>>>>> > > >
>>>>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>>>>> > language if a
>>>>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>>>>> > crossed the
>>>>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>>>>> > > >
>>>>>>>>> > > > - Quenio
>>>>>>>>> > >
>>>>>>>>> > > --
>>>>>>>>> > > Tony Morris
>>>>>>>>> > > http://tmorris.net/
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> >
>>>>>>>>> > --
>>>>>>>>> > Tony Morris
>>>>>>>>> > http://tmorris.net/
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Tony Morris
>>>>>>>>> http://tmorris.net/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

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

I'm not sure what you mean "invented" notions. Why couldn't you just answer "(3)"?
If I say something as the result of a misunderstanding, instead of saying I'm intentionally obfuscating your intention, please give me the beneft of the doubt and help me out.
And when I said that I am currently not able to look it up and read through it, but I don't want to discuss the reason why not, I did not mean because I'm lazy. Hopefully when I will be able to I will look it up, but that may not be for a while.
Okay. So what you're saying is, that Int => String means that Int implies String, in the sense that there exists a truth table that says that we can get a String for any Int, and it's okay to not have a non-Int without a String and a String without an Int, but given an Int there's a String for it. And you're saying that the same "implies," or truth table, covers Car extends Vehicle. Am I reading you correctly so far?

-------------------------------------
Tony Morris wrote:

No, I am not offended. You have offended intellectual discourse if anything.

"You are making shit up" is standard nomenclature down under. It means
"you're pulling it out of your arse" or "you're inventing nonsense." I'm
not sure what an appropriate translation is, so I hope this is sufficient.

I'm not prepared to concede to your invented notions, simply because you
are too lazy to read up a bit. Implication is nothing more than a truth
table, which is precisely what I provided. C-H is all about types as
theorems. What did you think the => syntax means in any case?

See if you can get through this
http://en.wikibooks.org/wiki/Haskell/The_Curry-Howard_isomorphism

It covers implication (=> or scala.Function1), disjunction
(scala.Either), conjunction (scala.Tuple2) and falsity (scala.Nothing)
to name a few.

Naftoli Gugenheim wrote:
> Excuse me?
> Did I offend you? I honestly had no such intention. If someone could point out what was offending about my questions please point it out so I can be more careful.
> You said your goal is to make people think. Well I'm doing a lot of thinking and you're not helping.
> In any case if there's anyone on the list that understands Tony's position then feel free to answer my questions. If no one does then I'll go on to my next question.
>
>
>
> -------------------------------------
> Tony Morris wrote:
>
> Naftoli Gugenheim wrote:
>
>> Please don't say I refuse to comprehend.
>>
>>
> I will stop saying it on exactly one condition.
>
>> If you can't explain implies except for in terms of a truth able (or more precisely a binary table) then either (1) you don't understand my question; (2) you happen to not have an answer; or (3) there is no answer, because this is not a concept that exists outside of mathematical jargon.
>>
>>
> You're just making shit up.
>
>> -------------------------------------
>> Tony Morris wrote:
>>
>>
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> You're missing my point.
>>> The basis of your argument is that the definition of functions covers inheritance too.
>>>
>>>
>> No it isn't. I have repeated myself enough now and if you insist on
>> misrepresenting what I say, then I suggest that we abort.
>>
>>
>>> This is based on your cryptic usage of "implies."
>>>
>>>
>> There is nothing cryptic about my use of implies. The => syntax *means
>> implies*. That is what it means. There is nothing cryptic here.
>>
>> Do you want me to explain implication? Sure.
>>
>> p q p->q
>> 0 0 1
>> 0 1 1
>> 1 0 0
>> 1 1 1
>>
>>
>>
>>
>>> You refuse to elaborate because you can't be bother to copy-paste? Is that the depth of your understanding? You know how to point to a source or copy-paste it? If you understand it, you should be able to explain it concisely but clearly in about five sentences.
>>>
>>>
>>>
>> That seems rather arbitrary. Did you pull that out of your arse? Why are
>> you so averse to learning?
>>
>>
>>> I won't respond to (2) because if you think about what I said you'll realize what I meant by bending over backward; and because it's secondary to this discussion.
>>>
>>>
>>>
>> There is no discussion. You refuse to comprehend what I am saying. I am
>> not sure why that is, but I suggest that due its consistency, you go no
>> believing what you do, and I'll keep understanding what inheritance (and
>> implication) is.
>>
>>
>>> -------------------------------------
>>> Tony Morris wrote:
>>>
>>> 1. I'm assuming you claim to be a computer programmer. I truly can't be
>>> expected to copy/paste reference material here.
>>> 2. A JButton. I'm not bending over backwards at all; I'm demonstrating
>>> quite emphatically, that inheritance is what I said it is, and
>>> therefore, has nothing at all to do with code reuse. It's a very popular
>>> myth that is spread via pop culture programming. Medusa didn't really
>>> have snakes in her hair either.
>>>
>>> By the way, Either represents disjunction under C-H.
>>> By the way, disjunction is inequivalent to implication.
>>>
>>> I might stop now, don't be afraid to learn!
>>>
>>> Naftoli Gugenheim wrote:
>>>
>>>
>>>
>>>> 1. Which skill did I claim to have? The only thing I recall saying is that I have *not* studied functional theory, nor do I have time to. I would appreciate if you can give a concise, understandable explanation of "implies." This is the underpinning of your approach and you have not yet elaborated on it.
>>>> 2. This point is a practical (pragmatic?) one. Say you're delegating--what will you delegate to? A JComponent in a Map? Or will say getBounds look up the bounds in a Map? What is the key type of the Map? JComponent? JButton? A Set of types including both? Either? In all these cases you're bending over backward to model an intuitive concept: Is-a is more special than its questionable generalization, Can-be-seen-as; or if my assumption was incorrect, modify accordingly.
>>>>
>>>> -------------------------------------
>>>> Tony Morris wrote:
>>>>
>>>> 1. I implore you read up on C-H, not because it is a diversion, but
>>>> because it is one of many fundamental tenets of the skill that you claim
>>>> to profess.
>>>> 2. There are many possibilites. The point is that JButton implies
>>>> JComponent and to get there you needn't call an explicit function, but
>>>> an implicit one implicitly (ala inheritance)
>>>>
>>>> Here's one
>>>>
>>>> new JComponent() {
>>>> // delegate
>>>> }
>>>>
>>>> Naftoli Gugenheim wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> You haven't answer any of my questions. I realized that was what you're proposing.
>>>>> 1. Is my understanding of your usage of "implies" completely off base? I am not about to start researching this in depth; can you just give a concise answer? I assume you are quite capable.
>>>>> 2. What will you write instead of ... in real life? Return a new JComponent each time? No. Look it up in a Map as I said? Something else?
>>>>>
>>>>> -------------------------------------
>>>>> Tony Morris wrote:
>>>>>
>>>>> Here's how it looks in Scala:
>>>>>
>>>>> implicit def JButtonExtendsJComponent(b: JButton): JComponent = ...
>>>>>
>>>>> That is all inheritance buys you (with some costs that are antithetical
>>>>> to code reuse). If this is somehow "code reuse", then I guess we are
>>>>> using very distinct definitions.
>>>>>
>>>>> I implore you to read up on C-H to understand why function signatures
>>>>> using => logical implication.
>>>>>
>>>>> Naftoli Gugenheim wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> First let me say that I do not take offense when someone disagrees with me. (When someone speaks as though there's no room to see things different than him--right or wrong--is another thing.) What I do take offense with though is vocabulary that comes from the gutter.
>>>>>>
>>>>>> What does "Int implies String" mean?
>>>>>> I'm guessing it means "having an instance of Int implies that you can get a String corresponding to it as per the aforementioned function."
>>>>>> Now you may be able to accomplish the same thing as JButton exends JComponent by defining a function (e.g. a Map) that gets an object with a setBounds method corresponding to the button. But conceptually ("cognitively" according to psychologists) they're very different.
>>>>>> Your answer is, I think, that that difference has no ramification.
>>>>>> Before I continue please correct any misunderstanding.
>>>>>>
>>>>>>
>>>>>> -------------------------------------
>>>>>> Tony Morris wrote:
>>>>>>
>>>>>> I've no idea what you mean by "putting code in functions and invoking
>>>>>> them is a form of code reuse."
>>>>>>
>>>>>> I define code reuse along the same lines as that mentioned in Why
>>>>>> Functional Programming Matters (John Hughes).
>>>>>>
>>>>>> What do I mean by implies? You have surely seen this Scala syntax =>.
>>>>>> That is logical implication under the Curry-Howard Isomorphism. When you
>>>>>> write Int => String, you are saying "Int implies String."
>>>>>>
>>>>>> Here's a fun example List[A] => A. This is a lie! It fails to terminate
>>>>>> under certain domain values (empty list). But we write such a function
>>>>>> anyway (head). That's what I mean by implies and it's exactly what *you*
>>>>>> mean when you use inheritance. You talk of "views"; these are simply
>>>>>> functions, they are not special, just functions. They might be
>>>>>> *implicit* functions (or views), but that's precisely what inheritance
>>>>>> is. When you say "Int => String", you are saying "Int inherits from
>>>>>> String, with the exception that it is explicit." When you write an
>>>>>> implicit function, you are using inheritance encoded differently (and
>>>>>> often times, without certain costs that *inhibit* code reuse).
>>>>>>
>>>>>> Here's another example, Option[A] => List[A] (there is a reason I am
>>>>>> avoiding Iterable). This is a true statement. Indeed, Option is simply a
>>>>>> List with a maximum length of 1. It is also (for a typical
>>>>>> implementation), an injection. This is an important part. Indeed, most
>>>>>> programmers, knowingly or not, use inheritance when the implication is
>>>>>> injective. It's not surjective though.
>>>>>>
>>>>>> That's all inheritance is. I realise that this may destroy a lot of
>>>>>> fanciful dreams and may even cause offence, but I am just the messenger.
>>>>>> This also has nothing to do with code reuse. It never did. *pop*
>>>>>>
>>>>>> Naftoli Gugenheim wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> First of all, in some sense putting code in functions and invoking them is a form of code reuse. So it's certainly not less than that. Whether it's more may take some thought. How do _you_ define "code reuse"?
>>>>>>> What do you mean by "implies"? I have not formally studied functional theory. But one of the most basic functions is sine. Where does "implies" fit in there?
>>>>>>> And implicit functions provide a view, so an Option can be seen as if it were an Iterable. So you seem to be saying that Some's relationship to Iterable is in the same class as its relationship to Option. You say that pointing one arrow upward and one sideways is meaningless from a mathematical perspective; our tendency to differentiate is "merely" cognitive. As if science is more authentic than conciousness. To me this smacks of the same evolutionism that led to mass removal of tonsils not too long ago.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------
>>>>>>> Tony Morris wrote:
>>>>>>>
>>>>>>> I'm not talking in riddles at all. I have already stated that
>>>>>>> inheritance is merely a function. We often think of it differently (to
>>>>>>> our detriment?) -- an arrow pointing upward instead of right-ward, but
>>>>>>> it essentially means "implies", just like any other function. It is also
>>>>>>> implicitly converted, unlike a typical function.
>>>>>>>
>>>>>>> I fail to see how any of this constitutes code reuse. I am awaiting an
>>>>>>> example to the contrary. I'm well aware that few programmers know what
>>>>>>> code reuse means, and I'm most aware of marketing slogans that tout
>>>>>>> inheritance as correlated to code reuse, but I remain optimistic.
>>>>>>>
>>>>>>> Show me an example.
>>>>>>>
>>>>>>> Naftoli Gugenheim wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Instead of talking in riddles and waiting for someone to give a typical example of what people call code reuse and you obviously don't, why don't you come out with your point? You know full well what people call code reuse.
>>>>>>>> I know, you're trying to get us to think. Another word for it is teasing. But probably not in the mathematical definition of reality.
>>>>>>>>
>>>>>>>>
>>>>>>>> -------------------------------------
>>>>>>>> Tony Morris wrote:
>>>>>>>>
>>>>>>>> No certainly not. I mean inheritance, just like you do. So, where's the
>>>>>>>> code reuse again?
>>>>>>>>
>>>>>>>> Quenio dos Santos wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Traits are just a clever way of doing multiple inheritance, which
>>>>>>>>> allows mixing without some of the issues you would find in C++. It is
>>>>>>>>> not much different from multiple inheritance in Eiffel, which also
>>>>>>>>> resolves some of the C++ issues.
>>>>>>>>>
>>>>>>>>> I think when you say inheritance, you really mean traditional single
>>>>>>>>> inheritance like in Java.
>>>>>>>>>
>>>>>>>>> On Sun, Nov 15, 2009 at 3:17 AM, Tony Morris >>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>> Scala without traits would be unthinkable! Inheritance is an expensive
>>>>>>>>> implicit.
>>>>>>>>>
>>>>>>>>> Quenio dos Santos wrote:
>>>>>>>>> > I may be completely be missing your point here, but I cannot imagine
>>>>>>>>> > Scala without traits. Maybe, without single inheritance, but not
>>>>>>>>> traits.
>>>>>>>>> >
>>>>>>>>> > On Sun, Nov 15, 2009 at 2:52 AM, Tony Morris
>>>>>>>>>
>>>>>>>>> > >> wrote:
>>>>>>>>> >
>>>>>>>>> > I didn't mean to imply that absence of inheritance was a
>>>>>>>>> good idea for
>>>>>>>>> > Go. I listed my opinion on Go a few days ago in private to other
>>>>>>>>> > inquiring minds.
>>>>>>>>> >
>>>>>>>>> > I intended only that inheritance is certainly not essential
>>>>>>>>> for a
>>>>>>>>> > "modern" programming language (which I assumed to be
>>>>>>>>> synonymous with
>>>>>>>>> > "practical") and is indeed, rather antithetical. One may or
>>>>>>>>> may not
>>>>>>>>> > agree, but it's quite easy to solidly argue the fact. Scala
>>>>>>>>> users
>>>>>>>>> > ultimately suffer as a result (see the mailing lists for
>>>>>>>>> many examples
>>>>>>>>> > with new ones regularly arriving). Thankfully Oleg has done
>>>>>>>>> all the
>>>>>>>>> > arguing for me so I best not be too loud lest I be coaxed
>>>>>>>>> into another
>>>>>>>>> > debate!
>>>>>>>>> >
>>>>>>>>> > Quenio dos Santos wrote:
>>>>>>>>> > > Go has neither inheritance nor sub-typing. It has interfaces,
>>>>>>>>> > which do
>>>>>>>>> > > provide sub-typing on some level, but are limited in my
>>>>>>>>> opinion. One
>>>>>>>>> > > interface cannot sub-type another interface, for example.
>>>>>>>>> > >
>>>>>>>>> > > As far as inheritance being a flaw, I don't think Martin
>>>>>>>>> Ordersky
>>>>>>>>> > > would agree with you. Otherwise, he wouldn't have put the
>>>>>>>>> feature in
>>>>>>>>> > > Scala :)
>>>>>>>>> > >
>>>>>>>>> > > Scala not only adopted inheritance but enhanced it with
>>>>>>>>> traits.
>>>>>>>>> > >
>>>>>>>>> > > On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > >
>>>>>>>>> >>> wrote:
>>>>>>>>> > >
>>>>>>>>> > > Haskell does away with inheritance just fine. Indeed, it
>>>>>>>>> > reaps the
>>>>>>>>> > > benefits of having abandoned such a blatant type
>>>>>>>>> system flaw.
>>>>>>>>> > > http://okmij.org/ftp/Computation/Subtyping/
>>>>>>>>> > >
>>>>>>>>> > > Quenio dos Santos wrote:
>>>>>>>>> > > > Hello All,
>>>>>>>>> > > >
>>>>>>>>> > > > I don't know if you have heard the buzz about the new Go
>>>>>>>>> > programming
>>>>>>>>> > > > language from Google, which is been touted as the
>>>>>>>>> new systems
>>>>>>>>> > > language
>>>>>>>>> > > > to replace C/C++.
>>>>>>>>> > > >
>>>>>>>>> > > > I have been exploring it, and although I found it
>>>>>>>>> interesting
>>>>>>>>> > > > initially, now I am not so impressed. Just for starters,
>>>>>>>>> > it doesn't
>>>>>>>>> > > > support sub-typing. I can't really see how can you live
>>>>>>>>> > without
>>>>>>>>> > > > sub-typing and inheritance in a modern programming
>>>>>>>>> language.
>>>>>>>>> > > >
>>>>>>>>> > > > I honestly believe that Scala would be a great systems
>>>>>>>>> > language if a
>>>>>>>>> > > > native compiler was available for Scala. Has that ever
>>>>>>>>> > crossed the
>>>>>>>>> > > > mind of the Scala development team, or anybody else?
>>>>>>>>> > > >
>>>>>>>>> > > > - Quenio
>>>>>>>>> > >
>>>>>>>>> > > --
>>>>>>>>> > > Tony Morris
>>>>>>>>> > > http://tmorris.net/
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> >
>>>>>>>>> > --
>>>>>>>>> > Tony Morris
>>>>>>>>> > http://tmorris.net/
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Tony Morris
>>>>>>>>> http://tmorris.net/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: Native Compiler for Scala
You really should read at least one of Tony's links since Tony seems uninterested in explaining the logical consequences of truth tables and inheritance himself.  You can get a reasonably clear explanation from this article he linked to; you should find something useful within about the first page:
  http://apocalisp.wordpress.com/2009/08/27/hostility-toward-subtyping/

If you don't have access to a web browser, and what I say below isn't enough, I'll post the text of that link to you off list (if you ask).

The basic idea behind preferring functions to inheritance is as follows:
  When you say "B extends A", you are saying that any time you have a B, you could use it where you could use an A.  Well, you could do the very same thing if you had a function b2a(b:B):A, couldn't you!  And b2a could do fancier things than inheritance, if you so desired!

Yes, quite true.  Likewise, BigDecimal can be used to represent Byte values.  But this does not make it wise from a pragmatic standpoint to throw away Byte and use only BigDecimal.

The problem with function conversion is that functions--pure functions anyway--are supposed to be side-effect free.  This means that b2a has to construct an entirely new object a, instead of simply using the same object b but treating it as an a, as happens when B extends A.

So you start off with a guaranteed penalty of one extra object creation, either paid on every call to b2a, or once each time one creates a b (you create its corresponding a also).  (Yes, you can do clever things with lazy vals to get a hybrid of these two.)

If this extra memory usage (and the extra function call) is okay, then there are some handy patterns you can use, like so:

  class B(val a:A) {
    def doSomethingNew = // something new done to A
  }
  implicit def b2a(b:B) = b.a

instead of

  class B(/* A's params */) extends A(/* A's params again */) {
    def doSomethingNew = // Something new done with A's data
  }

The former looks pretty good, except now object creation is a pain
  val b = new B( new A(/* A's params */) )

so now you're tempted to write alternate constructors:
  class B(val a:A) {
    def this(/* A's params */) = new B(new A(/*A's params*/))
    def doSomethingNew = // something new done to A
  }
  implicit def b2a(b:B) = b.a

which means you have more to write than before as well as needing an extra object creation.

And then you have issues of chaining:
  class C(/*params*/) extends B(/*params*/) {
    def niftyMethod = // something
  }
Pretty straightforward, but now
  class C(val b:B) {
    def this(/*B's params*/) = new C(new B(/*B's params*/))
    def niftyMethod = // something
  }
  implicit def c2b(c:C) = c.b
  implicit def c2a(c:C) = b2a( c2b(c) )
Uh-oh.  We've now had to create two conversion functions in order to get back to A from C.

And we probably don't want to let the compiler apply as many implicit conversions as it possibly can, since in a complex project it would be very difficult to reason about exactly what the compiler would do (plus there would be explosions of possibilities, worries about loops, etc. etc.).  The one-implicit-only rule of Scala is quite sensible.

Anyway, hopefully it's now clearer that
  * Yes, implicit functions can substitute for subclassing
  * Yes, implicit functions are even more powerful than subclassing
  * No, implicit functions are not as high-performance as subclassing
  * No, they're not easier to use when it comes to more complex hierarchies

I'm ignoring for the moment the issue of overriding methods.  That's more complicated, but one basic way to do that is to make A's methods be vals assigned to functions, and set defaults in A, but when constructing it from B, assign the val to different functions.  (Again, this tends to be more flexible, lower performance, and more of a hassle.)

It is worth keeping in mind that these things can be done, so that one can evaluate for any particular piece of code whether inheritance is *really* the best way to abstract the problem or whether a more functional method (as above) is superior.

  --Rex




On Mon, Nov 16, 2009 at 7:31 PM, Naftoli Gugenheim <naftoligug [at] gmail [dot] com> wrote:
I'm not sure what you mean "invented" notions. Why couldn't you just answer "(3)"?
If I say something as the result of a misunderstanding, instead of saying I'm intentionally obfuscating your intention, please give me the beneft of the doubt and help me out.
And when I said that I am currently not able to look it up and read through it, but I don't want to discuss the reason why not, I did not mean because I'm lazy. Hopefully when I will be able to I will look it up, but that may not be for a while.
Okay. So what you're saying is, that Int => String means that Int implies String, in the sense that there exists a truth table that says that we can get a String for any Int, and it's okay to not have a non-Int without a String and a String without an Int, but given an Int there's a String for it. And you're saying that the same "implies," or truth table, covers Car extends Vehicle. Am I reading you correctly so far?


Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

> Anyway, hopefully it's now clearer that
> * Yes, implicit functions can substitute for subclassing
> * Yes, implicit functions are even more powerful than subclassing
> * No, implicit functions are not as high-performance as subclassing
> * No, they're not easier to use when it comes to more complex
> hierarchies
These last two are only true for Scala. The original discussion mentions
type-classes, which are almost conceptually equivalent, but have better
implementations in other languages, particularly Haskell for which
inheritance is simply not possible, which is a good thing for code reuse
and its users reap the benefit.

I think it is fair to conclude: Inheritance has nothing to do with code
reuse, except perhaps that it hinders it for many cases.

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: Native Compiler for Scala
On Mon, Nov 16, 2009 at 8:18 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:

> Anyway, hopefully it's now clearer that
>   * Yes, implicit functions can substitute for subclassing
>   * Yes, implicit functions are even more powerful than subclassing
>   * No, implicit functions are not as high-performance as subclassing
>   * No, they're not easier to use when it comes to more complex
> hierarchies
These last two are only true for Scala.

Can you provide--again, if you already did--the reference that shows that you can use implicit functions to mimic inheritance with as little overhead as an invokevirtual (compared to invokestatic) in the JVM?  That's the standard for performance.

I've also lost track of what "the original discussion" was.  Did you refer to or directly explain something that explains how type classes can be used to gain all the benefits of inheritance without any extra overhead?

  --Rex

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Rex Kerr wrote:
> On Mon, Nov 16, 2009 at 8:18 PM, Tony Morris > wrote:
>
>
> > Anyway, hopefully it's now clearer that
> > * Yes, implicit functions can substitute for subclassing
> > * Yes, implicit functions are even more powerful than subclassing
> > * No, implicit functions are not as high-performance as
> subclassing
> > * No, they're not easier to use when it comes to more complex
> > hierarchies
> These last two are only true for Scala.
>
>
> Can you provide--again, if you already did--the reference that shows
> that you can use implicit functions to mimic inheritance with as
> little overhead as an invokevirtual (compared to invokestatic) in the
> JVM? That's the standard for performance.
I didn't. Implicit functions as they are implemented in Scala and I
expect any JVM language, will always incur this penalty. It raises the
interesting question of how CAL implements type-classes on the JVM. I
can guess off the top of my head.
>
> I've also lost track of what "the original discussion" was. Did you
> refer to or directly explain something that explains how type classes
> can be used to gain all the benefits of inheritance without any extra
> overhead?
The original discussion asserted that inheritance provides code reuse. I
called shenanigans asked for an example, which was not forthcoming. Then
I asserted the anti-thesis; inheritance hinders code reuse. Since an
example of the contrary position (to mine) was not forthcoming, other
defenses have been mounted, but none have succeeded that I have seen,
which brought us into the relationship between implicits, type-classes
and inheritance. My intent has been to show why an example was not
provided -- because no such thing exists -- and that inheritance is
indeed, somewhere between neutral (i.e. inheritance ~= implicits, so
what's that to do with code reuse?) and a hindrance to code reuse
(Kiselyov).

>
> --Rex
>

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: Native Compiler for Scala

On Mon, Nov 16, 2009 at 8:38 PM, Tony Morris wrote:
>
> Rex Kerr wrote:
>> Can you provide--again, if you already did--the reference that shows
>> that you can use implicit functions to mimic inheritance with as
>> little overhead as an invokevirtual (compared to invokestatic) in the
>> JVM?  That's the standard for performance.
> I didn't. Implicit functions as they are implemented in Scala and I
> expect any JVM language, will always incur this penalty. It raises the
> interesting question of how CAL implements type-classes on the JVM. I
> can guess off the top of my head.

Let me rephrase the question. With a budget of one extra pointer
dereference for virtual methods and zero for static methods, how can
one replace an arbitrarily complex type hierarchy with implicit
functions without having to write a lot of boilerplate conversion
code?

> The original discussion asserted that inheritance provides code reuse. I
> called shenanigans asked for an example, which was not forthcoming.
> . . .
> My intent has been to show why an example was not
> provided -- because no such thing exists

Okay, here's an example of such a thing existing:

abstract class Scalar {
def x:Int
def create(x0:Int):Scalar
def +(s:Scalar) = create(x+s.x)
// Lots more math goes here
}
class ImmutableScalar(val x:Int) extends Scalar {
def create(x0:Int):Scalar = new ImmutableScalar(x0)
}
class StringScalar(val s:String) extends Scalar {
def x = s.toInt
def create(x0:Int):Scalar = new StringScalar(x0.toString)
}
abstract class UpdatingScalar extends Scalar {
def x_=(x0:Int):Unit
def +=(s:Scalar):Unit = (x = x+s.x)
// Lots more math
}
class MutableScalar(var x:Int) extends Scalar {
def create(x0:Int):Scalar = new MutableScalar(x0)
}
class StringBufferScalar(val sb:StringBuffer) extends Scalar {
// Surely you can guess by now
}

There we go: code reuse of a pile of mathematical symbols. You can
use Scalar just like you would Int, regardless of whether it's
implemented as an Immutable, String, Mutable, or StringBuffer version.
I didn't check if any of it compiled; fixing syntax errors is left as
an exercise to the reader. I write math once, and get the + - * etc.
versions three times for free, and the += -= etc. versions once for
free. I have a tiny bit of extra boilerplate to write each time to
get that (just the create, and sometimes the getter/setters).

Now, how would I do even as well with implicits?

--Rex

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

I need one example, just one, of inheritance leading to code reuse.

Quenio dos Santos wrote:
> How many frameworks have to be implemented in how many OO languages
> for you to accept that one can use inheritance to reuse code?
>
> Quenio
>
> On Nov 16, 2009, at 7:38 PM, Tony Morris wrote:
>
>
>> Rex Kerr wrote:
>>
>>> On Mon, Nov 16, 2009 at 8:18 PM, Tony Morris >> > wrote:
>>>
>>>
>>>
>>>> Anyway, hopefully it's now clearer that
>>>> * Yes, implicit functions can substitute for subclassing
>>>> * Yes, implicit functions are even more powerful than subclassing
>>>> * No, implicit functions are not as high-performance as
>>>>
>>> subclassing
>>>
>>>> * No, they're not easier to use when it comes to more complex
>>>> hierarchies
>>>>
>>> These last two are only true for Scala.
>>>
>>>
>>> Can you provide--again, if you already did--the reference that shows
>>> that you can use implicit functions to mimic inheritance with as
>>> little overhead as an invokevirtual (compared to invokestatic) in the
>>> JVM? That's the standard for performance.
>>>
>> I didn't. Implicit functions as they are implemented in Scala and I
>> expect any JVM language, will always incur this penalty. It raises the
>> interesting question of how CAL implements type-classes on the JVM. I
>> can guess off the top of my head.
>>
>>> I've also lost track of what "the original discussion" was. Did you
>>> refer to or directly explain something that explains how type classes
>>> can be used to gain all the benefits of inheritance without any extra
>>> overhead?
>>>
>> The original discussion asserted that inheritance provides code
>> reuse. I
>> called shenanigans asked for an example, which was not forthcoming.
>> Then
>> I asserted the anti-thesis; inheritance hinders code reuse. Since an
>> example of the contrary position (to mine) was not forthcoming, other
>> defenses have been mounted, but none have succeeded that I have seen,
>> which brought us into the relationship between implicits, type-classes
>> and inheritance. My intent has been to show why an example was not
>> provided -- because no such thing exists -- and that inheritance is
>> indeed, somewhere between neutral (i.e. inheritance ~= implicits, so
>> what's that to do with code reuse?) and a hindrance to code reuse
>> (Kiselyov).
>>
>>
>>> --Rex
>>>
>>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>
>

Quenio dos Santos
Joined: 2009-11-15,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

How many frameworks have to be implemented in how many OO languages
for you to accept that one can use inheritance to reuse code?

Quenio

On Nov 16, 2009, at 7:38 PM, Tony Morris wrote:

>
>
> Rex Kerr wrote:
>> On Mon, Nov 16, 2009 at 8:18 PM, Tony Morris > > wrote:
>>
>>
>>> Anyway, hopefully it's now clearer that
>>> * Yes, implicit functions can substitute for subclassing
>>> * Yes, implicit functions are even more powerful than subclassing
>>> * No, implicit functions are not as high-performance as
>> subclassing
>>> * No, they're not easier to use when it comes to more complex
>>> hierarchies
>> These last two are only true for Scala.
>>
>>
>> Can you provide--again, if you already did--the reference that shows
>> that you can use implicit functions to mimic inheritance with as
>> little overhead as an invokevirtual (compared to invokestatic) in the
>> JVM? That's the standard for performance.
> I didn't. Implicit functions as they are implemented in Scala and I
> expect any JVM language, will always incur this penalty. It raises the
> interesting question of how CAL implements type-classes on the JVM. I
> can guess off the top of my head.
>>
>> I've also lost track of what "the original discussion" was. Did you
>> refer to or directly explain something that explains how type classes
>> can be used to gain all the benefits of inheritance without any extra
>> overhead?
> The original discussion asserted that inheritance provides code
> reuse. I
> called shenanigans asked for an example, which was not forthcoming.
> Then
> I asserted the anti-thesis; inheritance hinders code reuse. Since an
> example of the contrary position (to mine) was not forthcoming, other
> defenses have been mounted, but none have succeeded that I have seen,
> which brought us into the relationship between implicits, type-classes
> and inheritance. My intent has been to show why an example was not
> provided -- because no such thing exists -- and that inheritance is
> indeed, somewhere between neutral (i.e. inheritance ~= implicits, so
> what's that to do with code reuse?) and a hindrance to code reuse
> (Kiselyov).
>
>>
>> --Rex
>>
>
> --
> Tony Morris
> http://tmorris.net/
>
>

Randall R Schulz
Joined: 2008-12-16,
User offline. Last seen 1 year 29 weeks ago.
Re: Native Compiler for Scala

On Monday November 16 2009, Tony Morris wrote:
> I need one example, just one, of inheritance leading to code reuse.

I believe people view methods inherited by a subclass from its
superclass(es) to be code reused by that subclass.

Randall Schulz

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

Maybe I should have been more explicit, but if you were referring to me I was not discussing code reuse (except for when I mentioned it). My questions did not mean more than they said.

-------------------------------------
Tony Morris wrote:

Rex Kerr wrote:
> On Mon, Nov 16, 2009 at 8:18 PM, Tony Morris > wrote:
>
>
> > Anyway, hopefully it's now clearer that
> > * Yes, implicit functions can substitute for subclassing
> > * Yes, implicit functions are even more powerful than subclassing
> > * No, implicit functions are not as high-performance as
> subclassing
> > * No, they're not easier to use when it comes to more complex
> > hierarchies
> These last two are only true for Scala.
>
>
> Can you provide--again, if you already did--the reference that shows
> that you can use implicit functions to mimic inheritance with as
> little overhead as an invokevirtual (compared to invokestatic) in the
> JVM? That's the standard for performance.
I didn't. Implicit functions as they are implemented in Scala and I
expect any JVM language, will always incur this penalty. It raises the
interesting question of how CAL implements type-classes on the JVM. I
can guess off the top of my head.
>
> I've also lost track of what "the original discussion" was. Did you
> refer to or directly explain something that explains how type classes
> can be used to gain all the benefits of inheritance without any extra
> overhead?
The original discussion asserted that inheritance provides code reuse. I
called shenanigans asked for an example, which was not forthcoming. Then
I asserted the anti-thesis; inheritance hinders code reuse. Since an
example of the contrary position (to mine) was not forthcoming, other
defenses have been mounted, but none have succeeded that I have seen,
which brought us into the relationship between implicits, type-classes
and inheritance. My intent has been to show why an example was not
provided -- because no such thing exists -- and that inheritance is
indeed, somewhere between neutral (i.e. inheritance ~= implicits, so
what's that to do with code reuse?) and a hindrance to code reuse
(Kiselyov).

>
> --Rex
>

matthw
Joined: 2009-08-23,
User offline. Last seen 3 years 9 weeks ago.
Re: Native Compiler for Scala

> Scala.
> Note that Scala's implicit is extremely similar (with some minor
> notable
> differences) to Haskell's type-classes, which as you say replaces
> inheritance. I shall say no more :)

I'm not convinced scala's implicits are quite up to the task of
replacing inheritance yet. For example there's

- The transitivity issue you mention
- More generally the problem of finding a good place to limit
inference of implicits - too weak and you can't do everything a good
inheritance model can do, too strong and you might open the doors to a
combinatorial explosion of possible inferences that are hard to reason
about and easy to inadvertently disturb
- Object identity semantics and state become confusing and
unreliable when you're silently creating new, separate implicit
objects for different aspects of semantically the "same thing" (yes, I
realise the answer is probably "don't use mutable state, don't use
object identity", but it's not always as simple as that - if it were,
why not just use Haskell?)
- Lots of redundant object allocations going on, whether on the heap
or on the stack
- Somewhat tricky / ever-so-slightly-arbitrary-seeming scoping rules
- The ability of changes to the implicits in scope to have cross-
cutting non-local consequences which may not always be obvious
- No support for autocomplete or reflection on available-via-
implicits methods
- In general the way implicits feel a bit ad-hoc in their semantics
compared with haskell's typeclasses, which (IIRC) have a more elegant
formal basis
- Seems there are a bunch of design patterns which emerge when you
try to use implicits to structure code; the language should do more to
capture these if it intends implicits to be the primary tool of code
reuse.

That said they still prove pretty damn useful as a power tool to be
used with caution to smooth some of the rough edges on an API in scala
(your own or someone else's). And it seems like a lot of the downsides
could be fixed in a new language.

So, I hope that as the scala community gains more experience of the
tradeoffs and peculiarities of implicits, it'll provide a good
starting point for an OO language designed from the outset to be
inheritance-free, with a more elegant implicit system fine-tuned with
feedback after OO developers start trying to use the implicits
approach for their day-to-day work.

Would be really interested to see an attempt at something like this,
even just outlines of a proposed spec.

> See Scalaz for an example of using implicit instead of inheritance,
> with
> some exceptions.

About scalaz: My feeling is that it's an amazing proof of concept, but
most of the time, if I wanted to take that kind of approach I'd use
Haskell. Also while it serves to illustrate the implicits approach, it
does so more in the setting of high-level algebraic abstractions than
the kind of examples that might prove accessible to OO-ers unversed in
category theory.

Cheers
-Matt

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

I expect that too, but I am hoping otherwise. *crosses fingers*

Randall R Schulz wrote:
> On Monday November 16 2009, Tony Morris wrote:
>
>> I need one example, just one, of inheritance leading to code reuse.
>>
>
> I believe people view methods inherited by a subclass from its
> superclass(es) to be code reused by that subclass.
>
>
> Randall Schulz
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Hi Matthew

Matthew Willson wrote:
>> Scala.
>> Note that Scala's implicit is extremely similar (with some minor notable
>> differences) to Haskell's type-classes, which as you say replaces
>> inheritance. I shall say no more :)
>
> I'm not convinced scala's implicits are quite up to the task of
> replacing inheritance yet. For example there's
>
> - The transitivity issue you mention
> - More generally the problem of finding a good place to limit
> inference of implicits - too weak and you can't do everything a good
> inheritance model can do, too strong and you might open the doors to a
> combinatorial explosion of possible inferences that are hard to reason
> about and easy to inadvertently disturb
This only affects Scala specifically.
> - Object identity semantics and state become confusing and unreliable
> when you're silently creating new, separate implicit objects for
> different aspects of semantically the "same thing" (yes, I realise the
> answer is probably "don't use mutable state, don't use object
> identity", but it's not always as simple as that - if it were, why not
> just use Haskell?)
You guessed the answer right :) If you're going to do silly things,
expect the penalty.
> - Lots of redundant object allocations going on, whether on the heap
> or on the stack
This is a limitation of Scala's compiler. Consider Haskell's newtype
keyword for which there is no penalty.
> - Somewhat tricky / ever-so-slightly-arbitrary-seeming scoping rules
> - The ability of changes to the implicits in scope to have
> cross-cutting non-local consequences which may not always be obvious
Controlling the scope versus having no control? I know which I prefer.
> - No support for autocomplete or reflection on
> available-via-implicits methods
Why not?
> - In general the way implicits feel a bit ad-hoc in their semantics
> compared with haskell's typeclasses, which (IIRC) have a more elegant
> formal basis
There is no practical difference between:

1) newtype Eq a = Eq { eq :: a -> a -> Bool }
2) class Eq where
eq :: a -> a -> Bool
3) case class Eq[-A](eq: (A, A) => Boolean)

Except for the obvious: the Scala Eq may or not be passed implicitly
i.e. interchangeable between implicit/explicit, where 1) and 2) are
distinguishable constructs altogether (the former being always explicit
and the latter always implicit)

> - Seems there are a bunch of design patterns which emerge when you
> try to use implicits to structure code; the language should do more to
> capture these if it intends implicits to be the primary tool of code
> reuse.
See Scalaz.
>
> That said they still prove pretty damn useful as a power tool to be
> used with caution to smooth some of the rough edges on an API in scala
> (your own or someone else's). And it seems like a lot of the downsides
> could be fixed in a new language.
This is true. Haskell once had implicit arguments.
>
> So, I hope that as the scala community gains more experience of the
> tradeoffs and peculiarities of implicits, it'll provide a good
> starting point for an OO language designed from the outset to be
> inheritance-free, with a more elegant implicit system fine-tuned with
> feedback after OO developers start trying to use the implicits
> approach for their day-to-day work.
You'll upset a lot of people by pulling inheritance out -- pop culture
programming thinks it is related to code reuse after all!
>
> Would be really interested to see an attempt at something like this,
> even just outlines of a proposed spec.
>
>> See Scalaz for an example of using implicit instead of inheritance, with
>> some exceptions.
>
> About scalaz: My feeling is that it's an amazing proof of concept, but
> most of the time, if I wanted to take that kind of approach I'd use
> Haskell. Also while it serves to illustrate the implicits approach, it
> does so more in the setting of high-level algebraic abstractions than
> the kind of examples that might prove accessible to OO-ers unversed in
> category theory.
Scalaz is used in many commercial settings. What approach? A practical
one without all that repetition?

Programming is hard, it always has been. I don't pretend otherwise,
neither does Scalaz. Category theory is hardly necessary to use Scalaz
effectively as I am sure many people will testify.

>
> Cheers
> -Matt
>

Cheers Matt!

ichoran
Joined: 2009-08-14,
User offline. Last seen 2 years 3 weeks ago.
Re: Native Compiler for Scala
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


On Mon, Nov 16, 2009 at 9:27 PM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
I expect that too, but I am hoping otherwise. *crosses fingers*

Randall R Schulz wrote:
> On Monday November 16 2009, Tony Morris wrote:
>
>> I need one example, just one, of inheritance leading to code reuse.
>>
>
> I believe people view methods inherited by a subclass from its
> superclass(es) to be code reused by that subclass.
>
>
> Randall Schulz
>
>

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



matthw
Joined: 2009-08-23,
User offline. Last seen 3 years 9 weeks ago.
Re: Native Compiler for Scala

>> - More generally the problem of finding a good place to limit
>> inference of implicits - too weak and you can't do everything a good
>> inheritance model can do, too strong and you might open the doors
>> to a
>> combinatorial explosion of possible inferences that are hard to
>> reason
>> about and easy to inadvertently disturb
> This only affects Scala specifically.

Seems like a wider issue to me. eg Haskell hasn't quite made its mind
up on where to limit inference with typeclasses, with -
XFlexibleInstances, -XUndecidableInstances, -fallow-overlapping-
instances etc

>> - Object identity semantics and state become confusing and unreliable
>> when you're silently creating new, separate implicit objects for
>> different aspects of semantically the "same thing" (yes, I realise
>> the
>> answer is probably "don't use mutable state, don't use object
>> identity", but it's not always as simple as that - if it were, why
>> not
>> just use Haskell?)
> You guessed the answer right :) If you're going to do silly things,
> expect the penalty.

Personally I like scala's pragmatic but informed attitude to mutation.
If I wanted a pure functional language, I'd use Haskell, which (IMO)
does it better.

>> So, I hope that as the scala community gains more experience of the
>> tradeoffs and peculiarities of implicits, it'll provide a good
>> starting point for an OO language designed from the outset to be
>> inheritance-free, with a more elegant implicit system fine-tuned with
>> feedback after OO developers start trying to use the implicits
>> approach for their day-to-day work.
> You'll upset a lot of people by pulling inheritance out -- pop culture
> programming thinks it is related to code reuse after all!

I haven't made my mind up on the issue - in part because of the lack
of such a language to test these ideas in practise (as explained,
scala hasn't yet persuaded me either way). But I'm interested in the
idea, and in having an enlightening exploration of the various trade-
offs involved in a complicated language design issue. Doesn't seem
like a clear-cut issue.

I was trying to stay out of the code re-use debate, because I think
it's about semantics (of 'code re-use') not substance, and hence
rather tiresome.

>> About scalaz: My feeling is that it's an amazing proof of concept,
>> but
>> most of the time, if I wanted to take that kind of approach I'd use
>> Haskell. Also while it serves to illustrate the implicits approach,
>> it
>> does so more in the setting of high-level algebraic abstractions than
>> the kind of examples that might prove accessible to OO-ers unversed
>> in
>> category theory.
> Scalaz is used in many commercial settings. What approach? A practical
> one without all that repetition?
>
> Programming is hard, it always has been. I don't pretend otherwise,
> neither does Scalaz. Category theory is hardly necessary to use Scalaz
> effectively as I am sure many people will testify.

Fair enough - I can see the appeal of pushing scala to its limits in
this way, and if you're working with people who're on the same level
as you, great!

But while programming is hard, making it this hard (for example, from
scalaz.http.scapps, a web framework)

implicit def OptionKleisliSemigroup[A, B](implicit sg : Semigroup
[Option[B]]) : Semigroup[Kleisli[Option, A, B]] = {
semigroup[Kleisli[Option, A, B]]((k1, k2) => {
kleisli[Option]((a : A) => {
sg.append(k1(a), { val k = k2; k(a) })
})
})
}

Sets the bar unacceptably high for most of the stuff I get paid to
work on and people I get paid to work with. And I suspect I'm in the
majority there. Takes all sorts, etc.

All the best, g'night for now
-Matt

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Matthew Willson wrote:
>>> - More generally the problem of finding a good place to limit
>>> inference of implicits - too weak and you can't do everything a good
>>> inheritance model can do, too strong and you might open the doors to a
>>> combinatorial explosion of possible inferences that are hard to reason
>>> about and easy to inadvertently disturb
>> This only affects Scala specifically.
>
> Seems like a wider issue to me. eg Haskell hasn't quite made its mind
> up on where to limit inference with typeclasses, with
> -XFlexibleInstances, -XUndecidableInstances,
> -fallow-overlapping-instances etc
Agreed, I concede.
>
>>> - Object identity semantics and state become confusing and unreliable
>>> when you're silently creating new, separate implicit objects for
>>> different aspects of semantically the "same thing" (yes, I realise the
>>> answer is probably "don't use mutable state, don't use object
>>> identity", but it's not always as simple as that - if it were, why not
>>> just use Haskell?)
>> You guessed the answer right :) If you're going to do silly things,
>> expect the penalty.
>
> Personally I like scala's pragmatic but informed attitude to mutation.
> If I wanted a pure functional language, I'd use Haskell, which (IMO)
> does it better.
I think Haskell does mutation better than most languages and a whole lot
better than Scala does. If I want dangerous and impractical mutation I
use Scala!

To paraphrase, Haskell is perhaps the most practical and advanced
imperative language available. I forget who originated that, but the
realisation of its truth is at least very enlightening!

>
>>> So, I hope that as the scala community gains more experience of the
>>> tradeoffs and peculiarities of implicits, it'll provide a good
>>> starting point for an OO language designed from the outset to be
>>> inheritance-free, with a more elegant implicit system fine-tuned with
>>> feedback after OO developers start trying to use the implicits
>>> approach for their day-to-day work.
>> You'll upset a lot of people by pulling inheritance out -- pop culture
>> programming thinks it is related to code reuse after all!
>
> I haven't made my mind up on the issue - in part because of the lack
> of such a language to test these ideas in practise (as explained,
> scala hasn't yet persuaded me either way). But I'm interested in the
> idea, and in having an enlightening exploration of the various
> trade-offs involved in a complicated language design issue. Doesn't
> seem like a clear-cut issue.
>
> I was trying to stay out of the code re-use debate, because I think
> it's about semantics (of 'code re-use') not substance, and hence
> rather tiresome.
I was hoping it wasn't, but I am suspecting you are right with
"semantics" or specifically, the pop culture use of the term is
internally inconsistent. To quote a like-mind, copy/paste is "code
reuse." In any case, I gave a rigorous reference to code reuse earlier,
which I expect was overlooked.
>
>>> About scalaz: My feeling is that it's an amazing proof of concept, but
>>> most of the time, if I wanted to take that kind of approach I'd use
>>> Haskell. Also while it serves to illustrate the implicits approach, it
>>> does so more in the setting of high-level algebraic abstractions than
>>> the kind of examples that might prove accessible to OO-ers unversed in
>>> category theory.
>> Scalaz is used in many commercial settings. What approach? A practical
>> one without all that repetition?
>>
>> Programming is hard, it always has been. I don't pretend otherwise,
>> neither does Scalaz. Category theory is hardly necessary to use Scalaz
>> effectively as I am sure many people will testify.
>
> Fair enough - I can see the appeal of pushing scala to its limits in
> this way, and if you're working with people who're on the same level
> as you, great!
>
> But while programming is hard, making it this hard (for example, from
> scalaz.http.scapps, a web framework)
>
> implicit def OptionKleisliSemigroup[A, B](implicit sg :
> Semigroup[Option[B]]) : Semigroup[Kleisli[Option, A, B]] = {
> semigroup[Kleisli[Option, A, B]]((k1, k2) => {
> kleisli[Option]((a : A) => {
> sg.append(k1(a), { val k = k2; k(a) })
> })
> })
> }

That's not hard, that's easy! The alternatives are much, much harder.

When my oldest son was younger, he would proudly announce to me "Dad! I
know what two plus two is -- it's four!" He thought it was the best ever.
"But, I would say, what is two million plus two million?" He would be
overwhelmed with the prospect of having to draw that many apples! He
could never work that out!

Soon he learned about the distributive law of multiplication. "It's easy
Dad! It's four million!"

It's only hard if you don't know about the distributive law of
multiplication (and boy does it look hard!). Conversely, look how easy
it really is, with just a simple understanding of a tenet of arithmetic!

The above is not hard. If anything, drawing four million apples is hard.

>
> Sets the bar unacceptably high for most of the stuff I get paid to
> work on and people I get paid to work with. And I suspect I'm in the
> majority there. Takes all sorts, etc.
>
> All the best, g'night for now
> -Matt
>
Have a nice sleep!

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

Which dichotomy do you refer to?
In any case, would you like to demonstrate its falseness? I assumed intellectual discourse does not consist of stating facts without a source and expecting everyone to agree with you automatically.

-------------------------------------
Tony Morris wrote:

False dichotomy.

Naftoli Gugenheim wrote:
> I agree. I just read Oleg's article. How exactly can one construe his
> point as an inherent problem with inheritance?? So a Set is not a kind
> of Bag, fine. Does that mean that cats are not animals?
> Just as Tony and others extol the virtues of functions and discount
> functions that don't adhere to the design principles of functional
> programming--e.g., avoiding state--so too, one can reap the advantages
> of OOP design, as long as he stays away from misusing it.
>
> On Sun, Nov 15, 2009 at 5:13 PM, Quenio dos Santos
> > wrote:
>
> This article you referenced is very interesting. It basically
> shows that you can break the contract of a super-class by changing
> the behavior in the sub-class.
>
> I don't think this common, easily-resolvable issue should be a
> suggestion that inheritance is evil. Even with interfaces, you can
> always provide an implementation that breaks the contract of the
> interface.
>
> Also, in the article, the author suggests that test suite was
> carefully implemented by the authors of both the Bag and the Set.
> However, one important characteristic was not checked by the test
> suite: add(x);add(x);count(x) ==2. Exactly the one that failed in
> the foo() method of the example.
>
> It is interesting to me that one of the few languages that
> actually has built-in support for checking contracts (Eiffel) was
> designed by Bertrand Meyer, which stated clearly in his book
> "Object-Oriented Software Construction
> "
> that it is just fine to use inheritance as a way to re-use code
> even if the super-class and the sub-class have no sub-type
> relationship in the real world.
>
> Eiffel is a serious language implementation that has been around
> for years and is well-respected in the academic community. It has
> multiple inheritance, which works very similarly to traits, and it
> doesn't suffer from the diamond problem.
>
>
> On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris > wrote:
>
> Haskell does away with inheritance just fine. Indeed, it reaps the
> benefits of having abandoned such a blatant type system flaw.
> http://okmij.org/ftp/Computation/Subtyping/
>
> Quenio dos Santos wrote:
> > Hello All,
> >
> > I don't know if you have heard the buzz about the new Go
> programming
> > language from Google, which is been touted as the new
> systems language
> > to replace C/C++.
> >
> > I have been exploring it, and although I found it interesting
> > initially, now I am not so impressed. Just for starters, it
> doesn't
> > support sub-typing. I can't really see how can you live without
> > sub-typing and inheritance in a modern programming language.
> >
> > I honestly believe that Scala would be a great systems
> language if a
> > native compiler was available for Scala. Has that ever
> crossed the
> > mind of the Scala development team, or anybody else?
> >
> > - Quenio
>
> --
> Tony Morris
> http://tmorris.net/
>
>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

Naftoli Gugenheim wrote:
> Which dichotomy do you refer to?
>
The false one.
> In any case, would you like to demonstrate its falseness?
No.
> I assumed intellectual discourse does not consist of stating facts without a source and expecting everyone to agree with you automatically.
>
Haha that's rich.

Inheritance is conducive with code reuse. How is it so? Because you
can't show otherwise, or when you do, I refuse to comprehend it, that's how!

I've given up. Please believe what you will, please oh please.
> -------------------------------------
> Tony Morris wrote:
>
> False dichotomy.
>
> Naftoli Gugenheim wrote:
>
>> I agree. I just read Oleg's article. How exactly can one construe his
>> point as an inherent problem with inheritance?? So a Set is not a kind
>> of Bag, fine. Does that mean that cats are not animals?
>> Just as Tony and others extol the virtues of functions and discount
>> functions that don't adhere to the design principles of functional
>> programming--e.g., avoiding state--so too, one can reap the advantages
>> of OOP design, as long as he stays away from misusing it.
>>
>> On Sun, Nov 15, 2009 at 5:13 PM, Quenio dos Santos
>> > wrote:
>>
>> This article you referenced is very interesting. It basically
>> shows that you can break the contract of a super-class by changing
>> the behavior in the sub-class.
>>
>> I don't think this common, easily-resolvable issue should be a
>> suggestion that inheritance is evil. Even with interfaces, you can
>> always provide an implementation that breaks the contract of the
>> interface.
>>
>> Also, in the article, the author suggests that test suite was
>> carefully implemented by the authors of both the Bag and the Set.
>> However, one important characteristic was not checked by the test
>> suite: add(x);add(x);count(x) ==2. Exactly the one that failed in
>> the foo() method of the example.
>>
>> It is interesting to me that one of the few languages that
>> actually has built-in support for checking contracts (Eiffel) was
>> designed by Bertrand Meyer, which stated clearly in his book
>> "Object-Oriented Software Construction
>> "
>> that it is just fine to use inheritance as a way to re-use code
>> even if the super-class and the sub-class have no sub-type
>> relationship in the real world.
>>
>> Eiffel is a serious language implementation that has been around
>> for years and is well-respected in the academic community. It has
>> multiple inheritance, which works very similarly to traits, and it
>> doesn't suffer from the diamond problem.
>>
>>
>> On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris > > wrote:
>>
>> Haskell does away with inheritance just fine. Indeed, it reaps the
>> benefits of having abandoned such a blatant type system flaw.
>> http://okmij.org/ftp/Computation/Subtyping/
>>
>> Quenio dos Santos wrote:
>> > Hello All,
>> >
>> > I don't know if you have heard the buzz about the new Go
>> programming
>> > language from Google, which is been touted as the new
>> systems language
>> > to replace C/C++.
>> >
>> > I have been exploring it, and although I found it interesting
>> > initially, now I am not so impressed. Just for starters, it
>> doesn't
>> > support sub-typing. I can't really see how can you live without
>> > sub-typing and inheritance in a modern programming language.
>> >
>> > I honestly believe that Scala would be a great systems
>> language if a
>> > native compiler was available for Scala. Has that ever
>> crossed the
>> > mind of the Scala development team, or anybody else?
>> >
>> > - Quenio
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>>
>
>

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

I am not discussing code reuse!!! I said that already. I was not discussing it since the last email in which I mentioned it explicitly.
By the way, you were the one that started this discussion of code reuse after someone mentioned in passing. There were very few exchanges about it. And it has been said that the question is about the meaning of the term, not of what OOP does or doesn't do, so it's WAY off topic.
Please don't talk in riddles. You said you want to make us think be educated. Instead your acting like someone who wants to sound smart.. "False dichotomy." Why? You won't say--you insinuate it's obvious. If I was as smart as you want us to believe you are, I wouldn't have asked. So why are you belittling me? Is that what I deserve for trying to get educated?
So please tell me--I don't recall stating a dichotomy. I stated a parallel; you're the one distinguishing between your approach to functional and OO paradigms.
Please don't take offense at the following statement. Humans are automatically biased. They have cognitive dissonance. That is how everyone is. That is why debate is necessary to determine the truth, because no one person can perceive the truth on their own. Only by discussing a matter civilly and bringing arguments and counterarguments and refuting them can the truth of the matter come to light.
I am not taking sides over here. You made a statement; if you refuse to discuss what you mean or how you arrived at a conclusion, then neither of us knows the truth.

-------------------------------------
Tony Morris wrote:

Naftoli Gugenheim wrote:
> Which dichotomy do you refer to?
>
The false one.
> In any case, would you like to demonstrate its falseness?
No.
> I assumed intellectual discourse does not consist of stating facts without a source and expecting everyone to agree with you automatically.
>
Haha that's rich.

Inheritance is conducive with code reuse. How is it so? Because you
can't show otherwise, or when you do, I refuse to comprehend it, that's how!

I've given up. Please believe what you will, please oh please.
> -------------------------------------
> Tony Morris wrote:
>
> False dichotomy.
>
> Naftoli Gugenheim wrote:
>
>> I agree. I just read Oleg's article. How exactly can one construe his
>> point as an inherent problem with inheritance?? So a Set is not a kind
>> of Bag, fine. Does that mean that cats are not animals?
>> Just as Tony and others extol the virtues of functions and discount
>> functions that don't adhere to the design principles of functional
>> programming--e.g., avoiding state--so too, one can reap the advantages
>> of OOP design, as long as he stays away from misusing it.
>>
>> On Sun, Nov 15, 2009 at 5:13 PM, Quenio dos Santos
>> > wrote:
>>
>> This article you referenced is very interesting. It basically
>> shows that you can break the contract of a super-class by changing
>> the behavior in the sub-class.
>>
>> I don't think this common, easily-resolvable issue should be a
>> suggestion that inheritance is evil. Even with interfaces, you can
>> always provide an implementation that breaks the contract of the
>> interface.
>>
>> Also, in the article, the author suggests that test suite was
>> carefully implemented by the authors of both the Bag and the Set.
>> However, one important characteristic was not checked by the test
>> suite: add(x);add(x);count(x) ==2. Exactly the one that failed in
>> the foo() method of the example.
>>
>> It is interesting to me that one of the few languages that
>> actually has built-in support for checking contracts (Eiffel) was
>> designed by Bertrand Meyer, which stated clearly in his book
>> "Object-Oriented Software Construction
>> "
>> that it is just fine to use inheritance as a way to re-use code
>> even if the super-class and the sub-class have no sub-type
>> relationship in the real world.
>>
>> Eiffel is a serious language implementation that has been around
>> for years and is well-respected in the academic community. It has
>> multiple inheritance, which works very similarly to traits, and it
>> doesn't suffer from the diamond problem.
>>
>>
>> On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris > > wrote:
>>
>> Haskell does away with inheritance just fine. Indeed, it reaps the
>> benefits of having abandoned such a blatant type system flaw.
>> http://okmij.org/ftp/Computation/Subtyping/
>>
>> Quenio dos Santos wrote:
>> > Hello All,
>> >
>> > I don't know if you have heard the buzz about the new Go
>> programming
>> > language from Google, which is been touted as the new
>> systems language
>> > to replace C/C++.
>> >
>> > I have been exploring it, and although I found it interesting
>> > initially, now I am not so impressed. Just for starters, it
>> doesn't
>> > support sub-typing. I can't really see how can you live without
>> > sub-typing and inheritance in a modern programming language.
>> >
>> > I honestly believe that Scala would be a great systems
>> language if a
>> > native compiler was available for Scala. Has that ever
>> crossed the
>> > mind of the Scala development team, or anybody else?
>> >
>> > - Quenio
>>
>> --
>> Tony Morris
>> http://tmorris.net/
>>
>>
>>
>>
>>
>
>

Tony Morris 2
Joined: 2009-03-20,
User offline. Last seen 42 years 45 weeks ago.
Re: Native Compiler for Scala

I may enjoy educating and learning, but I also have limited patience.

Naftoli Gugenheim wrote:
> I am not discussing code reuse!!! I said that already. I was not discussing it since the last email in which I mentioned it explicitly.
> By the way, you were the one that started this discussion of code reuse after someone mentioned in passing. There were very few exchanges about it. And it has been said that the question is about the meaning of the term, not of what OOP does or doesn't do, so it's WAY off topic.
> Please don't talk in riddles. You said you want to make us think be educated. Instead your acting like someone who wants to sound smart.. "False dichotomy." Why? You won't say--you insinuate it's obvious. If I was as smart as you want us to believe you are, I wouldn't have asked. So why are you belittling me? Is that what I deserve for trying to get educated?
> So please tell me--I don't recall stating a dichotomy. I stated a parallel; you're the one distinguishing between your approach to functional and OO paradigms.
> Please don't take offense at the following statement. Humans are automatically biased. They have cognitive dissonance. That is how everyone is. That is why debate is necessary to determine the truth, because no one person can perceive the truth on their own. Only by discussing a matter civilly and bringing arguments and counterarguments and refuting them can the truth of the matter come to light.
> I am not taking sides over here. You made a statement; if you refuse to discuss what you mean or how you arrived at a conclusion, then neither of us knows the truth.
>
> -------------------------------------
> Tony Morris wrote:
>
>
>
> Naftoli Gugenheim wrote:
>
>> Which dichotomy do you refer to?
>>
>>
> The false one.
>
>> In any case, would you like to demonstrate its falseness?
>>
> No.
>
>> I assumed intellectual discourse does not consist of stating facts without a source and expecting everyone to agree with you automatically.
>>
>>
> Haha that's rich.
>
> Inheritance is conducive with code reuse. How is it so? Because you
> can't show otherwise, or when you do, I refuse to comprehend it, that's how!
>
> I've given up. Please believe what you will, please oh please.
>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> False dichotomy.
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> I agree. I just read Oleg's article. How exactly can one construe his
>>> point as an inherent problem with inheritance?? So a Set is not a kind
>>> of Bag, fine. Does that mean that cats are not animals?
>>> Just as Tony and others extol the virtues of functions and discount
>>> functions that don't adhere to the design principles of functional
>>> programming--e.g., avoiding state--so too, one can reap the advantages
>>> of OOP design, as long as he stays away from misusing it.
>>>
>>> On Sun, Nov 15, 2009 at 5:13 PM, Quenio dos Santos
>>> > wrote:
>>>
>>> This article you referenced is very interesting. It basically
>>> shows that you can break the contract of a super-class by changing
>>> the behavior in the sub-class.
>>>
>>> I don't think this common, easily-resolvable issue should be a
>>> suggestion that inheritance is evil. Even with interfaces, you can
>>> always provide an implementation that breaks the contract of the
>>> interface.
>>>
>>> Also, in the article, the author suggests that test suite was
>>> carefully implemented by the authors of both the Bag and the Set.
>>> However, one important characteristic was not checked by the test
>>> suite: add(x);add(x);count(x) ==2. Exactly the one that failed in
>>> the foo() method of the example.
>>>
>>> It is interesting to me that one of the few languages that
>>> actually has built-in support for checking contracts (Eiffel) was
>>> designed by Bertrand Meyer, which stated clearly in his book
>>> "Object-Oriented Software Construction
>>> "
>>> that it is just fine to use inheritance as a way to re-use code
>>> even if the super-class and the sub-class have no sub-type
>>> relationship in the real world.
>>>
>>> Eiffel is a serious language implementation that has been around
>>> for years and is well-respected in the academic community. It has
>>> multiple inheritance, which works very similarly to traits, and it
>>> doesn't suffer from the diamond problem.
>>>
>>>
>>> On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris >> > wrote:
>>>
>>> Haskell does away with inheritance just fine. Indeed, it reaps the
>>> benefits of having abandoned such a blatant type system flaw.
>>> http://okmij.org/ftp/Computation/Subtyping/
>>>
>>> Quenio dos Santos wrote:
>>> > Hello All,
>>> >
>>> > I don't know if you have heard the buzz about the new Go
>>> programming
>>> > language from Google, which is been touted as the new
>>> systems language
>>> > to replace C/C++.
>>> >
>>> > I have been exploring it, and although I found it interesting
>>> > initially, now I am not so impressed. Just for starters, it
>>> doesn't
>>> > support sub-typing. I can't really see how can you live without
>>> > sub-typing and inheritance in a modern programming language.
>>> >
>>> > I honestly believe that Scala would be a great systems
>>> language if a
>>> > native compiler was available for Scala. Has that ever
>>> crossed the
>>> > mind of the Scala development team, or anybody else?
>>> >
>>> > - Quenio
>>>
>>> --
>>> Tony Morris
>>> http://tmorris.net/
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

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

Well then I must be really dumb, if my questions have tried your patience. Or actually my one question. It's not as though you gave a single comprendible answer. You gave some cryptic replies which I suspect were not meant to be understood except by someone who would not ask the question, although I believe I understood them and they were insufficient. You pointed to sources. I read two of them against inheritance, and found their case to be very shoddy. When I have a chance maybe I'll copy them into an email and comment.
Is anyone going answer me, now that Tony has given up?
Can someone make a case against inheritance per se, other than it being mathematically redundant?

-------------------------------------
Tony Morris wrote:

I may enjoy educating and learning, but I also have limited patience.

Naftoli Gugenheim wrote:
> I am not discussing code reuse!!! I said that already. I was not discussing it since the last email in which I mentioned it explicitly.
> By the way, you were the one that started this discussion of code reuse after someone mentioned in passing. There were very few exchanges about it. And it has been said that the question is about the meaning of the term, not of what OOP does or doesn't do, so it's WAY off topic.
> Please don't talk in riddles. You said you want to make us think be educated. Instead your acting like someone who wants to sound smart.. "False dichotomy." Why? You won't say--you insinuate it's obvious. If I was as smart as you want us to believe you are, I wouldn't have asked. So why are you belittling me? Is that what I deserve for trying to get educated?
> So please tell me--I don't recall stating a dichotomy. I stated a parallel; you're the one distinguishing between your approach to functional and OO paradigms.
> Please don't take offense at the following statement. Humans are automatically biased. They have cognitive dissonance. That is how everyone is. That is why debate is necessary to determine the truth, because no one person can perceive the truth on their own. Only by discussing a matter civilly and bringing arguments and counterarguments and refuting them can the truth of the matter come to light.
> I am not taking sides over here. You made a statement; if you refuse to discuss what you mean or how you arrived at a conclusion, then neither of us knows the truth.
>
> -------------------------------------
> Tony Morris wrote:
>
>
>
> Naftoli Gugenheim wrote:
>
>> Which dichotomy do you refer to?
>>
>>
> The false one.
>
>> In any case, would you like to demonstrate its falseness?
>>
> No.
>
>> I assumed intellectual discourse does not consist of stating facts without a source and expecting everyone to agree with you automatically.
>>
>>
> Haha that's rich.
>
> Inheritance is conducive with code reuse. How is it so? Because you
> can't show otherwise, or when you do, I refuse to comprehend it, that's how!
>
> I've given up. Please believe what you will, please oh please.
>
>> -------------------------------------
>> Tony Morris wrote:
>>
>> False dichotomy.
>>
>> Naftoli Gugenheim wrote:
>>
>>
>>> I agree. I just read Oleg's article. How exactly can one construe his
>>> point as an inherent problem with inheritance?? So a Set is not a kind
>>> of Bag, fine. Does that mean that cats are not animals?
>>> Just as Tony and others extol the virtues of functions and discount
>>> functions that don't adhere to the design principles of functional
>>> programming--e.g., avoiding state--so too, one can reap the advantages
>>> of OOP design, as long as he stays away from misusing it.
>>>
>>> On Sun, Nov 15, 2009 at 5:13 PM, Quenio dos Santos
>>> > wrote:
>>>
>>> This article you referenced is very interesting. It basically
>>> shows that you can break the contract of a super-class by changing
>>> the behavior in the sub-class.
>>>
>>> I don't think this common, easily-resolvable issue should be a
>>> suggestion that inheritance is evil. Even with interfaces, you can
>>> always provide an implementation that breaks the contract of the
>>> interface.
>>>
>>> Also, in the article, the author suggests that test suite was
>>> carefully implemented by the authors of both the Bag and the Set.
>>> However, one important characteristic was not checked by the test
>>> suite: add(x);add(x);count(x) ==2. Exactly the one that failed in
>>> the foo() method of the example.
>>>
>>> It is interesting to me that one of the few languages that
>>> actually has built-in support for checking contracts (Eiffel) was
>>> designed by Bertrand Meyer, which stated clearly in his book
>>> "Object-Oriented Software Construction
>>> "
>>> that it is just fine to use inheritance as a way to re-use code
>>> even if the super-class and the sub-class have no sub-type
>>> relationship in the real world.
>>>
>>> Eiffel is a serious language implementation that has been around
>>> for years and is well-respected in the academic community. It has
>>> multiple inheritance, which works very similarly to traits, and it
>>> doesn't suffer from the diamond problem.
>>>
>>>
>>> On Sun, Nov 15, 2009 at 2:27 AM, Tony Morris >> > wrote:
>>>
>>> Haskell does away with inheritance just fine. Indeed, it reaps the
>>> benefits of having abandoned such a blatant type system flaw.
>>> http://okmij.org/ftp/Computation/Subtyping/
>>>
>>> Quenio dos Santos wrote:
>>> > Hello All,
>>> >
>>> > I don't know if you have heard the buzz about the new Go
>>> programming
>>> > language from Google, which is been touted as the new
>>> systems language
>>> > to replace C/C++.
>>> >
>>> > I have been exploring it, and although I found it interesting
>>> > initially, now I am not so impressed. Just for starters, it
>>> doesn't
>>> > support sub-typing. I can't really see how can you live without
>>> > sub-typing and inheritance in a modern programming language.
>>> >
>>> > I honestly believe that Scala would be a great systems
>>> language if a
>>> > native compiler was available for Scala. Has that ever
>>> crossed the
>>> > mind of the Scala development team, or anybody else?
>>> >
>>> > - Quenio
>>>
>>> --
>>> Tony Morris
>>> http://tmorris.net/
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>

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:24 AM, Tony Morris <tonymorris [at] gmail [dot] com> wrote:
I've given up. Please believe what you will, please oh please.

These threats seem pretty hollow as you've made them quite a few times before in this and the documentation vs. type theory thread.

Also, every time I've come up with a valid counterexample to what you've said, you've failed to say anything meaningful about it.

You said things about type theory without making it clear that you were talking about type theory; then once I figured it out and came up with examples of why type theory was limited, you completely ignored what I said, and kept harping on the type-theory-lets-you-prove-this topic.

Now you've just done the exact same thing with code reuse.  And, this time, there is no formal definition of "code reuse" that is widely accepted, so you can't blame a lack of education.

And you did the exact same thing with my question about the efficiency of a functional version of inheritance--you first avoided answering anything substantive (basically, "Ick, JVM!"), then when I rephrased, failed to answer anything at all.  (Which happens to be relevant to the point.)

You ought to know the definition of a mathematical proof, and have some familiarity with the informal extension to "logical argument", but again you've given a very short answer to an honest question which, as far as I can tell, only shows that you failed to understand what Naftoli said and needed to ask for clarification, or that your motives were not, in fact, to engage in a discussion.

So what, really, are you playing at here?

  --Rex

P.S. If you're actually interested in persuading people, you might try reading "How to Win Friends and Influence People", or for a more modern perspective, "Crucial Conversations".


 
> -------------------------------------
> Tony Morris<tonymorris [at] gmail [dot] com> wrote:
>
> False dichotomy.
>
> Naftoli Gugenheim wrote:
>
>> I agree. I just read Oleg's article. How exactly can one construe his
>> point as an inherent problem with inheritance?? So a Set is not a kind
>> of Bag, fine. Does that mean that cats are not animals?
>> Just as Tony and others extol the virtues of functions and discount
>> functions that don't adhere to the design principles of functional
>> programming--e.g., avoiding state--so too, one can reap the advantages
>> of OOP design, as long as he stays away from misusing it.
>>

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

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
>

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

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
>

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