Criticizing Computers
On the pipability front of software, I think a lot of that happens through APIs now, either directly linked or through various network APIs. The gotcha is that few APIs can handle the kind of asynchronicity that a pipe can. With pipes I can so something like:<p><pre><code>    oaktree | nutgrinder | cookiemaker | cookieeater
</code></pre>
and as soon as each nut is ready from the oaktree, it can be consumed by the nutgrinder and it can send nut flour to the cookiemaker as its ready and when the cookiemaker has enough nut flour to make a cookie, it can send a cookie to the cookieeater. Four processes, acting in parallel¹ with little friction to make it happen.<p>Now, try to architect this in your favorite programming language.² I did see where Google proposed something (almost a decade ago) for C++ to allow this <a href="https:&#x2F;&#x2F;isocpp.org&#x2F;files&#x2F;papers&#x2F;n3534.html" rel="nofollow">https:&#x2F;&#x2F;isocpp.org&#x2F;files&#x2F;papers&#x2F;n3534.html</a> although I don’t know where it stands now. I’ve been thinking along something similar for finl for each of its stages so that, e.g., parsing and tokenization doesn’t need to be complete to start formatting, but it would be nice if there were a simple language facility to allow this.<p>REST APIs also fail at this insofar as you need to wait for a whole request to complete before you get a response rather than being able to send the request and get each chunk of data back as appropriate. We seem to have forgotten so much that we knew thirty years ago.<p>⸻<p>1. Although not necessarily. IIRC, good old fashioned DOS pipes would wait until each process was done before opening the next application in the chain.<p>2. Assuming, of course, that shell scripting isn’t your favorite programming language.