[annoyingconst92]

The problem is that, when prototyping and iterating a design I often don't know in advance what should be private or const and what shouldn't be. And when interactively experimenting in the DevTools console I often want to redefine `const shadowMapSize=1024` to `shadowMapSize=2048` but const breaks interactive console redefinition. I have to save the js file to disk and edit shadowMapSize there, then reload the code. This is the workflow for a static language like C++, not a dynamic language like Lisp or JavaScript.

[yashap]

This seems like a realllly weak reason to write less maintainable code (harder than it needs to be for future readers to reason about). For workflows like this, you can easily use let/var while prototyping. Then once you’re done and are cleaning up the code, writing tests, etc., switch to const if the reference is never re-assigned. It’s the same in every language - when prototyping, go wild with god functions, mutable state, public everything, whatever, but clean it up and make it readable/maintained before it gets merged to master.

Also, if you’re talking about leaving mutability like this in the code long term, this really only applies to GLOBAL mutable state, and global mutable state is a terrible thing for code maintainability in any language. If it’s not global, you can’t fiddle with it later in the console anyways. Littering your program with global mutable state just because “someday, someone may want to fiddle with this in the console, and this makes that slightly easier”, that’s just not a reasonable argument.