6 ms·

I think this is obviously a useful tool and yet I worry that JS is going to end up in the C++ hole -- too much syntax for most people to remember, having to car

by dbt00 5y ago

I think this is obviously a useful tool and yet I worry that JS is going to end up in the C++ hole -- too much syntax for most people to remember, having to carve out practical subsets for readability.

ainar-g 5y ago
I'd argue, the too-much-syntax threshold has been passed back when destructuring assignments[1] got in. Now you can witness “beautiful” code like: const [,, { name }] = props; and: const { $ } = window; You can kind of reason about what's going on here, especially if you're a fan of one of the fancy languages with pattern matching, but if you're just a lowly backend developer in one of the “boring” languages, and you just need to fix this one thing in this one JS file, you're not going to have a good time. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- crate_barre 5y ago
  I’ll argue further suggesting Typescript has added to the too much syntax conundrum. Modern JS looks nothing like sensible syntax, and we are definitely in the realm of C++. But alas, no one ever listens in JS. They just add more and more shit until things are unrecognizable. People hate plain JS so much, that they’d rather mutilate into the language they prefer, and people are coming from every corner of programming with every type of preference (pun). One of these days I’m going create a barbarian horde of JavaScript developers and inundate another language, maybe Java, maybe Ruby or Python, and just vehemently insist that they must change their idiomatic style to that of Javascript. Let’s see how they like it. Anyone know why we have 30 imports at the top of each file like it’s Java? Where did that idea come from? Excessive types, huh? Since when? Have mercy on us, please. Edit: These were the welcome and necessary changes IMO: JS just really needed Classes as syntactic sugar for the odd way we replicated it with prototypes. That and the fat arrow (because binding ‘this’ was cumbersome), along with a basic import statement. Destructuring I can live with. Async/await was also necessary. We really didn’t need shit else. Small exception: I’ll make a veery small exception for a minimalist type system, or in other words, only 10% of typescript. I’ll take just the ‘Type’ and that’s all. Last note: Coffeescript did a better job synthesizing JS with ideas of other languages compared to ES6 honestly. Sometimes you have to think about how things mix/fit rather than ‘oh this language has it and JS doesn’t, so let’s add it’.
  - nine_k 5y ago
    As someone who had the pleasure to write plain JS since, say, 2003, I greatly welcome all these changes that make JS less repetitive and easier for writng the correct thing. And JS codebases are so much larger than in 2003 that the old idiomatic style is just unproductive.
  - nawgz 5y ago
    “10% of TypeScript” sounds like words uttered by someone who has never used typescript. Strictly typed programs are incredible. My UIs never crash anymore
    - crate_barre 5y ago
      I disagree. I didn’t start programming with Javascript, in fact I started with your typical compiled languages that literally need types to allocate memory. Even in those languages, I haven’t seen that kind of excessive use of Types that I see in Typescript. I’d love for more people to chime in on this because I was taken aback at how exhaustively Typescript is used by the JS community (different from widespread use, I mean people are literally going overboard with how far they are going with the type system). I’m advocating for a tighter, more minimalist language. It’s not what you put in, it’s what you leave out, remember?
      - nawgz 5y ago
        What kind of programs do you develop in JS? I don't think the kind of low-level programs that are allocating their own memory are anywhere near the same world that JS UIs are, and TS really helps solve JS UI problems like deeply nested JSON access, fully-typed state transitions, and manipulation of component interfaces (i.e. passing partials around so the "user" controls labeling while the component's developer wired functionality). What parts of TypeScript are you finding would impart more value by having been left out? For example, I find it extremely expressive, and I have gotten huge value out of things like accessing return types of functions, aliasing the non-nullable types in a union type, creating sub-types of massive JSON structures via `subtype = MyType["mySubField"]`, Partial/Pick, Exclude/Omit, ... What things have you seen that you don't understand the usage for? Final question: what is the most sophisticated UI component you have ever implemented? For example, I regularly implement what are sometimes referred to as "dataflow editors", so maybe this helps explain why I see value in the more niche sides of TS while you come in and decry the construct entirely
- lmc 5y ago
  I actually really like that syntax. Even from a back-end background.
- 5e92cb50239222b 5y ago
  While it's easy to go overboard with destructuring like function foo({ quux: { foo: { bar: { baz: [first] } } } }) { console.log(first); } (I've seen things like this), that's what code reviews are for. I find destructuring one of the features that made reading (and writing) JavaScript actually tolerable.
  - bionhoward 5y ago
    Try ramda.path https://ramdajs.com/docs/#path https://ramdajs.com/docs/#path
- mhink 5y ago
  It's not difficult to understand, you just can't be bothered to care. In the 7 years or so that destructuring assignment has been available, I've never once seen the 'empty destructuring' in your first example. (And if I did, I'd most likely tell someone to just do `const { name } = props[2];`. The second example is a bit silly- if you're using jQuery that much, autoprovide it using a transpiler and be done with it. My guess is that your org just can't be bothered to care that much about your frontend, so they slap something together that's difficult to maintain, and then blame the language, execution environment, or community for poor results.
  - lifthrasiir 5y ago
    In the other words, if some feature can be recursively composable and a weakness of the feature appears only when highly composed, it's generally not a fault of the feature itself. Of course it can still be argued that an empty destructuring (itself non-composable) should be made invalid.
game_the0ry 5y ago
I already feel that way with some features of ES6 and typescript - though both have more benefits than negative attributes, sometimes there are more than one way of doing things, which introduces a little mental overhead when reading code, and the overhead compounds over time. For example, types vs interfaces in typescript - they can be used interchangeably in many cases, and not in a few other cases. [1] Let's KISS, not over complicate for the sake of more features that may be negligible in value. And let us especially not introduce features that can overlap. [1] Example: "A class can implement an interface or type alias, both in the same exact way." - https://stackoverflow.com/questions/37233735/interfaces-vs-types-in-typescript https://stackoverflow.com/questions/37233735/interfaces-vs-t...
nine_k 5y ago
This is a very lightweight addition, with a huge quality-of-life impact, and one which must be immediately appealing to everyone, not just the FP crowd. C++'s syntax problem, to my mind, is not that it's excessively large, but that it's excessively clever and error-prone, and sometimes not very uniform. It's hard for humans to parse. This proposal does not introduce any special cases, it adds one (or two, if |?> is also accepted) very clearly defined operators, proven by practice. It makes parsing things by humans easier.
oweiler 5y ago
I've said the same a few years ago on Reddit and got downvoted to hell. JS due to maintaining backwards compatibility is already huge (syntax-wise) and is going to grow even bigger.

by dbt00 5y ago

ainar-g 5y ago

I'd argue, the too-much-syntax threshold has been passed back when destructuring assignments[1] got in. Now you can witness “beautiful” code like: const [,, { name }] = props; and: const { $ } = window; You can kind of reason about what's going on here, especially if you're a fan of one of the fancy languages with pattern matching, but if you're just a lowly backend developer in one of the “boring” languages, and you just need to fix this one thing in this one JS file, you're not going to have a good time. [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

crate_barre 5y ago
I’ll argue further suggesting Typescript has added to the too much syntax conundrum. Modern JS looks nothing like sensible syntax, and we are definitely in the realm of C++. But alas, no one ever listens in JS. They just add more and more shit until things are unrecognizable. People hate plain JS so much, that they’d rather mutilate into the language they prefer, and people are coming from every corner of programming with every type of preference (pun). One of these days I’m going create a barbarian horde of JavaScript developers and inundate another language, maybe Java, maybe Ruby or Python, and just vehemently insist that they must change their idiomatic style to that of Javascript. Let’s see how they like it. Anyone know why we have 30 imports at the top of each file like it’s Java? Where did that idea come from? Excessive types, huh? Since when? Have mercy on us, please. Edit: These were the welcome and necessary changes IMO: JS just really needed Classes as syntactic sugar for the odd way we replicated it with prototypes. That and the fat arrow (because binding ‘this’ was cumbersome), along with a basic import statement. Destructuring I can live with. Async/await was also necessary. We really didn’t need shit else. Small exception: I’ll make a veery small exception for a minimalist type system, or in other words, only 10% of typescript. I’ll take just the ‘Type’ and that’s all. Last note: Coffeescript did a better job synthesizing JS with ideas of other languages compared to ES6 honestly. Sometimes you have to think about how things mix/fit rather than ‘oh this language has it and JS doesn’t, so let’s add it’.
- nine_k 5y ago
  As someone who had the pleasure to write plain JS since, say, 2003, I greatly welcome all these changes that make JS less repetitive and easier for writng the correct thing. And JS codebases are so much larger than in 2003 that the old idiomatic style is just unproductive.
- nawgz 5y ago
  “10% of TypeScript” sounds like words uttered by someone who has never used typescript. Strictly typed programs are incredible. My UIs never crash anymore
  - crate_barre 5y ago
    I disagree. I didn’t start programming with Javascript, in fact I started with your typical compiled languages that literally need types to allocate memory. Even in those languages, I haven’t seen that kind of excessive use of Types that I see in Typescript. I’d love for more people to chime in on this because I was taken aback at how exhaustively Typescript is used by the JS community (different from widespread use, I mean people are literally going overboard with how far they are going with the type system). I’m advocating for a tighter, more minimalist language. It’s not what you put in, it’s what you leave out, remember?
    - nawgz 5y ago
      What kind of programs do you develop in JS? I don't think the kind of low-level programs that are allocating their own memory are anywhere near the same world that JS UIs are, and TS really helps solve JS UI problems like deeply nested JSON access, fully-typed state transitions, and manipulation of component interfaces (i.e. passing partials around so the "user" controls labeling while the component's developer wired functionality). What parts of TypeScript are you finding would impart more value by having been left out? For example, I find it extremely expressive, and I have gotten huge value out of things like accessing return types of functions, aliasing the non-nullable types in a union type, creating sub-types of massive JSON structures via `subtype = MyType["mySubField"]`, Partial/Pick, Exclude/Omit, ... What things have you seen that you don't understand the usage for? Final question: what is the most sophisticated UI component you have ever implemented? For example, I regularly implement what are sometimes referred to as "dataflow editors", so maybe this helps explain why I see value in the more niche sides of TS while you come in and decry the construct entirely
lmc 5y ago
I actually really like that syntax. Even from a back-end background.
5e92cb50239222b 5y ago
While it's easy to go overboard with destructuring like function foo({ quux: { foo: { bar: { baz: [first] } } } }) { console.log(first); } (I've seen things like this), that's what code reviews are for. I find destructuring one of the features that made reading (and writing) JavaScript actually tolerable.
- bionhoward 5y ago
  Try ramda.path https://ramdajs.com/docs/#path https://ramdajs.com/docs/#path
mhink 5y ago
It's not difficult to understand, you just can't be bothered to care. In the 7 years or so that destructuring assignment has been available, I've never once seen the 'empty destructuring' in your first example. (And if I did, I'd most likely tell someone to just do `const { name } = props[2];`. The second example is a bit silly- if you're using jQuery that much, autoprovide it using a transpiler and be done with it. My guess is that your org just can't be bothered to care that much about your frontend, so they slap something together that's difficult to maintain, and then blame the language, execution environment, or community for poor results.
- lifthrasiir 5y ago
  In the other words, if some feature can be recursively composable and a weakness of the feature appears only when highly composed, it's generally not a fault of the feature itself. Of course it can still be argued that an empty destructuring (itself non-composable) should be made invalid.

game_the0ry 5y ago

I already feel that way with some features of ES6 and typescript - though both have more benefits than negative attributes, sometimes there are more than one way of doing things, which introduces a little mental overhead when reading code, and the overhead compounds over time. For example, types vs interfaces in typescript - they can be used interchangeably in many cases, and not in a few other cases. [1] Let's KISS, not over complicate for the sake of more features that may be negligible in value. And let us especially not introduce features that can overlap. [1] Example: "A class can implement an interface or type alias, both in the same exact way." - https://stackoverflow.com/questions/37233735/interfaces-vs-types-in-typescript https://stackoverflow.com/questions/37233735/interfaces-vs-t...

nine_k 5y ago

This is a very lightweight addition, with a huge quality-of-life impact, and one which must be immediately appealing to everyone, not just the FP crowd. C++'s syntax problem, to my mind, is not that it's excessively large, but that it's excessively clever and error-prone, and sometimes not very uniform. It's hard for humans to parse. This proposal does not introduce any special cases, it adds one (or two, if |?> is also accepted) very clearly defined operators, proven by practice. It makes parsing things by humans easier.

oweiler 5y ago

I've said the same a few years ago on Reddit and got downvoted to hell. JS due to maintaining backwards compatibility is already huge (syntax-wise) and is going to grow even bigger.