<p>And are there underlying, unifying patterns to these regrets and how said creators would choose to create a revolutionary (in the sense of being &quot;more than evolutionary&quot; / making significant breaking changes) version of their language?</p>
<p>Phrased differently, what can we learn from the &quot;authoritatively perceived&quot; <sup><sub>(yes- I am aware that there is an inherent degree of contradiction in that phrasing)</sub></sup> mistakes of the creators of JavaScript?</p>
<p>Some clarifications to the scope of this question:</p>
<ul>
<li><p>You do not need to answer for multiple people in one answer post. Just one is fine too.</p>
</li>
<li><p>If you answer with respect to multiple contributing creators of the lanugage, their thoughts do not need to agree.</p>
</li>
<li><p>Please don't inject the thoughts of people who are not significantly contributing (/have not done so in the past) to the JavaScript (/ECMAScript) language into this Q&amp;A (including yourself unless you are one of those people). If you want such a question, write it as a new question post.</p>
<ul>
<li>In the same vein, <em>as much as you'd personally like to do otherwise</em>, make your best effort to present their ideas faithfully whether you agree with / like them or not.</li>
</ul>
</li>
</ul>

<javascript>
What do various designers of JavaScript regret or dislike about its design? Given the opportunity, what would they do differently and why?
CC BY-SA 4.0
2023-05-26T20:38:55.760Z
I’m voting to close this question because this is not very answerable unless you're a JavaScript creator.
CPlus
CC BY-SA 4.0
2023-05-26T20:42:09.053Z
related on meta: https://languagedesign.meta.stackexchange.com/q/277/251. That I can write an answer that fits the constraints of the question proves that it's possible and not insurmountably difficult. Often all it needs is research effort. A lot of design decision-making discourse is publicly available. Not always, but often. see also [this question](https://languagedesign.stackexchange.com/q/983/251) for example, which was received well. How is that question different with respect to your close-reason? I don't see a difference. Or do you suppose that that question should be closed too?
starball
CC BY-SA 4.0
2023-05-26T20:43:50.193Z
also related on meta: [What do we think of "soft / meta" questions?](https://languagedesign.meta.stackexchange.com/q/235/251).
starball
CC BY-SA 4.0
2023-05-26T21:36:53.917Z
I support this question remaining open. We decided during Definition that questions about language designers' intent were answerable (through publicly available statements, blog posts, etc.) and welcome, and JavaScript is a massively influential language and an excellent case study in (poor) language design and rollout.  I am upvoting and voting to leave open.
rydwolf
CC BY-SA 4.0
2023-05-26T22:38:24.533Z
@RydwolfPrograms I was going to ask for some examples from the Definition phase, but I see that you've already provided them [here](https://chat.stackexchange.com/transcript/message/63661461#63661461). None of the votes or close votes are from me, but I think the problem with this question is not so much about whether or not it's off-topic, but it looks like the asker watched a youtube video ([this one specifically](https://www.youtube.com/watch?v=NPB34lDZj3E)) and [so to speak] asked what it was about and then answered it. Shall we all just watch youtube videos about PLDI and ask questions
Nike Dattani
CC BY-SA 4.0
2023-05-26T22:39:32.707Z
then write answers? Shall we take a textbook and ask what Chapter 1 is about, then answer it, then do the same for all other chapters? It seems like an "inauthentic use" of the platform, even though it doesn't (yet) violate the upcoming 2023 [inauthentic usage policy](https://meta.stackexchange.com/q/388860/391772).
Nike Dattani
CC BY-SA 4.0
2023-05-26T22:43:23.563Z
@NikeDattani I think the core comes down to making useful, on-topic information searchable, understandable, and without noise with respect to the question (Stack Exchange's fundamental goal). When you search the theoretical question title, do you get useful answers, understandable, noiseless information? If so, there's not much point in making a Q&A. If not, then there is (a point).
starball
CC BY-SA 4.0
2023-05-26T22:45:38.603Z
@NikeDattani also, the inauthentic usage policy says: "_Plagiarizing or copying content from websites, books, or other online and offline tools without proper attribution in a manner that violates our [referencing standards](/help/referencing)._" I've paraphrased instead of direct-quoting here, and I've linked to the source and named the author of the content.
starball
CC BY-SA 4.0
2023-05-26T22:47:22.547Z
@starball while you wrote those two comments, I had written [this](https://chat.stackexchange.com/transcript/message/63661739#63661739) in chat. Anyone else that's interested in joining the conversation can feel free to do so there (or here if you think that's better)!
Nike Dattani
<p>I was at <a href="https://www.infoq.com/presentations/State-JavaScript/" rel="noreferrer">a presentation by Brendan Eich at Strange Loop 2012</a> where he began by speaking to some of these, with code examples on the <a href="https://brendaneich.github.io/Strange-Loop-2012/" rel="noreferrer">slides</a>. Particular points he noted were:</p>
<ul>
<li>The deployment process led to an inability to change things after a very very early point in development.</li>
<li>The equality operator.</li>
<li>The curly-brace object literal/code block overload, particularly at the start of statements making <code>{}</code> mean something different.</li>
<li>Implicit type conversions, particularly where they produce inconsistent results and are multi-stage:
<ul>
<li>Making arrays automatically go to comma-separated strings of their values.</li>
<li><code>+</code> converting strings to numbers.</li>
<li><em>Empty</em> strings to zero so that <code>+ []</code> is <code>0</code>.</li>
<li>Non-numeric values to Not A Number, &quot;which is a number&quot; (he blames IEEE754 for this part).</li>
<li>A particular example he draws on is that <code>{} + {}</code> is <code>NaN</code>, while <code>({} + {})</code> is <code>&quot;[object Object][object Object]&quot;</code>, and <code>{} + []</code> is zero.</li>
<li>He gestures at JSFuck as the destination of all these.</li>
</ul>
</li>
<li><code>Array(16)</code> makes an array of 16 holes, which aren't actually there, and not an array with <code>16</code> in it
<ul>
<li>So converting <em>this</em> to a string joins 16 nothings with commas to produce a string of fifteen commas.</li>
</ul>
</li>
<li>Attempts to add nominal classes in ES4.</li>
<li>The &quot;hideous&quot; <code>arguments</code> object, that he did &quot;in a tearing hurry&quot;.
<ul>
<li>The need to use the &quot;insane&quot; <code>Array.prototype.slice.call(arguments)</code> to get a real array from it.</li>
</ul>
</li>
<li>Delimiting regular expressions with slashes out of &quot;Perl envy&quot;, requiring an operator-precedence parse in order to lex.</li>
</ul>

CC BY-SA 4.0
2023-05-26T22:45:42.640Z
2023-05-26T23:21:53.890Z
2023-05-26T23:21:53.890Z
Michael Homer
CC BY-SA 4.0
2023-05-26T22:47:13.173Z
1) could you expand on the "whys"? (what exactly about this specific design point is undesirable) 2) Does Eich elaborate on what he would do differently if he were to start again? Note that [you don't have to give a complete answer to the question](/help/how-to-answer), but doing so would improve this post's long-term value.
starball
CC BY-SA 4.0
2023-05-26T22:49:18.173Z
@starball Your question asks *what* they regret and what they would do differently, not why they regret it.
kaya3
CC BY-SA 4.0
2023-05-26T22:50:51.447Z
It covers the whys as far as they are given, I think. He didn't comment on *what* about the equality operator he wanted to change and you asked me not to editorialise or interpret, so...
Michael Homer
CC BY-SA 4.0
2023-05-26T23:10:54.383Z
@kaya, well, maybe not 1:1, but the title of the question includes: "_what would they do differently and **why**?_"
starball
<p>Douglas Crockford has written an entire book- &quot;JavaScript: The Good Parts&quot; (implying that the rest of JavaScript is not &quot;good&quot; (presumably in some pure or idealistic sense)), and so there's a whole lot that could go in this answer, but here in particular, I'd like to focus on <a href="https://www.youtube.com/watch?v=NPB34lDZj3E" rel="nofollow noreferrer">his talk &quot;The Post JavaScript Apocalypse&quot; at the ConFoo developer conference in 2017</a>. <sup><sub>These are the ideas of Douglas Crockford and not my own. I do not completely agree with them or like them, and I do not necessarily think the reasoning is completely consistent or complete for all his examples, but I attempt to present them in a faithful manner.</sub></sup></p>
<h3>Regretting &quot;clutter&quot;</h3>
<p>In this talk, Douglas focuses on an underlying theme of problems related to &quot;clutter&quot;- having multiple subtly different ways of doing similar things, and wanting to have fewer of them (here he makes a reference to Marie Kondo), where clutter in systems makes them more difficult to use, learn, and work collaboratively on, and leads to endless arguments and debates (&quot;holy wars&quot;) about how things should be done with no real way to really resolve them, which is unproductive at best (if you want to hear more examples of his motivation for decluttering JavaScript, see the following timestamps: <a href="https://youtu.be/NPB34lDZj3E?t=81" rel="nofollow noreferrer">1:21</a>, <a href="https://youtu.be/NPB34lDZj3E?t=440" rel="nofollow noreferrer">7:20</a>, <a href="https://youtu.be/NPB34lDZj3E?t=1312" rel="nofollow noreferrer">21:52</a>, <a href="https://youtu.be/NPB34lDZj3E?t=1359" rel="nofollow noreferrer">22:39</a>).</p>
<p>He invites the audience (<a href="https://youtu.be/NPB34lDZj3E?t=325" rel="nofollow noreferrer">at 5:25</a>) to take part in a disciplined exercise, looking at several examples of &quot;clutter&quot; in JavaScript, and how he might choose to resolve / &quot;de-clutter&quot; them (or what might others might call having a more &quot;opinionated&quot; language):</p>
<ul>
<li><p>(<a href="https://youtu.be/NPB34lDZj3E?t=359" rel="nofollow noreferrer">at 5:59</a>) Tabs and Spaces for indentation: Get rid of tabs. People argue about how wide tabs should be, and argue about whether to use Tabs or Spaces. The arguing wastes a huge amount of time and provides no value. The rationale for dropping Tab is not &quot;which way is better&quot;, but &quot;which one can we get rid of&quot;, and since we can't get rid of Space (presumably because it is used for non-indentation purposes), it should be Tab that goes.</p>
</li>
<li><p>(<a href="https://youtu.be/NPB34lDZj3E?t=615" rel="nofollow noreferrer">at 10:15</a>) Single and Double quotes for string literals: Get rid of Single-quoted strings. The argument being that single quotes are &quot;overloaded&quot; (being used as apostrophes).</p>
</li>
<li><p>(<a href="https://youtu.be/NPB34lDZj3E?t=668" rel="nofollow noreferrer">at 11:08</a>) <code>let</code> and <code>var</code>: Get rid of <code>var</code> and use <code>let</code>- the argument being that <code>let</code> confuses Java developers less.</p>
</li>
<li><p>(<a href="https://youtu.be/NPB34lDZj3E?t=743" rel="nofollow noreferrer">at 12:23</a>) <code>null</code> and <code>undefined</code>: Get rid of <code>null</code>- the argument being that <code>typeof null</code> is broken, and pointing to <a href="https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/" rel="nofollow noreferrer">the &quot;billion dollar mistake&quot;</a>. Instead, use <code>null</code> as an empty immutable prototype-less object (<code>const null = Object.freeze(Object.create());</code>), possibly with the additional behaviour that attempts to reference a property by any name return itself (, which basically makes optional-chaining implicit with no opt-out).</p>
</li>
<li><p>(<a href="https://youtu.be/NPB34lDZj3E?t=1276" rel="nofollow noreferrer">at 21:16</a>) Callbacks- should the continuation argument be the first or last? Put it first. This plays nicer with rest parameters.</p>
</li>
<li><p>(<a href="https://youtu.be/NPB34lDZj3E?t=2598" rel="nofollow noreferrer">at 43:18</a>) Camel-case and snake-case: use names with spaces (he presents no rationale for this particular choice).</p>
</li>
</ul>


CC BY-SA 4.0
2023-05-26T20:24:35.163Z
2023-05-27T01:19:30.727Z
2023-05-27T01:19:30.727Z
starball
CC BY-SA 4.0
2023-05-26T22:10:59.507Z
Implicit, no-opt-out null chaining is not without precedent — Objective-C does that, for example.
Bbrk24
# What do various designers of JavaScript regret or dislike about its design? Given the opportunity, what would they do differently and why?
Posted by: username_0 on 2023-05-26
And are there underlying, unifying patterns to these regrets and how said creators would choose to create a revolutionary (in the sense of being "more than evolutionary" / making significant breaking changes) version of their language?

Phrased differently, what can we learn from the "authoritatively perceived" (yes- I am aware that there is an inherent degree of contradiction in that phrasing) mistakes of the creators of JavaScript?

Some clarifications to the scope of this question:

* You do not need to answer for multiple people in one answer post. Just one is fine too.
* If you answer with respect to multiple contributing creators of the lanugage, their thoughts do not need to agree.
* Please don't inject the thoughts of people who are not significantly contributing (/have not done so in the past) to the JavaScript (/ECMAScript) language into this Q&A (including yourself unless you are one of those people). If you want such a question, write it as a new question post.

  + In the same vein, *as much as you'd personally like to do otherwise*, make your best effort to present their ideas faithfully whether you agree with / like them or not.
**Tags:** javascript
> **Comments:**
> **username_1**: I’m voting to close this question because this is not very answerable unless you're a JavaScript creator.  
> **username_0**: related on meta: https://languagedesign.meta.stackexchange.com/q/277/251. That I can write an answer that fits the constraints of the question proves that it's possible and not insurmountably difficult. Often all it needs is research effort. A lot of design decision-making discourse is publicly available. Not always, but often. see also [this question](https://languagedesign.stackexchange.com/q/983/251) for example, which was received well. How is that question different with respect to your close-reason? I don't see a difference. Or do you suppose that that question should be closed too?  
> **username_0**: also related on meta: [What do we think of "soft / meta" questions?](https://languagedesign.meta.stackexchange.com/q/235/251).  
> **username_2**: I support this question remaining open. We decided during Definition that questions about language designers' intent were answerable (through publicly available statements, blog posts, etc.) and welcome, and JavaScript is a massively influential language and an excellent case study in (poor) language design and rollout.  I am upvoting and voting to leave open.  
> **username_3**: @RydwolfPrograms I was going to ask for some examples from the Definition phase, but I see that you've already provided them [here](https://chat.stackexchange.com/transcript/message/63661461#63661461). None of the votes or close votes are from me, but I think the problem with this question is not so much about whether or not it's off-topic, but it looks like the asker watched a youtube video ([this one specifically](https://www.youtube.com/watch?v=NPB34lDZj3E)) and [so to speak] asked what it was about and then answered it. Shall we all just watch youtube videos about PLDI and ask questions  
> **username_3**: then write answers? Shall we take a textbook and ask what Chapter 1 is about, then answer it, then do the same for all other chapters? It seems like an "inauthentic use" of the platform, even though it doesn't (yet) violate the upcoming 2023 [inauthentic usage policy](https://meta.stackexchange.com/q/388860/391772).  
> **username_0**: @NikeDattani I think the core comes down to making useful, on-topic information searchable, understandable, and without noise with respect to the question (Stack Exchange's fundamental goal). When you search the theoretical question title, do you get useful answers, understandable, noiseless information? If so, there's not much point in making a Q&A. If not, then there is (a point).  
> **username_0**: @NikeDattani also, the inauthentic usage policy says: "_Plagiarizing or copying content from websites, books, or other online and offline tools without proper attribution in a manner that violates our [referencing standards](/help/referencing)._" I've paraphrased instead of direct-quoting here, and I've linked to the source and named the author of the content.  
> **username_3**: @starball while you wrote those two comments, I had written [this](https://chat.stackexchange.com/transcript/message/63661739#63661739) in chat. Anyone else that's interested in joining the conversation can feel free to do so there (or here if you think that's better)!  
---
## 2 answers
### Answer by username_4 on 2023-05-26. Score: 7
I was at [a presentation by Brendan Eich at Strange Loop 2012](https://www.infoq.com/presentations/State-JavaScript/) where he began by speaking to some of these, with code examples on the [slides](https://brendaneich.github.io/Strange-Loop-2012/). Particular points he noted were:

* The deployment process led to an inability to change things after a very very early point in development.
* The equality operator.
* The curly-brace object literal/code block overload, particularly at the start of statements making `{}` mean something different.
* Implicit type conversions, particularly where they produce inconsistent results and are multi-stage:
  + Making arrays automatically go to comma-separated strings of their values.
  + `+` converting strings to numbers.
  + *Empty* strings to zero so that `+ []` is `0`.
  + Non-numeric values to Not A Number, "which is a number" (he blames IEEE754 for this part).
  + A particular example he draws on is that `{} + {}` is `NaN`, while `({} + {})` is `"[object Object][object Object]"`, and `{} + []` is zero.
  + He gestures at JSFuck as the destination of all these.
* `Array(16)` makes an array of 16 holes, which aren't actually there, and not an array with `16` in it
  + So converting *this* to a string joins 16 nothings with commas to produce a string of fifteen commas.
* Attempts to add nominal classes in ES4.
* The "hideous" `arguments` object, that he did "in a tearing hurry".
  + The need to use the "insane" `Array.prototype.slice.call(arguments)` to get a real array from it.
* Delimiting regular expressions with slashes out of "Perl envy", requiring an operator-precedence parse in order to lex.
> **Comments:**
> **username_0** (2023-05-26): 1) could you expand on the "whys"? (what exactly about this specific design point is undesirable) 2) Does Eich elaborate on what he would do differently if he were to start again? Note that [you don't have to give a complete answer to the question](/help/how-to-answer), but doing so would improve this post's long-term value.  
> **username_5** (2023-05-26): @starball Your question asks *what* they regret and what they would do differently, not why they regret it.  
> **username_4** (2023-05-26): It covers the whys as far as they are given, I think. He didn't comment on *what* about the equality operator he wanted to change and you asked me not to editorialise or interpret, so...  
> **username_0** (2023-05-26): @kaya, well, maybe not 1:1, but the title of the question includes: "_what would they do differently and **why**?_"  
---
### Answer by username_0 on 2023-05-26. Score: 6
Douglas Crockford has written an entire book- "JavaScript: The Good Parts" (implying that the rest of JavaScript is not "good" (presumably in some pure or idealistic sense)), and so there's a whole lot that could go in this answer, but here in particular, I'd like to focus on [his talk "The Post JavaScript Apocalypse" at the ConFoo developer conference in 2017](https://www.youtube.com/watch?v=NPB34lDZj3E). These are the ideas of Douglas Crockford and not my own. I do not completely agree with them or like them, and I do not necessarily think the reasoning is completely consistent or complete for all his examples, but I attempt to present them in a faithful manner.

### Regretting "clutter"

In this talk, Douglas focuses on an underlying theme of problems related to "clutter"- having multiple subtly different ways of doing similar things, and wanting to have fewer of them (here he makes a reference to Marie Kondo), where clutter in systems makes them more difficult to use, learn, and work collaboratively on, and leads to endless arguments and debates ("holy wars") about how things should be done with no real way to really resolve them, which is unproductive at best (if you want to hear more examples of his motivation for decluttering JavaScript, see the following timestamps: [1:21](https://youtu.be/NPB34lDZj3E?t=81), [7:20](https://youtu.be/NPB34lDZj3E?t=440), [21:52](https://youtu.be/NPB34lDZj3E?t=1312), [22:39](https://youtu.be/NPB34lDZj3E?t=1359)).

He invites the audience ([at 5:25](https://youtu.be/NPB34lDZj3E?t=325)) to take part in a disciplined exercise, looking at several examples of "clutter" in JavaScript, and how he might choose to resolve / "de-clutter" them (or what might others might call having a more "opinionated" language):

* ([at 5:59](https://youtu.be/NPB34lDZj3E?t=359)) Tabs and Spaces for indentation: Get rid of tabs. People argue about how wide tabs should be, and argue about whether to use Tabs or Spaces. The arguing wastes a huge amount of time and provides no value. The rationale for dropping Tab is not "which way is better", but "which one can we get rid of", and since we can't get rid of Space (presumably because it is used for non-indentation purposes), it should be Tab that goes.
* ([at 10:15](https://youtu.be/NPB34lDZj3E?t=615)) Single and Double quotes for string literals: Get rid of Single-quoted strings. The argument being that single quotes are "overloaded" (being used as apostrophes).
* ([at 11:08](https://youtu.be/NPB34lDZj3E?t=668)) `let` and `var`: Get rid of `var` and use `let`- the argument being that `let` confuses Java developers less.
* ([at 12:23](https://youtu.be/NPB34lDZj3E?t=743)) `null` and `undefined`: Get rid of `null`- the argument being that `typeof null` is broken, and pointing to [the "billion dollar mistake"](https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/). Instead, use `null` as an empty immutable prototype-less object (`const null = Object.freeze(Object.create());`), possibly with the additional behaviour that attempts to reference a property by any name return itself (, which basically makes optional-chaining implicit with no opt-out).
* ([at 21:16](https://youtu.be/NPB34lDZj3E?t=1276)) Callbacks- should the continuation argument be the first or last? Put it first. This plays nicer with rest parameters.
* ([at 43:18](https://youtu.be/NPB34lDZj3E?t=2598)) Camel-case and snake-case: use names with spaces (he presents no rationale for this particular choice).
> **Comments:**
> **username_6** (2023-05-26): Implicit, no-opt-out null chaining is not without precedent — Objective-C does that, for example.  
---
