In my post about GIFs, I pointed out that the creators of the GIF file format explicitly said that it wasn’t meant to be a great format for animations, but since it was widely available in people’s browsers, and no-one actually read that spec, it ended up being used for animations all over the place anyway, and now it’s all the format is known for. By opening a technological window, and allowing some limited animations to be stored in .gif files, they closed a door (new file formats with more advanced compression are constantly pushed back on because people are used to GIFs.)

Unrelatedly, here are two keywords that exist in JavaScript: const and let. let creates a variable that can have a new value assigned to it later, while const creates a variable that will always have the same value attached to it. const is the typical way that people declare variables in modern JavaScript; thanks largely to linting rules and style guides like the Airbnb JavaScript style guide, which for whatever reason was very popular back in the day, a generation of programmers learned that changing the values of variables was to be avoided, and obviously const is the way to do that, right?

If you’ve actually programmed in JavaScript, you know that the keyword const is misleading. Technically, in a high-falutin’ referential identity sense, const variables can never have a new value attached to them, but it is in fact the case that everything about any object or array that’s assigned to a const variable can be completely and totally changed at your whim. In other words, altering const variables’ values is often trivial and the whole keyword is kind of a lie. In more static languages, like C++, it is difficult to change data that is attached to a const variable; in JavaScript, it’s pretty easy, probably because the keyword const was not originally part of the language and was only shoved in later.

Who added let and const to the language? What do they have to say about this inevitable source of confusion for newcomers and sane people? At least in some cases, apologies:

Dave Herman, who was part of the TC39 committee that standardized ES6, which is the version of JavaScript that officially added let and const, has a lot of feelings about how things ended up. Here are a few of them:

A lot of feelings. Point is, at least within the subset of TC39 members that yap about it, the original intent was not for const to be the default variable declaration keyword in JavaScript. I think that the argument is pretty straightforward: In languages like C++, const is useful because the compiler will prevent you from altering any data that’s assigned to a const variable, so it lets you set rules about which data is alterable and which isn’t. In JavaScript, though, const doesn’t work like that: since values assigned to const variables can still be altered, all the keyword really does is send a signal to anyone reading the code that you think some value shouldn’t be altered. Except, if you use const by default, that signal is diluted to the point of meaninglessness, because it’ll also be used for variables that store objects or arrays that do, in fact, get altered.

Nevertheless, possibly out of misplaced nostalgia for more rigorous programming languages’ semantics, const is now used everywhere. By opening a window (letting people use const to make variables kind-of constant, but not really), the TC39 committee closed a door (there’s now no way for a programmer to signal that a value really shouldn’t be altered, because const is used for everything, including objects and especially arrays that do get altered.)

Is this a bad thing? Honestly, the right answer is probably not to care. With a lot of this kind of programming language minutiae, doing the “right thing” isn’t actually that different or helpful; my opinion is often that, even when a rule like this is technically correct, it’s probably not important enough to add error squiggles to an IDE window over it. Every creative pursuit has tiny little battles over niche stuff like this: writers argue about said-bookism, and photographers compare the bokeh of different lenses, but being right about either thing doesn’t change a bad book or photo into a good one.

It does sometimes lead to programming language decisions being made from an adversarial mindset, though, in which the designers say: “If we add [some feature] to our language, how will programmers misuse it?” Go is a programming language that is admired by practical people for its enticing simplicity, wherein things like the ternary operator (the ? operator) just don’t exist. According to the language’s official FAQ, this is because “the language’s designers had seen the operation used too often to create impenetrably complex expressions.” It seems likely that the only way to prevent programmers from using language features in ways that don’t meet your standards is not to include them at all. It kind of means treating your target audience like idiots, but sometimes the whole entire target audience does apparently completely misunderstand how you wanted them to do things.

Credit to this Epic Web Dev talk, “Let me be” by Ryan Florence, for originally surfacing some of Dave Herman’s tweets.