Should Top Be Banned

(Copied from InsultJustificationDiscussion.)

Let's have this issue out once and for all since many discussions seem to return to the same theme.

I was enthusiastic about c2 years ago. I stopped posting any of my opinions about software development years ago. I just cannot stand the idiotic flaming.

I still read c2, usually through RecentChanges. Sometimes I use it for reference, for which purpose it is usually good.

But there is no way I would bother with any of my approaches to software development. It just aint worth it.

In regard to the present discussion, I know Top has some very good ideas. I also know that the RKs of the world also have some very good ideas. The constant to-and-froing of people like these reminds me of the early days, when there was always a healthy argument between the fortranners and the cobolers. Never the twain shall meet.

Show some respect for opinions you do not embrace. You just may learn something. --PeterLynch

Yeah! We should stop deleting SchizoidGibberishWikiAuthor's contributions, too!

I agree that we shouldn't dismiss an opinion merely because we do not wish to embrace it. That's quite different from dismissing an opinion on the basis that there is no sound or valid justification for it. Sometimes TopMind has good ideas, and I don't hesitate to acknowledge those. RK was full of interesting ideas, though he was also an emotional powder-keg with a vicious streak who left about six months before I arrived (I chatted him up, later). But TopMind also likes to weigh in on subjects in which 'UnconsciousIncompetence' is a relatively positive description of his expertise (DeliberateIncompetence would often be more accurate). And if he has trouble following a counter-argument due to his incompetence, he shifts blame to everyone else - blame the 'academics' and 'ivy leagers', blame the anti-toppie conspiracy, blame anything but himself. Sometimes he even claims to be speaking for 'the masses' and 'the practitioners' arrogantly voting himself representative. (You won't see me speaking 'for' academics.)

Despite the fact that I acknowledge and respect some of TopMind's ideas (I refuse to dismiss ideas merely because they come from fools, babes, or TopMind), I cannot respect TopMind as a member of this society. I truly, honestly, believe he's of net negative impact and believe he should have been banned years before I joined WikiWiki, and I suspect the only reason he wasn't banned is that he was somehow 'grandfathered' in by people unwilling to ban members of the 'old guard'.

Anyhow, this present discussion isn't about whether Top has good ideas now and again. Nope. This isn't about insulting ideas. This is about behavior, and habit.

I know many of you want this to be an academics-only wiki, but it is not. Ward has NOT declared that scope limit. I know you don't like communicating with practitioner-minded people, but tough. If you want your ivy-league ideas to be adopted, you better learn to better communicate with practitioners instead of trying to belittle them away. If WetWare matters, the practitioner mind can't be dismissed anyhow just to simplify your equations. Software and design issues are as much for people as they are machines. You have to design hammers with carpenters in mind, not physics teachers. This means you have to work with carpenters to test your theories. It may be uncomfortable, but necessary. It's the step the Greeks skipped to their peril because they didn't want to get their hands dirty. The Romans, with their inferior math, clobbered the Greeks because they were willing to get their hands dirty.

If you ban me, do it because of clear-cut rules, not merely because my statements generate waves in general. It is human nature to ostracize minds not like our own. Resist. You can learn from aliens. Besides, other than failing to become an academic, I'm not sure what my "sin" is exactly. And who made Failing-To-Become-An-Academic an "official" sin here anyhow? I agree I generate "friction" in the wiki-wiki community, but it's because I say things about software that are uncomfortable to others. Is that by itself a sin? Controversy by itself is not "bad". In fact, it's a necessary part of growth and change. You seem to be afraid of the Big WetWare Question, and hide on an academic island with your poetry to protect you (queue S&G tune). --top

I vote no. -JH

I vote no and I am an academic. -- JohnFletcher

I vote no. -- GunnarZarncke

A vote is irrelevant - just HandWaving of a different sort.

{The "friction" Top causes here and elsewhere is the same "friction" that quacks cause in the medical community. However, unlike some quacks, Top is harmless -- except, perhaps, to his employers and himself -- and I doubt anyone (except other quacks) takes his views seriously. The best way to be "rid" of him is to ignore him; anything else only gives him a certain unfortunate legitimacy.}

Quacks cause friction, but so do those who push the status quo and break up GroupThink. Without clear-cut numeric metrics, it's hard to tell the difference. ArgumentByElegance is against the principles of science[1]. Lack of science is the breeding ground for bullshit either way. Kill me with science, not HandWaving patronization. -t
Science is the study of the natural universe. How can anyone kill you with science if programming is not really a science? For example in order to prove to you that number types exist, what does science offer us in regards to number types? Nothing. Science doesn't study number types. Math is not really science. How about relational theory? that's again mathematical, not a study of the natural universe. Since programming contains math, and since many people have tried to kill you with math, why don't you listen to any of the mathematical arguments such as: "math has types, so programming must also". Since math has number types, logically programming must also have number types. That's a fact. Programming contains math within it - any time you add two numbers, you are using math in programming. You argue that you want a programming language that is typeless or type free. You are arguing against math. Math is very old and has thousands of years of success to back it up. You are rejecting math. Your request for people to kill you with science isn't something we can always do, because programming is not as much of a science, since science studies the NATURAL universe around us. We can only kill you with logic and math. But if you don't understand math how can one kill you with it until you first understand it? There are plenty of logical arguments against Goto's like the structured programming articles, and these articles contain strong reasoning. You argue that programming is just psychology anyway. So we have to kill you with psychology, not science or math? You keep moving the goal posts. One day you support math, the next day it's just psychology and not about math.
Re: "You argue that you want a programming language that is typeless or type free." - Actually I want a programming language that is type-tag-free. Whether that encompasses all "types" depends on the definition of "type", which nobody can define unambiguously, and some of you seemed to eventually agree with. Sure, they have patterns and tendencies, but that's not necessarily unambiguous, and not how most definitions are written. Further, complaining about vague definitions is not necessarily the same as complaining about something as a useful tool. Something can be useful without being well-defined, such as life (DefinitionOfLife). -t
For the 20 years or so that I've been using a computer, I've never once cared whether or not types are implemented using tags, flags, or pattern matching. I wouldn't reject a programming language just because they used structs to store type information instead of using integers. The implementation details of a type system have nothing to do with understanding what types are. Your obsession of how a type is implemented doesn't make much sense to anyone on this wiki. I don't care if it uses flags or pylons underneath - even if the type system used Goto statements at a low level for some reason, that wouldn't change what types are and it wouldn't change the understanding of types.
- The "side tag" is a model, not necessarily an implementation. Ideally we want a definition, but nobody has proposed a solid one yet, so for now I'll stick with the model.
- What's with the "we", Top? This is your personal crusade, and yours alone. It would be much more accurate to say that you don't like the familiar, well-known, recognised definitions that have been repeatedly offered here, so you're sticking with something that is -- at the very, very best, and giving it a lot of latitude -- perhaps a vague analogy.
- You haven't done a decent survey and I haven't done a decent survey to see how many are "happy" with the current definitions. Thus, we have insufficient info to confirm or deny your statement. Most in the industry probably don't give a rat's ass: they just make tools and software that do useful things and move on. However, for academic and debate purposes, a more precise definition would be helpful. "I know an X when I see an X" is not the ideal state of a concept definition, and most academics and fellow IT pedantics will likely agree with me on this. -t
A child can easily understand types by looking at apples and oranges, which are different types of fruit. Does an apple or orange have a type tag in its molecular structure? Who cares? Even if it did use tags inside the molecules to ensure the apple really was an apple via its tag, that would be an implementation detail that the child need not be concerned about. The child doesn't care if apples are composed of Ions, tags, molecules, Atoms, or blood and gore. The child concerns himself with the fundamental understanding of what types of fruit are at a high level. There are different TYPES of apples, regardless of whether apples are made of molecules, ions, tags, and/or atoms. A child can easily tell an apple and orange apart from each other since they are different types of fruit. Whether or not the apple contains an apple molecule marker, flag, pylon, or tag at a microscopic level, doesn't matter when trying to understand types. He's not using a microscope to distinguish the apple from the orange, and even if he did use a microscope, there would be no apple tag sitting inside the apple at a microscopic level, it would just be a binary blob of atoms/molecules/ions. That is a low level detail whether or not something uses a tag to differentiate itself. In the universe, it just so happens there are no type "tags" or flags inside the apple or orange. And one does not need to understand tags or flags in order to distinguish between different types of fruit. The molecular composition of a fruit is what distinguishes it from another type of fruit. An apple has a different molecular composition than an orange, making it a different type of fruit - without any tags in the implementation! Who cares if the apple contained a type tag to differentiate it from the orange? Why would would someone understanding types need to understand low level tags?
- We already discussed and agreed in TopsTypeDeterminatorChallenge that "I know a type when I see it" exists and there is a rough agreement among the population about knowing "it" when they see "it". But notions are not sufficient rigor for our purposes. It's roughly comparable to DefinitionOfLife: everyone can name patterns and features which tend to roughly overlap among the debating population, but no consensus has arrived yet.
- The only "consensus" that's missing is your agreement with everyone else. You appear to be conflating "consensus" with "unanimous". The rest of us don't care whether you agree with the accepted definitions or not, but please don't try to make it look like there's some grand, computing-wide debate here, because there isn't. It's just you, quibbling.
- See above about opinion surveys.
It is like you are some kind of tag racist. If it has tags, I'm not using it. I never once cared whether or not Delphi or VB or Cee or Python used tags to distinguish records from integers or strings from reals, or whole numbers from decimals. Why would I care if it uses tags or cee structs to store type info? It's an implementation detail; it doesn't determine whether the type system is useful or not. Does CeeLanguage use tags to differentiate between procedures and functions? Procedures and functions are different things.. functions return a value, procedures do not. Could you use tags to differentiate between proc and a func? Who CARES! I don't really give a damn, and I wouldn't stop using Cee just because the compiler used tags rather than structs or some other storage to differentiate between include/define directives. Whether a "tag" is even a good description of what is happening underneath the hood is another question too. Whether you can actually implement a type system without some kind of storage (tag?) is another question: what are you trying to gain by avoiding types/tags/whatever you call it? Where did you even pull this tag/flag idea from - why would someone even care about whether an apple and orange at a low level are differentiated between a molecular pattern, or a tag? It's not relevant to understanding what types are. To understand what types are, all you have to do is look at different types of fruit - it's that easy. Real easy for a layman: do fruits have different tags inside them at a molecular level? Well they have different compositions of atoms/molecules, but not a tag storage in them. Tags just aren't a relevant detail to understanding at a high level what types are. It's important to distinguish between low level implementation details versus high level human concepts, for creeps sake.
Re: "There are plenty of logical arguments against Goto's like the structured programming articles, and these articles contain strong reasoning." - No they don't. Their reasoning appears to assume a model of human thought, which has not been validated via experiments. I might agree that their model reflects how my particular mind works, but that's not an objective statement and can't be extrapolated to other minds with any reliability. Their "steps" are something implied to happen in a human mind, not in the computer. Thus, validating their model requires a study of WetWare, not machines and not pure math. Math doesn't read code, humans do (and computers don't care whether we use Goto's or blocks for a given algorithm). If I am not mistaken, the "Harmful" paper generated enough controversy about its argument approach that ACM reconsidered their focus, and shifted more toward hardware-centric issues and descriptions of novel algorithms to avoid WetWare-related controversies. Thus, if the "goto" issue is your idea of "strong reasoning", we have a big problem here. Related: TopsToolObjectivityChallenge -t
(cont'd) The articles do contain reasoning about why jumping around with gotos is not good - It's called unstructured programming. I'm not talking about the "GOTO CONSIDERED HARMFUL" article, I'm talking about the whole branch of programming known as "structured programming" which came about decades ago. "Notes on structured programming" and other articles like "structured programming with gotos" by Knuth. One can write a paper that logically demolishes unstructured programming (using massive GOTOs) without running lab experiments! that's the difference between math and science. Science wastes a lot of time with experimenting, whereas math can use logic and reasoning without experimentation, saving humans a lot of time. Math proofs are done without lab experiments. You can prove someone wrong in math without doing experiments! That's the beauty of math and the problem with science; science requires tedious testing and experimentation of the mess we live in (the universe). You didn't run experiments to ensure your math was correct; if you did, you wasted lots of time! Math isn't a physical science. Neither does the relational model deal with the physical universe. Why run continuous experiments and labs to test the relational model to see if it is superior at a logical level compared to XML/trees/navigational db's? Do you think we should be running these experiments right now in labs? Likewise, why run experiments on Gotos if we already demolished unstructured programming decades ago. You still think that it just boils down to psychology or human differences. That's sad, very sad that you misunderstand logic and reasoning so much, and confuse it with psychology. In fact why not psychiatry instead of psychology?
- It's important to RaceTheDamnedCar when it comes to Goto's. Please answer: Does your favorite study/paper make any assumptions about the human thought process, yes or no?
(cont'd) I think this is where you went wrong in your understanding of programming: you thought programming was a natural science where we can run lab like experiments. Yet when asked for experiments or objective evidence for your own pet theories, you provide none. Why is that, Top?
(cont'd) They proved Goto spaghetti code (unstructured programming) was bad, and similarly they also used logic and reasoning (without lab experiments) to prove the relational model is king for databases. Do you think that they (Edgar Codd) used science lab experiments to prove navigational databases or data trees were poor data storage models for banks and similar companies? Or did they use logic and reasoning? Did Edgar Codd develop the relational model because of some psychology link? Is the relational model just a psychological or psychiatric medicinal thing? I challenge you to find some objective experiments out there that prove numbers or booleans are a good thing, or that poop has a bad smell to it.
- It appears relational caught on at least in part because a bunch test sample queries were more compact and more understandable to coders than the CODYSAL query systems of the times. Thus, it was a combo of ArgumentFromPopularity ("we like it") and an informal code-size metric (less query code). That was the recollection of one of the early enthusiasts at IBM. See HistoryOfRelational. (Code size can possibly be considered an objective metric. However, most agree it shouldn't be the only one, and there is disagreement about how to score size. Related: LinesOfCode.) -t
- Note that I believe a modernized version of ExBase could be quite competitive with relational. Although it lacks in automated query optimization potential, it makes up for it in its ability to mix declarative (functional) and imperative. Different things are easier, or at least more "natural" to most humans, in each paradigm. The smooth mixing is one thing I really really miss from ExBase. (One would have to do more hand-tuning to compete with auto-optimization.) -t
(cont'd) Where is the hard objective evidence that poop has a bad smell? Who is to say poop has a bad smell if EverythingIsRelative (cop out), and one person's stench is another person's gold? Or how about objective experiments that prove the plus sign or subtraction sign is useful or necessary to humans. Why do we need it. I demand evidence, now. Beat me with science. Otherwise I win all arguments on this wiki by default. I win 90 percent of arguments. Are there any statistics or studies or experiments or objective evidence proving numbers, booleans, or even our own poop is useful to us? If there aren't any experiments, why are we using numbers and poop? How about objective evidence for toilets - why do we even need them? Please, bring forward the science, beat me with SCIENCE. Toilets are not so useful until they are proven with hard science and objective evidence. I just won, another argument! By demanding objective evidence. What about booleans - did they do lab experiments to invent the Boolean or did some genius come up with it using logic and reason? I think this is the main problem with all your arguments, Top, on this wiki: you confuse natural sciences with math. You think that programming a computer is like a chemistry lab experiment - yet you provide no hard evidence or objective proof of your own pet theories.
How we allocate resources for human goals is a political + economic issue, i.e., WetWare. Science never dictates behavior in the absolute. All it can do is find the best way to achieve a given goal if the input resources and output good-ness criteria are well-defined. Thus, science will never dictate "blow up the moon" without a stated context. But it can help find the least expensive and/or quickest approach IF your goal is to blow up the moon, and you can define your resource optimization metrics in a clear way.
"Do goto's help or hurt software creation and maintenance costs and delivery times ("productivity") assuming an equal bug count" is a legitimate scientific question. However, keep in mind that answering that question doesn't necessarily answer WHY goto's are better or worse for productivity. That's a different science problem. -t
And, I only "demand" rigor if you INSIST your favored approach is objectively or clearly better. If you said, "My professional assessment is that allowing bags in RDBMS tables should always be avoided", I can respect that statement as given even if I disagree professionally. HOWEVER, if you insist that those who disagree are stupid dumb-ass trolls, then I have to complain about your approach and demand more rigor. In other words, the stronger, more absolute your claim, the more rigor you are obligated too. That's fair and I believe most WikiZens would agree with that statement. -t
I never insist that TableOrientedProgramming is objectively and clearly better than OOP or FP. I only insist it be respected as an option to consider. If TOP doesn't work for your particular WetWare, I can respect that and live with that. You, on the other hand, seem to believe your opinions are an absolute universal truth, and are rude to those who disagree. In my book, that makes YOU the "troll", not me. It's comparable, in a digital sense, to what terrorists and evil dictators do: use WMD's (DisagreeByDeleting) and violence (rudeness) to FORCE others to their view of the OneTrueWay. -t

Another no vote. I don't think we should ban people unless they are abusing someone. While Top's deliberate ignorance and claims to represent practitioners is annoying, I don't think it qualifies as abuse. -- Martin Shobe.

Reluctantly, I must go with the consensus here that Top is basically harmless. Annoying, sure. Simple-minded at times, absolutely. Capable of wasting plenty of your time with meaningless, illogical arguments, to be sure. But still harmless, even after all that. Stop feeding the trolls and they'll go elsewhere to chow down. -- MartySchrader

[As of October 2010 I may have shifted my opinion on this matter; check out IsTopTheNewRichardKulisz for more details. -- MartySchrader]

I think we should stop deleting SchizoidGibberishWikiAuthor's contributions on that same basis as the arguments given above. You guys (MartySchrader, Martin Shobe, Top) should help. We should start reverting deletions immediately.

{Point taken, but although the value of Top's contributions is clearly debatable, all but one of the participants who have weighted in on the matter would rather see Top's posts remain. I don't see anyone seriously arguing that SchizoidGibberishWikiAuthor's contributions should be preserved.}

I consider DoubleStandards the greater sin. If we are going to keep Top's contributions on the basis of the arguments given above, we shall also keep SchizoidGibberishWikiAuthor's. I will seriously argue this. If we wish to keep Top's contributions but reject SchizoidGibberishWikiAuthor's, you will need to provide some different arguments.

{Argue away. In the mean time, I propose we maintain status quo, such that Top's contributions shall remain and SchizoidGibberishWikiAuthor's shall be deleted. If you can convince the regular participants -- or at least a majority thereof -- that either Top's posts should go or SGWA's should remain, then that can change.}

DoubleStandards it shall be, then. I suppose I'll just leave WikiWiki.

{You do know we're no longer giving out the "Richard Kulisz Award for Amateur Dramatics (Queen Category)", don't you? By the way, the standard applied here is essentially the same as that used to maintain employment in the public sector throughout most of (at least) the Western world: Schizophrenia or psychosis is cause to be dismissed; being an idiot isn't.}

I've been thinking about leaving for a while now, so this is hardly a spur-of-moment thing. Rather, this is a 'last straw' issue - or perhaps an excuse I've been seeking for a while now. WikiWiki takes too much of my time. Arguing with self-important morons - mostly TopMind - is too tempting and takes too much of my time; the best way to resist temptation is to avoid it. People who say "don't feed the trolls" often feed them on a regular basis - hypocrisy whose basis is character weakness rather than dishonesty. I'm not strong enough to follow that advice, and the resulting ThreadMode messes undermine many otherwise valuable pages. I believe many useful community contributors have left for similar reasons. (How many people who commented in ObjectiveEvidenceAgainstTopDiscussion are still here?) I see WikiWiki as a dying community. I think I will find or build a better platform for airing my own thoughts. In the meantime, I will remove my name from this Wiki, along with any contributions I feel would require maintenance by me. Doing so will remove the remaining temptations to remain in this bad, bad place.

{I suspect you're reaching a realisation that most Wiki participants eventually seem to reach, which explains why keen contributors inevitably go elsewhere. It certainly is reasonable to leave if you're finding yourself drawn into spending more time here than you like. I never spend a minute more than I want to -- sometimes that means I delightfully argue ad infinitum against Top's idiocy, and other times I let it slide. I don't take WardsWiki seriously enough to give it more attention than that. Maybe that's part of the problem. *Shrug*. Note, by the way, that what you're going through with Ward's Wiki is something you'll probably eventually experience with the 'net as a whole and you'll wind up planting bananas or running a motorcycle shop. That's not a bad thing. The world needs more bananas and motorcycle shops.}

A community goes sour because the people let it. Anyhow, you should stop feeding the trolls even if you find it delightful. Your words: "The best way to be rid of him is to ignore him; anything else only gives him a certain unfortunate legitimacy." Or are you keeping a troll around for amusement? Sigh. Well, keep your pets, have fun.

{Yes, I do find Top amusing. Is he trolling deliberately? Dunno. Don't care. Doesn't matter. I haven't particularly argued with Top lately, though, because I don't feel like granting him any legitimacy except when my desire for casual amusement exceeds my desire to limit his legitimacy. Lately, it hasn't.}

See WikiAsReference for some comment on that aspect. (Note: this is missing a de-reference tag??) Please explain. Perhaps it is that I didn't give the reference here to PeterLynch's comments at the top of this page, where he said Sometimes I use it for reference, for which purpose it is usually good.

Won't Do Something

The accusation against me seems to be that I "won't bother" to read the pet academic materials of the author(s). However, I also ask a chore that the other side refuses; namely describe in detail how they know their pet technology is better in (useful) measurable numbers, not just "it feels right in my head".

Your chains of (alleged) reasoning are too long to skip measurement. GoodMetricsUseNumbers, so stop using lousy metrics and acting like your Rube Goldberg "logic" is "good enough". It doesn't matter how complex it is, numbers can be found to measure it. Even rocket designs can be measured in various metrics such as success percent, cost of fuel to reach the moon, etc. Thus, complexity is NOT an excuse to receive a Get-Out-Of-Metrics-Free card. I find it hypocritical that you complain about what I won't do, yet you won't do something either. --top

Banning him gives him more recognition than he deserves, delete gibberish and move on.

Deletion is rude. You are free to argue your case, but not delete others' opinions (without risking retaliation). I know you feel certain you are right, but that's not sufficient reason to delete opinions you don't agree with. EarnYourRightToInsultMe.

Engineering is a process by which we expand we expand and refine our knowledge based an application and testing, it is not a system of unsubstantiated belief. TOP applies a very old technique of LanguageFraming? such a way Facts are challenged by Belief on supposedly equal ground. aka "his opinions are just as good as our facts." It proves should a fundamentally misunderstand what science is about that I would be surprised if it can ever be fixed.

If your "facts" were clearly true and refined, then using them to counter such "proletariat" claims via something like ItemizedClearLogic should be relatively easy. If you do so repeatedly for the same person, such a proletariat will lose credibility and people will stop paying attention. You could link to a list of their failures against ItemizedClearLogic when they start a new set so that readers can quickly identify their past logic failures to know better. It has the side benefit of documenting IT knowledge in a concise manner for students etc.

"Equal ground"? That sounds like some kind of human ranking, ArgumentFromAuthority. -t

Footnotes

[1] Unless perhaps as it relates to selecting among competing theories. Occam's Razor generally favors elegance. But that's at a different stage than the "problem issue" here.

Hi!

I'm new here (just passing by). I think you're all a bunch of cowards for not manning up the courage to boot a constantly disruptive troll. I just wasted an entire day mezmerized by the resulting slo-mo train wreckage. It was entertaining, in a schadenfreude kind of way.

The idea of this wiki is good, but any online gathering place that will not deal with trolls will eventually be killed by them. I'm guessing that's what happened here. I wouldn't want to invest anything into joining this community (if it's still alive), simply because it seems trolls have free reign here.

Ain't nobody got time for that!

cheers!

Kill me with ItemizedClearLogic, not hate. I believe PageAnchor Complaint-004 under TopMind is by the same author as the above. Note that being "disruptive" by itself is not inherently bad. For example, Socrates was "disruptive", but started a revolution. (Of course, true charlatans also are disruptive.) --top

In my opinion, most anger against me is from those who get personally upset when their sacred cow or cash cow doesn't live up to the scrutiny I toss at them, and thus they join the "top is a charlatan troll" bandwagon along with the other cow-kicked WikiZens. Their pride or fear of financial loss prevents them from accepting defeat, and they thus deflect that onto me. Human pride is a bastard. --top

[I haven't seen anger against you for years. I've seen some frustration, but that's not because you are killing anyone's "sacred cow or cash cow". Indeed, like most technical people, I think C2 participants are sufficiently anarchical to appreciate a really good sacred cow (or cash cow) killing. However, sacred cows are killed by weight of evidence and cutting logic, neither of which your usual arguments bring. Your arguments are not "scrutiny" in any rigorous sense -- which would be great -- but are merely superficial (and frequently emotional) objections, i.e., they're slightly more verbose ways of saying "it sucks!" This seems especially the case with facilities -- recently, HigherOrderFunctions or PreparedStatements; historically, OO and polymorphism -- that as software engineers and computer scientists, we know they work and would much rather focus debate on the genuinely interesting controversies in the field rather than defend useful and established facilities against your naïve, weakly justified, poorly evidenced, and blatantly reactionary criticism.]

Such arrogance and hypocrisy. And I don't know why you reference OOP and polymorphism, I was largely right about it from the beginning: it's usefulness is limited to specific situations, and the industry as a whole generally came to agree. The OO fans of the time made the same accusations against me that you are making now ("Us smart/educated/academic people get it, but you don't"). Same lame anti-scientific song and dance. And my argument against PreparedStatements was NOT that they are "bad" per se, but rather that you were relying almost entirely on ArgumentFromAuthority to condemn those who question its use (because the evidence is locked up and proprietary for non-OSS DB's). ArgumentFromAuthority is still all you have.
[Sure, the "authority" of the major SQL vendors. That and over a decade of continuous industry use of PreparedStatements, and the source code for PostgreSQL and MySQL which demonstrate the same performance profile as closed-source DBMSs. If any vendor made a PreparedStatement implementation so flawed that it permitted SQL injection, I'm sure the industry would not have let it forget it. Regarding OOP and polymorphism in particular, I'm was referring to your argument was in favour of "if" statements over polymorphism. The "industry as a whole" most certainly does not agree with that.]
Like I said in that topic, The DB vendor could simply say it was a coding mistake and release a patch. There are all kinds of tricks vendors pull. They are proven spinners. Your premise was that they should be sued and/or fired for not accepting the vendor's word at face value. THAT'S FUCKING RIDICULOUS. I am confident most readers will agree that was a stupid stance of yours. And machine performance wasn't the main debate issue. And I never said that polymorphism was always bad, only that it was oversold. Example: ReplaceConditionalWithPolymorphism.
[If you used filters instead of PreparedStatements in my shop, I would fire you. Several of my colleagues and I discussed this a few months ago, and they would do the same. However, I invite the WikiReader to read TopOnPreparedStatements and related pages and make up his or her own mind. There is no need to repeat the debate here. As for polymorphism being "oversold", how do you measure "oversold"?]
Like I keep pointing out, people tend to gravitate toward certain personalities and institutional culture such that asking your colleagues may not be very representative or fair.
[So? It's sufficient to note that there are people who agree that firing you would be an appropriate response to deliberately choosing a mechanism demonstrated to be weak against SqlInjection (filters) over a mechanism demonstrated to be strong against SqlInjection (PreparedStatements).]
Untruth. It has NOT been demonstrated in a controlled environment. Just admit you rely on mostly ArgumentFromAuthority. Your pride and stubbornness just keeps you from manning up to admit it. Say it slow: a-r-g-u-m-e-n-t f-r-o-m a-u-t-h-o-r-i-t-y. Breath in. Breath out. Okay, let's try again real slow: a-r-g-u-m-e-n-t f-r-o-m a-u-t-h-o-r-i-t-y.
[It's been demonstrated in something better than a controlled environment; it's been demonstrated empirically in hundreds of thousands, maybe millions of dynamic Web sites, over the past decade. As for ArgumentFromAuthority, we've been over all that -- including why it isn't ArgumentFromAuthority when it's based on evidence -- on TopOnPreparedStatements and related pages. There is no need to repeat the debate here.]
I disagree with that claim, as I see no numbers, but I will let the above links address those. (Yes, you gave numbers, but they measured strawmen.)
[Disagree all you like. Reality is orthogonal to your assertions.]
We'll LetTheReaderDecide. I'm confident most would side with me that your "science" is tenuous, and wish I could bet money on the jury outcome. (I'm not against the usage of anecdotes, but to make strong claims USING those anecdotes is an intellectual sin in my book.)
[Where are strong claims being made using anecdotes? Do you know how PreparedStatements are implemented? Are you aware of even one instance of a properly used PreparedStatement resulting in SqlInjection? Arguing that they can is akin to arguing that "while" loops can, in and of themselves, cause buffer overflows. Obviously, in a deeply flawed language implementation they could, conceivably, do so -- with a certain almost concentrated effort to do things as badly as possible -- but no sensible implementation would ever do so, and a few minutes of a testing prior to release would reveal it.]
Reruns, sigh. You cannot verify how a given commercial vendor actually implements them. Further, we don't know if they'd be honest if a breach was found. I don't trust MS, Oracle, etc. to be forthright. They are known spinners. A true study would NOT rely on vendor honesty. Further, I don't know of any breach of established filter-oriented packages, such as [forgot the damned name]. Again, I'm not suggesting one completely ignore their advice, but their claims are NOT strong enough to justify your fire/sue treatment. IF there was clear and solid and available science on it THEN fire/sue would be justified. It's not, period. -t
[Commercial vendors don't have to be honest if a breach was found, because the developer and user community would be up in arms over it. It would be major IT news that a vendor couldn't possibly keep quiet. We also know exactly how PreparedStatements are implemented; they're established technology implemented in a conventional way that results in a recognised performance profile. That profile is the same whether the PreparedStatement implementation is OpenSource -- in which we can see how it's implemented -- or a commercial version. The performance profile is a clear indicator that the vendor has used convention in implementing PreparedStatements. All available evidence suggests PreparedStatements are more secure than filters. Even the makers of the filters whose name you've forgotten -- the OWASP ESAPI -- explicitly recommend against their own filters in favour of using PreparedStatements. Given their recognition in the industry, and given the preponderance of evidence in favour of PreparedStatements and against using filters, it seems clear that deliberately using your homespun filters (which they probably are, if you can't remember the OWASP ESAPI) instead of PreparedStatements is a deliberate rejection of a more secure mechanism in favour of a less secure mechanism. It wouldn't even matter if PreparedStatements were only slightly more secure than filters, your choice of a less secure mechanism over a more secure one -- when all else is equal, though PreparedStatements are actually simpler than DynamicSql on the client side of the DBMS because they don't need to invoke filters -- is a sackable offence.]
We don't know how many breaches are first revealed to the vender versus the public. Without evidence of that ratio, you only have personal speculation. As far as the performance profile, that's rather indirect evidence. Plus, you didn't cite the numeric results of such performance tests. Perhaps a professional SystemsSoftware expert could make a reasonable assessment of such an implementation claim, but the vast majority of custom business software development shops are NOT going to have many SystemsSoftware experts. Re: "Given their recognition in the industry": there you go again, more ArgumentFromAuthority. You look anti-scientific when you keep slipping into that bad habit, you know. Your attraction to authority keeps revealing itself. You have authority egg all over your face. And "slightly more secure" is a reason to fire/sue somebody??? That's utterly ridiculous, it's blatant NarrowStaffSelectionFactors. You are an obsessive fastidious zealot. Troll-B-Gone!
[Numbers aren't necessary -- simply run a DynamicSql query in a loop and compare it with executing the equivalent PreparedStatement. With a complex query, the difference is dramatic, and clearly demonstrates that query text is not being re-parsed when PreparedStatements are executed, just like the vendors say and just like the OpenSource implementations show. Why would software development shops need to have SystemsSoftware experts?]
[As for "authority egg all over [my] face", you must realise that you rely on authority all the time. You probably rely on your doctor to treat your diseases rather than a shaman, because a trained doctor is an authority on human wellness. You use an authority on plumbing to fix your pipes, and an authority on car mechanics to fix your engine. You almost certainly use an operating system written by Linus & Friends or the crew at Apple or Microsoft, because they are authorities in writing operating systems in ways that you are not. You almost certainly use a SQL DBMS written by an authority in writing SQL DBMSs, because they are an authority in writing SQL DBMSs and you are not. And so on. We rely on authority all the time, because without it we would be fumbling in the dark, struggling to figure out how to do things that the authorities know how to do. Likewise, OWASP have devoted the effort, manpower, expertise and resources that most of us lack into learning about Web security, and so we rely on then to provide reliable, useful results and advice that result in better Web security. So far, they have done so. Thus, they are an authority. Using their advice isn't ArgumentFromAuthority, because it's reference to established expertise. ArgumentFromAuthority is only reference to apparent expertise with no evidence to back it up.]
[You seem to have misunderstood my point about greater or lesser security. Again, if you deliberately choose a less secure mechanism over a more secure mechanism, it doesn't matter if the difference between them is minimal (and that's hypothetical; the difference in security between PreparedStatements and DynamicSql with filters is not minimal), to deliberately choose "less secure" over "more secure" is something for which you should be sacked.]

Another pet peve is that many of you are shitty communicators/writers. I give you suggestion for how to better convey and present your ideas, but you outright ignore them, going right back to your original shitty writing style that failed the first time, and sure enough fails again (at which point you blame me for reading it wrong). Evidence of stubborn personalities. -t

{I find it ironic that you are complaining about our writing styles while using words like "shitty". Please refrain from such outbursts as it makes it harder to take what you are saying seriously.}
Finally, a legitimate complaint against me. -t

[We're software engineers and computer scientists. We're not technical writers. If you'd like to create a page of suggestions on how to write well, I'm sure it would be helpful. Contrary to your claim, I don't recall you giving suggestions for how to better convey and present ideas. At least, I don't recall seeing any that weren't -- as is the case in the paragraph to which this is a response -- more insult than suggestion.]

Yeah, this appears to be the Top Method of <cough> argument. Throw some unsubstantiated claims about, then piss and moan when people point out the obvious holes. When whining isn't enough resort to gutter behavior and language. Thank goodness we have top to bring any possible chance of making progress in discussing serious software engineering topics to a halt with useless flameage and bickering.

No wonder this fellow insists on hiding his identity -- can you imagine discovering that you have top working for you? Oy!

Up yours, hypocrite Handle-Free-Fad-Boy. And I generally follow what my employer wants. If they want me to design stupidly, I'll do it. I state my point of view, and if it's rejected, it's my duty as an employee to do it their way regardless. The work-place is not a democracy. If they get too stupid, I start to look for another job rather than repeatedly argue with them. -t

Let me help you out here, topper ol' buddy -- this here's MartySchrader, yer old phanboi, once again calling you out as a crank, a nihilist, a general purpose naysayer, and an overall asswipe. Everybody on this board has tried to cut you the maximum amount of slack, but you insist on being a complete dweeb whilst hiding behind your anonymity. So, to the above list I add one more attribute: coward. Go ahead and throw all the tantrums and insults you'd like, but the Wikizenry recognizes you for what you are -- a troll and a waste of time. Up yer TenSeven.

I believe my antagonists are mostly a handful of regulars, NOT a WikiZen consensus. The pattern appears to be that fastidious academic-oriented personalities are frustrated that the industry doesn't take their pet concepts or high-abstraction programming seriously, and they take that frustration out on me because to them I represent the "typical field mentality" that rejects their high-falutin' ideas or ideals. They cannot call up random practitioners in the industry to chew them out for "doing it wrong", so instead they focus all their frustration on me: I'm the most accessible specimen of this "field mentality" they despise so much. That's my psychological profile speculation on their abrasive behavior toward me. That's my honest assessment, and may God, Buddha, Naraka, or Zeus strike me dead if I am intentionally lying about this assessment. -t

[The number of contributors, over more than a decade, who agree with you about anything appears to be small. The number of contributors -- who appear to be quite a large set over time, even if they're a fairly small set at any given time -- who disagree with you seems comparatively large. What does that suggest? Of course, we could all be wrong and you could be the lone voice of correctness, but what evidence is there to suggest that is true?]

Back in the usenet days, it appeared that almost everyone was against me in the OOP debates. Yet I got a lot of "fan mail" (for lack of a better description) from those who encouraged me to "keep up the fight". They admitted they were too timid to jump into the fray, seeing how badly I was treated (called a troll, Luddite, charlatan, university-hater, dumb, abstraction-color-blind, etc.). The editor of a well-known IT magazine even gave me personal kudos. I suspect similar here, although I don't post my email these days. Further, most of those against me don't sign. Thus, either a majority of WikiZens don't sign, or my antagonists are a handful of non-signers. Occum's Razor points to the second. The feel and Top-bashing is almost identical to the OOP battle. -t

[Fringe views, even outright batty ones, invariably draw followers. It's how, for example, some UFO zagnuts wind up forming (small) cults. (See http://en.wikipedia.org/wiki/List_of_UFO_religions) In other words, a few supportive emails do not constitute validation, especially when your views typically run contrary to ComputerScience and SoftwareEngineering. Of course, that doesn't mean ComputerScience and SoftwareEngineering are right, but it does mean if you're going to convince anyone outside the fringe that they're wrong, you're going to need far more potent evidence -- and a better approach to presenting it -- than you've brought to the table so far. If you expect any mainstream influence at all, you're going to have to demonstrate serious, in-depth, educated knowledge of ComputerScience and SoftwareEngineering so that you can present your issues to the field as a learned equal armed with patient persuasion, potent logic, powerful evidence, and extensive knowledge. Otherwise, your criticisms of technology appear to be nothing more than middle-aged grumpy naivety, reactionary resistance to change, a certain amount of laziness over learning new information, and a legitimacy-destroying inclination to use insults and expletives.]

Projection. YOU are the fringe, and YOU lack "potent logic". Most in the industry are not ivory tower zealots who mistake their pet models for universal truths. I have NOT violated any clear-cut ComputerScience logic, just your biased word-game versions of them. In short, you hallucinate the existence of ComputerScience canons. (Maybe you are a genius, but your shitting writing and evidence-presentation ability masks it deeply.)

[Your response is merely more evidence of my point, and confirms my allegation. Now, why not try a new approach: Learn about the technology you criticise so that you become an expert. Then you can attack it with knowledge instead of vapid insults.]

Your response is merely more evidence of my point, and confirms my allegation. Now, why not try a new approach: Learn about the scientific process, formal logic, and evidence presentation. Then you can present your claims with CLEAR EVIDENCE instead of ArgumentFromAuthority ("Me iz educated, you a dumby, therefore, me win"). The rocket metrics analogy (RocketAnalogyProblem) shows why your claim is an irrelevant red-herring and a liar's gimmick.

[I've presented much evidence, as have many others here. You ignore it because you don't like what it shows. (What is a "rocket metrics analogy", and how is an analogy a demonstration of logic?]

Bullshit. You hallucinate objectively where it doesn't exist (or is overridden by factors you want to ignore). I honestly think that is a big-ass fault of yours and your real-world-starved brethren. Another compiler writer recognized that trait also in you. The rocket angle proves you are a defective evidence evaluator..

[Wow. You briefly started a reasonable thread here about "thin tables" and proof, and by the time I tried to submit my answer, you'd replaced it with nothing but the above AdHominem insults. How does that help your credibility? ("Another compiler writer"??? "Rocket angle"??? Huh? Dude, I think you've popped a gasket.)]

Go ahead and prove thin tables are scientifically "better" if you want. By rocket angle I mean that you claim only an expert can validate the usefulness of a tool. RocketAnalogyProblem. It's a fallacy. Further, if average staff cannot absorb it either, it doesn't matter if it's theoretically better (GreatLispWar). (I lightened some of the insults.)

[You may have "lightened" the insults, but it's still a purely AdHominem attack. I still have no idea what you mean by "another compiler writer" and "rocket angle", and as far as I can tell in RocketAnalogyProblem, your correspondent discredited your points.]

You see it that way because you are biased against me.
[No, I'm not biased against you. I'm biased against weak evidence and poor arguments.]
Then you should be biased against yourself. Your evidence is very poor. You tend to obsess on narrow pet factors and magnify their importance in your head for reasons that are so very unclear to the reader. I suspect it's one of the trade-offs of an academic-oriented mind: you are very good at details, but sometimes only good at details such that you cannot balance and weigh multitudes of factors.
[It appears you made a mistake in the above. You wrote, "reasons that are so very unclear to the reader", when you clearly meant "reasons that are so very unclear to me." I was very successful as a practitioner in the field, developing -- among other things -- custom business software. One of the reasons for that is that I was quite competent at balancing and weighing multitudes of factors. However, those factors included knowledge of the aspects of ComputerScience and SoftwareEngineering that I suspect you consider "academic-oriented". Those "academic-oriented" aspects exist for a reason -- they directly impact software reliability, simplicity, API usability, flexibility, provability, and performance. All of those translate directly into meeting requirements. My clients liked the fact that I met their requirements -- especially the often-unstated but always assumed ones like performance and reliability (which derives, to a certain degree, from provability) -- and that I could deliver them quickly, which comes from simplicity, API usability, and flexibility. I can appreciate that you feel I ignore human factors -- what you usually call WetWare and economic considerations, as I recall -- but I do not. I simply focus on the human factors that are directly relevant -- like UI design, responsiveness, and ensuring my software makes my clients happy. I deprecate only the human factors that are irrelevant to me -- e.g., like avoiding higher order facilities in order to cater to weak programmers -- because they're also irrelevant to my clients.]
Well, that's anecdotes that I nor the reader have any way to verify, barring hiring a private detective. Everybody on the web claims to be great, smart, and rich such that it would be prudent to take such claims with a grain of salt. Note that the difference between successful projects and unsuccessful projects that I have direct control over usually has to do with understanding what the users/customers really want. Fancy (internal) coding or speed is not where I see the most snags. In one frustrating case, we improved a tool after reading a user survey and questionnaire. Adding the features they asked for made it too confusing to use such that we went back to mostly the old way. Sometimes it takes pure luck to get the features and interface balance just right. I need a mind reader, not a HOF. Also, maintenance issues are more important than creation issues in the longer run. One can often trade long-term for short-term. Paul Graham's system was eventually rewritten in more conventional languages because they couldn't find enough people who could sufficiently grok the Lisp code.
It sounds like the projects you typically work on have complex business and business rules requirements, but simple technical requirements. Fair enough. The software I typically work on has simple business rules requirements but complex technical requirements. As for Paul Graham's system, it was re-written not because they couldn't find enough people who could sufficiently grok Lisp code, but because they wouldn't find enough people who could grok the Lisp code. The management assumption was that Lisp code would be too hard to grok and so they headed off what they believed would become a problem, not that they found a problem and had to correct it.
- I generally agree with your "business rules" assessment. We are generally "gluers": we glue together text search engines, chart/graph engines, random number generator libraries, GUI kits, etc. to build custom software. rather than make these from scratch. But we probably disagree about the frequency of each. I believe there are far more gluers than glue makers. (And I'm not sure it's just about "complex" business rules, but often about murky and/or quickly-changing business rules.)
Are you saying they didn't try? I'm pretty sure a lot of high-level people considered the huge costs of rewriting lots of existing working production code.
Apparently, they didn't. In PaulGraham's own words: "A friend of mine ... went to interview [at Yahoo Stores] in about 2000. He said they told him they didn't need Lisp hackers, because they were going to port the Store Editor to C++. Why? Because they didn't think they'd be able to find Lisp hackers." I doubt a lot of high-level people were involved. Like most high-level executive decisions, it was probably down to the individual responsible for that division's "vision". One can easily imagine a non-technical executive believing the stereotypes of the time: Lisp is an obscure interpreted language with funny syntax and too many brackets, and it was invented in the 1950s so it must be obsolete, but C++ is ObjectOriented, compiled, current, and everybody knows it. Therefore, C++ is an obvious choice.
That anecdote is a lot of indirection: "Paul said a friend said his interviewer said that management said...". The rest of your statement seems highly speculative. More likely I suspect they realized they couldn't find enough Lisp expert with prior practical paid Lisp experience. Organizations highly value paid experience in the very tool they are targeting because they want a proven track record in that tool, not just general programming or IT. I agree they often over-do the specificity, but it is common that the final decision makers are not technical enough to judge the usefulness of "similar enough" claims. It is perhaps a form of QwertySyndrome, but Lisp has had far more shots at bat than almost every other partial failure (in terms of popularity), such that I don't feel sorry for it. You and Paul should form a FP/Lisp development shop and leverage their alleged power to kick all the other consulting shop butts even after the original founder(s) leaves. That would prove success is about the tools and not the nature of the founders or their first team and/or right-time-at-right-place luck. (I'm skeptical, but show me by making it work).
By now, it's all anecdotal and because of that, I was indeed speculating. That's why I used phrases like "easily imagine" and "I doubt" and "it was probably". As for tools, it's not about the tools any more than a good mechanic is about the tools. A bad mechanic with good tools is mostly useless. A good mechanic with bad tools is mostly wasted. A good mechanic with good tools is a powerful force. I'm sure you can extend the analogy to SoftwareDevelopment. (Lisp is a "partial failure"??? By any measure, it has been and still is a roaring success. What other language has had such an influential impact for so long? True, it's never been the most popular programming language, but it's always been a popular language and more to the point, it's been a significant and important language.)
Being influential is off topic. I have no problem with "teaching languages". Prolog and APL derivatives are also great teaching languages. But we are talking about production projects.
You claimed Lisp was a "partial failure", but being influential is perhaps the greatest success it could have. Almost every modern language can demonstrate features inspired by Lisp, but what does this have to do with teaching languages? Lisp, APL (and its derivatives) and Prolog are not considered teaching languages though they are sometimes used for teaching; they are all used on production projects.
I don't see how this contradicts my statement. But I am not going to get into a vocab battle over "teaching language" today.

[By the way, in response to your original "prove thin tables" are better, my response was this: How do you distinguish a "thin table" from a non-"thin table"? The only logically interesting table degrees are 0, 1, and n. At what 'n' do we have a thin table, and at what 'n' do we have a non-thin table? Of course, a table that requires nulls to represent missing column values introduces potential logical inconsistencies, and in general, higher normal forms are preferable to lower normal forms as higher normal forms are less subject to update anomalies. On the other hand, an increased number of joins may result in performance issues in performance-constrained environments, so there isn't a "prove thin tables" that means some (undefined?) degree is unconditionally better than some other (undefined?) degree, at least not without the qualifications that I've just given.]

As far as "update anomalies" I see trade-offs, not solid rules. See TableQuantityVersusAppSize. I agree to factor out known, clear, and stable duplication. However, there's a hell of a lot of grey area and crystal ball failures in the real world.

[I don't think there's a meaningful discussion to be had here until the distinction between a "thin table" and a non-"thin table" is determined. I agree that the appropriate level of normalisation is dependent on the requirements. For most "conventional" business applications, 3NF is fine. For some applications, particularly involving temporal data, only 6NF is even possible.]

I mentioned that it was situational and that I didn't wish to make any concrete "always do X" rules. Anyhow, didn't we once agree that if the DB was powerful and well-designed enough, then thin-versus-thick would be a view-oriented decision rather than a either/or decision? In other words, a "table" would always be a virtual construct (or there would be no visible distinction between a view and a table). It was one of the few times we actually agreed on something. -t

[Indeed, and I don't think what I wrote above contradicts that. It is entirely reasonable to construct a schema in 6NF and use views to present what a user expects.]

"Possible" and "made convenient" are not the same thing. I believe somebody else agreed that existing designs don't make virtual-ness very easy from the update side of things.

[True, most DBMSs do not support update-through-views, or only support it in a limited fashion. Whether this is a limitation or not depends on the requirements. In many implementations it's a non-issue, because updates are only done -- by software -- on base tables. Views are used to present a friendly schema to the people creating reports, which perform no updates.]

Academics want software to be about math, when it fact it's mostly about humans (WetWare). Since they are good at math and usually suck at humanity, they subconsciously try to force the industry into more of a math view to increase their perceived value to the industry and/or see their work recognized more. Sorry, it's the humans, stupid. Face the unpleasant reality instead of brow-beat the messenger, Mr. Top. -t

Really? I'm an academic and former (and still part-time current) practitioner (I mainly develop(ed) custom business software and DBMSs) and I don't know anyone, myself included, who wants software to be about math. We like math, because it's a useful tool, but then so is the wrench I use to remove and install wheel bolts on my truck. I'd rank math and the wheel wrench about equally. I don't want my truck to be made of wheel wrenches. Likewise, I don't think software is about math.

Are you sure you're not confusing "social science in computing" (which is an interesting subject) with ComputerScience and SoftwareEngineering? Are you also sure you're not making up a fight where there isn't one? If you and others want to focus on the human side of computing, that's great. I don't see how it contradicts what ComputerScience and SoftwareEngineering are about, though.

Software design is not "computer science", and software engineering is a gray art.

Indeed, software design is not ComputerScience, it's SoftwareEngineering. SoftwareEngineering is a collection of disciplines ranging from rigorous and mathematical (e.g., software metrics) to craftsmanship and artistry (e.g., user interface design.) There is no single statement, like "software engineering is a gray art", that can be accurately applied to all of it.

Further, you guys can't let some things go. If we come to an AnecdoteImpasse, then leave it there. You keep returning to AnecdoteImpasse topics in an obsessive way, and prod and prod in a rather rude and repetitious way. -t

We only do that when you post provocative (usually, insufficiently substantiated) statements to which we respond, but which you fail to respond adequately in kind.

That's not how I see it. For example, arguments that involve speculation about user or programmer behavior or viewpoints often result in an AnecdoteImpasse, but you guys keep probing me in rude ways for why I have a belief that group X is more likely to do or think A instead of B.

We have no problem with anecdotes and speculation about user or programmer behaviour. We prod you when your speculation is weakly evidenced but you assume it to be true (e.g., most developers can't understand HigherOrderFunctions) and use that assumed truth to argue vociferously against facilities we find useful, like HigherOrderFunctions.

It's a two-way street. The default of "Can typical users grok X?" is "unknown" (null), not Yes or No. Neither side has any evidence to point the needle away from "unknown" except for anecdotes about personal observation and experience. You don't have an OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy and I don't have an OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy. A symmetric AnecdoteImpasse. You can't seem to come to grips with that, seemingly thinking your anecdotes are beatified.

Nor have I seen any decent code demonstrations that HOF's significantly help out (simplify etc.) the kind of software I work on. LetTheReaderDecide if your existing examples sing to their own world (SummaryOfHofExamples). Let it be. If it fits it fits, if not, readers can vote with their eyes to go somewhere else on the web. You spend too much text on speculation about what is a typical reader/user/developer that is not based on solid evidence either way.

Indeed, you've frequently argued that HOFs won't significantly help the kind of software you work on. That's fine. They significantly help the kind of software I work on, as exemplified by HofPattern.

Good. I'm glad they help you.

See: IsTopTheNewRichardKulisz, PatternsOfClaimsAgainstTop

CategoryRant