t last? Moving from bs.send.pipe to just bs.send? about bs-webapi-incubator HOT 3 CLOSED

Well, first of all, t last and the pipe operator aren't established only in the Reason ecosystem. The pipe operator is also widely used in the OCaml ecosystem, and so if you want to leverage that you'd still have to deal with both even if the Reason ecosystem changes. The fast pipe operator also isn't actually Reason-specific, but BuckleScript-specific, which makes it difficult to write shared client/server code, or even just to mentally switch between the two worlds. The pipe operator is also established in other closely related languages, such as F# and Elm, and being different makes it difficult to transfer idioms between them and to learn from what these other communities are doing. For example, the pipe operator itself originated in F#, which is a much newer language than OCaml, and in fact OCaml was the primary inspiration for the design F#. It was therefore easy to bring the operator over, and if that hadn't happened it's not very likely we'd have the "fast pipe" either.

Even functional languages that don't have an established pipe operator, or something equivalent, still use t last because it enables function composition by partial function application, which is a pretty big part of being "functional" in the first place. The entire reason the pipe operator exists is because it follows quite naturally from composition of curried functions and can be implemented as an ordinary operator, whereas the "fast pipe" must be implemented as a syntactic transform. Note that in OCaml this could still work with t first if all other arguments are labelled, since labels can be applied in any order and when applied would effectively leave t last anyway. But even this proposal was just shut down and ignored.

As for pros, better type inference in some cases is a benefit, but there are other cases where t last works better and it's not clear to me that it's a net win. Another benefit is marginally better performance by default, partially because you can't partially apply a function "by accident" (whatever that means), and partially because it's a syntactic transform, while the ordinary pipe operator is treated as a function call that would have to be, and usually is, optimized away (or rather inlined) like any other function call might be. But even this benefit is debatable, since the ordinary pipe operator could be implemented as a syntactic transform as well. it just doesn't have to be. Lastly, I've heard it argued that it makes it more "natural" to interoperate with from JavaScript, since JS is not a functional language and therefore usually has t first. That's not much of a winning argument for me either, but YMMV.

I'm sure there are more subtle issue with it, and there might be more benefits as well. This is just off the top of my head, as there's never actually been a properly reasoned argument made for t first and the fast pipe operator. And in lieu of that, from what I've been able to gather on my own, both t first and the fast pipe operator add up to terrible design decisions.

But what's even worse for me is how criticism from the community was flat out ignored, and the changes forced though. It's caused me to lose any trust I had in the governance of both BuckleScript and Reason, and led me to look elsewhere for a language, ecosystem and community that I can trust, and that seems more sustainable.

from bs-webapi-incubator.

Hi. Thanks for asking. There are no plans to do so, and I doubt there'll ever be, because "fast piping" is worse than useless. I also don't think it's becoming standard in Reason because there are a lot of libraries and bindings that use the established pipe operator and they're not going to change just for the sake of change.

I absolutely understand the frustration of having to deal with multiple piping operators, and to always have to remember which function needs which operator, but this was brought up and well known before the new operator was introduced, and just ignored. The obvious solution is of course to revert the terrible decision, not to break the entire ecosystem, but I doubt that'll happen either as there seems to be too much pride involved.

I hope you can see where I'm coming from and understand my decision.

from bs-webapi-incubator.

Thank you, that's good to know.

It seems like you're quite passionate about the issue, and I haven't heard such a strong dissenting opinion on the matter before. Other than the ecosystem fragmentation, is there anything else about fast-piping you don't like? I've mostly come to prefer it because type inference seems to be better when I use it compared to the regular pipe.

from bs-webapi-incubator.