Since this horse came back to life, I'm going to give it a good thrashing, and
I've got goons to help me. 

I've asked the Phoenix Perl Mongers for their take on the situation. I've posted
a _completely_ unbiased synopsis of the situation. Here are excerpts from the replies:

Tony's take:

"Rename Perl 6 to something else."

Tony never posts more than a single line in reply to anything but replies to 
everything.
This comment appears to be in response to %foo<<bar>>, the gullimets, and the behavior
of %foo{shift} changing to mean %foo{'shift'} with no reguard for %foo`bar except to
dismiss it.

"Perl 6 i going to end up looking like Morse Code. =)"

This was a second, seperate reply, also consisting of a single line. I corrected Tony,
reminding him that Morse Code only has dots and dashes - no gullimets. Ada is the
common analogy, and I reitterated this. Tony then pointed out that he worked at the
Pentagon and many contractors refused to use Ada, holding out with Jovial until after
the Ada push had passed. Funny that now days many government workers hold out 
against other languages, refusing to give up Ada.

Eden's take:

"I like it, but I don't see why perl can't just adopt the dot like Java and C."

I forgot to mention that . was unusable because Perl 6 autoboxes, so this 
misunderstanding
was my fault, not Eden's. Eden went on with a discussion of string concatonation versus
subscripting which made me nod my head. Eden also wanted to know that currying was 
still
going to be there - yes, though it is no longer automatic. 

Andrew's take:

"Scott, I can tell you without hesitation that I /hate/ this.  Mostly for
the cons you've already specified."

"I agree wholeheartedly here, and with the poster that said, "call it
something besides Perl 6.""

In a later post, Andrew conceded that %hash`foo isn't really more complex
(I pointed out that it is up in the air whether %hash`foo is more or less
complex), and goes on to say:

"True, and I do generally like JavaScript, and do like that syntax
feature.  OTOH, it also looks a bit like PHP, and I generally hate PHP." 

I've attached my summerized pros and cons at the end for reference. Andrew writes 
meticulously clean Perl. He went on to express hope for reduction of complexity
and fewer synonyms in Perl 6. 

Doug's take:

"Personally, I don't mind typing the {} [edited], so I don't particularly feel the
need for extra syntax." ... "I probably just won't use the new syntax."

The "new syntax" was used to describe %foo`bar specifically. Doug is the head 
Perl monger and an unfailing voice of reason.

Victor's take:

"I've worked in APL.  Terse is *not good*.  (Although having
matrix inversion built into the language definitely rocks.)"

"Sign me "stuck in the mud".  If the mud is Perl 5.8, it's not
half bad."

Victor wrote a two page email that was interesting and entertaining.
I've attached a slightly edited version to the end of this document.

Michael's take:

"... I'd vote against using backtick
in this instance. For one thing, it'll throw my editor's syntax
coloring off, because it assumes that you'll always have a matched  
pair. :-)"
 
"In general, though, I'm with the group that says "there's nothing wrong
with being verbose". I'd rather have a clear %foo{bar()} and
%foo{'bar'} which fit my existing ideas of programming syntax* than
something involving single quote marks."
 
"But, TMTOWTDI, and since I'll never use the single backtick in any
related context, it really doesn't matter for my personal coding."

Michael went on to praise Perl, in its current incarnation, for still being 
readable by programmers of other languages, citing ==, =, "", and so on,
concluding that standard usage of symbols is a Good Thing, even though it
stretches the use of the symbols a bit.

Michael also writes Java and has shown disposition towards clean code,
having done an excellent presentation on writing tests as a way to
life and increased productivity.

Summary:

I'm doing this as an experiment towards community interest - both generating
it and making it visible.

Unlike PerlMonks or IRC, Phoenix Perl Mongers is a reasonable representation of
people who use Perl - PerlMonks, IRC, and lists tend to attract power users, 
academiacs, and hackers. 

This makes Phoenix Perl Mongers an interesting test bed. They're largely 
professional Perl programmers. They show up to presentations that expose how 
other companies are using Perl, share time saving techniques, and explain
how difficult problems were solved. Examples of production code draw
crowds. Academic topics and advanced features are less interesting, but there
is an interest in how things are done outside of the Perl world.

5 people believe they wouldn't use %foo`bar. 1 person likes it. Resolve not
to use it seemed to be the common message. Only a few people hinted that they
would prefer it not be in the language at all, suggesting that there are too
many ways (or agreeing with that point in the Cons). More people cited TMTOWTDI
than complained of too many ways to do it or a desire for simplicity.

I won't lie - I hoped to see more people voicing support for this, but 
I wasn't dissapointed with the replies.

I expected more people to be following the summaries and have specific opinions
about Perl 6. I found they were happy to form an opinion when asked, but people
weren't aware of even gross points from apocalypses, leading to several short
tangent threads. They also came up to speed very quickly, immediately realizing
implications as facts were pointed out. 

This isn't the first time Perl 6 concepts have been presented directly to the
general Perl-using public. Damian was in the state once, and there are 
articles on ora.com from presentations at London.pm where people were suspicious
and hesitant. People expect bad news and aren't too suprised when they see
something that looks like it (despite the "good news for good people" theme
of the apocalypses, which they haven't read). I think this effect can be
minimized by actively sociliting opinions and summerizing them - people will
be given an incentive to keep their knowledge current, and they'll feel as
though they're part of the process. By feeling as though you're part of
the process, you're more likely to do something that someone part of the
process would do. Of course, users should not dictate the design of a 
product - a topic that Dilbert often deals with. Still, a sort of
thermometer to take the community's pulse may break down tensions on both
ends. If I summarize and post Phoenix.pm comments in the future it will
be in the interest of fostering a sort of a Perl 6 community, or atleast
the feeling of it (but what is community but a feeling? You pay extra to live
in a development designed to have a feeling of community with no intention
of ever communicating with your neighbors except to complain about them
parking in the street at the next neighborhood association meeting - myself,
I paid extra not to have such a community and I've found the other people
avoiding a community in the same way are much nicer people - so perhaps
people don't want a sense of community foistered onto them - specifically,
I'm sure people on the list are hearing "call it something other than Perl!"
more than they'd like, but remember, people are also saying it more than they'd
like to be, or more than they need to be).

-scott

Supplemental material:

Cons from my original request to phoenix-pm-list:

* %foo`bar doesn't look like a hash subscript if you're used to %foo{'bar'}

* Could be used to write really terse code

* Ugly

* Perl 6 already has 2 ways to subscript hashes now, 3 is too many

* People who really want something like that can extend the language using Perl 6's
equivilent to source filters

Pros were approximately as I've already published here.

Original description send to the phoenix-pm-list:

It was recently proposed in Perl 6 that %foo{bar} would now always mean %foo{bar()}
rather than %foo{'bar'}. This is part of the general move away from barewords.
This also surprises some people as things like my $foo = shift; means shift(),
not 'shift', so Perl's general tendencies are reversed in hash subscripts. This 
is usually the right thing to do but requires programmers to be aware of it. 
So %foo<<bar>> and a difficult to explain how to type UNICODE version with 
gulimets where the << and >> are each one character does the same thing as 
%foo{'bar'}. [Examples ommitted]
 
Victor's email, edited:

> I'm definitely wit'cha on that one, Tony.
>  
> I've been coding in Perl for 10 years now.  I came from
> a long background in ALGOL, COBOL, PL/I and C with 
> forays into a few other languages -- Prolog, Lisp, 
> APL in all its terse Greek glory, VB, Honeywell's
> proprietary "tex", Euler, ADA and yes, even JOVIAL.
>  
> I never did anything in all those other languages that
> couldn't have been done more effectively in my little
> corner of Perl 5.8, except for the tiny set of problems
> that needed to be coded to the bare metal in ALGOL or C.
> And Perl might have even done better in those cases.
> Note that some people think like mathematicians and can
> say an enormous amount in a few symbols.  They can fly
> spaceships to Neptune without error, but heaven help
> anyone who tries to read the stuff.
> 
> Others are verbal types and, like me, think in prose. 
> Besides that, I'm a little slow.  So I like code that says
> exactly what it's doing, and doesn't take too much detective
> work to figure out what I'm looking at.
> 
> ...
> statements into multiple lines if necessary, with continuations
> nicely indented, so I have no problem with 
> $this_hash{'that_subscript'} or with $object->function().
> 
> I find that a *small* subset of Perl just does too much too well
> for me to stray into academic vortices, innovatio ad naseam.
> The proposed book cover says it all for me:
>   <http://onestepback.org/articles/usingruby/images/p6_cover.gif>
> 
> I don't mind hashes of function references or fairly
> complex regexp code, but in general I take it one step
> at a time and don't need "more than one way to do it".
> I'll even dare to say that your way is *wrong* if you drag in
> Yet Another Library so you can code your program in some
> "language" other than Perl. 
> 
> Specifically, the << >> and backtick things are YOOgly, and I
> won't go there unless *ordered* to on pain of termination.
>  
> I've worked in APL.  Terse is *not good*.  (Although having
> matrix inversion built into the language definitely rocks.)
> 
> Sign me "stuck in the mud".  If the mud is Perl 5.8, it's not
> half bad.
> 

Reply via email to