develooper Front page | perl.perl5.porters | Postings from April 2010

Re: RFC: Perl manual pages -- update to follow the perlstyle.podguidelines

Thread Previous | Thread Next
April 10, 2010 09:37
Re: RFC: Perl manual pages -- update to follow the perlstyle.podguidelines
Message ID:
On Sat, Apr 03, 2010 at 10:44:21AM +0300, Jari Aalto wrote:
> Tom Christiansen <> writes:
> > Believe me, beginners very much want to see parens surrounding
> > function call arguments. After twenty years of teaching them Perl, I
> > long ago came to agree with them. It hurts nothing, and helps much.
> > ... So yes, I do write time() and localtime(). It's a good idea. Trust
> > me.
> So do I where applicaple. I think functions calls like that (with no
> args passed) are better to be distinguishable. But parens get in the way
> in other occasions and the finesse of Perl is to allow writer to reduce
> it.
> It's unfortunate that a language has all kinds of
>     @
>     $
>     %
>     ' <as an old style package level var accessor, before the days of "::">
> Where really, many of the langaues don't need ones for variables. That
> must have been compiler design decisions (optiomization?) at the time of
> past.

Right. And Germans capitalize their nouns to optimize printing presses.

> So in Perl's case I firmly believe that there already is quite a many
> punctuation involved on a line, and adding more of that with "&&" and
> "parens" would not be making the situation better.
>     A side Note: The Agile (XP) paradign favors simplicity. And I tend
>     to agree.

Yeah, if only everyone agreed on which construct is more simple than another.
One might argue that only using "not" and "and" in boolean constructions is
the simplest way. Others will argue the simplest way is the one that uses
the least tokens.

> Anyway, this is all philosophical. Let's nail something down in a spirit
> of consensus.
> > ...You can't expect someone to be able to read a language they don't
> > know how to read: that's worse than ridiculous. There aren't very many
> > people programming in Perl who haven't ever seen shell or awk or C or
> > C# or C++ or Java ...
> I think there is a resemblance. What is easy for the average Joe is also
> easy for the well trained.

Can you back up that claim? Without some evidence, I'm not going to accept
that claim.

>                            There are reasons why those "and" "or"
> keywords have been introduced in several languages.
>     A side note: it is also interesting to remember how the SQL came to
>     be. One of the oldest "programming languages" and recall the design
>     decisions behind it.
> If you mean that for a trained the constant switching from "&&" to "and"
> is difficult, that's natural. He has developed a strong habbit to see
> "&&" and interpret it in a certain way; and he wants to keep the status
> quo.
> I've witnessed the same as well. Those trained in traditional languages
> insist on keeping "&&", no matter what language. The new trainees
> however have no difficulties in using "and".

They *think* they have no difficulties using "and". It's only when they
run into the issue that "and" isn't a fancy way of writing "&&" they
realise there are difficulties. But perhaps the "new" has worn off from
their trainee status by then?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About