<story><title>Pipe Operator (|&gt;) For JavaScript</title><url>https://github.com/tc39/proposal-pipeline-operator</url></story><parent_chain><item><author>notdonspaulding</author><text>I struggle to think of real-world examples where I&amp;#x27;ve just needed to chain and chain and chain values of different types more than a handful of times.  The claimed need for the pipe operator is this construction:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    function bakeCake() {
      return separateFromPan(coolOff(bake(pour(mix(gatherIngredients(), bowl), pan), 350, 45), 30));
    }
&lt;/code&gt;&lt;/pre&gt;
The piped code looks like:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    function bakeCake() {
      return gatherIngredients()
        |&amp;gt; mix(%, bowl)
        |&amp;gt; pour(%, pan)
        |&amp;gt; bake(%, 350, 45)
        |&amp;gt; coolOff(%)
        |&amp;gt; separateFromPan(%)
       ;
&lt;/code&gt;&lt;/pre&gt;
Which is... fine?  It certainly looks better than the mess we started with, but adding names here only helps clarify each step.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    function bakeCake() {
      const ingredients = gatherIngredients();
      const batter = mix(ingredients);
      const batterInPan = pour(batter, pan);
      const bakedCake = bake(batterInPan, 350, 45);
      const cooledCake = coolOff(bakedInPan);
      return separateFromPan(cooledCake);
    }
&lt;/code&gt;&lt;/pre&gt;
Even if you consider the `const` to be visual noise, the names are useful.  At any point you can understand the goal of the code on the right-hand side by looking at the name of the variable on the left-hand side.  You can also visually scan the right-hand side and see the processing steps.  You can also introduce new steps to the control flow at any point and understand what the data should look like both before and after your new step.&lt;p&gt;I agree that the the control flow is more clearly elucidated in the pipe operator example, but it tosses away useful information about the state that the named variables contain.  It also introduces two new syntactical concepts for your brain to interpret (the pipe operator and the value placeholder).  I contend the cognitive load is no greater in the example with names, and the maintainability is greatly improved.&lt;p&gt;If you have an example where there are dozens of steps to the control flow with no break, I&amp;#x27;d be really curious to see it.</text></item><item><author>scotty79</author><text>When there are a few they can be really great. But if you need to accurately name every single intermediate thing they can become visual noise that hides what happens.</text></item><item><author>kriz9</author><text>Temporary variables are often tedious? I have found that well named temporary variables are the only clear way to comment code without actually writing the comment. The version with temporary variables is much easier to understand without having to read the rest of the code.</text></item></parent_chain><comment><author>wefarrell</author><text>Imagine that you asked someone the question &amp;quot;How do you make a cake?&amp;quot; Which response would be clearer?&lt;p&gt;1. Gather the ingredients, mix them in a bowl, pour into a pan, bake at 350 degrees for 45 minutes, let it cool off and then separate it from the pan.&lt;p&gt;2. Get ingredients by gathering the ingredients. Make batter by mixing the ingredients. Make batter in a pan by pouring the batter in a pan. Make a baked cake by baking the batter in the pan at 350 degrees for 45 minutes. Make a cooled cake by cooling the baked cake. Separate it from the pan.&lt;p&gt;For me personally #1 is more readable because #2 is unnecessarily bloated with redundantly described subjects.</text></comment>
<story><title>Pipe Operator (|&gt;) For JavaScript</title><url>https://github.com/tc39/proposal-pipeline-operator</url></story><parent_chain><item><author>notdonspaulding</author><text>I struggle to think of real-world examples where I&amp;#x27;ve just needed to chain and chain and chain values of different types more than a handful of times.  The claimed need for the pipe operator is this construction:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    function bakeCake() {
      return separateFromPan(coolOff(bake(pour(mix(gatherIngredients(), bowl), pan), 350, 45), 30));
    }
&lt;/code&gt;&lt;/pre&gt;
The piped code looks like:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    function bakeCake() {
      return gatherIngredients()
        |&amp;gt; mix(%, bowl)
        |&amp;gt; pour(%, pan)
        |&amp;gt; bake(%, 350, 45)
        |&amp;gt; coolOff(%)
        |&amp;gt; separateFromPan(%)
       ;
&lt;/code&gt;&lt;/pre&gt;
Which is... fine?  It certainly looks better than the mess we started with, but adding names here only helps clarify each step.&lt;p&gt;&lt;pre&gt;&lt;code&gt;    function bakeCake() {
      const ingredients = gatherIngredients();
      const batter = mix(ingredients);
      const batterInPan = pour(batter, pan);
      const bakedCake = bake(batterInPan, 350, 45);
      const cooledCake = coolOff(bakedInPan);
      return separateFromPan(cooledCake);
    }
&lt;/code&gt;&lt;/pre&gt;
Even if you consider the `const` to be visual noise, the names are useful.  At any point you can understand the goal of the code on the right-hand side by looking at the name of the variable on the left-hand side.  You can also visually scan the right-hand side and see the processing steps.  You can also introduce new steps to the control flow at any point and understand what the data should look like both before and after your new step.&lt;p&gt;I agree that the the control flow is more clearly elucidated in the pipe operator example, but it tosses away useful information about the state that the named variables contain.  It also introduces two new syntactical concepts for your brain to interpret (the pipe operator and the value placeholder).  I contend the cognitive load is no greater in the example with names, and the maintainability is greatly improved.&lt;p&gt;If you have an example where there are dozens of steps to the control flow with no break, I&amp;#x27;d be really curious to see it.</text></item><item><author>scotty79</author><text>When there are a few they can be really great. But if you need to accurately name every single intermediate thing they can become visual noise that hides what happens.</text></item><item><author>kriz9</author><text>Temporary variables are often tedious? I have found that well named temporary variables are the only clear way to comment code without actually writing the comment. The version with temporary variables is much easier to understand without having to read the rest of the code.</text></item></parent_chain><comment><author>scotty79</author><text>Sometimes intermediate values either don&amp;#x27;t have domain specific meanings or the meaning is obvious from the function name that returns this temporary value.&lt;p&gt;Then naming it is just noise.&lt;p&gt;If your bake() function was rather named createBakedCake() than naming returned value bakedCake just increses reader fatigue through repetition.&lt;p&gt;Same way&lt;p&gt;Random random = new Random();&lt;p&gt;in C# is worse than&lt;p&gt;var random = Random();</text></comment>