Jebdm

It's frustrating that you see me as complaining, because my original goals were to (constructively!) get people to 1) remember to check the evidence for a claim before accepting it and 2) remember to either present evidence for your claims or label them as hypotheses. Pointing these things out is definitely helpful because humans have a whole bunch of biases that make us fail to notice a lack of justification and believe things before they are justified. I've been saved from making this mistake a number of times by "[citation needed]".

(Perhaps "[citation needed]" came across as snarky? Next time I'll write "What's your evidence?".)

The rest of my posts weren't complaining, either; mainly, I was arguing for the importance of getting people to do 1 and 2 above, and against the notion that it wouldn't be better for opinions (of the "claims you believe to be true" variety, not preferences) to be either supported or marked as hypotheses when they are expressed (at least in this sort of context).

I was definitely not dissenting; my criticism would be exactly the same even if I agreed with the expressed claims 100%.

At the risk of repeating myself: the "opinion" he is expressing is actually a theory of procrastination. When you make broad statements like "the reason why human-beings procrastinate is to feel in control of their life", you are declaring your belief about why a widespread phenomena occurs of the type which is either right or wrong (or partially right).

Making such statements without providing any evidence for them is not only intellectually vacuous (since if there is no need to provide evidence, then any claim can be made), but it leads to bias in others where people assume that because an argument was not made, that the information is "well known" or the person providing the information is an expert.

There's nothing wrong with sharing opinion. I'm guessing that the reason he came to the conclusions he did was based on personal experience (probably mixed with some reading); if so, then he shouldn't have said "the reasons why human-beings procrastinate is to feel in control of their life", he should've said "I noticed that I seem[ed] to procrastinate not because of (...), but because I didn't feel in control of my life". If his evidence wasn't introspective, then he should have shared whatever his evidence was. If he didn't have any evidence other than plausibility, then he should've framed what he was saying as a hypothesis (and ideally still explained his reasoning).

You don't have to back up everything you say with scientific evidence, but you shouldn't make sweeping claims, especially in fields like this one where the jury is still out, without either providing evidence or qualifying your claim. (And I don't buy the "it's too much extra writing" argument; he could've inserted "I have a hypothesis:" after "Dear procrastinator" and had it completely covered.)

And no, I'm not just being nitpicky; a number of well-known biases like the primacy effect, confirmation bias, the "trusting the confident statement" bias I mentioned earlier (which I can't remember the name of for the life of me), and wishful thinking (in this case, wishing for a solution to procrastination) mean that humans are very vulnerable to forming irrational beliefs when ideas are presented in this way. An ounce of prevention, in the form of stating the reason you believe what you believe at least when you're making new or potentially controversial claims, is surely not too much to ask given how easy it is and how far it goes.

I don't take claims without evidence as a rule, and he didn't present any evidence. His case is especially problematic because he is making strong claims about a fairly well-studied field in which there is not a clearly dominant theory.

If he's not intending to present what he's saying as fact, he should say so.

[citation needed]

Also, I frequently find the information I'm looking for in the blurb from the website and so don't bother to click through. (Or I view the cached version.)

Don't worry about the name--I think it's a sufficiently general pattern that it makes sense to use it in multiple contexts, and I don't think it trademarked or anything (like "For Dummies" is).

A little bit of explanation about formalisms and the communication problems you mention from a computer scientist/linguist who gets that same look of satisfaction:

In natural languages, the relationships between utterances and what they convey are somewhat fuzzy. Words like "tree" and "run" don't have single precise meanings; they have a variety of senses associated with them, and these senses vary in how closely they are related to each other. Biological trees made of cells are quite closely related to computer science trees by their shared shape; the relation between running with your legs and running for office is a bit fuzzier, via the race metaphor; the relation between a river bank and a financial bank is even more unclear.

Meaning in natural language is built in aggregate from associations, with the senses of expressions converging over time in groups of communicating speakers. Natural languages do not clearly define the relationships between different expressions, nor between expressions and the real world. Because natural languages are unspecified and evolving, you can only measure how often (in your observation) different expressions and relationships between expression reflect different situations.

Formalisms, like natural langauges, are also used to represent meaning via expressions made of symbols and relationships between them. (Technically, formalisms don't have to represent anything, but in practice they usually do because otherwise they're not very useful.) Unlike natural languages, formal languages have normatively defined specifications. These specifications can be written in a variety of ways, but usually they define rules (which always apply) for deriving expressions from each other.

To be able to use formal languages for real-life problems, you need to have these five skills:

Symbol manipulation: deriving expression in desirable forms from old ones using a specification Interpretation: relating formal expression to the domain Encoding: capturing domain knowledge in the formal language Abstraction: finding consistent patterns in the domain (to be expressed in the formalism) Modeling: expressing relationships in the domain using relationships between symbols

Unfortunately, most people are not very good at these skills. It is hard to break habits like using intuition and relying on others' ability to resolve ambiguity. Furthermore, most people are not very good at dealing with abstractions, especially new ones or higher-level ones. To make things worse, some of the problems involved in using formal systems are genuinely hard, even for computers and mathematicians. Obviously, even the most accomplished mathematicians are not always able to get the results they are looking for, let alone quickly, but people who are good with formalisms usually don't have as many problems with things like checking their intuition or dealing with abstractions.

The problem with communicating formal ideas to people who are not good with formalisms is rather fundamental, because the very attributes which make formalisms useful are the ones that those people have trouble understanding. You can, of course, relate the results of using a formalism, but without using formalisms it is often very hard to usefully express the "why" of the result. The problem is compounded because people who are good with formalisms have a hard time figuring out what is understandable to others, due to the general "knowing it too well to teach it" effect as well as lack of practice (since most people who care about formalisms are good with them).

Some talented communicators are able to explain formal results satisfactorily to others by relating them to familiar abstractions or rephrasing their logic in everyday terms, but unfortunately this frequently results in misunderstanding and misapplication of the results. Furthermore, there are a number of formal results which really can't be properly understood unless you have mastered the skills above (particularly in theoretical computer science and formal logic). The problem is akin to trying to talk to non-programmers about programming, but more general. Programming languages are formal languages, of a sort, but most programmers only understand a few particular formalisms. Theoretical computer science and proof theory involve dealing with a larger and more abstract set of formalisms, including formalisms about formalisms.

If you need examples of the difficulties, just look at all the ways that people try to explain Gödel's incompleteness theorems or monads informally.

Even better, provide a way to use it without a paid Instapaper account.

Even better would be weighting that by testing comprehension. And even better than that would be finding the relation between reading speed and comprehension, letting the user set either and automatically estimating the other.