Let’s say that you have the following situation:
You have an object that you want to model. Let’s say it’s a cube.
Now, what’s a cube made of? Well, vertices, edges, faces, “content.”
So you go to work and you implement your cube.
Later you find out that you need the geometric information related to the various parts of your cube. You now need to talk about Points, Line Segments, Bounded Planes, etc. Further, you need to be able to do “operations” no the geometric space which means you need heuristic characteristics: Vectors, orientation, “inner vs. outer,” etc.
Later you find out that you need to import data in a standard array-like format (cube described by array of “faces” which are really just arrays of “points” which are just arrays of numbers)
You might need to switch between each of these three domains fairly often. What the hell is the solution? Is there any programming language in which you can do this easily?
It seems like our ability to express how types are related is woefully, woefully, lacking. Now, you could say “make your Vertex a point.” But what type of point? An n-dimensional point? What if I want to write a 3D geometry engine? Then I have to think about how to relate the n-dimensional point class to the 3D point class.
The issue is that when we talk about types in everyday life we use vastly more relations than is-a. For instance, I could say:
“A vertex of a graph is an n-D point when the graph is embedded in n-D space.”
-or-
“A face is a bounded plane except that the orientation of the edges bounding a face matters.”
Computer science can be seen as “implementing math.” Imagine how stilted math would be if we had to perform these tedious conversions all the time. The crux is the following:
Conversions between types is fast and trivial when types are bound to computational contexts.
If I transition from the “graph theory” context to the “geometry” context then conversion between primitive types should be trivial (read: automated). I should be able to indicate which context I’m using.
