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?
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+)/} <>;
They tend to get a hair upset. It's not that they have to stare at this
any longer than they have to stare at the equivalent in C or C++ or
Java, but that they have this understanding of "how long it should take
to read a line of code," without respect to the semantic content of the
line.
In this one line we have (yeah, I know you can all read it, but I'm
going to list the components so that we stop and think about them) the
equivalent of a block of code with three loops (a read loop, a
match/store loop, and a hash builder loop), along with the implicit
behavior of <> over the pseudo-filehandle ARGV, along with the implicit
behavior of m/.../ in a list-context.
Write that in C and it would be a LOT of code (depending on the toolkits
you used).
Which one is easier to read? I'd argue that the Perl is much easier to
read, but that's only IF you know Perl well enough that you can absorb
such semantic complexity at a glance.
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.
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
