Comment by zodiakzz | Hacker News Reader

Comment by zodiakzz | Hacker News Reader

Parent Full thread

As someone who will be pulling their hair for the first few years it will have to be transpiled into obfuscated spaghetti code (and will be debugging/understanding it): Why do we need an operator just so people can write unreadable code. Instead of using... descriptively named variables?

  // A. Status quo (as per the proposal)
  console.log(
    chalk.dim(
      `$ ${Object.keys(envars)
        .map(envar => `${envar}=${envars[envar]}`)
        .join(' ')}`,
      'node',
      args.join(' ')
    )
  );

  // With pipes (from the proposal)
  Object.keys(envars)
    .map(envar => `${envar}=${envars[envar]}`)
    .join(' ')
    |> `$ ${%}`
    |> chalk.dim(%, 'node', args.join(' '))
    |> console.log(%);


  // A normal person who is able to write good code (me :P):
  const envVars = Object.keys(envars).map(envar => `${envar}=${envars[envar]}`).join(' ');
  const coloredText = chalk.dim('$ ' + envVars, 'node', args.join(' '));

  console.log(coloredText);

I'm not seeing it... can someone help me understand? Why are their so many proposals trying to force alien syntax into JS from "functional" languages?

As someone who originally would have strongly agreed with you, I think there is actually huge benefits to thinking in this "streaming" mindset.

That is, the first place I really encountered code like this was when Java introduced streams [1]. I wasn't used to programming like this when I first experienced this code, and at first I found it harder to read; it felt obfuscated.

As I got more used to it, though, I started to love it. There are tons of operations in programming like this, where you're really just performing a successive series of transformations on a set of data. Obviously functional programmers are familiar with this, but this is also the paradigm for shell programming, where you're just piping stdout to the next small little program in the chain.

The thing is, now I really feel a bit of a "switch" in my brain when I read code like this. That is, whenever I see this, I'm just like "OK, doing a whole bunch of data processing from some input set to a final output". Over time, when done correctly, I actually find this easier to read, with less verboseness, because my brain already has tons of context about what's going on.

1. Some Java streams examples, https://winterbe.com/posts/2014/07/31/java8-stream-tutorial-...

OP's link provides answers[1] to that question. And in my personal view, they aren't very convincing.

The first answer, tedium, is unconvincing, because pretty much anyone with more than a couple of years of experience in software development in a team knows that ease of reading beats ease of writing.

The second answer, unexpected mutation of temporary variables, seems to point to a deeper issue in JavaScript. That of const not quite being const. Unless you Object.freeze everything.

The third answer, that temporary variables require sequences of statements instead of a single big expression, is more of a feature than a bug, in my personal opinion. Statements allow the reader to comprehend the algorithm one step at a time instead of trying to untangle one giant expression. To say nothing about the fact that a sequence of statements is way more debuggable.

I'd say that JS is moving closer and closer to Perl in its write-only-ness.

[1]: https://github.com/tc39/proposal-pipeline-operator#temporary...

> The first answer, tedium, is unconvincing, because pretty much anyone with more than a couple of years of experience in software development in a team knows that ease of reading beats ease of writing.

Hah, I dunno, man. I guess it depends on how one defines "readable".

If having layer upon layer of indirection through inheritance, dependency injection, procedures split into tiny functions written in no particular order, and magic strings/numbers are considered readable code, then yeah, I suppose most mid-level developers prefer "readable" code.

> The third answer, that temporary variables require sequences of statements instead of a single big expression, is more of a feature than a bug, in my personal opinion.

Simplicity is much more important than even readability, though readability is still important. The more tools we add, the more rules and complexity need to exist around them, all while possibly adding little meaningful benefit.

In all honesty, I think that the most meaningful thing we got out of >=ES2015 is modules, promises and async/await, and maybe constants. Everything else became window dressing around existing constructs but introduced more complexity while also creating more rules. Things like classes were mistakenly implemented to satisfy Ruby and Python developers and to assist transpilers. The more I got away from using inheritance, the more I realized how unnecessary class syntax is. If you can just write a function that takes data and spits out data, then there's hardly any need for other class syntax features. If something seems to need inheritance, chances are you could have written your code to be more composable.

The more we try adding to JavaScript at this point, the more people are going to be encouraged to do things that make themselves feel clever to the exclusion of writing code that future devs won't have to spend hours deciphering.

A huge part of my job is deciphering. I don't know if it's like that for anyone else, but there's so much of it that it really makes me wonder how many millions, perhaps billions of dollars are wasted because engineers are trying to be clever.

Ah, missed that example. I am not seeing a single good argument

> Indeed, the benefits of method chaining are so attractive that some popular libraries contort their code structure specifically to allow more method chaining. The most prominent example is jQuery, which still remains the most popular JS library in the world. jQuery’s core design is a single über-object with dozens of methods on it, all of which return the same object type so that we can continue chaining. There is even a name for this style of programming: fluent interfaces.

Do they know what's so attractive about method chaining/fluent interfaces? They guarantee returning the same damn object/interface (tho the underlying values mutate). This pipe thing is complete opposite of that, what's the relevance here?

It's about reading the code in a natural order.

jquery style: a().b().c().d()

However this isn't tree shakable.

modern esm: d(c(b(a())))

this proposal: a() |> b(%) |> c(%) |> d(%)

I think this is a good summary of why pipeline operators are long sought, more so than the proposal. If you are not fundamentally against chaining calls, there is no fundamental reason to be against pipeline operators because it can be thought as a generalization of chaining with similar pros and cons.

> I'd say that JS is moving closer and closer to Perl in its write-only-ness.

I've never understood why it's common to dismiss Perl as "line noise" while, outside of contrived or unusual Perl examples, it's way less line-noiseish than what I see in certain languages that are, evidently, very popular among people influential in the JavaScript community.

Implicit, repeated re-assignment of a magical "%" variable while adding a two-character punctuation operator to reverse the "direction" that values "travel" is clean and more readable? In what universe?

The example that also uses Underscore, especially, reads like some kind of parody.

> Why are their so many proposals trying to force alien syntax into JS from "functional" languages?

I don't know, why are there so many proposals trying to turn JS into an C#/Java like language? The class syntax, the private fields, TS with its interfaces and abstract classes.

The pipe will lead to more functions and function composition instead of fluent interfaces, which I think is more in line with JS.

I recently had to work with a JS codebase that looked like it was written by Java devs that were fooled by the surface similarities of TS and Java. Everything was a class, usually in a complex hierarchy with a lot of implementation inheritance. The code was deeply imperative and very hard to follow as well as being painfully verbose. It was the worst of both worlds.

Weird, complex hierarchies with implementation inheritance fell out of favor over 10 years ago in Java.

I haven’t used Java in a long time. What is in favor now?

I guess not everyone got the memo.

You don't have to turn something into what it already is. Have you ever looked at the JS standard library String/Number/Math/Date? Heavily inspired by Java if not identical.

> “I was under marketing orders to make it look like Java but not make it too big for its britches. It’s just this sort of silly little brother language, right? The sidekick to Java.”

- Brendan Eich[1]

1: https://thenewstack.io/brendan-eich-on-creating-javascript-i...

Sure, but JS code usually looks nothing like Java. People mostly write functions and data structures, just like in C. You don't start your JS code by writing objects.

> I don't know, why are there so many proposals trying to turn JS into an C#/Java like language? The class syntax, the private fields, TS with its interfaces and abstract classes.

Javascript's very OO, deep down in its bones. Its functions are even objects. It was just cursed with an OO model (prototypal) the distinguishing features of which pretty much all fall under "for the love of god, never actually rely on or leverage this functionality in any meaningful way" as far as how good an idea they are for code readability, and with god-awful scoping rules. "Class" and some other changes make the existing OO features usable in a way that won't have your successors cursing you for your "clever" use of prototypes, and saves tons of dumb boilerplate that never should have existed. It also makes it much clearer to the reader when you intend to treat something as an object, and when you're planning to treat it more like a struct.

I didn't mention OO in general and specifically Java and C#. JS is OO deep down, nobody is denying that, but it's not OO as in Java/C# where writing a function without a class is not idiomatic.

> "Class" and some other changes make the existing OO features usable in a way that won't have your successors cursing you for your "clever" use of prototypes

That's a strawman, you can write "clever" code with classes that will make your successors curse you just like you can write plain and readable code with prototypes.

> you can write plain and readable code with prototypes.

It's really far from being ergonomic, unless you're basically just using JS objects as structs. Otherwise you're dancing around its pitfalls and limitations—visibly, in code, not just in your head—to express things that are very simple and clear in pretty much every other commonly-used OO-supporting language.

> I didn't mention OO in general and specifically Java and C#. JS is OO deep down, nobody is denying that, but it's not OO as in Java/C# where writing a function without a class is not idiomatic.

Sure, JS is multi-paradigm, like tons of other languages. Its early design, and early use in the wild, hints at "Imperative with quite a bit of OO and a sprinkling of functional for things like callbacks" being more-or-less its intended style, but of course that can (and has) changed over time, because the core language has half-decent support for all three styles.

Incidentally, I've yet to see a TS codebase that ties itself in knots to avoid defining a function outside a class, to avoid treating functions as first-class when it makes sense to, or even to avoid a little imperative code outside of objects, here and there. They may exist, but I haven't seen it. I have seen a lot of code using HOFs to the point of absurdity, while passing big objects around to a bunch of functions and pretending that's "more pure" than putting those related functions on a class for that object. Or trying to shoehorn runtime-checked immutability into the language, at a performance cost for end users. Or writing their own weird, crippled form of objects in a language that already has them so they can keep things "pure" and let people keep avoiding the Class keyword for... whatever reasons they want to do that (React Hooks).

> It's really far from being ergonomic, unless you're basically just using JS objects as structs. Otherwise you're dancing around its pitfalls and limitations—visibly, in code, not just in your head—to express things that are very simple and clear in pretty much every other commonly-used OO-supporting language.

That might be because I've started OO with JS and mostly did some with it, but in my experience it's fine. I do tend to not use OO as in "object mutating themselves" much though, outside of cases where it's a great fit like a database connection.

> Incidentally, I've yet to see a TS codebase that ties itself in knots to avoid defining a function outside a class, to avoid treating functions as first-class when it makes sense to, or even to avoid a little imperative code outside of objects, here and there.

I haven't seen big codebases like that, but I've had a few collegues coming from Java/C# start every piece of code by writing a class, usually in a "kingdom of names" styles. I'm worried that TS may enable these people even more in the future.

> I have seen a lot of code using HOFs to the point of absurdity, while passing big objects around to a bunch of functions and pretending that's "more pure" than putting those related functions on a class for that object. Or trying to shoehorn runtime-checked immutability into the language, at a performance cost for end users. Or writing their own weird, crippled form of objects in a language that already has them so they can keep things "pure" and let people keep avoiding the Class keyword for... whatever reasons they want to do that (React Hooks).

I'm not defending "functional" (as in ML/Haskell) JS and agree with you here. If people want to do functional programming, there's OCaml, Elm, F#, Scala.js and ReScript, no need to shoehorn that into JS. I think that's an antipattern, just like doing OO everywhere for the sake of it.

Haha, cool, I think we're actually in agreement. I think JS works best if you embrace its multi-paradigm nature, and attempts to make it either Java or Haskell would be horribly misguided, even if those were both better languages, because the language doesn't really support the things that make going purely into either of those paradigms attractive—with or without TypeScript doing a little compile-time type checking on top.

We are, I totally agree with you!

> Javascript's very OO, deep down in its bones

JavaScript, in its bones, is a mix between an impure functional programming language like Lisp and a prototype-oriented OOPL like Self; forcing Java-style class-oriented OOP into it is a lot more of an impedance mismatch with its “bones” than FP constructs that are common in the kind of FP languages that influenced it from the outset (though neither is a giant mismatch.)

> Why are there so many proposals trying to force alien syntax into JS from "functional" languages?

People want to leave their mark on something big. It's a form of status.

I see two limitations with your version above:

1) consts in JS aren't deeply immutable, so technically these could be mutated. This is a relatively small issue, but also...

2) More and more stuff happens in expression-contexts these days, including (most prominently) JSX. And JS doesn't let you define intermediary consts in expression-contexts (or even in lambdas, unless you build out the full curly-braces and add a return statement). So for many situations the consts version is arduous or even impossible.

1. Pipe proposal doesn't make anything deeply immutable either. In JS you can even use a curly braces block to avoid leaking your let/const variables.

2. I am dreading even thinking about how the pipe thing is supposed to operate on JSX. There's the do-expression proposal to achieve what you want in a sane way: https://github.com/tc39/proposal-do-expressions

1. It doesn't, but mutation is generally less likely to happen in an expression context than in a statement context (partly by convention, but also it's common to eg. lint against assignments in expression contexts)

2. Personally I think it will be quite elegant. JSX itself is an expression, not a function, so it would only ever be the last stage in a pipe (or the context in which a pipe expression is embedded). Note that it would be useful even for just (for example) string transformations that happen to be deeply embedded in some JSX, not exclusively contexts where JSX is directly involved

2b. I didn't know about do-expressions; those look potentially exciting

Yeah but if you just write plain old readable code that doesn't use esoteric syntax sugar, then the problem is that almost anyone can understand it without having to google stuff.

Reply on news.ycombinator.com