Hey, isn't that it? Some people can just spend all their time in abstracting thinking land, manipulating formulas without concrete examples providing any context, because they have some amazing super power that many of us (maybe most?) don't have.
Others need context. We need to see concrete examples of the problem, play around with them, explore them, until our brains can "get" a generalization.
And in the end, maybe we all benefit from concrete context? When you are manipulating formulas, do you impose a concrete example in your head to guide that manipulation? Wouldn't it be great to get that out onto the computer somehow?
I see two concerns being conflated here: (0) how to motivate the study of a formal system, and (1) how to actually study the formal system.
To motivate the study of a formal system, that is, to convince someone that the system is useful, obviosuly you need examples and applications. To a non-mathematician like me, that motivation must come from outside mathematics, e.g., how to design and write reliable programs that are easy to understand and maintain.
But, once you have decided that a formal system is useful, you really need to understand it in its own terms. You seem to view formulas as “too abstract”, and in need of “explanation” (not just motivation) in terms of something “more concrete”. I don't see why. By itself, a formula is nothing but a well-formed syntax tree, that is, a data structure just like lists or arrays (though usually with more complex internal invariants). Do you think lists and arrays are in need of “explanation”? The rules for manipulating formulas are themselves also fairly mechanical and concrete, just like the rules for manipulating lists and arrays.
This isn't about motivation. Its not even about study, rather how do you go about doing formal reasoning at all? Prove X has property P, what is even the first step? How do we get to the second step, and so on? Doing a proof is not a mechanical process, there isn't an algorithm for deciding what to do next to reach your goal!
Programming is a great example of this. Those lists and arrays don't appear out of nowhere. Someone has to write the code, how do they write the code? Why use a list to store those elements? Programs are generalized to operate on a wide variety of inputs to create a wide variety of outputs, but when you are writing code, you are thinking about just a few examples of those, you imagine them in your head and they guide the code you write. But perhaps the computer could help there as well.
> This isn't about motivation. Its not even about study, rather how do you go about doing formal reasoning at all? Prove X has property P, what is even the first step? How do we get to the second step, and so on? Doing a proof is not a mechanical process, there isn't an algorithm for deciding what to do next to reach your goal!
Yep, there's no general algorithm for coming up with proofs. Practice, experience and good heuristics help, though. And if they don't, then you redesign the formal system until they do.
> Programming is a great example of this. Those lists and arrays don't appear out of nowhere. Someone has to write the code, how do they write the code?
Same as above. Just replace “proofs” with “programs”, and “formal system” with “programming language”.
> Why use a list to store those elements?
The desired invariants (see below) and complexity bounds for your code will tell you what data structures might be more convenient than others.
> Programs are generalized to operate on a wide variety of inputs to create a wide variety of outputs, but when you are writing code, you are thinking about just a few examples of those, you imagine them in your head and they guide the code you write.
I can't speak for others, but I really don't think that way. When I'm designing an algorithm, or when I'm trying to understand someone else's design, what matters to me first and foremost is its invariants - what the program preserves, even though the process' state is changing. Only if I can't see what the invariants are, then I might use some examples to generate plausible candidates, but the job isn't done until I have found and confirmed the invariants themselves. In other words, I don't conflate “works for these few examples” with “works in general”.
> Practice, experience and good heuristics help, though. And if they don't, then you redesign the formal system until they do.
I'm not sure anyone really understands the cognitive processes behind doing math. But maybe?
> The desired invariants (see below) and complexity bounds for your code will tell you what data structures might be more convenient than others.
I rarely write code where I even need to think about complexity bounds! I'd be surprised if that was a dominating concern for even a significant fraction of programmers (systems HPC programmers, for sure, but...UI programmers?).
> Only if I can't see what the invariants are, then I might use some examples to generate plausible candidates, but the job isn't done until I have found and confirmed the invariants themselves. In other words, I don't conflate “works for these few examples” with “works in general”.
We don't. But you need to start somewhere. Don't underestimate the value of a few good examples in the problem solving process.
> I'm not sure anyone really understands the cognitive processes behind doing math.
As long as we all play by the rules of the symbolic game, I don't really need to understand what's going on inside anyone else's (or even my own) head.
> I rarely write code where I even need to think about complexity bounds! I'd be surprised if that was a dominating concern for even a significant fraction of programmers (systems HPC programmers, for sure, but...UI programmers?).
Invariants still remain, e.g., “the textboxes Red, Green, Blue, Hue, Saturation and Brightness must contain each a number between 0 and 255 inclusive; additionally, these numbers must satisfy the following equations (...)”.
> We don't. But you need to start somewhere. Don't underestimate the value of a few good examples in the problem solving process.
Oh, sure, examples can be a useful tool for finding the general rule, as I mentioned in my previous comment. But they don't replace the general rule.
