Question about 2005 Ruby critique...

[barcaroller]

I come from a C/C++/Perl background and I have been reading up on Ruby for a
while (no hands-on experience yet, except for a few tutorials). Most of the
stuff sounds/looks very positive but I recently found this critique of the
Ruby language on the web and I was wondering whether these statements have
any validity at all.


========================================
Ruby: better than Perl - but what isn't?
----------------------------------------

Ruby is the second-most vulgar programming language in wide usage. It
succeeds at its intended goal of being better than Perl, but its design
manifests a total ignorance of basic programming language theory.

Updated 9 January, 2005: Bruce Eckel apparently isn't bowled over, either.

Ruby's creator, Yukihiro "matz" Matsumoto, crossed the Perl language with
Smalltalk-inspired OO features including a fully-unified type system and
closures, then added exception handling and simulated multi-threading. The
result is certainly an improvement over Perl, but it is terribly
disappointing as a language.

The main philosophy of Ruby seems to be, "Side-effects rock!" We can
probably blame the C language for blurring the distinction between
imperative and applicative code. Maybe that blurring makes some amount of
sense for C, which is essentially a high-level assembly language. However,
languages such as C++, Java, and Perl have carried that foul practice
forward. And now Ruby takes it to new heights: every statement is an
expression, and every expression is a statement. Every method is a
procedure, and every method also is a function. Functions and expressions
with side-effects abound in Ruby.

Worse, Ruby exalts global side-effects. In a nominally multi-threaded
language, this is unseemly to say the least. As an everyday example, the
statement

x = gets

reads a line and sticks it into x just like you'd probably expect, but it
also has the side effect of sticking the line into the global variable $_.
WTF???

Ruby seems to love the magical global variables carried over from Perl.
There are dozens of them, all with nonintuitive names like $_, $!, $*, and
$~. Yuck. These things get set as side effects, and often are used
implicitly.

Ruby's exception mechanism combines the above failures into an astounding
disaster. When an exception occurs, an exception object is created and
stored into $! which is a global variable. Apparently you aren't supposed
to get exceptions in more than one thread at a time. Updated 9 January 2005:
It turns out that this isn't actually an issue; read the comments for
details.

Ruby also blurs the line between names of variables and methods. The
Uniform Access Principle is an excellent idea. at least in a language where
both variables and methods have to be declared and cannot overlap. But Ruby
allows a symbol to identify both a variable and a method, and the
disambiguation process is best described as eccentric.

Ruby delights in the bizarre usage of operator overloading. "<<" normally
means "left shift", but it also means "here document follows," "append to
string," and "extend array." Other operators have similar illogical
overloadings; for example, the "<" operator not only means "less than" but
also "is a subclass of."

Ruby throws a basic OO principle to the wind by allowing anyone to add
members and methods to an existing class, even outside of the original class
definition. The methods thus added have full access to all other members and
methods, including private ones. The usual term for this is "breaking
encapsulation," although I dislike that term because it misuses the word
encapsulation. A better term is "violation of the Open/Closed Principle," in
that the original class is not kept closed against modifications.

Ruby's multi-threading seems to be a misfeature from tip to toe. Ruby's
multi-threading is simulated: it only runs on a single CPU and is
fundamentally incapable of taking advantage of multiple CPUs or multiple
cores within a CPU. Which is just as well, because Ruby doesn't define a
memory model for coordinating data between CPUs or cores. Then there is the
problem of global variables being changed as side effects and accessed
implicitly. Writing multi-threaded code in Ruby looks like a good way to
cause yourself immense non-deterministic grief.

Ruby code can be written to be very clean and readable-something that cannot
really be said about Perl-but Ruby can also be written just as poorly as
Perl is. Unfortunately, most of the Ruby code that I've seen, including
various introductory guides to the language, seems to prefer the slutty side
of Ruby: procedural code using global variables and magical side effects.
I'm
not sure that I see how Ruby is better than Perl in those cases.

I've written some Perl over the years, and I probably will be transitioning
to Ruby for those tasks. Ruby certainly is better than Perl, especially if
you choose the high road and write clean code that eschews the side effects
and global variables. But I'm not at all happy with Ruby, because it easily
could have been so much better than it is.

Friday, 7 January, 2005

 

[Chad Perrin]

I come from a C/C++/Perl background and I have been reading up on Ruby for a
while (no hands-on experience yet, except for a few tutorials). Most of the
stuff sounds/looks very positive but I recently found this critique of the
Ruby language on the web and I was wondering whether these statements have
any validity at all.


========================================
Ruby: better than Perl - but what isn't?
----------------------------------------

I think that line really says it all. There's a *lot* of stuff that
isn't better than Perl. Perl's a great language, especially within its
particular niches of choice. Ruby is certainly better than Perl at some
things, and Perl is better than Ruby at others. Both are better than
Python at some things. Et cetera.

The so-called critique (more of an attempt at character assassination) is
filled with questionable value judgments without much value outside
personal preferences, presented as facts. I don't think it requires much
addressing beyond pointing out the ridiculous assumptions embodied in
that headline. Further indications that the author has no clue what
he/she is talking about include the implication that Perl doesn't support
closures, that Ruby's functional (read: no side effects) capabilities are
anathema to the language's core design philosophy, that side effects are
necessarily bad, and so on.

With such devastating exercises of logical rigor in making an argument as
"WTF???" and "Yuck," against which I have no defense, I feel I have been
bested on the field of honor. I shall now withdraw.

 

[Marc Heiler]

I think the point about "side effects" is rather weak...

Has anyone ever ran into a side effect that killed his program due to
setting of $_?

The << is a very easy operator in the sense (for me) that it just means
"add this stuff"... its one of the things i liked in C++ a lot.... cout
<< "hello world" << some_var << "\n" (or something, my C++ is so rusty
and i never spent a lot of time with it...)

The < well... he maybe has a very small point there ... it also means
smaller than ... ok, but I dont think this is really any issue at all,
and its short as well
To be honest, I believe the "speed reason", even if I dont care really
how "slow" ruby is anyway - i think that reason would be better than
stuff like "side effects" $_
(The variable names are really non-intuitive and ugly though, i always
use the long version if available... maybe except when one-liners would
matter)

"but Ruby can also be written just as poorly as Perl is."
I think this is a _VERY_ weak point. Basically, everyone can obfuscate
every language! Lets take an expert perl coder that tries to write good
perl code and compare the same to one doing that with ruby. I did so (i
am not at all a perl expert), IMHO the ruby code looks very very clean
and thus beautiful.

I can not say the same about python in this regard to all the extent i
do for ruby, although I'd share that getting rid of the end's is not
that bad at all (but I have a huge problem with the def foobar():, and
the need for the .method() and also implicit self in python ... in ruby
i choose my way and feel free, in python well... ;> )

Just choose the solutions you like and try to opt for clean and brief
ways (if possible). Didnt Larry Wall once wrote that the key to use perl
is, to use its strength, and not its weaknesses? (He must be one of the
funniest programmers alive! )

Anyway, i think python is also a LOT better than perl in this clean-ness
regard, at least I could see myself maintaing python scripts more likely
than perl scripts. But for many problems, getting the problem solved
quickly will suffice. For me I just wanted to have scripts that I look
at a later time in my life again, and I am in big love with ruby's OO
too so ... ;-)

 

[Bill Kelly]

[...]
I recently found this critique of the
Ruby language on the web and I was wondering whether these statements have
any validity at all. [...]

Ruby is the second-most vulgar programming language in wide usage. It
succeeds at its intended goal of being better than Perl, but its design
manifests a total ignorance of basic programming language theory.

Meh. Ruby's design to me represents a rather surprising balance
between expressiveness, orthogonality, consistency, and pragmatism
that few other language designers have been able to achieve.

I really like these slides from matz' oscon 2003 talk.
http://www.rubyist.net/~matz/slides/oscon2003/

To me those slides give a flavor of the qualities and values that
matz had (has) in mind while designing Ruby, and help paint a
picture of how ruby became as fun to program in as it is for many
of us.

The main philosophy of Ruby seems to be, "Side-effects rock!" We can
probably blame the C language for blurring the distinction between
imperative and applicative code.

Yes: Ruby isn't Haskell. Moving on . . .

Maybe that blurring makes some amount of
sense for C, which is essentially a high-level assembly language. However,
languages such as C++, Java, and Perl have carried that foul practice
forward. And now Ruby takes it to new heights: every statement is an
expression, and every expression is a statement. Every method is a
procedure, and every method also is a function. Functions and expressions
with side-effects abound in Ruby.

This seems to be complaining about an aspect of Ruby that I
actually like.

I love that statements are expressions. It's a quite elegant
elimination of an unnecessary distinction in imperative languages,
in my view.

Worse, Ruby exalts global side-effects. In a nominally multi-threaded
language, this is unseemly to say the least. As an everyday example, the
statement

x = gets

reads a line and sticks it into x just like you'd probably expect, but it
also has the side effect of sticking the line into the global variable $_.
WTF???

Ruby seems to love the magical global variables carried over from Perl.
There are dozens of them, all with nonintuitive names like $_, $!, $*, and
$~. Yuck. These things get set as side effects, and often are used
implicitly.

Not to worry. These Perlisms don't tend to get used except in the
case of one-liners. Some folks would rather they were banished
from Ruby entirely, but I like the ability to do concise one-liners
from the shell in Ruby, because it means I don't have to use Perl.

An example of the kinds of one-liners I appreciate being able to
knock off in ruby right from the command prompt:

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/86942

Ruby delights in the bizarre usage of operator overloading. "<<" normally
means "left shift", but it also means "here document follows," "append to
string," and "extend array." Other operators have similar illogical
overloadings; for example, the "<" operator not only means "less than" but
also "is a subclass of."

So because << means "left shift" for integers, it has to mean
"left shift" for strings and arrays and classes too? :duh:

I'd say << is an ideogram. Let it mean something appropriate
in context.

Ruby throws a basic OO principle to the wind by allowing anyone to add
members and methods to an existing class, even outside of the original class
definition. The methods thus added have full access to all other members and
methods, including private ones. The usual term for this is "breaking
encapsulation," although I dislike that term because it misuses the word
encapsulation. A better term is "violation of the Open/Closed Principle," in
that the original class is not kept closed against modifications.

It sounds like the sky is falling. But Ruby's "open classes" are
one of my favorite features.

Yes, one has to be careful, especially when writing library code,
so as not reopen classes in a way that might conflict with other
libraries.

But it's also a very powerful feature. Quoting matz:

| "open class" is so strong (often too strong), we can break things
| easily. In other word, Ruby trust you to give you sharp knives, where
| Python don't. From the Python point of view, it's wrong, I guess.



More on the subject: http://vying.org/blog/2007/05/ruby-and-trust

Ruby's multi-threading seems to be a misfeature from tip to toe. Ruby's
multi-threading is simulated: it only runs on a single CPU and is
fundamentally incapable of taking advantage of multiple CPUs or multiple
cores within a CPU. Which is just as well, because Ruby doesn't define a
memory model for coordinating data between CPUs or cores. Then there is the
problem of global variables being changed as side effects and accessed
implicitly. Writing multi-threaded code in Ruby looks like a good way to
cause yourself immense non-deterministic grief.

There are arguments pro- and con- green threads vs. OS threads.

However, the author's worries about global variables seem to be
entirely misplaced. The variables he's apparently worried about
are thread-local, not global. (Much ado about nothing?)

Ruby code can be written to be very clean and readable-something that cannot
really be said about Perl-but Ruby can also be written just as poorly as
Perl is.

:duh:


Anyway, . . .


Hope this helps,

Bill

 

[Wilson Bilkovich]

I come from a C/C++/Perl background and I have been reading up on Ruby for a
while (no hands-on experience yet, except for a few tutorials). Most of the
stuff sounds/looks very positive but I recently found this critique of the
Ruby language on the web and I was wondering whether these statements have
any validity at all.


========================================
Ruby: better than Perl - but what isn't?
----------------------------------------

Just a single correction here.. I won't bother with the rest..
The "side-effect globals" the author abhors are actually thread-local,
so they don't present a problem for multithreaded code. They just
happen to look like 'regular' globals.

 

[Gaspard Bucher]

The < well... he maybe has a very small point there ... it also means

smaller than ... ok, but I dont think this is really any issue at all,
and its short as well

I think the "smaller then" sign is great. It means "This subclass is a
descendant (smaller/younger) class of this other class."

Child < Parent makes perfect sense.

PS:
(I like the "postmodern mess" of Perl, but it tended to jump back at
me a couple of weeks later. I feel I have the same freedom with Ruby,
with a more secure feeling allowing me to write large applications
without fear. Perl was the first language I felt joyful with. Ruby
took the same path in my heart.)

Gaspard

 

[Chad Perrin]

PS:
(I like the "postmodern mess" of Perl, but it tended to jump back at
me a couple of weeks later. I feel I have the same freedom with Ruby,
with a more secure feeling allowing me to write large applications
without fear. Perl was the first language I felt joyful with. Ruby
took the same path in my heart.)

I like that description of your feelings about Perl and Ruby. I feel
similarly, with the exception that Ruby doesn't really make me feel any
safer than Perl -- because I feel "safe" enough with both. Where Perl
falls down for me, as compared with Ruby, is basically just where object
oriented programming is called for. OOP in Perl is kind of a painful
experience, especially compared with Ruby. On the other hand, there's a
lot of coding that really doesn't have any need for OOP and, in many
cases, might even be made more difficult or otherwise less "good" by
forcing it into an OOP paradigm -- and for that stuff, Perl is still one
of my favorite languages.

 

[Michael Neumann]

I come from a C/C++/Perl background and I have been reading up on Ruby for a
while (no hands-on experience yet, except for a few tutorials). Most of the
stuff sounds/looks very positive but I recently found this critique of the
Ruby language on the web and I was wondering whether these statements have
any validity at all.

Uh, who wrote that? Hopefully not Bruce himself
In short, they are not valid at all (they never were), except the one
with threading (but Ruby is getting native threads soon).

========================================
Ruby: better than Perl - but what isn't?
----------------------------------------

Ruby is the second-most vulgar programming language in wide usage. It
succeeds at its intended goal of being better than Perl, but its design
manifests a total ignorance of basic programming language theory.

Updated 9 January, 2005: Bruce Eckel apparently isn't bowled over, either.

Ruby's creator, Yukihiro "matz" Matsumoto, crossed the Perl language with
Smalltalk-inspired OO features including a fully-unified type system and
closures, then added exception handling and simulated multi-threading. The
result is certainly an improvement over Perl, but it is terribly
disappointing as a language.

This explains the unqualified rest of the text

The main philosophy of Ruby seems to be, "Side-effects rock!" We can

"Side-effects rock" => complete nonsense. A lot of String operations are
side-effect free, and destructive versions are available, denoted with a
"!" at the end!

probably blame the C language for blurring the distinction between
imperative and applicative code. Maybe that blurring makes some amount of
sense for C, which is essentially a high-level assembly language. However,
languages such as C++, Java, and Perl have carried that foul practice
forward. And now Ruby takes it to new heights: every statement is an
expression, and every expression is a statement.

Uh, and statements can't have side-effects? A method/function call is an
almost any language an expression, and has possible side-effects in
almost any imperative language.

I don't see any reason to have statements in a language, when everything
can be an expression. That's a servere limitation of the language if not
"everything is an expression". For example in C/C++/whatever, you have
to write:

i = 1 > 2 ? true : false;

because "if" is a statement. In Ruby:

i = i > 2 ? true : false

or:

i = if i > 2 then true else false end

Every method is a
procedure, and every method also is a function.

Hum, a method is a method. It's not a procedure, and not a function.
Point. Don't understand his reasoning here.

Functions and expressions
with side-effects abound in Ruby.

Worse, Ruby exalts global side-effects. In a nominally multi-threaded
language, this is unseemly to say the least. As an everyday example, the
statement

x = gets

reads a line and sticks it into x just like you'd probably expect, but it
also has the side effect of sticking the line into the global variable $_.
WTF???

Is it really global? Or did he meant thread-local?

The question is, how often do you see code accessing $_ in Ruby. How
many global variable accesses can you find in Ruby's standard library.
Not many. The good thing, they are quite easy to locate in Ruby, using
grep. Not so in C, C++.

Ruby seems to love the magical global variables carried over from Perl.
There are dozens of them, all with nonintuitive names like $_, $!, $*, and
$~. Yuck. These things get set as side effects, and often are used
implicitly.

Again, most of them are thread-local.

Ruby's exception mechanism combines the above failures into an astounding
disaster. When an exception occurs, an exception object is created and
stored into $! which is a global variable.

Complete nonsense. It's thread-local.

Apparently you aren't supposed
to get exceptions in more than one thread at a time. Updated 9 January 2005:
It turns out that this isn't actually an issue; read the comments for
details.

Ruby also blurs the line between names of variables and methods. The
Uniform Access Principle is an excellent idea. at least in a language where
both variables and methods have to be declared and cannot overlap. But Ruby
allows a symbol to identify both a variable and a method, and the
disambiguation process is best described as eccentric.

Has he ever written C++ code?

class Datastructure
{
private:

int _size;

public:

int size() { return _size; }
};


It's so annoying to rename the instance variable to "_size" if you add
an accessor method of the same name to it. God thank, Ruby doesn't has this.

Ruby delights in the bizarre usage of operator overloading. "<<" normally
means "left shift", but it also means "here document follows," "append to
string," and "extend array."

He chooses "extend array" instead of "append to array" by purpose, I
guess

Other operators have similar illogical
overloadings; for example, the "<" operator not only means "less than" but
also "is a subclass of."

Ruby throws a basic OO principle to the wind by allowing anyone to add
members and methods to an existing class, even outside of the original class
definition. The methods thus added have full access to all other members and
methods, including private ones. The usual term for this is "breaking
encapsulation," although I dislike that term because it misuses the word
encapsulation. A better term is "violation of the Open/Closed Principle," in
that the original class is not kept closed against modifications.

class A
def a
end
end
A.freeze

class A
def b
end
end # => TypeError: can't modify frozen class

Where's the problem?

Ruby's multi-threading seems to be a misfeature from tip to toe. Ruby's
multi-threading is simulated: it only runs on a single CPU and is
fundamentally incapable of taking advantage of multiple CPUs or multiple
cores within a CPU. Which is just as well, because Ruby doesn't define a
memory model for coordinating data between CPUs or cores. Then there is the
problem of global variables being changed as side effects and accessed
implicitly. Writing multi-threaded code in Ruby looks like a good way to
cause yourself immense non-deterministic grief.

Seems like his favorite language is Java.
Ruby is getting native-threads in 1.9.

Ruby code can be written to be very clean and readable-something that cannot
really be said about Perl-but Ruby can also be written just as poorly as
Perl is. Unfortunately, most of the Ruby code that I've seen, including
various introductory guides to the language, seems to prefer the slutty side
of Ruby: procedural code using global variables and magical side effects.
I'm
not sure that I see how Ruby is better than Perl in those cases.

I've written some Perl over the years, and I probably will be transitioning
to Ruby for those tasks. Ruby certainly is better than Perl, especially if
you choose the high road and write clean code that eschews the side effects
and global variables. But I'm not at all happy with Ruby, because it easily
could have been so much better than it is.

Friday, 7 January, 2005

He should have informed himself better before writing this. But I think
this blog entry was never intended to appear on ruby-talk.

Regards,

Michael