6 ms·

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/understand

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?

umvi 5y ago
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.
ainar-g 5y ago
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-variables-are-often-tedious https://github.com/tc39/proposal-pipeline-operator#temporary...
- ravenstine 5y ago
  > 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.
- zodiakzz 5y ago
  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?
atarian 5y ago
> 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.
- TwiceCubed 5y ago
  You're quite the nasty brat, aren't you?
brundolf 5y ago
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.
- zodiakzz 5y ago
  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 https://github.com/tc39/proposal-do-expressions
  - brundolf 5y ago
    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
Zababa 5y ago
> 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.
- zodiakzz 5y ago
  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-in-10-days-and-what-hed-do-differently-today/ https://thenewstack.io/brendan-eich-on-creating-javascript-i...
  - Zababa 5y ago
    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.
- handrous 5y ago
  > 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.
hn_throwaway_99 5y ago
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-examples/ https://winterbe.com/posts/2014/07/31/java8-stream-tutorial-...

umvi 5y ago

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.

ainar-g 5y ago

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-variables-are-often-tedious https://github.com/tc39/proposal-pipeline-operator#temporary...

ravenstine 5y ago
> 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.
zodiakzz 5y ago
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?

atarian 5y ago

> 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.

TwiceCubed 5y ago
You're quite the nasty brat, aren't you?

brundolf 5y ago

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.

zodiakzz 5y ago
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 https://github.com/tc39/proposal-do-expressions
- brundolf 5y ago
  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

Zababa 5y ago

> 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.

zodiakzz 5y ago
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-in-10-days-and-what-hed-do-differently-today/ https://thenewstack.io/brendan-eich-on-creating-javascript-i...
- Zababa 5y ago
  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.
handrous 5y ago
> 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.

hn_throwaway_99 5y ago

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-examples/ https://winterbe.com/posts/2014/07/31/java8-stream-tutorial-...