Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92996
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
To: internals@lists.php.net
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <8ea990da-1fe7-256c-4e08-0b30715c8e8a@gmail.com>
Message-ID: <5724F3F8.5070909@garfieldtech.com>
Date: Sat, 30 Apr 2016 13:05:44 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <8ea990da-1fe7-256c-4e08-0b30715c8e8a@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: larry@garfieldtech.com (Larry Garfield)

On 04/29/2016 07:19 PM, Stanislav Malyshev wrote:
> Hi!
>
>> This is one of my favorites out of HackLang.  It's pure syntactic
>> sugar, but it goes a long way towards improving readability.
>> https://wiki.php.net/rfc/pipe-operator
> I think this takes the syntax too much towards Perl 6 direction. There
> is a lot of fun in inventing cool signs like |> and making them do
> nontrivial cool stuff. There's much less fun when you try to figure out
> what such code is actually doing - and especially why it is not doing
> what you thought it is doing. Brian Kernigan once said:
>
> "Everyone knows that debugging is twice as hard as writing a program in
> the first place. So if you're as clever as you can be when you write it,
> how will you ever debug it?"
>
> I think this applies not only to debugging, but also to reading programs
> in general. If we are "as clever as we can be" with syntax, the program
> becomes unreadable.
>
> For this feature specifically, I see nothing wrong with assigning
> intermediate results to variables - moreover, I see an advantage to it
> both in reading (you tell people what you expect to have happened in
> this stage) and in debugging (you can actually *see* what happened and
> *check* whether what you thought should be happening actually happened).
>
> If we could achieve the elegance of Unix pipes, I'd agree that it is
> simple enough that we can see what is going on - but having it rely on
> two magic things which are in different part of expression and
> context-dependent ($$ means different things in different places) is too
> much for me.

See, I take that quote in the exact opposite direction.  I find chaining 
methods to be far, far less "clever" than deeply nesting them inside 
each other.  We shouldn't force pointless intermediate variables on 
people for the sake of readability.  The fair comparison is the deeply 
nested version vs. the chained version, and in that comparison the 
readability of the chained version is far, far better.

Lester pointed out error handling and branching.  True, the pipe 
chaining wouldn't handle that, but it doesn't claim to.  Neither does 
directly nesting the function calls inside each other.  If you do need 
to pause, examine a value, and branch, then yes that's where you want an 
intermediate variable to analyze and nothing has changed.  However, 
passing an array to array_filter() then passing the result to 
array_map() is always type safe (because array_filter still returns an 
array even if it filters down to 0 items), and array_map on an empty 
array is essentially a no-op, so I'm comfortable doing so, and wish I 
could do so more often with less fugly syntax. :-)

In a way... Sara, this syntax feels like it's only one step removed from 
promises; if any of the chained steps involve IO, it becomes basically 
what promises are for.  Am I barking down the wrong tree, or is there 
something we could connect there?  (I don't mean "reject this in favor 
of promises", but more "is there something we can do here to be forward 
thinking, since lots of people want to see async in core PHP?")

--Larry Garfield