''Try it! You'll like it!'' One of the FallaciousArgument''''''s, wherein it is asserted that dislike of the topic or position at hand (which is supported by the speaker) implies a lack of thorough understanding of that topic or position. In other words, a type of AdHominem argument - it is asserted that disagreeing with the speaker implies a lack of qualifications in the subject. Often, this fallacy is supported by a demonstrable correlation between knowledge of the subject and agreement with the speaker's position! However, CorrelationImpliesCausation itself is a fallacy; there are several different possibilities which may be explain the correlation: 1. Familiarity with the subject does ''indeed'' lead to agreement with the speaker's position. The conclusion the speaker wants you to draw. 1. Those who agree with the speaker's position are more than likely to study the position in detail than are the general population. This is common when the speaker's position represents a minority viewpoint, and a large number of those agreeing with the speaker see it as their mission to evangelize to the rest of us. 1. The literature, coursework, etc., which one must use to become familiar with the topic at hand is itself biased to the speaker's position; or the speaker (and his clique) have become experts by reading only a subset of the literature available (that which supports their position). 1. Literature which disagrees with the speaker's position is dismissed as lies, propaganda, cluelessness, etc. - anyone who is well-read in ''that'' can similarly be dismissed as an ignoramus. This fallacy also contains elements of NoTrueScotsman; as the definition of "knowledgeable person" is limited in scope to "knowledgeable person who agrees with me". And it seems to be a special case of the DogmaticFallacy. -------- This (alleged) fallacy is often used by those who don't support general SelfStandingEvidence. They will argue or imply that the topic is too complex or give a rebuttal on Wiki, and that the answer is found in volumes of references or books. In other words, a BookStop. Related: ScienceShouldBeEasy. My belief is if you cannot explain your viewpoint on Wiki, then it is likely an invalid or ill-formed view. -- top {I wrote a response here that I decided belonged on TopMind instead --ChrisMellon] Re: "alleged fallacy" -- the start of the page clearly describes circumstances when it would indeed be a fallacy. I assume that your objection is to the cases when someone '''claims''' that is the case incorrectly. That is, just because I '''claim''' you dislike it merely because you don't understand it, that doesn't mean it's true, and if in fact it is not true, then I would be the one making a fallacious claim. That's always the case, though; for every logical fallacy, someone can incorrectly claim that it has occurred. Conversely, someone can correctly claim it has occurred, and yet it could be incorrectly denied. That's not unique to the topic of this page. Anyway, top, you're not entirely wrong when you say if you can't explain, there's a problem, but you're on thin ice, because you don't always accept explanations that other people consider clear, so with that history, you're not going to get very far saying that, you know? * ''Perhaps it is off-topic, but where I have rejected clear and relevant evidence? Claiming something is clear is not the same as being clear.'' * I certainly hope that, from your point of view, you believe you haven't done so! That would mean bad faith. The point is that some other people have said they believe you have done so. I'm not one of them, and I'm not claiming that. I'm just saying that, with that kind of reputation in certain quarters, you won't get far with certain kinds of arguments. Just common sense, really. * ''Well, those guys seem to think that "elegance" is a real metric. I feel that they don't understand the scientific process and/or feel they are immune from it.'' Regardless, I think that your phrasing is too strong anyway. It is not "likely an invalid or illformed view", it's more like a Smell. Not the same as "likely". Gotta soft-peddle that more. Some things are just hard to explain, truly. Here's an example I ran across yesterday, where DanBernstein is describing the future prospects for proving numbers prime...a small quote: "For these cohomology groups, one can take a p-adic approach using a de Rham-type cohomology, lifting X to a p-adic ring R and take the hypercohomology of the de Rham sequence, quite explicit and computable but the complexity is worse than linear in p. Instead, , the H^i derive from injective resolutions on the etale topology." Some technical subjects can't really be adequately explained to anyone but another specialist, so one should be careful of blanket statements about explanations. -- DougMerritt ''Well, that is the crux of the problem. Somebody can claim that their pet position is like that even though it might not be true. In software it often comes down to, "If you were properly informed, you would then understand how elegant my solution is". In your example it is not that difficult for a non-mathematician to verify that a claimed prime is a prime. Testing a prime is far simpler than deriving one. The above appears to be speculation about future techniques, not something objectively measurable. If software solves (or creates) real problems, then there should be real metrics. Elegance is not a metric. If you consider "elegant" math to be a short equation, then that is a code-size issue more or less, which is measurable to some extent. Software is not to please programmers, but to please managers and customers. If X is better than Y, then ways must be found to relate it to what managers and customers want. If the above people made claims such as "The X algorithm can find more primes than the Y algorithm per hour", that can be tested. The manager or customer who wants primes, say for security purposes, can count that even if they are not mathematicians. The above are like to engineers arguing about which car engine design is the fastest. The ultimate test is on the race course where even non-engineers can measure the results.'' Umm...no, some problems there. "is not that difficult for a non-mathematician to verify that a claimed prime is a prime" -- that's actually false, because we're talking about arbitrarily large primes. If I claim that 1 billion factorial plus one is prime, you can't verify that (but in some cases DanBernstein and his colleagues might be able to). ''Well, okay a "usable" prime.'' * Won't help you; large primes actually do have application to real world algorithms (ok, yes, I usually get by with small primes, but it depends on the algorithm). Nor does it matter that he's talking about future techniques, because that lecture is years old and is now current technique. :-) Also you're now talking about "objectively measurable", which is always interesting to talk about, but before it was just about "explanation", so that's a topic change. ''I am quite sure what you mean. However, the topic is kind of weird in that it talks about "liking" instead of being better or worse.'' Also "Software is not to please programmers" -- not quite true either; the '''behavior''' of software is to please managers and customers, but the interior '''form''' of software is irrelevant to them, and is indeed crafted to please programmers (and of course micromanaging first level managers, but then they are a kind of programmer when they do that). One needs to keep claims about the behavior of software separate from claims about the interior form of software. Primes per hour can be verified objectively, yes; that's behavior. Easier for future maintenance programmers to understand, is about the form, but is frequently subjective, and is almost never purely objective. ''The manager cares about productivity. If maintenance slows down productivity, then it is an issue. It appears to me that people are most productive when they work in like-minded teams. Twins tend to be highly productive because they think so much alike that they don't have to spend a lot of time communicating and living with code style that they are uncomfortable with. It is the similarity, not absolute value of techniques that seem to matter the most.'' To bring up a specific example, Barbara Liskov's LiskovSubstitutionPrinciple is purely and wholly from mathematics, but is reinterpreted by non-mathematician programmers as a rule of thumb about elegance - which works to some extent, but misunderstands. Certain aspects of programming such as that actually do need appropriate mathematical background to truly understand, without which even the best of explanations will be at least partially misunderstood. So I wasn't just making a completely unrelated analogy. Some aspects of software need math. -- DougMerritt ''But that is generally a domain-specific issue.'' Not in the case of this particular example. It is one of the strongest non-objective criteria regarding creating OO software of any and all sorts. (It actually applies to non-OO, also, but I don't think that's super widely appreciated/practiced.) ''I did not mean type substitution but the first example. I did not make that clear. Besides, the substitution rule does not say whether types are good. It only provides a framework to keep them predictable IF you decide to rely on types.'' * Untrue. I will grant that you can criticize various type schemes, as I have granted before, and I understand non-literal use of language for metaphor and such, so if you say "there are no types", I can potentially accept that non-literally to mean, for instance, there are problems with the type schemes you're aware of, that you don't want to use certain kinds of types, etc. * But you cannot literally and formally say "types don't exist", because you're not going to be able to find anything better than a mathematical definition for the word "exist", there, and mathematically, types certainly do exist because their existence has been formally proven in several areas. Particularly because the situations often called "untyped" are actually "single-typed", so everywhere you've got at least one type. You can choose your type scheme, but it's meaningless to try to claim that you can choose not to use types at all. This is about 50% on the topic of word definitions. * Furthermore, even aside from that, as I mentioned in passing, the LiskovSubstitutionPrinciple isn't just about OO, since it originates in non-OO math; it applies wherever there's more than one kind of thing, regardless of how you define "kind" and "thing". I know damn well that in your part of the world, you differentiate between "employee" and "salary", and I don't care whether you call that "types", or not; there is apropos mathematics, including the LiskovSubstitutionPrinciple, that applies as soon as you distinguish things by any means whatsoever, whether you wish to pay attention to such analyses or not. * ''Those are "entities", not "types". Whether they overlap or not is perhaps another topic. Types generally come into play when there are (alleged) sub-variations of entities, such as a "kind of" employee.'' * Entities '''are''' types, Top. Whether or not they are expressed in a formal constructive type system, by predicate, or by membership in a particular table in a particular database, entities are types. Mathematically speaking. You seem to think that the word "type" only applies to classes, structs, and other programming language constructs used to specify such things formally within a programming language. But to us, types are '''far''' broader than that, and a common complaint is that the formal type systems in programming languages aren't sufficiently expressive enough to cover all the cases. You often express the same lament, though you seem to presuppose the widespread use of a mythical language with a particularly weak type system (though Java comes close), that has further limitations than are found in practice. And the sad part is - the programming languages in widespread use with the most crippled, brain-dead type systems are a) structural languages like C and pre-DotNet VB, and b) SQL. No ''wonder'' you try to express everything as a string; SQL gives you little else. * ''I don't dispute that everything can be thought of as types. There are a lot of EverythingIsa candidates. EverythingIsRelative. The real question is does it help build and manage software. At this point I go into "show me a scenario of betterment" mode. I am open minded, but I want to see code, not words. -- top'' * Well, any RDBMS will prevent you from inserting an "Employee" tuple into an "Accounts" relation. That is an example of a type system (a fairly simple one) detecting and disallowing what is probably a programming error. It's a type judgement which in most cases happens at runtime - most programming languages implementations cannot typecheck SQL queries - but a runtime error is still preferable to an incorrect operation or a trashed system. Likewise, your RDBMS won't let you stuff a BLOB into an attribute which is declared in the schema to be a string of six characters or less. I think you'll agree that having your RDMBS flag these illegal operations - in other words, performing these type judgements - is a good thing. * Where SQL (and relational in general) has issues, is with subtype relations. The pure relational model can easily deal with subtyping by restriction, and it can deal with relations which are extensions of other relations, but it doesn't deal with the combination of the subtyping and extension well at all. OO programming languages deal with it exceptionally well - it's called "inheritance" - and attempts to mimic inheritance in tables (TableInheritance) have failed spectacularly. * And I'll remind you up front that "hierarchies" and single inheritance (a restriction that often imposes hierarchical structure) are '''not''' fundamental issues with OO. Some OO languages, certainly, but don't confuse bad languages with the paradigm itself. Almost forgot: note the rather interesting point above, that the number in question is definitely objectively either prime or composite, but only a specialist has a hope of verifying which. Everyone else is forced to accept the judgement of the specialists, even though it's an objective matter. ''Aren't there accepted algorithms for those kinds of things?'' * Depends on what you think you mean by that. Certainly, algorithms exist, and you're aware of the obvious one that you yourself would apply to determine whether 31 was prime or not - and yes, there are quite a few other algorithms on the topic - are any perfect? No. Is it a finished research area? Not even close. Are any good enough for everyday use? Well, for some things, like RSA encryption. Will any of them allow you to test the example above, 1 billion factorial plus 1? No. It would have to be attacked by a human mathematician, who might or might not discover a proof one way or the other. * The question is rather ironic anyway, because consider this: let's say there's an ultimate algorithm for telling whether a huge number is prime or not, 100% accurately. But this doesn't allow you to do the verification you're talking about! Why not? Because the algorithm was invented by someone like Bernstein, directly implementing theory such as the above quote, and again, you won't understand the algorithm, so again you'll be taking the specialist's word for it that it does what he claims. So that doesn't go anywhere. In cognitive science/anthropology this is well-known and has a name, which I've forgotten... the usual example is that everyone knows that a birch and an ash are both trees, but a large percentage of the population has no idea how to identify them. We rely on specialists (which in this case could be simply nature lovers in parts of the country where both grow) to tell the difference for us. * I found a note about this; the particular example seems to come from Kripke 1980 Naming And Necessity, quoted by another author as "notes how people willingly defer to scientific authority the task of knowing what essences are. (e.g. birch trees vs ash trees)". Other authors have said things stronger than "willingly defer" and have discussed the inevitability. -- DM Or less dramatically, most people could probably do pretty well at pointing out bushes versus trees, but would not be able to formally define the difference (unless you accept Peanut's "a tree is a bush that made the bigtime"). The same thing absolutely happens in software. You're competent, you can tell a bush from a tree. You may even be able to tell an ash from a birch. But there are always going to be some areas where you're not a specialist, and must rely on the opinion of specialists. -- DougMerritt ''Classifications usually don't make very good examples. What something is labelled as and whether it is useful are two different things. Labels may allow us to make short-cut judgements, but they are not a substitution for science. For example, a paper-maker may know from experience that certain kinds of trees make better paper. However, "better paper" is the real metric. It is just that it is not practical to test every tree. Related: LimitsOfHierarchiesInBiology'' Yes, I know, we've talked about that page before, and I just wrote something on Intertwingled just yesterday that roughly agrees with your favorite philosophy here trees and hierarchies have limits, yes, yes. But no, that doesn't really apply here, because nothing you said contradicts the point that you must rely on specialists' judgements. If an expert paper maker says that it's best to use birch wood, then you can't verify his argument - it may sound convincing or it may not, but you really don't know, since you lack the various multiple related background specialties to verify. Conversely, you're agreeing that the classification of trees does matter to that paper making specialist. So that whole paragraph really went nowhere. Either you become a specialist and you learn things like topology to understand Bernstein's argument about primes above, or else you just have to accept his judgement. Either you become a specialist and learn about mathematical type theories, else you have to accept the judgement of specialists like Liskov. You haven't made a counter-point against this. -- DougMerritt ---- IdontUnderstandLispButIlikeIt I really like Wiki, but I only think I understand it because I know how to use it. ''Exactly like everything else in life! :-)'' ---- FallaciousArgument