What’s New in ES2019 • Hacker News Board

Re: What’s New in ES2019

#381

Post by orange8 » Wed, Jul 31, 2019, 11:27 AM UTC

Too wrote: post #372

orange8 wrote: post #362

Earlier quoted context omitted.

How will TypeScript instead of plain JS help the future me? Unless of-course you meant that as a joke (going by the wink).

Type safe code improves code readability, and the future you will most likely read the code you are writing today.

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.

Re: What’s New in ES2019

#382

Post by masklinn » Wed, Jul 31, 2019, 11:51 AM UTC

sbergot wrote: post #228

cocoflunchy wrote: post #148

Earlier quoted context omitted.

Also see assignment expressions recently adopted in python 3.8: https://www.python.org/dev/peps/pep-0572/

In Python things are a bit different because declarations and assignments are ambiguous.

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

Re: What’s New in ES2019

#383

Post by heavenlyblue » Wed, Jul 31, 2019, 11:52 AM UTC

z3t4 wrote: post #379

jarekkruk wrote: post #308

Earlier quoted context omitted.

I tend to mainly use const, let only when necessary. I never use var and set linter to scream about it at me. IE11 supports it, so unless you develop application for IE compatibility mode (my condolences) I don't see a reason to use var. On the other hand var mainly bites you when declaring closures inside loops, also hoisting is just plain weird.

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_?

Re: What’s New in ES2019

#384

Post by masklinn » Wed, Jul 31, 2019, 11:58 AM UTC

runarberg wrote: post #346

mantap wrote: post #258

Earlier quoted context omitted.

No this is not an alternative, it will fail if the array is too large, as you will exceed the maximum number of arguments a function will accept (which is implementation defined). In general the spread operator should only be used for forwarding arguments not for array operations.

> In general the spread operator should only be used for forwarding arguments not for array operations. Not quite. You should also use the spread operator when you are spreading an iterable into an array: const unique = [...new Set(arr)];

Seems like a needlessly unreadable alternative to Array.from unless you're combining multiple iterables or values an iterables e.g.

    const unique = [...a, ...b];

You might expect that concat would work, but it doesn't handle arbitrary iterables:

    > [].concat([1][Symbol.iterator](), [2][Symbol.iterator]())
    [Array Iterator, Array Iterator]
    > [...[1][Symbol.iterator](), ...[2][Symbol.iterator]()]
    [1, 2]

Re: What’s New in ES2019

#385

Post by dotancohen » Wed, Jul 31, 2019, 12:54 PM UTC

munificent wrote: post #282

dotancohen wrote: post #255

Earlier quoted context omitted.

And what if foo had already been defined in the scope?

The new one shadows it.

Local scope might not be what the programmer wants, though, depending on circumstance. Pseudocode:

  i = 3;
  foo = \0;

  while ( i-- ) {
      if ( foo = resultFromFooApi() ) {
          break;
      }
      sleep 1;
  }

  return foo;

Re: What’s New in ES2019

#386

Post by eropple » Wed, Jul 31, 2019, 1:14 PM UTC

orange8 wrote: post #381

Too wrote: post #372

Earlier quoted context omitted.

Type safe code improves code readability, and the future you will most likely read the code you are writing today.

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 reason for that.cs TypeScript is loose where it should be loose and yet strongly encourages flexible but very clear typing that provides significant resistance to broken contracts and misunderstood semantics. 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.

"I write worse code, slower" is defensiveness masked as "a taste thing." We've improved the state of the art and it's better here.

Re: What’s New in ES2019

#387

Post by addicted » Wed, Jul 31, 2019, 1:25 PM UTC

hajile wrote: post #283

addicted wrote: post #117

Earlier quoted context omitted.

Without getting into the merits of allowing redefines in a loosely typed language, the simple reason why JS can't support this is hoisting. Any var/let statement of the form var a = 1; is interpreted as 2 statements. (1) The declaration of the variable which is hoisted to the beginning of the variable scope, and the (2) setting of the value, which is done at the location the var statement is at. Having multiple let s…

That's not quite accurate. It's actually the reverse. Think of the closure as an object. It contains variables like `this`, `arguments`, a pointer to the parent closure, all your variables, etc. The interpreter needs to create this closure object BEFORE it runs the function. Before the function can run, it has to be parsed. It looks for any parameters, `var` statements, and function statements. These are all added to…

We are on the same page.

My point is having 2 let or var statements doesn't actually do anything on the interpreter side.

If JS allowed 2 var/lets without complaining, it would be entirely a social convention as to what that meant, since it would have no effect on the actual code that was run.

And the social convention benefit (which could more easily be achieved with just putting a comment at the end) is probably far outweighed by the many, real examples I've seen where someone has accidentally created a new variable without realizing that variable already exists in scope.

Disallowing multiple vars helps linters identify these situations (which are far more common with var's function level scoping than let's block level scoping).

Re: What’s New in ES2019

#388

Post by eropple » Wed, Jul 31, 2019, 1:50 PM UTC

andybak wrote: post #347

eropple wrote: post #298

Earlier quoted context omitted.

I dunno how to put this in a non-controversial way, but...at some point, I switched from thinking a desirable, throw-the-money-at-them developer is somebody who writes a lot of code to somebody who understands things and is capable of understanding new ones when they arise. I'm not saying that to excuse thrash . Thrash is bad. But like..."oh, at some point you'll have to have somebody who actually understands how the…

> somebody who understands things and is capable of understanding new ones when they arise. Some of us won't let go of the crazy dream that things should be simpler. I want this not because I'm lazy or because I don't understand them but because - dammit - things should be simpler.

Complex things are complex. Attempting to simplify complex systems below this threshold of complexity invariably ends in lost capability or lost fingers when the sharp edge you didn't know was there sneaks up on you.

And web browsers are very complex beasts by design, by accretion, and by necessity.

Sorry, I guess. Does bemoaning it actually help anything?

Re: What’s New in ES2019

#389

Post by Too » Wed, Jul 31, 2019, 2:42 PM UTC

orange8 wrote: post #381

Too wrote: post #372

Earlier quoted context omitted.

Type safe code improves code readability, and the future you will most likely read the code you are writing today.

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 Typescript so it hardly adds any verbosity.

Re: What’s New in ES2019

#390

Post by sbergot » Wed, Jul 31, 2019, 4:21 PM UTC

masklinn wrote: post #382

sbergot wrote: post #228

Earlier quoted context omitted.

In Python things are a bit different because declarations and assignments are ambiguous.

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