Your comparison is not quite optimised as you use () which is not
necessary. But I understand the comparison you make.
But, you can write an optimised pipe in ruby too. I actually did
that, because I could not want to be bothered to be restricted via
ruby's syntax for pipe-like operations.
Even aside from that, the original claim was about pipes versus
method chaining. To me these are not orthogonal to one another;
they are very similar. Just with the pipe focusing on tying together
different programs and focusing on input-output functionality.
Method chaining in ruby is a bit more flexible, we have blocks,
and usually the methods chained occur in one class/object or
the toplevel namespace (less frequently though, usually). Even
the pipe comparison is not ideal, because traditional UNIX pipes
don't support e. g. data manipulation via an object-oriented
focus. And I want that (see avisynth, but extend the idea there
via a) nicer syntax and b) data manipulation for EVERYTHING).
I don't see pipe as being exclusive over method chaining or
reverse.
One interesting idea was to add |> elixir's pipe-like operator
to ruby. I like that, but indeed, the net-gain in ruby is quite
minimal since method-chaining + blocks already offer a ton of
flexibility, so I am not sure how |> would fit into ruby 1:1.
Still I like the idea, but anyone proposing |> needs to come
up with really convincing ideas to matz here. Because people
WILL ask what the real difference is to method chaining. Even
fail-safe method chaining in ruby though I absolutely hate
the syntax via ? there ... it reads like garbage to me. Example:
(It has moved since then, so the above link no longer works,
been some years since I first saw it. Upon seeing it my brain
instantly cancelled any use of "&.", even though I understand
the rationale. It is just ugly to no ends. I still like the
|> syntax in Elixir though, even though I can not really see
what this should do in ruby.)
alt Hacker News
Your comparison is not quite optimised as you use () which is not necessary. But I understand the comparison you make.
But, you can write an optimised pipe in ruby too. I actually did that, because I could not want to be bothered to be restricted via ruby's syntax for pipe-like operations.
Even aside from that, the original claim was about pipes versus method chaining. To me these are not orthogonal to one another; they are very similar. Just with the pipe focusing on tying together different programs and focusing on input-output functionality. Method chaining in ruby is a bit more flexible, we have blocks, and usually the methods chained occur in one class/object or the toplevel namespace (less frequently though, usually). Even the pipe comparison is not ideal, because traditional UNIX pipes don't support e. g. data manipulation via an object-oriented focus. And I want that (see avisynth, but extend the idea there via a) nicer syntax and b) data manipulation for EVERYTHING).
I don't see pipe as being exclusive over method chaining or reverse.
One interesting idea was to add |> elixir's pipe-like operator to ruby. I like that, but indeed, the net-gain in ruby is quite minimal since method-chaining + blocks already offer a ton of flexibility, so I am not sure how |> would fit into ruby 1:1. Still I like the idea, but anyone proposing |> needs to come up with really convincing ideas to matz here. Because people WILL ask what the real difference is to method chaining. Even fail-safe method chaining in ruby though I absolutely hate the syntax via ? there ... it reads like garbage to me. Example:
https://github.com/ruby/ruby/blob/trunk/test/ruby/test_threa...
(It has moved since then, so the above link no longer works, been some years since I first saw it. Upon seeing it my brain instantly cancelled any use of "&.", even though I understand the rationale. It is just ugly to no ends. I still like the |> syntax in Elixir though, even though I can not really see what this should do in ruby.)