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

New Features in ES2019

javascript.christmas

Post reply on HN
Print view View original

11–20 of 123 posts

Re: New Features in ES2019

#11

Post by pythux »

Really liking these new developments! JavaScript is not the horrible language it used to be anymore (in my very subjective opinion). When I started writing JavaScript in 2016 after a Python background I was frustrated every day... Then after some time and learning about which dark corners to avoid, which tools to use, etc. it became quite an enjoyable experience. Nowadays I mostly use a mix of JavaScript and TypeScript depending on the projects and it's been great.

One thing that I am a bit afraid about though is that the language might become more complex and complicated over time because of backward compatibility (C++-like?). I saw that they will be introducing a new function "replaceAll(...)" to avoid the weird semantics of "replace(...)" (stopping after first occurrence unless a 'global' RegExp is passed as argument). And that's great, but that's a new function, and maybe 'replace(...)' should have had this behavior from the start. I hope to be wrong on this one!

Re: New Features in ES2019

#12

Post by [deleted] »

tempguy9999 wrote: post #8
haecceity wrote: post #4

I wonder what kind of shenanigans you could do with Function.toString(). It'd be even better if they had Function.toAST().

In MS's dialect of jscript you could get the function body as a string. That would have been useful in a few cases I'd worked on.

[deleted]

Re: New Features in ES2019

#13

Post by cztomsik »

haecceity wrote: post #4

I wonder what kind of shenanigans you could do with Function.toString(). It'd be even better if they had Function.toAST().

exactly my thoughts! and if we could construct it too and pass it to the new Function(ast) that would make life easier a lot for tool developers

Re: New Features in ES2019

#15

Post by masklinn »

alkonaut wrote: post #10
haxiomic wrote: post #5

Earlier quoted context omitted.

Another sort() quirk that catches people out is not realising it uses string comparison by default [1,2,10].sort() = [1,10,2]

It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base. If the comparison function argument was mandatory in sort() this wouldn’t be a problem.

> It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base.

Stupid defaults is not "the curse of optional arguments", it's the curse of stupid defaults.

Most languages have defaults for these two operations yet have proper defaults rather than stupid ones. Python's list.sort() and int() certainly do, so do Java's Collections.sort() and Integer.parseInt().

Uniquely awful defaults is a historical (and defining) feature of javascript, not of having default values, or optional arguments.

Re: New Features in ES2019

#16

Post by IgorPartola »

Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.

Re: New Features in ES2019

#17

Post by BillinghamJ »

IgorPartola wrote: post #16

Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.

There's plenty of good reasons one doesn't exist. JSON is not JS-specific. It is a standard interchange format used by thousands of languages, many of which have very different date implementations.

If you did have a JSON date, how would you decide what it was? Would it be a timestamp, or a civil date-time? Would it have timezones? Offsets? Locations? Would there be a database along with it required to understand it correctly?

Just stick with ISO8601 strings.

Re: New Features in ES2019

#19

Post by alkonaut »

masklinn wrote: post #15
alkonaut wrote: post #10

Earlier quoted context omitted.

It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base. If the comparison function argument was mandatory in sort() this wouldn’t be a problem.

> It’s the curse of the optional arguments. Same thing with parsing numbers where the second argument magically specifies the base. Stupid defaults is not "the curse of optional arguments", it's the curse of stupid defaults. Most languages have defaults for these two operations yet have proper defaults rather than stupid ones. Python's list.sort() and int() certainly do, so do Java's Collections.sort() and Integer.pa…

The horror that arises in js is due to a combination of unfortunate things like function arity, and coercion. The one I was thinking of is the famous

[1,2,10].map(parseInt)

It’s several things that on their own aren’t mad which taken together produces a crazy result. 10 as the default for an optional second argument of parseInt is fine. But map should only use a single argument closure by default. So map(parseInt) must be equivalent to map(x -> parseInt(x)).

Re: New Features in ES2019

#20

Post by mikece »

IgorPartola wrote: post #16

Not ES directly, but you know what I need on an almost daily basis? A JSON date type. It’s obnoxious to have to pass a string back and forth and parse it on either end between server and browser.

I was going to ask a variant of that question: what is the status of BigInt and when might it clear TC39 approval? In most languages a Date object is just a BigInt with Unix time() making this somewhat obvious. BigInt will allow not only proper Date implementation but Currency and Real types, and many more things.
Post reply on HN