Unbias the names, please?

[benlesh]

I know there's probably momentum with the names, and it's a silly request, but the names are biased, can we change them to something neutral?

"Smart" pipeline vs "F#" pipeline? One of those proposals clearly has a better marketing team.

Or at the very least, rename "F# Pipeline" to "Simple pipeline". So then it's "Smart vs Simple". haha.

[mAAdhaTTah]

Hah, for me, as a proponent of the F# Pipeline, I think "F# Pipeline" is more descriptive of what it is / how it works, whereas "Smart Pipeline" doesn't tell me much. I'd personally be inclined to change that one, but I'm generally a bit resistant to changing the names at all at this point, given that we've been putting out communications using those names (e.g. the blog post I wrote for babel: https://babeljs.io/blog/2018/07/19/whats-happening-with-the-pipeline-proposal).

[dead-claudia]

It's very easy to read "F# Pipeline" and know exactly what it means, if you're familiar with what F# does, but if you aren't, "smart" would still be more self-explanatory. The term "smart" comes from the numerous ways it tries to "intelligently" adapt to various ways of using it. It's not as obviously precise, but you can't really summarize it in a title without either being so general you start losing some of the meaning (as is the case now) or being inaccurate about some facet of it. Besides, naming things in general is hard.

I personally feel the "smart pipeline" variant is trying to solve problems that don't really exist, though, and I've held that view for pretty much the entirety of its existence.

[aikeru]

In spite of being called "smart", its usage can be simpler in practice. Here's a real-world use-case (ie: an app in production I maintain). We currently use the bind operator :: to give helpers like set, setIn, etc. against immutable objects (from seamless-immutable) so we needn't modify the prototype.

Today that's something like:

function set(...args) {
  return Immutable.set(this, ...args)
}

// Used like
foo :: set('bar', true)
  :: set('foo', false) // Make a copy with "bar" true and "foo" false

With smart pipelines, it doesn't change a lot...

const set = Immutable.set

foo |> set(#, 'bar', true)
  |> set(#, 'foo', false)

With F# pipelines, we need to do one of these...

const set = Immutable.set

// Either an arrow function ... oh dear
foo |> (x => set(x, 'bar', true))
  |> (x => set(x, 'foo', false))

// Or a curried helper
const set = (...args) => (obj) => {
  return Immutable.set(obj, ...args)
}

// This is clean, but requires the complexity of that helper above
foo |> set('bar', true)
  |> set('foo', false)

Am I missing something?

[mAAdhaTTah]

@aikeru There's a lot more to it, but there are also plenty of other threads to have that debate. This is mostly about naming.

That said, given that the names themselves are going into the babel plugin itself, I think this ship has sailed.

[dead-claudia]

@mAAdhaTTah I agree the ship has already sailed, but it's not like we can't just call it back and tell it to go somewhere else. Besides, TC39 has made far more drastic changes way later in the game than this - consider the mess with decorators as a good concrete example of this in action.

Also, private fields/slots/symbols/whatever have gone through like 5 different renditions already: relationships, then private slots, then abstract refs (basically weak map-backed private slots), then private fields (basically private slots again), and now private symbols (which function similarly to private symbols). So even stuff that seems the most certain can still flip on a dime.

[mAAdhaTTah]

@isiahmeadows If we fundamentally changed the proposals like those examples, I would be in favor of giving them new names. I just don't see an alternative name that communicates the proposal so much better than "F# Pipeline" does that it would be worth attempting to rebrand it.

[dead-claudia]

Those were just examples of why I don't see the name as completely immutable, even though it's already in broad use. I'm not saying they have to (or even that they should), just saying that it's not a lost cause to get it changed if they really wanted to.

[littledan]

I don't think these names are going to be biasing people in practice. Most people I talk to prefer the minimal, F# approach, even though the other one is called "smart". I'd be fine with renaming F# to Simple, though, if that makes it easier to understand (I think we can all agree that the F# alternative is simpler.)

[aikeru]

@littledan I'd just like to point out that the F# proposal is not simpler to use and does in fact require more complexity to make use of, as far as I've seen. If I'm wrong I would like to be enlightened.

Perhaps by "simpler" you meant it has less features or has a smaller spec or something? Or perhaps I am confused... :)

FWIW I wish the "smart" proposal was named something else.

[js-choi]

The terminology originally came from someone’s nomenclature (from @gilbert, I think) back in late 2017 and early 2018. Back then, there were terms like “split mix” and “smart mix”. Lots of ideas were flying around, and his nomenclature clarified them much. You can still see its vestiges in the wiki and in our proposals’ numbering in some of the issues here (1, 2, 3, 4). Now that split mix has been abandoned due to it seemingly being unpopular, only “smart mix” is left, so its name has become less specific. I’d be fine with renaming smart pipes to something like “placeholder pipes”. Nothing in the proposals is nailed down.

The only problem is that it would be a hassle to update everything, especially without breaking links and Babel code, just for tweaking the name. It might be worth looking into later, but we’re working on the Babel plugins right now.

All of the proposals would solve problems that exist in real code. They just make different tradeoffs, with varying amounts of payoff to varying people.

[littledan]

Placeholder pipes seems like a decent name too. The amount of code that will break only increases over time from here, as people adopt the Babel transform.

[js-choi]

“Hack style” is another option: It’s what @gilbert’s nomenclature originally called the placeholder concept, as a parallel to “F# style”—and that came from @zenparsing’s original proposal in #84. Though, technically, smart pipes mix both Hack style and F# style.

[dead-claudia]

@aikeru

@littledan I'd just like to point out that the F# proposal is not simpler to use and does in fact require more complexity to make use of, as far as I've seen. If I'm wrong I would like to be enlightened.

Perhaps by "simpler" you meant it has less features or has a smaller spec or something? Or perhaps I am confused... :)

FWIW I wish the "smart" proposal was named something else.

I know this wasn't aimed at me, but by "simpler", he means conceptually, not necessarily to use. The F# style is simple sugar for x |> f ↔ f(x), so things like getValue() |> (value => value + 1) desugars to (value => value + 1)(getValue()) and, thanks to lambda calculus, to getValue() + 1.

Usability is roughly equivalent between the two, since the F# style requires explicit functions for simple operations, while the smart style requires ceremony to do things like stream |> (debounce(10)).

[littledan]

Let's stick to the naming in this thread, and discuss the tradeoffs between the alternatives in other threads. I think we can all agree that we'd like to choose something which is good to use.

[zakhenry]

I’d like to see some more proposals for naming - I’d like to suggest “Pointfree pipelines” and “Placeholder pipelines”. Unfortunately even this has some difficulties as pointfree can sound a bit functional programming scary, and placeholder can sound like a temporary solution. “Topic reference pipelines” is another possibility

[dead-claudia]

@zakhenry IIRC they were at one point called "topic pipelines" really early in their design, when it was first being put together.

I like "Placeholder pipelines" better IMHO - they use an explicit placeholder rather than the implicit argument position of the Elixir style (it's being considered, just not listed) or direct function call of the F# style.

[tabatkins]

Coming back to this, I agree we should avoid non-descriptive words that contain value judgements; both "minimal" and "smart" are bad by this criteria.

I suggest either "F#-style" or "functional-style" for the one that expects its RHS to be a function, and "topic-style" for the one that bind a topic reference over its RHS.

("Placeholder-style" isn't bad, per se, but it also sounds like it's a TBD name. ^_^)

[ghost]

@tabatkins I'd love to see "topic style" for smart and something that isn't a branded name for F#. Maybe "curry style"? I think they're both "functional", but that would still be better than "F#".

[ghost]

What a waste of time thread. No wonder this proposal has not progressed with distractions like this

One can easily see all the ppl that don’t want this proposal to move forward or only move forward under their terms if you just stick around for a while

This is such BS smh

I feel like this borders on abusive and aggressive and regardless of your intent, there are more constructive ways to communicate your feelings.

[mAAdhaTTah]

If we decide to change the names, we'll need to update the babel plugins, probably with aliases between the old & new.

That said, there's a good amount of writing out there using the current names; I'm not sure changing them now is material, tbh, as people will likely need to refer back to the original names in order to avoid confusion.

It's not impossible, but I'm still not convinced the benefits outweigh the costs here.

[tabatkins]

I have to say, this is the first time I've heard backwards compat being used as an argument to not make a change to a proposal that's only vaguely stage 1. ^_^

[tabatkins]

Closing this issue, as it was resolved a long time ago (we switched over to "F#-style" and "Hack-style" as the naming convention).