Question about 2005 Ruby critique...

Discussion in 'Ruby' started by barcaroller, Sep 24, 2007.

  1. barcaroller

    barcaroller Guest

    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
    barcaroller, Sep 24, 2007
    #1
    1. Advertising

  2. barcaroller

    Chad Perrin Guest

    On Tue, Sep 25, 2007 at 06:50:09AM +0900, barcaroller wrote:
    > 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.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    Patrick J. LoPresti: "Emacs has been replaced by a shell script which 1)
    Generates a syslog message at level LOG_EMERG; 2) reduces the user's disk
    quota by 100K; and 3) RUNS ED!!!!!!"
    Chad Perrin, Sep 24, 2007
    #2
    1. Advertising

  3. barcaroller

    Marc Heiler Guest

    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 ... ;-)
    --
    Posted via http://www.ruby-forum.com/.
    Marc Heiler, Sep 25, 2007
    #3
  4. barcaroller

    Bill Kelly Guest

    From: "barcaroller" <>
    >

    [...]
    > 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
    Bill Kelly, Sep 25, 2007
    #4
  5. On 9/24/07, barcaroller <> wrote:
    > 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.
    Wilson Bilkovich, Sep 25, 2007
    #5
  6. > 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
    Gaspard Bucher, Sep 25, 2007
    #6
  7. barcaroller

    Chad Perrin Guest

    On Tue, Sep 25, 2007 at 03:58:09PM +0900, Gaspard Bucher wrote:
    >
    > 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.

    --
    CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
    Baltasar Gracian: "A wise man gets more from his enemies than a fool from
    his friends."
    Chad Perrin, Sep 25, 2007
    #7
  8. barcaroller schrieb:
    > 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
    Michael Neumann, Sep 25, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Fao, Sean

    Critique Request: CheckBoxColumn

    Fao, Sean, Feb 15, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    508
    Fao, Sean
    Feb 15, 2006
  2. Ike

    Pls critique

    Ike, Oct 1, 2003, in forum: Java
    Replies:
    1
    Views:
    438
    John C. Bollinger
    Oct 1, 2003
  3. Cynthia Turcotte

    critique request

    Cynthia Turcotte, Sep 12, 2003, in forum: HTML
    Replies:
    7
    Views:
    464
    Chris Leonard
    Sep 13, 2003
  4. rubist __

    Ruby/Tk code critique

    rubist __, Jul 28, 2006, in forum: Ruby
    Replies:
    1
    Views:
    122
    Hidetoshi NAGAI
    Jul 28, 2006
  5. voipfc
    Replies:
    0
    Views:
    120
    voipfc
    Oct 11, 2006
Loading...

Share This Page