Utterly flummoxing development process...

[rdking]

As promised several months ago, I'm still not going to make any more suggestions regarding this bolloxed proposal, but I have questions that need answering.

I just finished reading this thread where yet another good alternative to using # was given and shot down because the TC39 board seems to think that such proposals (and there have been many) make it "highly more likely" that a developer will make a hard to detect error.

Here's my question: since when has that stopped well thought-out and syntacticly appealing features from being added into JS?

There's a long history of features since day 1 that act confusingly and still to this day cause developers problems:

• this: Potentially different in different scopes of the same object. a. function (foo()) vs new function (new foo()) b. function vs nested function c. member function (foo.fn()) vs reference to member function (a = foo.fn; a()) d. nested function vs nested arrow function (new in ES6)
• Symbol: Asymmetric primitive constructor. (new in ES5) a. All other primitive constructors allow the use of new to create an object version of the primitive b. Symbol just throws a TypeError if used with new even though typeof(Symbol) == "function"
• Proxy: Confusingly weak. (new in ES5) a. Compares result of proxy handler operations to the results of internal functions called against the target instead of checking for consistency against related proxy handler operations. This makes the original target a confusing and unnecessary constraint on what the proxy can do with calls against the target.

I could go on, but the point should be clearly visible. The TC39 board is no stranger to creating features that cause hard to detect errors. However, these features were still added without using hard to read, non-ergonomic, non-convention breaking syntax. I've been programming for 35 years. It's only been the past 15 of those that I've seen this bewildering trend of programming languages trying to protect the developer from making small, but admittedly potentially disastrous mistakes.

I get it. However, in the past, those were learning opportunities that turned good programmers in to great ones, programmers that knew how to squeeze every last bit of power out of the platform and language combination they had to work on. Those who didn't have the courage to try new and novel things stuck to using the paradigms and techniques they were already comfortable with using. Was there anything wrong with that? IMO, no!

Let me roll it all up this way: the likelihood that one of the many, many sigil-less alternatives will lead to hard to find consistency errors is far, far less likely than someone forgetting a single # somewhere in a 1000+ line JS module producing some obscure error in someone else's code 3+ nested require/imports later. How can I justify this?

1. Who hasn't experienced the pain of trying to find where the missing [.,,,;] goes?
2. Almost every other major C-based language out there has already handled this feature without a sigil. The developers understood the syntax well and has been using them for years.

To assert without evidence (even anecdotal) that developers are highly likely to stumble into such a trap without knowing how to use a debugger and find the issue just feels disingenuous.

[littledan]

Some past decisions could be considered regrettable, but we'll do the best we can this time around.