http://www.perlmonks.org?node_id=614815


in reply to What's wrong with Perl 6?

There is one thing that IMHO is bad about Perl 6 now. It is an arguable fact, and many will disagree - but as the OP asked, I am just expressing a personal opinion.

Perl 6 looks to me to be inferior to Ruby 1.8 in many aspects, especially in overall cleanness and natural OOP.

For example, while I read the article titled Perl 6 Now (from Perl.com), I couldn't help thinking to myself how every bit of code would be done in Ruby and reaching the conclusion that it would be much cleaner.

Perl 5 has 3 strong pros against Ruby: CPAN, the community and performance. The performance of Perl 6 would be arguably comparable to Ruby. If it runs on Pugs, it will probably be even slower. On Parrot, Ruby can run too (besides the fact that Ruby has a new VM that makes it much faster, almost ready). CPAN will have to be translated to Perl 6 anyway, sooner or later. And Ruby is quickly catching on in this area. The community is a huge plus that is hard to change. It is sad to have a much better community for an inferior language, but I hope this will change too, sometime.

Replies are listed 'Best First'.
Re^2: What's wrong with Perl 6?
by chromatic (Archbishop) on May 11, 2007 at 07:29 UTC

    Are you serious?

    Maybe Ruby 3.0 will address the allomorphic problem with duck typing. Maybe.

    Maybe Ruby 3.0 will add continuations and coroutines back into the language.

    Maybe Ruby 2.5 will add a native calling interface.

    Maybe Ruby 3.0 will interoperate with several other languages (but by that point we'll call it Cardinal).

    Maybe Ruby 3.0 will add multiple dispatch, and multiple blocks to a function, and automatic currying, and optional typing, and built-in laziness, and asynchronous IO, and parellelizable hyperoperators, and constrained types, and finally fix the require mess.

    Maybe Ruby 4.0 will add junctions.

    The only problem is that no one has announced Ruby 3.0 yet, so I'm just guessing at when the Ruby developers will start to think about some of the nice features of Perl 6. Meanwhile, maybe Ruby 2.0 will come out before Perl 6. Maybe.

[reply]
[d/l]

      And while we are in the maybes

      • Maybe Ruby will get a little bit more clever in letting me spread a statement over several lines without jumping through hooooooops that much.
        x = 1 + 2
 + 3
puts x

        [download]
        prints 3. That's kinda what I'd expect from a language that more or less uses the newline character as the statement terminator. But even 
        x = (1 + 2
 + 3)

        [download]
        prints 3. (Sorry? How???) 
        x = foo(1 + 2
 + 3)

        [download]
        on the other hand errors out with "syntax error, unexpected tUPLUS, expecting ')'". Lovely. Choose between the two ugly options 
        x = foo(1 + 2 +
 3)

        [download]
        and 
        x = foo(1 + 2 \
 + 3)

        [download]
      • Maybe sometime in the future it will get sensible error messages. "unexpected tUPLUS"? What the f..k? And that's one of the least cryptic I've seen.
      • Maybe in a few years the Ruby folk gets through the discussion that was hot in the Perl community some eight years ago and add variable declaration and use strict. (There is currently no way to know whether an "x" used in a block is a new local one or shared with a bigger scope. And no way to specify that. And to make things more interesting the locality of the block parameters is currently context dependent, in the upcomming version they will always be local. Sweet.) Currently all you get is a runtime check that the first thing you do to a variable is some kind of assignment.

      Jenda
      Support Denmark!
      Defend the free world!

[reply]
[d/l]
[select]
        1) The exact syntactical rules don't matter that much, because once you get used to Ruby, it feels natural to write code in a certain way. I'm sure Python is even more unusual from Perl's point of view. I have never had a problem with the problem you present in Ruby. And finishing each intermediary line in a multi-line expression with an operator is a good practice.

        2) Ruby doesn't need 'use strict' the way Perl does, because in Ruby uninitialized variables don't 'spring to life' when referenced. Variables must be initialized before use, otherwise you get an exception. In this sense Ruby is very much like Lisp, and you don't hear people complaining about the lack of the 'strict' module in Lisp.

[reply]
        A reply falls below the community's threshold of quality. You may see it by logging in.
Re^2: What's wrong with Perl 6?
by Arunbear (Prior) on May 11, 2007 at 09:16 UTC
    For example, while I read the article titled Perl 6 Now (from Perl.com), I couldn't help thinking to myself how every bit of code would be done in Ruby and reaching the conclusion that it would be much cleaner.

    Can you show what those examples would look like in Ruby?

[reply]
      I started typing the whole thing but it's too long, so I'll just post the code relevant to my comment. I feel that sigils are unnecessary at all (and they are harmful to my wrists !) 
      ##
## Sigil invariance
##

array = [1, 3, 5, 12, 37, 42]

# I use symbols here, but one can use strings: {'alpha' => 4, 'beta' =
+> 6}
# 
hash = {:alpha => 4, :beta => 6}

third = array[2]

# This would be hash['beta'] when using strings
#
beta = hash[:beta]

# Ruby doesn't slice as a part of syntax - there are special member 
# methods for that. I personally see it as a good thing.
odds = array.values_at(1, 3, 5)
bets = hash.values_at(:alpha, :beta)

      [download]
[reply]
[d/l]

        You like having symbol names automagically spring into existence without even the namespacing protection of different prefixes?

[reply]

In Section Meditations