Comment by andai

3 days ago

Given an option that is configurable, why would the default setting be the one that increases probability of errors?

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 ;)

> Or to be blunt: correctness should not be opt-in. It should be opt-out.

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.

But why put it as a global metaswitcher instead of having different type infered from initial assignation qualifier?

Example:

    let integer answer be 42 — this is a constant
    set integer temperature be 37.2 — this is a mutable

Or with the more esoglyphomaniac fashion

    cst ↦ 123 // a constant is just a trivial map
    st ← 29.5 // initial assignment inferring float

> Given an option that is configurable, why would the default setting be the one that increases probability of errors?

They'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')

  • Well, arguably if it's immutable, then it's not a variable so "var" doesn't make sense. The corollary is if it's a variable it should be mutable so "var mut" is a tautology.

    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).

    • Trying to pick a good name for the keyword is valid but it's bikeshedding. Either way the keywords should be consistent and a config option is more trouble than it's worth.

      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.