Bravo to Ms Thomson for championing this kind of thinking. I also like her choice of languages -- m4!
Still I wish the write-up spelled out her thinking more. I think her two examples are supposed to be positive here-is-how-you do it cases. But then she immeditaely says they could be better, and even points out a serious problem with the second example.
The biggest thing though is culture and process: it's great to have style for leaving comments to your co-workers about restrictions and guarantees. But in the wrong work environment, those comments will be ignored. What I want to know is how to build the right environment.
I think her two examples are supposed to be positive here-is-how-you do it cases. But then she immeditaely says they could be better, and even points out a serious problem with the second example.
I did it that way to help get people into the habit of immediately looking at their code after they write it and see if there is anything that can be improved :)
All of my co-workers are good programmers. But some are good programmers who care about invariants and others are good programmers who will trample invariants to get this week's feature done.
I think it is really a matter of process. E.g. code reviews. But I don't yet know how to strike the balance between rigour and efficiency.
This is what objects were supposed to be for. When you have some consistency requirement between some variables, you make them private to an object and only export methods which maintain that consistency requirement.
Otherwise, nothing has been lost: naïve approach to objects seems to work well for managing memory and garbage collection, otherwise it's just a bothering implementation detail of a language runtime, that does not help a programmer much and is itself a liability.
Objects do dynamic checks at runtime, whereas types are known (and verified) before a program is executed.
That is a good idea as far as it goes, but it does not go far enough. Soon enough you will find a consistency requirement that does not fit into any structure that works for other consistency requirements (other than the degenerate God object antipattern, which defeats the purpose) - and consistency is only the first step to being correct, anyway.
Still I wish the write-up spelled out her thinking more. I think her two examples are supposed to be positive here-is-how-you do it cases. But then she immeditaely says they could be better, and even points out a serious problem with the second example.
The biggest thing though is culture and process: it's great to have style for leaving comments to your co-workers about restrictions and guarantees. But in the wrong work environment, those comments will be ignored. What I want to know is how to build the right environment.