Aaron Sherman writes:
> On Mon, 2005-03-28 at 13:38, Luke Palmer wrote:
>
> > Your "list mod" idea is interesting, though. I fear that adding too
> > many list operators will start to make us look like Haskell, where we
> > have *extremely* expressive single lines that take an hour to write and
> > an hour to read (I call this "concise hell").
>
> Ah, to have access to the Concise Hell compiler... ;-)
>
> Seriously, if you have a line of code which takes an hour to write and
> an hour to read, is that any better or worse than the equivalent 10
> pages of code that take an hour to write and an hour to read?
Depends on your reading style, but I think it is.
>
> That said, one of Perl's largest PR problems has always been the power
> of the syntax and grammar of the language. When people look at a program
> and see:
>
> my %uid_map = map {/^(\w+):[^:]*:(\d+)/} <>;
That line takes about the average amout of time for me to read, but for
a less experienced programmer, this is exactly what I'm talking about.
And indeed, if you did it in C, it would be a lot longer and more
verbose, even though each line would be easier to read than this one.
To illustrate my point, for the novice, this would be a nicer way to
write that:
my %uid_map;
while (<>) {
my ($key, $value) = /^(\w):[^:]:(\d+)/;
$uid_map{$key} = $value;
}
Five lines instead of one, not ten pages instead of one. And after
having illustrated my point, I see why it's a Good Thing. It forces you
to name things. If the novice does not understand some syntax, he will
be guided by how you name your intermediate variables.
[snip]
> The question is: should you be apologetic and/or fail to follow this
> semantic compression down to its logical conclusion because some people
> will find it off-putting.
>
> I think that in the specific case of Perl 6, the answer is a resounding
> NO for two reasons:
>
> 1. Perl 6 can (dangerous lack of the future subjunctive here)
> introspect to a degree that almost no other language can (some
> functional languages are exceptions here), so writing a "strict"
> module that forces programmers to avoid these semantically rich
> constructs (or limit their use to "reasonable situations") is at
> your fingertips. You could even make it invalid at a parser
> level to chain more than some given number of operations.
> 2. Parrot provides access to Perl 6 code from other languages, so
> if Damian writes some wiz-bang module that everyone in the world
> wants access to, even the people who don't like Perl 6 can do so
> without having to get used to Perl 6. If APL had had Parrot, we
> might all be running APL code to this day.
>
> Because of this, Perl 6 need not apologize for it's APL/Haskell-like
> penchant for semantic compression. It can evolve along the lines that
> Perl 4 and 5 made available to it, and not leave anyone behind.
These are definitely good points. You have to understand that I am
somewhat conflicted about my role in this thread. I am not opposed to
semantic/syntactic sophistication (like `%hash{dims @[EMAIL PROTECTED] = @c`
from
earlier today or your example), but I am opposed to semantic/syntactic
complexity. But you can't have one without the other. For example:
# sophisticated (from Perl6::Placeholders)
my $code = $2;
my $vars = join ",", sort $code =~ m/(\$\^\w+)/g;
my $decl = qq{my($vars)[EMAIL PROTECTED];};
# complex (from my ass)
my $decl = 'my(' . join(',', sort $2 =~ m/(\$\^\w+)/g) . ')[EMAIL
PROTECTED];';
It's the same code. And it's exactly what I illustrated eariler. It's
just that the latter is doing a bunch of unrelated stuff in one line,
and the other is keeping the "semantic units" together... and naming
them.
So I believe that my opposition to operators like `[/]` is that they
lend themselves to both these kinds of code, but the fear comes from the
latter. I don't think I would mind so much if the same operator were
called `chunks` (or even something sane ;-) instead of `[/]`. Because
then you could look it up (maybe we just need a big list of operators
with mnemonics and descriptions like we have for special variables in
Perl 5).
Luke
