Ruby’s mixins have similar features to Java interfaces, but they are more
flexible, and don’t play any specification role. Also, Ruby classes don’t
need
any interface description to be able to plug-n-play; they just need to
support
the rigth methods at the right time.
In short, it’s not a technical reason. Ruby doesn’t want to be as strict as
Java. Result: more flexibility, but no guarantees.
If you find yourself in a situation where you want these things, but also
want
to use Ruby, either:
use Ruby as a prototype and then convert to Java if necessary
enforce type-compliance to key methods by raising exceptions
While I understand your point, I do have to disagree and say that Mixins
aren’t anything like interfaces coming from my perspective.
From my perspective, interfaces and/or contracts are a way to
unerringly guarantee than an object ALWAYS provides specific
functionality. Mixins are a way to share common functionality amongst
multiple objects via code-reuse, but they don’t guarantee that said
functionality will be implemented (methods can be changed after the
fact). A contract says I must do something. If I no longer do
something, I no longer follow that contract and it is therefore no
longer valid. I’ve never read anything about Ruby Mixins being
immutible like this
Also, another important reason why I think the two concepts don’t serve
the same purpose is that interfaces only guarantee functionality.
They say nothing about how that functionality is implemented (are you
reading from a database? or from an xml file?). A mixin is a mixin and
it behaves a certain way. You can have two mixins with the same
behavior, they may look and act the same but they are in fact two
distinct things (unless I’m misunderstanding Mixins).
You can use Mixins to implement interface like funtionality, so your
point is certainly valid. But you can’t use Mixins to GUARANTEE that
functionality across the board for all time. That’s the missing piece
for a lot of us.
Bryan
In Ruby, the attitude always has to be “you can …”, with the disclaimer that
“you can’t guarantee …”. If you’re writing code for yourself, you trust your
own “interfaces” and use them to organise code and communicate intention
better. If you’re coding with other people, you obviously need to trust that
they will not drive on the wrong side of the road just because they can.
But your points certainly do drive a wedge further between mixins and
interfaces, the latter no longer being considered a Java specialty.
You lost me there, Bryan, perhaps because the only languages that I’ve
used interface inheritance in are Java and ObjC and Ruby. But in Java,
anyway, when I say “implements xyz” I’m free to define xyz any way I
want as log as the method takes standard arguments. In fact the message
name is really no more than a hint as to what the method does. How can
that be a ‘contract’?
···
On Monday, September 30, 2002, at 07:27 PM, Bryan Murphy wrote:
While I understand your point, I do have to disagree and say that
Mixins aren’t anything like interfaces coming from my perspective.
From my perspective, interfaces and/or contracts are a way to
unerringly guarantee than an object ALWAYS provides specific
functionality.
I don’t think that Mixins are equivalent to language checked
interfaces either, but I also disagree with some of your conclusions.
For one, I don’t think that interfaces practically guarantee specific
functionality any more than mixin’s. The interface guarantees a
specific interface – you shall be able to call method fu with class
sna. But you are no more sure that the correct thing will happen when
sna.fu is called. Mixins are more useful for indicating that not only
will method fu exist in a class and that a functionality is
implemented a certain way. True, with ruby’s dynamic classes, there’s
no certainty that the class hasn’t been altered, but really is it that
any more certain that the backend implementation of an interface has
been changed since the last sync with an outside codebase?
To me features such as interfaces are very useful for design, but when
you get to implementation, they get in the way because you often end
up debugging several abstraction layers away from the actual bugs.
For programmers which come from stricter environments, I understand it
feels odd - it felt odd to me at first too. Giving up discipline
enforcing features such as interfaces, and type checking is
disorienting and a little scary. I’m getting a little nebulous, but
looking back those features are good at preventing “mechanical”
errors, but usually break down when programmers try to extend them to
enforce human “semantical” relationships. Giving up those features may
increase some rates of mechanical errors but in exchange you get focus
the ability to concentrate on the design and implementation of your
code “semantics” with very few syntax mechanics obscuring your vision.
Ultimately, I think it’s this focus on the human factor is what drives
my productivity higher with Ruby.
···
On Tue, Oct 01, 2002 at 11:27:59AM +0900, Bryan Murphy wrote:
Gavin Sinclair wrote:
If you find yourself in a situation where you want these things, but also
want
to use Ruby, either:
use Ruby as a prototype and then convert to Java if necessary
enforce type-compliance to key methods by raising exceptions
While I understand your point, I do have to disagree and say that Mixins
aren’t anything like interfaces coming from my perspective.
From my perspective, interfaces and/or contracts are a way to
unerringly guarantee than an object ALWAYS provides specific
functionality. Mixins are a way to share common functionality amongst
multiple objects via code-reuse, but they don’t guarantee that said
functionality will be implemented (methods can be changed after the
fact). A contract says I must do something. If I no longer do
something, I no longer follow that contract and it is therefore no
longer valid. I’ve never read anything about Ruby Mixins being
immutible like this
Also, another important reason why I think the two concepts don’t
serve the same purpose is that interfaces only guarantee
functionality. They say nothing about how that functionality is
implemented (are you reading from a database? or from an xml file?).
A mixin is a mixin and it behaves a certain way. You can have two
mixins with the same behavior, they may look and act the same but
they are in fact two distinct things (unless I’m misunderstanding
Mixins). You can use Mixins to implement interface like
funtionality, so your point is certainly valid. But you can’t use
Mixins to GUARANTEE that functionality across the board for all
time. That’s the missing piece for a lot of us.
On Monday, September 30, 2002, at 09:27 PM, Bulat Ziganshin wrote:
Hello William,
Monday, September 30, 2002, 6:16:46 PM, you wrote:
objective-c is kind-of Apple oriented (?)
reverse - OC was used in nextstep, which itself is base of new aplle’s
unix-derived OS. so, at this time OC is dead, except for using it in
nextstep/darwin programs
In Ruby, the attitude always has to be “you can …”, with the disclaimer that
“you can’t guarantee …”. If you’re writing code for yourself, you trust your
own “interfaces” and use them to organise code and communicate intention
better. If you’re coding with other people, you obviously need to trust that
they will not drive on the wrong side of the road just because they can.
But your points certainly do drive a wedge further between mixins and
interfaces, the latter no longer being considered a Java specialty.
Regards,
Gavin
Yeah, and I think that gets to the core issue why everybody keeps
talking about types and static typing. Static typing, contracts,
interfaces, it can all be summed up in one thing: people wanting to
guarantee a minimum amount of functionality. Is that a Ruby thing? I
really don’t know, but it’s basically what people are clamoring for. If
we can solve this problem while still keeping Ruby Ruby, that might go a
long way to bringing these threads to an end!
What’s the solution? I’m really not sure. I’m not a language designer,
but I’m thinking about it. If I have any good ideas, maybe one day I
will send them.
While I understand your point, I do have to disagree and say that
Mixins aren’t anything like interfaces coming from my perspective.
From my perspective, interfaces and/or contracts are a way to
unerringly guarantee than an object ALWAYS provides specific
functionality.
You lost me there, Bryan, perhaps because the only languages that I’ve
used interface inheritance in are Java and ObjC and Ruby. But in Java,
anyway, when I say “implements xyz” I’m free to define xyz any way I
want as log as the method takes standard arguments. In fact the
message name is really no more than a hint as to what the method does.
How can that be a ‘contract’?
You’re taking me way too literally. Had I dwelled in horrendous detail
over every little word in my original post I would have been a bit more
carefull about my use of Interfaces and Contracts as they are not the
same thing (though they share similar features). My main point is
simply that people want an easy and convenient way to guarantee that
things behave a certain way in Ruby. Interfaces, contracts, static
typing, they are all attempts to do this that solve different parts of
the problem but don’t solve the problem as a whole.
I’m sure Brad Cox, a frequent poster here, will also be somewhat
disappointed ;-).
I read Brad’s 0-C book “OOP-An Evolutionary Approach” back in
1985. It was inspirational. Although I have never worked
seriously with NextStep, One of the delights of Ruby was
rediscovering some of Brad’s ideas implemented in a new
language.
BTW. There was extensive debate on the PragProg LOTY list about
which language to study next year. Objective-C had many
advocates.
I totally agree with the statement below; I think so far Ruby results in
a very high human productivity. Now the question is, in essence, do you
want an option to reduce the productivity by 20%, if you can increase the
computer productivity by 500%? (This is even an option; you may choose to
do it or stay with you current productivity level.)
Regards,
Bill
···
==========================================================================
Alan Chen alan@digikata.com wrote:
Ultimately, I think it’s this focus on the human factor is what drives
my productivity higher with Ruby.
In Ruby, the attitude always has to be “you can …”, with the disclaimer
that
“you can’t guarantee …”. If you’re writing code for yourself, you trust
your
own “interfaces” and use them to organise code and communicate intention
better. If you’re coding with other people, you obviously need to trust
that
they will not drive on the wrong side of the road just because they can.
But your points certainly do drive a wedge further between mixins and
interfaces, the latter no longer being considered a Java specialty.
Regards,
Gavin
Yeah, and I think that gets to the core issue why everybody keeps
talking about types and static typing. Static typing, contracts,
interfaces, it can all be summed up in one thing: people wanting to
guarantee a minimum amount of functionality. Is that a Ruby thing? I
really don’t know, but it’s basically what people are clamoring for. If
we can solve this problem while still keeping Ruby Ruby, that might go a
long way to bringing these threads to an end!
What’s the solution? I’m really not sure. I’m not a language designer,
but I’m thinking about it. If I have any good ideas, maybe one day I
will send them.
Bryan
It’s not a Ruby thing. Amongst experienced Rubyists (not including myself
here) there’s a belief that static typing is limiting, and the benefits of it
are either illusory or available through other means. In other words, Ruby has
a certain flavour to it, a paradigm if you will.
OK, I plead guilty. I’ve noticed that some people want “an easy and
convenient way to guarantee that things behave a certain way in Ruby”
but I’m still wrestling with:
Why do they want that
and
What does “behave a certain way” mean?
Though those questions aren’t as distinct for me as the above dichotomy
implies. If I use the same method name in two different classes, I seem
to be expressing the idea that they are the ‘same behavior’ at some
level of abstraction but obviously they are different at some level or
detail. Even in C, adding ints is not really the same thing as adding
floats.
···
On Monday, September 30, 2002, at 08:42 PM, Bryan Murphy wrote:
Chris Gehlker wrote:
While I understand your point, I do have to disagree and say that
Mixins aren’t anything like interfaces coming from my perspective.
From my perspective, interfaces and/or contracts are a way to
unerringly guarantee than an object ALWAYS provides specific
functionality.
You lost me there, Bryan, perhaps because the only languages that
I’ve used interface inheritance in are Java and ObjC and Ruby. But in
Java, anyway, when I say “implements xyz” I’m free to define xyz any
way I want as log as the method takes standard arguments. In fact the
message name is really no more than a hint as to what the method
does. How can that be a ‘contract’?
You’re taking me way too literally. Had I dwelled in horrendous
detail over every little word in my original post I would have been a
bit more carefull about my use of Interfaces and Contracts as they are
not the same thing (though they share similar features). My main
point is simply that people want an easy and convenient way to
guarantee that things behave a certain way in Ruby. Interfaces,
contracts, static typing, they are all attempts to do this that solve
different parts of the problem but don’t solve the problem as a whole.
I’m sure Brad Cox, a frequent poster here, will also be somewhat
disappointed ;-).
He’ll probably be heartbroken
I read Brad’s 0-C book “OOP-An Evolutionary Approach” back in
1985. It was inspirational. Although I have never worked
seriously with NextStep, One of the delights of Ruby was
rediscovering some of Brad’s ideas implemented in a new
language.
BTW. There was extensive debate on the PragProg LOTY list about
which language to study next year. Objective-C had many
advocates.
Well, for someone who is familiar with both C and Ruby, ObjC is more
like ‘Language of the Day.’ I just hope folks don’t dismiss it because
it is easy to learn.
···
On Tuesday, October 1, 2002, at 02:59 AM, Aidan Mark Humphreys wrote:
As an adolescent I aspired to lasting fame, I craved factual certainty,
and I thirsted for a meaningful vision of human life - so I became a
scientist. This is like becoming an archbishop so you can meet girls.
-Matt Cartmill, anthropology professor and author (1943- )
Personally, I’m not interested in that tradeoff. If I want higher
performance, I can perform design/algorithmic optimizations best in
Ruby. If that doesn’t suffice, I can drop into C/C++ or ASM or any
number of other well established, widely supported
languages. Furthermore, in that alternate language, I can focus on a
narrow optimization issue.
Now if you can keep the human productivity the same while increasing
run speed I’d be very interested (not to mention that more of the ruby
community would be more supportive). So many of the recent syntax
extension discussions have assumed that Ruby as it is now would be
difficult to optimize because of the dynamic language features, but
that seems like a poorly examined supposition to me. I would bet that
run-time dynamic updates in ruby code happens in a small set of
instances - and then primarily near startup. There’s no reason that a
optimizing, ruby, run-time engine couldn’t go ahead and emit optimized
code with any number of type-based restrictions, but detect dynamic
updates which may invalidate that particular optimized code
block. Think of it as a ruby version of a Java HotSpot compiler.
alan
···
On Tue, Oct 01, 2002 at 10:19:51PM +0900, William Djaja Tjokroaminata wrote:
Hi Alan,
I totally agree with the statement below; I think so far Ruby results in
a very high human productivity. Now the question is, in essence, do you
want an option to reduce the productivity by 20%, if you can increase the
computer productivity by 500%? (This is even an option; you may choose to
do it or stay with you current productivity level.)
But how about making declaring type optional? Even the referenced web
page states that “A hybrid solution where you can adapt to the problem at
hand will have the highest probability of success.”
Therefore, people who want to code in the current Ruby style and syntax
can do it that way (no change to Ruby at all), while people who want to
try to make the code “run faster” (and probably need some weak type
checking) can use the optional typing.
If the concern is that optional typing will make overall Ruby slower, we
can just use a switch when running Ruby interpreter, where “ruby
-no_type_check” will run the current, established, interpreter, and other
switches will invoke a new interpreter which will have optional typing.
Finally, the “Efficient-dynlang-implementer view” in the referenced web
page states it precisely:
“DynTypes are great but cost a lot since we cannot optimize for a
certain type. To make the task of the compiler/optimizer simpler we need
hints of the actual types. Lets give the user a way to specify/hint on
the actual types.”
Ruby already takes the good things from Perl, SmallTalk, Lisp, etc. An
experimentation with the good things from Dylan probably will not hurt, I
guess. Only later when the experiment is deemed successful, we can
incorporate it in the mainstream Ruby, if we (or Matz to be more
precise) choose to do so.
It’s not a Ruby thing. Amongst experienced Rubyists (not including myself
here) there’s a belief that static typing is limiting, and the benefits of it
are either illusory or available through other means. In other words, Ruby has
a certain flavour to it, a paradigm if you will.
For me, it is because I assume that my code user (sometimes including
myself) will make mistakes, such as giving the code a String when a Fixnum
is expected. Therefore, so that I can catch the error as early as
possible (to give more useful hints to the user that it is his/her input
that is wrong, not the code), I usually code
Now, I just want a convenience in writing the above code if I can just
write
def func (Fixnum a)
....
In this case, that’s it. The new code is not more safe than the code that
we can write right now with Ruby. It is just more convenient, I guess…
(Well, but then, if the above proposal is accepted, we can use it further
for interpreter/compiler optimization also, and not just simple type error
checking as above…)
Regards,
Bill
···
===========================================================================
Chris Gehlker canyonrat@mac.com wrote:
Why do they want that
and
What does “behave a certain way” mean?
Though those questions aren’t as distinct for me as the above dichotomy
implies. If I use the same method name in two different classes, I seem
to be expressing the idea that they are the ‘same behavior’ at some
level of abstraction but obviously they are different at some level or
detail. Even in C, adding ints is not really the same thing as adding
floats.
I don’t know, Alan; just like Java, probably some typing is currently the
only obvious way to make Ruby run even faster, but people are saying that
it is not the Ruby way. If there is indeed a new technology that can make
Ruby run faster without some typing, that will indeed be the right way to
go.
In my dream language, the typing is optional, and then I will add ‘struct’
(not the current Ruby Struct), so that member data “@data” is not accessed
through hash anymore, but through memory offset. It will take me some
time to learn lex and yacc and the Ruby interpreter. As already
commented, probably eventually I will have to take the task myself (if I
have the time).
Regards,
Bill
···
===========================================================================
Alan Chen alan@digikata.com wrote:
Now if you can keep the human productivity the same while increasing
run speed I’d be very interested (not to mention that more of the ruby
community would be more supportive). So many of the recent syntax
extension discussions have assumed that Ruby as it is now would be
difficult to optimize because of the dynamic language features, but
that seems like a poorly examined supposition to me. I would bet that
run-time dynamic updates in ruby code happens in a small set of
instances - and then primarily near startup. There’s no reason that a
optimizing, ruby, run-time engine couldn’t go ahead and emit optimized
code with any number of type-based restrictions, but detect dynamic
updates which may invalidate that particular optimized code
block. Think of it as a ruby version of a Java HotSpot compiler.
Maybe you guys should have a look at Suns Self language.
It’s a prototype based language that has similarities with Smalltalk. If I
remember correctly, they did a lot of research into hotspot compilation
which was later poached for Java. It’s not easy stuff though and it tended
to generate a lot of code to handle all of the dynamic cases.
On Tue, Oct 01, 2002 at 10:19:51PM +0900, William Djaja Tjokroaminata wrote:
Hi Alan,
I totally agree with the statement below; I think so far Ruby results in
a very high human productivity. Now the question is, in essence, do you
want an option to reduce the productivity by 20%, if you can increase
the
computer productivity by 500%? (This is even an option; you may choose
to
do it or stay with you current productivity level.)
Ultimately, I think it’s this focus on the human factor is what drives
my productivity higher with Ruby.
Personally, I’m not interested in that tradeoff. If I want higher
performance, I can perform design/algorithmic optimizations best in
Ruby. If that doesn’t suffice, I can drop into C/C++ or ASM or any
number of other well established, widely supported
languages. Furthermore, in that alternate language, I can focus on a
narrow optimization issue.
Now if you can keep the human productivity the same while increasing
run speed I’d be very interested (not to mention that more of the ruby
community would be more supportive). So many of the recent syntax
extension discussions have assumed that Ruby as it is now would be
difficult to optimize because of the dynamic language features, but
that seems like a poorly examined supposition to me. I would bet that
run-time dynamic updates in ruby code happens in a small set of
instances - and then primarily near startup. There’s no reason that a
optimizing, ruby, run-time engine couldn’t go ahead and emit optimized
code with any number of type-based restrictions, but detect dynamic
updates which may invalidate that particular optimized code
block. Think of it as a ruby version of a Java HotSpot compiler.
For me, it is because I assume that my code user (sometimes including
myself) will make mistakes, such as giving the code a String when a Fixnum
is expected. Therefore, so that I can catch the error as early as
possible (to give more useful hints to the user that it is his/her input
that is wrong, not the code), I usually code
Ruby types are not releated to classes. They’re related to object
protocols (the infamous Duck Typing). That’s what gives Ruby much of
its appeal. Testing for classes is really very poor style, and
artificially constrains the users of your code.
> If the concern is that optional typing will make overall Ruby slower, we
> can just use a switch when running Ruby interpreter, where "ruby
> -no_type_check" will run the current, established, interpreter, and other
> switches will invoke a new interpreter which will have optional typing.
>
Hi, Bill. You are very persistent and seem to be a little slow on the uptake.
In that I already have a reputation on this list as being somewhat of a loose
cannon, let me state something very clearly. Type checking is undesired and
unnecessary in any purely OOP language, Ruby included. You seem to be intent
on recruiting someone else to write a new language to your specifications. I
suspect that you will not find anyone willing to do that here. Therefore, I
suggest that you take what is the time honored path in open source software:
do it yourself.
···
On Tuesday 01 October 2002 1:19 pm, William Djaja Tjokroaminata wrote:
objc is just 4 years older than nextstep (and ~15 years older than