原文
| ||||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||
 | ||||||||||||||||||||||||||||||||||||||||||||||||||
（评论）
(comments)
原始链接: https://news.ycombinator.com/item?id=43751076
Hacker News上的一篇讨论围绕着一篇文章展开，该文章称赞管道化是编程语言中最喜欢的特性之一。评论者们就作者过分关注语法而忽略语义，以及调试长管道带来的挑战展开了辩论。“管道化”一词的含义模糊不清，因为它涵盖了方法链、运算符重载和一等函数，也引发了大家的担忧。一些用户建议使用“窥视步骤”之类的调试技巧。其他人则重点介绍了各种语言中的管道化实现，包括R的tidyverse、Elixir（使用`|>` 运算符）、C#的LINQ和Scala。一位Python用户抱怨说，对象方法默认不返回`self`，这阻碍了管道化。还提到了Python的替代库Pipe和pipetools。最初的文章也被认为是一篇轻松的“热议”。
相关文章
Pipelining can become hard to debug when chains get very long. The author doesn't address how hard it can be to identify which step in a long chain caused an error.
They do make fun of Python, however. But don't say much about why they don't like it other than showing a low-res photo of a rock with a pipe routed around it.
Ambiguity about what constitutes "pipelining" is the real issue here. The definition keeps shifting throughout the article. Is it method chaining? Operator overloading? First-class functions? The author uses examples that function very differently.
reply