Defending Ruby's OOP

[Robert Klemme]

In Smalltalk, if-then-else is a message and messages are objects....

If Ruby is 100% OOP, then what is Smalltalk?

Probably more in the 120% area. ;-)

robert

 

[Enrique Comba Riepenhausen]

Probably more in the 120% area. ;-)

robert

LOL... That makes Smalltalk somehow metaphysical... It's like saying
I am 120% human... That is 20% more human than a human can be....
scary

Enrique Comba Riepenhausen

 

[John Joyce]

LOL... That makes Smalltalk somehow metaphysical... It's like
saying I am 120% human... That is 20% more human than a human can
be.... scary

Enrique Comba Riepenhausen

Smalltalk IS somehow metaphysical! quantum-something.
Ruby is a nice blend like good coffee

 

[Paul Brannan]

But to answer your actual question, your friend is correct. for, case,
do, else, if, etc. are reserved words, not objects. Check your pickaxe
book, page 329.

Blocks are not objects, either, until they are encapsulated into a Proc
object. Methods are also not objects, until they are encapsulated into
a Method object.

Making everything an object makes the language more consistent, but IMO
less natural. In fact, I think OOP isn't very natural, but is beautiful
once you learn it.

Paul

 

[Rick DeNatale]

Smalltalk is the purest OOP language there is and it doesn't **have**
if or unless at all. You know how you can bypass control structures in
Ruby by using blocks and closures instead? In Smalltalk, that's the
only way to do control structures at all. "If" and "unless" don't even
exist in Smalltalk.

Not entirely true.

Yes, in Smalltalk control structures are built using methods on
Booleans and Blocks, and with Block arguments.

On the other hand, most Smalltalk implementations cheat on this.
There's an old VM implementors mantra that you have to cheat so you
have to work hard not to get caught cheating. In practice if:else:
gets compiled down to test and branch bytecodes, with exception
processing to handle the rare case where the receiver isn't a boolean.
Evaluating a block in Smalltalk looks like a message send but in
reality it's usually implemented as optimized byte code sequences
after some analysis. This led to some mystifying code reading. The
old Digitalk Smalltalk had the value method in Block which read

value
^self value

Which sure looks like it should be an infinite loop. In reality, this
code never got executed except when someone did something silly like:

[1 + 2] perform:#value

or maybe less silly by doing this with a stored block.

In this regard, the purest OO language when it comes to control
structures is probably Self, which avoided such hand-crafted
optimizations in favor of dyamically optimized code.

 

[Lloyd Linklater]

Hi,

I've got someone here saying that Ruby (and other languages) can't be
100% object-oriented because if and unless and so on (keywords) are no
objects.

How can I defend the claim that Ruby is 100% OOP?

Yeah, it is just silly. If he has his own definition of 100% OOP, why
not make each character am object? What about font size? I agree with
the earlier post, argue with smarter people.

 

[Peter Booth]

Remind him that Ruby is, of course, superior to all other languages
because it is red.

Hi,

I've got someone here saying that Ruby (and other languages) can't be
100% object-oriented because if and unless and so on (keywords) are no
objects.

How can I defend the claim that Ruby is 100% OOP?

Peter Booth
(e-mail address removed)
917 445 5663

 

[Mike Hamilton]

Hi,

I've got someone here saying that Ruby (and other languages) can't be
100% object-oriented because if and unless and so on (keywords) are no
objects.

How can I defend the claim that Ruby is 100% OOP?

I have to wonder what exactly the benefit of having control structures
as objects would be? The bottom line effectiveness of any language
relates to what one can accomplish with it and how efficiently said task
can be accomplished. Under what circumstance would overriding the "if"
method be beneficial? Not to mention the fact that since Ruby provides
the ability to override things like operators and more functional
components (that can be more logically represented as objects), then why
would the lack of control structure object orientation make Ruby less of
an OO language? Not to mention the kind of trouble that one could easily
get into attempting to override control structures.

 

[John Joyce]

I have to wonder what exactly the benefit of having control structures
as objects would be? The bottom line effectiveness of any language
relates to what one can accomplish with it and how efficiently said
task
can be accomplished. Under what circumstance would overriding the "if"
method be beneficial? Not to mention the fact that since Ruby provides
the ability to override things like operators and more functional
components (that can be more logically represented as objects),
then why
would the lack of control structure object orientation make Ruby
less of
an OO language? Not to mention the kind of trouble that one could
easily
get into attempting to override control structures.

Hmm... there could be some bizarre and interesting possibilities.
For example, instead of if,
why not a construct called 'perhaps' or 'maybe' to include randomness
or other interesting side-effects.
Or even 'occasionally' or 'usually' for weighted randomness.
Adverbs could make very interesting control structures, which could
of course be def'd more (or less) precisely.
Imagine the expressive possibilities of: often, quickly, slowly,
monthly, quarterly, hourly, randomly, quietly, obsequiously,
obscenely, derisively, politely, privately, publicly, etc...
'unless' could be 'other_than' or 'except_if'
'if' itself could be semantically described as the same as 'when' in
many human languages.
Rather than simply being declarative like java keywords, many
constructs could become more descriptive.
This is one of Ruby's biggest strengths, its expressiveness in a very
natural way.

Once it has got the native unicode thing happening, it will be
possible to begin to write Ruby in languages other than English!
Even in Japanese (which would by its grammar, make a very good
programming language)

Some abstraction is bad because it continues to slow things down, but
processing power is still increasing, while human limits are pretty
constant.

 

[Giles Bowkett]

I've got someone here saying that Ruby (and other languages) can't be

Hmm... there could be some bizarre and interesting possibilities.
For example, instead of if,
why not a construct called 'perhaps' or 'maybe' to include randomness
or other interesting side-effects.
Or even 'occasionally' or 'usually' for weighted randomness.

I suppose it could make sense, actually, for a language where you
could patch If objects dynamically with fuzzy logic or Bayesian
back-propagation. Then you could say things like "for certain values
of if" and mean it.

You would have to call a language like that Socrates, I think.

Technically, though, couldn't you build that in Ruby in about twenty
minutes? I think a framework in Ruby for weirdly-patched Boolean logic
would be much quicker to build than the individual weird patches
would. You could just do it with three methods named iif, aand, oor,
and then have them default to standard Boolean implementations of
if/and/or unless alternative implementations were supplied.

--
Giles Bowkett

I'm running a time management experiment: I'm only checking e-mail
twice per day, at 11am and 5pm. If you need to get in touch quicker
than that, call me on my cell.

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org

 

[Giles Bowkett]

Smalltalk is the purest OOP language there is and it doesn't **have**

Not entirely true.

Yes, in Smalltalk control structures are built using methods on
Booleans and Blocks, and with Block arguments.

On the other hand, most Smalltalk implementations cheat on this.
There's an old VM implementors mantra that you have to cheat so you
have to work hard not to get caught cheating. In practice if:else:
gets compiled down to test and branch bytecodes, with exception
processing to handle the rare case where the receiver isn't a boolean.
Evaluating a block in Smalltalk looks like a message send but in
reality it's usually implemented as optimized byte code sequences
after some analysis. This led to some mystifying code reading. The

Wow, that's kind of surprising. So if you wanted to rewrite
Smalltalk's Boolean logic, at that point even Smalltalk wouldn't be
turtles all the way down?

In Smalltalk's defense, dynamically patching Boolean logic is not a
common use case.

--
Giles Bowkett

I'm running a time management experiment: I'm only checking e-mail
twice per day, at 11am and 5pm. If you need to get in touch quicker
than that, call me on my cell.

Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org

 

[Robert Dober]

well, a car fueled by oats would probably be carbon neutral...

One has to be careful about that, it depends how the oat is grown

Oatman
would indeed be as least as eco-friendly as captain planet! Picard's brother?

Robert