Top On Why Top Is Hated
Top On Why Top Is HatedAs one can see from ObjectiveEvidenceAgainstTopDiscussion, ShouldTopBeBanned, IsTopTheNewRichardKulisz, and TopNoiseFilter, my writing ticks off at least a certain group of WikiZens. (Not sure of the number or percent of angry people because most of my detractors don't sign, oddly...and suspiciously.)
I don't like to be "hated", but I also feel compelled to dissect and criticize the logic of claims that "X is clearly better than Y" or "X is the canonical model/definition/design-rule". It's usually strongly stated opinions I defend against, not just any opinion. I hold strong-opinion-holders to their claims, and this agitates them.
For example, if somebody simply says, "Tool X works well for me in my experience", I won't object to that, other than stating it differs from my personal experience. No problems there. However, if they say "X is clearly better than Y to the well informed", then I will ask for concrete and detailed evidence, whether it makes that person uncomfortable or not.
Sometimes this generates friction, and I do fight back at times with counter personal accusations. But my return fire is not significantly more intense than the starter of the personal accusation. I believe I have a right to counter rudeness with rudeness. If such personal skirmishes are what really bothers you about my content, then perhaps we can work out a way to move such scuffles to another side topic, with a link, to keep the main topic cleaner.
But complaints about rudeness are probably just detractors using "rudeness" as an excuse to silence me. I highly suspect they just finding "social" ways to protect their SacredCow tool or theory by exaggerating the "rudeness issue".
If it was JUST rudeness, there are solutions. I doubt that's the case, it's just broken taillight syndrome in play. (Broken taillight syndrome is where cops invent reasons to stop and search your car if they have no real reason. It's sometimes brought up in "profiling" law enforcement controversies.)
Kill me with real logic, not bullshit accusations.
Some also argue I should be banned/deleted/silenced simply because I "generate friction", without directly assigning blame. Whether that alone is a sufficient reason depends on what you feel the purpose of this wiki is. If you feel its suppose to be like an encyclopedia of "official" or "sanctioned" knowledge about IT, then kicking out a friction-generator makes sense. If on the other hand you view it as a place to hash out the difficult questions of IT, then friction-generation alone should not be a reason to boot people or content. It comes with the territory: the cutting edge does leave razor burns.
Again, if you wish to help manage the rudeness alone, there are ways. But examining ObjectiveEvidenceAgainstTopDiscussion in greater, it look like a backlash against criticism of SacredCow notions. I invite the reader to take a careful look with an open mind.
--top (TopMind)
Top, you're a highly illogical person with ridiculous delusions of being logical. You fail to recognize evidence and logic when it is presented to you. Instead, you hold logic and evidence and even objectivity itself to your own illogical standard, which you stupidly call 'real logic'. You're immune to true logic because you can't recognize or follow it, and you're hostile to learning anything. You're an ass, a troll, a thick-headed willful ignoramus, and a blind hypocrite. You DEVALUE every page on WikiWiki you touch - really, WikiWiki is simply not a suitable forum for arguments. I believe WikiWiki would be better off if we simply deleted every page in which you were a significant participant, even if it meant deleting other people's words - even mine. Many people have left WikiWiki because they get fed up with your incessant noise and bullshit. We don't sign because, honestly, we'd be embarrassed to have our names associated with yours. You don't even work to implement your eponymous ideas of TableOrientedProgramming; you'd rather spend your time here whining about how people are rude to you, or attempting to justify your poisonous LieOrStreet morality. Your reactions are predictable, and half the people who engage you do so for their own amusement, because they certainly aren't seeking an intellectual discussion (unless they're either new and naively sympathetic, or just as masochistic and moronic as you). GTFO.
You admitted you are too lazy to present ItemizedClearLogic. Present it right, and I will recognize good logic. Be obtuse and round-about and indirect like a lazy college professor on weed, and indeed I won't recognize "logic". I'll take a wrong asshole over a piss poor lazy writer any day. You just mistake your internal preferences for clear and universal truths without realizing they are only in your head instead of wired into the objective logic of the universe. See below as far as LieOrStreet. I don't see what implementing TOP has to do with anything here. RedHerring.
[Where has anyone admitted such? I (not him) have recently told you that it's just extra work. There's nothing to be gained by using ItemizedClearLogic. I believe you know this too, otherwise you would be using it.]
I'll give you one more. I don't like the thread messes that pages top edits heavily descend to. --AnonymousDonor
It takes two to tango. Why pick on just me? Because I use a handle? That kind of approach will just encourage no handles. I don't like thread-messes either, but haven't found a workable alternative other than avoid controversy, which goes against one of the purposes of this wiki. DontComplainWithoutAlternatives: show debates "done right" for similar topics so we have a good example to learn from. Often it appears there are communication impasses such that it's not easy to the organize info well. How do you classify debate parts (to organize them) when neither side agrees on the classifications assigned by the other? I haven't figured out how to solve this. My past attempts at summaries failed for this very reason (among others). I plead "stumped" on this issue and would like constructive help. Vague complaints are not helpful. --top
On WetWare -- External Logic & Math Versus Human Mind
I do believe software engineering is mostly about WetWare, and the human mind is currently a gray science. "Logic" in the strict sense is not always TheRightToolForTheJob when dealing with WetWare, unfortunately. Tuning software for a better WetWare fit (grokkability) is more akin to pattern analysis and perhaps statistics and probability rather than "traditional" logic and math. Many want software engineering to be about rigorous and definitive science and math so much so that they inject false rigor into the discipline, using ArgumentByElegance or false canons instead. (See DisciplineEnvy. Also, there are very few decent formal studies on WetWare and software such that speculation and anecdotes are often our only usable evidence. This lack of studies can be frustrating, but it's the way it is at this time.)
Based on their patterns of replies, I suspect my biggest detractors' egos are trying to defend all that time and effort they've spent in the "computer science" academic setting, which unfortunately downplays WetWare and has got itself into a "science bind" because of that mistake. They get pissed when I sprinkle the ugly messy WetWare and economic reality on their claims, and they lash out at me. I'm just the messenger. Kick the messenger all you want, but the Great WetWare Gap won't go away. It's not my fault some of you wasted so much time holed up in your ivory tower, focusing on the wrong factors and getting lost in irrelevant reality-detached minutia, thinking it mattered. --top
{I don't disagree that there is a human aspect to SoftwareEngineering. However, your detractors have no problem with you bringing "economic reality" and "ugly messy WetWare" into debates. What your detractors have a problem with is that (a) your claims of "economic reality" and "ugly messy WetWare" are typically unsupported by evidence; (b) you generally deprecate, ignore, or are openly scornful of any academic or theoretical argument and only acquire the most superficial knowledge of subjects you criticise deeply; and (c) your assertions frequently defy established practice or knowledge. A typical debate with you demonstrates all three, but the last item particularly puts the burden of proof on you. Instead, you either demand that we defend established practice or knowledge and treat your claims are self-evident, or you demand that we give your claims equal footing with established practice or knowledge. Given your usual approaches, neither will ever happen.}
{As one of your detractors, I have over thirty years experience of in-the-trenches software development working with typical developers and typical clients and I have over twenty years experience working in and/or with academia. I've seen both sides, and I know there are academics who live in a distant ivory tower divorced from reality. I also know there are practitioners who see naught but their own small world through a cloudy magnifying lens and believe it encompass everything. Of course, these are polar extremes; both are equally deluded, and allowing either pole to dominate results in poor-quality software. Ideally, both views should be considered equally, allowing theoretical purity to underpin practical applicability. That results in the most flexible, learn-able, and robust software.}
As far as evidence for WetWare issues, like I already stated, there are very few solid studies. All we can do is speculate and create cognitive models to try to estimate developer thought processes. However, this does not mean we should ignore WetWare. Just because a factor is difficult to measure does not make it unimportant. This is often the fallacy committed by academics: "It's so messy/difficult to measure such that we'll only use easy metrics to judge tools". (See SovietShoeFactoryPrinciple.)
And I am not against using "theoretical purity" to measure tools. It should indeed be part of the evaluation equation. However, there have been two practical problems trying to apply it. First is that nobody agrees on what it is. Is it about parsimony alone (fewest parts, smallest code)? I disagree that parsimony trumps everything else; it's one factor to weigh among many. See ChallengeSixLispVersionDiscussion for a related discussion.
Second is connecting theoretical purity to some practical metric. For example, in the thin-tables-versus-wide-tables debate, the thin-table proponents insisted that thin tables are "better purity" (paraphrased). (Generally "thin table" means a high normalization number.) But they didn't say what metric they were using for "better", nor how it would translate to practical benefits in a clear way. Their argument appeared to be, "If you read all the books and research papers I have, you'll JUST KNOW, you'll feel it in your bones that it's better". That's hog-wash! I refuse to accept that kind of argument other than a form of weak or highly anecdotal evidence. You cannot expect one to accept the "feel it in your bones if you were informed enough" type of evidence in a strong way. (Weak evidence is fine as a minor rule of thumb, just don't hang your hat on it.)
Even something as complicated as a rocket, one can almost always justify a technique in terms of practical benefits such as being more fuel-efficient, more accurate, more reliable, less pollution, etc. If you only say, "But engine X increases the Florkenheimer Coefficient by 300%! Therefore, it's better!". I then ask, "but how does a higher Florkenheimer Coefficient translate into something practical?" I expect an answer in terms of economics, speed, reliability, etc. (which can then be measured via physical models or actual tests.) However, I get a round-about response from my detractors, similar to the just-feel-it-in-your-bones approach above. This is frustrating and a cop-out. It appears to be MentalMasturbation over a concept instead of an attempt to see concepts in terms of practical benefits.
In RocketAnalogyProblem, it was pointed that the complex interaction of parts is just as important as optimizing each part, especially if we want to mix and match and adapt systems to new situations or environments, which is closer to typical software engineering issues. However, the variables associated with these complex interactions are many. Yet some seem to obsess on some narrow theoretical aspect(s) and insist this thing of theirs is more important than everything else. If I ask them why that one or few factors is more important than everything else, I either get the "easier to measure" fallacy (above), or you-will-just-feel-it-in-your-bones-if-you-learn-enough approach (above), which is equally full of putrid squishy stuff.
I welcome different opinions and accept different options as something to consider. But what gets me are those who INSIST on OneTrueWay without practical metrics that demonstrate it. I don't insist that any one metric or tool is "clearly better", but some of you zealots do, and these "clearly-better" zealots are the ones that I debate intensely with, creating a ThreadMess in the process. -t
Re: "your assertions frequently defy established practice or knowledge" -- Every claim should be justified and challenged. ArgumentFromAuthority is a fallacy. If a claim that X is better than Y is "established practiced", it should be challenged in terms of practical metrics. If it cannot produce practical metrics, I have a right to criticize it. No technique gets a get-out-of-scrutiny-for-free card. If you have clear evidence, present it. Just don't give me the you-will-just-feel-it-in-your-bones-if-you-learn/use-enough bullshit. -t
Summary of common fallacies from my detractors:
Most of the accusations from my detractors are indeed bullshit. They don't think through their accusations; they are just knee-jerk reactions in most cases. I find them shallow thinkers who crave authorities to quote and do their difficult thinking for them, especially in terms of compare and contrast. They don't want to admit to messy complexity in tool measurement and comparing, and instead look for the single magic factor or formula to hang their entire argument off of. This includes looking for the a single magic factor to fail a given design on if they don't personally like it. More practical-minded people, on the other hand, understand that design and engineering is the art of trade-offs among myriad factors such that there is no OneTrueWay or magic metric to pass or fail something off of. My detractors tend to have an obsessive kind of personality and look for fake reasons to be able to obsess on something to satisfy their obsession-addiction. "If you were smart like me, you'd just know that factor X is the most important factor in the world!"
[This interesting world view explains a lot.]
I don't see it as an unusual viewpoint in terms of tool evaluation, but I suspect a lot of the tension on this wiki is due to very different philosophical views regarding the purpose of software and how to measure how well it meets such purposes, etc. Perhaps it's because I view software as a tool to do useful work as defined by the "customer" while some here view it as way to document and "correctly" model reality on a big scale.
[A lot of people don't know how narrow their small glimpse of reality really is.]
Perhaps that applies to every human being. If you are spending time doing A, your are not doing B.
[That's a FalseDichotomy, not doing something doesn't mean to not being aware of it, not knowing it or not understanding it.]
I never met anyone good at everything relevant to software. (Sure, some blowhards claim they are, but usually actual skill is inversely proportional to bragging intensity.)
Also, there's been a few times where I was debating someone claiming to be an expert in a particular field, and later another alleged expert comes along and either agrees with me, or proposes a 3rd viewpoint altogether. Even IT subject experts often don't agree.
But the bottom line is that ArgumentFromAuthority should NEVER be presented as strong evidence. As weak evidence, fine; I have no problem with that.
As far as LieOrStreet, I'll LetTheReaderDecide whether that's subversive or not. And I only raised questions, not recommend a certain action. I don't understand what you are upset about specifically in it.
Re: "You don't even work to implement your eponymous ideas of TableOrientedProgramming;"
Relax, I've got time: http://news.sciencemag.org/climate/2014/01/earth-wont-die-soon-thought
As has been suggested multiple times, can we not refactor all these useless quarrels with the top persona into one easily-ignored pile of puke? Let the top arguebot spew all over that one page, and the rest of us can go on with our professional lives in peace. -- MartySchrader, signing so that the top coward can't complain about anonymity. Heh. Irony, anyone?
See WikiFilterist
See: PatternsOfClaimsAgainstTop, TopVsOthers
EditText of this page
(last edited September 2, 2014)
or FindPage with title or text search