Hacker News Reader

> I believe avoiding unnecessary temporary variables in a very valuable thing for the reasonability of code

I’m not convinced temp vars are avoidable in production code, since usually you end up needing error checking/handling on intermediate results anyway. Teams I’ve worked on generally try to avoid dense nested and/or chained expressions for this reason, but also because too much density or conciseness also limits the readability/reasonability of code.

I like that pipes turn nested expressions right-side out like the article points out, but temp vars already do this too.

The other thing that temp vars help with is making it easier to change functions in the middle of a sequence. If you have a nested expression, sometimes having to refactor something in the middle leads to a bigger avalanche of changes than necessary. Using temp vars might be somewhat less churn in some cases due to already haven broken down the expression into pieces. Maybe this pipes design will allow that too, it’s hard to say without using it for a while.

In practice pipes actually work in the opposite direction, the one you like: they allow people to break down nested expressions. Pipes allow the language to report granular line numbers and you can do error handling in them, if it’s functional (not if you need try catch of course).

While I’ve been on the team pushing for pipes and for the Hack variant, I do appreciate that there are many instances where giving an expression a name is helpful.

This is a tool that comes with great responsibility. My hope is that people will learn how to use it. It’s worth it imho the added language complexity.

The more ways there are to write in a language, the harder it gets to read the code of someone else using a different style guide, or with different preferences, than you. This matters a whole lot in a language so completely dependent on 3rd party libraries as JS is.

Not that I think this will hurt much, as the language and community fled that barn long ago. There are already 50 ways to do most things in JS, half of which will be present in your deps, and only 5 of which a typical active JS developer will happen to have stored in their brain at any given time.

This is certainly true. But this is also true of human languages, very few of which 'stop development' at the level of complexity of even the most complex programming language.

I love a good lisp or ML, and all things being equal, less syntax is probably better than more. But flexibility is also a good thing, and the irony is that the proof is almost always in the pudding - if a language gets too complex (e.g. Perl, C++), it is almost always true that the community eventually establishes solid guidelines around which idioms to avoid (or when to avoid them). Sometimes there's pain, but rarely do languages die because of it.

I think it's possible to have a reasonable debate about when to introduce new language features, but around here, in my opinion, the pendulum has swung very far toward the "don't move my cheese" side of things.

What do you want from this community? All we hear, day and night, is how JavaScript sucks and has gotten ridiculously complicated. Now someone shows up with a proposal for pipes or the F# people and their pipes, like, what do you want from us?

We’re aware of what’s happening, or has happened to JS, and we’re having the realistic discussion about this stuff finally. The once ‘oh neat, new JS thing, let’s use it’ phase is over. We’ve seen the concrete impact of too much shit layered on top of each other in actual workplace codebases.

If you wanted this, you shoulda came earlier, the party is finished. We went too far between 2010-2020 and we’re all exhausted. It’s got nothing to do with ‘don’t move my cheese’ and everything to do with ‘I think we’re good over here, thx’.

We need to take a step back, evaluate all the nonsense (clean up after the party), before we can throw another one.

Like, it’s all good F# pipe people, totally appreciate your input, but we have our own clusterfuck that needs to be sorted out at the moment, maybe next time.

Programming languages are tools. I don't like it when I find out I'm going to need yet another set of bits for some new type of screw head, either. Doubly so if it's at-best marginally better than the two next-best kinds I already own. Takes up space, more shit to misplace or mistake for something else, et c.

> This is certainly true. But this is also true of human languages

Yes, but this goes to the parent's point. Natural languages dialects can be so distinct that even though two interlocutors may be speaking the same language (e.g. English), they still might not be able to understand one another.

Classic example: https://www.youtube.com/watch?v=73d6h_go7QI

This happens in computer programming languages as well. If you're a C++ programmer who uses smart pointers for everything, then you will have a rough time with my C++ code that uses raw pointers for everything. Even though we would both call ourselves C++ developers, our code follows different idioms, they are essentially different "dialects" of C++. I put dialect in quotes, because I wonder if there is any effort to track, catalogue, or otherwise create a taxonomy of computer programming language dialects as is done for natural language dialects.

Like, you can figure out where someone was born based on the words they use. Can you figure out what kind of projects a person has worked on, the companies they worked for, or the school they went to based on the style of code they write? This would be the job of a linguist or sociologist I think, and I don't know how often they look toward or communities for study.

> The more ways there are to write in a language, the harder it gets to read the code of someone else using a different style guide, or with different preferences, than you. This matters a whole lot in a language so completely dependent on 3rd party libraries as JS is.

Hmmm, kinda.

The pipe operator enables more readable code, so whilst I agree there would be more ways to do things, the average code readability could well go up.

The average absolutely won't. The average dev misuses new language features.

Every time one of these things is introduced, 90th percentile code gets cleaner and 50th percentile code gets worse.

This is what they said about fat arrow functions and that's only true in some cases.

it also leads to our discipline accomplishing more and more as the years pass

All that seems to be being accomplished -- especially in the JS world -- is reinventing the same things over and over again in some sad attempt at "modernity", but using increasingly more resources to do so (and in the process, irritating more users and even developers.)

and the industry would be an order of magnitude smaller than it is

It's already too big, having traded quality for quantity far too much. I get the feeling that a lot of developers seem to be stuck in some weird "bubble of positivity" that makes them immune to negative feedback and think they can do whatever they want and users will love them for it, but if you talk to the users, the reality is quite different.

As the old saying goes: "It's not the tool, it's how you use it." If we stop trying to constantly create and promote new tools, maybe developers can start actually getting good at using the existing ones, and only then will quality go up.

> I read these sort of objections all the time and all I can think is that if we took the "change almost nothing about our tools - think of the juniors!" approach advocated by these folks

Weird, when I started programming I wished there were a pipe operator and I never understood why it didn’t exist in most languages.

> I read these sort of objections all the time and all I can think is that if we took the "change almost nothing about our tools - think of the juniors!" approach advocated by these folks, we'd still be writing C and the industry would be an order of magnitude smaller than it is.

I don't think that's what those people mean. What those people mean is "if you want something else than JS, use something else than JS". If you want pipes, you can already use OCaml, ReScript, F#. They compile to JS and work well.

> Thankfully, the silent majority seems to understand this just fine, which is why despite the tenor of the conversation around these (and other) parts, our tools do continue to get better and better as the years go by.

Which is also why brain power is lost of things like this or the walrus operator in Python. JS is a fine compilation target. If you really like |> and JS, you can use a babel plugin! I don't see the point of adding it to the base language.

Maybe if people stopped always using the most popular option available, we wouldn't need to constantly add stuff to this popular option, and could have a rich and diverse ecosystem.

I think this just fundamentally misunderstands how languages work in practice. In the vast majority of cases, switching languages is impossible, whereas picking up new words or idioms within the same language is very practical.

And as far as I know, this will be in a future version of ECMAscript, which means that most people will in fact be using this via babel?

"Switching languages is impossible" is a self-fulfilling prophecy. You think you can't, so more stuff get added to the language, so it's less justified to switch, etc. And then you end up with people trying to use immutable structures in JS and having way worse performance (but there's records and tuples coming!). Many people that said that switching languages was impossible happily migrated to Typescript, because the migration was easy. You could do the same with something like ReScript, but instead of getting the codebase more and more strict like with TS, you would transform it more and more into ReScript. There's also often lots of opportunities for small greenfield projects/part of projects.

> And as far as I know, this will be in a future version of ECMAscript

This may be in a future version of ECMAscript. Stage 4 proposals are the one accepted, stage 3 are almost official. This one is stage 2.

It's not _just_ a self-fulfilling prophecy - there are other factors at play here beyond simply "X is good enough". But sure, the more that dominant languages try to pick up good features from other, better languages, the more they will tend to maintain their dominance. This is the way nearly all successful systems behave, incidentally. Please note that it's going to be tough sledding trying to convince JS users not to try to improve their language so that some other clearly superior language can come along and take its market/mindshare.

And, well, yes, I realize we're talking about a future maybe-feature. That said, I assume you're granting my counter-point about how, no matter how you slice it, this is still ultimately "just a babel plugin"?

> Please note that it's going to be tough sledding trying to convince JS users not to try to improve their language so that some other clearly superior language can come along and take its market/mindshare.

My point is that there's no "clearly superior language" compare to JS. Some people want a ML flavor, some people want a C# flavor, some people want a Lisp flavor. I wish people would just use those language and improve the interops instead of putting everything into JS.