[32868] in Perl-Users-Digest
Perl-Users Digest, Issue: 4146 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Feb 22 21:14:33 2014
Date: Sat, 22 Feb 2014 18:14:09 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 22 Feb 2014 Volume: 11 Number: 4146
Today's topics:
Re: obj 8-2 <rweikusat@mobileactivedefense.com>
Re: obj 8-2 <john@castleamber.com>
Re: obj 8-2 <john@castleamber.com>
Re: obj 8-2 <news@todbe.com>
Re: obj 8-2 <m@rtij.nl.invlalid>
Re: obj 8-2 <news@todbe.com>
Re: obj 8-2 <johnblack@nospam.com>
Re: obj 8-2 <johnblack@nospam.com>
Re: obj 8-2 <john@castleamber.com>
Re: obj 8-2 <hjp-usenet3@hjp.at>
Re: obj 8-2 <m@rtij.nl.invlalid>
Re: obj 8-2 <ben@morrow.me.uk>
Re: obj 8-2 <ben@morrow.me.uk>
Re: obj 8-2 <john@castleamber.com>
Re: obj 8-2 <hjp-usenet3@hjp.at>
Re: obj 8-2 <hjp-usenet3@hjp.at>
Re: obj 8-2 <uri@stemsystems.com>
Re: obj 8-2 <john@castleamber.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 22 Feb 2014 19:35:14 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: obj 8-2
Message-Id: <87a9djos99.fsf@sable.mobileactivedefense.com>
John Black <johnblack@nospam.com> writes:
> In article <874n3rvz45.fsf@sable.mobileactivedefense.com>, rweikusat@mobileactivedefense.com
> says...
[...]
>> >> $max = $array[0];
>> >> $_ > $max and $max = $_ for @array[1 .. $#array];
>> >>
>> >> print "The Answer is: $max\n";
>> >
>> > Honestly, I like Marek's second solution much better than all of
>> > yours. Marek's code is very readable and easy to understand what its
>> > doing. Sorry Rainer, but yours is a cryptic mess (IMO).
>>
>> Referring to a single line of code with three expressions as "cryptic
>> mess" seems a little out of place (George's arithmetic solution was
>> relatively cryptic because of the 'if' hidden inside the the
>> abs-function but it was far to simple and obviously too organized that
>> it could be labeled as 'a mess'). Looking at it, what is used here is
>>
>> - a short-circuiting boolean operator for conditional evaluation
>> - a statement modifier
>> - $_ with it usual meaning of "the current thing"
>> - an array slice expression using the integer range operator
>>
>> These are all pretty basic Perl features and if they're sufficiently
>> unfamiliar to you that they seem 'cryptic' to you, that's not my fault.
>> Perl has sufficient expressive power that really simple things, like
>> finding the largest number in an array, can be expressed succinctly
>
> I know how your code works but I stand by what I said.
Well, I was trying to inform you politely that you weren't making any
more sense as if you'd accuse me of "sacricing readability and
maintainability" (or some other suitable objectivation of an opinion of
yours in lieu of arguing in favor of it) because I wrote something in
German, say "Guten Tag, Herr Praesident!" you didn't understand
because the language was unfamiliar to you: The "Good afternoon, Mr
President" didn't become more complicated because it was expressed in a
different form. Likewise,
$max = $array[0];
for (@array[1 .. $#array]) {
if ($_ > $max) {
$max = $_;
}
}
or
$max = $array[0];
for ($i = 1; i < @array; ++i) {
if ($array[$i] > $max) {
$max = $array[$i];
}
}
are no more or no less complicated at the content-level than
$max = $array[0];
$_ > $max and $max = $_ for @array[1 .. $#array];
It's the same thing expressed in three different ways and 'verbosity' is
not a virtue in its own right (as is brevity, for that matter).
------------------------------
Date: Sat, 22 Feb 2014 14:24:57 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: obj 8-2
Message-Id: <87mwhiyjxi.fsf@castleamber.com>
Marek Novotny <mach2@hushmail.com> writes:
> Thank you. Yeah, no mention of anything like that just yet. I just picked
> up 3 O'Reilly books:
>
> Learning Perl 6th edition
after this one ...
> Intermediate Perl 2nd edition
or this one I recommend to read "Modern Perl", see:
http://onyxneon.com/books/modern_perl/
You can download a PDF version (and experimental epub version)
> Mastering Perl 2nd edition
>
> And then also picked up Programming Perl 4th edition.
>
> I just started on Learning Perl and am just about to the chapter 3 quiz.
> I wrote about 17 tiny scripts to illustrate chapter 2.
> Quite literally just getting started with Perl.
One thing I can recommend to get into very early is testing; write a
separate script (or scripts) that test your code.
http://www.perl.org/about/whitepapers/perl-testing.html
> This is all fascinating for me.
;-).
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Sat, 22 Feb 2014 14:39:10 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: obj 8-2
Message-Id: <87fvnayj9t.fsf@castleamber.com>
John Black <johnblack@nospam.com> writes:
> I know how your code works but I stand by what I said. Some people
> like to sacrifice readability and maintainability to save one or two
> lines of code ("succinctly"). Burying a decision inside of a short
> circuit AND is one of those cute tricks people do to avoid using a
> simple IF but not something I would encourage people (especially
> beginner programmers)
So you don't recommend:
open my $fh, '<', $filename
or die "Can't open '$filename' for reading: $!";
?
The use of short circuit operations is very common in Perl. It's not
more confusing (to me) than:
$foo += $bar;
Idioms like this are very common in languages that support them. IMO,
instead of dumbing down a language so everybody can program in it, it's
better to learn idioms and use them.
This is not programming specific: as soon as a lot of people start doing
things together they make up jargon so they don't have to describe
things in detail endlessly or write things down endlessly.
> makes sense (this is not one). Even using $#array is not necessary.
> foreach $elem (@array) is clear and unmistakable. I could probably
> show Marek's solution to someone who doesn't even know Perl and they'd
> be able to easily tell me exactly what it does. Not so with yours.
But this is the case for a lot of languages. I can copy paste a piece of
Python (you know, often advertised as the most readable and most easy to
learn of all programming languages) or Haskell here and without knowing
enough of the language one wouldn't have a clue what it does.
As for the use of $#array: I see more beginners using this and indexing
instead of using looping over @array.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Sat, 22 Feb 2014 12:46:46 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: obj 8-2
Message-Id: <leb2bh$uci$1@dont-email.me>
On 2/22/2014 11:35, Rainer Weikusat wrote:
>
> Well, I was trying to inform you politely that you weren't making any
> more sense as if you'd accuse me of "sacricing readability and
> maintainability" (or some other suitable objectivation of an opinion of
> yours in lieu of arguing in favor of it) because I wrote something in
> German, say "Guten Tag, Herr Praesident!" you didn't understand
> because the language was unfamiliar to you: The "Good afternoon, Mr
> President" didn't become more complicated because it was expressed in a
> different form. Likewise,
>
> $max = $array[0];
> for (@array[1 .. $#array]) {
> if ($_ > $max) {
> $max = $_;
> }
> }
>
> or
>
> $max = $array[0];
> for ($i = 1; i < @array; ++i) {
> if ($array[$i] > $max) {
> $max = $array[$i];
> }
> }
>
> are no more or no less complicated at the content-level than
>
> $max = $array[0];
> $_ > $max and $max = $_ for @array[1 .. $#array];
>
> It's the same thing expressed in three different ways and 'verbosity' is
> not a virtue in its own right (as is brevity, for that matter).
I like:
my @array = (42,41,42,31,54,42,56,57,46,58,59,60,34,61);
my $max = $array[0];
foreach (@array) { $max = $_ if $_ > $max; }
print "The Answer is: $max\n";
It has the required if and looping constructs too.
------------------------------
Date: Sat, 22 Feb 2014 22:01:00 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: obj 8-2
Message-Id: <cpfnta-l31.ln1@news.rtij.nl>
On Fri, 21 Feb 2014 14:46:33 -0600, Marek Novotny wrote:
> On Fri, 21 Feb 2014 22:36:20 +0200, George Mpouras wrote:
>
>> how about finding the answer without IF ?
>>
>>
>> my @array = qw(42 41 42 31 54 420 56 57 46 58 59 60 34 61);
>> my $max = $array[0];
>> $max = (($_ + $max)/2) + (abs($_ - $max)/2) foreach @array[1 ..
>> $#array];
>> print $max
>
> A requirement for the lesson was to use loops and if.
OK.
my @array = qw(42 41 42 31 54 420 56 57 46 58 59 60 34 61);
sub max {
local $_ = shift;
return $_ unless @_;
if ($_ > $_[0]) {
shift;
unshift $_;
}
goto &max
}
print $max for (1);
See, a loop and an if. :-)
M4
------------------------------
Date: Sat, 22 Feb 2014 13:05:10 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: obj 8-2
Message-Id: <leb3e1$511$1@dont-email.me>
On 2/22/2014 12:39, John Bokma wrote:
>
> So you don't recommend:
>
> open my $fh, '<', $filename
> or die "Can't open '$filename' for reading: $!";
>
FWIW ...
One thing I learned very early in my C programming years was to
always end a continued line with an operator (if possible) so
it's obvious that the line is continued (rather than your version
where the operator starts the 2nd line). EG:
open my $fh, '<', $filename or
die "open '$filename': $! ($^E)";
It's much easier to read someone else's code that way.
I usually also add the $^E cause it often gives helpful additional
info (especially if the error was deep in the code).
I'm also still a fan of the original K&R braces:
if (...) {
}
rather than the wasted line versions often used today:
if (...)
{
}
for similar reasons as the operator on the end of the line.
------------------------------
Date: Sat, 22 Feb 2014 15:17:33 -0600
From: John Black <johnblack@nospam.com>
Subject: Re: obj 8-2
Message-Id: <MPG.2d72cfe4e504dadf9897b1@news.eternal-september.org>
In article <cpfnta-l31.ln1@news.rtij.nl>, m@rtij.nl.invlalid says...
>
> On Fri, 21 Feb 2014 14:46:33 -0600, Marek Novotny wrote:
>
> > On Fri, 21 Feb 2014 22:36:20 +0200, George Mpouras wrote:
> >
> >> how about finding the answer without IF ?
> >>
> >>
> >> my @array = qw(42 41 42 31 54 420 56 57 46 58 59 60 34 61);
> >> my $max = $array[0];
> >> $max = (($_ + $max)/2) + (abs($_ - $max)/2) foreach @array[1 ..
> >> $#array];
> >> print $max
> >
> > A requirement for the lesson was to use loops and if.
>
>
> OK.
>
> my @array = qw(42 41 42 31 54 420 56 57 46 58 59 60 34 61);
>
> sub max {
> local $_ = shift;
> return $_ unless @_;
> if ($_ > $_[0]) {
> shift;
> unshift $_;
> }
> goto &max
> }
>
> print $max for (1);
>
> See, a loop and an if. :-)
>
> M4
LOL. He's kidding Marek (even though I'm sure it works).
John Black
------------------------------
Date: Sat, 22 Feb 2014 15:21:54 -0600
From: John Black <johnblack@nospam.com>
Subject: Re: obj 8-2
Message-Id: <MPG.2d72d0f0db38e5109897b2@news.eternal-september.org>
In article <leb3e1$511$1@dont-email.me>, news@todbe.com says...
> I'm also still a fan of the original K&R braces:
> if (...) {
> }
> rather than the wasted line versions often used today:
I like this too. I like being able to follow the column right up to the associated If or
While statement.
John Black
------------------------------
Date: Sat, 22 Feb 2014 15:25:31 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: obj 8-2
Message-Id: <878ut2yh4k.fsf@castleamber.com>
"$Bill" <news@todbe.com> writes:
> On 2/22/2014 12:39, John Bokma wrote:
>>
>> So you don't recommend:
>>
>> open my $fh, '<', $filename
>> or die "Can't open '$filename' for reading: $!";
>>
>
> FWIW ...
>
> One thing I learned very early in my C programming years was to
> always end a continued line with an operator (if possible) so
> it's obvious that the line is continued (rather than your version
> where the operator starts the 2nd line). EG:
> open my $fh, '<', $filename or
> die "open '$filename': $! ($^E)";
> It's much easier to read someone else's code that way.
I prefer the or on a new line, also with stuff like:
my $line = '........................'
. ' and then some more';
since a line of Perl starting with 'or' or '.' is very odd.
> I'm also still a fan of the original K&R braces:
> if (...) {
> }
Use those to, even on subs.
> rather than the wasted line versions often used today:
> if (...)
> {
> }
Depends, when I use the former I often write:
if ( ... ) {
....
}
(i.e. empty line after if) and when I used the latter I did:
if ( ... )
{
....
}
So often the same amount of lines. IMO, don't worry about the number of
lines. Make your code flow and easy to read and don't be too clever ;-)
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Sat, 22 Feb 2014 23:17:32 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: obj 8-2
Message-Id: <slrnlgi8fs.q55.hjp-usenet3@hrunkner.hjp.at>
On 2014-02-22 21:05, $Bill <news@todbe.com> wrote:
> On 2/22/2014 12:39, John Bokma wrote:
>>
>> So you don't recommend:
>>
>> open my $fh, '<', $filename
>> or die "Can't open '$filename' for reading: $!";
>>
Actually I would recommend autodie here.
But I think this is different in several aspects.
1) In the “open or die” idiom, the open is the important part, while
the die is just error handling, so it is fitting that the die is
hidden at the end of the line (or a continuation line in this case).
But in “$_ > $max and $max = $_” the assignment is central and should
not be hidden.
2) “open or die” conveys the proper meaning as an English sentence,
but “$_ > $max and $max = $_” doesn't. In English “and” is used to
combine similar things, so after reading “$_ > $max and” one would
expect another comparison, not an assignment. Or vice versa, both
subexpressions could “do something” and the whole statement could
execute both (something like the comma operator). In Perl it means
something completely different, so the similarity to an English
sentence is distracting (I don't have this problem with the &&
operator).
I am an advocate of writing idiomatic code. If you write Perl code,
write code which looks like Perl, not like Fortran with funny
characters. But “idiomatic code” doesn't mean “cram every language
feature you can think of into the smallest possible space”. It means
code which is common among experienced programmers and easy to read for
them (not necessarily for the beginner).
I like Rainer's code as a demonstration of several useful language
constructs in a single line. But I wouldn't write it like that in
production code. (OTOH, if I encountered it in production code, I
wouldn't change it. While it's overly cute in my opinion, it's far from
obfuscated.)
> One thing I learned very early in my C programming years was to
> always end a continued line with an operator (if possible) so
> it's obvious that the line is continued (rather than your version
> where the operator starts the 2nd line). EG:
> open my $fh, '<', $filename or
> die "open '$filename': $! ($^E)";
> It's much easier to read someone else's code that way.
Damian Conway recommends the opposite in Perl Best Practices:
Breaking Long Lines
Break long expressions before an operator.
When an expression at the end of a statement gets too long, it's
common practice to break that expression after an operator and then
continue the expression on the following line, indenting it one
level. Like so:
push @steps, $steps[-1] +
$radial_velocity * $elapsed_time +
$orbital_velocity * ($phase + $phase_shift) -
$DRAG_COEFF * $altitude;
The rationale is that the operator that remains at the end of the
line acts like a continuation marker, indicating that the expression
continues on the following line.
Using the operator as a continuation marker seems like an excellent
idea, but there's a serious problem with it: people rarely look at
the right edge of code. Most of the semantic hints in a program—such
as keywords—appear on the left side of that code. More importantly,
the structural cues for understanding code—for example,
indenting—are predominantly on the left as well (see the upcoming
"Keep Left" sidebar). This means that indenting the continued lines
of the expression actually gives a false impression of the
underlying structure, a misperception that the eye must travel all
the way to the right margin to correct.
A cleaner solution is to break long lines /before/ an operator. That
approach ensures that each line of the continued expression will
start with an operator, which is unusual in Perl code. That way, as
the reader's eye scans down the left margin of the code, it's
immediately obvious that an indented line is merely the continuation
of the previous line, because it starts with an operator.
The indentation of the second and subsequent lines of the expression
is also critical. Continued lines should not simply be indented to
the next indentation level. Instead, they should be indented to the
starting column of the expression to which they belong. That is,
instead of:
push @steps, $steps[-1]
+ $radial_velocity * $elapsed_time
+ $orbital_velocity * ($phase + $phase_shift)
- $DRAG_COEFF * $altitude
;
one should write:
push @steps, $steps[-1]
+ $radial_velocity * $elapsed_time
+ $orbital_velocity * ($phase + $phase_shift)
- $DRAG_COEFF * $altitude
;
This style of layout has the added advantage that it keeps the two
arguments of the push visually separated in the horizontal, and
thereby makes them easier to distinguish.
When a broken expression is continued over multiple lines, it is
good practice to place the terminating semicolon on a separate line,
indented to the same column as the start of the continued
expression. As the reader's eye scans down through the leading
operators on each line, encountering a semicolon instead makes it
very clear that the continued expression is now complete.
It takes a bit of an effort to shake off years of habit, but I agree
with him: It does make the code more readable.
I recommend Perl Best Practices. All the recommendations are
thoughtfully explained. While you may disagree with some of them (I know
I do), at least it makes you think about your style choices.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Sun, 23 Feb 2014 00:14:06 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: obj 8-2
Message-Id: <uinnta-d6t.ln1@news.rtij.nl>
On Sat, 22 Feb 2014 15:17:33 -0600, John Black wrote:
> In article <cpfnta-l31.ln1@news.rtij.nl>, m@rtij.nl.invlalid says...
>>
>> my @array = qw(42 41 42 31 54 420 56 57 46 58 59 60 34 61);
>>
>> sub max {
>> local $_ = shift; return $_ unless @_;
>> if ($_ > $_[0]) {
>> shift; unshift $_;
>> }
>> goto &max
>> }
>>
>> print $max for (1);
>>
>> See, a loop and an if. :-)
>>
>> M4
>
> LOL. He's kidding Marek (even though I'm sure it works).
>
I am kidding, but it's a nice example of tail recursion nonetheless.
M4
------------------------------
Date: Sat, 22 Feb 2014 23:08:06 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: obj 8-2
Message-Id: <m7nnta-6bt.ln1@anubis.morrow.me.uk>
Quoth Marek Novotny <mach2@hushmail.com>:
>
> Thank you Ben! This is so appreciated. I'm humbled. I feel like a giant
> dope. I'm not used to thinking this way yet. So I want to apologize in
> advance for all the really stupid questions I will likely ask in the
> future.
Stupid questions that come from ignorance are *absolutely OK*; we were
all ignorant once, and will all find ourselves in situations where we
are ignorant again.
> This should have been obvious to me.
Like mathematics, many of the concepts in programming seem so obvious
once you understand them that it's hard to believe you didn't see them
before; this doesn't mean they weren't hard to understand.
The important lesson to learn here is 'always check the edge cases'. As
soon as you write a starting condition of $x = 0 you should be thinking
'But what will happen if all the numbers are greater than 0 / less than
0 / equal to 0 / ...?'.
Ben
------------------------------
Date: Sat, 22 Feb 2014 23:22:18 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: obj 8-2
Message-Id: <a2onta-6bt.ln1@anubis.morrow.me.uk>
Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
>
> The indentation of the second and subsequent lines of the expression
> is also critical. Continued lines should not simply be indented to
> the next indentation level. Instead, they should be indented to the
> starting column of the expression to which they belong. That is,
> instead of:
>
> push @steps, $steps[-1]
> + $radial_velocity * $elapsed_time
> + $orbital_velocity * ($phase + $phase_shift)
> - $DRAG_COEFF * $altitude
> ;
>
> one should write:
>
> push @steps, $steps[-1]
> + $radial_velocity * $elapsed_time
> + $orbital_velocity * ($phase + $phase_shift)
> - $DRAG_COEFF * $altitude
That I don't like. Non-standard indentation IMHO is more confusing than
it is helpful. If I felt it necessary to separate @steps and the start
of the expression more clearly, and particularly if there were two such
expressions, I'd use another line:
push @steps,
$steps[1]
+ ...
+ ...,
$steps[2]
- ...
+ ...;
Of course in many circumstances the long expression could be broken
differently, so that $steps[1] didn't appear on its own.
> ;
This, also, I don't like: a bare semicolon or comma looks terribly out
of place. If I wanted to get the semicolon on a line on its own I'd add
a set of brackets, properly indented:
push @steps, (
$steps[1]
+ ...,
$steps[2]
+ ...,
);
This has the additional advantage of allowing a trailing comma inside
the brackets (although, now I check, 'push @x, 1, 2,;' is in fact legal,
despite looking even weirder than a bare semi).
> I recommend Perl Best Practices. All the recommendations are
> thoughtfully explained. While you may disagree with some of them (I know
> I do), at least it makes you think about your style choices.
I recommend perlstyle :).
Ben
------------------------------
Date: Sat, 22 Feb 2014 18:03:33 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: obj 8-2
Message-Id: <87ob1ywv8q.fsf@castleamber.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-02-22 21:05, $Bill <news@todbe.com> wrote:
>> On 2/22/2014 12:39, John Bokma wrote:
>>>
>>> So you don't recommend:
>>>
>>> open my $fh, '<', $filename
>>> or die "Can't open '$filename' for reading: $!";
>>>
>
> Actually I would recommend autodie here.
>
> But I think this is different in several aspects.
>
> 1) In the “open or die” idiom, the open is the important part, while
> the die is just error handling, so it is fitting that the die is
> hidden at the end of the line (or a continuation line in this case).
> But in “$_ > $max and $max = $_” the assignment is central and should
> not be hidden.
Yeah, I know the argument(s), have read PBP more than once, etc.
To me, it's all a matter of taste, and my experience is that it changes
over time.
I prefer (now) this
$x > 12 or next;
over:
next if $x > 12;
I think of the former as something that must be true for the lines that
follows.
I've also no problem with:
$x <= 12 and next;
But now I sometimes write it like I did several years back:
next if x <= 12;
I see both styles in code (and way much weirder ones).
>
> 2) “open or die” conveys the proper meaning as an English sentence,
> but “$_ > $max and $max = $_” doesn't. In English “and” is used to
Yes, I understand the reason, etc. Yet, I don't see how someone has a
hard time with reading/understanding
$_ > $max and $max = $_
It's nice that Perl sometimes reads like an English sentence, but a lot
doesn't in my experience.
> I am an advocate of writing idiomatic code. If you write Perl code,
> write code which looks like Perl, not like Fortran with funny
> characters.
To me $_> $max and $max = $_ for @values; reads like Perl ;-)
> But “idiomatic code” doesn't mean “cram every language
> feature you can think of into the smallest possible space”. It means
> code which is common among experienced programmers and easy to read for
> them (not necessarily for the beginner).
Exactly, and to me the above falls in that class.
> I like Rainer's code as a demonstration of several useful language
> constructs in a single line. But I wouldn't write it like that in
> production code. (OTOH, if I encountered it in production code, I
> wouldn't change it. While it's overly cute in my opinion, it's far from
> obfuscated.)
Yup. I sometimes write dense code like that, and other times I write it
more out. It depends on my mood and also how complicated the code
surrounding it is, and of course for who I am writing.
> I recommend Perl Best Practices. All the recommendations are
> thoughtfully explained. While you may disagree with some of them (I know
> I do), at least it makes you think about your style choices.
Yup, I certainly recommend PBP as well and wouldn't mind a more modern
version. And I think most people who've read it a) disagree with some
and b) have become better programmers.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: Sun, 23 Feb 2014 01:14:51 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: obj 8-2
Message-Id: <slrnlgifbr.l0u.hjp-usenet3@hrunkner.hjp.at>
On 2014-02-23 00:03, John Bokma <john@castleamber.com> wrote:
> I prefer (now) this
>
> $x > 12 or next;
>
> over:
>
> next if $x > 12;
One of these two lines doesn't do what you think.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpat. -- Ralph Babel
------------------------------
Date: Sun, 23 Feb 2014 01:20:22 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: obj 8-2
Message-Id: <slrnlgifm6.l0u.hjp-usenet3@hrunkner.hjp.at>
On 2014-02-22 23:22, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth "Peter J. Holzer" <hjp-usenet3@hjp.at>:
[quoting BPP]
>> The indentation of the second and subsequent lines of the expression
>> is also critical. Continued lines should not simply be indented to
>> the next indentation level. Instead, they should be indented to the
>> starting column of the expression to which they belong. That is,
>> instead of:
>>
>> push @steps, $steps[-1]
>> + $radial_velocity * $elapsed_time
>> + $orbital_velocity * ($phase + $phase_shift)
>> - $DRAG_COEFF * $altitude
>> ;
>>
>> one should write:
>>
>> push @steps, $steps[-1]
>> + $radial_velocity * $elapsed_time
>> + $orbital_velocity * ($phase + $phase_shift)
>> - $DRAG_COEFF * $altitude
>
> That I don't like. Non-standard indentation IMHO is more confusing than
> it is helpful. If I felt it necessary to separate @steps and the start
> of the expression more clearly, and particularly if there were two such
> expressions, I'd use another line:
>
> push @steps,
> $steps[1]
> + ...
> + ...,
> $steps[2]
> - ...
> + ...;
Ugh. That looks mis-aligned. I like stuff to align vertically.
>> ;
>
> This, also, I don't like: a bare semicolon or comma looks terribly out
> of place.
Yeah, I don't do this.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpat. -- Ralph Babel
------------------------------
Date: Sat, 22 Feb 2014 19:25:46 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: obj 8-2
Message-Id: <87mwhi7jzp.fsf@stemsystems.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> This has the additional advantage of allowing a trailing comma inside
BM> the brackets (although, now I check, 'push @x, 1, 2,;' is in fact legal,
BM> despite looking even weirder than a bare semi).
perl is one of the few (only?) languages to allow trailing commas. it is
such an easy syntax thing to add and it allows for easy reordering of
lists with one per line or other things. too bad most lang designers
didn't see that like larry did.
uri
------------------------------
Date: Sat, 22 Feb 2014 18:46:53 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: obj 8-2
Message-Id: <87k3cmwt8i.fsf@castleamber.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-02-23 00:03, John Bokma <john@castleamber.com> wrote:
>> I prefer (now) this
>>
>> $x > 12 or next;
>>
>> over:
>>
>> next if $x > 12;
>
> One of these two lines doesn't do what you think.
Yes, my bad.
next unless $x > 12;
( or $x > 12 and next; to go with the if )
I still prefer the or/and version, mostly, but like I wrote I recently
started to fall back to if/unless recently.
--
John Bokma j3b
Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4146
***************************************
