To the best of my knowledge, no TuringComplete paradigm/technique/tool has ever been proven objectively better than another overall for software development and maintenance, outside of machine performance. In the 50 or so years of computer and algorithm research, not a single specimen proof exists [DemandForEvidence]. They all "degenerate" into psychology, a soft science about subjectivity itself. If you disagree, please give citations and page numbers. * This is shifting burden of proof. * ''How so?'' ** Because it's more or less kickign off a debate with a loaded statement, and then doing the "''I am presuemd right until you prove otherwise''" HandWave. Any point which is not self-evident or already known should be backed up, and there's no reason to suggest that to do that one side needs to provide supporting evidence whereas the other does not. * No, no, we all agree! BrainFuck for example is equal in every way to all other languages - some people's psychology allows them to be more productive in BrainFuck. Actually this is a straw man, because you could do a lab experiment and prove empirically that 99 out of 100 programmers prefer not to use brainfuck for so and so problem - say producing a web app - and this science lab experiment would objectively prove that brainfuck is not a good web programming tool. You could also prove it using logic and reason without the science experiment in a lab, but some people would reject the logic and reason outright and call the logic and reason subjective psychology. * ''Perhaps, but experiments like such are rare for our usual tools. We don't have the luxury of such experiments available on this wiki. If you can perform it and bring it to help your claim, that would be wonderful. Also note that I'd suggest comparing fans of a given language versus a random selection of programmers.'' {I believe it more likely that you actively resist obtaining knowledge that would contradict this idea of yours, and your resistance to proof is the only reason everything "degenerates" into psychology for you. (If you disagree, please give citations and page numbers. :-) If this claim of yours has ANY validity, you should be able to objectively prove that that some universally recognized 'awful' TuringComplete tool, such as the CellularAutomaton or InterCal, is FULLY equivalent with regards to such '''objective''' (but non-performance) considerations as correctness-provability, security guarantees, portability, asymptotic code volume, code-change costs, and objective resistance to known common forms of programmer fault. Indeed, I'm quite certain the opposite has been proven many times, that you have received full proofs for many of them, that plenty more such proofs are readily available via ACM, and that you promptly 'thumbed your nose' at all such proofs and insisted that it was all psychology (despite your complete lack of evidence for your own claim). Hell, you even think that 'programmer fault' is just a matter of psychology.} There are similar topics to this, but this one emphasizes the "never". The never-ness is telling. Some "absolutists" here complain that I offer no evidence that benefits are subjective. While I believe it contradictory to expect objective evidence of subjectivity, the lack of objective proof for the entire field spanning more than 50 years is a piece of evidence I can offer, as a bonus. So, there you go. --top {There are similar topics to this, but this one has TopMind making an ''even more absolute'' claim without a shred of evidence. Some "intelligent" people might note that "objective proof" means to TopMind something that convinces him despite his stubborn biases; anything less is merely "evidence" and no amount of 'mere' evidence ever will convince someone who is unwilling to be convinced. That which TopMind doesn't wish to see, he'll never see. That's psychology for you. Only if TopMind considers lack of omniscience, lack of perfect foresight, all programmer faults both typographical and logical, communications faults, etc. to be issues of 'psychology', would his primary claim have even a fighting chance at validity. As is, the most he can claim is that he's never found an objective proof he's psychologically willing to comprehend and accept.} * It's not just about me. There is not even a reasonable consensus that there is such a thing, let alone specifics of where it is. There's plenty of "fanboys" promoting their favorite GoldenHammer in an overly-aggressive way, but that is not a consensus by any stretch. * {I don't believe in GoldenHammer''''''s for '''all''' problems. But that doesn't it prevent me from knowing that some solutions are objectively ''worse'' than others by almost every reasonable measure I've ever heard of or come across, and ''no better'' by every other such measure - and, by consequence, that some solutions are objectively better by these same measures. A trivial example was given in AbsolutismHasGreaterBurdenOfProof. Nor, incidentally, does not believing in GoldenHammer''''''s for all problems prevent me from believing in B''''''lindFoolsAndCharlatans.} [ToDo: move material from AbsolutismHasGreaterBurdenOfProof into here] ------- Notable Past Attempts: * Code Size - Those who claim this tend to withdraw this claim when somebody can find a program smaller than theirs for the same task, but its so compressed and factored and context-sensitive that its difficult to read, understand, and change. Generally an agreement is reached that code-size should not be the only factor, but simply one of many to weigh. Library size (built-in operations/frameworks) also tend to skew the results. Related: LinesOfCode. * GoTo's - The best arguments I've seen are related to psychology, and no objective proof that blocking is better has stood up to scrutiny. -------- ''Re: GoTo's:'' ''Do you need to see some proven case studies where jumping from one procedure to another is scientifically bad or evidently bad? There are several written case studies of why GoTo's can be avoided and replaced with better alternatives - is this not enough evidence and proof? How about if we find some program that cost a company millions of dollars because of GoTo's, would that be evidence?'' * All of them I've seen involve psychological assumptions. If not, cite your sources. ''Identifying where GoTo was useful (GoodUseOfGoto) and where it was '''not''' was the '''progress''' made by '''banning''' it ('''aim high'''). Once we aim '''too''' high and realize we aimed too high (Wirth and Dikjstra) then we simply make a small exception to our high aims. Without such articles as '''GoTo Considered Harmful''', people might still be coding in unstructured Basic with BrainDamage. Aiming high and trying to ban the GoTo was good, regardless of whether or not there are very special cases for an occasional GoTo. Similarily, aiming high for normalization is better than sloppily coding MySql spreadsheets - even if in exceptional cases you cannot use normalization to its fullest potential. Writing an article such as "MySql Considered Harmful" or "ImproveDatabasesOrElse" is a high aim and it serves a purpose just as "GoTo Considered Harmful" served a purpose.'' That might be true, but that is still not objective. The reasons I '''personally''' like blocks over lots of goto's is generally psychological. Blocks are usually better MentalIndexability for me and indentation offers visual cues. But, your association of goto's with wide-tables is silly. If anything, narrow tables are more pointer-centric. --top {''Tables are not pointer centric - you might be thinking about implementation details again. A database could even use BrainFuck as its underlying implementation and still be a proper database, whether it uses pointers or not - what's your point? Pun intended. Tables are all different shapes and sizes - narrow, wide. Please explain what you mean by narrow tables - you use narrow tables yourself when you first start making a table initially, do you not? A table starts out small - so it is using pointers when you first start building your business app, but stops using pointers as it gets wider? What the hell?''} * No. Narrow tables in general use more ''conceptual'' pointers. * ''Okay take an example: you fire up mysql and start making a table.. it is narrow.. then as you expand your application it gets wider. As it gets wider, the conceptual pointers decrease? What the hell are you thinking?'' * Somewhere there is a communication breakdown here. I'll see if I can find the old topics on this. * ''Do you mean a database that has plenty of narrow tables instead of one large wide table, where your narrow tables have references to other tables instead of it being all in one single table'' {''And the reason we like evolution better than creationism is purely psychological too. Err wait a minute, can that be right? There are actual papers written about GoTo which prove that goto is unstructured. There are logical reasons why unstructured programming is bad, just like there are scientific reasons why drinking gasoline is bad, or producing an unstructured house is bad (since it is harder to maintain). One could argue that an unstructured house is just as good as a structured one, because psychologically some person might prefer living in an unstructured home made of straws and snot, instead of bricks and mortar. Seriously, give me evidence right now, that unstructured homes are bad? Who is to say? Where is the evidence? There isn't any immediately available, but it could be found if you actually looked it up. You could do science tests on bricks and mortar and study how easy it is to maintain a brick house versus a straw house - and you can also do science studies on programs, studying how easy it is to maintain a program with gotos versus a structured one with less gotos. The structured program would win, like the brick home, and it would win objectively. Objectively a structured home is better than an unstructured home. Structured programming (reducing goto's) is objectively better than unstructured programming - but it doesn't mean unstructured programming isn't TuringComplete too! With an unstructured home built with straws and snot (instead of bricks and mortar), you could still build a complete home. Home Complete! Turing Complete! See DenyingObjectiveEvidence''} You keep stating this about goto's all over this wiki, but never prove it. Learn to factor your rants and link instead of repeat them all over. (See OnceAndOnlyOnce.) You know our friend science: Here's my metrics....Here's why I chose these metrics...Here are the numerical results...Here's why the numerical result show blocks are better than goto's, etc. ''If you had actually taken the time to read the structured programming articles and actually digest what they were saying (instead of relating it to psychology, which has absolutely nothing to do with it) then you wouldn't keep saying there is no evidence against gotos.'' * Pick a paper you feel is one of the best, then write up roughly a half-page summary (about 4 paragraphs) in it's own topic such as "DrFooGotoStudy", and then link to study/article itself. Note that I won't fork over cash for ACM papers, and it's unrealistic you expect other readers to also. Thus, you will probably have to re-state the evidence yourself if it's fee-based. I agree a productivity study could be done, but it hasn't yet. The existing evidence is NOT based on productivity studies. I'm just the messenger. ''There are no productivity studies done on booleans either - therefore booleans are probably bogus.'' What? I never said lack of study means a tool is no good. Where the hell did you get that? I'm only asking those with strong absolutism opinions to provide real rigor for their claims before trashing other people who disagree. Basically you insulted me for disagreeing with you, and that triggered me to ask for more rigor from you. That's fair and common. Note that capitalism relies heavily on ArgumentFromPopularity, for good or bad. It's the model we chose to use as a society for measuring "goodness". -t -------- See also: ObjectivityIsAnIllusion, ThereIsNoObjectiveEvidenceThatKeyboardsAreUseful CategorySubjectivityAndRelativism, CategoryEvidence