I do think the idea of the “condensor”, as he calls is, is good in princple. I kind of think that GitHub is helping us get closer to that, though, by allowing forks and pull requests, so we can reuse things, instead of having to implement it ourselves.
Maybe there is some interesting way to ust GitHub, or similar things, in order to reduce redundancy? (Perhaps not.)
The important answer to his problem of the size of state space is that it is fractal.
For example, if you look at the typical state space of a program… you have thousands of “String” shaped sub spaces.
So long as you have zero defects in your String methods…. your defects aren’t there.
This is why class invariants are so important.
A class invariant is the shape of the substate space that the class manages.
The class invariant is the set of all states for which your public method operate correctly.
This is why your API matters. If the state space your class manages is fuzzy and leaks and is shared by other classes…. your complexity is hideous.
If your class properly encapsulates it’s state space so there is no way that a client can invoke a method on the class and propagate the object out of the valid region, so there is no way a client and mutate your object into some state where the invariant no longer holds….. then you don’t have to worry about that subspace.
It is “safe”. So all you need to worry about is how you construct large subspaces out of those objects.
This is an odd talk.
I do think the idea of the “condensor”, as he calls is, is good in princple. I kind of think that GitHub is helping us get closer to that, though, by allowing forks and pull requests, so we can reuse things, instead of having to implement it ourselves.
Maybe there is some interesting way to ust GitHub, or similar things, in order to reduce redundancy? (Perhaps not.)
The important answer to his problem of the size of state space is that it is fractal.
For example, if you look at the typical state space of a program… you have thousands of “String” shaped sub spaces.
So long as you have zero defects in your String methods…. your defects aren’t there.
This is why class invariants are so important.
A class invariant is the shape of the substate space that the class manages.
The class invariant is the set of all states for which your public method operate correctly.
This is why your API matters. If the state space your class manages is fuzzy and leaks and is shared by other classes…. your complexity is hideous.
If your class properly encapsulates it’s state space so there is no way that a client can invoke a method on the class and propagate the object out of the valid region, so there is no way a client and mutate your object into some state where the invariant no longer holds….. then you don’t have to worry about that subspace.
It is “safe”. So all you need to worry about is how you construct large subspaces out of those objects.