> (firstname, lastname) and (x,y,z) are homogeneous collections.
Disagree. In a language with a decent type system you would give them different types, because using a first name as a last name or an x as a z is always an error.
Another rule of thumb is that a lot of the time you can make code that uses tuples clearer by rewriting it to use namedtuple-defined struct values. If the language supported it, it'd probably also make sense most of the time to define a type for each tuple field, and have a type-checker look for errors.
Occasionally you see tuples used where they want immutable and hashable lists, but most of the time they're used as shorthand struct/"pod" tours types.
Interesting. I should probably try one of these typed languages. When I was thinking of types I was thinking about "physical" types like in C, not abstract types.
Yeah, it's pretty common to think of types as "representational", and that really doesn't get at most of what they are good for.
Even in C you can get some good help from the type checker if you know how to use it. For instance, see https://dlthomas.github.io/using-c-types-talk/slides/slides.... for a technique that can turn a flakey segfault from misuse of an API into a compile time error (later slides do just that for a simple SDL program, with a modified header file).
Even in C, we could use abstract types more; we could use wrapper structs more, to introduce abstraction where we often idiomatically do not.
(Again about Rust and C++ equally, if we'd only care about "physical" type, the string and the vector would be the same type. The distinct string type allows us to form the rules around exactly what kind of values we allow for or optimize for using that type.)
Disagree. In a language with a decent type system you would give them different types, because using a first name as a last name or an x as a z is always an error.