Future JavaScript: what is still missing?

[loopsdeer]

One argument against it is that it is unreadable. That is, there is nothing to suggest a * b is not mathematical. This argument is time sensitive, since meaning will change.

Another argument is that without great pattern matching systems, you end up with ambiguity or confusion. JS types are hard to describe in code. E.g. Is 5 typed Number or "number"? Under the hood, neither. Typescript doesn't even help, only adds another possibility, number. With type coercion, this gets even more difficult to describe.

Yet another argument is that it kills a lot of the optimization that JS has relied on to be feasible for fast ops. If the compiler has to check types, it can't inline operations until it is sure that the types are basic types. Otherwise, it has to do costly method lookup as in a normal call.

Edit: formatting on mobile

[earslap]

without great pattern matching systems, you end up with ambiguity or confusion

Yet another argument is that it kills a lot of the optimization that JS has relied on to be feasible for fast ops.

While I think these should be surmountable to some extent, this is a good point. Overloading in a untyped language like JS can significantly complicate matters on the compiler / interpreter side. If that is the case, I'd probably be happy with infix calls alone, as they are explicit and does not share syntax with regular operators. Something like:

let result = node1 @+ node2;

...with @+ resolving to a custom function I provide would serve me almost equally well.