I think you aren't buying very good math books then. I find the exact opposite: the thing about math books I have read is that they overemphasize rigor at the expense of intuition. Everything is painstakingly illustrated in such great detail that I sometimes see the trees and lose sight of the forest. I feel as if reading proofs and doing problem sets in math books is just manipulating symbols in well-known ways without really understanding intuitively why something must be true. For example my introduction to metric spaces started by defining the characteristics of a certain function d without explaining how this could be thought of as a generalization of distance.
On the other hand, many programming stuff is ruefully hand-waving and lacks rigor. They might present important algorithms in pseudocode; even when they present in real code, the precise semantics of the real code is often underspecified and vaguely described in English. I mean take a language; how often do you see in the language specification the semantics of the language defined rigorously, using operational or denotational semantics? PL nitpicking aside, how many programmers think a piece of code must be correct because they pass a few test cases, without ever giving a proof?
I'm of course not saying the lack of rigor in programming is bad. Perhaps 95% of the software we are building isn't mission-critical and relying on intuitions is fine; we ain't got no time to prove every piece of code we write. But my point is your observation really does not match mine.
> I feel as if reading proofs and doing problem sets in math books is just manipulating symbols in well-known ways without really understanding intuitively why something must be true.
I have a few thoughts about this. The first is that it is largely up to the learner. Sure, you can just symbolically manipulate things with no real understanding, but no one says you have to stop there (and arguably that's what you should be working on when you read the proof).
The second is that a lot of times the intuition comes later. There was a joke in my school (and I presume others) that you learn algebra in calculus, calculus in DEs, etc. It takes a while to develop that intuition and sometimes just doing it frequently is part of what it takes. I think of it like learning music theory but not really getting it until you've gotten proficient at an instrument.
The third is that some math is just like that. There might be someone somewhere who has some type of intuitive understanding of it, but they are an outlier.
That said, the best learning I've done in mathematics is to take a book without answers in the back and work through it with other people. It's difficult, but very rewarding to really grok the topic and be confident in your answer; and having people you have to explain your solution to helps tremendously.
But at least all imperative procedural steps are clearly understandable from source code given in many programming books. Where as maths books routinely leave out many steps in proofs and calculations, on top of many ambiguously used notations and terminology that can leave a self-student confused.
A program proves nothing at all so I am not sure what you can understand from it? Typically in programming you are presented with a piece of code, a statement that this piece of code solves a specific problem and then a proof of that it actually works. Those proofs are typically far from understandable or rigorous.
> Typically in programming you are presented with a piece of code, a statement that this piece of code solves a specific problem and then a proof of that it actually works.
Not really. It's quite unusual to see a serious formal approach.
I'm working through a book that uses C++. Every few pages I find undefined behaviour (struct punning, illegal use of memset to zero-out objects, etc) and needless usage of non-standard compiler-specific language features.
This is the well it works on my machine mindset used widely in programming, even in books written by highly qualified people.
> Those proofs are typically far from understandable or rigorous.
I'm not sure what kind of thing you're thinking of here. Can you give an example?
At least in the light of the Curry–Howard correspondence. :)
Anyways, I do agree that in programming it’s easier to see what are introductions, assumptions, definitions, functions, values etc. You can’t just invent a notation and go with it. Everything needs to be defined from the ground up. It’s constructive and I like that, probably because I’m a programmer.
>I think you aren't buying very good math books then.
Just to follow up. A comment[0] on the book `Discrete Mathematics and Its Applications by Kenneth H. Rosen`
`I'm convinced that math gurus are incapable of teaching math.
Whenever I encounter math textbooks like this one, I'm reminded of Underpants Gnomes on South Park. For the unwashed: Underpants Gnomes stole underwear from the residents of South Park hoping that they'd profit from the thefts, but although their business plan included a Phase 1 ("Steal underwear") and a Phase 3 ("Make a profit"), Phase 2—the connective tissue—was just "?".
Rosen and others like him fail to grasp how much "?" connective tissue they're leaving out when they "teach" math. He'll describe a math concept using almost-but-not-quite human language, then—oh, there's always a "then" with these books—the math gymnastics begin. Math teachers can't resist the gymnastics, can they? No, they really can't. At some point they lose their ability to see how much they assume other people know, and when that happens they cease being effective at teaching. This describes almost every math teacher I've had, and it definitely describes almost every math textbook that I've read. Rosen's book isn't the worst math textbook that I've read, but it's still pretty awful.
Seriously, corner cases and extreme mind-bending problems don't help people learn math; giving students time to grasp concepts before baffling them with bullshit does. This is why math schools like Khan Academy are amazing and college/university level math courses are not. This stuff can be taught, but not like this.`
I strongly agree with this argument. I had this book in my undergrad and I felt barely learning anything and just kept getting drowned in the way the content was written. I switched to a different text in a few weeks and it became an easy subject. The difference was more intuitive examples and gradual difficulty in exercises and less of the proof is left for the reader as an exercise.
>the thing about math books I have read is that they overemphasize rigor at the expense of intuition
I think these are not contradictory notions! Bad maths books lack rigour. Many books are like you say: rigorous but difficult to make sense of. But truly great books both explain the concepts in the simplest, most lucid and succinct way possible AND maintain the rigour necessary to do mathematics.
I like this quote from Michael Spivak: "In addition to developing the students’ intuition [...], it is surely equally important to persuade them that precision and rigor are neither deterrents to intuition, nor ends in themselves, but the natural medium in which to formulate and think about mathematical questions."
I couldn't agree more. Rigour is not a "masturbatory" end in itself to feel very smart, but it is not also an obstacle to understanding.
Agree, additionally I've found that the key to thw very best books is explaining how the intuition and rigour link. I have found that many books (and teachers) exaplin both seperately, but fail to adequately connect the two.
On the other hand, many programming stuff is ruefully hand-waving and lacks rigor. They might present important algorithms in pseudocode; even when they present in real code, the precise semantics of the real code is often underspecified and vaguely described in English. I mean take a language; how often do you see in the language specification the semantics of the language defined rigorously, using operational or denotational semantics? PL nitpicking aside, how many programmers think a piece of code must be correct because they pass a few test cases, without ever giving a proof?
I'm of course not saying the lack of rigor in programming is bad. Perhaps 95% of the software we are building isn't mission-critical and relying on intuitions is fine; we ain't got no time to prove every piece of code we write. But my point is your observation really does not match mine.