Well, I've voiced my opinion on IRC, and I thought it was time to make it stand up on its own. So I wrote a rebuff to Pier's article. The rebuff isn't meant to be against Piers by any stretch, but against where I see Perl 6 going.
Note that the URL above won't be the final resting place, so don't link to it. The article is also in flux, as I'm accomodating feedback from people. So please use the comments facility here to respond.
Rebuttal
wickline on 2001-10-25T13:12:56
disclaimer: I like where perl6 is going, but I certainly respect your dislike of that direction. These comments are intended only to help you clarify your opinion, not to de-value your opinion.
> a number of changes are being made for the
> sake of change. Things that we use a _lot_
> in Perl 5, like '.' for concatenating, and
> the dereference operator are going to change
The fact that they are used a _lot_, and that they are changing, does not mean that they are being changed for the sake of change. One could argue that the '.' is being given new meaning because it is so easy to type that it should be used for something we use constantly. In Perl6, I think you'll find that most code will use the new '.' operator more than it uses the new (concatenation) '_' operator. See also Apocalypse 3 comments re: Huffman encoding
http://www.google.com/search?q=cache:4Qf38IvSsGU:w ww.perl.com/pub/a/2001/10/02/apocalypse3.html+huff man&hl=en
> It's no good if we come up with a fantastic
> syntax that's almost impossible to produce
> a grammar for
actually, many changes in perl6 are motivated by a desire to make perl6 much easier to parse. For example, ?? regexen won't fly, and a great deal of care was put into how to use the colon. Indirect object syntax flakiness from perl5 will go away.
> In all the Apoc's and Eg's I'm yet to see
> a grammar, or part of a grammar, for Perl 6
...but then you won't find one in the camel either. These Apoc's and Eg's are intended to follow the camel book, which didn't include a grammar either. Note that this was not an argument for you to not use perl5, so maybe it shouldn't be an argument for you to not use perl6. I suspect that as more and more Apoc's arrive, the Good Folks on the perl6 lists will begin writing the grammar you're looking for, in order to inform their parsers. Frankly, they're going to have a harder time writing the same for perl5 when they're working on that backwards compatability angle.
> If it's possible for the interpreter
> backend to be able to do $^_ + $^_, then
> it's possible for a module to do that too
Sure. This is entirely a matter of opinion. One could also argue that map and grep should be implemented as modules. Everyone is going to draw their own line as to what they think is appropriate for the language and what should be shoved into modules. I think the hope here is that folks are going to find currying to be just as useful as $_ once they're familiar with it. Maybe you'll never once use it. I know I plan to.
> Perl 6 needlessly populates Perl with syntax
Your opinion. For what it's worth, I'm looking forward to this syntax. I *like* the idea of being able to do all this spiffy stuff without having to wait for the Damians of the world to write a module for me.
> The intent of the second is only clear if
> you know what ^/ means. It's not something
> I've seen in any other language. So how
> would I look up the documentation for this?
> perldoc -f '^/' ?
One could say the same about a great deal of perl5 if one's comming from a non-perl background. Just because you haven't seen it doesn't mean it's not good. Maybe I've never seen regular expressions or the ||= or =~ or !~ operators or the ternary ? : operator or references. That doesn't mean that they're bad. As for how you look up operators, I think you'd look up ^/ the same way you look up ||= in perl5. It's just an operator.
> I believe the former is less obscure.
> It is explicit in its operation
This argument could also be used by a C programmer (or an assembly programmer) to justify their pages and pages of code over the one line regex full of line noise that a perl programmer would rather use. The regex is only more obscure if you don't understand it. However, that should not be a convincing argument against the utility of the regex. Similarly, lack of familiarity with new operators shouldn't be a convincing argument against becoming familiar with them. On the other hand, if you personally don't want to learn them, you don't have to. Plenty of perl5 hackers write mostly perl4 code. I'm sure many perl6 hackers will write mostly perl5 code.
> File test operators are NASTY. We would be
> far better served by something like a stat
> object. Then you just use a schwartzian
> grep to do your tests
I think I understood your points before this one, and I just disagreed. In this case, I don't think I understand. Are you claiming that your four lines ST code is less "NASTY" than
grep { -r -w -x -f $_ } @files
I'm afraid I just don't understand why that is. If you're claiming that the stat method is more efficient, note that the perl6 syntax is not doing four checks against the filesystem. The underlying mechanism uses a stat-type object, so it is just as efficient. In the new syntax, you loose the wrap/unwrap map from the ST construction, and in my opinion the result is much less "NASTY" (not that ST is nasty at all, it's just not necessary in this case with the new perl6 syntax).
I guess I think of it this way. You seem to be advocating an ST where the new syntax would "just do it". I don't understand why. The argument seems to me like saying "grep is just NASTY... we'd be better off using this nice for loop instead".
> Module
You wrote the above re: Binary ';'
Again, a matter of preference. Would you also like to see perl5 slice syntax moved into a module? Personally, I love slices. I'm sure I'm going to love convenient multi-dimensional slices.
> Parsing is a solved problem. Tell me
> again why it should be a core function?
There's a bunch of stuff that's just a royal pain in the ass without core support. One can work around lack of support by implementing your new feature as a source filter and essentially completely re-writing a program to make it do what you want. However, perl6 is a good opportunity to do away with the need for that sort of kludge in some cases. Parsing is a very often tackled with perl, and increasing core support for parsing may be a big win, saving many module authors many many hours of headaches.
> the above can be achieved quite simply
> using eval(), rather than closures
The purpose of the Eg3 was to use perl6. So, doing it the perl6 way is appropriate even if it can be done other ways. If you're saying that eval() is better, I guess that's a matter of opinion. Personally, I cringe every time I have to use eval()... it just feels like a hack for something that should be easier in most cases (for example, error trapping in DBI).
> Another thing that confuses me in the
> above us why is it using
:= instead of
> "sub assert_with_comparator {
... }
It's *calling* the assert_with_comparator function to construct an assertion subref. The result is then assigned with
:= to the sub assert_foo (fill in whichever instance you're looking at).
> And where is it supposed to get the
> function arguments from? Or is this
> using magic special variables again?
Yup. This may still be new and unfamiliar, but that doesn't mean it's bad. People learning perl say almost the same words whenever $_ comes into play (or @_). That doesn't mean that $_ is bad.
> Every OO language I've used has an
> implicit concept of "this" in method
> calls. Why are we trying to be different?
Perl6 also has the same concept. It's not different in that way. However, the concept isn't invoked with
this.method()
but rather with
.method()
Which is different, but in a keystroke-saving sense, much like $_ is different from most languages, and the fact that you don't type *anything* at all to mean $_ in some cases is even more different.
print;
That print statement is *very* convenient. Similarly,
sub method { $.attribute =
.other_method(); }
is much more convenient than
sub method {
my $self = shift;
$self.attribute = $self.other_method();
}
moving on...
> OO baby, OO
>
> geq ($expected, $got)
Ah, but your example doesn't have the precidence of the perl operator eq, and it doesn't have the associativity of an operator. I think you missed the point here. While Damian's example was small and could be trivially replaced by a function, the point is that you could do so much more just as easily. With perl6 you can overload operators much much easier (and more of them). This means that your arbitrary objects can now be compared with normal operators with only a few lines of code and no extra module overhead. And if you want a new operator, creating it takes only a few lines of code... and it *works* like an operator instead of a function. Maybe you want to do matrix math and have cross products and dot products with real operator-type syntax instead of a function call. You wouldn't want to write (for addition)
$result = plus( $this, $that );
so why would you want to write
$result = dot_product( $this, $that );
With perl6 you don't have to... and you can create your own operator for dot_product instead of having to overload an existing one if you want.
> So now we just have to fix perl to do the
> right thing as above.
I don't think I understood your complaint against the proposed trait handling, so I also don't understand why your suggestion is an improvment. Perhaps more details would help?
> I despise the indirect object syntax,
> so I despise the binary :
Perhaps you should avoid using it then.
:) I despise eval(), and use it only when I have to. That doesn't mean it should leave the language. It sounds like you use it more than me, and so it's useful, just not for me.
> there's no reason to change the basic
> syntax in such fundamental ways.
I disagree. There's plenty of reason. Maybe the new features aren't very compelling for you, but they sure are for me (and I'm much less of a Damian than Piers, and in fact am nothing at all of a Damian).
Off to Mexico for a week now
:)
-matt
Re:Rebuttal
Matts on 2001-10-25T13:35:54
OK, one thing that people have seemed to completely miss in my discussion of this is my fundamental objection: Perl 6 won't parse Perl 5.
I accept a lot of your points and take them on board. My point about the file test operators wasn't that I dislike the new syntax - I think it's *much* better than doing tests on the magic underscore. I just dislike the file test operators altogether :-)
You ask if I'd like to see slice and grep moved into a module. Well no, I wouldn't, because they are functions that operate on Perl's fundamental data types. But I *would* like to see things like the networking functions moved into modules.
And you're right, I don't like the idea of using eval() either. It's a hack. I was being overly picky about that. However I didn't find the closure syntax confusing at all. Maybe it's just me :-)
I do think you missed the point about the := being used. Let's look at the code:
&assert_with_comparator := {
unless ($^comparator.($^a, $^b)) {
throw Exception::FailedComparison :
comparator => $^comparator,
result => $^a,
target => $^b
}
}
That's the code I meant, not the assignment code below that. Here we see a block being assigned to the function "assert_with_comparator". So why not use sub assert_with_comparator? Is it just for obfuscation? Secondly, where does the code block get its parameters from? There's no parameters declaration section, so the params appear to be magical. I mean, I know there's no interpreter yet, and so Piers maybe just made a boob on the above, so I'd like to know.
Re:Rebuttal
pdcawley on 2001-10-27T14:54:39
Ah... I think I understand what you mean now. The reason that I can't just do
sub assert_with_comparator {
...
}
Is because I need the automatic currying behaviour, which comes from $^comparator, $^a & $^b ($^foo introduces a named currying parameter, in the same way as $^_)
Maybe
sub (&comparator, $a, $b) is curried {
...
}
will become a valid way of declaring a curried subroutine, but that hasn't been stated yet, so I used the notation that I *know* will work.
