For some niches the answer is "because the convenience is worth it" (e.g. game jams). But I personally think the error prone option should be opt in for such cases.
Or to be blunt: correctness should not be opt-in. It should be opt-out.
I have considered such a flag for my future language, which I named #explode-randomly-at-runtime ;)
One can perfectly fine write correct programs using mutable variables. It's not a security feature, it's a design decision.
That being said, I agree with you that the author should decide if Zen-C should be either mutable or immutable by default, with special syntax for the other case. As it is now, it's confusing when reading code.
A classic strategy!
Example:
let integer answer be 42 — this is a constant
set integer temperature be 37.2 — this is a mutable
cst ↦ 123 // a constant is just a trivial map
st ← 29.5 // initial assignment inferring floatThey're objecting to the "given", though. They didn't comment either way on what the default should be.
Why should it be configurable? Who benefits from that? If it's to make it so people don't have to type "var mut" then replace that with something shorter!
(Also neither one is more 'correct')
I think "const x = something();" would be logical but they've used const already for compile-time constants. There's probably a sensible way of overloading that use though, depending if the expression would be constant at compile-time or not, but I've not considered it enough to think about edge cases (as it basically reduces to the halting problem unless any functions called are also explicitly marked up as compile time or not).
And "variables" in math are almost always immutable within a single invocation. It's not a particularly bad word to use. But there's plenty of options. const/var. let/var. let/mut. var/mut I guess. let/set from a sibling comment.
const f = (x) => {
const y = x + 1;
return y + 1;
}
I've only glanced at this Zen-C thing but I presume it's the same story.
1) A ‘variable’ is an identifier which is bound to a fixed value by a definition;
2) a ‘variable’ is a memory location, or a higher level approximation abstracting over memory locations, which is set to and may be changed to a value by an assignment;
Both of the above are acceptable uses of the word. I am of the mindset that the non-independent existence of these two meanings in both languages and in discourse are a large and fundamental problem.
I take the position that, inspired by mathematics, a variable should mean #1. Thereby making variables immutably bound to a fixed value. Meaning #2 should have some other name and require explicit use thereof.
From the PLT and Maths background, a mutable variable is somewhat oxymoronic. So, I agree let’s not copy JavaScript, but let’s also not be dismissive of the usage of terminology that has long standing meanings (even when the varied meanings of a single term are quite opposite).
In a function f(x), x is a variable because each time f is invoked, a different value can be provided for x. But that variable can be immutable within the body of the function. That’s what’s usually being referred to by “immutable variable”.
This terminology is used across many different languages, and has nothing to do with Javascript specifically. For example, it’s common to describe pure functional languages by saying something like “all variables are immutable” (https://wiki.haskell.org/A_brief_introduction_to_Haskell).
Good luck propagating ideas, as sound as it might, to a general audience once something is established in some jargon.
[1] https://en.wiktionary.org/wiki/mneme [2] https://www.merriam-webster.com/medical/mnemon
No, the term came directly from mathematics, where it had been firmly established by 1700 by people like Fermat, Newton, and Leibniz.
The confusion was introduced when programming languages decided to allow a variable's value to vary not just when a function was called, but during the evaluation of a function. This then creates the need to distinguish between a variable whose value doesn't change during any single evaluation of a function, and one that does change.
As I mentioned, the terms apply to two different aspects of the variable lifecycle, and that's implicitly understood. Saying it's an "oxymoron" is a version of the etymological fallacy that's ignoring the defined meanings of terms.
In Rust if you define with "let x = 1;" it's an immutable variable, and same with Kotlin "val x = 1;"
Neither "let" nor "val[ue]" implies constancy or vacillation in themselves without further context.
Euler used this terminology, it's not new fangled corruption or anything. I'm not sure it makes too much sense to argue they new languages should use a different terminology than this based on a colloquial/nontechnical interpretation of the word.
Also it’s fine that anyone name things as it comes to their mind — as long as the other side get what is meant at least, I guess.
On the other it doesn’t hurt much anyone to call an oxymoron thus, or exchange in vacuous manner about terminology or its evolution.
On the specific example you give, I’m not an expert, but it seems dubious to me. In x+1=2, terms like x are called unknowns. Prove me wrong, but I would rather bet that Euler used unknown (quantitas incognita) unless he was specifically discussing variable quantities (quantitas variabilis) to describe, well, quantities that change. Probably he used also French and German equivalents, but if Euler spoke any English that’s not reflected in his publications.
The use of "variable" to denote an "unknown" is a very old practice that predates computers and programming languages.
f x = let y = x + 1 in y + 1
When reading working code, it doesn't matter whether the language mode allows variable reassignment. It only matters when you want to change it. And even then, the compiler will yell at you when you do the wrong thing. Testing it out is probably much faster than searching the codebase for a directive. It doesn't seem like a big deal to me.
> By default, variables are mutable. You can enable Immutable by Default mode using a directive.
> //> immutable-by-default
> var x = 10; > // x = 20; // Error: x is immutable
> var mut y = 10; > y = 20; // OK
Wait, but this means that if I’m reading somebody’s code, I won’t know if variables are mutable or not unless I read the whole file looking for such directive. Imagine if someone even defined custom directives, that doesn’t make it readable.