Yep, I wondered that for a few optimizations in Racket. It's harder than it looks, probably something about covariant or contravariant types, I gave up.

Yes, that’s ObjC, any NSMutableArray is an NSArray (and an NSObject) - classes passed by reference.

Swift is completely different. Standard arrays are structures, always mutable - value types passed by value

"Was" like that? .... Some of us still use Objective-C!

You just misinterpreted what NSArray is. It’s not an immutable type, it’s a read-only type. As others already mentioned that’s different things. If you have a read-only variable and exclusive access to it, then you can rely on immutability as well. This is what Rust has, for example. Many languages use this definition as well as it’s much more useful than having some sort of pure immutable type guarantee (which some languages do have with const). Another language that uses this is Kotlin: List is a read-only type. MutableList is a subtype of List. You can get a “const” List by only keeping a reference to the value via a List binding. This can be worked around via casting and reflection, but even in Haskell you can do unsafe things that mutate a immutable value, so I don’t think that undermines the idea.

intelligence is overrated

If the article is written for human consumption, then it fails the primary goal (or logic?) of being useful. If a human has to digest a flood of this logic slop just to get convinced about this simple concept, they are not going to be able to do anything useful.

In other words, immutable != read only.

In C# ReadOnlyCollection<T> and ImmutableArray<T> are two completely different things for this exact reason.

If you pair mutability with exclusive access then you have handled the objection raised by the (some may say overly) strict definition of subtyping here and also the attempt to argue over the objection. No code which asks for an immutable instance will ever observe the mutability because the ask for an immutable reference is exclusive. Therefore, you could pass the mutable reference but so long as something holds onto that reference the mutability is no longer available to other code.

So mutability xor aliasing provides this strict subtyping relation. Of course, you also then need ways of loosening this by providing objects without such a contract and you enter the land of interior mutability, where again the mutable methods can be understood as a part of a subtype because a holder of the reference without mutable methods was explicitly told that there was no the guarantee that the object wouldn't change.

One of the problems with this comes if you're able to dynamically promote something that was passed to you as an "immutable" type to its actual implementation type, you can break this "contract".

I'm currently being annoyed by python's type hinting system, which has exactly this sort of hierarchy for containers, but there's nothing stopping a caller/callee from using type-narrowing to "discover" that the underlying type is actually e.g. a (mutable) list, and then modifying it without any complaints from the type checker. The only way to enforce this would be to actually convert to an immutable implementation type, involving unnecessary copying.

Fair enough. Although I don't fully subscribe to the dichotomy of compile vs run time, we can say that.

In semantics, types are properties of values and expressions. Type safety is about whether the type of an expression always matches the type of the value it evaluates to.

Doesn’t this break down with dependent type systems?

it may be that my point of view is too narrow

Not sure if you're just being polite but, in case you're doubting, functional languages make that distinction too.

Haskell has `Data.Vector.Vector` vs `Data.Vector.Mutable.MVector`.

Clojure has `transient`.

OP is just mistaken.

A system programming language needs to match hardware where mutability is associated with memory addresses, something functional languages can afford to abstract away.

Which is why "data structures" probably also belong in the "variables" column.

Types are properties of values, not variables.

In computer science, specifically programming language theory, types are properties of terms (syntactic expressions). It wouldn’t be possible in general to typecheck a program before running it if you had to have a value before you could discover its type.

Mutability is a property of variable, not of a value. [...] This has nothing to do with whether it can be reassigned (i.e. mutability).

I feel like you're using "mutable" too narrowly, as it's used colloquially in some programming languages. E.g. in JS, MDN itself talks about "reassignment"[0] and not "mutability" even though people often use "mutability" as a word to refer to the distinction between `const` and `let`. The only mention of mutability there is:

Others may prefer `let` for non-primitives that are mutated

I.e. explicitly using `let` for mutated arrays, even if not reassigned, to make the signal mutability (which JS cannot express).

Note that you used "reassignment" which is the specific word for "mutating a binding", but the article is not referring to bindings at all.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Types are properties of values, not variables.

In statically typed languages, variables and expressions have a compile-time type and values have a run-time type.

Mutability is a property of variable, not of a value.

In which languages?

In D, mutability is a property of a type. And variables and expressions have a compile-time type and values have a run-time type, so mutability is also a property of variables, expressions, and values.

(Immutability is also transitive in D, so an immutable value cannot have mutable parts, including mutable references, and a variable with an immutable type cannot contain a value or reference with any mutable parts.)

When we speak of "type of a variable", we mean this variable can only be assigned (bound to) values of certain type. This has nothing to do with whether it can be reassigned (i.e. mutability).

This seems confused. "Mutable" ot "immutable" are types like any other, like "String" or "Integer".

So the problem is that the semantic of methods (car, cdr) is not well defined: it is either "give me that member" or "give me that member and guarantee next time the result will be same". And the solution is to clearly separate those by adding more method names.

The cons example is conflating implementation details (return the value passed in to cons) with the semantics (return the left-side of this pair that was instantiated by cons). In the first case it is a category error to think about mutability. In the second mutability makes perfect sense.

Moreover, I suspect it is possible to construct an interface such that to prove statically that you can Liskov Substitute a type into it would be equivalent to deciding Halt: All you need are extensional semantics in your type system.

In C, const can also answer B, but only in non-pointer contexts.

What i dont understand is why does everything have to be so brief.

The concept is to make things easier for people who are familiar with the language. Making things harder for that group is always counterproductive, because they are the only people who can do any useful work.

More short names fit in your fovea than long names so for the most common operations they are the easiest to read. It’s the same reason the most common words in human languages are the shortest (and programming languages are for humans to use so subject to the same pressure.

Also, Back In The Old Days memory was very expensive and precious so short identifiers were important. Often labels were tightly constrained, for example being limited to six upper-case characters so they would fit in a single word.

The usual convention (which also occurs in natural languages) is that often-used words should be short, rarely used should (and can afford to be) more descriptive.

Most people actually write small amounts of code in a day, saving a single character here and there typing hardly matters. Its a saving that amounts to seconds for a days work.

More characters on the other hand prevents many potential types of mistakes, such as meaning one statement of target and actually entering another.

I agree, I too think this is all nuts.

Something I tell junior developers: There is one way to correctly spell things out a word in full, but many different ways of abbreviating it. Don't make me guess or memorise which one you chose, completely arbitrarily.

UNIX and languages "born from it" are especially prone to a ludicrous level of abbreviation because of its starts in the earliest days of computing when serious machines had mere kilobytes of memory, and so every byte was precious. Compounding that were the use of teletypewriters, which did not generally allow edits and were glacially slow. Tab complete was impossible.

This has become so ingrained in the early generation of computing science pioneers that they passed on these behaviours almost like religious doctrine, like dogma or rituals that must be preserved. Perhaps it was mostly subconsciously done, but I have seen programmers in the 90s and early 2000s still instructing others to do these things, to shave bits and bytes off identifiers to 'save space'.

What i dont understand is why does everything have to be so brief

Computers used to have very little memory and processing power, and screens had very low pixel density so line width was not that big. Then you have to deal with the baggage 50 years later.

Modern Lisps have the luxury so they use head/tail or first/rest.

Names need to express not only differences, but also similarity.

Because if mutable is a sub type of immutable, it wouldnt be right to give a mutable value when the receiver expected immutable values. The same is also true if one reverses the relationship, the mutable operations should not be defined on the immutable, and if they were that would be dumb because the immutable implementations should fail, which is silly.

An immutable object is a special kind of mutated object, which when mutated does what exactly?

No? "Immutable" means "not mutable", so mutability and immutability are mutually exclusive.