
How to Think Real Good (2013) - michael_fine
https://meaningness.com/metablog/how-to-think
======
gyuserbti
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).

~~~
naringas
> but something involving probability will be part of it

quantum mechanics without the physics?

~~~
iwintermute
> "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."

[https://www.scottaaronson.com/democritus/lec9.html](https://www.scottaaronson.com/democritus/lec9.html)

------
mercer
> 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.

~~~
bonestamp2
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.

------
woodandsteel
In terms of academic philosophy, I would say he is doing a version of
pragmatism.

