How to Think Real Good (2013)(meaningness.com) |
How to Think Real Good (2013)(meaningness.com) |
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).
quantum mechanics without the physics?
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.
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.