Re^2: What's wrong with Perl 6?

[chromatic]

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.

[Jenda]

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
  

  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)
  

  prints 3. (Sorry? How???)

  x = foo(1 + 2
   + 3)
  

  on the other hand errors out with "syntax error, unexpected tUPLUS, expecting ')'". Lovely. Choose between the two ugly options

  x = foo(1 + 2 +
   3)
  

  and

  x = foo(1 + 2 \
   + 3)
  

• 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.

[spurperl]

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.

[Jenda]

Ad 1) You mean you think

blah = blah blah blah blah blah blah blah blah +
  blah blah blah blblah blah blah blah +
  blah blah blah bla blah blah blahh blablah +
  sdfgdfgdfhfgh

is a good practice? With the operators hidden all the way to the right, each at a different column, forcing you to scan for the end of the lines to find out where does the statement end? Well, up to you. I find this incredibly ugly.

Ad 2) Sorry, no that's not true. All Ruby does is it makes the warnings turned on by use warnings 'uninitialized'; fatal. It has no way whatsoever to catch even something as simple as

 result = foo(...)
 do something with result
 ...
 resutl = bar(...)
 do something with result

There is no way to specify that one assignment is supposed to be "initialization" and another not. Which means that some operations on variables are kinda guarded, others are not. Because they are undistinguishable from intended initializations.

Another problem is that you CAN'T declare a variable as being private for a block. You can only hope you do not stomp on an outer variable accidentaly. Or create an outer variable later and break stuff. At least the block parameters will always be local to the block starting with 1.9, but I still will not be able to start using a variable within a block without having to look elsewhere to make sure it really is a new variable. And no, all methods cannot be those advertised 5 lives long, if only because of data literals.