3
$\begingroup$

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.
$\endgroup$
9
  • 2
    $\begingroup$ I’m voting to close this question because this is not very answerable unless you're a JavaScript creator. $\endgroup$
    – CPlus
    Commented May 26, 2023 at 20:38
  • $\begingroup$ related on meta: 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 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? $\endgroup$
    – starball
    Commented May 26, 2023 at 20:42
  • $\begingroup$ also related on meta: What do we think of "soft / meta" questions?. $\endgroup$
    – starball
    Commented May 26, 2023 at 20:43
  • 2
    $\begingroup$ 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. $\endgroup$ Commented May 26, 2023 at 21:36
  • 1
    $\begingroup$ @starball while you wrote those two comments, I had written this 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)! $\endgroup$ Commented May 26, 2023 at 22:47

2 Answers 2

6
$\begingroup$

I was at a presentation by Brendan Eich at Strange Loop 2012 where he began by speaking to some of these, with code examples on the slides. 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.
$\endgroup$
4
  • 2
    $\begingroup$ 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, but doing so would improve this post's long-term value. $\endgroup$
    – starball
    Commented May 26, 2023 at 22:47
  • $\begingroup$ @starball Your question asks what they regret and what they would do differently, not why they regret it. $\endgroup$
    – kaya3
    Commented May 26, 2023 at 22:49
  • 1
    $\begingroup$ 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... $\endgroup$
    – Michael Homer
    Commented May 26, 2023 at 22:50
  • 2
    $\begingroup$ @kaya, well, maybe not 1:1, but the title of the question includes: "what would they do differently and why?" $\endgroup$
    – starball
    Commented May 26, 2023 at 23:10
6
$\begingroup$

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. 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, 7:20, 21:52, 22:39).

He invites the audience (at 5:25) 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) 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) 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) let and var: Get rid of var and use let- the argument being that let confuses Java developers less.

  • (at 12:23) null and undefined: Get rid of null- the argument being that typeof null is broken, and pointing to the "billion dollar mistake". 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) Callbacks- should the continuation argument be the first or last? Put it first. This plays nicer with rest parameters.

  • (at 43:18) Camel-case and snake-case: use names with spaces (he presents no rationale for this particular choice).

$\endgroup$
1
  • 1
    $\begingroup$ Implicit, no-opt-out null chaining is not without precedent — Objective-C does that, for example. $\endgroup$
    – Bbrk24
    Commented May 26, 2023 at 22:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .