Denying Objective Evidence

Bob: a brick and mortar house is objectively better than a house made with straw and snot.

Clever Troll: no, straw houses are just as good, because you may want to tear down the house quickly if you have to move to a new location - brick houses take longer to tear down so ItDepends on the situation.

Bob: well objective evidence is available that proves brick houses are stronger and withstand tornados better than straw houses bonded together with nose snot.

Clever Troll: but if a person wants to quickly tear down the house and move to a new location, the straw house is better.

Bob: true! And you are not denying objective evidence, you're just providing different objective evidence for a different speciality! Objectively, indeed, if you wanted to constantly relocate your house, it would be best to not use brick and mortar. However, instead of using straw and snot, we could use some kind of Lego snap together house that could be put together quickly, or use a camping tent can be put up quickly. But what you have just proven is not that objective evidence doesn't exist! On the contrary, you've proven that objective evidence does exist. There is evidence that bricks are better for a structured strong home, but there is also evidence that bricks are harder to tear apart if you want to take down the home. That doesn't prove objective evidence is not there.

Net Evidence

The above is misleading (I assume it's talking about my debate style). When I talk about "objective evidence" for a given tool, I'm generally talking about what I call "macro evidence" (related to MacroAndMicroRigor). Meaning there is evidence that a tool is overall better. Most everyone agrees that every tool likely has spots where it can shine ("micro evidence"). But that alone doesn't answer the actual question of "which tool is better to use"? Micro-evidence is not good enough for that purpose. -t

Note that macro- versus micro-evidence is "working terminology". There may be better terms to describe such. If you find them, I will use the "proper" ones. I don't want to be accused of "making up terms" again. -t

In the above example, we'd need to know more about intended use patterns to answer the macro question. It's basically an economic-style exercise: weighing time, money, safety, etc. against each other to find the best combo to fit need (internal) or make the customer happy (external) in a way that makes us the most profit. Obviously if the customer wishes to move their house a lot, then lighter materials may be the way to go. -t

Likewise, unstructured programming with GoTo's may be the way to go in very rare cases. The linux kernel uses GoTo in some places to jump to the end of a procedure, similar to how a return, break, or exit statement ends the section you are in. There are articles that have been written showing where GoTo's are useful (Structured Programming with GoTo's by Knuth). There is objective evidence that massive (macro) use of GoTos leads to unstructured unmaintainable programs. In rare micro cases you need unstructure (lack of structure) - but structure is objectively better at the macro level. You think that it boils down to psychology, because you think there is no such thing as objective evidence when it comes to programming. Scientific lab tests could be done proving that GoTo programs are harder to maintain, providing loads of empirical evidence. There may have been lab tests done on this; but if there haven't been any done, it's because it would be a waste of time - we already know that macro use of GoTo's are obviously objectively worse than structured programming, so we need not beat a dead horse and do millions of lab experiments proving it (which costs money). Your problem is you want to beat the dead horse - you want to defend things like GoTo until there is more and more evidence against them! Mmaybe psychologically someone prefers goto all over his code, even though there can be and is objective evidence discouraging that practice.

Why are we talking about goto's in this topic? Why not stick to the house example? You jump around too much. Cut down on the caffeine.

Anyhow, my reply moved to DecentStudyOfGotoProductivity.