For my toy example I don't think it is because it's generally easy (in the languages I work in) to overload arithmetic operators on types that are basically constrained scalars so there's no explicit wrapping/unwrapping to do when you want to operate on them as if they were plain scalars.
Maybe you could give me an example of the kind of pathological situation you're alluding to?
Have you never worked in a dynamically typed language?
what cost? aesthetics?
But then somebody else needs to look at this code in the future, and they're scratching their head as to what these names represent. Or somebody didn't really put enough thought into what the variables are, or gave them a name that only half represents what they actually mean.
I basically threw away all care for how long a variable name is long ago and have never had a problem. I just name it with enough words it needs to describe what it represents and don't fuss with making it smaller. With a decent IDE you don't even have to remember the whole name for things half the time, only parts of it.
Personally I'm thinking more along the lines of
Succinct ->KEY
Verbose -> MAIL_SERVICE_API_KEY
They absolutely do have a cost. The question is whether the benefit they bring in implicit documentation is worth their cost.
> Even beyond the DX of readable names, it also acts like a type-checker. By reading the code, you can verify at least the semantics make sense.
I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name.