5 ms·

If you're inventing a special shorthand for functions like foo(42, ^), then why only in the context of a pipe? Make up some punctuation to introduce or surround

If you're inventing a special shorthand for functions like foo(42, ^), then why only in the context of a pipe? Make up some punctuation to introduce or surround this kind of expression, then use it anywhere. Less to learn, more useful.

throw_m239339 5y ago
and why stop there? Introduce lazy evaluation, type classes, custom operator overloading and what not... I'm jesting of course, I find JavaScript already too complicated, it's like some people want to make it look like Scala... just no.
- dtech 5y ago
  I'm mainly puzzled why they want to introduce additional syntax specific for it, when higher order function are perfectly possible in the current language already and integrate well with the F#-style pipe.
- abecedarius 5y ago
  Very reasonable, and that's why I phrased it like "if we do this". A TC39 member on this topic of restraint and priorities: https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9 https://erights.medium.com/the-tragedy-of-the-common-lisp-wh...
- nsonha 5y ago
  > I find JavaScript already too complicated I get that you don't want it *to become* complicated, but as it currently is, JavaScript is still a rather simple language.
dtech 5y ago
This is sort-of how Scala does it. _ in the context of a lambda means "the next argument", so it is general: val plus: (Int, Int) => Int = _ + _
jasperry 5y ago
It looks like Hack doesn't support first-class functions, which would explain why they don't do this. But I agree that it would be a neat short notation for lambdas.
ejones 5y ago
There's a proposal for this: https://github.com/tc39/proposal-partial-application https://github.com/tc39/proposal-partial-application
- abecedarius 5y ago
  That's more specialized: it can express foo(42, ?) but not what you'd write within this pipe syntax as foo(42, ^) + 1 The tradeoff is that it doesn't need some extra delimiter since the function call is what delimits it. Perhaps that's a better tradeoff, I'm not sure; but for sure we shouldn't have both.

throw_m239339 5y ago

and why stop there? Introduce lazy evaluation, type classes, custom operator overloading and what not... I'm jesting of course, I find JavaScript already too complicated, it's like some people want to make it look like Scala... just no.

dtech 5y ago
I'm mainly puzzled why they want to introduce additional syntax specific for it, when higher order function are perfectly possible in the current language already and integrate well with the F#-style pipe.
abecedarius 5y ago
Very reasonable, and that's why I phrased it like "if we do this". A TC39 member on this topic of restraint and priorities: https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9 https://erights.medium.com/the-tragedy-of-the-common-lisp-wh...
nsonha 5y ago
> I find JavaScript already too complicated I get that you don't want it *to become* complicated, but as it currently is, JavaScript is still a rather simple language.

dtech 5y ago

This is sort-of how Scala does it. _ in the context of a lambda means "the next argument", so it is general: val plus: (Int, Int) => Int = _ + _

jasperry 5y ago

It looks like Hack doesn't support first-class functions, which would explain why they don't do this. But I agree that it would be a neat short notation for lambdas.

ejones 5y ago

There's a proposal for this: https://github.com/tc39/proposal-partial-application https://github.com/tc39/proposal-partial-application

abecedarius 5y ago
That's more specialized: it can express foo(42, ?) but not what you'd write within this pipe syntax as foo(42, ^) + 1 The tradeoff is that it doesn't need some extra delimiter since the function call is what delimits it. Perhaps that's a better tradeoff, I'm not sure; but for sure we shouldn't have both.