"If you do like const (which I do) then you can put it in pretty much everywhere"

In retrospect, it might have been better to have a keyword for things that can change. This goes equally for Java and "final". Making immutability the default and mutability opt-in makes for fewer bugs and more reliable programs.

Arguably, this is what Clojure does where you have functional, immutable constructs by default with ways to declare things that can change (refs, etc.).

const by default may not be a bad idea, but immutability of structures/objects in C++ sounds like it would be a huge performance hit to me. I've used an image processing library (CIMG) which lets you do things like `img = img1 * 2 + img2 * 0.5`, instead of editing the image in-place. It's pretty, but with regular 800x600 images the performance was around 2 orders of magnitude below a simple for loop... it made a lot of extra copying and allocation instead of mutating the image.

The thing is, this kind of code isn't an exception in the C++ world. C++ is made for problems where performance matters: image processing, compilers, browsers... immutability works for Clojure, but Clojure is a lot slower than C++. It's more of an "enterprise software" language.

That's usually considered a drawback of C++; it's a huge, complicated language and everybody tends to use a different subset for their own work.

The same can be said of English. And in both cases, there are sundry tasks of limited scope where the language is probably not the most natural choice (e.g. operas). However, when one is simultaneously dealing with multiple, disparate domains/constraints simultaneously (e.g. real-time computer vision), such a language might be the least unattractive option thanks to its inclusiveness.

Except program don't express natural language, and in fact the required context awareness of natural language is exactly what kills many languages and frameworks. I shouldn't have to know all of these things to edit some stranger's code, it should be obvious how it works.

That's not really true. If you need to work with libraries that use const everywhere you have only two options:

* Use const everywhere

* Use casts everywhere

The same thing happens if you use const and your libraries don't...