Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s New in ES2019

blog.tildeloop.com

Post reply on HN
Print view View original

21–30 of 411 posts

Re: What’s New in ES2019

#21

Post by heavenlyblue »

afandian wrote: post #3

It's great to see JS getting some of the features of better planned languages. But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation. In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't…

I still don't understand why neither JSs var or let allow you to redefine the variable with the same name.

I makes chaining things while debugging so much harder:

  let a = a.project();
  let a = debug(a);
  let a = a.eject();
vs

  let a1 = a.project();
  let a1d = debug(a1);
  let a2 = a1d.eject();

Re: What’s New in ES2019

#22

Post by jacobwilliamroy »

wongarsu wrote: post #7
afandian wrote: post #3

It's great to see JS getting some of the features of better planned languages. But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation. In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't…

Mutation is a real weakness of Javascript. I think the general idea is "methods don't mutate unless they are ancient". For example Array.map (an IE9-era feature) doesn't mutate, Array.sort (an IE5.5-era feature) does. Similarly a "for(let i=0; i Proper immutable support (or a stronger concept of const) would also help with this.

> for(let e of arr) e = b

Is that just

  arr.map( e => b )

?

Re: What’s New in ES2019

#24

Post by EGreg »

heavenlyblue wrote: post #21
afandian wrote: post #3

It's great to see JS getting some of the features of better planned languages. But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation. In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't…

I still don't understand why neither JSs var or let allow you to redefine the variable with the same name. I makes chaining things while debugging so much harder: let a = a.project(); let a = debug(a); let a = a.eject(); vs let a1 = a.project(); let a1d = debug(a1); let a2 = a1d.eject();

What’s wrong with

  var a = ...;
  a = a.project();
  a = debug(a);
  a = a.eject();

Re: What’s New in ES2019

#25

Post by afandian »

felixfbecker wrote: post #16
afandian wrote: post #3

It's great to see JS getting some of the features of better planned languages. But I'm still very nervous about some of the stuff mentioned here with regard to mutation. Taking Rust and Clojure as references, you always know for sure whether or not a call to e.g. `flat` will result in a mutation. In JS, because of past experience, I'd never be completely confident that I wasn't mutating something by mistake. I don't…

JS already has immutable objects with `Object.freeze()`. Personally I just use TypeScript which can enforce not mutating at compile time (for the most part).

Thanks. But can I then add and remove items from an immutable object to create new objects?

Part of the immutable value proposition is being able to work with the objects. Based on [0] Freezing feels more like constant than immutable. And the 'frozenness' isn't communicated through the language - I could be passed a frozen or unfrozen object and I wouldn't know without inspecting it.

And freeze isn't recursive against the entire object graph, meaning the nature of freezing is entirely dependent on the implementation of that object.

I really like the language-level expression and type checking of Rust. But it does require intentional language design.

I'm not criticising JS (though I think there are plenty of far better langauges). Just saying that calling `freeze` 'immutable' isn't the full story.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Re: What’s New in ES2019

#26

Post by EGreg »

afandian wrote: post #13
Dextro wrote: post #11

Earlier quoted context omitted.

Yes, this is a real problem and I've been bitten by it more times than I can count. Now I always keep this handy website ready: https://doesitmutate.xyz/

Thanks for sharing. I think this is the kind of thing you just have to learn when you use any language. But when you're switching between half a dozen, being able to rely on consistent founding design principles really makes things easier. And when there aren't any, this kind of guide helps.

Coming from PHP, we’re used to it. Half the methods have $haystack, $needle, and the other half use them in the other order.

Re: What’s New in ES2019

#28

Post by EGreg »

moomin wrote: post #8

That’s a surprisingly small amount of change. I’ll leave it to others to determine if that’s a good or bad thing.

Very good!

Personally, I am not a fan of languages growing. I think C is awesome, because everyone can understand the code, and doesn’t have to be a language lawyer like with C++. Concepts, Lambdas, crazy Template preprocessing, and more. The team can just work, pick up any module and read it without magic.

In C++ I am not even sure if a copy constructor would run vs an overloaded = operator without looking it up.

Re: What’s New in ES2019

#29

Post by pcr910303 »

EGreg wrote: post #24
heavenlyblue wrote: post #21

Earlier quoted context omitted.

I still don't understand why neither JSs var or let allow you to redefine the variable with the same name. I makes chaining things while debugging so much harder: let a = a.project(); let a = debug(a); let a = a.eject(); vs let a1 = a.project(); let a1d = debug(a1); let a2 = a1d.eject();

What’s wrong with var a = ...; a = a.project(); a = debug(a); a = a.eject();

That can’t show the programmer’s intent whether it is mutation (e.g. a = a + someNum) verses defining a new variable with different types (but has a similar meaning so has a same name) (e.g. someKindOfData = [...someKindOfData])

Rust allows this, and it really clears codes up. I don’t have to make up different identifiers for same data but different representations. (e.g. I would do the above code in JS as... someKindOfDataAsArray = [...someKindOfObectAsNodeList])

Post reply on HN