whether something (a variable) is a width or a height is encoded somewhere in the code because if the variable is a width it makes its usage different than if it is a height.

Then the code is written to make sure you never make the mistake of sending a width to a height, because that would be silly.

The type (width or height) is represented as logic in the code.

theoretically - if you have a type system that allows you to know something is a width or height you can often reduce logic to keep track of these things but my experience is that level of granularity in your typing reduces dynamism too much. I would rather keep track of that in code (as it probably will have to deal with it anyway) than make my type system deal with it.

There's some cool mechanisms in type-forward languages that lead to minimal dynamism loss along with safety: For instance, you can do scientific programming that carries units along. So you really can divide a length by a time with no problems: Your results just happens to be a velocity, and will come out in meters per second (or whichever your favorite units are). Adding meters to kilometers? Congrats, you might you have to say which physical representation you want in float-land. But then you are saved from adding seconds to milliliters, because then the types will tell you it's complete nonsense.

But note that to make all of that work well you really need your language to provide a lot of syntactic sugar features which are missing in most older languages, so all the operations read seamlessly, instead of being full of ceremony. One could do all of this in, say, old Java 1.4 or something, but the amount of type annotation, along with the massive mounts of boilerplate to get all of the operationg working right, and checked at compile time would make it all Not-Worth-It(tm) But with enough language features, and a smart enough compiler, `val acc = mySpeed / someSeconds` will work, straight up, with the safety included.

thanks for saying it a lot better than I did!

Bundling the time and the volume might be better called "forming a vector" or "forming an ordered pair" rather than "addition". You can then perform addition and subtraction with the resulting ordered pairs or vectors.

There's no need for ordering (it's a bag rather than a vector), but yeah.

That's nonsense because addition loses the structure. 3 litres and 6 seconds becomes indistinguishable from 4 litres and 5 seconds. Maybe that's what you want, but it's realistically pretty much never what you want.

That's not how it works. Addition losing structure doesn't mean "strip out everything from the textual description that isn't a number". It just loses some properties, like ordering.

Which means, for example: (3 liters and (i.e. "+") 6 seconds) + (4 liters and 2 oranges) = (7 liters and 6 seconds and 2 oranges). Perfectly sensible addition, which you do all the time. There's no stipulation the output has to be a single number...

Alright you're just talking about a different operation entirely but have decided to give it the name "addition". Not particularly insightful, but thanks anyway.

What? Addition isn't just for numbers. This is literally no different from adding vectors. I'm sure you've seen that in school?

What do you mean subtracting a cat from a dog doesn't make sense? Heh, ackshualllyyy I was imagining a vector of pets, where we have still have a dog but now a cat deficit of one, because the cat died and now we have a big hole in our family... nothing personnel kid. surely you learnt that in school?

The point is, making a vector, that's not addition.

This is quite literally no different than 1i + 2j. Or if you hate vectors like i or j, just complex numbers -- 1 + 2i. I'm not sure why you feel the rudeness is helping you get a point across, because it's very much not.

I am being no ruder than you are, more or less.

> because it's very much not

I don't expect to change the mind of someone who thinks that addition and defining a vector are the same thing. You've just redefined generally common terms and then started accusing people of being uneducated for not sharing your own eccentric definitions. Poor show.

No, you're grossly misrepresenting what I said. I never accused you of being poorly educated; in fact quite the opposite. I was ~100% sure you had seen vectors and complex numbers before and I was telling you this is exactly like what you have already seen. That's not an accusation of poor education, that's literally the opposite: pointing out that you're well educated enough to have seen that before.

I didn't intend that to be rude, I was pointing out this is something everyone learns in a standard curriculum i.e. that this is very much the opposite of esoteric. But you seemed determined to reply rudely, so I'll stop here.

That just means it exists in your head.

Not really. Whether an integer represents a width or a height won't even exist in your head if you're implementing a function like max(a, b).

> exist in your head if you're implementing a function like max(a, b)

surely, you have an idea of what you're using that function for, while you're writing it.

The compiler is doing a check to see if the function makes some minimal logical sense (ala, a typecheck), but it cannot read your mind. But this implies the types are actually an actualization of the thoughts in your head, in a formal manner.

Because inside the abstraction max it doesn't represent a width or height, they are just numbers (or just some "comparable things"). But outside the abstraction, at some level, you'll definitely know what a and b are.

The type is encoded in the name of the function.

Is a pretty bad system because you say "won't even exist in your head" but I dont even know if I should pass it integers, floats a srtring. Or what it will return.

At the extreme end, and with no claims of scalability, you have shell: everything is a string.

I'm skeptical that sophisticated type systems need to exist.

Perhaps I should dust off my copy and start reading SICP