(Begin Rant)

Some claim there are industry "canons" without any evidence beyond anecdotes or cherry-picked citations. I'm growing tired of these FakeIndustryCanon''''''s.  Establish canons with solid evidence and statistically valid samples (random) or don't imply a canon exists (beyond a "soft" anecdotal suggestion). Knock it off! --top

(End Rant)

''Out of context, this is reasonable.  Taken in its implied context, most of the canon you appear to consider fake seems to either be what introductory SoftwareEngineering and ComputerScience texts explain at length, or what is so foundational in those fields that it's taken as given.''

Then do a '''proper''' textual survey to show they universally say (and prove) one factor or concept is more important than another. It's not my job to prepare YOUR evidence for YOUR claims. -t
 
''No one said any concept is more important than another.  However, some concepts are more recognised or established than others.  Some concepts are recognised by almost everyone in SoftwareEngineering and ComputerScience, and others appear to only be recognised by you.  If you were an authority in SoftwareEngineering or ComputerScience -- like a Djikstra or Knuth, or even a Yourdon -- that might have some weight.  Given that you're not Djikstra, Knuth or Yourdon, your unique-to-you concepts have no weight.  Like the rest of us, if you want your new concepts to gain weight, you have to back them up with strong and compelling evidence.''  

''Note, by the way, that Djikstra, Knuth, and even Yourdon became authorities in their respective fields by consistently backing up their ideas and concepts with strong and compelling evidence.  You could do the same.''

They are topic titles. I don't see a problem. If you wish to classify topics into some kind of "official" versus "non-official", please see PageAnchor topic-disclaimers-01 at NormalizationRepetitionAndFlexibility. (EditHint: move that section here?)

And the rest is blatant ArgumentFromAuthority (or popularity per popularity of author).

''How do you think they became authorities, so that you could even allege ArgumentFromAuthority?  Why do we respect the writings of Knuth, but less so for the writings of Top?''

Arguments should stand on their own merit and logic. I do my best to explain my reasoning. I don't do design suggestion X more than Y because because Dr. Foo said so, but rather because Dr. Foo explained '''WHY''' doing X matters more than Y. -t

''Do you think your best is good enough?''

To you, no. Unfortunately, software engineering (SE) is mostly about WetWare, and WetWare is still an infant science. Software is written for humans '''first''', and machines secondly. This state of affairs isn't my doing, I'm just the messenger. The component on the human body that processes software is called "the brain". Therefore, if we want to optimize software for it's intended use/goal/target, then we must understand this component known as "the brain". -t

You appear to ''want'' SE to be about math and machines, making the SovietShoeFactoryPrinciple error. You value "solvability" over utility. It's my opinion that this is your key psychological point of error that leads to you optimize for factors that matter only a little to the end result. -t

And note that academics tend to focus on easy-to-analyze factors over important-but-difficult-to-measure factors BECAUSE they are difficult to measure. If it's easier to study factor X over factor Y, then of course academics are going to study factor X more than factor Y. But that doesn't mean that factor X is more important. Thus, there is an '''inherent bias in academia'''. It's not a "fault" of people, but rather just the nature of the '''economics of science''' in that we milk the low hanging study fruit before the higher fruit. It's rational allocation of resources, but with the '''side-effect of measure bias'''. It's why we know more about rat biology than human biology; but that doesn't mean we consider rats more important. 

Therefore, the '''quantity of mention or study of a given topic is not necessarily proportional to its importance'''. A "book count" would thus not be a very good source of importance measure. --top

''That's an interesting rant, but it -- like most of your arguments -- has no basis in evidence.  If you're going to ever achieve any respect for your opinions, you need to back them up with evidence.''

Got some?

''I'm not the one making bold, contrary, and unsubstantiated assertions here.''

Me neither. Maybe it's that pink rabbit in the corner.

''This Wiki is full of your contrary and unsubstantiated assertions.  With logical arguments and evidence to back them up, some of them might be innovative or valuable, and worthy of recognition.  Without logical arguments and evidence to back them up, they're nothing but questionable opinion.''

* Unfortunately software is mostly about WetWare, not "traditional" math and science. I'm just the messenger, I did not create this state of affairs such that complaining to me about it will not change it. If you only want to focus on easy-to-collect analysis, you'd likely be committing the SovietShoeFactoryPrinciple sin. '''You won't solve most software problems with test-tubes and chalk-boards''', and nobody here wants to donate the money for real studies. See also DisciplineEnvy.

* ''Software '''preferences''' may be "about WetWare", but that's irrelevant to ComputerScience and SoftwareEngineering.  The product comparisons you seek are properly the domain of ProjectManagement and business productivity; look to business academia if you want the psychology of software to be a consideration.  Alternatively, try bringing it into ComputerScience and SoftwareEngineering by writing some preliminary papers on the subject.  If you want them to be noticed, you'll have to treat the subject scientifically and rigorously.  If you want your writing to be accepted and validated and not merely dismissed as opinion, you have to think like your critics and anticipate their counter-arguments, and address those arguments with irrefutably compelling logic and sound evidence.''

* Hell, the industry cannot even prove something as basic as goto's being "objectively worse" than blocks.

* ''Why would it "prove" (science doesn't do that; only math and logic prove statements, and then only in highly constrained areas) something that isn't necessarily true?  It's worth reading http://dl.acm.org/citation.cfm?id=1241535''

** That's not "strong evidence" either.

** ''Who said it was?''

* If you wish to fork off your OWN wiki that ONLY focuses on "traditional" math and science with all its easy-to-prove but marginally useful conclusions, please do. Nobody is stopping you. -t

* ''I have absolutely no objection to discussing the psychological or "WetWare" aspects of software here, but only if they are evidence-based.  Pointless water-cooler rumination about (for example) whether or not the "average" programmer can/can't understand some software feature, and the like, should be deprecated -- it leads nowhere and gains nothing.''

* Personal observations about programmer behavior are acceptable evidence on THIS wiki. If you don't like that norm, feel free to lobby WikiZens for a change. But until the vote is tallied, the norm stands. And why do you keep complaining about this norm? It just wastes text. We already have a topic on it: AreWeaklyBackedOpinionsAcceptable. THIS topic is about alleged canons. Please don't cross-confuse evidence type debates with canon debates.

* ''Personal observations are fine, if such observations are described.  Unsubstantiated statements of "fact" have never been acceptable evidence, especially as they aren't evidence.  That's why you are opposed pretty much every time you make them.''

** To the best of my knowledge, I'm not "doing it wrong". You'll have to do a better job of explaining your complaints at the source of the problems. 

** ''If you were doing it right, your posts wouldn't be opposed pretty much every time you make them.  Instead, you'd be a "thought leader", respected for your contributions.  The difference lies in your ability to present a compelling case, and presenting a compelling case relies on evidence and logical argument.''

** It's the '''same''' 2 or 3 people that seem to complain, perhaps for personal reasons or because I downplay the worth/contribution of academia, which seems to be their life ambition, and thus they are defensive of their livelihood the same way buggy whip makers would be naturally defensive against automobiles. Sorry, I'm not going to kiss up just to "get along" with the academics. Their ideas don't get to cut in line. And I DO make logical arguments. Sometimes such logic will be based on my own observations of WetWare/behavior, but that is acceptable evidence on this wiki. If you give me a check for 20 million dollars, I'll be happy to test those observational patterns on actual projects. -t

** ''Over the course of Wiki history, active participants leave and new ones join, so that the aggregate number of participants is relatively large but at any given time the number of active participants is relatively small.  It has always been that way.  Thus, today, the same 2 or 3 people object to your postings.  Whilst at least one of those current participants is an academic (i.e., me), your objectors over time have been a large and very diverse population with few apparent academics.  What is consistent is that over time, there are '''always''' 2 or 3 people actively objecting to your postings, and for largely the same reasons:  Your postings demonstrate superficial knowledge of the subjects you target, and your justifications are invariably weak.  That inevitably draws opposition.  What do you think would happen if you gained in-depth knowledge of the subjects you targeted and presented strong, evidence-based arguments underpinned by evidence?''

** By the way, where is the "compelling" (your own words) case for the existence of IT canons? -t

** ''They're self-evident, obvious and apparent to anyone working in the field.  That's what makes them canons.''

** No, they are not. I can agree certain people are "relatively well-known" in IT, but that's not canon-level. Further, IT celebrities having a certain opinion is ArgumentFromAuthority if accepted BECAUSE they are celebrities. The bottom line is that very few have done direct studies on "tool comparisons". Thus, solid evidence is lacking for tool comparison. '''If this wiki is to ONLY contain solid direct evidence, it would be maybe like 200 pages'''. Instead, we have to use indirect implications, speculations, and anecdotes as ProxyFactor''''''s for real studies. I didn't create this state of affairs such that complaining to me about it won't change it. -t

** ''It has nothing to do with well-known people, and everything to do with established foundational knowledge.  It's the stuff in every introductory ComputerScience textbook.''

** What "established knowledge" that is relevant to tool benefit comparisons? Please list it, perhaps under another topic if that's appropriate.

** ''In terms of ComputerScience, it would depend what tools you're comparing.  If you're comparing languages, you need to understand principles of language design and implementation, and probably understand various language paradigms.  If you're comparing assemblers, you need to understand machine language and linkers.  And so on.''

** Implementation of compilers/interpreters? No, not really. Programmers usually don't know and don't care about that. And one should also understand user WetWare and economics, not just languages. It's all part of the "system" the produces the result. Actually, a good study would NOT need to "know" anything about the language: it would simply look at the profitability of a large quantity of companies using tool X versus those not. That's a form of RaceTheDamnedCar. Engine construction knowledge is not needed to merely race.

** ''There's no need to understand "user Wetware" and economics in order to compare the technical merits of languages.  If you're intending to compare their application in the workplace, then understanding user Wetware and economics may make sense.  That, however, is a ProjectManagement or business concern, not a ComputerScience concern.''

** What exactly is a "technical merit" outside of machine performance? And I don't care what DeweyDecimalSystem classification or Harvard building issues fall into; they are either important for tool select or they are not.  That's rather arbitrary.

** ''Speed, memory consumption, reliability, robustness, isolation, coupling, cohesion, composability, flexibility, abstractness, durability, etc.''

** See near PageAnchor grokkability-01 in ScienceAndTools.

* I would also note that the default position is NOT that a given code design doesn't confuse programmers. The confusion rating is "unknown" until further evidence.

* ''True, but much of your (for example) anti-HigherOrderFunction arguments revolve around your insistence that HigherOrderFunctions '''do''' confuse programmers.  That isn't "unknown" on your part, you believe it to be known.  I believe it to be unknown or demonstrated false (look at all the HOFs being used in JavaScript!)  At the very least, if it's "unknown", it's not worth discussing until it is known.  Perhaps HigherOrderFunctions cause Alzheimer's and flatulence?  That's unknown, too.  Shall we change the way we program just in case HOFs '''do''' cause Alhzeimer's and flatulence?''

* I have NOT "insisted". That is flat wrong. You appear to be imagining angles I haven't actually typed as text. I have proposed LetReaderDecideEvidenceAgreement so '''both parties can freely present their viewpoints'''. The agreement is very fair and flexible. If somebody wants to add a 3rd flatulent claim to the list, that's fine, but the reader is likely to ignore it in practice. '''I'm not asking readers to accept my staff WetWare claims at face value''', only describing the implications IF they agree with the staff profile. Your staff assumption hasn't been solidly proven either. It carries no more weight than my viewpoint. And people are often forced to use JS and its HOF-centric API's because it's a de-facto client-side standard (QwertySyndrome), ''not'' because they like JS. (I see alot of complaints about JS in discussion boards.) We've been over this already. Let's not reinvent the JS fights here. Until somebody does a formal JS "love" survey, it's an AnecdoteImpasse.

* ''You propose LetReaderDecideEvidenceAgreement '''now''', but that has not always been the case.''

* I've been using a form of LetTheReaderDecide for at least 2 years, I believe. But why fuss about bygones anyhow? Don't complain about small things.

* ''You tend to use it after the argument has gone on for a few months.  It would be nice if you started with it.''

* I do not believe that to be accurate. And why did you forget the first few times I used it? It appears to me you are obsessing on that particular issue, refusing to LetItGo.

[Let's put a PleaseAddEvidence tag on ideas that might be innovative or valuable if properly supported.]

Keep in mind I'd be happy to use it also.

''Excellent.  That's how it should be.''

----------
What in the world? I thought TopMind was getting more moderate and reasonable (and more modest, in contrast to his alias), but this is like something out of his early years!

''There seems to be a fundamental difference with how some of us view "science" and "evidence". Software has an '''"evidence problem"''', and I'm not the first to point this out. For example, I did NOT create the topic: DisciplineEnvy. --top''

{Curiously, I find it difficult to discern what your view is on "science" and "evidence".  In some contexts you appear to demand evidence beyond the norm, and in others you find it acceptable to provide no evidence at all.  What it appears is that you want agreement with your opinions, but don't want to work to get it.}

First poster speaking: I'm completely fine with what Top said here. Software development isn't math; it's a soft science like anthropology, history, or military tactics. Haskell tries to turn software development into math, but it has to jump through some pretty complicated hoops to get there; and speaking personally, I've found my knowledge of MrAristotle, NaturalPhilosophy, and RomanCatholic theology infinitely more useful in programming than my knowledge of advanced math (although algebra -- semi-advanced math -- is absolutely indispensible). I think it's better to live with the soft-science situation than to be consumed with DisciplineEnvy; and I endorse the idea that a given programmer should use the paradigm that he's most comfortable with, which seems to be the main thing Top's saying. I'd add, of course, that self-improvement and engaging with new challenges are important -- but that doesn't mean that everyone has to drop everything and learn Lisp. You can only learn what you already almost know (that's a wiki page, right?) -- evolutionary improvement, like C to C++, C++ to Java and Python, Python to Ruby, C++ to C++11, is probably more useful than attempts to change one's way of thinking all at once.

{Software development isn't math, but it isn't a soft science either.  It's a craft, like making furniture.  What Top appears to want from us are studies that prove screws are better than nails, whilst we should take his word for it that typical carpenters are confused by lathes.}


''Re: "the idea that a given programmer should use the paradigm that he's most comfortable with, which seems to be the main thing Top's saying" -- Not quite. Ideally we'd have productivity studies to decide what technique is more productive in team environments (or at least shared code). But since those are not practical to obtain, team preference is probably the NEXT best approximation/proxy/consolation factor (see ProxyFactor). '''We generally agree on what an "ideal" study would look like, but the hard part is agreeing on how to score the messier alternatives to ideal studies. -t''' ''

''Re: "What Top appears to want from us are studies that prove screws are better than nails" -- What are you referring too? Don't we ALL want studies that demonstrate if one IT tool is better than another? But since we are not likely to get such studies, we need proxy (consolation) studies and analysis instead. Some of this will result in relying on weaker forms of evidence, such as personal anecdotes about coder behavior. -t''

''Re: "whilst we should take his word for it that typical carpenters are confused by lathes." -- No, that is flat wrong. See LetReaderDecideEvidenceAgreement. The quality of results is obviously affected by carpenter skill level factor and it's unrealistic to assume infinite or elite skills from average carpenters. You seem to want to set the default skill level assumption at an unrealistic level. Why should we take YOUR word for it that a high skill level should be the default assumption? '''You are in the same boat''', Bub. I vote to let the reader decide which profile claim fit's their OWN shop rather than keep bickering over whose profile is "right". YOU cannot let it go.  -t''

I didn't see any reason to get quite that angry in response to that comment -- but then, I'm not a regular. Letting the reader decide seems reasonable, not least since different tools will cut with or against the grain on different tasks. (Haskell, for example, is not a good language in which to write a <strike>word processor</strike> %thing_which_should_not_be_written_in_Haskell%.)

* [Have you tried writing a word processor in Haskell?  If I had to write a word processor, starting today, I'd write it in Haskell.]
* What would you say should not be written in Haskell?
* [I probably wouldn't write an operating system kernel or device driver in Haskell.  It isn't really designed for low-level systems programming.  However, anything that can be done in a conventional, imperative, application development language like Java or C# can be done in Haskell. <some time passes; some reading is done>  On the other hand, I might change my mind.  See http://book.realworldhaskell.org/read/systems-programming-in-haskell.html]
* I vividly remember someone attempting to implement Pac-Man in Haskell in 2011; a month and four densely-reasoned webpages later, he had a more or less functional game, but it was very brittle and not very extensible, and he admitted that this could be done in C in a couple of days. Has Haskell become any more suitable for games -- especially games with a bit more heft to them than Pac-Man -- in years since? (I will candidly admit, I hope it hasn't. I neither like nor trust that language, given how fond it is of higher math and opaque terminology, and I'm very alarmed by how much prestige it commands these days. I hope that niches, at least, will persist where other languages can flourish.)

Bracket-posting respondant, good point on software as craft. Some soft sciences are unprovable or have intractable problems collecting data, or are oriented towards moving targets; others are testable but not reducable to physics (linguistics, for example); but software isn't either, since with software the odd thing is that wildly different methodologies can produce equally good or bad results.

----------
CategoryStandards, CategoryScience
----
DecemberFourteen