Whether this is a good thing or not is open to debate. Ruby DSLs, as flexible as they are, still pretty much look like Ruby. That's a valuable asset -- it means once I have a good understanding of how Ruby syntax works, a DSL isn't likely to completely surprise me, whereas with Perl, my source could be run through an arbitrary regular expression.
But it is a limitation, and to duplicate it in Ruby requires games like eval(some_filter(File.read('foo.rb')))
i don't think Perl6 needs any protection, as much as Ruby doesn't also need any. Different languages, different communities, different perspectives...
Few things to note in its favor though: -the redesign is highly influenced by Ruby -it already has more than one implementations -one of its implementation, the Pugs, has a great deal more thoughts about threading than both Ruby and Python -one other implementation, Rakudo, is part of an initial push on the rosetta stone multi-language Parrot VM, which if it turns right could also have a lot of implication for Rubyists.
I find language war is no fun game at all, collaboration always wins in the end
> Whether this is a good thing or not is open to debate. Ruby DSLs, as > flexible as they are, still pretty much look like Ruby. That's a valuable > asset -- it means once I have a good understanding of how Ruby syntax works, > a DSL isn't likely to completely surprise me, whereas with Perl, my source > could be run through an arbitrary regular expression.
> But it is a limitation, and to duplicate it in Ruby requires games like > eval(some_filter(File.read('foo.rb')))
> Greg Donald wrote:
>> I thought some of you might find this humorous.
Louis-Philippe wrote: > Few things to note in its favor though:
Versus what?
> -the redesign is highly influenced by Ruby
Ruby _is_ Ruby, so that's a pointless comparison.
> -it already has more than one implementations
So does Ruby. MRI, JRuby, IronRuby, Rubinius, Maglev...
> -one of its implementation, the Pugs, has a great deal more thoughts about > threading than both Ruby and Python
How so? If the advantage is just the lack of a GIL, JRuby doesn't have a GIL either.
> -one other implementation, Rakudo, is part of an initial push on the rosetta > stone multi-language Parrot VM, which if it turns right could also have a > lot of implication for Rubyists.
Maybe. Except that Ruby is already implemented on several VMs, so this only really matters if a Ruby-on-Parrot port became mainstream -- and even then, you'd probably have some people using JRuby.
> I find language war is no fun game at all, > collaboration always wins in the end
I find language wars are quite fun, done well. It's a kind of collaboration in its own right -- finding weaknesses in a given language could be considered constructive criticism.
For instance, one of the biggest complaints about Ruby was that it's slow. Two responses to that were YARV and Merb. And ultimately, that is collaboration -- YARV became part of Ruby 1.9, and Merb will merge with Rails to become Rails 3 / Merb 2.
> Ruby _is_ Ruby, so that's a pointless comparison.
yes, and Ruby borrowed a lot from Perl, so its good to see some of Ruby going back to Perl
> -it already has more than one implementations
> So does Ruby. MRI, JRuby, IronRuby, Rubinius, Maglev...
bravo!!! I didn't meant to compare it to anything, I am only answering the previous post that a language needs to lives before having a logo... so now you know it already has 2 lives.
> -one of its implementation, the Pugs, has a great deal more thoughts about >> threading than both Ruby and Python
> How so? If the advantage is just the lack of a GIL, JRuby doesn't have a > GIL either.
because Pugs is implemented comes from a very evolved and foreign language, Haskell. Threading is an old problem, lots of solutions are already there. You can read the Pugs author's comment on the subject here: http://www.perlmonks.org/?node_id=580042
> -one other implementation, Rakudo, is part of an initial push on the >> rosetta >> stone multi-language Parrot VM, which if it turns right could also have a >> lot of implication for Rubyists.
> Maybe. Except that Ruby is already implemented on several VMs, so this only > really matters if a Ruby-on-Parrot port became mainstream -- and even then, > you'd probably have some people using JRuby.
I agree, and Parrot is probably not the Holy Grail... but what if people made it this way? especially considering mod_parrot, an all language apache module, if one day it performs great, that would mean a great simplification for web deployment... its is yet to be done, but you never know what people a capable of when they want it.
> I find language war is no fun game at all, >> collaboration always wins in the end
> I find language wars are quite fun, done well. It's a kind of collaboration > in its own right -- finding weaknesses in a given language could be > considered constructive criticism.
you're right... but "done well" is the key in here... gratuitious bashing does not show this... I'm really not saying you did that, but when you throw oil at the fire it is not long before the disrespectful brazier emerges.
> For instance, one of the biggest complaints about Ruby was that it's slow. > Two responses to that were YARV and Merb. And ultimately, that is > collaboration -- YARV became part of Ruby 1.9, and Merb will merge with > Rails to become Rails 3 / Merb 2.
totally agree, and this feels like were finally getting somewhere :D
