Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Neat, but I think that functions already do what we need.

For one thing, the example isn't the most compelling, because you can:

    const greeting = 'hello'.toUpperCase() + '!!!';
or

    const greeting = 'HELLO!!!';
That said, there is already:

    function thrush(initial, ...funcs) {
        return funcs.reduce(
            (current, func) => func(current),
            initial);
    }

    const greeting = thrush('hello', s => s.toUpperCase(), s => s + '!!!');


Are any of the cases compelling? Thinking of the actual proposal. It creates some new magic with |> and % just for syntactic sugar.


I am all for clean syntax but I feel like JS has already reached a nice middle ground between expressiveness (especially w/ map/reduce/filter) and readability. I'd personally rather not have another syntax that everyone will have to learn unless we're already moving to a new language.


I think JS's map/reduce/filter design is one of the worst ones out there actually - map has footguns with its extra arguments and everything gets converted to an array at the drop of a hat. Still, pipeline syntax probably won't help fix any of that.


I always thought JS map filter reduce felt quite nice, especially playing around with data in the REPL. Java maps with all the conversions back and forth to streams are clumsy.


Well in JS you have to convert to arrays instead. You can't do `document.querySelectorAll(...).map(...)`.


That's the DOM API, it's not part of the language! They had reasons for querySelectorAll not returning an array.


> everything gets converted to an array at the drop of a hat

Can you name an example? IME the opposite is a more common complaint: needing to explicitly convert values to arrays from many common APIs which return eg iterables/iterators.


`map` returns an array and can only be called on an array.


Right, but I’m not clear on what gets converted to an array. Do you mean more or less what I said in my previous comment? That it requires you (your code, or calling code in general) to perform that conversion excessively?


People write a lot of stuff like [...iterable].map(fn). They do it so much it's as if they do it each time a hat drops.


Thank you for clarifying. (I think?)

I think what confused me is the passive language: "everything gets converted" sounds (to me) like the runtime or some aspect of language semantics is converting everything, rather than developers. Whereas this is the same complaint I mentioned.


One gripe I have is that the result of map/filter is always an array. As a result, doing `foo.map(...).filter(...).slice(0, 3)` will run the map and the filter on the entire array even if it has hundreds of entries and I only need the first 10 to find the 3 that match the filter.


I agree but to steelman it, what about custom functions? I think just doing it naively is perfectly fine. Or if you want use some pipe utility. Or wrap the array, string, etc. with your own custom methods.


Whatever that thrush thing is feels 10x more gross than the pipe


Not if you consider that the linked repo requires you to use asPipe on all functions first. So it's this:

  const greeting = thrush(
    'hello',
    s => s.toUpperCase(),
    s => s + '!!!'
  );
Vs this:

  const upper = asPipe(s => s.toUpperCase())
  const ex = asPipe((s) => s + '!!!')
  const greeting = pipe('hello')
    | upper
    | ex
  await greeting.run()
(And that doesn't work in reality, as the top comment here notes)


Thrush is the "T combinator" - I believe that the "Thrush" name comes from To Mock a Mockingbird by Raymond Smullyan [1].

[1]: https://www.amazon.com/Mock-Mockingbird-Other-Logic-Puzzles/...

[2]: https://en.wikipedia.org/wiki/Combinatory_logic#In_computing

[3]: https://leanpub.com/combinators/read#leanpub-auto-the-thrush




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: