I think this points to a seperate issue as well: Often times we have a choice to express the same thing through types or through state. As the influence of functional languages grows, we tend to choose types more often.
It wouldn't be surprising to have a ReadOnlyFile type and a ReadWriteFile type. This can easily be justified because an individual file object doesn't need to change its read/write property after it has been created. But conceptually, files can be written to, just not always.
Another example makes that clearer. Adults can do things that minors can't. So, for instance, a signContract() method would have to go on the Adult type not on the Person type. But people grow older, so at any point in time some objects conceputally change their type from Minor to Adult.
Technically this is not a difficult problem to solve. But it shows the disconnect between our natural language concepts and the ever more type centered way of modelling we use in modern software design.
My point isn't a formal one but rather an observation about software design trends.
More imporantly though, what FP does in both its dynamically and statically typed incarnations is to prefer (and sometimes enforce) immutability.
Immutable objects support a much more type centered view of the world. Theoretically, you could have something like a VehicleAtFullSpeed type (dynamic or static) because the speed attribute of an individual object never changes.
It wouldn't be surprising to have a ReadOnlyFile type and a ReadWriteFile type. This can easily be justified because an individual file object doesn't need to change its read/write property after it has been created. But conceptually, files can be written to, just not always.
Another example makes that clearer. Adults can do things that minors can't. So, for instance, a signContract() method would have to go on the Adult type not on the Person type. But people grow older, so at any point in time some objects conceputally change their type from Minor to Adult.
Technically this is not a difficult problem to solve. But it shows the disconnect between our natural language concepts and the ever more type centered way of modelling we use in modern software design.