Another problem is highlighted by Joe Armstrong and Rich Hickey, which is that as soon as you move beyond the confines of a single program and start dealing with a system of programs, type guarantees become less relaible. So you have these types that may make complete sense in your program's world, but they drift out of sync as the larger system evolves. This is a general problem with any sort of proof mechanism. I still like types and think they can be useful, but they are only a single tool in designing a robust system. They have limitations and drawbacks like everything else.
types that may make complete sense in your program's world, but they drift out of sync as the larger system evolves.
At the risk of being inflammatory, I would say that you've been looking at poorly designed systems.
A running joke about Google engineers is that all they do is shuffle data from one ProtoBuf to another. It's largely true. The upshot of that is that every single service/system has common, typed definitions of the data structures they use and require. Data never drifts out of sync.
To be sure, a lot of the problems I dealt with there were around data structure migration on large systems — but there was never any uncertainty about the structure of the data itself.
I like JSON APIs, but I think JSON especially contributes to people getting hand-wavy and casual about the structure of data across systems in stupid ways (see NoSQL vs SQL).
I don't think that's inflammatory at all. I tend to agree with you that a very good engineering organization would enforce data-first design and maintenance practices and build types around that. But unfortunately a lot of places don't operate that way and so my comment was meant in more of a general sense, not in a "types cannot possibly be useful at a systems level" way.
Comments
Another problem is highlighted by Joe Armstrong and Rich Hickey, which is that as soon as you move beyond the confines of a single program and start dealing with a system of programs, type guarantees become less relaible. So you have these types that may make complete sense in your program's world, but they drift out of sync as the larger system evolves. This is a general problem with any sort of proof mechanism. I still like types and think they can be useful, but they are only a single tool in designing a robust system. They have limitations and drawbacks like everything else.
At the risk of being inflammatory, I would say that you've been looking at poorly designed systems.
A running joke about Google engineers is that all they do is shuffle data from one ProtoBuf to another. It's largely true. The upshot of that is that every single service/system has common, typed definitions of the data structures they use and require. Data never drifts out of sync.
To be sure, a lot of the problems I dealt with there were around data structure migration on large systems — but there was never any uncertainty about the structure of the data itself.
I like JSON APIs, but I think JSON especially contributes to people getting hand-wavy and casual about the structure of data across systems in stupid ways (see NoSQL vs SQL).
I don't think that's inflammatory at all. I tend to agree with you that a very good engineering organization would enforce data-first design and maintenance practices and build types around that. But unfortunately a lot of places don't operate that way and so my comment was meant in more of a general sense, not in a "types cannot possibly be useful at a systems level" way.
A robust system is typed. A robust ecosystem is typed. Everything else is evaluated and dependent upon some agency.