41–50 of 78 posts
I feel like that just confuses things for no good reason. It's no fewer characters than parens but provides as I see it less clarity.
I think the clarity comes from the reading order. str |> method1 |> method2 |> method3 vs method3(method2(method1(str))).
It also encourages you to write methods that take a single argument and return a single value, or partially apply those that don't.
If we're going to do this operator, I would prefer a regular arrow: import { sortBy, filter, map } from 'array-like'; let names = document.querySelectorAll('.entry') -> sortBy('title') -> filter(entry => entry.getAttribute('data-url') in whitelist) -> map(entry => entry.getAttribute('name'); I personally find this more readable than either the bind proposal (which looks too much like a property access, and not enough…
Please no. Javascript's beauty lies in its versatile simplicity. Can we just leave these sorts of things to systems programming languages like C++? I came to javascript because of its lack of cruft, but if libraries start adopting this then I'll be forced to put it in my code as well. If that happens then I'll probably leave for nim or clojure, though that's not preferable.
Can't speak for nim, but Clojure has a near-exact feature which is used all over the place, the thread-first and thread-last macros. Example: (defn do-stuff [params-map] (-> (build-object params-map) (do-thing-with-object) (extract-thing) (format-thing))) I'm not sure why you'd choose Clojure to get away from things like |>.
Earlier quoted context omitted.
Can't speak for nim, but Clojure has a near-exact feature which is used all over the place, the thread-first and thread-last macros. Example: (defn do-stuff [params-map] (-> (build-object params-map) (do-thing-with-object) (extract-thing) (format-thing))) I'm not sure why you'd choose Clojure to get away from things like |>.
Clojure is a functional language, so it meshes well with the rest of the syntax, but in javascript's case it's just syntax bloat. It's going to be really jarring in the middle of regular imperative code, and it's not going to be too far removed from cout
Doesn't seem fair to shut down this proposal because you happen to write and work with imperative code, a style that Javascript and modern abstractions are moving away from.
In fact, the Javascript hack to get a pipeline-like style is to make some opaque wrapper object that you can chain method calls onto like `_.chain(a).b().c().d().value()` in Lodash, when all you wanted was a chain of function application.
`|>`, `<|`, composition operators, and friends would all be welcome complements to the Javascript code bases I've worked with in the last few years.
If we're going to do this operator, I would prefer a regular arrow: import { sortBy, filter, map } from 'array-like'; let names = document.querySelectorAll('.entry') -> sortBy('title') -> filter(entry => entry.getAttribute('data-url') in whitelist) -> map(entry => entry.getAttribute('name'); I personally find this more readable than either the bind proposal (which looks too much like a property access, and not enough…
> I would prefer a regular arrow And I want it painted green ;-) > ... which doesn't have an immediate meaning to my eyes. It's a matter of background. F#, Julia and Livescript have identical operators, likely among others. https://msdn.microsoft.com/en-us/library/dd233229.aspx#Ancho... http://docs.julialang.org/en/release-0.4/stdlib/base/?highli... http://livescript.net/#piping
I personally consider compound operators (asymmetrical) to be pretty risky (the do, indeed, depend on background), and I like '->' because it has a clear meaning outside of programming.
But you're right, this is a bikeshed.
I'd prefer either version of the pipeline operator to bind.
Earlier quoted context omitted.
that won't play nice with coffeescript!
CoffeeScript should have thought of that ;)
var result = exclaim(capitalize(doubleSay("hello")));
var result = "hello"
|> doubleSay
|> capitalize
|> exclaim;
result = exclaim capitalize doubleSay 'hello'
Can we just put more focus on sweet.js so we can do this kind of in a library with standard build tooling? http://sweetjs.org/ There's a lot more operators than |> that you would want. Clojure commonly uses ->, ->>, as->, etc. It should be done in a library if it is done at all. Also, going full-on functional in javascript is going to end badly, javascript simply wasn't designed for it. If you go down this path in re…
Can you elaborate on the rough seams between JavaScript and "full on functional"? I'm not a believer in the FP vs. OO religion, and have historically been skeptical of the bind operator. That said, I think that both composition via objects and composition via functions have their place. The pipeline operator attempts to make composition via functions more readable (left-to-right instead of right-to-left) and unless y…
Earlier quoted context omitted.
Why the arrow? That works just fine with a dot. let names = document.querySelectorAll('.entry') .sortBy('title') .filter(entry => entry.getAttribute('data-url') in whitelist) .map(entry => entry.getAttribute('name');
Only if those methods are added to NodeList, which they haven't been. (and of course 'sortBy' is nonstandard)
var newScore = add(7, validateScore( double(person.score) ))
var newScore = person.score
|> double
|> score => add(7, score)
|> validateScore
Why not go all the way to pure RPN?
7 person score . double ValidateScore add newScore =
Do we really want to go down this route? It's all syntax; it doesn't add any capability. As an extension to an existing language, it's likely to produce a mess.
Mixing functional and imperative notations is a problem. LISP is all nested parentheses, and that bothered a lot of people. Forth eliminates all the parentheses, which bothered different people. Python was pure imperative, ("lambda" went in over major objections) and is gradually getting more functional features, but they don't fit the syntax well.
What's so painful about just doing `exclaim(capitalize(doubleSay("hello")));`? Why introduce needless syntactic sugar that'll only confuse people about how UNIX pipes work?