What’s New in ES2019 • Hacker News Board

Re: What’s New in ES2019

#391

Post by masklinn » Wed, Jul 31, 2019, 5:09 PM UTC

sbergot wrote: post #390

masklinn wrote: post #382

Earlier quoted context omitted.

They're not ambiguous, assignments are declarations unless the variable was pre-declared (via global or nonlocal). Assignment was specifically made a statement to avoid the confusion / typo risks of `=` v `==`.

They are not ambiguous if you have the whole file in your head. This is why there are keywords like "global" & "nonlocal".

> They are not ambiguous if you have the whole file in your head.

They're not ambiguous period, python's `=` always performs a local declaration unless overridden via the keywords you mentioned.

> This is why there are keywords like "global" & "nonlocal".

It's the exact opposite of your statement: `global` and `nonlocal` indicate non-local bindings, because by default all bindings are local and you do not need to have "the whole file in your head".

Re: What’s New in ES2019

#392

Post by masklinn » Wed, Jul 31, 2019, 5:09 PM UTC

contravariant wrote: post #375

masklinn wrote: post #128

Earlier quoted context omitted.

> They could have also implemented flat in terms of flatMap: flatMap(x => x) Flat can flatten any level of nesting (it just defaults to 1), so would be difficult to implement in terms of flatMap.

You could reproduce that behaviour of 'flat' by doing something like: function flatten(x, n=1) { return n > 0 ? x.flatmap(y => flatten(y, n-1)) : x; }

You could also blow up your stack as there is no requirement whatsoever that javascript implementations be tail-recursive.

Re: What’s New in ES2019

#393

Post by erikpukinskis » Wed, Jul 31, 2019, 5:30 PM UTC

rgoulter wrote: post #371

Ajedi32 wrote: post #147

Earlier quoted context omitted.

For what it's worth, there are only two, maybe three methods in that entire list that mutate where it's not obvious: sort, reverse, and (maybe) splice. All the other methods (like push, pop, fill, etc) are methods whose entire purpose is to mutate the array.

That was my first impression. But then the same logic applies to concat. ("I want to add another array").

Sometimes I don’t. Actually usually I don’t, I do a lot of [].concat(a, b).

Re: What’s New in ES2019

#394

Post by zachrose » Wed, Jul 31, 2019, 5:59 PM UTC

afandian wrote: post #12

zachrose wrote: post #9

Earlier quoted context omitted.

In other words you’re concerned that some Array methods mutate the array (push, pop) and some don’t (map, concat)? If so then yeah, that can be annoying and/or confusing.

Yes, it stems from arrays. But extends from there to any collection, built in or custom. Kind of bridges the built in type system but it's really about the expressivity of the language. It becomes especially important in React where you share objects up and down an immutable structure of objects.

Yep. If you've bitten the apple of JavaScript tooling you can kinda sorta rig up compiler-enforced immutable data structures with TypeScript. But IMO if you're going that far it's much easier/well-documented to just use Elm or something.

Re: What’s New in ES2019

#395

Post by Roboprog » Wed, Jul 31, 2019, 6:51 PM UTC

sdegutis wrote: post #342

Roboprog wrote: post #336

Earlier quoted context omitted.

Let me know when (type inference of) partial function application and object literals are easy in Typescript and I’ll consider it.

Do you have a specific example of code that's hard to annotate in TypeScript? I've been using it for about a year without major issues (except somewhat slow compile times).

https://ramdajs.com/docs/#partial

Re: What’s New in ES2019

#396

Post by orange8 » Wed, Jul 31, 2019, 9:18 PM UTC

eropple wrote: post #386

orange8 wrote: post #381

Earlier quoted context omitted.

If you were more comfortable/most familiar with strongly typed languages, then yes. But don't assume everyone has your tastes. Java for example is a very strongly typed language, and I find the verbosity makes it harder to parse. Good, future proof code can be written in any language. There's lots of still functioning, well maintained js written 10yrs back out there.

"I didn't have to write a test to know that I am passing a data structure correctly across every module of my application" is not a "taste" thing and comparing TypeScript to nominative typing isn't a reasonable and fair tactic. We have legacy JavaScript dependencies and most of them worry me. I don't stay up at night worrying about the domain and range of TypeScript ones even if their testing is weak. There's a reaso…

If you write JavaScript with a c# frame of mind, of-course you'll find it akward and hard to test. TypeScript is basically JavaScript written in a c# frame of mind, and there is nothing wrong with that. If it helps some people be more productive, then more power to them. but don't fool yourself that TypeScript is the best way to do JavaScript. If you're finding writing maintainable apps in plain JavaScript hard then you are simply doing it wrong. You can learn how to do it right (hint: its a functional, not a class based language) and add one more tool to your box, or you could stick with Typescript and your comfort zone.

I have worked with TypeScript, and I enjoyed it. It reminded me of ActionScript 3, a language I really enjoyed that's more or less dead now. And I also enjoy plain JS, and its just more powerful and expressive.

> I won't hire a web or Node developer who has a problem with it today because understanding the value of gradual and structural typing is, I strongly think, evidence of baseline competence.

If you think the benefits of "gradual and structural typing" cannot be achieved in JavaScript, you clearly don't understand the language. And that's ok. It is also ok hire people you are comfortable with, rather than those who challenge and disrupt your way. And I wouldnt want to work somewhere where the devs are too rigid or tribal about tools. Am more interested in what I'm building, rather than the tools used.

Re: What’s New in ES2019

#397

Post by orange8 » Wed, Jul 31, 2019, 9:22 PM UTC

Too wrote: post #389

orange8 wrote: post #381

Earlier quoted context omitted.

If you were more comfortable/most familiar with strongly typed languages, then yes. But don't assume everyone has your tastes. Java for example is a very strongly typed language, and I find the verbosity makes it harder to parse. Good, future proof code can be written in any language. There's lots of still functioning, well maintained js written 10yrs back out there.

Java is verbose because it is Java, not because it is statically typed. Let's look at some more modern and ergonomic language instead, like Typescript which is much more relevant to the OP. The typing there might add a few extra characters to your function definitions but you gain them back in terms of less need for documenting the argument types in comments. You hardly ever see typing inside of functions in Typescri…

Java was used as an example of strongly typed taken to the extreme. Something YOU can relate to, as a TypeScript user. In terms of verbosity, the difference between Java and TypeScript is like the difference between TypeScript and JavaScript.

Re: What’s New in ES2019

#398

Post by z3t4 » Wed, Jul 31, 2019, 11:54 PM UTC

heavenlyblue wrote: post #383

z3t4 wrote: post #379

Earlier quoted context omitted.

I find hoisting a convenient feature as I can declare the variable in context to where it's used. It means I do not have to break the flow of how the code reads, making the code easier to understand and less bug prone. Example: if(something) var foo = 1;

So how do you maintain the invariant that this variable is used only if is true _down the line_?

It's only logical that it will be undefined if it's never assigned. With var you can just declare anywhere. While with let it feels like a chore when you have to declare in a parent block, eg. outside the if-block for it to be accessible within another if-block. Lexical function scope works very well in an async language with first class functions, as you deal mostly with functions, which can access it's closures at any time, etc. makes it logical that the function should define the scope, not if-statement or for-loops.

Re: What’s New in ES2019

#399

Post by wbercx » Thu, Aug 01, 2019, 1:31 AM UTC

kdmccormick wrote: post #366

codenirvana wrote: post #332

Earlier quoted context omitted.

Only helps with const. Better use linting to avoid such issues.

> Only helps with const. Can you elaborate?

If the `x` in the example was a const, it would throw an error because the code attempts to assign the value of `y` to `x`. You cannot assign a new value to a const.

Re: What’s New in ES2019

#400

Post by Too » Thu, Aug 01, 2019, 5:38 AM UTC

orange8 wrote: post #397

Too wrote: post #389

Earlier quoted context omitted.

Java is verbose because it is Java, not because it is statically typed. Let's look at some more modern and ergonomic language instead, like Typescript which is much more relevant to the OP. The typing there might add a few extra characters to your function definitions but you gain them back in terms of less need for documenting the argument types in comments. You hardly ever see typing inside of functions in Typescri…

Java was used as an example of strongly typed taken to the extreme. Something YOU can relate to, as a TypeScript user. In terms of verbosity, the difference between Java and TypeScript is like the difference between TypeScript and JavaScript.

I do appreciate the comparison and have suffered enough Java in my life to fully understand it. But i have to tell you again, Java is not verbose because it has "taken strong typing to the extreme" (correlation vs causation), it's just a badly designed language. From the same familiy of languages look at C# and Kotlin for example, they are both much stronger than java (minus checked exceptions) but at the same time very less verbose. There are many other examples of this, C++21 is stronger and less verbose than C++98. Rust can also many times be less verbose than C++ or C and at the same time stronger.

In many cases typescript can also reduce verbosity because of more modern features and transpiling. For example early versions had foreach long before it was in ES and before Babel was as widespread as today. In fact you don't even need to add type annotations at all to run typescript, you can let it try its best on plain javascript, in those places where it's not obvious from context, just add the extra :string.