Re: maintainability and "or"
Thank you all for the wonderful training and feedback!
Re: maintainability and "or"
On 03/21/2017 11:25 AM, Brandon Allbery wrote: people comparing perl 5 speed to perl 6 should take note: perl 5 used to be slow too If you wanted "speed", code in C or assembly. I am after rapid development. Perl 6 is perfect. -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
Re: maintainability and "or"
On 03/21/2017 04:50 AM, Elizabeth Mattijsen wrote: $PathAndName.IO.open(:w).close unless $PathAndName.IO.f; Hi Liz, Now that is elegant! Thank you! -T -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
Re: maintainability and "or"
On Tue, Mar 21, 2017 at 02:46:43PM -0400, Brandon Allbery wrote: > On Tue, Mar 21, 2017 at 2:37 PM, Patrick R. Michaud > wrote: > > > On Tue, Mar 21, 2017 at 7:38 AM, ToddAndMargo > > wrote: > > > > $Name.IO.f or $Name.IO.open(:w).close; > > > > > > fwiw I consider this a perl3_to_5-ism; it's an optimization, and a fairly > > > > It's not entirely a perl3-to-5ism. Using || and && for conditional > > execution dates back to Unix shell programming (long before Perl existed); > > Perl 5 introduced the low precedence "or"/"and" versions of the operators. > > True, but I don't really consider shells to be full programming languages; > they exist to glue external programs together. and FWIW, Perl was long known as a "glue language" as well. :) > If you have an actual programming language around, there's no reason to > stick to unreadable JCL-ish constructs. ...unless you have a large audience of people that are fluent in those constructs and would like to continue using them in their shiny new programming environment. Pm
Re: maintainability and "or"
On Tue, Mar 21, 2017 at 2:37 PM, Patrick R. Michaud wrote: > On Tue, Mar 21, 2017 at 02:25:02PM -0400, Brandon Allbery wrote: > > On Tue, Mar 21, 2017 at 7:38 AM, ToddAndMargo > wrote: > > > $Name.IO.f or $Name.IO.open(:w).close; > > > > fwiw I consider this a perl3_to_5-ism; it's an optimization, and a fairly > > It's not entirely a perl3-to-5ism. Using || and && for conditional > execution dates back to Unix shell programming (long before Perl existed); > Perl 5 introduced the low precedence "or"/"and" versions of the operators. > True, but I don't really consider shells to be full programming languages; they exist to glue external programs together. (Shell as JCL, if you will.) If you have an actual programming language around, there's no reason to stick to unreadable JCL-ish constructs. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: maintainability and "or"
On Tue, Mar 21, 2017 at 7:28 PM, Brandon Allbery wrote: > On Tue, Mar 21, 2017 at 7:50 AM, Elizabeth Mattijsen > wrote: > >> $PathAndName.IO.open(:w).close unless $PathAndName.IO.f; > > > This has a readability issue, though: you've buried the lede. Well, to me it seems the opposite: That condition does not exactly "entice the reader to read the full story". At least not this reader. The most significant/interesting info, in this reader's opinion, is not the test of existence (and non-directoriness), but the creation of the file. Different folks. :) Eirik, whose fingers first somehow autocompleted "test of time" while trying to write "test of existence" …
Re: maintainability and "or"
On Tue, Mar 21, 2017 at 02:25:02PM -0400, Brandon Allbery wrote: > On Tue, Mar 21, 2017 at 7:38 AM, ToddAndMargo wrote: > > $Name.IO.f or $Name.IO.open(:w).close; > > fwiw I consider this a perl3_to_5-ism; it's an optimization, and a fairly > poor one for readability and maintainability, but one that used to be > fairly important (people comparing perl 5 speed to perl 6 should take note: > perl 5 used to be slow too). It's not entirely a perl3-to-5ism. Using || and && for conditional execution dates back to Unix shell programming (long before Perl existed); Perl 5 introduced the low precedence "or"/"and" versions of the operators. Pm
Re: maintainability and "or"
On Tue, Mar 21, 2017 at 7:50 AM, Elizabeth Mattijsen wrote: > $PathAndName.IO.open(:w).close unless $PathAndName.IO.f; This has a readability issue, though: you've buried the lede. The condition should be up front where it stands out, not hidden at the back. The wide usage of the Perl 5 "or" convention actually derives from this: both the prefix-or and postfix-unless were faster than the explicit if, but prefix-or vs. postfix-unless was judged to be cognitively a speed bump vs. a brick wall. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: maintainability and "or"
On Tue, Mar 21, 2017 at 7:38 AM, ToddAndMargo wrote: > $Name.IO.f or $Name.IO.open(:w).close; fwiw I consider this a perl3_to_5-ism; it's an optimization, and a fairly poor one for readability and maintainability, but one that used to be fairly important (people comparing perl 5 speed to perl 6 should take note: perl 5 used to be slow too). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
Re: maintainability and "or"
On Tue, 21 Mar 2017 12:50:18 +0100, Elizabeth Mattijsen
wrote:
> > On 21 Mar 2017, at 12:38, ToddAndMargo wrote:
> > This is just one of those chatter posts.
> >
> > To me, the holy grail of coding is maintainability,
> > which is why I code in Top Down.
> >
> > Code like below get my goat because I have to look
> > at it several times before I realize what is going on
> >
> > $Name.IO.f or $Name.IO.open(:w).close;
> >
> > Basically the above says:
> >
> >If the the first part of the logical OR passes,
> >then don't bother testing the second part. And
> >if the second part of the Logical OR passes or
> >fails, then "so what”.
>
> FWIW, I agree with you. I don’t like the use of and/or in this
> capacity. But many people swear by it. To each its own.
I am in the opposite camp. I use this all the time, as - to me - it
makes perfect sense. I am rather consequent (in perl5) using the mix of
|| (between expressions) and or (between an expression and an action)
expression or action;
expression || expression and action;
> > I'd much rather see
> > if not $PathAndName.IO.f { $PathAndName.IO.open(:w).close; }
I can live with that, but I still prefer the or, because it reads
cleaner
> > Which to me says:
> >
> >If this does not pass, then do something about it.
> >
> > To me, it is much more maintainable.
>
> And then there is the postfix if/unless way, which I personally like:
>
> $PathAndName.IO.open(:w).close unless $PathAndName.IO.f;
Which I really abhor/hate. *THAT* makes me have to read the line thrice
> Which to me reads:
>
> Create the file unless it already exists.
To me it reads "Create the file". Oh shit I shouldn't have as some
idiot told me too late not to if it rains.
Program minds differ :)
> Liz
--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.25 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
pgpsm3TmyUPtj.pgp
Description: OpenPGP digital signature
Re: maintainability and "or"
> On 21 Mar 2017, at 12:38, ToddAndMargo wrote:
> This is just one of those chatter posts.
>
> To me, the holy grail of coding is maintainability,
> which is why I code in Top Down.
>
> Code like below get my goat because I have to look
> at it several times before I realize what is going on
>
> $Name.IO.f or $Name.IO.open(:w).close;
>
> Basically the above says:
>
>If the the first part of the logical OR passes,
>then don't bother testing the second part. And
>if the second part of the Logical OR passes or
>fails, then "so what”.
FWIW, I agree with you. I don’t like the use of and/or in this capacity. But
many people swear by it. To each its own.
> I'd much rather see
> if not $PathAndName.IO.f { $PathAndName.IO.open(:w).close; }
>
> Which to me says:
>
>If this does not pass, then do something about it.
>
> To me, it is much more maintainable.
And then there is the postfix if/unless way, which I personally like:
$PathAndName.IO.open(:w).close unless $PathAndName.IO.f;
Which to me reads:
Create the file unless it already exists.
Liz
