3 ms·
I've recently come to appreciate a mathematical approach, which I see as declaring constraints. The power of this (for me) is that you can separate constraints
by 10ren 18y ago
I've recently come to appreciate a mathematical approach, which I see as declaring constraints. The power of this (for me) is that you can separate constraints in any way you like, and combine them however you like. This is important when you need to simplify a problem into parts, in order to be able to understand it one bit at a time (it's still an art to know how to divide up the problem, but maths gives you options).
It's very appealing (and obvious) step to then execute these declared constraints - that is, to code directly in terms of the mathematics.
But here's the problem: the maths doesn't tell you the answer; it just tells you its constraints. The answer you want is somewhere in that space. Of course, it's possible to write a language that will always give you an from within that space. The most well-known way for this issue to show up is in efficiency: the solution given by the language does fall within the constraints, but it takes too long. If we had a way to declare the efficiency as a constraint, this might change... but apparently that's a hard one.
Other constraints are things like: usability, understandability (to coders of average ability, average education and average deadlines), interoperability with standards (which are never ideal, but which exist and which work), portability, modularity and many others that I haven't encountered or imagined.
Partly the difficulty is in specifying a soft, human constraint in formal terms; the other part is solving for that constraint, which appears to require strong AI or bump up against the halting problem - or else we could just declare the constraint: "fastest possible solution".
- anonymousDan 18y agoI've recently started taking the exact same constraint approach. I find it helps to give me a much more concise mental model of the problem I'm trying to solve. I guess this is because of the declarative nature of the constraints, and the fact that aren't trying to keep all the implementation details in your head. Instead you just ensure that whiles you are programming, you respect the constraints at all times. I find it particularly useful when the problem requires maintaining lots of different data structures that interact with each other.
- 10ren 18y agoYes. I actually find it really difficult to stop thinking about the implementation (and the usability) of what I'm creating. These are good things to be concerned about, but not when the problem is already too complex. On another aspect of it: the last couple of days, I've found it very effective to think of a model as just the nouns, not verbs; data structures, not algorithms (as in the Brooks quote). Guess this is implicit in the idea of a constraint, but it's helping. The other thing is that the model doesn't have to be precisely correct. It only needs to be correct in the important ways (if I don't already know what the important aspects are, a complicated model probably won't enlighten me). This gives me conceptual framework to think in, rather than to be an authoritative definitive description, perfectly correct in every minor details (they can be corrected early or late, if they really are minor). I find it helps to give me a vantage point, to see further. My mind is very fertile with finding solutions - provided I can see where I am.