The Mathematician (1947)
www-history.mcs.st-and.ac.uk
The Mathematician (1947)
1–9 of 9 posts
Re: The Mathematician (1947)
#2Re: The Mathematician (1947)
#3An excerpt from that final paragraph:
But there is a grave danger that the subject will develop along the line of least resistance, that the stream, so far from its source, will separate into a multitude of insignificant branches, and that the discipline will become a disorganized mass of details and complexities. In other words, at a great distance from its empirical source, or after much "abstract" inbreeding, a mathematical subject is in danger of degeneration. At the inception the style is usually classical; when it shows signs of becoming baroque, then the danger signal is up. It would be easy to give examples, to trace specific evolutions into the baroque and the very high baroque, but this, again, would be too technical.
Seems very much along the lines of software projects: we lay down some framework that we work in which appears simple, elegant and well-suited to the conception of the product we're building. Then, as time goes one, it becomes complex as we 'patch' the imperfections of the initial system—then we refactor: a sort of paradigm shift occurs and we're working with new basic terms, hopefully restoring elegance to the system.
Re: The Mathematician (1947)
#4Those interested in von Neumann as a person may be interested in this 1966 film about him, at https://www.youtube.com/watch?v=VTS9O0CoVng .
Re: The Mathematician (1947)
#5Re: The Mathematician (1947)
#6Von Neumann is not exactly making the same point, but he is arguing against the sense that math is a kind of purely abstract discovery that has escaped from the messiness of day-to-day reality.
One could ask: will we ever get to a point when all mathematical proofs are rigorously checked, so that we know they're correct? I hope we do get to a point when program-checked proofs are standard, but even then there's the possibility that a proof-checker itself is buggy. So, philosophically, it seems we may never justifiably feel certain beyond all doubt that any given proof is correct.
But we can have greater confidence in a proof verified by both expert humans and by a trusted program than in a proof simply reviewed by humans. So the effort is meaningful and worthwhile - all in the context of seeing math as a field as fallible as any other.
Re: The Mathematician (1947)
#7Many mathematicians seem to have an attitude that a well peer-reviewed proof is simply correct and etched in stone for good. This seems to me like publishing programs - some of them thousands of lines long - and expecting them to be essentially bug-free without ever running them. Von Neumann is not exactly making the same point, but he is arguing against the sense that math is a kind of purely abstract discovery that…
[1] http://www.gwern.net/The%20Existential%20Risk%20of%20Mathema...
Re: The Mathematician (1947)
#8Many mathematicians seem to have an attitude that a well peer-reviewed proof is simply correct and etched in stone for good. This seems to me like publishing programs - some of them thousands of lines long - and expecting them to be essentially bug-free without ever running them. Von Neumann is not exactly making the same point, but he is arguing against the sense that math is a kind of purely abstract discovery that…
I think that the important distinction is 'peer-reviewed'. A random programme published, even by a very good programmer, is indeed likely to have errors; but I think that one can have more confidence in a peer-reviewed programme (which is essentially why we trust open source over closed source, after all).
Of course there are distinctions: software is automatically tested when used, whereas mathematics is not automatically tested when read, so that one might reasonably have more confidence in software purely on the basis of its longevity than one does in mathematics; but, on the other hand, although individual pieces of reasoning can be extremely arcane, 'flow control' in mathematical reasoning tends to be much more elementary than in software, so that one is unlikely to uncover the mathematical analogue of an infrequently visited branch in a code path going untested despite heavy use of the software.