How to Think Real Good (2013) 131 points by michael_fine 3 months ago | hide | past | web | favorite | 6 comments

 Interesting read that loops full circle to classic AI debates.I was frustrated a bit by the dismissal of probability theory, though, as if Bayes theory solved it, and by extension, and probability as a whole could be dismissed.A lot of the issues the author raises are limitations with Bayesian (at least classical Bayesian) theory. The author's critisms dovetail with some areas of probability theory (cf Jaynesian or algorithmic probability literature); I suspect their concerns are one in the same at some level as some of the concerns discussed there.The problem is uncertainty to various degrees is fundamental to reasoning, so probability must be involved at some level. An integrated approach is needed. I agree that Bayesian theory per se isnt the end of the story, but something involving probability will be part of it (and because Bayesianism is a big part of that, probably that too).
 > but something involving probability will be part of itquantum mechanics without the physics?
 > "Even though it was discovered by physicists, it's not a physical theory in the same sense as electromagnetism or general relativity. <...> Quantum mechanics is what you would inevitably come up with if you started from probability theory, and then said, let's try to generalize it so that the numbers we used to call "probabilities" can be negative numbers."
 > Work through several specific examples before trying to solve the general case. Looking at specific real-world details often gives an intuitive sense for what the relevant distinctions are.This describes well why I like the more functional approach to programming (whether within an OO framework or otherwise). I often find myself solving a problem a number of times before I abstract it. And usually creating said abstraction before the problem appears leads to over-engineering.When writing 'functional' code, I come up with solutions that are isolated enough that I can later replace them with various more abstract solutions, whereas the more OO or procedural approach can leave me with a mess that is too much work to disentangle.
 I'm the same. One of my work projects is a fairly large code base and we add new features to it regularly. When I'm adding a new feature I generally prototype it all in one file (or at least as few as possible).Once I have something working, I try to simplify it, then I look at the relationships within the code and as it interfaces with other code. The abstraction usually becomes quite obvious at that point. This approach of starting "dirty" usually results in very clean code at the end of refactoring. If I try to start clean, it is usually far dirtier and I end up changing much of the architecture anyway. So, it seems more efficient to start without any architecture and then tailor fit at the end.I guess it's like writing text, it's best start with a rough draft to get the ideas down, then you can organize it once you've got a working version.
 In terms of academic philosophy, I would say he is doing a version of pragmatism.

Search: