Front page | perl.perl5.porters |
Postings from April 2010
On Sat, Apr 03, 2010 at 10:44:21AM +0300, Jari Aalto wrote: > Tom Christiansen <tchrist@perl.com> 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? AbigailThread Previous | Thread Next