Larry Wall's comments on Ruby

ruby-talk
1

Mon, 9 Sep 2002 14:26:37 +0900, Wirianto Djunaidi ryo_saeba_009@yahoo.com pisze:

Totally agree. It’s the same case as with the 5.cos
doesn’t make sense because cos(), sin(), etc…are not
behaviour of a number in regular sense. Those are
trigonometry functions which applied on those numbers.

The problem is that Ruby couples the syntax of the call with the way
the function is dispatched.

The distinction between “intrinsic behavior” and “external function” is
fuzzy. Why are trigonometric functions more external than arithmetic?
What about exp, sqrt and abs?

If a function should be implemented differently based on types
of arguments, the Ruby way is to make it a method of one of the
dispatched arguments (and it fails to provide means to dispatch on
several arguments). Mathematical functions above should be dispatched
(some even on several arguments), so basing on this principle they
should be methods of numbers.

It makes the notation unfamiliar - that’s how Ruby’s syntax looks
like. These method calls could be wrapped in functions like module
Math currently.

A problem in making all functions methods of the class of their most
important argument is IMHO the largest flaw in Ruby: that all method
names of the given class are put in a single namespace! And class
names generally too.

I know that it would otherwise not fit the way method calls are
designed. This is a reason why I’m not a fan of the model.

For me names defined in a module (i.e. file) should by default be
local to this module. When several modules independently define
the same name (function or class), even at their top levels, they
should not conflict. And the natural place to put functions should
distinguish functions defined by independent modules. In Ruby the
place is the class of the most important argument and the name must
be unique within a class…

Types can be dynamic; scopes should be static. When I refer to the name
of an operation, dispatched or not, it should be explicitly imported
from somewhere or introduced locally, not pulled from some global
namespace - so names can be given without worrying about conflicts
with other modules.

···

–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.

2

Hi,

A problem in making all functions methods of the class of their most
important argument is IMHO the largest flaw in Ruby: that all method
names of the given class are put in a single namespace! And class
names generally too.

I’m not sure if you’re talking multi-method like one in CLOS, or other
namespace issue.

I don’t take multi-method just because it does not fit in traditional
OO model, which I prefer. A method does not belong particular class
anymore.

If you’re talking about namespace, tell more concretely please.

						matz.
···

In message “Re: Larry Wall’s comments on Ruby” on 02/09/10, Marcin ‘Qrczak’ Kowalczyk qrczak@knm.org.pl writes:

3

“Marcin ‘Qrczak’ Kowalczyk” wrote in
…

The problem is that Ruby couples the syntax of the call with the way
the function is dispatched.

The distinction between “intrinsic behavior” and “external function” is
fuzzy. Why are trigonometric functions more external than arithmetic?
What about exp, sqrt and abs?

The artificial distinction, mathematically it makes little (actually
no) sense (so why should Ruby do it?) between external and
intrinsic Ruby functions is more easily defendable in a language
like Python, where ``self’’ needs to be an explicitly method
argument and would not be an implicitly supplied argument of
every Ruby method call.
I hope that once Ruby gets proper namespace support we will
also see the end of the Java’ish module function Math.cos
and it friends.

If a function should be implemented differently based on types
of arguments, the Ruby way is to make it a method of one of the
dispatched arguments (and it fails to provide means to dispatch on
several arguments). Mathematical functions above should be dispatched
(some even on several arguments), so basing on this principle they
should be methods of numbers.

It makes the notation unfamiliar - that’s how Ruby’s syntax looks
like. These method calls could be wrapped in functions like module
Math currently.

A problem in making all functions methods of the class of their most
important argument is IMHO the largest flaw in Ruby: that all method
names of the given class are put in a single namespace! And class
names generally too.

I know that it would otherwise not fit the way method calls are
designed. This is a reason why I’m not a fan of the model.

I agree with you whole heartedly , expect that it really isn’t a failing of
Ruby itself but the single method receiver model Matz and probably
the vast majority of ``Rubyists’’ (imo unfortunately) seem to prefer.

/Christoph

4

Tue, 10 Sep 2002 09:17:42 +0900, Yukihiro Matsumoto matz@ruby-lang.org pisze:

I’m not sure if you’re talking multi-method like one in CLOS,
or other namespace issue.

Both, they are related.

In the Ruby model methods are anonymous names with no associated
data and the receiver alone is sufficient to understand a method,
so method names are distinguished by apperance rather than identity.
Although it would be possible to extend method names to include
explicitly generated fresh symbols (that you must import from somewhere
in order to send), it would introduce awkwardness not present before,
just to be safe wrt. namespaces, so it wouldn’t be accepted.

In my CLOS-like model methods are fully-fledged objects existing
outside their receivers, so it’s natural that you explicitly create
them somewhere. A method belongs to the module which introduced it.
You explicitly import modules anyway in order to call functions
defined in them. Unqualified name lookup is static.

The problem seems to be real:

···

Date: Tue, 10 Sep 2002 16:33:28 +0900
From: “Shashank Date” ADATE@kc.rr.com
Subject: Re: Rockit problem

[…]
This is due to two conflicting class definitions:

class BoundedLruCache # in rockit/bounded_lru_cache.rb required by rockit
class BoundedLruCache < Hash # in site_ruby/resultcache.rb required by Memoize

So how do I overcome this problem ?

–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.

5

“Yukihiro Matsumoto” wrote
…

Marcin ‘Qrczak’ Kowalczyk wrote

A problem in making all functions methods of the class of their most
important argument is IMHO the largest flaw in Ruby: that all method
names of the given class are put in a single namespace! And class
names generally too.

I’m not sure if you’re talking multi-method like one in CLOS, or other
namespace issue.

I don’t take multi-method just because it does not fit in traditional
OO model, which I prefer. A method does not belong particular class
anymore.

However (multi)-methods could belong'' to several (specified) classes. This does seem to be very popular and is certainly more difficult to implement but I find this much more natural than the traditional OO-model. The most prominent example, is the completely unnatural choice of the left summand as a method receiver in additions a + b’'.

/Christoph

6

I hope that once Ruby gets proper namespace support we will
also see the end of the Java’ish module function Math.cos
and it friends.

It should be possible to write a little module to mix
in methods into Numeric (I suppose) which would do the
same thing.

If I were a little smarter or less lazy, I’ll bet I could
do this in fewer than ten lines of Ruby (by writing a little
routine to take a symbol and create the new Numeric#foo
based on the old Math.foo and then passing in the list of
methods :sin, :cos, etc.).

A problem in making all functions methods of the class of their most
important argument is IMHO the largest flaw in Ruby: that all method
names of the given class are put in a single namespace! And class
names generally too.

I know that it would otherwise not fit the way method calls are
designed. This is a reason why I’m not a fan of the model.

I agree with you whole heartedly , expect that it really isn’t a failing
of
Ruby itself but the single method receiver model Matz and probably
the vast majority of ``Rubyists’’ (imo unfortunately) seem to prefer.

This is very interesting to me, as the only OO I know
is single-receiver. Can you explain the paradigm? A
URL would suffice.

Hal

···

----- Original Message -----
From: “Christoph” chr_news@gmx.net
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Monday, September 09, 2002 10:13 PM
Subject: Re: Larry Wall’s comments on Ruby

7

[…]

It should be possible to write a little module to mix
in methods into Numeric (I suppose) which would do the
same thing.

class Numeric
[:sin, :cos, :tan, :log, :log10, :exp, :sqrt].each do
> meth |
module_eval <<-EOF
def #{meth}
Math.#{meth}(self)
end
EOF
end
end

Personally, I still prefer the traditional function notation.

		Reimer Behrends
···

Hal E. Fulton (hal9000@hypermetrics.com) wrote:

8

Hi,

···

In message “Re: Larry Wall’s comments on Ruby” on 02/09/10, “Christoph” chr_news@gmx.net writes:

I don’t take multi-method just because it does not fit in traditional
OO model, which I prefer. A method does not belong particular class
anymore.

However (multi)-methods could belong'' to several (specified) classes. This does seem to be very popular and is certainly more difficult to implement but I find this much more natural than the traditional OO-model. The most prominent example, is the completely unnatural choice of the left summand as a method receiver in additions a + b’'.

Multi-method is kinda like multiple inheritance. It is natural
extension of the original concept. It is theoretically clean. But it
is easy to make thing too complex with them. Only smart people can
use their full power. If you see no problem, it’s because you’re
smarter than me. :wink:

						matz.
9

However (multi)-methods could belong'' to several (specified) classes. This does seem to be very popular and is certainly more difficult to implement but I find this much more natural than the traditional OO-model. The most prominent example, is the completely unnatural choice of the left summand as a method receiver in additions a + b’'.

/Christoph

I’m not convinced that it’s unnatural. We don’t know the types of a and
b, and for some objects a and b, a + b != b + a.

I’m interested what you think the alternative is, or an argument against
the above, and how you would like to see a + b defined in Ruby.

Gavin

10

I agree with you whole heartedly , expect that it really isn't a failing

of

Ruby itself but the single method receiver model Matz and probably
the vast majority of ``Rubyists'' (imo unfortunately) seem to prefer.

This is very interesting to me, as the only OO I know
is single-receiver. Can you explain the paradigm? A
URL would suffice.

Look at "parasitic" methods [ruby-talk:17875], but there are very good
reasons to don't introduce these methods in ruby.

Guy Decoux

11

[…]

It should be possible to write a little module to mix
in methods into Numeric (I suppose) which would do the
same thing.

class Numeric
[:sin, :cos, :tan, :log, :log10, :exp, :sqrt].each do
> meth |
module_eval <<-EOF
def #{meth}
Math.#{meth}(self)
end
EOF
end
end

Personally, I still prefer the traditional function notation.

Yeah… what he said. :slight_smile:

Hmm, ten lines exactly.

Thanks…

Hal

···

----- Original Message -----
From: “Reimer Behrends” behrends@cse.msu.edu
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Monday, September 09, 2002 10:53 PM
Subject: Re: Larry Wall’s comments on Ruby

Hal E. Fulton (hal9000@hypermetrics.com) wrote:

12

I find that highly unnatural because we’ve been learning since grade school
that a + b = b + a.

If the objects don’t satisfy that property they should be using a different
symbol.

···

On September 10, 2002 04:38 am, Gavin Sinclair wrote:

I’m not convinced that it’s unnatural. We don’t know the types of a and
b, and for some objects a and b, a + b != b + a.

I’m interested what you think the alternative is, or an argument against
the above, and how you would like to see a + b defined in Ruby.

Gavin

–
To call me “awesome” is an understatement.

13

“Yukihiro Matsumoto” wrote in
…

Multi-method is kinda like multiple inheritance. It is natural
extension of the original concept. It is theoretically clean. But it
is easy to make thing too complex with them. Only smart people can
use their full power. If you see no problem, it’s because you’re

Why, shouldn’t I use something if I am not smart enough to use (or
understand) it to its fullest extend. A lot of people are using C++, Pythons
multiple inheritance and I doubt that they are all geniuses …

smarter than me. :wink:

I guess not seeing any problems translates into being foolish (well
I am a complete fool anyway;-) … seriously trying to bolt multi-dispatch
onto Ruby might turn out to be a complete disaster or something
really wonderful?

/Christoph

14

On 10 Sep 2002, at 19:37, ts wrote about multi-methods:

Look at “parasitic” methods [ruby-talk:17875], but there are very
good reasons to don’t introduce these methods in ruby.

Guy,

could you please talk a little bit about those reasons? Maybe they
are in the article you mentioned, but I don’t have access to it.

Regards,
Pit

15

matz@ruby-lang.org (Yukihiro Matsumoto) writes:

Hi,

I don’t take multi-method just because it does not fit in traditional
OO model, which I prefer. A method does not belong particular class
anymore.

However (multi)-methods could belong'' to several (specified) classes. This does seem to be very popular and is certainly more difficult to implement but I find this much more natural than the traditional OO-model. The most prominent example, is the completely unnatural choice of the left summand as a method receiver in additions a + b’'.

Multi-method is kinda like multiple inheritance. It is natural
extension of the original concept. It is theoretically clean. But it
is easy to make thing too complex with them. Only smart people can
use their full power. If you see no problem, it’s because you’re
smarter than me. :wink:
Sorry I do not like this smarter than anyone else stuff. even with a
:wink: You do not have to use multiple inheritance if you do not like
it. You do not have to use Multimethods if you don’t like it. And you
can avoid using a lot of other thing if you do not like them.

But it’s your (the programmers) choice. If the langauge does not offer
those facilities you simply do not have a choice.

I would think that having the choice is a good thing. Otherwise we
could all get alond with castrated languages, where you fight the
langauge and do not do what you really should do, solving a problem
(not related to the language)

Another counterexample of not giving people a choice have I written
down here:
http://www.wikiservice.at/dse/wiki.cgi?SpracheEiffel

I do not have the mentioned problem with Ruby. I do not have it in
Common Lisp but I do had have it in Eiffel.

Having too restrictive tools restricts you too.

Regards
Friedrich

···

In message “Re: Larry Wall’s comments on Ruby” > on 02/09/10, “Christoph” chr_news@gmx.net writes:

16

class Numeric
Math.singleton_methods.each do
> meth |
module_eval <<-EOF
def #{meth}
Math.#{meth}(self)
end
EOF
end
end

10 lines…but works with all methods defined in Math (some new ones
added in 1.7).

-rich

···

-----Original Message-----
From: Hal E. Fulton [mailto:hal9000@hypermetrics.com]
Sent: Monday, September 09, 2002 11:57 PM
To: ruby-talk ML
Subject: Re: Larry Wall’s comments on Ruby

----- Original Message -----
From: “Reimer Behrends” behrends@cse.msu.edu
Newsgroups: comp.lang.ruby
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Monday, September 09, 2002 10:53 PM
Subject: Re: Larry Wall’s comments on Ruby

Hal E. Fulton (hal9000@hypermetrics.com) wrote:
[…]

It should be possible to write a little module to mix
in methods into Numeric (I suppose) which would do the
same thing.

class Numeric
[:sin, :cos, :tan, :log, :log10, :exp, :sqrt].each do
> meth |
module_eval <<-EOF
def #{meth}
Math.#{meth}(self)
end
EOF
end
end

Personally, I still prefer the traditional function notation.

Yeah… what he said. :slight_smile:

Hmm, ten lines exactly.

Thanks…

Hal

17

Hello –

···

On Tue, 10 Sep 2002, nico wrote:

On September 10, 2002 04:38 am, Gavin Sinclair wrote:

I’m not convinced that it’s unnatural. We don’t know the types of a and
b, and for some objects a and b, a + b != b + a.

I’m interested what you think the alternative is, or an argument against
the above, and how you would like to see a + b defined in Ruby.

Gavin

I find that highly unnatural because we’ve been learning since grade school
that a + b = b + a.

If the objects don’t satisfy that property they should be using a different
symbol.

On the other hand, in grade school you probably weren’t adding
strings.

David

–
David Alan Black | Register for RubyConf 2002!
home: dblack@candle.superlink.net | November 1-3
work: blackdav@shu.edu | Seattle, WA, USA
Web: http://pirate.shu.edu/~blackdav | http://www.rubyconf.com

18

I find that highly unnatural because we’ve been learning since
grade school
that a + b = b + a.

If the objects don’t satisfy that property they should be using a
different
symbol.

Quite a change for existing ruby for that.

a = “foo”
b = “bar”

puts (a + b)
puts (b + a)

···

=====

Use your computer to help find a cure for cancer: http://members.ud.com/projects/cancer/

Yahoo IM: michael_s_campbell

Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute

19

nico wrote:

···

On September 10, 2002 04:38 am, Gavin Sinclair wrote:

I’m not convinced that it’s unnatural. We don’t know the types of a and
b, and for some objects a and b, a + b != b + a.

I’m interested what you think the alternative is, or an argument against
the above, and how you would like to see a + b defined in Ruby.

Gavin

I find that highly unnatural because we’ve been learning since grade school
that a + b = b + a.

If the objects don’t satisfy that property they should be using a different
symbol.

No way. For example, product is commutative only up to complex
numbers. If you move on to quaternions, you get a noncommutative
product. And as for noncommutative sum … think for example about
strings. “a” + “b” != “b” + “a”

–
Giuseppe “Oblomov” Bilotta

“E la storia dell’umanità, babbo?”
“Ma niente: prima si fanno delle cazzate,
poi si studia che cazzate si sono fatte”
(Altan)
(“And what about the history of the human race, dad?”
“Oh, nothing special: first they make some foolish things,
then you study which foolish things have been made”)

20

Ummm… with a string, a + b != b + a; yet this is to be expected. I
did a quick Google on “non-commutative addition” and came up with

http://www.cut-the-knot.com/do_you_know/addition.shtml

This says that addition is often required to be commutative, but
not always.

-austin
– Austin Ziegler, austin@halostatue.ca on 2002.09.10 at 14.02.11

···

On Tue, 10 Sep 2002 23:31:40 +0900, nico wrote:

On September 10, 2002 04:38 am, Gavin Sinclair wrote:

I’m not convinced that it’s unnatural. We don’t know the types of
a and b, and for some objects a and b, a + b != b + a.

I’m interested what you think the alternative is, or an argument
against the above, and how you would like to see a + b defined in
Ruby.
I find that highly unnatural because we’ve been learning since
grade school that a + b = b + a.

If the objects don’t satisfy that property they should be using a
different symbol.