Re: Function composition vs pipeline

> The point is that there is an unavoidable cost to the developer when features are added to the language. My apologies if that wasn't clear. You don't really need to argue that there is an unavoidable cost to new features. Few would disagree. And this cost is already taken into account in

Re: Function composition vs pipeline

The point is that there is an unavoidable cost to the developer when features are added to the language. My apologies if that wasn't clear. -Terence Bandoian On 3/22/2018 11:20 AM, Michael J. Ryan wrote: Nobody is wishing away anything with a linter. The linter can only enforce a choice not

Re: Re: Function composition vs pipeline

Nobody is wishing away anything with a linter. The linter can only enforce a choice not to use a given language feature. In any case, I feel this syntax is very valuable, fairly obvious in use, and similar to use in other languages. Pipeline/composition are important features, touched on by

Re: Re: Function composition vs pipeline

That's very true. However, every new feature is an added cost to the developer that can't be wished away with a linter. -Terence Bandoian On 3/20/2018 6:07 PM, Jordan Harband wrote: Learning is a continuing requirement with or without new features in the language; any one feature *not*

Re: Function composition vs pipeline

Learning is a continuing requirement with or without new features in the language; any one feature *not* added to the language tends to mean you'll have to learn about more than one userland solution to that problem. Obviously there's a cost to adding anything to the language - but there's a cost

Re: Function composition vs pipeline

When "features" are added to the language, developers have to learn them. Either that or risk being relegated to second class status. That means more time learning about and testing and sorting out support for new features and less time actually developing an application. I like the idea of

Re: Function composition vs pipeline

I would probably structure this so differently that it's hard to even say where the changes should be. I don't know the Electron API, so the following is almost certainly wrong, but it should demonstrate the basic ideas: ``` const promisify = require('some-promisify-function'); const

Re: Function composition vs pipeline

@michael, integration-level javascript rarely deals with blocking-code. its mostly tedious-work debugging and “fixing” endless piles of async-io timeout issues, without the help of a stack-trace :`( and the term “fixing” is oftentimes euphemism for “rewriting the carefully architected backend

Re: Function composition vs pipeline

Straw man. The problem is variables named h, f and g, not the use of a composition operator. On Sun, 11 Mar 2018 at 07:37, kai zhu wrote: > @peter, put yourself in the shoes of a senior-programmer responsible > for overseeing an entire web-project. the project is @ the >

Re: Function composition vs pipeline

All good points :-) I wasn't suggesting there's no cost to adding syntax to a language; I was suggesting that kai's blanket "please don't add new syntax because I don't want to have to deal with it in my project" isn't a useful objection on its own. On Tue, Mar 13, 2018 at 7:59 AM, Mark Miller

Re: Function composition vs pipeline

On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband wrote: > As someone who does wear the shoes of a senior programmer responsible > (along with my team) for overseeing a very very large web project, the > super trivial and easy answer to this is "use a linter" - eslint can be >

Re: Function composition vs pipeline

As someone who does wear the shoes of a senior programmer responsible (along with my team) for overseeing a very very large web project, the super trivial and easy answer to this is "use a linter" - eslint can be configured to restrict any syntax you like, and since surely your CI process is

Re: Function composition vs pipeline

In my opinion, one of the more significant advances in the C programming language was the increase in the maximum length of identifiers. To me, this translates to "less cryptic is better". -Terence Bandoian On 3/11/2018 1:09 AM, Peter Jaszkowiak wrote: Personally, I'd push my subordinates

Re: Function composition vs pipeline

Personally, I'd push my subordinates to learn this new syntax. But if you dislike it, you can blacklist it in your linter: it's one of the main features of a linter. On Mar 10, 2018 23:37, "kai zhu" wrote: > @peter, put yourself in the shoes of a senior-programmer

Re: Function composition vs pipeline

@peter, put yourself in the shoes of a senior-programmer responsible for overseeing an entire web-project. the project is @ the integration-stage and you're busy debugging an async timeout/near-timeout bug preventing the frontend from talking to the backend (which btw, is one of the most common

Re: Function composition vs pipeline

Oh please, This is an alternative syntax that's very useful for many people. If you want too simplify syntax yourself you can use a linter to disable alternatives. On Mar 10, 2018 22:56, "kai zhu" wrote: > my vote is for neither. exactly what industry painpoint or >

Re: Function composition vs pipeline

my vote is for neither. exactly what industry painpoint or problem-space do either of these proposals solve? rather, they compound an existing industry painpoint; where ocd-programmers have problems in deciding-and-choosing which es6 style/design-pattern to employ and stick with before coding

Re: Function composition vs pipeline

Just thought I'd point out that the proposal itself entertains the possibility of a corresponding composition proposal [1]. Also, in my proposal, one of my "potential expansions" [2] would open a generic door for "lifting" over a type, addressing the concern of extensibility. (It's not ideal, and

Re: Function composition vs pipeline

Although it doesn't allow composition with generator functions like the composition proposal does, otherwise it's a pretty good solution. My only concern with pipeline is that since it offers a different way of calling functions than the `()` syntax, it can lead to mixed and hence slightly more

Re: Function composition vs pipeline

I'd like to point out the partial application operator: https://github.com/tc39/proposal-partial-application Sounds like the combination of pipeline + partial application would result in what is essentially the same as function composition operator: ``` const h = ? |> f |> g; ``` Which results

Re: Function composition vs pipeline

That could be a problem for readability. I agree with the rest of what you said. On Sat, 24 Feb 2018 at 11:16 Viktor Kronvall wrote: > I don’t know the implications but I could easily imagine the pipeline > proposal being extended to not taking any input on the left

Re: Function composition vs pipeline

I don’t know the implications but I could easily imagine the pipeline proposal being extended to not taking any input on the left hand side and effectively represent composition in the opposite direction. For example: ``` let h = |> f |> g h(2) //g(f(2)) ``` That said, the point holds for the

Re: Function composition vs pipeline

The function composition operator composes function pipelines into functions for later use and/or further composition. Those functions still need to be called via the existing `()` syntax, so it doesn't offer a different way of calling functions as such. The function pipeline operator calls the

Re: Re: Function composition vs pipeline

See also recent discussions in these GitHub issues that touch on composition: https://github.com/tc39/proposal-pipeline-operator/issues?q=composition+sort%3Aupdated-desc. Look particularly at the issues that were created after 2018-01-31 – when Gilbert/Mindeavor split the proposal into four

Re: Function composition vs pipeline

How is either operator not "a different way of calling functions"? On Thu, Feb 22, 2018 at 8:34 PM, Naveen Chawla wrote: > I was just thinking about the relative merits and coexistence (or not) of > function composition operator and function pipeline operator features: >

Function composition vs pipeline

I was just thinking about the relative merits and coexistence (or not) of function composition operator and function pipeline operator features: e.g. https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition https://github.com/tc39/proposal-pipeline-operator They can